Por qué un solo motor no basta: más motores solo ayudan si fallan de forma distinta

Hicimos una comparación con una entrevista de negocios de 42 minutos. Una transcripción salió directamente de ElevenLabs. La otra pasó por todo nuestro proceso. Las dos coincidían en un 91%.

El 9% restante era justo la parte que más les importa a los investigadores.

Lo peligroso es el «casi todo bien»

Seleccionamos 19 términos clave de la entrevista: marcas, números de modelo, topónimos, jerga del sector. En la transcripción sacada directamente del motor, 10 estaban mal, 4 estaban parcialmente mal y 5 estaban bien. Una marca apareció seis veces y ni una sola vez se escribió correctamente. Cada vez se convirtió en una palabra corriente que sonaba parecido y significaba algo completamente distinto.

Para ser justos con ElevenLabs, ese día lo hizo bien. Nada se vino abajo, no se perdió nada y acertó con los hablantes alrededor del 98% del tiempo. Juzgado en conjunto, costaría encontrarle un fallo.

Ese es el problema. Quien lee una frase fluida no tiene motivos para dudar del sustantivo que hay en medio. Y los otros tres motores que teníamos a mano también se equivocaron en esos mismos términos. Así que la cuestión no es que un motor sea malo. Es que cualquier motor por sí solo oirá mal los términos del sector que no ha encontrado antes.

Nuestra propia «optimización» no hacía más que barajar las cartas

Antes de enviar el audio a un motor, lo dividimos en secciones y normalizamos el formato. Suponíamos que esto mejoraría la precisión.

Arregló 22 cosas y estropeó 25. Más o menos como lanzar una moneda.

Al final entendimos por qué. Este motor es muy sensible al punto del audio en el que empieza a escuchar. El mismo número de modelo salía como «X6» cuando la sección empezaba en el segundo cero, y deletreado como «X-six» cuando empezaba en 1:30. Ni siquiera la transcripción sin procesar era coherente: «X-six» durante los primeros 32 minutos y «X6» a partir de ahí.

Llegar hasta ahí nos costó tres experimentos controlados, cada uno de los cuales descartaba una explicación obvia: no era la duración del archivo, no era el formato de audio y no era la configuración de idioma. Si nos hubiéramos quedado con la primera respuesta plausible, habríamos escrito la causa equivocada en nuestra propia documentación.

Lo que de verdad mejoró la transcripción fue que los motores se revisaran entre sí

Otros tres motores transcriben el mismo audio, y los comparamos todos juntos, con un glosario de términos. De las 25 cosas que había estropeado nuestra división, se recuperaron 14, es decir, un 56%.

El número de modelo se resolvió del mismo modo. Otro motor escribió «X6» todas y cada una de las veces, así que cada vez que el motor principal fallaba, la transcripción final seguía teniendo la forma correcta a la que recurrir.

Cuando los motores no logran resolverlo, no decidimos por el lector. Marcamos el punto como dudoso para que alguien pueda escuchar ese segundo. Esta entrevista tuvo 7 marcas.

Más motores no es automáticamente mejor

Es tentador concluir que más motores significa mejores resultados. Lo probamos. No es así.

Probamos ocho motores chinos de código abierto ejecutados en local y los dejamos votar. El resultado fue peor que el mejor motor individual por sí solo. La mayoría de los ocho procedían de la misma empresa y se habían entrenado con datos muy solapados, así que tendían a fallar en las mismas palabras. La votación no corrigió esos errores. Los consolidó.

Pasar a cuatro motores basados en cuatro enfoques técnicos distintos lo cambió. Entre dos cualesquiera de ellos, solo entre el 32.6% y el 45.8% de los errores caían en el mismo sitio, y juntos superaban claramente a cualquiera de ellos por separado.

Por eso, cuando elegimos motores de apoyo para un idioma, no solo preguntamos qué precisión tiene cada uno. Preguntamos si falla en lugares distintos que el motor principal. El coreano es un ejemplo. Un motor parecía estar bien por sí solo, pero sus peores errores eran casi idénticos a los de los otros dos: los tres se equivocaban en las mismas palabras y de la misma manera. Lo sustituimos por Soniox, cuyos errores se solapaban menos.

Otra cosa nos hizo ser prudentes. Cuando AssemblyAI lanzó una nueva versión, su tasa de error publicada para audio con mezcla de idiomas bajó del 9.07% de la generación anterior al 7.69%. La comprobamos palabra por palabra en seis de nuestros idiomas. Todos salieron peor o sin mejora: la nueva versión añadía palabras que nadie había dicho. A una frase en inglés se le añadió un "Bruh". Unas "50,000 lire" en italiano se convirtieron en "50 million". Según la tasa de error, casi los seis parecían mejoras, porque una palabra de más apenas mueve esa métrica. La documentación oficial lo explicaba: la nueva versión usa un decodificador al estilo de los grandes modelos de lenguaje. Volvimos a una versión anterior.

La tabla de resultados de un proveedor mide las condiciones que elige el proveedor. No es tu entrevista.

Dónde seguimos perdiendo

Después de defender el uso de varios motores, esto es lo que hicimos mal.

La transcripción final todavía tenía 10 errores, todos en palabras cotidianas. En uno, el entrevistado dijo «mi mujer» y la transcripción decía «mi hermana».

Con la misma entrada tres veces, nuestro paso de comparación recuperó 0, 3 y 3 errores. Ese paso también tiene aleatoriedad.

Probamos a cambiar las reglas de comparación e hicimos una prueba A/B. No sirvió, así que lo revertimos. Indagando más, el problema no estaba en las reglas, sino un paso antes, en la alineación. La palabra correcta estaba en algunas de las transcripciones de apoyo, pero como los límites de las secciones no coincidían, nunca llegó a la comparación. Si la respuesta correcta no está en la entrada, ninguna regla puede elegirla.

Todavía no lo hemos resuelto del todo. Lo incluimos porque es la misma lección que todo lo anterior: varios motores solo valen tanto como las pruebas que de verdad puedes aportar.