Segundo y medio para responder: así funciona un agente de voz en tiempo real

Si el reconocimiento de voz, el modelo de lenguaje y la síntesis de voz se ejecutan uno tras otro, cada uno esperando al anterior, quien llama aguarda entre tres y cinco segundos por cada respuesta. Por teléfono, eso es inasumible. En los últimos meses hemos montado varios agentes telefónicos con IA, y en todos surgieron las mismas tres preguntas: cuánto pasa desde la última palabra de quien llama hasta la respuesta, qué ocurre si interrumpe y cómo se defiende el sistema con el húngaro. Esta es la arquitectura a la que llegamos, con sus trampas.

Todo en streaming

La configuración clásica tiene tres escalones: reconocimiento de voz (STT), modelo de lenguaje (LLM) y síntesis de voz (TTS). Para evitar la espera de tres a cinco segundos, los tres funcionan en modo streaming:

• el STT entrega transcripciones parciales (partial) a medida que llega el audio, sin esperar al final de la frase;
• el LLM emite token a token, y en el primer signo de puntuación que cierra una frase ya pasamos el texto;
• el TTS sintetiza por fragmentos, y el primer chunk de audio sale cuando el modelo todavía genera la continuación.

El conjunto es una tubería asíncrona en la que cada tramo tiene su propia cola y su propia señal de cancelación. En Node.js sale de forma natural: streams, iteradores asíncronos, AbortController.

Cuándo termina el silencio

La mayor parte de la latencia no viene de los modelos. Viene de una decisión: ¿cuándo ha terminado de hablar quien llama? Un umbral de silencio fijo, por ejemplo de 700 ms, es sencillo y falla de dos maneras. Con una pausa corta interrumpe al interlocutor; con un umbral largo, el sistema parece lento.

Combinamos tres señales: VAD (voice activity detection) sobre el audio en bruto, la propia señal de end-of-speech del STT y una heurística lingüística sencilla que estima, a partir de la transcripción parcial, si la frase está sintácticamente cerrada. En húngaro es más difícil que en inglés porque el orden de las palabras es más libre, aunque las partículas interrogativas y los sufijos ayudan mucho. Una máquina de estados pondera las tres señales y el umbral se adapta: si quien llama habla despacio y con pausas, el sistema se vuelve más paciente.

El presupuesto, en milisegundos

Lo que percibe quien llama es el tiempo entre su última sílaba y el primer sonido que oye de vuelta. Lo repartimos más o menos así, con órdenes de magnitud orientativos:

• decisión de endpointing: 200-400 ms
• cierre del STT: 100-300 ms
• primer token del LLM: 300-600 ms
• primer chunk de audio del TTS: 150-300 ms
• red y jitter buffer: 100-200 ms

En total, entre uno y uno y medio segundos, lo que ya suena natural. Medimos cada tramo por separado, con spans, por llamada. Con la suma final no sabríamos dónde se ha estropeado. Un truco que funciona es la reacción de relleno: si el primer token del LLM se retrasa, puede salir antes una confirmación breve y adaptada al contexto (“De acuerdo, lo compruebo.”). Gana tiempo y evita que el interlocutor se quede ante una línea muda.

Cuatro frecuencias de muestreo

La parte telefónica es la menos vistosa y la que más trabajo da. Desde la PSTN llega RTP por un trunk SIP, normalmente G.711 (8 kHz, alaw/ulaw) o, con suerte, Opus. Desde el navegador llega WebRTC, Opus a 48 kHz. Los modelos de STT esperan casi siempre PCM a 16 kHz, y el TTS suele entregar 24 kHz. En la capa de medios hay, por tanto, resampling en todas las direcciones. Debe resolverse en un único sitio, con un contrato de formato inequívoco; si no, el audio sale chillón o a media velocidad.

Los paquetes RTP llegan de forma irregular, así que en el lado entrante trabaja un jitter buffer adaptativo, en un rango de 20-60 ms. En el lado saliente hace falta pacing: el TTS produce audio más rápido de lo que la línea lo transporta, así que lo enviamos en tramas de 20 ms, a ritmo de reloj. Sin eso, el jitter buffer del otro extremo descarta los paquetes.

Cuando el interlocutor interrumpe

La interrupción se llama barge-in. En ese momento se detiene de inmediato la reproducción del TTS, se vacía el búfer de salida, se cancela la generación del LLM y la nueva entrada se trata como un turno nuevo. Lo difícil es la respuesta cortada: en el historial de la conversación guardamos lo que de verdad se dijo, no el texto completo que generó el modelo.

Cada llamada externa tiene su timeout. Si el proveedor de STT no responde a tiempo, pasamos a uno secundario; en el LLM caemos a un modelo más pequeño. Los reintentos solo se permiten en pasos idempotentes: un TTS reproducido a medias no se repite. Si todo falla, el agente pide disculpas con un audio pregrabado y promete devolver la llamada. Es peor que el funcionamiento normal y mucho mejor que el silencio.

Fechas con sufijos

El húngaro es una lengua aglutinante, así que los modelos de STT dudan más que en inglés ante las formas de palabra poco frecuentes. Lo que hemos visto:

• el reconocimiento de nombres propios y términos técnicos (calles, códigos de producto) mejora si el STT recibe un glosario o un prompt hint;
• los números, las fechas y las horas no pueden llegar en bruto al TTS: en lugar de “2024. 12. 10.” pasamos “kétezer-huszonnégy december tizedike”, con la declinación incluida (“tizedikén”, “háromkor”);
• los números de teléfono y los identificadores se leen agrupados, con pausas, y luego se confirman preguntando;
• las voces de TTS en húngaro varían mucho en entonación, así que comparamos varios proveedores con el mismo conjunto de frases.

La lección principal: un agente de voz es un sistema de medios en tiempo real, y el LLM es solo uno de sus tramos. La latencia, la capacidad de interrupción y la normalización lingüística exigen al menos tanto trabajo de ingeniería como el prompt.