🤖 machine learning

The Replay Gap: Static Evaluation of Model Switching in LLM Agents Scores the Wrong World

Este artigo demonstra que os métodos de avaliação baseados em replay estático falham fundamentalmente ao avaliar roteadores de agentes de LLM porque a substituição das saídas do modelo em trajetórias registradas ignora a divergência em cascata das ações subsequentes do agente, levando a métricas de desempenho enganosas que não refletem resultados do mundo real.

Autores originais: Ashritha Gonuguntla

Publicado 2026-08-11

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Ashritha Gonuguntla

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você é o capitão de uma nave espacial navegando por um campo de asteroides perigoso. Você tem uma frota de diferentes pilotos de IA: alguns são rápidos e baratos, mas cometem pequenos erros, enquanto outros são lentos, caros e incrivelmente precisos. Para economizar combustível, você decide trocar de piloto no meio da jornada com base no que está acontecendo agora. Se o caminho estiver livre, você usa o piloto barato; se um asteroide enorme aparecer, você muda para o especialista. Este é o sonho do "roteamento de agentes" no mundo dos Grandes Modelos de Linguagem (LLMs). Esses modelos são os cérebros por trás dos agentes de IA que podem escrever código, resolver problemas matemáticos ou jogar jogos ao tomar uma série de decisões. A grande questão para os engenheiros é: Como sabemos se nossa estratégia de troca de pilotos realmente funciona?

Tradicionalmente, os cientistas testam essas estratégias como um diretor de cinema revisando um roteiro. Eles analisam uma jornada registrada (uma "trajetória") onde um único piloto voou todo o caminho. Então, eles fingem: "E se tivéssemos trocado o piloto no passo 10?". Eles simplesmente colam as respostas registradas do novo piloto no roteiro antigo e veem se o final parece bom. Isso é chamado de "avaliação de replay". É barato, rápido e assume que, se mudarmos o piloto no passo 10, o resto da jornada da nave teria permanecido exatamente igual ao registro original. Mas, no mundo real, uma nave espacial é um loop fechado: a ação do piloto no passo 10 muda a visão no passo 11, o que muda a decisão no passo 12, e assim por diante. Se o novo piloto vir um campo de asteroides diferente devido à sua própria ação anterior, todo o roteiro muda. Este artigo faz uma pergunta simples e terrível: Nosso método de testar por "roteiro de filme" está, na verdade, medindo a realidade errada?

Os pesquisadores da Carnegie Mellon University decidiram parar de adivinhar e começar a testar. Em vez de editar um roteiro de filme, eles construíram uma máquina do tempo. Eles pegaram agentes de IA reais resolvendo problemas de engenharia de software e, em momentos específicos, "ramificaram" a linha do tempo. Eles criaram dois universos paralelos: um onde o piloto original continuou e outro onde trocaram por um modelo diferente. Crucialmente, eles não apenas colaram novas respostas na história antiga; eles deixaram o novo piloto realmente assumir o controle, interagir com o ambiente do computador e ver o que realmente aconteceu a seguir. Eles realizaram cerca de 900 desses experimentos paralelos para ver o quanto as histórias divergiam.

Os resultados foram um choque para o sistema. A suposição de que o resto da jornada permanece o mesmo estava completamente errada. Quando eles trocavam de modelo, o novo piloto não apenas assumia o caminho existente; ele reescrevia todo o futuro. Nos estágios iniciais de uma tarefa, trocar de modelos fazia com que o agente mudasse de ideia em 74% a 77% de sua próxima ação imediata. Quando os pesquisadores analisaram a jornada completa, o novo piloto havia reescrito de 61% a 94% de todos os passos que se seguiram à troca. Para colocar em perspectiva, se você trocasse um piloto em um videogame, o mundo do jogo mudaria tão drasticamente que o "roteiro" que você estava tentando ler estaria descrevendo um nível que não existe mais.

O estudo também descobriu que o método de "replay" é perigosamente cego ao sucesso. Em seus experimentos, eles observaram cinco momentos específicos onde trocar um piloto realmente mudou o resultado da missão — salvando uma tarefa que falharia ou perdendo uma que seria resolvida. O antigo método de "roteiro de filme" perdeu cada um desses momentos críticos. Ele previa falha quando o novo piloto realmente tinha sucesso, e previa sucesso quando o novo piloto falhava. O patch de código que o novo piloto realmente escreveu não se parecia em nada com o patch que o método de replay previu; eles eram essencialmente não relacionados.

