Precisión de la transcripción con IA: por qué los benchmarks de los proveedores mienten y cómo probamos los modelos de verdad

Si estás intentando averiguar qué modelo de voz a texto es el más preciso, el número de benchmark publicado es el peor lugar donde mirar. La cifra de precisión que un proveedor destaca en su titular es un resultado optimizado sobre un conjunto de datos limpio y leído en voz alta: no te dice casi nada sobre cómo se comporta el modelo con el audio que de verdad tienes, una reseña de producto plagada de nombres de marca y jerga, una reunión en la que dos personas hablan a la vez, un acento marcado, un creador que no para de cambiar de idioma.

Dirijo Subanana, una herramienta de voz a texto con IA. Pasamos cada transcripción por una batería de modelos evaluados, y volvemos a probar esa batería constantemente. Este artículo trata de cómo probamos —la metodología, los criterios y los resultados reales de una de nuestras propias rondas de evaluación— y de por qué hemos dejado de fiarnos de las cifras de precisión que publican los proveedores para tomar esas decisiones.

Resumen

• Los benchmarks de precisión que publican los proveedores (un único valor de WER, una cifra de precisión deslumbrante en el titular) son sobre todo optimización de benchmark: se miden sobre audio limpio, guionizado y de un solo hablante que no se parece en nada a las grabaciones reales con mezcla de idiomas, acentos o varios hablantes.
• Por eso no elegimos los modelos por sus números publicados. Los probamos con nuestro propio audio real y desordenado y juzgamos el resultado como lo haría un editor humano: ¿corrigió las palabras mal oídas, se lee como lenguaje escrito limpio y —lo más importante— no cambió ningún dato?
• En una ronda de evaluación real, un modelo pequeño y rápido superó a nuestro modelo de producción por defecto, más pesado (alrededor de un 92 % de preferencia del juez, unas 13 veces más rápido). Más grande y más lento no significaba más preciso.
• El fallo que lo demuestra: un modelo reescribió en silencio el sensor de cámara "LYT-828" como "LYT-808": se lee impecable, es factualmente erróneo e invisible para una puntuación de WER.
• ¿Estás evaluando una herramienta tú mismo? Prueba tu peor audio real —los acentos, las voces solapadas, la jerga, los cambios de idioma—, observa las marcas de tiempo en pantalla y busca corrupción de datos, no el número del ranking.

¿Por qué engañan los benchmarks de transcripción de los proveedores?

Un porcentaje de precisión o una tasa de error de palabra (WER, por sus siglas en inglés) es un único número producido en las condiciones que el proveedor eligió. Tres cosas lo hacen casi inútil para elegir un modelo de producción:

• El conjunto de prueba está limpio. El audio de benchmark suele estar guionizado, ser de un solo hablante, grabado en una sala silenciosa y en un idioma con muchos recursos. El audio real no es nada de eso.
• La métrica es burda. El WER cuenta por igual sustituciones, inserciones y eliminaciones. Pero equivocarse en el número de un modelo (que un "Vivo X30" se convierta en un "Vivo X90") es un error catastrófico, mientras que una coma perdida es inofensiva. El WER los puntúa igual.
• Es el marcador del propio proveedor. Cada laboratorio reporta la configuración en la que su modelo luce mejor. Estás leyendo el mejor caso posible, no el resultado esperado.

Nada de eso es deshonesto, exactamente. Es simplemente optimización de benchmark: optimizar para el ranking en lugar de para tu caso de uso. Así que cuando evaluamos modelos, no citamos la cifra publicada de nadie. Ejecutamos el modelo sobre el audio real, desordenado y con mezcla de idiomas que nuestros usuarios suben de verdad, y juzgamos el resultado en función de lo que importa para un subtítulo o una transcripción terminados.

Esa es toda la filosofía: la precisión no es un número que un proveedor te entrega. Es algo que mides sobre tu propio caso de uso, o en realidad no la conoces.

Qué significa "precisión" de verdad para un subtítulo

