Agentes de voz com RAG e function calling

Um agente de voz que só conversa é demo. Um agente de voz que consulta o seu CRM, busca uma conta, cobra um cartão e atualiza um pedido é produto. A diferença é function calling e RAG. A parte difícil é conectar os dois numa conversa em streaming sem estourar o orçamento de latência que faz o agente parecer natural. Este post caminha pelo que function calling e RAG fazem de fato por um agente de voz, pelas arquiteturas híbridas que viraram padrão em 2026, quando o agente deve chamar uma ferramenta e quando deve continuar falando, e por como o SipPulse AI orquestra tudo.

Por que um agente de voz precisa de ferramentas e RAG

Pedido real de cliente não fica nos dados de treino do LLM. O cliente pede o saldo, o agente precisa chamar a API de cobrança. O cliente pergunta sobre uma feature, o agente precisa buscar documentação atual. O cliente quer reagendar, o agente precisa consultar a API de calendário e escrever o novo compromisso. Nada disso se responde só com o prompt do modelo.

Dois padrões resolvem:

• Function calling: o LLM decide no meio da conversa que precisa chamar uma API, o runtime executa a chamada, o resultado volta para o próximo turno do LLM
• RAG (Retrieval Augmented Generation): o agente recupera documentos relevantes de uma base de conhecimento, injeta no prompt e gera uma resposta ancorada no conteúdo recuperado

Function calling lida com estado dinâmico (dado de conta, transações, estoque em tempo real). RAG lida com conhecimento documentado (docs de produto, políticas, FAQs). Um agente de voz de produção tipicamente usa os dois.

Function calling: a chamada de API no meio da conversa

Function calling deixa o LLM decidir, no meio de um turno, que precisa invocar uma API. O modelo emite uma chamada estruturada com parâmetros, o runtime executa e a resposta é dobrada de volta no prompt para a próxima geração. Para o usuário, o agente diz "deixa eu checar para você", uma pausa de meio segundo acontece, e depois "seu saldo é R$ 432,18". O loop inteiro fecha abaixo de um segundo numa stack bem afinada.

A implementação importa. Function calling adiciona latência: a chamada de API precisa do round-trip e o LLM precisa gerar segunda resposta. Agentes de produção lidam com isso de três formas:

• Falar um preenchimento enquanto a chamada está em voo: "deixa eu ver isso aqui" compra o tempo do round-trip
• Streamar resultado parcial: o agente começa a falar a resposta assim que os primeiros tokens chegam, não quando a resposta completa acaba
• Pré-buscar chamadas prováveis: se o cliente está perguntando sobre conta, busque dado de conta antes de ele terminar a frase

Um agente que fica em silêncio por 2 segundos enquanto a chamada resolve parece quebrado. Um agente que diz "olhando agora" e segue em frente parece profissional.

RAG para voz: ancorando o agente nos seus dados

RAG transforma sua base de conhecimento em algo que o agente de voz consegue responder. O padrão: documentos são fatiados e transformados em embeddings num banco vetorial. Quando o usuário pergunta, o agente recupera os trechos mais relevantes, injeta no prompt do LLM como contexto e gera uma resposta ancorada.

Para voz, RAG tem restrições mais apertadas que para chat:

• Latência: busca vetorial precisa completar rápido o bastante para caber no orçamento da conversa, idealmente abaixo de 100ms
• Precisão sobre recall: uma recuperação errada vira resposta falada errada que o usuário não tem como inspecionar
• Orçamento de comprimento: respostas faladas precisam ser curtas, então o contexto RAG precisa ser seletivo e não despejar o trecho inteiro

Sistemas de RAG nativo sincronizam a base de conhecimento da empresa diretamente na memória do agente. O custo de manutenção importa tanto quanto o setup inicial: quando uma política muda, os embeddings precisam ser reconstruídos, ou o agente passa a citar a política antiga com confiança.

Speech-to-speech híbrido com cascata

Muitas implantações em 2026 são híbridas: speech-to-speech para small talk e aberturas emocionais, com fallback em cascata (STT, LLM, TTS separados) quando tool call ou RAG entra em cena. A razão se divide:

• Modelos speech-to-speech (um modelo só recebe áudio e produz áudio) ganham na latência de abertura. São ótimos para "Oi, como posso ajudar?" e reconhecimentos curtos e emocionais.
• Pipelines em cascata dão mais flexibilidade, uso mais limpo de ferramentas e escolha de qual LLM e TTS plugar. São necessários no momento em que o agente precisa chamar API ou buscar em base de conhecimento.

O padrão certo depende do caso. Um agente de reserva que sempre precisa chamar API de calendário fica em cascata de ponta a ponta. Uma recepcionista amigável que lida majoritariamente com small talk se beneficia de speech-to-speech nas aberturas e cascata só quando a intenção escala. O Nemotron da NVIDIA, lançado no CES 2026, e o GPT-4o realtime API são as duas opções canônicas de speech-to-speech; ambos suportam function calling, com cascata geralmente ainda preferida para orquestração complexa de ferramentas.

Quando o agente NÃO deve chamar ferramenta

O outro lado do function calling é contenção. Um agente que chama ferramenta a cada pergunta é lento. Prompting de produção inclui política clara sobre quando chamar:

• Buscar dado que o agente não sabe (saldo, status de pedido, disponibilidade de produto)
• Executar uma ação (reservar, cancelar, cobrar, atualizar)
• Verificar um fato em incerteza (esse produto ainda está disponível, o preço mudou)

Mas não:

• Cumprimentar o cliente (sem ferramenta)
• Confirmar entendimento (o LLM parafraseia sem ajuda)
• Tratar recusa ou pedido fora de escopo (o agente deve seguir instruções de segurança, não chamar ferramenta para pensar)

A disciplina importa porque toda chamada desnecessária adiciona latência e custo.

Onde o SipPulse AI se encaixa

O SipPulse AI suporta function calling e RAG nativamente no prompt do agente. Você declara as ferramentas a que o agente tem acesso, o runtime trata do round-trip do LLM, o TTS em streaming fala preenchimento enquanto as ferramentas resolvem. RAG consegue puxar de qualquer banco vetorial via APIs padrão, e a estrutura de prompt facilita a regra "responda só a partir do contexto recuperado" para reduzir alucinação.

O NIVA, nosso construtor em blocos, deixa pessoas sem perfil de engenharia configurar quais agentes têm quais ferramentas, rotear a conversa entre agentes especializados com base na intenção e combinar blocos de agente de voz com passos clássicos de URA. Um agente de retenção com ferramentas de consulta profunda de conta e um agente de cobrança com ferramentas de pagamento podem viver no mesmo fluxo com handoff limpo.

Converse com uma demo de function calling em sippulse.ai/demos e veja a latência por chamada no visualizador de telemetria de exemplo. Quando function calling entra no loop, o timing por estágio no payload do webhook facilita ver se a latência está na chamada de API ou na segunda passagem do LLM.

Leia também

• Arquitetura de agentes de voz: STT, LLM, TTS e o orçamento de latência
• Construindo agentes de voz em WebRTC: a stack de produção
• Avaliando agentes de voz em produção: WER, MOS, latência

Conclusão

Um agente de voz que chama API e se ancora na sua base de conhecimento é a diferença entre brinquedo de chat e produto. Function calling e RAG carregam custo de latência e complexidade, e speech-to-speech híbrido com cascata é o padrão dominante de produção em 2026. Teste nossa demo para sentir function calling em ação ou fale com o time para plugar o SipPulse AI nas suas ferramentas e dados.