Corregir el habla en su origen

VoxRange ejecuta agentes de IA que contestan llamadas telefónicas reales en urdu y en la mezcla de urdu e inglés, con cambios de código, que la gente habla de verdad. Soy el arquitecto principal. Este artículo trata de un error que cometimos en la parte de escucha de ese pipeline y de la regla que saqué de él.

El síntoma

La conversión de voz a texto en las llamadas en urdu seguía produciendo fragmentos sueltos en alfabeto latino en mitad de las transcripciones en urdu. El audio telefónico de banda estrecha, la mezcla de idiomas y los nombres ya dificultan la transcripción, y estos fragmentos lo empeoraban: lo que dice la transcripción es a lo que responde el agente.

La solución obvia era limpiar la salida. Si un agente está configurado para urdu y un fragmento vuelve en alfabeto latino, se descarta antes de que el agente lo vea.

Por qué el filtro era un error

El filtro funcionó, en el sentido de que la basura desapareció. También desapareció habla real.

Quienes llaman no se quedan dentro de un solo alfabeto. Mucho urdu se escribe con letras latinas como urdu romanizado, y muchas conversaciones cotidianas pasan al inglés para una palabra o una frase entera. Un ejemplo inventado: "mera appointment confirm kar dein" es una petición corriente, y cada palabra es habla real escrita con letras latinas. Una regla que elimina texto en alfabeto latino no puede distinguir esa frase del ruido, porque cuando se ejecuta lo único que queda por juzgar es el alfabeto, y el alfabeto no es el problema.

Revertimos el filtro. Se mantuvo uno más limitado: los alfabetos que no pueden ser habla real plausible en estas llamadas, como los caracteres cirílicos o CJK, se siguen descartando, porque eliminarlos no cuesta nada real.

De dónde viene realmente la basura

Los fragmentos sueltos eran un síntoma de que la etapa de escucha funcionaba mal, así que ahí es donde corresponde la solución:

• Detección del final del habla. La detección de actividad de voz decide cuándo ha dejado de hablar quien llama. Si lo decide demasiado pronto, un turno se corta en fragmentos, y un fragmento de palabra es exactamente el tipo de audio que un modelo de voz convierte en un disparate dicho con total seguridad.
• Anclaje del idioma. Decirle al modelo qué idioma esperar, en lugar de dejar que lo adivine en cada clip corto, evita que se desvíe a otro idioma ante una ráfaga de ruido.
• Vocabulario. Los nombres, lugares y términos del dominio que el modelo nunca ha visto vuelven como conjeturas aproximadas. Darle el vocabulario que va a oír es más barato que reparar las conjeturas.

Cada uno de estos cambios modifica lo que el modelo oye o espera. Ninguno descarta nada de lo que dijo quien llama.

La lección relacionada: la deriva de la configuración

La detección del final del habla depende de un valor: cuánto silencio esperar antes de decidir que quien llama ha terminado. Lo habíamos ajustado tras problemas anteriores en llamadas. En una llamada posterior había vuelto a un valor agresivo, y el agente cortaba a quienes llamaban a mitad de frase. Los turnos fragmentados que habían producido malas transcripciones desde el principio también habían vuelto.

El valor solo existía en el entorno de un servidor. Nada en el código ni en su historial guardaba el valor ajustado, así que nada impedía que cambiara. Un valor de ajuste como este debe estar en una configuración versionada, junto al código que lo lee, con una nota sobre por qué tiene ese valor:

# voice-runtime config, versioned with the code
# How long to wait in silence before ending the caller's turn.
# Too short cuts callers off and fragments transcripts.
END_OF_SPEECH_SILENCE_MS: <tuned value>

La misma llamada enseñó una segunda cosa. El silencio muerto en un turno es la suma de varias etapas: la espera del final del habla, la transcripción, la recuperación, el LLM y la síntesis de voz. Algunas estaban cronometradas y una no. No se puede decidir qué optimizar hasta medir cada etapa de un turno, porque la etapa que no mides es aquella sobre la que acabarás haciendo conjeturas.

Lo que le diría a alguien que construya lo mismo

1. Cuando un modelo produzca basura, encuentra la etapa que la causó antes de escribir una regla para eliminarla. Los filtros de salida no pueden ver las causas.
2. Prueba cualquier regla de limpieza con habla real y desordenada, incluidos los cambios de código, antes de confiar en ella.
3. Guarda los valores de ajuste en una configuración versionada con una razón adjunta, no solo en el entorno de un servidor.
4. Mide cada etapa de un turno antes de optimizar cualquiera de ellas.