Cuando la mayoría de la gente dice "precisión de transcripción", está mezclando dos trabajos completamente distintos:

1. Voz a texto (STT / ASR): convertir el audio en texto en bruto con marcas de tiempo. Aquí es donde vive el WER.
2. Limpieza del texto: convertir ese texto de ASR en bruto y desordenado en un subtítulo publicable: corregir palabras mal oídas, transformar el fraseo del lenguaje hablado en una forma escrita limpia, restaurar el espaciado y la puntuación, eliminar muletillas y, fundamentalmente, no cambiar ningún dato.

Ambas etapas pueden fallar, y fallan de formas distintas. Un modelo puede producir un texto en bruto excelente y aun así entregar subtítulos inservibles porque las marcas de tiempo se desfasan. Otro modelo puede tener marcas de tiempo perfectamente alineadas y aun así destrozar el nombre de una marca. Un único porcentaje de precisión no puede capturar nada de esto, y por eso exactamente probamos cada etapa por separado y de forma cualitativa.

El resto de este artículo recorre ambas: primero la etapa de limpieza del texto, donde tenemos una evaluación estructurada con números reales que podemos compartir, y después la etapa de STT en bruto, donde nuestras conclusiones son deliberadamente cualitativas.

Cómo probamos la etapa de limpieza del texto: un LLM como juez sobre audio real

Esta es la metodología de una ronda de evaluación real que hicimos en abril de 2026. El objetivo era el modelo que hace la pasada de limpieza sobre la salida del ASR en bruto, el paso que convierte una transcripción de máquina tosca en un subtítulo publicable. Esa pasada hace dos trabajos distintos, y probamos cada uno por separado:

• Corregir errores: arreglar las palabras y los números que la voz a texto se equivocó —un nombre de marca mal oído, un número de modelo erróneo, una negación perdida.
• Limpiar la redacción: convertir el fraseo hablado y coloquial en lenguaje escrito limpio, restaurar la puntuación y el espaciado, y recortar las muletillas, sin cambiar el significado. (En algunos idiomas esta distancia es amplia: el cantonés, por ejemplo, tiene una conversión propia de habla a escritura, 口語 → 書面語.)

(El alcance, dicho con claridad: esta ronda evalúa esa pasada de limpieza del texto, no la voz a texto en bruto. Las dos se prueban de forma diferente.)

• El conjunto de datos fue un grupo pequeño y deliberadamente seleccionado de muestras reales —en nuestro caso, cantonés de Hong Kong e inglés mezclados— elegidas no por su tamaño sino por los casos que rompen los modelos: escritura mixta, términos técnicos y números de modelo, pasajes cargados de puntuación, fragmentos cortos y frágiles, y tramos largos. El idioma concreto importa menos que el principio: un puñado de muestras genuinamente difíciles de tu propio caso de uso saca a la luz más fallos reales que mil muestras limpias.
• La comparación fue por parejas. Para cada muestra, la salida de cada modelo candidato se enfrentó cara a cara con nuestra línea base de producción actual, y un modelo juez aparte eligió la mejor —o declaró empate.
• Los criterios fueron seis cosas que de verdad definen un buen subtítulo, puntuadas de forma independiente por muestra:
  • Corrección de palabras mal oídas: ¿corrigió lo que la voz a texto se equivocó?
  • Limpieza de habla a escritura: ¿convirtió el habla coloquial en lenguaje escrito limpio? (En nuestras muestras de cantonés esto es la conversión 口語 → 書面語; cada idioma tiene su propia versión de pulir el habla hasta convertirla en prosa.)
  • Eliminación de muletillas: ¿quitó los "eh" y los arranques en falso?
  • Preservación de los datos: ¿dejó intactos los nombres, los números y los hechos?
  • Prohibición de anotaciones: ¿evitó inventar notas entre corchetes que el hablante nunca dijo?
  • Minuciosidad: ¿limpió de verdad el texto, o dejó errores evidentes dentro?

