Não deixe o LLM tomar decisões nem executar lógica de negócio

Argumento central: saia do LLM o mais rápido possível e não permaneça nele por muito tempo

• Não se deve delegar tomada de decisão ou lógica de negócio ao LLM → faltam precisão e estabilidade
• Na maioria dos casos, o LLM deve servir apenas como interface entre o usuário e a API da aplicação
• A lógica central deve ser executada em um sistema ou motor dedicado, e o LLM deve apenas converter a solicitação do usuário em chamadas de API e depois transformar o resultado de volta em linguagem natural

Por quê?

• Exemplo de bot de xadrez: o usuário envia pelo WhatsApp "capture o cavalo com meu bispo" → o LLM até pode manter o estado do tabuleiro e jogar, mas isso traz muitos problemas em confiabilidade, desempenho e manutenção

• Desempenho: a capacidade do LLM de jogar xadrez é impressionante, mas ainda assim ele é mais lento e menos preciso do que um motor de xadrez especializado (ex.: Stockfish)

• Impossibilidade de depuração e ajuste: é difícil saber por que ele tomou determinada decisão, então é complicado fazê-lo funcionar da maneira pretendida

• Outros problemas:

  • A saída do LLM é difícil de testar
  • O desempenho em matemática ou geração de números aleatórios é fraco
  • Controle de versões e auditoria são difíceis
  • Manter estado em linguagem natural é frágil
  • Surgem problemas como cobrança de API e limite de taxa
  • As fronteiras de segurança ficam difusas

A separação correta de papéis vista por diferentes exemplos

• Em um jogo, "quero atacar o jogador X com a espada vorpal" → o LLM deve apenas converter isso para a forma attack(player=X, weapon="vorpal_sword") e repassar para a lógica do jogo
• Agente de negociação → o LLM não toma decisões de negociação; ele apenas empacota a entrada do usuário, envia ao motor de negociação e transmite o resultado
• Geração de respostas aleatórias → não deve ser escolhida pelo LLM; isso precisa ser tratado por uma função aleatória externa

Em que o LLM é bom

• LLMs são especializados em transformação, interpretação e comunicação
• Exemplos:
  • "bater no orc com a espada" → converter para attack(target="orc", weapon="sword")
  • { "error": "insufficient_funds" } → explicar naturalmente como "você não tem ouro suficiente"
  • Classificar se a entrada do usuário é um comando de combate, verificação de inventário ou pedido de ajuda
  • Entender bem conceitos humanos (ex.: blade = sword, smash = attack)
• O ponto principal não é fazer julgamentos complexos nem gerenciar estado → ele serve apenas como ponte para conectar a intenção do usuário ao sistema

Perspectivas futuras e princípios que permanecem

• A tecnologia está evoluindo rapidamente, então o que é impossível hoje pode em breve se tornar viável
• Porém, problemas estruturais que o LLM não consegue resolver provavelmente continuarão existindo:
  • Lógicas que não usam LLM são mais fáceis de entender e de manter, além de facilitarem o controle de versões
  • O custo de execução também é mais baixo
• Mesmo no futuro, o LLM deve continuar focado no papel de interface, enquanto a lógica central deve ficar a cargo de sistemas dedicados

[GN⁺]

Comentários do Hacker News

• Existem dois tipos de lógica

  • 1. Lógica que precisa ser inerentemente correta e rigorosa
  • 2. Lógica que acabou sendo assim por causa das características dos computadores

• O tipo 1 se aplica a áreas como segurança, finanças e matemática

• O tipo 2 tem alta probabilidade de ser substituído por IA

• Partes diferentes do mesmo aplicativo podem se encaixar no tipo 1 ou no tipo 2

• Em um hackathon recente, foi criado um jogo educacional

  • O jogo foi gerado e executado usando um LLM, mas o fluxo do jogo não ficou bom
  • No fim, muito código Python e vários prompts foram usados para gerenciar o estado do jogo
  • O melhor é usar o LLM como uma pequena peça de um sistema maior

• Um LLM não deve implementar lógica

  • Lógica, otimização e programação por restrições são técnicas separadas
  • O fundador da lógica moderna é George Boole, e ele era avô de Geoffrey Everest Hinton

• É difícil entender as capacidades dos LLMs

  • Os leitores querem respostas simples
  • LLMs podem ter dificuldade para escrever uma máquina de estados simples
  • Artigos de pesquisa estão ganhando popularidade, e provavelmente ninguém entenderá completamente os LLMs nem até 2025

• Se a resposta de um LLM precisa ser rápida e barata, use prompts curtos e modelos pequenos

  • Muita informação parte do pressuposto de usar modelos grandes
  • Uma UI tradicional pode ser uma escolha melhor

• É difícil testar algo baseado apenas em LLM

  • O estilo de cada pessoa afeta a interação
  • O custo de manutenção pode ser alto
  • Pode ser mais sensato converter isso em chamadas de API

• Usar LLMs na lógica de negócio é arriscado

  • Eles são adequados para processamento de linguagem

• É possível usar imagens geradas por IA para resumir artigos