GPT-4 Falhou 99,4% das Vezes — Então Paramos de Deixá-lo Tomar Decisões

Era quase meia-noite, e eu estava observando nosso agente reservar um voo para a cidade errada pela terceira vez seguida.

Não uma cidade errada diferente a cada vez — a mesma cidade errada. Delhi em vez de Dehradun. O usuário havia digitado "Dehradun" claramente. O LLM havia interpretado corretamente em seu raciocínio de cadeia de pensamento. E então, quando gerou a chamada de API, trocou pelo código do aeroporto de Delhi. Com confiança. Silenciosamente. Três vezes.

Meu cofundador estava na ligação. Ele disse: "Ele sabe a resposta certa. Olhe o rastro de raciocínio. Ele literalmente diz Dehradun. E então faz outra coisa."

Foi naquela noite que parei de acreditar que prompts melhores nos salvariam.

Estávamos construindo um agente de IA para reservas de viagens — o tipo que se comunica com Sistemas de Distribuição Global como Amadeus e Sabre, aqueles backends antigos, da era dos mainframes, que alimentam cada reserva aérea do planeta. E vínhamos fazendo o que todo mundo fazia em 2023: envolver o GPT-4 em uma fina camada de orquestração, dar a ele ferramentas e rezar.

A reza não estava funcionando.

O Número Que Mudou Tudo

Algumas semanas depois daquele incidente de Dehradun, deparei-me com o benchmark TravelPlanner — uma avaliação acadêmica rigorosa que testa LLMs no planejamento de itinerários de vários dias com restrições reais: orçamentos, transporte, alimentação, hospedagem. O tipo de coisa que um agente de viagens competente faz em vinte minutos.

A taxa de sucesso geral do GPT-4: 0,6%.

Não 60%. Não 6%. Zero vírgula seis por cento.

Li isso três vezes. Depois abri a metodologia para me certificar de que não tinham cometido um erro. Não tinham. Quando você pede ao modelo de linguagem mais avançado do mundo para planejar uma viagem que respeite um orçamento, conecte voos a hotéis a restaurantes e não viole a lógica temporal básica — ele falha 99,4% das vezes.

Quando o GPT-4 foi solicitado a planejar viagens com restrições do mundo real, ele teve sucesso 0,6% das vezes. Um agente neuro-simbólico resolvendo o mesmo problema obteve 97%.

O sistema que obteve 97% não usou um modelo mais inteligente. Ele usou uma arquitetura fundamentalmente diferente — em que o LLM traduzia a solicitação do usuário em dados estruturados, e então um solucionador determinístico fazia o planejamento de verdade. O LLM era o tradutor. O código era o cérebro.

Aquele benchmark não apenas validou nossa frustração. Ele nos deu um projeto.

Por Que Seu Agente de IA Continua Falhando?

Aqui está o que ninguém na corrida do ouro dos "agentes de IA" quer falar: LLMs não raciocinam. Eles preveem.

Quando o GPT-4 "decide" chamar uma API de busca, ele não está executando lógica. Ele está prevendo o próximo token estatisticamente mais provável com base em padrões de seus dados de treinamento. Em uma conversa, essa previsão costuma ser boa o suficiente. Em um fluxo de trabalho de API de dez etapas em que cada etapa depende da saída exata da anterior? É um desastre.

Comecei a chamar isso de problema da Cadeia de Probabilidade. Suponha que seu LLM acerte cada etapa 90% das vezes — uma estimativa generosa para uso complexo de ferramentas. Aqui está a matemática:

• 1 etapa: 90% de sucesso
• 5 etapas: ~59% de sucesso
• 10 etapas: ~34% de sucesso

Um fluxo de trabalho de reserva de voo — buscar, filtrar, selecionar, precificar, coletar dados do passageiro, criar PNR, validar, pagar, emitir bilhete — rotineiramente ultrapassa dez etapas. Com 34% de sucesso teórico, você não está construindo software. Você está construindo uma máquina caça-níqueis.

E 34% é o teto. O desempenho no mundo real é pior por causa de dois fenômenos que ficávamos enfrentando em produção.

A Cascata de Alucinação

