Pergunta de Entrevista sobre IA #2: Como Garantir a Confiabilidade das Chamadas de Ferramentas por Grandes Modelos de Linguagem (LLM)

Como garantir que um grande modelo de linguagem (LLM) funcione de forma confiável e controlável ao chamar ferramentas, em vez de depender apenas de prompts para "convencer" o modelo. É necessário um framework de restrições em múltiplas camadas.

Por exemplo, no caso de consulta meteorológica, existem três comportamentos comuns de "invenção" do modelo ao chamar ferramentas:
1. Não chamar a ferramenta e inventar a resposta diretamente.
2. Chamar a ferramenta com parâmetros em formato incorreto (por exemplo, a ferramenta não suporta "depois de amanhã", mas o parâmetro passado é date="depois de amanhã").
3. Converter o formato dos parâmetros por conta própria (por exemplo, converter "depois de amanhã" em uma data específica), mesmo que a ferramenta não exija isso.

A raiz do problema é que a saída do modelo é essencialmente probabilística, e os prompts apenas impõem "restrições suaves" na distribuição de probabilidade, não um mecanismo obrigatório que garanta a adesão estrita do modelo. Em cenários complexos, essas "restrições suaves" falham facilmente.

Para resolver esse problema, é necessária uma solução de engenharia em múltiplas camadas:

1. Primeira Camada: Otimização de Prompts (Restrições Suaves)

   • Posicionamento: é o ponto de partida do sistema de restrições, mas definitivamente não o fim.
   • Os prompts devem ser tratados como um "contrato operacional", descrevendo claramente o propósito da ferramenta, o tipo de cada parâmetro, os limites e listando exemplos de valores inválidos.
   • Devem ser incluídos exemplos Few-shot, mostrando exemplos de "entrada correta → chamada correta", utilizando aprendizado em contexto para ancorar o padrão de comportamento do modelo.

2. Segunda Camada: Introdução de JSON Schema (Restrições Rígidas)

   • Este é um passo crucial para passar de "argumentar" para "colocar barreiras".
   • Substituir a descrição de parâmetros em linguagem natural por definições estruturadas legíveis por máquina e verificáveis (JSON Schema). É possível definir rigorosamente o tipo do campo, se é obrigatório, o intervalo de valores enumerados, e proibir o modelo de gerar qualquer campo não definido através da configuração additionalProperties: false.
   • As principais plataformas de API suportam esse tipo de restrição de saída estruturada durante a fase de decodificação do modelo, evitando violações de formato na origem.

3. Terceira Camada: Estabelecer um Ciclo de Validação-Correção-Retry (Execução de Contingência)

   • Mesmo com o Schema, ainda é necessário realizar validação sintática e de Schema após obter a saída do modelo.
   • Quando a validação falha, deve-se projetar um mecanismo automático de limpeza e retry (com limite máximo), fornecendo informações de erro ao modelo para corrigir a saída. Após exceder o número de tentativas, deve haver um plano de degradação ou intervenção manual.

4. Nível de Arquitetura: Separação de Responsabilidades

   • Deve-se separar a decisão da execução, formando uma arquitetura de três camadas:
     • Camada do Modelo: Responsável apenas pela decisão (decidir qual ferramenta chamar, quais parâmetros gerar).
     • Camada de Framework: Responsável pela execução do framework, incluindo validação de Schema, chamada de ferramentas, tratamento de retries e integração de resultados. Isso garante que erros do modelo não afetem diretamente a segurança das ferramentas, e que alterações nas ferramentas não exijam ajustes frequentes nos prompts.
     • Camada de Ferramentas: Implementação de capacidades de negócio específicas.
   • Frameworks como LangChain e LlamaIndex estão exatamente fazendo esse trabalho.

Limitações da abordagem atual: Lida bem com problemas de formato de parâmetros, mas ainda é insuficiente na validação de semântica de parâmetros (por exemplo, equivalência entre "Xangai" e "沪"). Este será um desafio de engenharia a ser enfrentado no futuro.

Conclusão Principal: Tornar a chamada de ferramentas por LLMs confiável é essencialmente um problema de engenharia de software, que requer o estabelecimento de uma solução de engenharia sistemática, desde restrições suaves, restrições rígidas, execução de contingência até design de arquitetura, em vez de depender apenas da otimização de prompts.