La voz en tiempo real ofrece una forma radicalmente distinta de interactuar con aplicaciones basadas en IA. En vez de escribir o navegar por menús, los usuarios hablan con naturalidad y reciben respuestas con un ritmo en tiempo real y contexto emocional.
Crear una gran experiencia de voz en tiempo real consiste en coordinar una interacción en directo. Aquí comienza el verdadero trabajo de producto. La experiencia en tiempo real es inmediata y natural; crear una aplicación capaz de mantenerla plantea un reto de ingeniería específico.
El modelo solo es una parte del sistema. Las aplicaciones en producción necesitan infraestructura diseñada para voz, una separación clara entre la fluidez de la conversación y el razonamiento profundo, y un control basado en eventos que gestione la sesión mientras se desarrolla.
Las medidas de protección y la evaluación concentran gran parte de las dificultades pendientes. Las comprobaciones de seguridad deben seguir el ritmo del audio en directo, y las cualidades efímeras de la conversación, como los tiempos, el tono y la fluidez, son difíciles de medir con estrategias de evaluación tradicionales.
La mayoría de las aplicaciones de IA con voz siguen funcionando hoy del mismo modo: entra voz, sale texto, un modelo piensa y una voz sintetizada lee la respuesta. Funciona. Pero la interacción se percibe como lo que es: un proceso, no una conversación.
La voz en tiempo real cambia esta situación. 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 con los procesos encadenados de conversión de voz a texto; se parece más a hablar con una persona que a manejar un sistema.
Hemos visto cómo esto abre 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, requerirían largos y restrictivos menús de respuesta de voz interactiva y transferencias entre departamentos. Pueden formar, facilitar la incorporación, mejorar la accesibilidad en distintos medios y mucho más. Siempre que la conversación hablada ofrezca ventajas frente a las interfaces de texto, merece la pena desarrollar una solución de voz en tiempo real.
La mayoría de las aplicaciones con voz emplean el denominado «enfoque encadenado»: un proceso con modelos independientes para convertir voz en texto, procesar el lenguaje y convertir texto en voz. Estos sistemas funcionan bien y abren un amplio abanico de posibilidades, pero el audio solo está presente en los extremos. Los pasos independientes imponen estructura y añaden latencia, lo que produce una interacción menos natural que una conversación real.
La voz en tiempo real adopta otro enfoque. En lugar de depender de distintos modelos para escuchar, pensar y hablar, un único modelo realiza las tres tareas de forma nativa, y comprende y genera simultáneamente tanto audio como transcripciones. La entrada y la salida se producen de forma continua, lo que permite al sistema responder con tiempos naturales y emoción, manteniendo el ritmo realista de una conversación en directo. Así, los tiempos, el tono y la gestión de interrupciones se convierten en aspectos centrales del producto.
La experiencia en tiempo real resulta atractiva porque parece inmediata; es difícil porque nada espera su turno. Para ofrecerla no basta con generar audio de forma rápida y precisa. Lo difícil es todo lo demás. El modelo funciona dentro de una sesión en directo; todo lo que lo rodea —estado, seguridad, orquestación y control— debe operar en paralelo a 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 puede que ninguna hable y se produzca un silencio. Un usuario puede interrumpir a mitad de una respuesta o formular otra pregunta antes de que el sistema termine de hablar. Las interrupciones dejan de ser casos excepcionales y pasan a ser un patrón central de interacción.
Este patrón convierte las aplicaciones en tiempo real en un problema fundamentalmente de coordinación y explica por qué el sistema que rodea al modelo importa tanto como el propio modelo.
Ofrecer este tipo de sistema a gran escala exige diseñarlo específicamente para la interacción en directo. Esto consta de tres elementos 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 de palabra, las interrupciones, el ciclo de vida de la conexión y la ejecución del agente. Según dónde se implante la aplicación, también puede ser necesario admitir telefonía. Son elementos básicos 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 a la aplicación un entorno donde gestionar participantes, transmitir audio y ejecutar agentes en un entorno de telefonía. Según nuestra experiencia, Livekit ha resultado especialmente útil, ya que proporciona de serie una pila WebRTC de baja latencia, cancelación de ruido de alta calidad y reducción de la fluctuación. Rara vez compensa asumir la complejidad adicional de implementar esta capa por cuenta propia.
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. Tareas como llamar a herramientas, recuperar información o tomar decisiones estructuradas se benefician de que las ejecute otro modelo.
Un patrón útil es la arquitectura de respondedor y pensador.
El respondedor es el agente de voz en tiempo real. Se encarga de mantener la interacción en directo: escuchar, hablar, gestionar las interrupciones y conservar la fluidez de la conversación. Su diseño prioriza la capacidad de respuesta, la claridad y la continuidad emocional.
El pensador es un agente independiente basado en un modelo con capacidad de razonamiento. Funciona fuera del canal principal 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 actuar como orquestador de un conjunto de agentes especializados. La idea clave es que este trabajo lo realice un modelo más adecuado para las tareas de razonamiento.
La ventaja es sencilla: el respondedor puede seguir siendo rápido, conversacional y centrado, 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, pero, por ahora, hemos comprobado que este patrón supera sistemáticamente a los enfoques de un solo agente.
Los sistemas de voz en tiempo real generan de forma natural un flujo continuo de eventos.
Los usuarios empiezan a hablar, hacen pausas e interrumpen. Las transcripciones se actualizan de forma gradual. Las respuestas se generan y se transmiten. Llegan resultados externos. Las condiciones de la sesión evolucionan. Todos estos elementos pueden capturarse, transmitirse y almacenarse como eventos clave que han dado lugar al estado actual concreto de la conversación. Sin ellos, perdemos la capacidad de realizar intervenciones específicas y precisas.
Un enfoque basado en eventos ofrece una forma clara de gestionarlo. El sistema captura los eventos conforme se producen, actualiza el estado de la sesión y activa las acciones posteriores pertinentes.
Los controladores ligeros mantienen ágil el flujo en tiempo real, mientras que las tareas más complejas —como actualizar máquinas de estados, registrar métricas, eliminar información sensible, actualizar bases de datos y salir de una sesión— se activan como tareas asíncronas en segundo plano.
A medida que se añaden funciones, el número de estas tareas en segundo plano puede crecer rápidamente. Incluso pequeños cambios en el producto pueden introducir nuevos flujos de eventos y dependencias. Una arquitectura bien estructurada para gestionar esta concurrencia es importante para que el sistema siga siendo comprensible y fiable a medida que evoluciona.
Este enfoque basado en eventos también permite abordar un aspecto esencial del producto: dar forma a la propia conversación. Un sistema de audio en tiempo real no se limita a generar respuestas; gestiona el ritmo, los silencios y las interrupciones, y decide cómo y cuándo debe concluir 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 cambia según el número de turnos, el tiempo transcurrido o el comportamiento del usuario, el sistema puede proporcionar indicaciones específicas al respondedor. Puede indicar al agente que ayude al usuario a concluir cuando se acerque al límite de la sesión, o que ofrezca una aclaración si la interacción se estanca. Estas intervenciones son ligeras, pero hacen que la experiencia parezca deliberada 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 son indispensables en la IA de cara al usuario. Gestionan la seguridad, el cumplimiento normativo, el uso indebido y la fiabilidad. En un sistema por turnos, hay momentos evidentes para aplicarlas: después de que hable el usuario o antes de entregar una respuesta.
La voz en tiempo real elimina la mayoría de esos cómodos puntos de control. La entrada del usuario llega de forma continua. Es posible que la salida de audio ya se esté transmitiendo. Las transcripciones completas suelen llegar después que el sonido. Si el sistema espera a recibir mensajes completos para comprobarlos, la conversación deja de parecer en tiempo real.
En su lugar, las medidas de protección deben funcionar en paralelo a la conversación para conservar una interacción natural. Una opción consiste en transmitir el audio a un búfer mientras se evalúan de forma asíncrona los fragmentos de la transcripción conforme están disponibles. Así, las comprobaciones de seguridad pueden ejecutarse 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 puntúan. En sistemas de texto o audio encadenado, es sencillo: se introduce texto y se comprueba el texto resultante. En tiempo real, la entrada es audio en directo y las dinámicas conversacionales más importantes pertenecen a la dimensión temporal: cómo gestiona el agente el habla simultánea, cuánto tarda en responder y cómo se recupera de una interrupción.
Las pruebas manuales —hablar directamente con el agente— reflejan estas cualidades, pero no son escalables. La automatización basada en transcripciones sí 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 indica que adopte un perfil de usuario concreto, conversa con el sistema sometido a prueba. Un tercer LLM, que actúa como juez, puntúa la interacción. Esto permite probar a gran escala todo el recorrido del audio, incluidos los tiempos y la gestión de interrupciones.
Métricas no funcionales: el tiempo hasta el primer audio y el análisis del tono emocional de la transcripción ofrecen indicadores cuantitativos indirectos de la calidad de la conversación.
Revisión cualitativa manual: sigue siendo esencial para detectar problemas que las métricas automatizadas pasan por alto, sobre todo en el tono y la naturalidad.
Ningún método lo abarca todo. Llevar agentes en tiempo real a producción exige combinar los tres métodos y, aun así, las herramientas para evaluar audio en tiempo real siguen estando poco maduras frente a las de 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 solo es una parte del sistema. La voz en tiempo real en producción requiere una capa de sesión diseñada para voz, una separación clara entre hablar y razonar, y un control basado en eventos en torno a la sesión en directo. Las medidas de protección siguen siendo el cuello de botella de la latencia, pero los enfoques creativos permiten conservar gran parte de la experiencia en tiempo real.
La evaluación sigue siendo la parte más débil del conjunto. Todavía no existe un método consolidado para probar las cualidades que hacen satisfactoria la voz en tiempo real: los tiempos, el tono, la gestión de interrupciones y la fluidez de la conversación. Hasta que exista, los equipos que desarrollen con esta tecnología tendrán que combinar pruebas automatizadas, sesiones entre agentes y revisiones manuales.