Resumo Técnico: TraceGraph – Paisagens de Decisão Compartilhadas para Diagnóstico e Melhoria de Trajetórias de Agentes

1. Declaração do Problema

Os benchmarks de agentes atuais registram cada vez mais trajetórias de interação ricas e intercaladas (pensamentos, chamadas de ferramentas, feedback do ambiente). No entanto, as práticas de avaliação tipicamente colapsam esses processos complexos em uma única métrica escalar (por exemplo, taxa de sucesso/falha ou pontuação de recompensa). Embora tais pontuações classifiquem os sistemas, elas obscurecem a dinâmica subjacente do processo: falham em revelar como os modelos navegam pelos espaços de tarefas, onde eles divergem em estratégia, ou se evitam regiões de falha ou se recuperam delas.

O desafio central é a falta de um sistema de coordenadas compartilhado para comparar trajetórias entre diferentes modelos. Os estados dos agentes são longos, ramificados e específicos de cada benchmark, misturando escolhas de ferramentas, pistas de arquivos e evidências parciais. Sem alinhamento, é difícil determinar se o Modelo A atingiu um estado análogo ao do Modelo B, se evitou a mesma região de falha ou se recuperou por uma rota diferente. Os métodos existentes frequentemente inspecionam trajetórias individuais isoladamente ou dependem de pontuações agregadas que ocultam a diversidade do processo.

2. Metodologia: O Framework TraceGraph

O TraceGraph é um framework baseado em grafos que transforma rollouts de agentes agrupados em uma paisagem de decisão compartilhada. Ele opera em três estágios, construindo um mapa independente de modelo do espaço de tarefas antes de analisar comportamentos específicos de modelos.

Estágio 1: Construção da Paisagem Compartilhada

O framework ingere etapas de ação–observação de múltiplos modelos e tarefas.

• Codificação: Cada etapa $i$ é codificada como um conjunto esparso de chaves observáveis $K_i$, incluindo tipos de ferramentas/ações, classes de comandos, padrões de observação (ex: rastros de erro), pistas de arquivos e fases temporais. Para tarefas de busca, chaves específicas para domínios de URL e novidade de consulta são adicionadas.
• Similaridade e Construção de Grafo: A similaridade pareada é calculada usando uma sobreposição de Jaccard ponderada por IDF sobre os conjuntos de chaves. Chaves raras e informativas (ex: padrões específicos de traceback) pesam mais do que as genéricas.
• Topologia: Um grafo mutual-$k$NN é construído sobre todos os passos agrupados. Este grafo é decomposto em Componentes Biconexos (BCCs) e pontos de articulação (portões).
  • BCCs agrupam passos com similaridade mútua densa, representando estados de agentes compartilhados grosseiros.
  • Pontos de articulação marcam transições de estratégia ou fase onde um rollout pode ramificar-se em continuações qualitativamente diferentes.
• Independência de Modelo: A identidade do modelo é excluída da assinatura e da construção do grafo. A paisagem é definida unicamente pelo espaço de estados observável.

Estágio 2: Sobreposições Informadas pelo Resultado

Uma vez fixada a estrutura do grafo, o framework sobrepõe dados de resultado para identificar "núcleos produtivos" e "regiões de armadilha".

• Difusão de Recompensa: Para cada bloco BCC, uma recompensa suavizada por Laplace é atribuída com base nos resultados terminais dos rollouts que visitam esse bloco. Esta recompensa é então difundida através do grafo de quociente do bloco para suavizar o ruído local.
• Definição de Região:
  • Núcleo Produtivo ($C_t$): Quantis de alta positividade do campo de recompensa difundido.
  • Regiões de Armadilha ($B_t$): Quantis de baixa negatividade do campo de recompensa difundido.
• Estas sobreposições são descritivas, localizando onde o tráfego de alto e baixo resultado se concentra, em vez de prever resultados para execuções não vistas.

Estágio de 3: Sumarização de Eventos de Rollout

A trajetória de cada modelo é sumarizada por três eventos discretos definidos sobre as sobreposições de núcleo/armadilha:

1. Acesso ($A_r$): O rollout intersectou o núcleo produtivo?
2. Exposição à Armadilha ($E_r$): O rollout intersectou uma região de armadilha?
3. Reparo ($R_r$): O rollout visitou uma armadilha e, subsequentemente, atingiu um núcleo?

Análise: Perfis de Oferta e Demanda
O TraceGraph gera dois perfis descritivos:

