Voz en tiempo real vs. batch — un agente de IA telefónico no es un chatbot

Cuando un proveedor te presenta un «agente de IA telefónico», hazle una pregunta: «¿Cuál es tu latencia de extremo a extremo entre el final del habla del usuario y el inicio de la respuesta?»

Si la respuesta supera los 1,5 segundos, no es un agente telefónico. Es un chatbot con un módulo de ASR / TTS pegado al frente.

La regla de los 800 ms

Una persona al teléfono tolera el silencio tras su pregunta. Pero ese silencio tiene un umbral: más allá de 800 ms, el otro extremo se siente «congelado». A 1500 ms, quien llama dice «¿oiga?». A 3000 ms, cuelga suponiendo un problema de línea.

El objetivo para un agente de voz serio es por tanto: por debajo de 800 ms entre el final del habla y el primer byte audible de la respuesta.

Desglosémoslo.

El presupuesto de tiempo en detalle

[user speech]──▶[ASR streaming]──▶[LLM]──▶[TTS streaming]──▶[audio out]
      ~150ms          ~80ms        ~?       ~250ms             ~50ms

De los ~800 ms disponibles, aproximadamente 270 ms los consumen ASR + TTS + transporte. Eso deja 530 ms para el LLM — incluyendo el tiempo de prefill, el razonamiento y la generación del primer token.

Implicaciones:

• GPT-4 Turbo sin streaming: ~2000 ms para generar una respuesta de 200 tokens. Descartado.
• GPT-4o streaming: ~400 ms hasta el primer token en días buenos, ~800 ms en los malos. Aceptable pero justo.
• Claude Haiku streaming: ~250 ms hasta el primer token. Cómodo.
• Llama 3 8B servido por vLLM: ~150 ms hasta el primer token. Excelente (y privado).

Una arquitectura de voz seria requiere por tanto:

1. Todo es streaming — ASR, LLM, TTS. Ni un solo eslabón en modo batch.
2. El modelo de LLM se selecciona por TTFT (time to first token), no por su puntuación en MMLU.
3. El TTS empieza a hablar con el primer token recibido, no tras completarse la respuesta entera.

Barge-in

En un canal de texto, el usuario espera a que el bot termine. Por teléfono, interrumpe. Tres de cada cinco veces, en conversaciones naturales.

Un agente de voz que no sabe gestionar que lo corten se siente «robótico» — sigue hablando mientras el usuario intenta interrumpir. Es intolerable, y delata de inmediato un bot mal construido.

El barge-in técnico requiere:

• El TTS se detiene de inmediato cuando el ASR detecta señal vocal saliente del usuario.
• El LLM descarta la respuesta en curso (sin protestar).
• El buffer de audio saliente se vacía al instante (de lo contrario se oye una media sílaba residual).
• El historial de conversación anota que la respuesta no se oyó por completo — para evitar repetirla sin querer.

Es un detalle técnico que lo cambia todo en cómo se siente la interacción.

Gestionar la incertidumbre

Por teléfono, el ASR se equivoca con regularidad. Donde un chatbot de texto siempre recibe el texto exacto tecleado por el usuario, el agente de voz recibe una transcripción a menudo imperfecta.

Estrategias que funcionan:

• Pedir confirmación en los elementos de alta consecuencia (número de expediente, importe, apellido inusual). No de forma sistemática — eso se vuelve insoportable.
• No confiar a ciegas en el LLM cuando el ASR es ambiguo. Si la frase recibida es «quiero cancelar mi contrato» con una puntuación de confianza baja, es mejor preguntar «¿Quiso decir cancelar su contrato?» que activar el procedimiento de cancelación.
• Cortar las divagaciones — un agente que se desvía del guion debe ser reconducido por un nodo de condición / operador, no por un prompt que «debería bastar».

El teléfono también es una pila tecnológica

Más allá de la IA, un agente telefónico requiere:

• Un SIP trunk de un operador (Twilio, Voxbone, OVH, Sewan…).
• Un media gateway (LiveKit-SIP, FreeSWITCH, Asterisk) que hable SIP del lado del operador y WebRTC del lado de la plataforma.
• Un transcriptor robusto frente al ruido, los acentos y las voces superpuestas.
• Un sintetizador que pronuncie correctamente nombres propios, números y fechas.

Ninguno de estos elementos es trivial. Todos interactúan entre sí.

Lo que betool gestiona

La arquitectura de voz de betool — LiveKit + LiveKit-SIP + worker dedicado + streaming de LLM en cascada — cubre los requisitos anteriores de fábrica. Tú mantienes el control de:

• El SIP trunk (tu operador, tus números).
• Los modelos (BYOK o modelos privados).
• Los parámetros (latencia objetivo, agresividad del barge-in, fallback a voz humana).

Tú no configuras la fontanería en tiempo real — ese es el trabajo de la plataforma. Tú diseñas la conversación, que es el verdadero reto de negocio.