O primeiro é o que chamo de Cascata de Alucinação. Em uma arquitetura encadeada, a saída da Etapa 2 se torna a entrada da Etapa 3. Se o LLM comete um erro sutil no início — lendo o horário de chegada de um voo como 14h em vez de 2h — esse erro não é detectado. Ele se propaga. O agente reserva o check-in de um hotel para o dia errado com base no horário alucinado. A API do GDS não conhece a intenção do agente, apenas sua entrada, então processa a solicitação com sucesso. O agente vê uma resposta 200 OK e reforça seu próprio erro.

Você acaba com um rastro de execução "bem-sucedido" que produz um resultado catastrófico no mundo real. O agente acha que mandou bem. O cliente chega ao aeroporto e descobre o contrário.

O segundo fenômeno é a Deriva de Contexto. À medida que o agente avança por um plano de várias etapas, a janela de contexto se enche de dados intermediários — resultados de busca, respostas de API, mensagens do usuário. O mecanismo de atenção do modelo se dilui cada vez mais entre todos esses tokens. Na Etapa 10, ele efetivamente "esqueceu" a restrição de orçamento que identificou corretamente na Etapa 2. As pontuações de atenção, governadas pela função softmax, se diluem entre tokens irrelevantes demais.

Vi isso acontecer ao vivo durante uma demonstração para um possível parceiro. O agente encontrou um hotel dentro do orçamento na Etapa 3. Na Etapa 8, ao selecionar um restaurante, havia perdido completamente o controle do orçamento restante. Ele recomendou um lugar que teria estourado o limite de gastos do usuário em 40%. O parceiro se virou para mim e disse: "Então ele simplesmente... esquece?"

É. Ele simplesmente esquece.

O Que Acontece Quando a IA Encontra um Mainframe?

Para realmente entender por que precisávamos de uma abordagem diferente, você precisa entender como é trabalhar com os Sistemas de Distribuição Global.

Amadeus, Sabre, Travelport — esses são a espinha dorsal das viagens aéreas globais. Foram projetados na era dos mainframes e se comportam como tal. Uma reserva de voo não é uma única chamada de API. É uma máquina de estados finitos com uma sequência precisa de operações que não pode ser reordenada, pulada ou aproximada.

Você se autentica e obtém um token de sessão. Esse token deve ser passado em todo cabeçalho subsequente — se o LLM o "esquece" ou aluc­ina um novo, todo o contexto da transação se perde. Depois você busca voos, e o GDS retorna enormes cargas JSON aninhadas — muitas vezes mais de 50KB — contendo códigos de base tarifária, modelos de bagagem, referências de trecho. O LLM precisa extrair um offerId específico dessa carga para prosseguir. Mas LLMs são compressores com perdas. Eles resumem. Eles truncam. Eles "prestativamente" normalizam formatos de dados que o GDS exige que sejam exatos, até o byte.

Certa noite, passamos quatro horas depurando uma falha de reserva. O LLM havia "corrigido" um código de base tarifária — trocou uma letra minúscula por maiúscula, porque isso parecia mais "certo" para um modelo treinado em texto em inglês. O GDS rejeitou com um erro enigmático: ERR 1209 - SEQUENCE ERROR. Sem explicação. Sem sugestão. Apenas uma parede.

LLMs são compressores com perdas. Quando transferem dados entre chamadas de API, eles "autocorrigem" e "normalizam" de maneiras que quebram a integridade criptográfica que os sistemas corporativos exigem.

E quando o GDS retorna um erro como UC (Unable to Confirm), o LLM não tem ideia do que fazer. Ele foi treinado para ser prestativo, então interpreta o erro como uma falha momentânea e repete exatamente a mesma solicitação. De novo. E de novo. Vimos agentes queimarem milhares de tokens e atingirem limites de taxa da API, presos no que passamos a chamar de "Loop da Morte" — batendo repetidamente contra uma parede que não conseguiam entender.

A Noite em Que Invertemos a Arquitetura

O ponto de virada veio durante uma discussão.

Estávamos com três meses de projeto. Meu líder de engenharia queria continuar melhorando os prompts — mensagens de sistema mais longas, mais exemplos, instruções de cadeia de pensamento. "Estamos tão perto", ele repetia. "Se a gente só estruturar melhor o prompt para a etapa de criação do PNR..."

Abri nossos logs. Na semana anterior, tivemos 47 tentativas de reserva fracassadas em nosso ambiente de teste. Onze foram o Loop da Morte. Nove foram códigos de aeroporto alucinados. Seis foram o LLM tentando efetivar um PNR antes de adicionar o campo obrigatório "Received From" — um erro de sequência que nenhuma quantidade de prompting parecia corrigir, porque o modelo não tinha nenhum conceito inerente de ordenação temporal além do que havia absorvido dos dados de treinamento.

