Es importante destacar que la interacción por voz en tiempo real requiere un replanteamiento completo de la arquitectura tradicional de procesamiento de audio. En lugar de una cadena secuencial de reconocimiento, generación y síntesis, la solución óptima se basa en una conexión persistente y bidireccional que permite que el audio fluya simultáneamente en ambas direcciones. Esta característica esencial la ofrece Gemini Live a través de una API que mantiene abierta una sesión de streaming, evitando los silencios incómodos que aparecen cuando cada paso espera a que el anterior finalice.
Una consideración clave es el uso de WebSockets entre el navegador y el backend. El navegador captura el micrófono, reproduce el altavoz y controla el reproductor de música, mientras que el WebSocket actúa como un conducto continuo que transporta fragmentos de audio cada pocos milisegundos. En el servidor, los componentes de Google ADK –cola, runner, agente y sesión– se organizan de forma que la cola desacopla los flujos de entrada y salida, garantizando que ninguno bloquee al otro. El agente se define en un único bloque de configuración que incluye el modelo de lenguaje, la personalidad deseada y un conjunto de herramientas implementadas como funciones Python; añadir una nueva habilidad implica simplemente registrar una nueva función.
La experiencia nos demuestra que el runner es el corazón del ciclo de vida del agente. No basta con describir el agente; es necesario ejecutarlo mediante el runner, que gestiona la apertura y el cierre de la llamada, y traduce cada interacción en eventos. Estos eventos son la clave para reaccionar en tiempo real: la llegada de un fragmento de voz, la generación de subtítulos, la invocación de una herramienta (por ejemplo, reproducir música) o la detección de una interrupción por parte del usuario. Mantener la sesión en memoria resulta fundamental para que la latencia sea prácticamente nula; cualquier acceso a un servicio externo de sesión introducirá retrasos que romperían la sensación de inmediatez.
En la práctica, el envío de audio se divide en dos modalidades. Cuando el flujo es continuo, como el audio del micrófono, se utiliza la operación *send real?time*, que permite transmitir fragmentos sin esperar a que el usuario pulse un botón de envío. Es crucial no filtrar el silencio, ya que el modelo necesita esos intervalos para determinar el final de una frase. Por otro lado, para entradas discretas y completas –por ejemplo, un mensaje escrito o una foto– se emplea *send content*, que marca claramente el punto de finalización de la solicitud. Esta distinción evita errores comunes y asegura que el modelo reciba la información en el formato esperado.
El bucle en vivo se materializa mediante una única cola que recibe los fragmentos de audio en tiempo real y, paralelamente, entrega los eventos generados por Gemini Live al cliente. El backend funciona como dos procesos independientes: uno que alimenta la cola con los datos entrantes (*upstream*) y otro que consume los eventos y los envía de vuelta al navegador (*downstream*). Gracias a este desacoplamiento, el agente puede interrumpir su propia respuesta tan pronto como detecte que el usuario ha hablado, logrando una interacción tan natural como una llamada telefónica.
Finalmente, la integración de herramientas multimodales abre la puerta a casos de uso más avanzados. Una vez que el agente puede reproducir música bajo demanda, la siguiente fase consiste en dotarlo de la capacidad de iniciar llamadas o controlar otras partes de la aplicación, siempre manteniendo la arquitectura de flujo abierto y la gestión basada en eventos. Esta metodología no solo simplifica el desarrollo, sino que también garantiza escalabilidad y robustez en entornos de producción donde la latencia y la fluidez son requisitos críticos.
Fuente: YouTube
