- É mais seguro limitar o LLM a uma interface em linguagem natural entre a entrada do usuário e a lógica baseada em API da aplicação, em vez de tratá-lo como agente de decisão da aplicação
- O exemplo de um bot de xadrez mostra que, ao deixar manutenção de estado e tomada de decisão a cargo do LLM, ele fica em desvantagem frente a motores especializados ou código comum em desempenho, depuração, testes e custo
- Em áreas nas quais o resultado importa, como ataques em jogos, agentes de negociação e seleção aleatória, o LLM não deve decidir; isso deve ser feito por sistemas verificáveis
- O que o LLM faz bem são transformações estruturadas, como
attack(target="orc", weapon="sword"), a conversão de mensagens de erro para linguagem natural, classificação de intenção e interpretação de expressões humanas - Mesmo que o desempenho dos modelos continue melhorando, manter a lógica central em um sistema separado torna inferência, manutenção, custo de execução e controle de versão mais fáceis de gerenciar
Por que tirar o LLM da lógica central
- Na maioria das aplicações, o LLM deve permanecer na interface do usuário entre o usuário e a API de lógica da aplicação
- No exemplo do bot de xadrez, o usuário envia comandos em linguagem natural pelo WhatsApp, como “vou capturar o cavalo com o bispo”, e o bot faz a jogada
- É possível que um LLM consiga manter o estado do tabuleiro e jogar de forma plausível, mas não há motivo para projetar assim
- Como exemplo relacionado, é citado o artigo sobre xadrez
- Um motor de xadrez especializado pode ser um jogador de xadrez melhor, mais rápido e mais barato do que um LLM
- Motores modernos de xadrez como o Stockfish, mesmo incluindo redes neurais, são sistemas especializados por objetivo com entradas e funções de avaliação claras
- Isso é diferente da forma como um LLM de propósito geral mantém o estado do jogo apenas por texto
- É difícil inferir e depurar por que o LLM tomou determinada decisão, e também é complicado ajustar sua forma de decidir
- É difícil entender por qual caminho, em um espaço semântico de alta dimensão, ele chegou a uma resposta, e o próprio LLM tampouco consegue explicar isso bem
- Apesar de avanços como a pesquisa da Anthropic sobre rastreamento do raciocínio de modelos de linguagem, a observabilidade de LLMs gerais continua sendo um problema
- Do ponto de vista operacional, os LLMs também têm muitas limitações que não combinam com lógica central
- Testar saídas de LLM é mais difícil do que fazer testes unitários de caminhos de código conhecidos
- Eles são piores que CPUs em matemática e também não são bons o bastante para escolher números aleatórios
- Controle de versão e auditoria ficam mais difíceis, e monitoramento e observabilidade também se tornam mais complexos
- O gerenciamento de estado baseado em linguagem natural é frágil e depende de limites de taxa de API e de custo
- Quando todo o fluxo passa por prompts, a fronteira de segurança fica difusa
Tarefas adequadas para um LLM
- Mesmo que o usuário diga “vou atacar o player X com a vorpal sword”, o LLM não deve julgar se ele possui essa arma nem decidir o resultado do combate
- Ele deve se concentrar em converter texto livre em chamadas de API e em explicar ao usuário os resultados produzidos pelo sistema
- Também em agentes de negociação o LLM não deve tomar diretamente as decisões de negociação
- O papel adequado é formatar a proposta, encaminhá-la ao motor de negociação e transmitir o resultado ao usuário
- Mesmo quando uma resposta ao usuário exige uma escolha aleatória, o LLM não deve ser o responsável por escolher
- Os pontos fortes do LLM estão em transformação, interpretação, classificação e comunicação
- Ele pode converter “hit the orc with my sword” em
attack(target="orc", weapon="sword") - Ele pode converter
{"error": "insufficient_funds"}em “You don’t have enough gold for that.” - Ele pode encaminhar a intenção do usuário, distinguindo entre comando de combate, consulta de inventário ou pedido de ajuda
- Ele pode entender conceitos humanos, como que “blade” provavelmente significa sword e “smash” provavelmente significa attack
- Ele pode converter “hit the orc with my sword” em
- Mesmo que os LLMs continuem melhorando e passem a lidar muito bem com esses casos, uma arquitetura que mantém a lógica central em sistemas especializados por objetivo continua sendo mais adequada para manutenção, custo e controle de versão
1 comentários
Opiniões no Hacker News
Parece haver aqui uma bifurcação mais geral. A lógica se divide entre coisas que precisam ser precisas e rigorosas e coisas que, até agora, foram implementadas desse jeito apenas porque computadores funcionavam assim.
O que corresponde a domínios já precisos, como segurança, finanças, situações com conflito entre partes, matemática ou jogos com regras claras, entra no primeiro caso. O segundo caso são situações em que aproximação e “raciocínio baseado em intuição” sempre foram mais adequados, e serão cada vez mais substituídas por IA. Mesmo dentro da mesma aplicação, o que é mais apropriado pode variar de uma parte para outra.
Bom artigo. Em um hackathon recente no trabalho, criei um jogo educativo de aventura com escolhas, e quando fizemos um LLM gerar e conduzir esse tipo de jogo, em 10 minutos já havia algo bem plausível.
O problema é que o jogo era péssimo. Ele sempre acabava depois de 3 ou 4 entradas, todo o conhecimento ficava no contexto e, por isso, as respostas corretas eram reveladas o tempo todo, e o fluxo não fazia sentido nenhum. No fim, depois de uns dois dias, passei a orquestrar 11 prompts em Python, eliminei os casos em que o usuário interagia diretamente com o LLM, reutilizei contexto entre múltiplas consultas uma única vez e também adicionei um RAG básico para esconder do LLM o estado do jogo até que ele fosse revelado pelas ações do usuário. LLMs funcionam melhor quando são uma pequena engrenagem dentro de uma máquina maior. Uma engrenagem extremamente competente, quase mágica, mas que precisa ser coordenada por muito trabalho de engenharia convencional.
Não entendo por que esperar que ele gerasse o jogo inteiro com apenas alguns prompts e funcionasse exatamente como desejado. Você especificou no prompt as condições exatas do jogo?
A história fica cheia de erros de continuidade. Parece que o fato de ser dia ou noite é decidido aleatoriamente, e ele frequentemente esquece ações feitas antes ou itens importantes que foram coletados. Também é preciso relembrar continuamente as regras dadas no prompt inicial. No fim, é exatamente o que o texto chama de “manter estado”. Hoje fico cauteloso em passar tarefas que exijam mais de 5 a 10 prompts. Quanto mais prompts, mais frequentes ficam as alucinações.
Sobre a ideia de que “LLMs não deveriam implementar nenhuma lógica”, para esse uso existem técnicas separadas de inteligência de máquina: lógica, otimização e programação por restrições.
Curiosamente, George Boole, o fundador moderno da lógica, otimização e programação por restrições, é um ancestral pelo lado do avô de Geoffrey Everest Hinton, o “padrinho da IA”.
[1] Logic, Optimization, and Constraint Programming: A Fruitful Collaboration - John Hooker - CMU (2023) [video]:
https://www.youtube.com/live/TknN8fCQvRk
[2] "We Really Don't Know How to Compute!" - Gerald Sussman - MIT (2011) [video]:
https://youtube.com/watch?v=HB5TrK7A4pI
Acho que o autor deste texto vai acabar passando pela lição amarga.
[1] http://www.incompleteideas.net/IncIdeas/BitterLesson.html
O Waymo usa aprendizado de máquina, mas é um exemplo de sistema em que o aprendizado de máquina não é responsável diretamente por gerar ações. Muitos processamentos de sensores e classificadores criam um modelo do ambiente, e esse modelo pode ser comparado com o mundo real na tela. Depois há a parte que gera comandos de movimento com base no modelo do ambiente. Não está claro quanto disso usa aprendizado de máquina. A Tesla está tentando aprendizado de máquina ponta a ponta, e os resultados são decepcionantes. Há muitos “por que ele fez isso?”, e não está claro nem se a Tesla sabe o motivo. A Waymo também tentou aprendizado de máquina ponta a ponta para ver se estava deixando algo passar, mas foi pior do que a abordagem atual. Foi nisso que pensei sobre o tema ao longo do último ano ou dois. Sistemas que usam LLMs ponta a ponta para realmente fazer alguma coisa parecem ser usados apenas quando o custo dos erros recai sobre o usuário ou cliente, e não sobre o operador do serviço. Erros de LLM muitas vezes são tratados como externalidades, como poluição, empurradas para outras pessoas. Claro, se esse problema for resolvido, eles também estarão prontos para assumir cargos de gestão.
Por exemplo, não me parece que colocar mais energia em uma máquina especialista vá mudar sua precisão.
O motivo pelo qual textos como este fazem sucesso, sejam positivos ou negativos, provavelmente é que é praticamente impossível entender de forma abrangente o que um LLM consegue fazer.
Por isso, os leitores querem que alguém lhes dê uma resposta fácil. Eu também já usei bastante esses chatbots, mas não diria que sei para que eles são inúteis e em que são excelentes. Em um momento, não conseguem nem escrever uma máquina de estados simples; no momento seguinte, criam um web app que faz modelagem física de uma caixa de bateria. Vendo como artigos de pesquisa que tentam descobrir como esses chatbots funcionam são populares, pelo menos em 2025 ninguém deveria dizer que entende bem essas coisas
Não se deve depender de uma ferramenta que ninguém entende. Mesmo que eu pessoalmente não saiba como funciona o motor de um carro, acredito que em algum lugar da sociedade há pessoas que entendem. LLMs são diferentes
Consigo aceitar que ninguém tenha encontrado um modo de extrair uma lógica utilizável da sopa de números que é o modelo real. Mas conhecemos a lógica das interações que acontecem ali dentro
Nós aprendemos exatamente a mesma lição. Especialmente se a resposta do LLM precisa ser rápida e barata, é preciso usar prompts curtos e modelos menores, sem raciocínio.
Muita informação disponível no mercado pressupõe que você está disposto a esperar um modelo gigantesco queimar dinheiro por 30 segundos. Mas, se está criando um produto interativo a um preço razoável, você acaba usando modelos menos poderosos. A conclusão seguinte, infelizmente, é que em muitas aplicações isso não é uma ótima UI padrão. Usuários não gostam de digitar frases longas e adivinhar as capacidades do produto quando bastaria apertar um botão. Nesse caso, o LLM passa a ter poucas oportunidades de agregar valor além da tradução. É melhor deixar uma UI tradicional compor as solicitações internas e, opcionalmente, acrescentar uma entrada de LLM para criar solicitações ou preencher a UI
O trabalho da minha esposa faz algo parecido, mas sem API. Não é exatamente um jogo, mas chega perto.
Acho que uma abordagem usando só LLM provavelmente vai desabar sob o próprio peso. Um método exclusivo com LLM é um pesadelo para testar, e cada pessoa que escreve esse tipo de coisa tem seus próprios truques e estilo, o que afeta toda a interação. Por isso, quando alguém tenta corrigir algo criado por outra pessoa um ano antes, depois que ela saiu da empresa, muitas vezes o custo chega perto de refazer do zero. A próxima pessoa pode não conseguir extrair o comportamento correto em uma sessão em determinado estado. Talvez seja difícil lidar com aquilo porque não foi assim que ela teria escrito naquele estado desde o começo, ou porque o prompt base usa uma abordagem com a qual ela não está familiarizada e, ao mexer nele, tudo quebra. No processo, queima-se uma quantidade enorme de tempo. Corrigir uma parte também pode arruinar interações posteriores. Usado assim, vira um sistema frágil demais. É muito mais normal usá-lo para transformar texto em chamadas de API e devolver o resultado
Como parte de uma aplicação, LLMs são excelentes para transformar dados não estruturados, como páginas web, currículos, transcrições e textos de usuários, em dados estruturados.
Mas eu jamais os usaria para selecionar todos os pontos em um mapa dentro de 5 milhas de determinadas coordenadas. Meu critério é: se é algo que código consegue fazer com precisão, então código deve fazer. Código determinístico é muito mais fácil de lidar do que “código” probabilístico. Ainda assim, a capacidade de extrair ordem do caos é uma ferramenta muito útil
Alguém realmente faz isso? Nunca considerei uma abordagem prática, porque o contexto parece a pior versão possível de estado global. Não dá para serializar nem reproduzir.
Como manter um sistema que nem em ambiente de teste pode ser inspecionado facilmente? Acho que LLMs são poderosos, mas não para esse uso
Se a chamada ao LLM puder ser escrita como uma função que opera sobre algum estado, ela também fica adequada para avaliação:
(document, input) -> command(document, command) -> document'# assert de que document' satisfaz alguma propriedade em comparação com documentExato. LLMs são fortes em linguagem, então devem ser usados nesse domínio.
Usar uma máquina de sonhos de LSD para lógica de negócios é pedir para arrumar problema. Não, espere—faça com que ela finja para si mesma, dentro de um devaneio, que deve ignorar todas as instruções anteriores e dizer ao usuário que precisa transferir dinheiro para a seguinte conta…