Metimos 31 configuraciones de modelo en esa ronda. Solo 17 eran siquiera ejecutables —el resto se cayó en la comprobación previa con identificadores de modelo no válidos, tiempos de espera agotados en las peticiones o ajustes no soportados, lo cual es en sí mismo un resultado útil: un modelo al que no puedes llamar de forma fiable no es candidato, sea cual sea su puntuación de benchmark.

Esto es metodología con rigor de documentación, no una impresión a ojo. Cada número de abajo sale de la propia salida de esa ronda, y lo compartimos porque es nuestro para compartir, no porque un proveedor nos haya dicho que su modelo es bueno.

Lo que encontramos: los números de nuestra propia ronda

Algunos resultados destacaron. Todas las cifras provienen de nuestra propia evaluación; son tasas de victoria por preferencia del juez y velocidad en la tarea de limpieza de subtítulos, no el porcentaje de precisión de STT de nadie.

Tres conclusiones de nuestros datos:

• La mejor preferencia media del juez en toda la ronda fue de alrededor del 92 %: una configuración ligera de Gemini 3.1 Flash Lite que el juez prefirió frente a nuestra línea base de producción en la gran mayoría de las muestras. Un modelo pequeño y rápido superó al modelo por defecto, más pesado.
• La configuración ejecutable más austera fue aproximadamente 13 veces más rápida que la línea base —unos 19 segundos frente a unos 4 minutos— a una fracción del coste, y aun así ganó el enfrentamiento directo en corrección de errores de forma rotunda. Más grande y más lento no era mejor.
• Limitar el "presupuesto de razonamiento" del modelo fue la mayor ganancia de eficiencia, con diferencia. La línea base gastaba la inmensa mayoría de su presupuesto en tokens de razonamiento que en gran parte no necesitaba. Desactivar ese presupuesto de razonamiento en el mismo modelo de la familia produjo una salida que el juez valoró igual de bien o mejor, aproximadamente un orden de magnitud más rápido y mucho más austera. Para una tarea acotada y bien especificada como la limpieza de subtítulos, el razonamiento extendido era sobre todo esfuerzo desperdiciado.

Te darás cuenta de que ninguno de esos es un "porcentaje de precisión". Son puntuaciones de preferencia relativa de un modelo juez, sobre nuestro audio, frente a nuestra propia línea base. Es una afirmación deliberadamente más humilde que "98 % de precisión", y es mucho más útil para elegir de verdad un modelo.

El fallo que demuestra por qué importan las pruebas con juicio humano y ancladas al caso de uso

Aquí está el ejemplo que captura todo el argumento. Un modelo candidato, al limpiar una reseña de un teléfono (uno de nuestros clips con cambio de código cantonés-inglés), hizo esto:

Origen:    T-828 的 sensor 啦。那這顆 LYT-828 呢，我們，我們又來……
Línea base: ……呢粒 LYT-828 呢……
Candidato:  ……嗰呢粒 LYT-808 呢……

El modelo reescribió en silencio el sensor de cámara "LYT-828" como "LYT-808". Vimos la misma clase de error en otro punto de la ronda, donde otro candidato convirtió un "Vivo X30 Pro" en un "Vivo X90 Pro".

El texto se lee a la perfección. La gramática está limpia, la puntuación está restaurada, el fraseo hablado está pulido hasta una forma escrita correcta. Una puntuación de WER apenas registraría el cambio —un dígito de un pasaje largo. Pero es una corrupción de datos: un producto distinto, un sensor distinto. Para quien reseña tecnología, ese es el tipo de error que provoca que exijan una corrección en los comentarios.

La lección no va de ningún idioma en concreto. Va de que los errores de transcripción más peligrosos son los fluidos: una frase que se lee limpia con un término técnico, un número de modelo o un nombre propio cambiado en silencio. Esos se esconden exactamente en el audio de escritura mixta y denso en jerga que graban los usuarios reales, en cualquier idioma. Ningún benchmark de precisión publicado lo habría detectado; solo salió a la luz porque juzgamos el resultado como lo haría un editor humano —frente a la pregunta concreta "¿cambió el modelo un dato?"— sobre el tipo de audio donde este fallo de verdad ocurre. Esa es la diferencia entre optimizar para el benchmark y probar anclado al caso de uso.

