Janela de contexto não sabe o que ainda é verdade: benchmark mede o custo do contexto obsoleto

A janela de contexto lembra do passado — mas não sabe o que ainda é verdade

Uma janela de contexto pode estar tecnicamente completa e, ainda assim, descrever um mundo que não existe mais. É essa a premissa de um novo benchmark determinístico criado pelo pesquisador Emmimal P. Alexander, publicado no Towards Data Science, que mede o custo de agentes de IA agirem sobre contexto obsoleto.

O problema é sutil porque não parece uma falha de memória. Nada foi esquecido, nenhum texto foi cortado, nenhum log sumiu. O fato que levou à decisão errada estava lá na janela o tempo todo — ele só deixou de ser verdade três minutos antes, e nada no sistema checava essa mudança. “Não é perda de contexto. É contexto que permanece tempo demais depois de deixar de ser válido”, resume o autor.

Presença não é o mesmo que validade

Uma janela de contexto é essencialmente uma transcrição: registra o que aconteceu, em ordem, e conta ao agente sobre o passado. Uma camada de validade responde a uma pergunta diferente — se aquela informação ainda é segura para usar agora.

O benchmark atribui a cada fato um de quatro estados, em vez de um simples verdadeiro/falso: ACTIVE (a evidência atual sustenta o fato), STALE (já foi verdade, mas há dados mais novos), SUPERSEDED (uma observação mais recente o substituiu) e UNKNOWN (não há evidência suficiente). O quarto estado é o que permite ao sistema uma terceira escolha: verificar antes de agir, em vez de tratar toda dúvida como falha.

Há ainda uma distinção que o autor chama de crucial: invalidez factual versus invalidez operacional. Um preço de passagem que muda de R$ 420 para R$ 610 é factualmente inválido. Já um banco de dados com exatamente 10.000 registros continua factualmente verdadeiro se o número não mudar — mas se o banco sai do ar, aquele número se torna operacionalmente inútil. Um carimbo de tempo não resolve isso, porque a quebra aconteceu em outro ponto do grafo de dependências.

Dois executores, um mesmo trabalho

O experimento é 100% Python puro, sem APIs e sem LLMs — uma escolha deliberada para isolar o mecanismo de rastreamento de estado do ruído de qualidade de modelo. Dois executores determinísticos fazem exatamente o mesmo trabalho: o Baseline segue executando o plano até a ação falhar; o Validity-Aware verifica o status de uma dependência antes de cada passo e replaneja imediatamente se o dado estiver superseded.

Os resultados, medidos em Pre-Failure Work (passos executados depois que uma dependência quebra, mas antes de o sistema perceber), foram consistentes. Em uma cadeia de quatro passos, o baseline gastou 9 passos e fez 2 de trabalho condenado; o executor ciente de validade gastou 6 passos e zero trabalho condenado.

O que a varredura de 96 configurações revelou

A hipótese inicial do autor era de que o formato do grafo de dependências — cadeia, árvore larga, árvore profunda — determinaria o desperdício. Uma varredura de 96 configurações derrubou essa intuição: em todos os casos, Baseline PFW = total de nós afetados menos 1. O que importa não é a forma, mas quantos passos dependem do fato quebrado.

A descoberta mais útil veio do experimento de isolamento: conforme o plano cresce de 8 para 50 nós, o dano absoluto de um fato quebrado permanece fixo em 7 passos perdidos. O que encolhe é a fração do plano exposta à falha — de 100% para 16%. Quebrar o plano em ramos independentes não torna a falha mais barata, mas torna o sistema mais resiliente, porque o trabalho não relacionado permanece não relacionado.

Verificar nem sempre compensa

O autor também testou o custo da verificação quando ela não evita uma falha — um falso alarme. Nesse caso, o executor ciente de validade gastou um passo extra confirmando algo que estava perfeitamente bem, enquanto o baseline seguiu sem custo. A conclusão é honesta: checar atualidade nunca é grátis. A pergunta de engenharia não é “devo verificar?”, e sim se o custo esperado de agir sobre estado obsoleto supera o custo de checar.

O experimento mais decisivo foi a varredura de orçamento: com folga, os dois executores concluem a tarefa. Mas com orçamento apertado (de 6 a 8 passos), o executor ciente de validade ainda termina — e o baseline fica sem espaço para se recuperar. É o ponto em que contexto obsoleto deixa de ser questão de eficiência e vira a diferença entre concluir ou não a tarefa.

Por que isso importa para quem constrói agentes

Ao contrário do que sugere a intuição, mais contexto não resolve esse problema — uma janela maior só dá mais companhia a um fato obsoleto. O que ajuda é uma ideia antiga de sistemas: invalidar estado quando ele deixa de ser seguro e detectar isso antes de agir, não depois da falha. Para agentes que executam planos de múltiplos passos com custo real — chamadas de ferramenta, gasto de API, efeitos colaterais irreversíveis — rastrear validade é o que separa uma tarefa concluída de uma tarefa fracassada sob orçamento limitado. O código completo do benchmark está disponível no repositório Emmimal/context-validity-benchmark.