Resumo Técnico: Estrutura de Exploração em Agentes de LLM para Localização de Mudanças em Múltiplos Arquivos

Declaração do Problema

Problemas de engenharia de software raramente envolvem mudanças em um único arquivo; resolver um bug frequentemente requer modificações em vários subsistemas (por exemplo, CLI, bibliotecas subjacentes, plugins e documentação). Os agentes de Large Language Model (LLM) atuais tipicamente empregam uma estratégia de exploração linear e sequencial, visitando um diretório ou arquivo por passo. Os autores postulam que essa abordagem linear é um desajuste estrutural para mudanças de múltiplos arquivos que abrangem diversos subsistemas. Se um agente esgota seu orçamento de passos ou tokens enquanto explora o primeiro subsistema, os subsistemas subsequentes que contêm os arquivos "gold" necessários podem nunca ser examinados.

O artigo aborda três questões centais de pesquisa:

1. A exploração linear é estruturalmente limitante para mudanças de múltiplos arquivos, ou modelos fortes podem compensar via melhor seleção de passos?
2. Conceder acesso bruto ao sistema de arquivos melhora a localização de forma confiável, ou introduz erros de navegação e sobre-predição?
3. Forçar a consulta multi-agente agressiva melhora o recall, ou injeta ruído de subsistemas irrelevantes?

Metodologia

Construção do Benchmark

O estudo utiliza um benchmark de sessão persistente derivado do SWE-BENCH PRO, focando no repositório ansible/ansible.

• Escopo: Três janelas temporais foram construídas: Maio–Novembro de 2020 (o conjunto curado original), Abril–Setembro de 2025 e Janeiro–Maio de 2026.
• Estabilidade: Todas as instâncias em uma janela estão ancoradas a um único commit base para garantir estado constante do repositório e custos de exploração constantes.
• Conjuntos Gold: Os autores comparam contra o conjunto gold curado do SWE-BENCH PRO (arquivos fonte selecionados manualmente) e um conjunto gold expandido baseado em PR (cada arquivo tocado pelo Pull Request de resolução, incluindo testes e changelogs).
• Métricas: As métricas primárias incluem Micro-F1, taxa de All-Gold (fração de instâncias onde todos os arquivos de verdade fundamental são preditos) e F1 macro por instância.

Sistemas Experimentais

Os autores comparam quatro famílias de sistemas de LLM, isolando a estrutura de exploração da capacidade do modelo base ao usar o mesmo modelo pequeno da classe Haiku para a maioria das variantes:

1. LLM Comum (Sem Acesso ao Repositório): Uma única chamada de API baseada apenas no conhecimento de pré-treinamento da estrutura do repositório.
2. Modelo de Linguagem Recursivo (RLM) de Agente Único: Um agente com um REPL Python persistente que permite acesso sequencial ao sistema de arquivos (ex: os.listdir, grep). Isso testa a eficácia da exploração sequencial sem especialização de domínio.
3. Sistema de Agente de Domínio (Proposto): Uma arquitetura multi-agente apresentando:
   • Inicialização: Um coordenador raiz explora o repositório para identificar áreas de manutenção coerentes (subsistemas como cli/, module_utils/, docs/) e gera agentes de domínio persistentes para cada um.
   • Tempo de Consulta (Query-Time): O coordenador despacha agentes de domínio relevantes em paralelo para explorar suas regiões atribuídas.
   • I/O Limitado: Arquivos grandes e listagens de diretórios são gerenciados em um ambiente programático; apenas prévias compactas ou intervalos de linhas específicos entram no contexto do LLM para evitar o esgotamento de tokens.
   • Ablações: As variantes incluem "no-spawn" (o registro está presente, mas não há despacho paralelo) e "nudged" (consulta agressiva forçada).
4. Baseline de CLI Externo: Utiliza o Codex 5.5 High, um modelo de fronteira muito maior, para estabelecer uma referência de limite superior.
5. Baseline BM25: Um sistema clássico de recuperação lexical varrendo $K$ de 1 a 30 para gerar um envelope de precisão-recall.

Contribuições e Descobertas Principais

1. A Estrutura de Exploração é um Fator Crítico

A abordagem de Agente de Domínio, que paraleliza a exploração ao longo dos subsistemas do repositório, atinge o Micro-F1 mais alto entre todos os modelos da classe Haiku por uma margem larga.