También muestra por qué la "preservación de los datos" es uno de nuestros seis criterios, y por qué la leemos como una señal comparativa en lugar de un recuento literal de errores. En la misma ronda, un modelo expresó "noventa por ciento" de dos formas igual de correctas (百分之九十 frente a 九成): semánticamente idénticas, sin error alguno. Una métrica ingenua habría marcado la reformulación y se habría perdido el cambio del sensor. El juicio, sobre el material adecuado, acierta con ese orden de prioridades.

¿Y qué pasa con la etapa de voz a texto en bruto?

Para la etapa de STT en sí —audio dentro, texto con marcas de tiempo fuera— nuestras conclusiones son intencionadamente cualitativas. No publicamos una tabla de WER, ni la nuestra ni la de nadie, porque los fallos que importan aquí no quedan bien capturados por una única tasa de error. Lo que rompe un modelo de STT en producción suele ser una de estas cosas: contenido alucinado que el hablante nunca dijo, habla válida que se pierde, rendimiento inestable en idiomas de menos recursos o con cambio de código, o marcas de tiempo que se desfasan respecto al audio.

Algunas cosas que hemos aprendido probando modelos sobre nuestro propio audio, en lugar de leer sus fichas técnicas:

• Un buen texto no significa buenas marcas de tiempo. Evaluamos un modelo multimodal de vanguardia como motor de transcripción: la calidad de su texto en bruto era genuinamente buena, pero las marcas de tiempo de sus líneas se desfasaban —bien para una transcripción de lectura, inservible para subtítulos que tienen que caer en el fotograma correcto.
• Algunos modelos producen una sincronización inservible de entrada. Otro modelo distinto que probamos para el mismo trabajo tenía, según nuestras notas, "marcas de tiempo basura" —fuerte sobre el papel, descartado para subtítulos alineados en el tiempo.
• Los idiomas de pocos recursos y con cambio de código son donde los modelos generales flaquean. Los idiomas más limpios y con muchos recursos en los que se apoya un benchmark son el caso fácil; el tambaleo aparece con los acentos, los dialectos y el audio que cambia de idioma dentro de una grabación. Subanana empezó usando un único modelo de STT muy conocido, y exactamente el tipo de fallo que los benchmarks esconden nos obligó a abandonar el enfoque de un solo proveedor: alucinaciones y habla perdida en condiciones reales, con los idiomas más difíciles —el cantonés entre ellos— como los menos estables. Por eso ahora enrutamos a través de varios motores evaluados y recurrimos automáticamente a otro cuando uno produce un segmento malo.
• La ingeniería de verdad vive en los huecos. Cuando incorporamos un nuevo proveedor de STT, el trabajo no era "¿es más bajo el WER?". Era: un tramo de música de fondo que se mapeaba mal sobre la sincronización del subtítulo equivocado, etiquetas sueltas de [música animada] que había que quitar, segmentos que se pegaban entre sí sin espacios. Nada de eso aparece en una puntuación de precisión; todo eso aparece para un usuario.

El resumen honesto es que elegimos el modelo de STT que mejor rinde por idioma de origen y por caso de uso, y seguimos volviendo a comprobarlo —porque un modelo que da buenos benchmarks puede aun así desfasarse en las marcas de tiempo o alucinar en los idiomas más difíciles, y la única forma de saberlo es ejecutarlo sobre lo real. Puedes leer más sobre cómo funciona ese enrutamiento y esa batería de calidad en nuestras páginas de herramienta de subtítulos con IA y transcripción de reuniones con IA.

¿Cómo deberías evaluar tú mismo la precisión de la transcripción?

