Por que mais contexto pode produzir decisões piores

Parte I: Por que mais contexto pode produzir decisões piores

Um otimizador de rotas, mais de 1,4 milhão de estados rejeitados e a diferença entre um agente que responde e um sistema que pode ser depurado

O que este artigo cobre

• Por que uma janela de contexto maior não define a responsabilidade entre módulos.
• Como recusas preservadas revelaram a causa real dentro de cerca de 1,6 milhão de estados de rota rejeitados.
• Por que um módulo deve responder a uma pergunta e ter uma forma válida de recusar.
• Quando vários agentes ajudam e quando o custo de coordenação piora o resultado.

Durante uma semana, a gente continuou olhando pra economia.

O aplicativo tinha que coletar pedidos potenciais de veículos numa plataforma comercial de cargas, guardar as evidências numa base local, combinar pedidos compatíveis, montar rotas possíveis e verificar preço, receita bruta, receita por milha, capacidade do reboque, sequência de coletas, sequência de entregas e uma lista inteira de restrições operacionais.

O programa rodava. A base tinha resultados. A sessão ainda devolvia erro.

Então a gente analisava o código, mudava um cálculo, montava outra versão, rodava de novo, encontrava outro problema e repetia tudo. Cada pedaço de código, separado, quase sempre estava certo. O sistema não. Um módulo produzia um resultado válido, outro interpretava o estado de outra forma, e no fim o status dizia que nada útil tinha acontecido.

E a gente não estava usando modelo barato nem configuração barata de raciocínio. Pode acreditar, isso não salvou o projeto.

O projeto e a plataforma não são identificados de propósito. Alguns números operacionais foram arredondados para proteger o sistema original. A sequência dos acontecimentos e o mecanismo de engenharia continuam os mesmos.

O problema era a arquitetura.

O modelo caro continua vendo o problema errado

Existe uma tentação enorme quando você trabalha com agentes de IA. Você tem um projeto e uma lista de mudanças, então coloca tudo num prompt grande. Corrige a lógica da base, muda o ranking, atualiza o montador de rotas, revisa a economia, roda os testes, prepara a nova versão.

Pra que separar em módulos, commits, testes locais, transferências de estado e mais um ciclo de release? O agente consegue ler o repositório. Deixa ele trabalhar.

E ele trabalha. Escreve código bom, acha erro de sintaxe, conserta teste, muda arquivo rápido. Depois o projeto chega naquela parte em que uma decisão correta depende de outra decisão correta tomada em outro lugar.

É ali que começa o problema.

Num desenho inicial, a gente tinha mais de 8.000 linhas misturando SQL, busca, ranking, economia e ciclo de vida da sessão. Todo defeito sério na história do projeto morou naquela área. Não porque o arquivo tivesse passado por algum limite amaldiçoado. Ele continha decisões diferentes, cada uma com uma definição diferente de sucesso.

O agente que trabalhava ali tinha permissão demais e contexto demais. Ele via o pedido, a rota, a economia, o estado da busca, a base, o objetivo final. Parece útil. Na prática, isso empurrava o agente pra decisões que estavam fora da pergunta que ele deveria responder.

Quando isso acontece, o resultado fica difícil de reproduzir. O pedido sumiu porque a evidência estava ilegível, porque o reboque não comportava, porque a rota dava prejuízo, porque a busca já tinha enchido o reboque, ou porque o agente viu tudo isso e deu um palpite razoável?

"Razoável" é um péssimo código de falha.

Janela de contexto é capacidade, não atenção confiável

A pesquisa está ficando mais clara nesse ponto. Uma janela de contexto grande permite que o modelo receba mais tokens. Ela não garante que o modelo use cada token relevante com a mesma precisão.

O estudo de 2023 Lost in the Middle mostrou que modelos de linguagem muitas vezes tinham o melhor desempenho quando a informação relevante aparecia no começo ou no fim de uma entrada longa. Quando a mesma informação ficava no meio, o desempenho caía. Isso também aconteceu em modelos feitos para contextos longos.

O RULER, publicado em 2024, foi além da busca simples por uma agulha no palheiro. Ele testou recuperação, encadeamento em várias etapas, agregação e perguntas sobre contextos cada vez maiores. Modelos quase perfeitos no teste básico começaram a cair quando a entrada ficou mais longa, os distratores ficaram mais difíceis ou várias evidências tiveram que ser ligadas.

O NoLiMa, publicado na ICML em 2025, removeu a coincidência fácil de palavras entre a pergunta e a evidência. Foram testados doze modelos de contexto longo. Com 32 mil tokens, dez caíram abaixo da metade do bom resultado obtido no contexto curto. O GPT-4o foi de 99,3% no teste curto para 69,7% com 32 mil tokens.