"Não estamos perto", eu disse. "Estamos no teto. A arquitetura é o problema."

Naquela semana, reescrevemos tudo. Paramos de pedir ao LLM para orquestrar. Paramos de deixá-lo decidir qual etapa vinha em seguida. Paramos de alimentá-lo com respostas brutas do GDS na esperança de que ele extraísse os campos certos.

Em vez disso, construímos um grafo.

Para o detalhamento técnico completo do que construímos e por quê, escrevi um artigo de pesquisa detalhado que aprofunda a arquitetura.

Como a IA Neuro-Simbólica Realmente Funciona?

A ideia central é enganosamente simples: o fluxo de controle não é uma tarefa de linguagem.

Decidir o que fazer em seguida em um processo de negócios rígido não deveria ser uma questão de previsão de tokens. Deveria ser uma questão de lógica condicional. A decisão de "pedir pagamento" só deveria ser acionada se "o voo estiver selecionado" E "o preço estiver confirmado". Isso é uma condição booleana, não uma sugestão probabilística.

Dividimos nosso sistema em duas camadas:

O LLM tornou-se a camada de interface — o tradutor. Ele interpreta a linguagem natural do usuário ("Quero um voo de manhã para Dehradun, não muito caro") em dados estruturados: {origin: "DEL", destination: "DED", date: "2024-03-15", time_preference: "morning", budget: "economy"}. É nisso que os LLMs são genuinamente excelentes: entender a bagunçada intenção humana.

O grafo tornou-se a camada de execução — o gerente. Ele recebe esses dados estruturados e executa a lógica de negócios usando código determinístico. Nós codificados manualmente. Esquemas de estado tipados. Arestas condicionais que inspecionam variáveis, não vibrações.

Usamos o LangGraph para construir isso, porque ele fornece as primitivas de que você precisa: um esquema de estado compartilhado (apoiado por um banco de dados, não por um histórico de chat), nós que são apenas funções Python e arestas condicionais que roteiam com base em valores reais de variáveis.

O LLM deveria ser o trabalhador — extraindo dados, resumindo texto, formatando JSON — enquanto o gerente deveria ser um software codificado manualmente. Essa inversão de controle é a característica definidora de sistemas agênticos robustos.

Em nossa arquitetura, o LLM literalmente não pode pular etapas. É fisicamente impossível para o sistema tentar uma reserva antes que a variável selected_offer_id seja preenchida no estado. Não porque dissemos ao LLM "não faça isso" em um prompt, mas porque a aresta do grafo não será acionada. É como tentar dirigir através de uma parede — o código simplesmente não permite.

Como É o Sistema de Verdade?

Deixe-me guiá-lo pelo que acontece quando alguém diz "Reserve um voo de Mumbai para Londres na próxima terça-feira."

Primeiro, um nó Coletor — alimentado por um LLM — interpreta essa frase em campos estruturados. Ele usa geração guiada (JSON Mode) para produzir um esquema específico. Um validador em Python verifica se os códigos de aeroporto são reais. "Londres" é ambíguo — Heathrow ou Gatwick? — então o grafo roteia para um nó de desambiguação. O LLM não adivinha. Ele pergunta.

Uma vez que temos critérios de busca validados, um nó Recuperador chama a API da Amadeus. Isso é código puro. Nenhum LLM envolvido. A resposta volta, é armazenada em cache no estado, e só então um nó Resumidor — um LLM — converte os cinco melhores resultados em uma mensagem legível por humanos. Mas ele é estritamente restrito: só pode exibir dados presentes no JSON em cache. Não pode inventar vantagens nem alterar preços.

O usuário escolhe uma opção. Um nó Seletor resolve "o segundo" para o hash específico do offer_id. Um nó Guardião verifica as regras de negócio — isto está dentro da política corporativa? A companhia aérea está na lista negra? Se houver uma violação, o grafo suspende. Ele persiste seu estado no banco de dados, envia uma solicitação de aprovação a um gerente e aguarda. Horas depois, quando o gerente clica em "Aprovar", o grafo recarrega o estado exato e retoma no nó de reserva.

