De Prometa & Ore para "Ferramentas & Ore"

Quando as equipes de desenvolvimento enfrentam a fragilidade de um LLM independente, seu próximo passo lógico é integrar "ferramentas" por meio de chamada de função. O objetivo é permitir que o modelo interaja com APIs externas, como consultar um saldo de conta, enviar uma senha de uso único (OTP) ou até mesmo criar um plano de pagamento.

À primeira vista, isso parece a solução ideal. Um desenvolvedor expõe um conjunto de APIs para o modelo e lhe instrui, por meio do prompt, sobre quando e como usá-las. Parece que se está ganhando controle. O modelo pode agora "agir" no mundo real.

No entanto, o padrão subjacente permanece o mesmo: "Ferramentas e Ore." Você ainda está dependendo de uma caixa preta para tomar decisões consistentes. Você está esperando que o modelo:

• Selecione a ferramenta certa.

• Na ordem correta.

• Com os argumentos exatos.

• Respeitando as políticas de negócios e de segurança.

Em outras palavras, embora a chamada de função possa parecer uma evolução, não resolve o problema fundamental do controle. Em ambientes empresariais de alto risco, depender de um LLM para orquestrar processos complexos, mesmo com acesso a ferramentas, introduz risco em vez de removê-lo. 

Como também mencionado em capítulos anteriores, a verdadeira solução está em uma arquitetura que separa o que o modelo faz bem (conversa fluida e interpretação de texto) do que requer precisão, segurança e auditabilidade (regras de negócio).

→ Leia o Capítulo 4 de "Mergulhos Profundos em IA": IA para Pagamentos: Por que "Prompt e Ore" falha e o que escala de forma segura

O risco de depender apenas do LLM

Em indústrias de alto risco, como serviços financeiros e cobrança de dívidas, essa abordagem é particularmente perigosa. O que parece um simples "conjunto de APIs" é na verdade um processo de negócios complexo e multifacetado que requer:

• Validações de elegibilidade.

• Divulgações legais obrigatórias.

• Validação de consentimento.

• Etapas adicionais de autenticação.

• E notas de auditoria.

Tentar agrupar todos esses requisitos em descrições de ferramentas e um "mega-prompt" não garante que serão executados na sequência correta, com recuperação adequada em caso de falha, ou com o tom exigido pelos reguladores. 

O modelo pode recuperar o saldo correto e elaborar uma mensagem educada, mas também pode pular a solicitação de consentimento, manusear mal a autenticação ou fabricar um parâmetro de plano de pagamento, tudo antes que alguém perceba.

O que Chamada de Função pode e não pode fazer

Sejamos claros, chamada de função tem seu lugar. É ótimo para:

✅ Acesso a dados frescos: Permite que o modelo busque informações atualizadas. 
✅ Recuperação estruturada: Ajuda o modelo a obter dados específicos e organizados. 
✅ Base de dados: Fornece contexto factual para a resposta do LLM.

No entanto, por si só, não resolve:

❌ Controle de processo: A ordem e a lógica das ações não são garantidas. 
❌ Validação de argumentos: Não garante que os dados passados para as ferramentas sejam válidos ou sigam as regras de negócio. 
❌ Consentimento e autorização: Não garante que as etapas de permissão foram seguidas. 
❌ Garantias de tom e conformidade: A resposta final e o comportamento do sistema podem não atender às diretrizes de conformidade. 
❌ Auditabilidade e explicabilidade: Complica o rastreamento de cada etapa do processo.

Exemplo: Imagine que um cliente solicita o cancelamento de uma transferência bancária. O LLM escolhe a ferramenta correta, mas esquece de verificar a identidade com OTP antes de executar a chamada. Ou fabrica um ID de transação que parece válido, mas não existe. Ambos os casos resultam em controles falhos, exposição a fraudes em potencial e reconciliação dolorosa para as equipes de finanças. Sem um planejador externo, validadores e um sistema de controle determinístico, a abordagem "Ferramentas e Ore" simplesmente não é robusta o suficiente para a realidade empresarial.

→ Leia: O que é RAG (e o que não é): Um rápido histórico