Depois veio o preprint de 2025 Context Length Alone Hurts LLM Performance Despite Perfect Retrieval. Os autores testaram cinco modelos abertos e fechados em matemática, perguntas e código. O desempenho caiu entre 13,9% e 85% conforme a entrada crescia, mesmo quando a evidência correta já tinha sido recuperada. Eles trocaram o conteúdo irrelevante por espaços em branco, mascararam esse conteúdo e colocaram a evidência logo antes da pergunta. A queda continuou.

Esses trabalhos não provam que menos conhecimento deixa o modelo mais inteligente. Eles sustentam uma afirmação mais estreita e muito mais útil: a quantidade de texto que o modelo aceita é maior que a quantidade de texto que ele consegue usar com confiança em cada decisão.

É nessa diferença que começa a engenharia de agentes.

Um módulo, uma pergunta

A gente reorganizou o projeto em torno de uma regra simples:

Um módulo responde a uma pergunta. Se a pergunta não cabe numa frase, provavelmente são dois módulos.

O módulo de aceitação pergunta: este cartão está legível e é fisicamente admissível?

O módulo de economia pergunta: a rota já montada passa pelo limite de receita por milha?

Os dois tocam nos mesmos pedidos. Não são donos da mesma decisão.

Essa diferença importa. Numa execução capturada, o módulo de aceitação registrou resultados para mais de 15.000 cartões numa base de evidências selada. O agrupamento arredondado ficou assim:

cerca de 14.000  aceitos
cerca de    700  descrição do veículo não visível
cerca de    500  classe de veículo incompatível
cerca de    250  duplicata não preferida
cerca de    140  descrição de veículo incompatível
cerca de    100  tipo de veículo não visível
cerca de     60  localização não resolvida
cerca de uma dúzia  evidências inconsistentes
cerca de uma dúzia  quantidade acima da capacidade
menos de dez  quantidade de veículos ausente

Ele aceita um pedido de cerca de US$ 350 por quase 900 milhas. Isso dá perto de US$ 0,40 por milha e, sozinho, parece péssimo. O módulo de aceitação não liga. O lucro depende do que vai viajar junto com aquele veículo, e esse módulo não pode saber o que o reboque vai carregar depois.

A fronteira é limpa porque o módulo pode aceitar um pedido sem lucro e continuar certo.

Agora olha a quantidade de veículos. Esse número pode aparecer num título semântico, numa lista separada por barra, num prefixo explícito 2 Vehicles ou numa linha própria. O módulo compara essas fontes. Se elas entrarem em conflito, ele devolve partial. Ele é proibido de escolher qual fonte parece mais verdadeira.

Essa é a diferença entre um agente com responsabilidade limitada e um agente solto no projeto inteiro. O primeiro tem um lugar definido onde pode dizer "eu não sei". O segundo tende a entregar alguma resposta porque o sistema não criou um estado válido de recusa.

A semana em que a gente consertou o subsistema errado

O melhor exemplo veio depois, durante a busca de rotas.

A busca gerou perto de 1,6 milhão de estados candidatos rejeitados. Todo mundo desconfiou do modelo econômico. Fazia sentido. Um reboque com um veículo dava algo entre US$ 1,10 e US$ 1,60 por milha, enquanto o limite de liberação ficava perto de US$ 2,25.

A gente trabalhou uma semana na economia.

Depois agrupamos as recusas armazenadas pelo código de motivo:

mais de 1,4 milhão  trecho com ocupação única acima do limite
cerca de     153.000  progresso insuficiente até o destino
cerca de      22.000  candidatos demais a partir de um estado pai
cerca de       4.000  trecho com um veículo acima do limite
cerca de       3.500  trecho vazio acima do limite
menos de          10  taxa combinada abaixo do mínimo

A economia tinha rejeitado seis candidatos.

O problema real era geometria.

Um parâmetro confirmado do processamento limitava a cerca de 100 milhas qualquer trecho com exatamente um veículo no reboque. A regra parecia razoável: não atravesse metade do país com o reboque pela metade.

Só que a mesma regra cobria o deslocamento da primeira coleta até a segunda. Pra carregar o segundo veículo, o reboque precisa percorrer parte da rota com um veículo a bordo. A regra proibia exatamente a manobra que dava sentido a um reboque de dois veículos.

Uma segunda consulta confirmou tudo. Em menos de 200 estados analisados, a ocupação máxima era um. O reboque nunca ficou cheio. O módulo econômico não podia aprovar uma rota combinada porque a busca quase nunca deixava uma combinação existir.

Mudamos um parâmetro confirmado de cerca de 100 para cerca de 300 milhas. Nenhuma linha de código. No processamento seguinte, o reboque ficou cheio durante aproximadamente 87% das milhas da rota, e o candidato passou do limite de liberação.

Então apareceu outra regra: um trecho carregado tinha que ter cerca de 100 milhas, mas um segmento tinha aproximadamente 60. Esse limite vinha de uma versão antiga, antes de o aplicativo verificar a economia da rota completa. O motivo tinha desaparecido. O número ficou.