Além disso, os pesquisadores descobriram que o "ruído" no sistema depende fortemente de como os modelos são executados. Mesmo usando exatamente o mesmo modelo duas vezes, os resultados nem sempre eram idênticos. Se o modelo fosse servido usando um tipo de compressão de hardware (FP8), as execuções de "controle" (onde nenhuma troca ocorreu) divergiam 90% das vezes. Mas com um método de compressão diferente (AWQ), as execuções permaneciam quase idênticas. Isso significa que até mesmo a linha de base para comparação é instável, tornando o método de "replay" ainda menos confiável.

O artigo conclui que a forma atual de testar o roteamento de IA está pontuando o mundo errado. O método de "replay" é como julgar um chef lendo uma receita que ele escreveu ontem, ignorando o fato de que os ingredientes na cozinha mudaram. Os autores sugerem que, para realmente entender como rotear agentes de IA, precisamos parar de pretender que o futuro é fixo e começar a testar executando os agentes em realidades paralelas e ramificadas. Eles disponibilizaram suas ferramentas e dados para que outros possam parar de adivinhar e começar a enxergar a maneira verdadeiramente caótica e fascinante como esses agentes de IA realmente se comportam quando as regras do jogo mudam.

Resumo Técnico: O Gap de Replay em Roteamento de Modelos Agênticos

Declaração do Problema
O roteamento de modelos para Grandes Modelos de Linguagem (LLMs) evoluiu da seleção de consultas de turno único para a tomada de decisão por etapa dentro de agentes multi-etapas (ex: engenharia de software, uso de ferramentas). As metodologias de avaliação atuais para esses "roteadores agênticos" dependem de replay estático: o registro de trajetórias geradas por um modelo base e a simulação da decisão de um roteador ao substituir a saída registrada de um modelo diferente em uma etapa específica, assumindo que o restante da trajetória permanece inalterado.

Este artigo argumenta que essa suposição é fundamentalmente falha para agentes. Diferente das consultas de turno único, as trajetórias de agentes formam um loop fechado, onde uma ação na etapa $k$ determina diretamente a observação na etapa $k+1$ . O replay estático trata implicitamente a trajetória como um loop aberto, ignorando que a troca de um modelo altera a distribuição de estados, levando a ações futuras divergentes. O artigo postula que os benchmarks baseados em replay "pontuam o mundo errado", pois os estados que eles avaliam contra nunca ocorrem de fato no cenário contrafactual.

Metodologia: Rollouts de Ramificação (Branching Rollouts)
Para medir a magnitude e a estrutura dessa divergência, o autor introduz um protocolo de rollout de ramificação que vai além do replay estático para a avaliação contrafactual:

Configuração: Os experimentos utilizam o scaffold mini-SWE-agent no conjunto de dados SWE-bench Verified. O ambiente é um loop ReAct minimalista apenas com bash, com um orçamento de 50 etapas e contexto de 28k tokens.
Modelos: Dois modelos são utilizados: um modelo pequeno (S: Qwen3-4B-Instruct, quantizado em FP8) e um modelo grande (L: Qwen3-14B, quantizado em AWQ). Ambos são servidos via vLLM com temperatura 0 em uma única GPU de 24GB.
Protocolo de Forking:
- Uma trajetória base é executada até a terminação.
- Em pontos de controle de fork (30% e 70% da extensão da trajetória), o processo ramifica-se em um novo container Docker.
- Fidelidade de Replay: O prefixo de ação pré-fork é reexecutado no novo container para garantir que o estado do ambiente corresponda à trajetória base (verificado com 99,99% de concordância no código de retorno).
- Semeio (Seeding): O histórico de mensagens é semeado com o prefixo registrado para que o modelo da ramificação veja exatamente o mesmo contexto.
- Braços (Arms): Cada ponto de fork gera dois braços: um braço de troca (swap arm) (trocando para o outro modelo) e um braço de controle do mesmo modelo (same-model control arm) (continuando com o modelo base). O braço de controle isola o ruído de amostragem, batching e replay de ambiente, permitindo que o autor atribua a divergência especificamente à troca de modelo.
Escala: O estudo compreende seis pares de execções (variando dificuldade e direção da troca), gerando aproximadamente 900 rollouts e 717 pares de ramificação pontuados.