• Oferta do Modelo: A média centrada na tarefa dos eventos de um modelo em relação à média do modelo. Isso revela o "estilo de navegação" de um modelo (ex: alto acesso/alto reparo vs. conservador/raso).
• Demanda do Benchmark: O contraste ponderado pela recompensa entre o tráfego de alto e baixo resultado. Isso revela o que um benchmark específico recompensa (ex: evitar armadilhas vs. recuperação).

3. Principais Contribuições

1. Framework TraceGraph: Um método para construir grafos de tarefas independentes de modelo a partir de rollouts agrupados e sobrepor regiões informadas pelo resultado para criar uma paisagem de decisão compartilhada.
2. Perfis de Processo Compactos: Uma demonstração de que, através de cinco divisões de benchmark (7.329 registros, 427 tarefas, 5 modelos), os eventos de Acesso, Exposição à Armadilha e Reparo separam estilos de navegação de modelos e demandas de benchmarks que pontuações agregadas colapsam.
3. Pipeline de Recuperação Guiado pelo TraceGraph: Uma aplicação prática no SWE-bench onde regiões de armadilha derivadas do grafo servem como gatilhos de tempo de execução. Quando um agente ao vivo entra em uma região de armadilha histórica, uma política de recuperação leve é ativada.

4. Resultados Experimentais

Insights Diagnósticos

• Diversidade de Modelos: Pontuações agregadas frequentemente ocultam diferenças de processo. Por exemplo, em uma paisagem compartilhada, o DeepSeek-V3.2 exibe um estilo de "alto acesso, alto reparo", enquanto o Qwen3-Next mostra um estilo de "baixo acesso, baixo reparo" (navegação conservadora e rasa).
• Heterogeneidade de Benchmark: Benchmarks impõem diferentes demandas de processo:
  • $\tau^2$-bench, MCPBench, TerminalBench: Fortemente avessos a armadilhas (altos resultados correlacionam-se com evitar regiões de baixo resultado).
  • SWE-bench: Fortemente demandantes de reparo (altos resultados correlacionam-se com recuperar-se de estados do tipo armadilha após a falha inicial).
  • Busca (Search): Recompensa o acesso a evidências produtivas com recuperação ocasional.

Experimento de Recuperação (SWE-bench)

Os autores instanciaram um pipeline de bifurcação de prefixo ciente de armadilhas em instâncias do SWE-bench Verified (500 no total).

• Mecanismo: Um detector dispara quando um rollout ao vivo corresponde a uma assinatura de armadilha canonicalizada. Ao disparar, o agente continua a partir do mesmo estado sob três políticas:
  1. Baseline: Continuação padrão ($T=0.6$).
  2. Hot: Aumento da diversidade de amostragem ($T=0.9$).
  3. Note: Uma nota de diagnóstico conservadora e fundamentada em evidências anexada ao contexto (sem patches de ouro).
• Resultados:
  • No subconjunto disparado por provedor ($n=616$), a melhor política agrupada (Hot) elevou a taxa de resolução de 40,4% para 43,5% (+3,1 pp, $p=0,016$).
  • No subconjunto de disparo comum ($n=288$), a política Hot elevou a taxa de 41,0% para 44,8% (+3,8 pp, $p=0,045$).
  • Especificidade de Provedor: O componente de recuperação ativo variou por provedor. O Qwen3.6-35B-A3B beneficiou-se mais da nota de diagnóstico, enquanto o GLM-5.1 e o DeepSeek-V4-Pro beneficiaram-se mais do aumento de temperatura.

5. Significância e Alegações

O artigo posiciona o TraceGraph não como um novo escore escalar ou um preditor cego de sucesso, mas como um vocabulário de processo para avaliação de agentes.

• Poder Descritivo: Revela o que um benchmark testa (ex: esquiva vs. recuperação) e onde os modelos divergem em uma paisagem compartilhada.
• Orientação Acionável: Demonstra que armadilhas derivadas de grafos podem guiar intervenções downstream. Ao identificar regiões de falha históricas, o framework permite políticas de recuperação direcionadas que melhoram as taxas de resolução de tarefas sem exigir informações de oráculo ou re-treinamento total.
• Modéstia: Os autores enfatizam que o pipeline de recuperação é uma intervenção local em um subconjunto específico do SWE-bench e não é reivindicado como um mecanismo universal de reparo de agentes. O framework é um instrumento analítico para explicar a concentração de tráfego, não um controlador para todos os comportamentos de agentes.

Em resumo, o TraceGraph desloca o foco de "quantas tarefas o agente resolveu?" para "como o agente navegou pela paisagem da tarefa, e onde ele ficou preso ou se recuperou?", fornecendo uma base estrutural para compreender e melhorar trajetórias de agentes.