Cascada T-one + GigaAM: borrador de subtítulos durante la reunión, versión final después

El autor de un servicio de reuniones uno a uno comprobó si se puede dejar la nube de Deepgram por un servidor propio sin tarjeta gráfica y, aun así, obtener subtítulos en directo y un texto final de calidad. Montó una cascada de dos modelos. Durante la llamada, T-one convierte el habla en un borrador con menos de 2 segundos de retraso.

Después de la reunión, GigaAM revisa el borrador, corrige los errores y entrega la versión final con puntuación. El esquema funcionó y las mediciones llevaron tres días. Pero dos resultados sorprendieron al autor más que los propios modelos: la referencia de calidad fallaba en uno de cada cuatro puntos dudosos, y la técnica popular de «un segundo modelo corrige los términos» apenas aportó nada en sus llamadas.

De dónde salió la idea de la cascada

En la primera parte, el autor comprobó que el número de vCPU dice poco sobre el rendimiento. Un Xeon de 2013 sin AVX2 sostiene entre 6 y 8 veces menos pistas en vivo que un procesador actual con un número similar de núcleos. Su máquina B (6 vCPU Xeon E5-2680 v2, 11 GB de RAM) aguanta dos reuniones simultáneas: T-one entrega la frase 1,08 s (p50) y 1,2 s (p95) después de la pausa.

T-one tiene puntos débiles. No pone puntuación y, en precisión de palabras, queda por detrás tanto de la nube como de GigaAM. GigaAM, por su parte, solo trabaja sobre una grabación ya terminada. La cascada cubre ambas carencias. La impulsó @pahaz, que ese mismo día publicó un artículo sobre una cascada GigaAM + Parakeet para transcripción offline y le aconsejó añadir Parakeet a la comparación.

Los requisitos siguen siendo los mismos: las pistas de los participantes llegan por separado, así que no hace falta diarización; la frase debe aparecer en los subtítulos como máximo a los 2 s (p95); y el audio no sale del servidor en Rusia. Se añadió uno nuevo: un texto final con puntuación, no peor que el de la nube, donde lo más importante son las cifras, los plazos y los nombres.

La referencia que favorecía a los modelos

En la primera parte, la referencia era Deepgram, y el propio autor lo consideraba un punto débil. Ahora amplió la muestra y revisó la referencia a mano. Resultó que, en uno de cada cuatro puntos dudosos, la referencia anterior se equivocaba y favorecía a los modelos con los que se había construido. Esto significa que el WER medido contra esa referencia sobrestima la calidad de los sistemas «de casa».

El segundo hallazgo se refiere a la corrección de términos. En el caso de @pahaz, el segundo modelo que corregía los términos redujo el WER en 5 p. p. En las llamadas de trabajo del autor, en el mejor de los casos no cambió nada y en el peor añadió 7 p. p. La ganancia de la cascada depende mucho del dominio y de la calidad de la grabación.

Qué se midió exactamente

Datos de prueba:

• 51 segundos de un call center del paquete de T-one • Una sesión de coaching de 29 minutos • 4 grabaciones de llamadas de trabajo: 2 h 21 min, 14 970 palabras

Referencias: el acuerdo entre motores en una muestra, el texto de Deepgram nova-3 en la sesión, y un texto consensuado de tres sistemas con corrección manual de términos y escucha por muestreo.

En la primera parte se compararon T-one, GigaAM-v3, Vosk, Deepgram nova-2 y nova-3. En la segunda:

• T-one en modo greedy y con el modelo de lenguaje KenLM • GigaAM-v3 e2e • Parakeet TDT 0.6B v3 • Deepgram nova-3

Métricas: WER, WERx, errores en números, precisión de términos y de puntuación. Por separado, el autor analizó qué carga la CPU en tiempo real, cómo repartir el trabajo entre los dos modelos y cuánto cuesta.

Conclusión práctica

Quien monte su propia transcripción debería empezar por la referencia, no por los modelos. Si la referencia se construye con la salida de los mismos sistemas que se comparan, las cifras saldrán optimistas. Hace falta una revisión manual, al menos de los puntos dudosos, y escuchar el audio, sobre todo donde aparecen importes, fechas y nombres.

La segunda conclusión se refiere a las cascadas. La ganancia de 5 p. p. que otro obtuvo con un modelo corrector no se traslada automáticamente a tus conversaciones: hay que comprobarlo con tus propias grabaciones. Repartir los papeles entre dos modelos está justificado por la propia lógica del problema: uno rápido y tosco para los subtítulos en directo, otro lento y preciso para el documento posterior a la reunión. Para un servicio pequeño, esto significa que dos llamadas simultáneas en un viejo Xeon de seis núcleos son perfectamente factibles, siempre que la parte en vivo recaiga en un modelo ligero y el trabajo pesado se aplace hasta después de la reunión.