La voz en tiempo real ofrece una forma radicalmente distinta de interactuar con aplicaciones basadas en IA. En lugar de escribir o navegar por menús, los usuarios hablan con naturalidad y reciben respuestas con el ritmo de una conversación en tiempo real y contexto emocional.
Crear una excelente experiencia de voz en tiempo real consiste en coordinar una interacción en vivo. Aquí comienza el verdadero trabajo de producto. La experiencia en tiempo real es inmediata y natural; desarrollar una aplicación capaz de sostenerla plantea un desafío de ingeniería particular.
El modelo es solo una parte del sistema. Las aplicaciones para producción necesitan infraestructura diseñada para voz, una separación clara entre la fluidez conversacional y el razonamiento profundo, y un control basado en eventos que gestione la sesión a medida que avanza.
Las medidas de protección y la evaluación concentran gran parte de las dificultades pendientes. Las verificaciones de seguridad deben seguir el ritmo del audio en vivo, y las cualidades efímeras de una conversación —como los tiempos, el tono y la fluidez— son difíciles de medir con estrategias de evaluación tradicionales.
Actualmente, la mayoría de las aplicaciones de IA con voz aún funcionan de la misma manera: reciben voz, la convierten en texto, un modelo piensa y una voz sintetizada lee la respuesta. Funciona. Pero la interacción se siente como lo que es: un proceso, no una conversación.
La voz en tiempo real cambia esto. Los usuarios hablan con naturalidad y reciben respuestas que transmiten ritmo, tono y contexto emocional. La experiencia es más rápida y fluida que los procesos encadenados de voz a texto: se parece más a hablar con una persona que a operar un sistema.
Hemos visto que esto habilita posibilidades de producto difíciles de abordar con arquitecturas de procesos encadenados. Los agentes de voz en tiempo real pueden gestionar interacciones de atención al cliente que, de otro modo, exigirían menús de respuesta de voz interactiva largos y restrictivos, además de transferencias entre departamentos. También pueden capacitar, facilitar la incorporación, mejorar la accesibilidad en distintos medios y mucho más. Vale la pena desarrollar voz en tiempo real siempre que la conversación hablada ofrezca ventajas frente a las interfaces de texto.
La mayoría de las aplicaciones con voz utilizan el llamado “enfoque encadenado”: un proceso compuesto por modelos independientes para convertir voz en texto, procesar el lenguaje y convertir texto en voz. Estos sistemas funcionan bien y abren muchas oportunidades, pero el audio solo aparece en los extremos. Los pasos independientes imponen estructura y agregan latencia, lo que produce una interacción menos natural que una conversación real.
La voz en tiempo real adopta otro enfoque. En vez de recurrir a distintos modelos para escuchar, pensar y hablar, un solo modelo realiza las tres tareas de forma nativa: comprende y genera simultáneamente audio y transcripciones. La entrada y la salida se producen continuamente, lo que permite al sistema responder con tiempos naturales y emoción, y conservar el ritmo realista de una conversación en vivo. Como resultado, los tiempos, el tono y el manejo de interrupciones se convierten en elementos centrales del producto.
La experiencia en tiempo real resulta atractiva por su inmediatez, pero es difícil porque nada espera su turno. Para ofrecerla, no basta con generar audio rápido y preciso. Lo difícil es todo lo demás. El modelo opera dentro de una sesión en vivo; todo lo que lo rodea —el estado, la seguridad, la orquestación y el control— debe operar a la par de la conversación y al mismo ritmo.
En una aplicación de voz encadenada, las conversaciones por turnos ofrecen una estructura clara de intercambio. El usuario habla, el sistema responde y comienza el siguiente paso. La voz en tiempo real no ofrece esa estructura. Ambas partes pueden hablar al mismo tiempo o ninguna puede hacerlo, lo que produce un silencio. Un usuario puede interrumpir a mitad de una respuesta o hacer otra pregunta antes de que el sistema termine de hablar. Las interrupciones dejan de ser casos excepcionales y se convierten en un patrón central de interacción.
Este patrón convierte a las aplicaciones en tiempo real, fundamentalmente, en un problema de coordinación. Por eso, el sistema que rodea al modelo importa tanto como el propio modelo.
Para ofrecer este tipo de sistema a escala, hay que diseñarlo específicamente para la interacción en vivo. Esto comprende tres aspectos que aparecen una y otra vez en los sistemas que llegan a producción.
Las sesiones de voz en tiempo real deben gestionar la transmisión de audio, los turnos para hablar, las interrupciones, el ciclo de vida de la conexión y la ejecución de agentes. Según dónde se implemente la aplicación, también puede ser necesario admitir telefonía. Estos son componentes fundamentales de la experiencia y esenciales para escalar la aplicación.
El primer requisito es una capa de sesión diseñada para voz. Los marcos de comunicación en tiempo real (RTC) proporcionan un entorno donde la aplicación puede gestionar participantes, transmitir audio y ejecutar agentes en un entorno de telefonía. Según nuestra experiencia, Livekit ha resultado especialmente útil: ofrece un conjunto de tecnologías WebRTC de baja latencia con cancelación de ruido de alta calidad y reducción de fluctuaciones listas para usar. Implementar esta capa por cuenta propia rara vez compensa la complejidad adicional.
Una arquitectura multiagente para voz en tiempo real se basa fundamentalmente en separar responsabilidades.
Los modelos de voz en tiempo real son muy eficaces para transmitir audio conversacional, pero no están optimizados para un razonamiento más profundo. Es preferible que tareas como el uso de herramientas, la recuperación de información o la toma estructurada de decisiones sean ejecutadas por otro modelo.
Un patrón útil es la arquitectura respondedor-pensador.
El respondedor es el agente de voz en tiempo real. Se encarga de mantener la interacción en vivo: escuchar, hablar, gestionar interrupciones y conservar la fluidez conversacional. Su diseño prioriza la capacidad de respuesta, la claridad y la continuidad emocional.
El pensador es un agente independiente, impulsado por un modelo capaz de razonar. Opera en un canal independiente y se ocupa de tareas como usar herramientas, recuperar información y planificar. El respondedor puede recurrir a él cuando sea necesario e incorporar los resultados a la conversación.
En algunos casos, el pensador puede encargarse directamente del razonamiento. En otros, puede orquestar un conjunto de agentes especializados. La idea clave es que este trabajo lo realice un modelo más adecuado para tareas de razonamiento.
El beneficio es sencillo: el respondedor puede mantenerse rápido, conversacional y enfocado, mientras el pensador se ocupa del trabajo que requiere más tiempo, contexto o estructura.
Los futuros avances en modelos de vanguardia podrían volver innecesario este enfoque. Por ahora, hemos comprobado que este patrón supera de manera constante a los enfoques de un solo agente.
Los sistemas de voz en tiempo real producen naturalmente un flujo continuo de eventos.
Los usuarios comienzan a hablar, hacen pausas e interrumpen. Las transcripciones se actualizan de forma gradual. Las respuestas se generan y transmiten. Llegan resultados externos. Las condiciones de la sesión evolucionan. Todos estos elementos pueden capturarse, transmitirse y almacenarse como eventos clave que dieron lugar al estado actual específico de la conversación. Sin ellos, perdemos la capacidad de realizar intervenciones específicas y detalladas.
Un enfoque basado en eventos ofrece una forma clara de gestionar todo esto. El sistema captura los eventos a medida que ocurren, actualiza el estado de la sesión y activa las acciones de seguimiento correspondientes.
Los controladores ligeros mantienen ágil el proceso en tiempo real, mientras que las tareas más complejas —como actualizar máquinas de estados, registrar métricas, eliminar información confidencial, actualizar bases de datos y salir de una sesión— se activan como tareas asíncronas en segundo plano.
A medida que se agregan funciones, la cantidad de estas tareas en segundo plano puede crecer rápidamente. Incluso los pequeños cambios en el producto pueden introducir nuevos flujos de eventos y dependencias. Una arquitectura bien estructurada para esta concurrencia es importante a fin de mantener el sistema comprensible y confiable conforme evoluciona.
Este enfoque basado en eventos también atiende una necesidad crítica del producto: dar forma a la conversación. Un sistema de audio en tiempo real no solo genera respuestas: también gestiona el ritmo y los silencios, maneja las interrupciones y decide cómo y cuándo debe terminar una sesión. Estos comportamientos forman parte de la experiencia del producto y se benefician de un diseño explícito.
A medida que el estado de la sesión evoluciona según la cantidad de turnos, el tiempo transcurrido o el comportamiento del usuario, el sistema puede proporcionar indicaciones específicas al respondedor. Por ejemplo, podría indicarle al agente que ayude al usuario a concluir cuando se aproxime al límite de la sesión, o que brinde una aclaración si la interacción se estanca. Estas intervenciones son ligeras, pero hacen que la experiencia se sienta intencional y coherente.
Un sistema bien diseñado mantiene una visión clara del estado de la sesión: quién habla, cómo avanza la conversación y qué condiciones se han cumplido. Este estado, actualizado continuamente por el flujo de eventos, permite ofrecer la indicación adecuada en el momento oportuno.
Las medidas de protección no son opcionales en la IA orientada a usuarios. Gestionan la seguridad, el cumplimiento, el uso indebido y la confiabilidad. En un sistema por turnos, hay momentos claros para aplicarlas: después de que habla el usuario o antes de entregar una respuesta.
La voz en tiempo real elimina casi todos esos cómodos puntos de control. La entrada del usuario llega de forma continua. Es posible que el audio de salida ya se esté transmitiendo. Las transcripciones terminadas suelen demorarse con respecto al audio. Si el sistema espera a recibir mensajes completos para verificarlos, la conversación deja de sentirse en tiempo real.
Por eso, las medidas de protección deben operar a la par de la conversación para conservar una interacción natural. Una opción es transmitir el audio a un búfer mientras se evalúan de manera asíncrona los fragmentos de la transcripción conforme están disponibles. Así, las verificaciones de seguridad pueden operar casi en tiempo real sin bloquear la interacción.
Cuando se activa una medida de protección, el sistema puede responder según el contexto: redirigir la conversación, ajustar su comportamiento o finalizar la sesión cuando corresponda. Esto permite que las medidas de protección funcionen en tiempo real sin perjudicar la experiencia del usuario.
Lo más difícil de evaluar un sistema conversacional en tiempo real es que algunas de sus cualidades más importantes —los tiempos, las interrupciones, la fluidez y el tono— no pueden medirse con pruebas basadas únicamente en transcripciones.
Los procesos de evaluación estándar introducen situaciones realistas en el sistema, observan los resultados y los califican. En sistemas de texto o audio encadenado, esto es sencillo: se envía texto y se revisa el texto obtenido. En tiempo real, la entrada es audio en vivo y las dinámicas conversacionales más importantes se desarrollan en la dimensión temporal: cómo gestiona el agente las voces superpuestas, qué tan rápido responde y cómo se recupera de una interrupción.
Las pruebas manuales —hablar directamente con el agente— captan estas cualidades, pero no son escalables. La automatización basada en transcripciones es escalable, pero elimina la señal que distingue una buena experiencia en tiempo real de una mala.
Ningún método basta por sí solo. La solución práctica es combinar varios niveles:
Evaluaciones entre agentes: un segundo agente en tiempo real, al que se le indica que adopte un perfil de usuario específico, conversa con el sistema que se está probando. Un tercer LLM actúa como juez y califica la interacción. Esto permite probar a escala todo el recorrido del audio, incluidos los tiempos y el manejo de interrupciones.
Métricas no funcionales: el tiempo hasta el primer audio y el análisis de sentimiento de las transcripciones proporcionan indicadores cuantitativos indirectos de la calidad conversacional.
Revisión cualitativa manual: sigue siendo esencial para detectar problemas que las métricas automatizadas pasan por alto, sobre todo en cuanto al tono y la naturalidad.
Ningún método abarca todo. Implementar agentes en tiempo real en producción exige combinar los tres métodos. Aun así, las herramientas para evaluar audio en tiempo real siguen siendo inmaduras frente a las disponibles para la IA basada en texto.
La voz en tiempo real transforma el producto. Los usuarios perciben los tiempos, las interrupciones, los silencios y la recuperación tanto como las palabras.
Esto significa que el modelo es solo una parte del sistema. La voz en tiempo real para producción necesita una capa de sesión diseñada para voz, una separación clara entre el habla y el razonamiento, y un control basado en eventos que gestione la sesión en vivo. Las medidas de protección siguen siendo el cuello de botella de la latencia, pero los enfoques creativos pueden conservar gran parte de la experiencia en tiempo real.
La evaluación sigue siendo la parte más débil del conjunto. Aún no existe un método establecido para probar las cualidades que hacen satisfactoria la voz en tiempo real: los tiempos, el tono, el manejo de interrupciones y la fluidez conversacional. Hasta que exista, los equipos que desarrollan con esta tecnología deberán combinar pruebas automatizadas, ejecuciones entre agentes y revisiones manuales.