• No benchmark curado de 2020, o Agente de Domínio (Haika) atinge um Micro-F1 de 0.447, superando significativamente o LLM Comum (Haika) em 0.199 e o RLM de Agente Único (Haika) em 0.151.
• O sistema de Agente de Domínio é competitivo com o muito maior Codex 5.5 High (Micro-F1 0.422 no curado, 0.523 no baseado em PR), apesar de usar um modelo menor.
• Descoberta: A exploração linear (RLM) é estruturalmente limitante; a exploração paralela e com escopo de domínio é necessária para uma localização de múltiplos arquivos eficaz.

2. O Acesso Bruto ao Sistema de Arquivos Pode Degradar o Desempenho

Ao contrário da intuição de que mais acesso equivale a melhor desempenho, conceder a um único agente acesso bruto ao sistema de arquivos (RLM) degradou a localização em comparação com um LLM Comum ao usar o mesmo modelo Haiku.

• RLM (Haika): Micro-F1 0.151.
• LLM Comum (Haika): Micro-F1 0.199.
• Causa: O RLM tendeu a prever excessivamente arquivos de teste e navegar em hierarquias irrelevantes, esgotando orçamentos de contexto e introduzindo falsos positivos. O LLM Comum, baseando-se no conhecimento estrutural pré-treinado, foi mais conservador e preciso.

3. Consulta Forçada Não Ajuda

Forçar o coordenador a consultar mais agentes ("nudged" variant) não melhorou mensuravelmente o recall, mas aumentou significativamente os custos de tokens (de ~16M para ~25M de tokens).

• A geração indiscriminada introduziu ruído de subsistemas irrelevantes sem recuperar arquivos gold adicionais.
• Conclusão: O despacho adaptativo (consultando apenas domínios relevantes) é superior à consulta agressiva forçada.

4. O Gap de Coevolução da Documentação

Uma falha sistemática foi observada em todas as arquiteturas (incluindo o grande modelo Codex) em relação aos arquivos de documentação (docs/docsite/).

• Taxa de Erro (Miss Rate): Arquivos de documentação tiveram uma taxa de erro agregada de 73%, muito maior que os arquivos de código.
• Razão: As descrições de problemas frequentemente descrevem mudanças no comportamento do código fonte sem mencionar explicitamente a necessidade de atualizar a documentação. Esta é uma dependência latente (acoplamento lógico) que as políticas de exploração atuais não conseguem resolver porque o "sinal" está ausente do texto de entrada.

5. Generalização ao Longo do Tempo

Os resultados generalizam-se através das janelas temporais (2020, 2025, 2026).

• A abordagem de Agente de Domínio superou consistentemente outros baselines de modelos pequenos.
• Na janela de 2025 e 2026, a abordagem de Agente de Domínio até superou o Codex 5.5 High no conjunto gold "estreito" (apenas fonte), embora o Codex tenha mantido vantagem no conjunto "amplo" (baseado em PR) devido à sua tendência de prever conjuntos de arquivos mais amplos (incluindo testes).

Significância e Alegações

O artigo alega que a estrutura de exploração é um fator de segunda ordem que pode compensar a capacidade limitada do modelo. Ao reestruturar o agente para paralelizar a exploração ao longo dos subsistemas do repositório e utilizar I/O limitado, um modelo pequeno pode igualar ou exceder o desempenho de modelos de fronteira muito maiores em tarefas de localização de mudanças de múltiplos arquivos.

No entanto, os autores são modestos quanto às limitações:

• Exploração não é suficiente: Nenhuma arquitetura atual consegue recuperar arquivos de documentação de forma confiável porque o texto do problema carece dos sinais necessários. Isso requer uma mudança na política de roteamento (ex: despachar agentes de doc baseados em mudanças de fonte) em vez de uma melhor exploração.
• Acesso não é uma panaceia: O acesso bruto ao sistema de arquivos sem estratégias de exploração direcionadas pode prejudicar ativamente o desempenho ao amplificar ambiguidades de prompts e causar sobre-predição.
• Escopo: O estudo isola a localização de arquivos da geração de patches e execução de testes, o que significa que estas descobertas aplicam-se especificamente à fase de "onde mudar" da engenharia de software.

O trabalho estabelece que, para a localização de mudanças de múltiplos arquivos, o despacho de geração em paralelo com escopo de domínio é um padrão arquitetural superior à exploração sequencial linear, desde que o sistema evite o acesso bruto ao sistema de arquivos e gerencie os orçamentos de tokens através de I/O limitado.