Não deixe um LLM tomar decisões ou executar lógica de negócios: eles são péssimos nisso. Eu crio PNJs para um jogo online e me perguntam muito: "Como você conseguiu que o ChatGPT fizesse isso?". A resposta é invariavelmente: "Eu não consegui, e você também não deveria".

Na maioria das aplicações, o LLM deve ser a interface do usuário apenas entre o usuário e uma API para a lógica da sua aplicação. O LLM não deve executar nenhuma lógica. Saia do LLM o mais rápido possível e fique fora o máximo de tempo possível.

Por quê?

Isso é melhor ilustrado por um exemplo artificial: você quer criar um bot para jogar xadrez que você acessa pelo WhatsApp. O usuário envia uma descrição do que deseja fazer ("usar meu bispo para roubar o cavalo"), e o bot joga contra ele.

Você poderia colocar o LLM encarregado de manter o estado do tabuleiro de xadrez e jogar de forma convincente? Possivelmente, talvez . Você faria isso? Claro que não, por algumas razões intuitivas:

• Desempenho : É impressionante que os LLMs consigam jogar xadrez, mas são péssimos (em 01/04/2025). Um motor de xadrez especializado sempre será um jogador de xadrez mais rápido, melhor e mais barato. Mesmo motores de xadrez modernos como o Stockfish, que incorporam redes neurais, ainda são sistemas especializados, com entradas e funções de avaliação bem definidas – e não modelos de linguagem de propósito geral que tentam manter o estado do jogo por meio de texto.
• Depuração e ajuste : É impossível raciocinar e depurar por que o LLM tomou uma determinada decisão, o que significa que é muito difícil mudar a forma como ele toma essas decisões se você precisar ajustá-las. Você não entende a jornada que ele percorreu pelo espaço semântico de alta dimensão para chegar à sua resposta, e ele também é muito ruim em explicá-la. Mesmo redes neurais construídas para esse propósito, como as de motores de xadrez, podem ser desafiadoras para a observabilidade, e um LLM geral é um pesadelo, apesar dos grandes avanços da Anthropic nessa área .
• E o resto... : testar saídas de LLM é muito mais difícil do que testar caminhos de código conhecidos em unidades; LLMs são muito piores em matemática do que sua CPU; LLMs não são suficientemente bons em escolher números aleatórios; o controle de versão e a auditoria se tornam muito mais difíceis; o monitoramento e a observabilidade se tornam dolorosos; o gerenciamento de estado por meio de linguagem natural é frágil; você fica à mercê dos limites de taxa e custos da API; e os limites de segurança se tornam confusos quando tudo flui por meio de prompts.

Exemplos

O exemplo do xadrez ilustra o problema fundamental do uso de LLMs para a lógica de aplicações principais, mas esse princípio se estende muito além dos jogos. Em qualquer domínio onde precisão, confiabilidade e eficiência sejam importantes, você deve seguir a mesma abordagem:

1. O usuário diz que quer atacar o jogador X com sua espada vorpal? O LLM não deveria ser o sistema descobrindo se o usuário tem uma espada vorpal, ou quais seriam os resultados disso: o LLM é responsável por traduzir o texto livre que o usuário forneceu para uma chamada de API apenas e traduzir o resultado em texto para o usuário.
2. Você está construindo um agente de negociação que deve responder às ofertas do usuário? O LLM não é responsável pela negociação, apenas por empacotá-la, repassá-la ao mecanismo de negociação e informar o usuário sobre o resultado.
3. Você precisa fazer uma escolha aleatória sobre como responder ao usuário? O LLM não pode escolher

Lembrete do que os LLMs fazem bem

Embora eu tenha focado no que os LLMs não devem fazer, é igualmente importante entender seus pontos fortes para que você possa aproveitá-los adequadamente:

Os LLMs se destacam na transformação e na categorização, e têm uma base muito boa em "como o mundo funciona", e é aí que você deve aplicá-los no seu processo.

O LLM é bom em pegar "acerte o orc com minha espada" e transformar em attack(target="orc", weapon="sword") . Ou pegar {"error": "insufficient_funds"} e transformar em "Você não tem ouro suficiente para isso".

O LLM é bom em descobrir o que o usuário está tentando fazer e encaminhá-lo para a parte certa do seu sistema. É um comando de combate? Uma verificação de inventário? Um pedido de ajuda?

Por fim, o LLM é bom em conhecer conceitos humanos e saber que uma “lâmina” é provavelmente uma espada e “esmagar” provavelmente significa ataque.

Observe que todos esses pontos fortes envolvem transformação, interpretação ou comunicação — não tomada de decisões complexas ou manutenção do estado crítico da aplicação. Ao restringir os LLMs a essas funções, você obtém seus benefícios sem as armadilhas descritas anteriormente.

O futuro

O que os LLMs podem e não podem fazer está em constante mudança e me lembra do " Deus das lacunas ". Um termo da teologia que diz que cada fenômeno misterioso já foi explicado por intervenção divina — até que a ciência preencheu essa lacuna. Da mesma forma, as pessoas constantemente identificam novas tarefas "exclusivamente humanas" para alegar que os LLMs não são verdadeiramente inteligentes ou capazes. Então, apenas alguns meses depois, surge um novo modelo que lida com essas tarefas muito bem, forçando todos a mudarem as regras do jogo novamente, exemplos passim . É uma meta em constante evolução, e o que parece fora de alcance hoje pode ser resolvido mais cedo do que esperamos.

E assim como em nosso exemplo de xadrez, provavelmente em breve teremos LLMs que podem lidar razoavelmente bem com todos os exemplos acima. Suspeito, no entanto, que a maioria das desvantagens não desaparecerá: a lógica não LLM que você passar para ela será mais fácil de raciocinar, mais fácil de manter, mais barata de executar e mais fácil de controlar por versão.

Mesmo que os LLMs continuem melhorando, o princípio arquitetônico fundamental permanece: use os LLMs para aquilo em que eles são melhores — a camada de interface — e confie em sistemas desenvolvidos especificamente para sua lógica principal.