Por fim, um nó Transacionador executa a sequência de criação do PNR — trechos, dados do passageiro, precificação, efetivação — exatamente na ordem que o GDS exige. Se o GDS retornar um aviso de mudança de preço (comum em viagens), o nó interrompe e pede que o usuário confirme. Ele não reserva automaticamente pela tarifa mais alta.

Cada transição de nó é registrada. Cada decisão é rastreável. Um auditor pode ler o log de execução e entender exatamente por que o sistema reservou um voo específico — não interpretando uma bagunça de tokens, mas lendo um registro estruturado: Node:Gatekeeper | Input: Price=1200 | Rule: Policy_Limit=1000 | Output: REJECT_NEED_APPROVAL.

Escrevi sobre a arquitetura completa, incluindo os diagramas interativos, na versão interativa do whitepaper.

Isto Não É Só... Engenharia de Software Comum?

As pessoas me perguntam isso o tempo todo. "Então você está dizendo que devíamos escrever código em vez de usar IA? Revolucionário."

Não. Estou dizendo que a indústria de IA ficou tão embriagada com a mágica dos modelos de linguagem que esqueceu os últimos sessenta anos da ciência da computação. Máquinas de estados, esquemas tipados, ramificação condicional, integridade transacional — esses não são conceitos ultrapassados. São a razão pela qual seu banco não transfere dinheiro por acidente para a conta errada.

A abordagem neuro-simbólica não é anti-IA. É pró-arquitetura. Usamos LLMs de forma agressiva — para interpretação de intenção, para desambiguação, para sumarização, para lidar com o problema genuinamente difícil de entender o que um humano quer dizer quando digita algo ambíguo. Mas não deixamos o LLM tocar no volante quando o carro está na estrada.

Você pode construir um chatbot que fala sobre fazer o trabalho, ou pode arquitetar um agente que faz o trabalho. A diferença é o grafo.

Há também um argumento de custo que me surpreendeu. Agentes puramente baseados em LLM são caros — não porque a inferência seja custosa por chamada, mas por causa dos loops de falha. Quando um agente fica preso tentando repetir um erro do GDS alucinando novos parâmetros, ele queima milhares de tokens antes de expirar. Uma única sessão travada pode custar de US$ 5 a US$ 10 em créditos de API. Nossos tratadores de erro codificados manualmente capturam essas falhas com custo zero de tokens. E como enviamos ao LLM apenas os 5 campos relevantes de uma resposta de 50KB do GDS em vez da coisa toda, reduzimos o uso da janela de contexto em cerca de 90%.

Mas os Modelos Não Vão Ficar Bons o Suficiente Eventualmente?

Talvez. Genuinamente não sei se o GPT-6 ou o GPT-7 serão confiáveis o suficiente para orquestrar fluxos de trabalho de API de dez etapas sem guardrails. Mas sei de duas coisas.

Primeiro, mesmo que os modelos melhorem drasticamente, o problema da Cadeia de Probabilidade é matemático, não tecnológico. Se seu modelo for 99% confiável por etapa — uma conquista extraordinária — um fluxo de trabalho de dez etapas ainda falha 10% das vezes. Para transações corporativas, isso ainda é inaceitável. O grafo elimina isso completamente porque o roteamento não é probabilístico.

Segundo, esperar que os modelos melhorem é um luxo que a maioria das empresas não tem. Elas precisam de agentes que funcionem agora, que sejam auditáveis agora, que cumpram os requisitos de transparência do EU AI Act agora. A abordagem neuro-simbólica não aposta no futuro. Ela se baseia em princípios de engenharia comprovados, usando ao mesmo tempo as melhores capacidades de IA disponíveis hoje.

A Arquitetura É o Produto

Estive em salas suficientes com investidores e compradores corporativos para saber que a indústria de IA está começando a despertar. A pergunta está mudando de "Quem tem o modelo mais inteligente?" para "Quem tem o sistema mais robusto?" As demonstrações que deslumbram em uma palestra de conferência — aquelas em que um agente reserva um voo impecavelmente em um ambiente controlado — são baratas. O que é caro, e o que importa, é construir algo que funcione na décima milésima solicitação com a mesma confiabilidade da primeira.

Estamos entrando em uma era em que a diferenciação não será o modelo. Será o grafo. O esquema de estado. Os tratadores de erro. As arestas condicionais. A engenharia de software chata, rigorosa e determinística que envolve a mágica probabilística e a impede de incendiar a casa.

A mágica nunca esteve no prompt. Ela sempre esteve na arquitetura.