Principais Contribuições

Metodologia: Um harness reproduzível para avaliação contrafactual de troca de modelo por etapa via ramificação ao vivo, pareado com controles do mesmo modelo para isolar o ruído.
Quantificação do Gap de Replay: Evidência empírica de que trocas de modelos causam divergência imediata e significativa, tornando o replay estático inválido.
Insights Estruturais: Caracterização de como a divergência depende da profundidade do fork (início vs. fim) e da direção da troca (upgrade vs. downgrade).
Auditoria de Determinismo: Uma demonstração de que o determinismo de "temperatura-0" é dependente de configuração, com algumas pilhas de serviço (FP8) introduzindo ruído significativo mesmo nos controles do mesmo modelo.

Principais Resultados

Divergência ao Nível de Ação: As trocas reescrevem de 61% a 94% das ações pós-fork. A distância de edição normalizada entre os braços de troca e os controles correspondentes varia de +0,25 a +0,66 (os ICs de 95% excluem o zero).
Divergência Imediata: 74–77% das trocas precoces divergem logo na primeira ação pós-fork, comparado a apenas 6–35% dos forks de controle.
Invalidade dos Estados de Replay: Para trocas precoces, um avaliador de replay estático pontuaria 92–97% das decisões pós-fork contra estados que nunca ocorrem (apenas 3–8% dos estados de replay permanecem válidos).
Inversões de Resultado (Outcome Flips): Todas as cinco inversões de resultado observadas (instâncias onde o status da solução mudou devido à troca) ocorreram exclusivamente nos braços de troca. Zero inversões ocorreram nos 359 forks de controle. Especificamente, upgrades resgataram instâncias não resolvidas, e um downgrade causou a perda da única instância resolvida. O replay estático falhou em prever qualquer um desses resultados relevantes para o sucesso.
Similaridade de Patch: Os patches previstos por um avaliador de replay de costura de log (log-stitching) tiveram uma similaridade de 0,00–0,11 com os patches reais produzidos pelo modelo trocado.
Piso de Ruído (Noise Floor): Mesmo os controles do mesmo modelo não são perfeitamente determinísticos. Os controles servidos por FP8 divergiram em 90–96% dos forks (distância de edição 0,49–0,67), enquanto os controles servidos por AWQ permaneceram quase idênticos (distância de edição 0,16–0,23).
Imposto de Thoroughness (Thoroughness Tax): Sob orçamentos apertados, o modelo mais forte (14B) esgotou seu orçamento de etapas sem submeter uma solução com mais frequência do que o modelo mais fraco (4B), sugerindo um "imposto de thoroughness" que roteadores conscientes de orçamento devem considerar.

Significância e Alegações
O artigo afirma que benchmarks de replay pontuam o mundo errado para o roteamento agêntico. A cegueira estrutural do replay estático impede a observação de inversões de resultado e a avaliação de decisões contra estados válidos.

Para Avaliação: O autor afirma que os benchmarks de roteador agêntico devem adotar avaliação ao vivo ou ramificada. Eles fornecem seu harness e dataset como um ponto de partida para validar estimadores off-policy (ex: amostragem de importância, estimadores doubly robust), que são propostos como correções necessárias para o deslocamento de distribuição.
Para Políticas de Roteamento: Os resultados sugerem que a posição e a direção do fork são características críticas: as transferções (handoffs) devem ocorrer tardiamente para downgrades (para herdar o trabalho concluído) e precocemente para upgrades (para capitalizar em decisões imediatas).
Modéstia: O autor afirma explicitamente que suas descobertas baseiam-se em um piloto controlado (um scaffold, stacks de quantização específicas, baixas taxas de resolução) e não pretendem demonstrar o ranking incorreto de ponta a ponta em "regimes competentes" ainda. Eles enquadram seu trabalho como o estabelecimento da invalidade dos inputs para a avaliação de replay, em vez de provar uma estratégia de roteamento específica como superior. O artigo conclui que o sinal do resultado (o replay está errado) é uniforme, mas a magnitude do erro em regimes de alto desempenho requer mais validação.

Mais como este