Como o Function Calling funciona (e onde ele falha) [AI Deep Dives - Capítulo 6]
George
Chief of AI na Moveo
26 de setembro de 2025
in
✨ AI Deep Dives
Se você está acompanhando nossa série “AI Deep Dives”, sabe que, até agora, exploramos as limitações de abordagens como RAG e a inadequação da estratégia "Prompt & Pray" para tarefas empresariais críticas.
No capítulo anterior, "From Prompt & Pray to “Tools & Pray'", começamos a questionar se o uso de ferramentas seria a solução mágica. Já no sexto capítulo, entenderemos mais a fundo o function calling: a habilidade dos modelos de linguagem de interagir com ferramentas e APIs.
Veremos como essa funcionalidade opera, por que é tão popular e, o mais importante, por que ela se torna uma fonte de problemas quando aplicada em ambientes corporativos que exigem rigor, segurança e governança. Confira!
O function calling, ou tool calling, é um recurso que permite que um modelo de linguagem interaja com o mundo exterior. Em essência, você fornece ao modelo uma lista de ferramentas (funções), com seus nomes, descrições e os argumentos esperados. Durante uma conversa, o modelo pode decidir:
Escolher uma ferramenta (por exemplo,
getTransactions).Preencher os argumentos (ex:
{ "date": "2025-09-01" }).Sua aplicação executa a ferramenta e retorna o resultado.
O modelo usa o resultado para continuar a conversa ou chamar outra ferramenta.
Essa abordagem funciona perfeitamente para tarefas simples e de baixo risco, como verificar o clima, pesquisar um registro no CRM ou fazer um cálculo rápido. Se o modelo cometer um pequeno erro, o risco de dano ao negócio é mínimo. É por isso que muitos desenvolvedores e equipes gostam da simplicidade e da flexibilidade que ela oferece.
Por que o Function Calling quebra em empresas reais
Apesar de sua utilidade, o function calling não é a solução definitiva para todos os desafios empresariais. Em ambientes de alta complexidade e risco, ele falha de maneiras previsíveis e perigosas.
As falhas mais comuns podem ser divididas em cinco categorias:
1. Seleção de Ferramentas em Grande Escala
À medida que o número de ferramentas aumenta, o modelo pode ter dificuldade em escolher a ação correta.
Imagine um assistente de suporte que pode createRefund(), initiateChargeback() ou openDispute(). Se o usuário pede para "disputar uma transação", mas o modelo aciona um reembolso ou estorno, isso pode gerar um caos financeiro, exigir reconciliações complexas e até mesmo expor a empresa a riscos de conformidade.
→ Leia o Capítulo 4: IA para Pagamentos: Por Que “Prompt & Pray” falha e o que escala com segurança
2. Correção de Argumentos
Mesmo que o modelo selecione a ferramenta certa, ele pode preencher os argumentos de forma incorreta.
Por exemplo, um assistente pode citar um ID de transação que parece correto, mas não pertence ao usuário, ou configurar a start_date de um plano de forma errada.
Pequenos erros como esses levam a ações incorretas que podem causar grandes dores de cabeça, como disputas que falham ou cobranças incorretas.
3. Ordem e Estado do Fluxo
Em fluxos de trabalho que exigem múltiplos passos, como autenticação antes de uma transação, o function calling não garante que a ordem correta será seguida. Não é viável confiar que o modelo sempre fará as coisas na sequência certa.
Ele pode, por exemplo, criar um plano ou disputar uma transação antes de autenticar o usuário ou obter o consentimento explícito. O risco de pular etapas, a ausência de retentativas ou rollbacks e a persistência de alucinações tornam essa abordagem inviável para processos críticos.
4. Lógica de Negócio em Linguagem Natural
Tentar codificar regras complexas ("enviar OTP antes de criar um plano, a menos que o usuário seja verificado") diretamente nos prompts é um convite para o desastre.
Essas instruções em linguagem natural são ambíguas e frágeis, e pequenas mudanças na redação podem alterar drasticamente o comportamento do modelo. Isso torna quase impossível garantir consistência e conformidade em larga escala.
5. Conformidade e Auditoria
Em setores regulamentados, certas divulgações, controles de tom e registros de cada etapa do processo são obrigatórios. O modelo não pode garantir que uma frase necessária, como "Esta é uma comunicação de um cobrador de dívidas", seja incluída.
Se o modelo cometer um erro de tom ou pular uma etapa de consentimento, a empresa pode enfrentar multas, danos à reputação e falta de artefatos essenciais para auditorias.
Onde a falha acontece | O que o usuário vê | Por que é um problema para a empresa |
Seleção de Ferramentas em Escala | O modelo chama | Ação financeira incorreta; caos na reconciliação e potenciais estornos (clawbacks); exposição à conformidade (compliance); reverter a ação pode ser complexo ou irreversível. |
Correção dos Argumentos | O assistente cita um ID de transação que parece correto, mas não é do usuário; ou define a | Disputas falham ou atingem o item errado; planos configurados incorretamente (mis-configured plans); dores de cabeça com reconciliação e regulamentação. |
Ordem e Estado do Fluxo | O assistente cria um plano / disputa uma transação antes de autenticar ou sem consentimento explícito. | A implementação de processos rigorosos passo a passo dentro de prompts não é viável devido a vários riscos: os modelos podem pular etapas, não há garantia de sequenciamento, retentativas (retries) ou reversões (rollbacks), e o risco de alucinação persiste. |
Lógica de Negócio em Prompts = Ambiguidade | A instrução é vaga: "Enviar OTP antes de criar um plano, a menos que o usuário seja verificado." O modelo interpreta "verificado" de forma flexível e pula o OTP. | Regras em linguagem natural são ambíguas/frágeis; o comportamento varia com pequenas mudanças na redação; é impossível provar conformidade consistente (consistent compliance). |
Conformidade e Auditoria | Falta de divulgação obrigatória (por exemplo, "Esta é uma comunicação de um cobrador de dívidas"); ou fraseado coercitivo ("Você deve pagar hoje"). | Exposição a regulamentação, multas, danos à reputação; artefatos para auditores ausentes ou deficientes (consentimento, divulgações, logs de etapas). |
Então… o que falta no Function Calling?
Quando etapas críticas (como consentimento, autenticação e gravação em um banco de dados) dependem do modelo, não há garantia de que elas acontecerão, na ordem certa ou com a devida exatidão. O function calling, por si só, carece do controle e da previsibilidade necessários para ambientes corporativos complexos.
É por isso que as empresas não podem depender apenas dele. É preciso ir além, combinando a flexibilidade dos modelos de linguagem com uma arquitetura que ofereça controle, governança e previsibilidade.
→ Leia o Capítulo 2: Wrappers vs. Multi-Agent Systems: O grande debate na IA Corporativa
A jornada continua...
O function calling é poderoso, pois dá aos LLMs a capacidade de interagir com o mundo exterior e até mesmo executar ações reais. Contudo, esse poder não resolve o desafio fundamental.
O function calling não é um plano de controle: ele não garante a precisão, não impõe a ordem correta das etapas e não oferece a confiabilidade e a governança que as empresas exigem.
Em vez disso, ele deve ser visto como apenas um componente dentro de um framework empresarial mais amplo. Por si só, ele amplifica o que um modelo pode fazer; quando combinado com a arquitetura correta, torna-se parte de um sistema que garante rigor, conformidade e confiança.
Em nosso próximo artigo, o Capítulo 7: The Moveo.AI approach (deeper), vamos aprofundar como uma arquitetura híbrida, que combina a inteligência dos LLMs com o rigor dos fluxos de diálogo determinísticos, pode resolver os desafios que exploramos até agora.
Você está pronto para descobrir como construir sistemas de IA que são não apenas inteligentes, mas, acima de tudo, confiáveis? Fique ligado!