Function calling: o modelo não executa a função

Function calling, ou chamada de função, é o mecanismo que permite a um modelo de linguagem solicitar a execução de uma operação externa — consultar um preço, criar um registro no CRM, disparar um e-mail. É a base técnica de todo agente de IA. E carrega o mal-entendido mais consequente da categoria: o modelo não executa função nenhuma. Ele devolve um texto estruturado dizendo qual função chamaria e com quais argumentos; quem executa é o código da sua aplicação. A documentação dos fornecedores é literal nisso — o modelo “retorna uma chamada estruturada que sua aplicação executa”. A diferença não é semântica: define de quem é a responsabilidade quando a chamada errada é executada. E há um segundo dado que separa demonstração de produção — a chamada isolada acerta 97,5% das vezes, mas numa conversa real em que falta um parâmetro o melhor modelo cai para 48,5%.

O ciclo completo, e onde entra o seu código

São cinco passos, e o terceiro é o que importa para segurança:

• Você declara quais funções existem e que argumentos aceitam
• O modelo devolve um bloco estruturado: nome da função e argumentos
• Seu código executa — ou não executa
• Você devolve o resultado ao modelo
• O modelo redige a resposta final

Uma nuance que 2026 acrescentou: alguns fornecedores oferecem ferramentas executadas na própria infraestrutura deles — busca na web, execução de código. Então a formulação precisa não é “o modelo nunca executa”, e sim: a execução é do seu código ou do fornecedor, e você precisa saber qual dos dois em cada caso.

⚠️ Funciona na demonstração e quebra na conversa real

Existe um benchmark dedicado a isso, mantido por universidade, e o contraste que ele revela é o dado mais útil deste verbete. Os números abaixo são do artigo revisado por pares, com 71 modelos avaliados:

A leitura: a chamada isolada é problema resolvido — 97,5% de acerto, cerca de 2 erros a cada 100. É o que a demonstração do fornecedor mostra.

O que a demonstração não mostra é a conversa real, em que o cliente muda de assunto, esquece de informar um dado ou pede algo para o qual não existe função. Aí o melhor modelo entre 71 acerta 41% das vezes — erra em quase 6 de cada 10. E o pior caso é justamente o mais comum em atendimento: pedir algo que o sistema não faz.

Ressalva de datação: esses valores vêm do artigo publicado em 2025. O ranking vivo foi atualizado depois, mas é renderizado por JavaScript e não conseguimos extrair os números atuais — por isso atribuímos ao artigo, não ao ranking de hoje.

O que isso muda na prática

Que o modelo apenas solicite a execução tem uma consequência de segurança direta: se o seu código executa a solicitação sem validar, quem autorizou a operação foi um texto gerado. Combine isso com injeção de prompt — conteúdo externo que o modelo leu pode induzi-lo a emitir a chamada — e o risco fica claro.

Quatro decisões de projeto que os números acima justificam:

• Valide os argumentos no seu código, sempre. Faixa de valores, permissão do usuário, coerência com o estado atual. Nunca execute só porque o modelo pediu.
• Confirmação humana para o irreversível — disparar campanha, alterar preço, apagar registro, emitir cobrança.
• Ensine o agente a perguntar em vez de inferir. O pior cenário medido é justamente parâmetro faltando; um agente que chuta o valor ausente erra mais da metade das vezes.
• Teste o caminho torto, não o feliz. Cliente que muda de ideia, pedido fora do escopo, informação incompleta. É onde o desempenho despenca — e onde a demonstração nunca vai.

O protocolo que padronizou essa conexão entre modelos e ferramentas está em MCP.

Fontes

• Berkeley Function Calling Leaderboard — ICML 2025, 71 modelos avaliados
• Ranking vivo do BFCL — consultar na data da decisão
• Documentação de tool use — descreve quem executa cada tipo de ferramenta

Leitura das fontes em 17/08/2026.