Como a Chamada de Função Funciona (e Onde Ela Quebra) [Aprofundamentos em IA, Capítulo 6]
Jorge
Chefe de IA na Moveo
in
✨ Mergulhos Profundos em IA
Se você tem acompanhado nossa série "AI Deep Dives", sabe que já exploramos as limitações de abordagens como RAG e a inadequação da estratégia "Prompt & Pray" para tarefas críticas de negócios.
No nosso capítulo anterior, "De Prompt & Pray para Tools & Pray", começamos a questionar se usar ferramentas era a bala de prata. Neste sexto capítulo, vamos nos aprofundar em chamadas de função: a capacidade de grandes modelos de linguagem (LLMs) de interagir com ferramentas e APIs.
Veremos como essa funcionalidade funciona, por que é tão popular e, o mais importante, por que se torna uma fonte de problemas quando aplicada em ambientes corporativos que exigem rigor, segurança e governança.
Vamos lá!
O que é Chamada de Função?
Chamadas de função (ou chamadas de ferramenta) são um recurso que permite que um LLM interaja com o mundo exterior. Essencialmente, você fornece ao modelo uma lista de ferramentas (funções), junto com seus nomes, descrições e os argumentos esperados. Durante uma conversa, o modelo pode decidir:
Selecionar uma ferramenta (por exemplo,
getTransactions).Preencher os argumentos (por exemplo,
{ "date": "2025-09-01" }).Seu aplicativo executa a ferramenta e retorna o resultado.
O modelo usa o resultado para continuar a conversa ou chamar outra ferramenta.
Esta abordagem funciona perfeitamente para tarefas simples e de baixo risco, como verificar o clima, consultar um registro de CRM ou fazer um cálculo rápido. Se o modelo cometer um pequeno erro, o risco para os negócios é mínimo. É por isso que muitos desenvolvedores e equipes adoram a simplicidade e a flexibilidade que isso oferece.
Por que a chamada de função falha em empresas do mundo real
Apesar de sua utilidade, chamada de função não é a solução definitiva para todos os desafios empresariais. Em ambientes complexos, de alto risco e voltados para o cliente, ela falha de maneiras imprevisíveis e perigosas. As falhas em aplicações práticas muitas vezes caem em cinco categorias:
1. Seleção de Ferramentas em Escala
À medida que o número de ferramentas disponíveis aumenta, o modelo pode ter dificuldades em escolher a ação correta. Imagine um assistente de suporte que pode createRefund(), initiateChargeback() ou openDispute(). Se um usuário solicita "disputar uma transação", mas o modelo ativa um reembolso ou uma devolução, o resultado pode ser desordem financeira, reconciliações complicadas e até possíveis violações 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 incorretamente. Por exemplo, um assistente pode citar um ID de transação que parece correto, mas não pertence ao usuário, ou definir a start_date de um plano incorretamente. Pequenos erros como esses levam a ações incorretas que podem causar grandes dores de cabeça, como disputas falhadas ou cobranças incorretas.
3. Ordem e Estado do Fluxo de Trabalho
Em fluxos de trabalho de múltiplas etapas, como a necessidade de autenticação antes de uma transação, a chamada de função não pode garantir que as etapas serão executadas na ordem correta. Não é um mecanismo confiável para garantir que o modelo siga consistentemente a sequência correta.
Por exemplo, o modelo pode criar um plano ou discutir uma transação antes de autenticar o usuário ou obter consentimento explícito. Os riscos de pular etapas, a ausência de tentativas ou reversões, e a persistência de alucinações tornam essa abordagem inadequada para processos críticos.
4. Lógica de Negócios em Linguagem Natural
Tentar codificar regras complexas ("envie OTP antes de criar um plano, a menos que o usuário esteja verificado") diretamente em prompts é um convite ao 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 escala.
5. Conformidade e Auditoria
Em indústrias regulamentadas, certas divulgações, controles de tom e registros de cada etapa 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ívida", será incluída.
Se o modelo cometer um erro tonal ou pular uma etapa de consentimento, a empresa pode enfrentar multas, danos à reputação e a falta de artefatos essenciais para auditores.
Onde quebra | O que o usuário vê | Por que é um problema para a empresa |
Seleção de ferramentas em escala | Modelo chama | Ação financeira incorreta; caos de reconciliação e possíveis recuperações de valores; exposição à conformidade; desfazer pode ser complexo ou irreversível |
Correção de argumentos | Assistente cita um ID de transação que parece correto, mas não é do usuário; ou define o | Disputas falham ou atingem o item errado; planos mal configurados; dores de cabeça de reconciliação e regulamentação. |
Ordem e estado | Assistente cria um plano / disputa uma transação antes de autenticar ou sem consentimento explícito. | Implementar processos rígidos passo a passo de forma confiável dentro de prompts não é viável devido a vários riscos: os modelos podem pular etapas, não há garantia de sequência, tentativas ou reversões, e o risco de alucinação persiste. |
Lógica de negócios em prompts = ambiguidade | A instrução é vaga: “Envie OTP antes de criar um plano, a menos que o usuário esteja verificado.” O modelo interpreta “verificado” de forma abrangente 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. |
Conformidade e auditoria | Faltando a divulgação obrigatória (por exemplo, “Esta é uma comunicação de um cobrador de dívidas”); ou redação coercitiva (“Você deve pagar hoje”). | Exposição regulatória, multas, danos à reputação; artefatos pobres ou ausentes para auditores (consentimento, divulgações, registros de etapas). |
O que está faltando na Chamada de Função?
Quando etapas críticas, como consentimento, autenticação ou gravações em banco de dados, vivem dentro do prompt do modelo, não há garantias de que elas acontecerão, acontecerão na ordem correta ou serão executadas corretamente. A chamada de função, por si só, carece do controle e previsibilidade necessários para ambientes empresariais complexos.
É por isso que as empresas não podem confiar apenas nisso. Elas devem ir além, combinando a flexibilidade dos modelos de linguagem com uma arquitetura que fornece controle, governança e previsibilidade.
→ Leia o Capítulo 2: O grande debate da IA: Wrappers vs. Sistemas Multi-Agente em IA empresarial
A jornada continua...
Chamadas de função são poderosas, pois permitem que LLMs interajam com o mundo exterior e até executem ações reais. Mas esse poder não resolve o desafio subjacente. Chamadas de função não são um plano de controle: não garantem precisão, não impõem a ordem correta dos passos e não fornecem a confiabilidade e a governança que as empresas requerem.
Em vez disso, devem ser vistas como apenas um componente dentro de um framework empresarial mais amplo. Sozinha, amplifica o que um modelo pode fazer; combinada com a arquitetura certa, torna-se parte de um sistema que garante rigor, conformidade e confiança.
Na nossa próxima edição, Capítulo 7: A abordagem Moveo.AI (mais profunda), vamos mergulhar em como uma arquitetura híbrida, que combina a inteligência de LLMs com o rigor de fluxos de diálogo determinísticos, pode resolver os desafios que exploramos.
Você está pronto para descobrir como construir sistemas de IA que são tanto inteligentes quanto, mais importante, confiáveis? Fique atento!