En el mundo de la IA generativa, la latencia es la principal causa de muerte de la inmersión. Hasta hace poco, construir un agente de IA con capacidad de voz era como ensamblar una máquina de Rube Goldberg: canalizabas audio a un modelo de voz a texto (STT), enviabas la transcripción a un modelo de lenguaje grande (LLM) y finalmente transportabas el texto a un motor de texto a voz (TTS). Cada salto añadía cientos de milisegundos de retraso.
OpenAI ha colapsado esta pila con la API en tiempo real. Al ofrecer un modo WebSocket dedicado, la plataforma proporciona una conexión directa y persistente a las capacidades multimodales nativas de GPT-4o. Esto representa un cambio fundamental de los ciclos de solicitud-respuesta sin estado a la transmisión con estado y basada en eventos.
El cambio de protocolo: ¿por qué WebSockets?
La industria ha dependido durante mucho tiempo de las solicitudes HTTP POST estándar. Si bien la transmisión de texto a través de eventos enviados por el servidor (SSE) hizo que los LLM se sintieran más rápidos, una vez iniciado, siguió siendo una calle de sentido único. La API en tiempo real utiliza el protocolo WebSocket (wss://), proporcionando un canal de comunicación full-duplex.
Para un desarrollador que crea un asistente de voz, esto significa que el modelo puede “escuchar” y “hablar” simultáneamente a través de una única conexión. Para conectarse, los clientes apuntan a:
wss://api.openai.com/v1/realtime?model=gpt-4o-realtime-preview
La arquitectura central: sesiones, respuestas y elementos
Comprender la API en tiempo real requiere dominar tres entidades específicas:
La Sesión: La configuración global. A través de un evento session.update, los ingenieros definen el mensaje del sistema, la voz (por ejemplo, aleación, ceniza, coral) y los formatos de audio. El elemento: cada elemento de la conversación (el discurso de un usuario, la salida de un modelo o una llamada a una herramienta) es un elemento almacenado en el estado de conversación del lado del servidor. La respuesta: una orden para actuar. El envío de un evento Response.create le indica al servidor que examine el estado de la conversación y genere una respuesta.
Ingeniería de audio: PCM16 y G.711
El modo WebSocket de OpenAI opera en fotogramas de audio sin formato codificados en Base64. Admite dos formatos principales:
PCM16: Modulación de código de pulso de 16 bits a 24 kHz (ideal para aplicaciones de alta fidelidad). G.711: El estándar de telefonía de 8 kHz (u-law y a-law), perfecto para integraciones VoIP y SIP.
Los desarrolladores deben transmitir audio en pequeños fragmentos (normalmente de 20 a 100 ms) a través de eventos input_audio_buffer.append. Luego, el modelo transmite eventos de respuesta.output_audio.delta para su reproducción inmediata.
VAD: Del silencio a la semántica
Una actualización importante es la expansión de la Detección de Actividad de Voz (VAD). Mientras que el server_vad estándar usa umbrales de silencio, el nuevo semantic_vad usa un clasificador para comprender si un usuario realmente ha terminado o simplemente se ha detenido a pensar. Esto evita que la IA interrumpa torpemente a un usuario que está a mitad de una frase, un problema común en el “valle inquietante” en la IA de voz anterior.
El flujo de trabajo basado en eventos
Trabajar con WebSockets es inherentemente asincrónico. En lugar de esperar una única respuesta, escucha una cascada de eventos del servidor:
input_audio_buffer.speech_started: el modelo escucha al usuario. Response.output_audio.delta: los fragmentos de audio están listos para reproducirse. Response.output_audio_transcript.delta: las transcripciones de texto llegan en tiempo real. conversation.item.truncate: se utiliza cuando un usuario interrumpe, lo que permite al cliente decirle al servidor exactamente dónde “cortar” la memoria del modelo para que coincida con lo que el usuario realmente escuchó.
Conclusiones clave
Comunicación full-duplex basada en estado: a diferencia de las API REST tradicionales sin estado, el protocolo WebSocket (wss://) permite una conexión bidireccional persistente. Esto permite que el modelo “escuche” y “hable” simultáneamente mientras mantiene un estado de sesión en vivo, eliminando la necesidad de reenviar todo el historial de conversaciones en cada turno. Procesamiento multimodal nativo: la API omite el proceso STT → LLM → TTS. Al procesar audio de forma nativa, GPT-4o reduce la latencia y puede percibir y generar características paralingüísticas matizadas como tono, emoción e inflexión que normalmente se pierden en la transcripción de texto. Control granular de eventos: la arquitectura se basa en eventos específicos enviados por el servidor para la interacción en tiempo real. Los eventos clave incluyen input_audio_buffer.append para transmitir fragmentos al modelo y Response.output_audio.delta para recibir fragmentos de audio, lo que permite una reproducción inmediata y de baja latencia. Detección avanzada de actividad de voz (VAD): la transición de server_vad simple basado en silencio a semantic_vad permite que el modelo distinga entre un usuario que hace una pausa para pensar y un usuario que termina su oración. Esto evita interrupciones incómodas y crea un flujo de conversación más natural.
Consulta los detalles técnicos. Además, no dude en seguirnos en Twitter y no olvide unirse a nuestro SubReddit de más de 100.000 ML y suscribirse a nuestro boletín. ¡Esperar! estas en telegrama? Ahora también puedes unirte a nosotros en Telegram.
Michal Sutter es un profesional de la ciencia de datos con una Maestría en Ciencias de Datos de la Universidad de Padua. Con una base sólida en análisis estadístico, aprendizaje automático e ingeniería de datos, Michal se destaca en transformar conjuntos de datos complejos en conocimientos prácticos.
