Una voz sintetizada leyó una novela en 1 h 58 min; lo que fallaba era la capa de procesamiento que rodea al modelo

Una voz sintetizada leyó una novela completa: 16 capítulos, 15 444 palabras y 1 h 58 min de audio. Según el autor de la serie de artículos en Habr, la voz se mantuvo estable durante las dos horas. Casi todas las averías estaban no en el modelo en sí, sino en el código que lo rodea. El set de verificación de 14 frases, con el que se comparaban las versiones del modelo, no detectó ninguna de ellas.

El texto elegido para el experimento fue la novela «Merdiven» («La escalera») de Shamil Alyadin. Es el tercer artículo de la serie: el primero incluía una tabla con los resultados de la lectura del libro y, en el segundo, el autor prometió analizar por separado qué se rompía en distancias largas. No revela los nombres de los modelos, las fuentes de datos, los scripts internos ni los parámetros de entrenamiento y decodificación. En el texto quedan las métricas, la metodología de verificación y los errores en los que tropezó.

Dónde se rompía realmente

El autor enumera cinco zonas problemáticas. Todas pertenecen a la capa de procesamiento que rodea al modelo, es decir, a lo que ocurre antes y después de generar el audio:

• división del texto en oraciones;
• pegado de frases cortas;
• recorte de respiraciones;
• extracción del texto del archivo del libro;
• marcado temporal.

Para los ingenieros que han trabajado con TTS, la lista resulta familiar. El modelo recibe un fragmento de texto limpio y devuelve un fragmento de audio limpio. Si el texto se corta por donde no corresponde, si una réplica corta («— No.») se pega al vecino equivocado o si una respiración se recorta a media sílaba, el oyente notará el defecto aunque las métricas del propio modelo no hayan cambiado. Un error en la extracción del texto del archivo del libro ocurre incluso antes de la síntesis: el modelo leerá fielmente lo que se le entregue.

Por qué las 14 frases no detectaron nada

La segunda conclusión del autor es, quizá, más interesante que la primera. El set de 14 frases de verificación servía para comparar versiones del modelo y, al parecer, cumplía bien esa función. Pero no veía los problemas de la distancia larga. Es lógico: una frase aislada no contiene uniones entre oraciones, no exige dividir un capítulo y no comprueba cómo se acumula el marcado temporal a lo largo de dos horas de audio.

Hay además un caso más inquietante. En un episodio, el set no logró distinguir una buena corrección de una perjudicial. Para un equipo que toma decisiones a partir de este tipo de pruebas, es una señal de alarma: una métrica que no distingue entre mejora y empeoramiento se convierte en ruido.

Las cifras ayudan a calibrar la escala. 15 444 palabras en 118 minutos dan unas 131 palabras por minuto, y cada capítulo tiene de media unas 965 palabras y 7 minutos de audio. A esa distancia hay muchas más uniones entre fragmentos que en cualquier set corto, y cada unión es un posible punto de fallo.

Qué comprobar en tu propio pipeline

Del material se desprenden conclusiones prácticas que no dependen de ningún modelo concreto.

• Mantén junto al set corto al menos una ejecución larga: un capítulo o un libro entero. El set corto sirve para comparar versiones del modelo, pero no para validar todo el pipeline.
• Prueba la capa de procesamiento por separado del modelo: segmentación, pegado, recorte de pausas, extracción de texto y marcado temporal. Cada eslabón necesita sus propias comprobaciones.
• Empieza el análisis de defectos por el texto que llega a la síntesis. Si el error está ahí, culpar al modelo no tiene sentido.
• Verifica la propia prueba: si no distingue una corrección útil de una perjudicial, es pronto para tomar decisiones con sus resultados.

El autor promete detallar la metodología de verificación en el propio artículo, y probablemente ese sea el mayor valor del material. Por ahora, el anuncio deja una idea sencilla: cuando la voz suena estable durante dos horas seguidas, la calidad del pipeline depende de lo bien rematadas que estén las costuras.