Una empresa elige al proveedor de reconocimiento de voz para su agente de voz más o menos así: abre un ranking, mira la primera fila y revisa si el ucraniano figura en la lista de idiomas admitidos. Casi siempre figura. Ahí suele terminar la revisión.
El problema es que la cifra de la primera fila no se midió con el tipo de audio con el que va a trabajar el agente. Y una medición hecha con ese audio no la hemos encontrado: ni en las páginas de los proveedores, ni en rankings independientes, ni en publicaciones de arXiv.
Tres cifras públicas sobre el ucraniano, y ninguna habla de tu llamada
Estas tres cifras son las que más se citan cuando se habla del reconocimiento de voz en ucraniano.
Cifra | Qué se midió exactamente | Quién midió | Condiciones de grabación |
|---|---|---|---|
3,5% WER | Scribe v1, ucraniano | ElevenLabs, página propia | FLEURS: habla leída, de estudio |
2,3% WER | Scribe v2, clasificación general | Artificial Analysis, AA-WER v2.0 | conjunto sin ucraniano |
8,5% WER | modelo de Soniox, ucraniano | Soniox, comparación con Google | audio de YouTube, 2025; la página ya no abre |
Cada una de estas cifras es correcta. El problema surge en el momento en que se ponen una junto a otra y se empiezan a comparar.
La primera sale de la página de ElevenLabs dedicada al ucraniano. Allí figura un 3,5% de WER —word error rate, la proporción de palabras mal reconocidas en la transcripción— en el benchmark FLEURS, y la tabla indica expresamente que se trata de Scribe v1. FLEURS es habla leída en voz alta y grabada en buenas condiciones: locutor, silencio, banda de frecuencias completa.
La segunda cifra sale del índice AA-WER v2.0 de Artificial Analysis, un tercero independiente. En agosto de 2026, Scribe v2 encabezaba ese índice con un 2,3%, seguido de Gemini 3 Pro con un 2,9%; a octubre de 2026 tiene un 2,2% y ocupa el cuarto puesto. Solo que el índice se compone de tres datasets: AA-AgentTalk (peso del 50%), VoxPopuli-Cleaned-AA (25%) y Earnings22-Cleaned-AA (25%), y allí no se publicó ningún resultado en ucraniano, como tampoco ningún desglose por idioma. «El mejor modelo del mundo» es una afirmación correcta sobre un índice en el que tu idioma no estaba.
Con la tercera cifra pasó lo más interesante. La página de comparación de Soniox con Google daba un 8,5% de WER en ucraniano frente a un 18,3%; era material del proveedor, pero con las condiciones indicadas con honestidad: un estudio de 2025 con audio real de YouTube. A 25 de agosto de 2026 esa página ya no abre. Los buscadores todavía la recuerdan, pero el servidor devuelve un 404.
Lo que ha quedado en su lugar, en la página activa de Soniox sobre el ucraniano, son, a octubre de 2026, las fórmulas «World’s most accurate Ukrainian speech-to-text» e «industry-leading error rates», es decir, afirmaciones sobre la máxima precisión y la tasa de error más baja sin una sola cifra. El mismo proveedor tiene una sección de benchmarks, pero solo mide el inglés.
La diferencia entre el 3,5% y el 8,5% se leía como una ventaja del doble para el primer modelo. En realidad es la diferencia entre una locución grabada en estudio y vídeos de YouTube: se comparaban condiciones, no modelos. Además, en años distintos y con las versiones que cada proveedor eligió por su cuenta. Y ahora una de las dos cifras simplemente ha desaparecido: ya no se puede verificar en la fuente original.
Por qué el canal telefónico hay que medirlo aparte
Las tres mediciones tienen un rasgo en común: ninguna se hizo sobre telefonía.
Una llamada telefónica es una señal de banda estrecha: frecuencia de muestreo de 8 kHz, banda útil de unos 3,4 kHz, compresión con el códec G.711. Frente a una grabación de estudio con muestreo de 16 kHz o más, se le recortó físicamente la parte alta del espectro. Justo ahí viven los rasgos que distinguen las consonantes sordas, y las sibilantes del ucraniano, que abundan en el idioma, son las primeras en resentirse. Súmale a eso el ruido de fondo del lado de quien llama: la calle, el coche, una tienda, un niño cerca.
Un modelo que marca un 3,5% en una grabación de locutor va a marcar otra cifra con este material. Cuánto difiera depende del modelo concreto, y justo esa prueba en ucraniano no la hemos encontrado en fuentes abiertas.
Hay otra trampa, puramente técnica. Muchos cuentan con obtener el audio de la llamada mediante la API HTTP común del proveedor de telefonía y después descubren que allí solo queda la grabación a posteriori, cuando la conversación ya terminó. Para la analítica de llamadas basta; para un diálogo, no. El flujo en vivo lo da una troncal SIP, y eso ya es una capa de medios propia en el circuito: un SBC que recibe RTP y se lo entrega al reconocimiento. Una ventaja adicional de este esquema es que en esa misma capa se puede quitar el ruido antes de que el audio llegue al modelo.
Dónde falla exactamente el ucraniano en una llamada
El acento no es la dificultad principal. Los verdaderos puntos de fallo son otros, y son específicos del mercado ucraniano.
Cambio de idioma dentro de una misma frase. La persona empieza en ucraniano, mete una palabra en ruso y vuelve al ucraniano. El surzhyk, esa mezcla de los dos idiomas, es la norma en el habla cotidiana, no la excepción, y para el modelo es la clase más difícil: tiene que sostener dos sistemas fonéticos a la vez y decidir a cuál pertenece cada palabra.
Nombres propios. Nombres de ciudades, pueblos y distritos, apellidos, nombres de empresas y marcas. Aquí el modelo no cuenta con la pista del contexto de la oración y se equivoca justo en la palabra por la que se hizo la llamada.
Habla rápida y emocional, interrupciones, cortes. Quien llama con un problema no habla como un locutor: habla más rápido, se come las terminaciones e interrumpe al interlocutor a mitad de frase.
Las dos primeras clases no son una conjetura de la práctica, sino un hecho medido. Solo que medido en otros idiomas.
La lección sobre las cifras de los proveedores: versión, fecha, condiciones
Cuando Grow2.ai trabajaba en la arquitectura de un agente de voz para cualificar leads, la evaluación arrancó con una cifra alarmante: el reconocimiento del ucraniano de uno de los candidatos supuestamente daba un 13,5% de errores. Para un escenario en el que el agente debe escuchar bien el nombre de la ciudad, aquello parecía una sentencia, y estuvo a punto de descartar la opción antes de cualquier prueba. Es un episodio de nuestra evaluación interna, no una medición publicada: no nombramos al proveedor ni la fecha, porque aquí la cifra no es una prueba, sino una ilustración.
Cuando intentamos rastrear el origen de la cifra, se desmoronó. El dato correspondía a la generación anterior del modelo y se había medido con audio sucio de YouTube, un material de por sí más difícil que la media. Con la versión vigente, que para entonces ya había salido, no tenía relación alguna.
La conclusión de este episodio no trata de un proveedor en particular. Trata de que cualquier cifra sobre la precisión del reconocimiento sin tres coordenadas —versión del modelo, fecha de la medición, condiciones de grabación— no es información. Es una frase de marketing que sirve igual de fácil para vender algo que para descartar algo por error.
Las dos trampas, por cierto, esperan en la misma página del proveedor: la cifra para el ucraniano que allí aparece corresponde a la primera versión del modelo, y el titular sobre el primer lugar del mundo se apoya en un índice que no incluye ucraniano.
No necesitas precisión palabra por palabra
Buena parte de la inquietud en torno al WER desaparece con una observación sobre qué es exactamente lo que el agente tiene que escuchar.
El WER mide la proporción de palabras mal reconocidas en toda la transcripción. Pero un agente que cualifica leads no levanta un acta palabra por palabra. Tiene que extraer de la conversación unos pocos campos de los que depende a dónde irá el lead: por ejemplo, la ciudad del interlocutor y el motivo de la llamada. El resto de la conversación puede reconocerse con toda la imprecisión que se quiera: al enrutamiento no le afecta.
Así que la métrica relevante no es el WER, sino la precisión en los campos de decisión. Una transcripción con un 12% de errores en la que ninguno cayó sobre el nombre de la ciudad es mejor, para la tarea de cualificación, que una con un 6% de errores en la que la mitad arruinó justamente los topónimos. Un modelo que en general se ve más débil puede resultar más adecuado si maneja mejor los nombres propios.
De ahí se desprende también cómo reducir el riesgo. En lugar de perseguir el último punto porcentual de precisión general, se acota la tarea: un guion corto en el que el agente debe averiguar dos o tres cosas en 20-30 segundos; volver a preguntar cuando la confianza es baja; darle al modelo como pista una lista del vocabulario esperado (las ciudades que de verdad aparecen en tus llamadas). Esta última técnica la admiten los modelos directamente: en Scribe v2, por ejemplo, el keyterm prompting permite pasar palabras y frases a las que el modelo debe prestar especial atención: a octubre de 2026, hasta 1000 en modo por lotes y hasta 50 en tiempo real.
Un plan de prueba antes del lanzamiento, no después
Como no hay una cifra pública, hay que obtenerla por cuenta propia. A continuación, lo que Grow2.ai incluye en el plan de prueba previo al piloto. Es un plan, no un informe de un resultado medido: las cifras válidas solo aparecen con el audio de un proyecto concreto, y no hay otro lugar de donde sacarlas.
- Montar un conjunto de prueba propio. Grabaciones reales de llamadas de tu telefonía, no frases de estudio. Bastan unas decenas de conversaciones, pero necesariamente con la distribución que de verdad tienes: ciudades, surzhyk, ruido, cortes.
- Etiquetar la referencia a mano. Sin la respuesta correcta no hay con qué comparar. No se etiqueta todo el texto palabra por palabra, sino los campos de decisión: qué dijo realmente la persona sobre la ciudad y sobre el motivo de la llamada.
- Pasar a varios candidatos por el mismo conjunto. La comparación solo tiene sentido cuando las condiciones son iguales para todos, justo lo que les falta a las cifras públicas.
- Medir la precisión por campos, no el WER. Y aparte: la proporción de casos en que el modelo no estaba seguro y el agente debió volver a preguntar.
- Probar por separado el reconocimiento y la lógica del diálogo. De lo contrario no queda claro qué falló: si el agente no escuchó la ciudad o si la escuchó y decidió mal a dónde llevar el lead.
- Evaluar la reducción de ruido como una variante aparte. El mismo conjunto, procesado con y sin limpieza del audio antes del reconocimiento, muestra si esta capa justifica complicar la arquitectura.
Una prueba así cuesta unos días de trabajo y da una cifra que no está en ningún ranking, pero que habla justamente de tus llamadas. La lógica es la misma que en el checklist para lanzar un agente en dos semanas: la prueba con datos reales va antes de escalar, no después.
Qué medir después del lanzamiento
El piloto da el punto de partida; después hace falta una supervisión constante. Desde el primer día conviene llevar a la monitorización la precisión en los campos de decisión, es decir, la proporción de llamadas en las que la ciudad y el motivo de la llamada se determinaron bien, y junto a ella los errores de enrutamiento separados por causa: el lead fue a la etapa equivocada porque el agente no escuchó o porque decidió mal.
Aparte va la frecuencia con que el agente vuelve a preguntar, y no tiene una dirección deseable. Si pregunta de nuevo con demasiada frecuencia, la conversación se vuelve agotadora y la gente cuelga. Si no lo hace nunca, está adivinando. El rango normal hay que encontrarlo a tientas con tráfico real, y es distinto para cada escenario.
El cuarto indicador es la proporción de conversaciones que el agente consideró atípicas y derivó a un operador. No es señal de debilidad del sistema. Un agente que deriva a tiempo un caso difícil a una persona se comporta correctamente; el problema aparece cuando no deriva nada. Ese límite de competencia se define igual que el resto de los mecanismos de protección; sobre ellos hay más detalle en el análisis de los tres niveles de protección de un agente de IA.
Qué se desprende de esto para la decisión de implantar
La falta de una medición pública no es motivo para renunciar a un agente de voz en ucraniano. Es motivo para no comprar una solución guiándose por un ranking.
La elección del proveedor de reconocimiento deja de ser parte de la compra y pasa a ser parte del piloto. Eso cambia también el formato del acuerdo con el contratista: la prueba con tus grabaciones debe estar en el plan antes de fijar la arquitectura definitiva, no después de firmar el acta de entrega. El enfoque general sobre qué tareas conviene delegar en un agente en ventas está en la guía para directivos, y la aritmética de la comparación con el trabajo de un comercial, aparte.
Para el dueño del negocio, de esta sección se desprende una sola pregunta para el contratista: ¿qué hacéis con una frase que el modelo ha reconocido mal: la reescribís entera o le volvéis a preguntar a la persona? La respuesta «la reescribimos» significa que el agente va a corregir a ciegas los nombres de ciudades y los apellidos de tus clientes. Lo que sigue es la mecánica de esta capa para quienes la van a construir.
Para el equipo técnico: una capa de corrección sobre el reconocimiento
Sobre una única pasada de reconocimiento se puede poner un modelo de lenguaje que refina el resultado en varios pasos: clasifica la intervención del interlocutor como confirmación, información nueva o corrección, localiza el fragmento erróneo en la transcripción y edita solo ese fragmento, en lugar de reescribir toda la intervención. Ese es el diseño del trabajo Agentic ASR (arXiv:2605.29430, preprint enviado el 28 de mayo de 2026), y en él la mayor parte de los errores semánticos se elimina ya en el primer refinamiento, también en un benchmark con nombres propios, es decir, en la misma clase que hace fallar a la telefonía en ucraniano.
La mecánica de la corrección, la métrica S²ER, las tablas completas y los límites de este resultado los analizamos aparte: corrección de errores de reconocimiento de voz en tres pasos. Ahí mismo está qué parte de esas cifras se traslada al ucraniano y cuál no, y qué significa eso para el precio y los plazos del piloto.
Para la implantación, aquí importa más la mecánica que los porcentajes. La corrección funciona mediante el diálogo: el modelo aclara aquello de lo que no está seguro. En un agente de voz eso se traduce en una conducta simple: volver a preguntar, no adivinar. Un agente que vuelve a preguntar el nombre de la ciudad cuando la confianza del reconocimiento es baja hace lo mismo que el modelo corrector de este trabajo, solo que en vez de un segundo modelo usa al interlocutor.
El siguiente paso es hablar de un piloto del agente de voz: en una sola reunión definimos qué campos de decisión son críticos en tus llamadas y cómo montar la prueba con tus grabaciones. Escríbenos.
Y un detalle que suele notarse solo después del lanzamiento: el conjunto de prueba tiene que seguir vivo. Las llamadas cambian con las campañas publicitarias y con la temporada, y un conjunto montado una sola vez antes del piloto deja de describir, a los pocos meses, lo que realmente entra por la línea.
Fuentes:
- The Batch, Issue 367 — «Agents Come to Speech Recognition» (21 de agosto de 2026)
- Agentic ASR — arXiv:2605.29430
- Artificial Analysis — Speech to Text Leaderboard (AA-WER v2.0)
- ElevenLabs — Ukrainian Speech to Text
- Soniox — Ukrainian Speech to Text (la página de comparación con Google, que daba un 8,5% de WER, devuelve un 404 a 25 de agosto de 2026)
