El sistema de voz de Retell funciona como una cadena en vivo con tres pasos clave. Y cada uno depende del paso anterior.
ASR → LLM → TTS
ASR (reconocimiento automático del habla) escucha a quien llama y convierte su habla en texto.
LLM (modelo de lenguaje) lee ese texto, entiende lo que se dijo y decide qué responder.
TTS (texto a voz) toma esa respuesta y la convierte en audio hablado que quien llama escucha.
Así que el flujo es básicamente: quien llama habla → ASR lo transcribe → LLM genera una respuesta → TTS la reproduce en voz alta.
Cuando alguien está en una llamada, tanto el sistema de ASR como el de LLM son los sistemas críticos que trabajan en tiempo real. Y ambos pueden fallar, ralentizarse o comportarse de forma impredecible. Necesitamos poder confiar en que ambos sistemas funcionan, así que hemos creado una configuración que monitoriza, respalda y conmuta constantemente en tiempo real. Y así es como los dos trabajan juntos y por qué estas actualizaciones importan:
Primero, vigilamos el retraso (no el fallo)
Nos hacemos constantemente una pregunta sencilla: «¿El sistema va al ritmo de la conversación?». Cada 0,1 segundos, comparamos:
- Cuánto audio hemos enviado
- Cuánto audio se ha procesado realmente
Si la diferencia crece por encima de los 5 segundos, esa es nuestra señal: este proveedor se está quedando atrás. No está caído. No está roto. Pero va hacia ahí. Y ahí es cuando actuamos.
Mantenemos una «red de seguridad» en vivo de tu audio
A medida que se procesa el audio, mantenemos una copia de seguridad continua de todo lo que aún no se ha gestionado por completo. Piénsalo así:
- Si el sistema confirma que procesó algo → lo descartamos
- Si aún no lo ha hecho → lo conservamos
Así que en cualquier momento tenemos una copia perfecta del audio «intermedio», que es la parte con más riesgo de perderse. Sin conjeturas. Sin huecos.
Luego cambiamos a un respaldo
En el momento en que detectamos un retraso, no nos quedamos esperando. Nosotros:
- Ponemos en marcha un proveedor de respaldo (hay un orden de prioridad: primero el más rápido, el más cercano y el más fiable)
- Enviamos todo ese audio «en el limbo» para que pueda ponerse al día
- Apagamos el proveedor con problemas
También le damos al nuevo proveedor un breve periodo de gracia (~20 segundos) para estabilizarse antes de empezar a evaluar su rendimiento.
¿El resultado?
La transcripción simplemente… sigue adelante. Sin saltos. Sin retrocesos. Sin huecos extraños. Desde la perspectiva de quien llama, no pasó nada.
Por qué esto importa
La mayoría de los sistemas esperan a que un proveedor se caiga por completo antes de conmutar.
Nosotros no. Detectamos el momento en que empieza a tener problemas y lo sustituimos antes de que llegue a convertirse en un problema.
En resumen
- No esperamos al fallo
- Detectamos ralentizaciones en tiempo real
- Conservamos cada segundo de audio
- Cambiamos de proveedor sin interrupciones
Así la conversación sigue fluyendo exactamente como debería.
LLM: del enrutamiento a nivel de proveedor al nivel de despliegue
Cómo funcionan nuestros fallbacks de LLM
Ahora, en el lado de la respuesta, el fallo no es tan obvio. Es más sutil. Para cada modelo LLM (p. ej. GPT-4.1) tenemos un conjunto de «despliegues» que sirven ese modelo. Piensa en un despliegue como un centro de datos físico. Cuando queremos generar una respuesta de IA —o recuperar contexto fundamentado de un LLM Knowledge Graph para mejorar la precisión y reducir las alucinaciones— necesitamos especificar un despliegue concreto que procese esa solicitud.
Bajo el capó hay varias piezas en movimiento y puede volverse algo complejo, pero la idea central es sencilla:
Enrutamos a despliegues con menor latencia
Garantiza que las respuestas se generen más rápido y reduce el retraso para mantener las conversaciones sincronizadas en tiempo real.
Medimos y monitorizamos constantemente la tasa de errores de cada despliegue
Y cortamos el tráfico a los que tienen tasas de error altas.
Tenemos necesidad de velocidad al enviar una solicitud a un despliegue
Si es lento, no esperamos. Enviamos la solicitud a otro sitio y seguimos hasta que uno responda.
Que gane el mejor modelo de IA
Si un modelo falla en varios despliegues, no seguimos intentándolo. Cambiamos a otro y seguimos adelante.
En resumen
No dependemos de un solo modelo ni de un solo proveedor.
Estamos constantemente:
- enrutando a la mejor opción
- evitando lo que falla
- compitiendo por respuestas más rápidas
- y cambiando cuando hace falta
Así que, incluso cuando los sistemas tienen un mal día, tus conversaciones no.
.avif)