Depois de remover essa restrição antiga, o processamento seguinte liberou uma rota com vários pedidos, cerca de US$ 4.500 de receita e pouco menos de 2.000 milhas.

Um limite local tinha matado quase nove em cada dez estados candidatos. Ele parecia razoável, pertencia a outra premissa operacional e quebrava uma parte do sistema que parecia não ter nada a ver com ele.

A gente encontrou porque cada recusa continuava lá.

Eu já tinha visto a mesma coisa antes da IA

Numa fábrica de galvanização, um pedido grande pode levar a produção pra perto de um turno contínuo. O problema não é só a quantidade de peças. Peças diferentes exigem operações diferentes, o ritmo normal fica quebrado, as pessoas precisam interferir manualmente, e um bloqueio vai descendo pela linha.

Na limpeza industrial funciona igual. A equipe entra no local com uma janela de tempo definida. O produto de limpeza chega atrasado, o aspirador industrial não foi limpo, falta equipamento de proteção, e uma demora pequena passa pelo trabalho inteiro. Atraso vira dinheiro perdido.

O sistema quase nunca quebra porque ninguém sabe fazer uma operação isolada. Ele quebra na passagem, onde o estado de uma operação vira a entrada da próxima.

Aplicações com IA têm a mesma fraqueza. O modelo pode escrever cada função corretamente e ainda errar na passagem entre coleta, armazenamento, busca, ranking, economia e liberação. Mais inteligência dentro de uma etapa não conserta um contrato indefinido entre duas etapas.

Por que vários agentes às vezes ajudam e às vezes pioram tudo

Dividir o trabalho entre agentes pode ajudar por dois motivos. Cada agente recebe um contexto mais limpo, e trabalhos independentes podem acontecer em paralelo. Só que a tarefa precisa permitir essa separação.

A Anthropic informou que seu sistema multiagente de pesquisa superou uma configuração de agente único em 90,2% numa avaliação interna, principalmente em pesquisas amplas, que podiam ser divididas em direções independentes. O mesmo relatório diz que o uso de tokens, sozinho, explicou 80% da variação de desempenho no BrowseComp. Vários agentes ajudaram em parte porque o sistema gastou mais tokens de inferência e fez mais chamadas de ferramentas, não porque um comitê ficou sábio por mágica. Relatório de engenharia da Anthropic

O trabalho de 2025 Why Do Multi-Agent LLM Systems Fail? analisou 1.642 rastros de execução de sete frameworks multiagente e identificou 14 modos de falha ligados ao desenho do sistema, alinhamento entre agentes, verificação e encerramento. Os autores encontraram taxas de falha entre 41% e 86,7% nos sistemas analisados. Mudar o prompt ajudou em alguns casos. Mudar a topologia e a verificação do sistema teve mais peso.

O aviso quantitativo mais claro veio do preprint de 2025 do Google e do relatório de janeiro de 2026, Towards a Science of Scaling Agent Systems. A equipe testou 180 configurações em quatro benchmarks e três famílias de modelos. Uma coordenação centralizada melhorou uma tarefa financeira paralelizável em 80,9%. No planejamento sequencial, todas as arquiteturas multiagente pioraram o desempenho, entre 39% e 70%. Agentes independentes amplificaram erros em 17,2 vezes. Um coordenador central reduziu essa amplificação para 4,4 vezes.

A regra é simples. Use vários agentes quando o trabalho tiver ramos independentes e um ponto claro de síntese. Mantenha uma cadeia única de raciocínio quando cada decisão depender diretamente da anterior.

Mais agentes não são uma arquitetura.

Uma forma melhor de dizer a ideia

Eu comecei com a intuição de que a IA funciona melhor num ambiente limitado porque um ambiente limitado contém conhecimento limitado.

Hoje eu diria de outra forma.

Um agente trabalha com mais confiabilidade quando o ambiente contém conhecimento suficiente para uma decisão, limites explícitos sobre o que ele pode mudar, uma forma válida de recusar e evidência que continua existindo depois da falha.

O pedido aceito importa. O recusado também. A rota aprovada importa. Os mais de 1,4 milhão de candidatos mortos por uma única regra importam mais, porque mostram onde o sistema está mentindo pra si mesmo.

Um agente limitado não comete necessariamente menos erros.

Os erros dele podem ser encontrados.

Lições práticas

1. Defina a pergunta do módulo em uma frase.
2. Dê ao módulo estados explícitos de aceitação, recusa e resultado parcial.
3. Preserve decisões e recusas num registro de evidências append-only.
4. Agrupe as falhas por motivo antes de mudar o subsistema que parece culpado.
5. Use um coordenador central quando as etapas seguintes dependerem diretamente das decisões anteriores.

Em resumo

• Capacidade de contexto não é atenção confiável.
• Responsabilidade limitada torna as falhas rastreáveis.
• Recusas preservadas podem revelar mais que resultados bem-sucedidos.
• Mais agentes ajudam somente quando o trabalho pode ser separado e sintetizado com clareza.