Para além do entroncamento SIP: reduzir a latência dos agentes de voz para menos de 300 ms

Pela equipa da IdentityCall AI | Engenharia | 8 min de leitura

O novo padrão de latência

Em 2024, o “teste de Turing” para os agentes de voz não é só uma questão de inteligência: é uma questão de velocidade. O padrão anterior de 800 ms a 1 s de latência (típico das cadeias de LLM na cloud) já não é aceitável em interações de risco elevado com clientes. Os utilizadores percecionam os atrasos >500 ms como “robóticos” ou “avariados”, o que provoca sobreposições na fala e frustração.

O novo padrão de excelência é a alternância de turnos em menos de 300 ms. Este artigo explora as mudanças de arquitetura necessárias para o alcançar.

O estrangulamento: as cadeias tradicionais na cloud

A pilha tradicional de IA de voz tem este aspeto:

VAD (deteção de atividade de voz) espera pelo silêncio (200-500 ms).
Envio do áudio para a cloud (100 ms).
ASR (transcrição) processa o enunciado completo (200-400 ms).
Inferência do LLM gera o fluxo de tokens (200-800 ms).
TTS (síntese) gera áudio a partir do texto (200-400 ms).
Descarregamento do áudio e reprodução (100 ms).

Latência total: 1.5 s - 2.5 s. É por isto que o seu bot de voz de primeira geração parecia lento.

A solução: arquiteturas de streaming e edge

1. Execução especulativa e ASR em streaming

Não espere pelo silêncio. As arquiteturas modernas usam ASR em streaming, que envia transcrições parciais ao LLM enquanto o utilizador ainda está a falar.

Técnica: o LLM começa a prever a resposta com base nos primeiros 80% da frase.
Segurança: uma “porta de compromisso” garante que o bot não fala até a intenção estar clara, mas os tokens já estão pré-gerados.

2. IA no edge e VAD local

Mover a deteção de atividade de voz (VAD) para o edge (ou para o nó localizado do fornecedor de telefonia) poupa um tempo de ida e volta crítico.

Impacto: corta 100-200 ms de jitter de rede.
Implementação: usar módulos VAD em WebAssembly (Wasm) que correm diretamente no navegador ou no edge da telefonia.

3. Otimização do TTFT (tempo até ao primeiro token)

Para o próprio LLM, otimizamos o tempo até ao primeiro token.

Quantização: usar modelos quantizados a 4 bits (por exemplo, Llama-3-8B-Int4) aumenta drasticamente a velocidade de inferência, com uma perda de precisão insignificante em tarefas conversacionais.
Cache: o armazenamento em cache semântico guarda respostas a saudações comuns (“Olá”, “Quem fala?”) para as servir instantaneamente (0 ms de inferência).

Diagrama de arquitetura (Mermaid)

sequenceDiagram
    participant User
    participant Edge_VAD
    participant Cloud_LLM
    participant TTS_Engine
    
    User->>Edge_VAD: Speaks "I need to reset..."
    Edge_VAD->>Cloud_LLM: Stream: "I need to reset..."
    Cloud_LLM->>Cloud_LLM: Pre-fetch "Reset Password flow"
    User->>Edge_VAD: "...my password"
    Edge_VAD->>Cloud_LLM: Stream: "...my password" [EOS]
    Cloud_LLM->>TTS_Engine: Stream Tokens (Immediate)
    TTS_Engine->>User: Audio Stream (Sub-300ms)

Conclusão

Uma latência inferior a 300 ms transforma um “bot de voz” num “agente de voz”. Ao abandonar os ciclos rígidos de pedido-resposta em favor de arquiteturas fluidas de streaming, criamos experiências que parecem notavelmente humanas.

Pronto para construir agentes mais rápidos? Explore a nossa documentação da API para conhecer os endpoints de streaming.