Resumo Técnico: Libra: Treinando o Ambiente para Recuperação de Informação Agêntica

Declaração do Problema

A localização de código dentro de repositórios de software massivos é uma capacidade fundamental para agentes de codificação autônomos, correlacionando-se fortemente com as taxas de resolução de tarefas subsequentes. As abordagens existentes para melhorar o desempenho de agentes geralmente se dividem em duas categorias:

1. Centrada no Modelo: Ajuste fino (fine-tuning) do modelo de fundação subjacente com dados derivados do repositório. Esta abordagem prende o sistema a um modelo específico, podendo abdicar das capacidades de raciocínio superiores de LLMs comerciais de última geração.
2. Aumento de Ambiente Estático: Construção de índices estáticos (ex: resumos hierárquicos, índices reversos ou grafos de conhecimento) para auxiliar a recuperação. Embora sejam agnósticos ao modelo, esses índices são estáticos e carecem de mecanismos para se adaptar dinamicamente aos desafios de recuperação específicos de um agente ou para aproveitar dados de interação para melhoria contínua.

O campo carece atualmente de um framework agnóstico ao modelo e orientado por dados que possa evoluir ativamente as capacidades de recuperação de informação de um agente para um repositório específico.

Metodologia: O Framework Libra

O Libra introduz uma mudança de paradigma do indexamento estático para um índice de texto simples (plain-text) que evolui ativamente e é nativo ao repositório. O sistema emprega um framework de autoevolução impulsionado por um loop de otimização de LLM adversarial envolvendo três agentes congelados e um artefato de ambiente mutável: Libra Catalogs.

1. O Artefato Mutável: Libra Catalogs

O Libra constrói uma hierarquia de arquivos Markdown (chamados de "catálogos") colocados na raiz do repositório e dentro de diretórios de submódulos. Esses arquivos servem como índices navegáveis, codificando informações de roteamento do repositório. Diferente de embeddings ou grafos estáticos, esses catálogos são legíveis por humanos, editáveis por humanos e variáveis de estado mutáveis atualizadas pelo sistema.

2. Os Três Agentes Congelados

O loop de otimização utiliza três agentes distintos com pesos e prompts fixos:

• Prompter (Sintetizador de Dados): Gera pares de pergunta-resposta sintéticos. Ele amostra um fragmento de código aleatório $c$ do repositório e fabrica uma consulta em linguagem natural $q$ que seja respondível por $c$, com o caminho do arquivo alvo (gold file path) $p^*$ como a resposta. O Prompter é instruído a evitar identificadores exatos para forçar a busca semântica.
• Solver (Resolvido de Consultas): Representa o agente de codificação de downstream. Dada uma consulta $q$ e o estado atual do catálogo $K$, o Solver tenta localizar o caminho do arquivo correto $\hat{p}$ navegando pelo repositório usando apenas os catálogos como guia. Crucialmente, o Solver não tem acesso ao fragmento ou caminho alvo durante este processo.
• Healer (Otimizador de LLM): Funciona como o otimizador. Ele analisa o conjunto de falhas do Solver $F$ (onde $\hat{p} \neq p^*$) e reescreve os catálogos Markdown $K$ para reparar os sinais de roteamento. O Healer diagnostica se as falhas decorrem de lacunas de informação, ruído ou problemas estruturais no catálogo e aplica edições direcionadas.

3. O Loop de Otimização

O sistema opera em rodadas ($T$):

1. Fase de Teste: O Prompter gera um lote de consultas. O Solver tenta resolver as consultas usando os catáotes atuais. As falhas são agregadas em um conjunto de falhas $F$.
2. Fase de Cura (Healing): O Healer processa $F$ e atualiza os catálogos $K$ para minimizar erros de roteamento futuros.
   Este loop continua até a convergência, produzindo um conjunto de catálogos otimizados que servem como um índice persistente.

Principais Contribuições

• Treinamento de Ambiente: O artigo propõe treinar o ambiente (o índice) em vez do modelo, criando um artefato agnóstico ao modelo que melhora a recuperação sem realizar o ajuste fino dos pesos do LLM.
• Auto-melhoria Adversarial: O sistema utiliza um loop adversarial onde o Prompter cria consultas desafiadoras, o Solver expõe as fraquezas no índice atual e o Healer refina iterativamente a estrutura do índice com base nessas falhas.
• Índices de Texto Simples: Ao usar catálogos em Markdown em vez de embeddings vetoriais ou grafos complexos, o Libra oferece um índice interpretável, portátil e editável que se integra nativamente ao código-fonte.

Resultados Experimentais

Os autores avaliaram o Libra em 12 repositórios Python do conjunto de dados SWE-BENCH LITE.

• Melhoria Logarítmica: No repositório sympy, o treinamento em consultas sintéticas gerou melhorias contínuas e logarítmicas na precisão de localização de código. O sistema começou com 60,3% de precisão de arquivo (Passo 0) e atingiu 83,3% (Passo 85), superando as linhas de base (baselines) de última geração.
• Generalização para Tarefas do Mundo Real: Catálogos treinados inteiramente em dados sintéticos transferiram com sucesso suas capacidades de localização para tarefas reais de localização de bugs do SWE-BENCH LITE. O Solver treinado do Libra alcançou o maior desempenho (77,8% de File ACC em 5 turnos, 82,3% em 10 turnos) comparado ao LocAgent e RepoMem, apesar de usar um conjunto de ferramentas minimalista (apenas Bash e Read).
• Agnosticismo ao Modelo: Os catálogos otimizados atuaram como um recurso persistente que aumentou o desempenho de diferentes modelos de Solver (GPT-5-mini, GPT-5 e Gemini-2.5-Flash) sem retreinamento. O aumento de desempenho foi mais significativo para modelos mais fracos (ex: o Gemini-2.5-Flash ganhou +31,0 pontos percentuais).
• Efeito de Cura: A análise de instâncias individuais de teste mostrou que 54,3% das instâncias melhoraram das fases iniciais para as finais de treinamento, com uma razão de 3,3:1 de desempenho melhorado para degradado, demonstrando a capacidade do sistema de corrigir sistematicamente falhas de roteamento.

Significância e Alegações

O artigo afirma que o Libra demonstra que a otimização de índices baseados em texto via feedback de interação oferece uma alternativa viável e adaptável aos métodos de recuperação tradicionais.

As principais conclusões enfatizadas pelos autores incluem:

1. Mudança de Paradigma: Mudança de embeddings externos estáticos para um índice de texto simples que evolui ativamente e é nativo ao repositório.
2. Transferibilidade: Um sistema treinado inteiramente em suas próprias consultas sintéticas pode transferir com sucesso suas capacidades de roteamento aprendidas para resolver tarefas de engenharia de software do mundo real.
3. Custo e Portabilidade: A abordagem alcança um desempenho competitivo com baselines de última geração, oferecendo vantagens distintas em interpretabilidade (catálogos legíveis por humanos) e portabilidade (agnóstico ao modelo).

Os autores reconhecem limitações, observando a intensidade computacional do loop de otimização e a suposição atual de repositórios estáticos, deixando atualizações incrementais e síntese de consultas de múltiplos saltos (multi-hop) para trabalhos futuros. No entanto, eles afirmam que o framework consegue preencher a lacuna entre o aumento de ambiente estático e o ajuste fino específico do modelo.