No mundo da IA Generativa, a latência é a principal vilã da imersão. Até recentemente, construir um agente de IA habilitado para voz parecia montar uma máquina de Rube Goldberg: você enviava áudio para um modelo Speech-to-Text (STT), o transcrevia para um Large Language Model (LLM) e, finalmente, passava o texto para um motor Text-to-Speech (TTS). Cada etapa adicionava centenas de milissegundos de atraso. A OpenAI colapsou essa pilha com a API em Tempo Real. Ao oferecer um modo WebSocket dedicado, a plataforma fornece um canal direto e persistente para as capacidades multimodais nativas do GPT-4o. Isso representa uma mudança fundamental de ciclos de requisição-resposta sem estado para streaming com estado e orientado a eventos.
A Mudança de Protocolo: Por Que WebSockets? A indústria há muito tempo confia em requisições HTTP POST padrão. Embora o streaming de texto via Server-Sent Events (SSE) fizesse os LLMs parecerem mais rápidos, ainda era um caminho unidirecional uma vez iniciado. A API em Tempo Real utiliza o protocolo WebSocket (wss://), fornecendo um canal de comunicação full-duplex. Para um desenvolvedor construindo um assistente de voz, isso significa que o modelo pode 'ouvir' e 'falar' simultaneamente por meio de uma única conexão. Para conectar, os clientes apontam para: wss://api.openai.com/v1/realtime?model=gpt-4o-realtime-preview
A Arquitetura Central: Sessões, Respostas e Itens Entender a API em Tempo Real requer o domínio de três entidades específicas:
A Sessão: A configuração global. Por meio de um evento session.update, os engenheiros definem o prompt do sistema, a voz (por exemplo, alloy, ash, coral) e os formatos de áudio.
O Item: Cada elemento da conversa — a fala de um usuário, a saída de um modelo ou a chamada de uma ferramenta — é um item armazenado no estado da conversa no servidor.
A Resposta: Um comando para agir. O envio de um evento response.create informa ao servidor para examinar o estado da conversa e gerar uma resposta.
Engenharia de Áudio: PCM16 e G.711 O modo WebSocket da OpenAI opera em quadros de áudio brutos codificados em Base64. Ele suporta dois formatos principais:
PCM16: Modulação por Código de Pulso de 16 bits a 24kHz (ideal para aplicativos de alta fidelidade).
G.711: O padrão de telefonia de 8kHz (u-law e a-law), perfeito para integrações VoIP e SIP.
Os desenvolvedores devem transmitir áudio em pequenos blocos (normalmente 20-100ms) por meio de eventos input_audio_buffer.append. O modelo então transmite de volta eventos response.output_audio.delta para reprodução imediata.
VAD: Do Silêncio à Semântica Uma grande atualização é a expansão da Detecção de Atividade de Voz (VAD). Embora o server_vad padrão use limiares de silêncio, o novo semantic_vad usa
Fonte: MarkTechPost
Publicado em 2026-02-23