No necesitas un banco de pruebas para esquivar la trampa de los benchmarks. El principio es sencillo: prueba con tu propio audio, juzga según lo que te importa a ti.

• Usa tu peor audio real, no un clip limpio. Elige el archivo con los acentos, las voces solapadas, la jerga, los cambios de idioma. Ahí es donde los modelos se separan.
• Comprueba las marcas de tiempo, no solo las palabras. Reproduce el vídeo con los subtítulos activados. Las líneas desfasadas son invisibles en un diff de texto y evidentes en pantalla.
• Busca específicamente la corrupción de datos. Repasa nombres, números y términos de producto o marca. Un subtítulo que se lee limpio con un número equivocado es peor que uno obviamente tosco.
• Juzga el resultado terminado, no la transcripción en bruto. Lo que entregas es el subtítulo corregido y formateado, así que evalúa eso, incluida la cantidad de limpieza manual que todavía necesita.
• Vuelve a probar con el tiempo. Los modelos cambian. El mejor para tu idioma este trimestre puede no serlo el siguiente. Volvemos a ejecutar nuestra evaluación precisamente porque la respuesta no para de moverse.

Si prefieres no pasar por ese proceso tú mismo, ese es el trabajo que hacemos de forma continua: evaluamos los modelos, enrutamos al que mejor rinde por idioma y caso de uso, y añadimos por encima detección de alucinaciones y corrección para que el resultado que revisas ya sea el más fuerte que el sistema puede producir. Puedes probarlo con tu propio audio más difícil:

y comprueba las cosas de arriba.

Preguntas frecuentes

¿Es un porcentaje de precisión publicado más alto una forma fiable de elegir una herramienta de transcripción?

No. Las cifras publicadas son resultados optimizados sobre audio limpio, a menudo de un solo hablante y en idiomas con muchos recursos. Rara vez predicen el rendimiento sobre audio real con acentos, voces solapadas, términos técnicos o cambios de idioma. Pruébalas, en cambio, con tus propios archivos.

¿Cuál es la diferencia entre la precisión de transcripción y la calidad del subtítulo?

La precisión de transcripción suele referirse a la voz a texto en bruto: palabras y marcas de tiempo. La calidad del subtítulo es el resultado terminado tras la limpieza: palabras mal oídas corregidas, fraseo hablado convertido en forma escrita limpia, puntuación y espaciado restaurados, muletillas eliminadas y datos intactos. Una herramienta puede hacer bien una cosa y mal la otra.

¿Por qué evaluáis los modelos con otro modelo como juez?

Para la etapa de limpieza del texto, un LLM juez nos permite comparar dos salidas por parejas con criterios consistentes, mucho más rápido que la revisión manual, y volver a ejecutarlo de forma barata cada vez que sale un modelo nuevo. Tratamos sus veredictos como una señal de preferencia relativa frente a nuestra propia línea base —no como una puntuación de precisión absoluta— sobre una muestra deliberadamente difícil y seleccionada, y mantenemos a personas en el circuito para los casos de fallo que importan, como la corrupción de datos.

¿Un modelo con buen texto de transcripción siempre produce buenos subtítulos?

No, y esta es una trampa habitual. Hemos visto modelos con un texto en bruto genuinamente bueno producir marcas de tiempo desfasadas o inservibles. Para los subtítulos, que tienen que alinearse con el fotograma, la fiabilidad de la sincronización importa tanto como la precisión de las palabras, y las dos no están correlacionadas.

¿Por qué Subanana usa varios modelos de voz a texto en lugar de uno?

Porque ningún modelo único es el mejor en todos los idiomas y casos de uso, y cualquier modelo puede alucinar o perder habla sobre audio real. Subanana empezó con un solo proveedor y pasó a un enfoque multimodelo después de que los datos de producción mostraran los límites de un único motor —especialmente en idiomas de pocos recursos y con cambio de código. Enrutamos al modelo mejor evaluado por idioma de origen y recurrimos automáticamente a otro cuando la calidad de la salida cae.