Resumo Técnico: Self-Play Ancorado para Reparação de Código

Formulação do Problema

A reparação de código é uma capacidade crítica para modelos de linguagem (LMs) em fluxos de trabalho de programação, exigindo que o modelo gere um programa fixo que passe em testes unitários dado um programa com erro e o conjunto de testes. Embora dados de reparação do mundo real de alta qualidade sejam limitados, trabalhos recentes exploraram a escalabilidade da supervisão usando LMs para gerar tarefas de correção de bugs. Os autores investigam o self-play gerador–reparador (generator–fixer self-play), um cenário onde um único modelo é treinado via aprendizado por reforço para alternar entre gerar bugs (editando código correto) e repará-los.

O desafio central identificado é o desvio de distribuição (distribution drift). Embora os testes unitários verifiquem efetivamente a correção funcional (passar/falhar), eles não verificam o realismo do bug. No self-play padrão, o gerador pode derivar para a produção de bugs "difíceis, mas irreais" — edições que falham nos testes, mas não se assemelham a erros encontrados na prática (ex: código escrito por humanos ou código de LM editado por humanos). Consequentemente, embora o reparador melhore em relação à distribuição sintética do gerador, seu desempenho frequentemente degrada em fontes de bugs realistas.

Metodologia

1. Self-Play Gerador–Reparador

Os autores instanciam um loop de self-play onde uma única política $\pi_\theta$ desempenha dois papéis:

• Gerador (G): Edita uma implementação de referência correta $c^\star$ para produzir um programa com bug $b$.
• Reparador (F): Repara $b$ dado o descritor da tarefa e o feedback do teste unitário $o(x, b)$.

Recompensas:

• Recompensa do Reparador: Recompensa binária baseada em se o programa reparado $y$ passa em todos os testes unitários ($v(x, y) = 1$).
• Recompensa do Gerador: Projetada para incentivar bugs que sejam válidos (executáveis e que falhem nos testes) e de dificuldade intermediária. A dificuldade é estimada pela taxa de reparação de $K$ tentativas de reparação independentes. Bugs que são muito fáceis (sempre reparados) ou muito difíceis (nunca reparados) são penalizados para manter um currículo adaptativo.

O sistema é otimizado usando GRPO (Group Relative Policy Optimization).

2. O Modo de Falha: Desvio de Distribuição

Experimentos mostram que o self-play padrão exibe dinâmicas coevolutivas onde o gerador produz bugs cada vez mais difíceis para um reparador fixo, e o reparador melhora nesses bugs específicos. No entanto, quando avaliado em fontes realistas (bugs escritos por humanos, editados por humanos e bugs gerados por LM), o desempenho regride. O reparador sofre overfitting às edições idiossincráticas e irreais geradas pelo loop de self-play.

3. Solução Proposta: Self-Play Ancorado (ASP)

Para mitigar o desvio, os autores propõem o Self-Play Ancorado (ASP), que ancora o processo de self-play a um pequeno conjunto de referência de bugs ($D_{ref}$) amostrados de fontes realistas. O ASP emprega dois mecanismos complementares:

• Mistura de Referência para Treinamento do Reparador: Durante o treinamento, uma fração dos bugs de entrada do reparador é substituída por bugs do conjunto de referência ($D_{ref}$). Isso garante que o reparador seja continuamente exposto a padrões de bugs realistas, evitando o overfitting à distribuição sintética evolutiva do gerador. O gerador não é atualizado nessas episódios misturados para evitar problemas de off-policy.
• Modelagem do Gerador Guiada por Similaridade: Uma recompensa auxiliar é adicionada ao objetivo do gerador para direcioná-lo a produzir bugs similares ao conjunto de referência.
  • O gerador computa o diff unificado entre a solução de referência e o bug gerado.
  • Este diff é incorporado (embedded) usando um modelo de embedding de código (voyage-code-3).
  • A recompensa é baseada na similaridade de cosseno entre o embedding do bug gerado e os $k$-vizinhos mais próximos no pool de referência.
  • Uma recompensa de similaridade centrada é usada: $\delta_t(b) = \text{sim}_{01}(b) - B_t$, onde $B_t$ é uma linha de base móvel. Isso molda o gerador para edições semelhantes às de referência sem sobrecarregar a recompensa primária do teste unitário.

Principais Contribuições

1. Formulação do Problema: Os autores formalizam o self-play gerador–reparador para reparação de código e identificam o desvio de distribuição como um modo de falha primário ao depender exclusivamente de recompensas de testes unitários.
2. Benchmark (BUGSOURCEBENCH): Eles introduzem e lançam o BUGSOURCEBENCH, um benchmark controlado para avaliar a generalização de reparação entre fontes. Ele abrange quatro fontes de bugs enquanto mantém constantes as tarefas subjacentes, especificações e testes unitários:
   • HUMAN: Bugs introduzidos por anotadores em soluções de referência escritas por humanos.
   • HUMAN-EDITED LM: Bugs em código gerado por LM que foram subsequentemente editados por humanos.
   • LM ERRORS (QWEN-7B): Erros de um modelo de código mais fraco.
   • LM ERRORS (GPT-OSS-20B): Erros de um modelo de código mais forte.
3. Método (ASP): Eles propõem o Self-Play Ancorado, que combina o direcionamento por similaridade de embedding para geração de bugs com o treinamento do reparador com mistura de referência para estabilizar o self-play e melhorar a generalização.

Resultados Experimentais

Os autores avaliam o ASP contra um Modelo Base, um baseline de Reparador-Apenas (gerador congelado, reparador treinado) e o Self-Play padrão no BUGSOURCEBENCH.

• Desempenho Geral: O ASP alcança a maior taxa média de reparação em todas as fontes de bugs. Ele melhora a taxa média de reparação em +7,0 pontos percentuais (absolutos) e 24% (relativos) sobre o self-play padrão.
• Generalização entre Fontes:
  • Bugs Gerados por LM: O ASP mostra ganhos massivos, melhorando as taxas de reparação em +11 pp (100% relativo) em média para bugs gerados por LM.
  • Bugs de Origem Humana: O ASP melhora as taxas de reparação em +3,4 pp (7,1% relativo) em bugs escritos por humanos, enquanto o self-play padrão frequentemente degrada o desempenho nessas fontes.
• Estudos de Ablação:
  • Tanto a mistura de referência quanto a modelagem por similaridade contribuem para o desempenho, mas sua combinação produz os maiores ganhos, sugerindo que eles abordam modos de falha complementares.
  • O método é eficiente em termos de amostra, mostrando melhorias com apenas 50 exemplos de referência.
  • O uso de um pool de referência misto (cobrindo todas as fontes de bugs) produz o melhor desempenho geral em comparação com pools restritos a uma única fonte.
• Robustez: Os ganhos do ASP são robustos através de diferentes modelos de embedding (voyage-code-3 vs. CodeBERT), modelos base (Qwen-7B vs. DeepSeek-6.7B) e distribuições de tarefas (transferência para DebugBench).

Significância e Alegações

O artigo afirma que o self-play baseado apenas em testes unitários é insuficiente para escalar a reparação de código porque carece de um sinal explícito de realismo, levando ao desvio de distribuição. Ao introduzir o Self-Play Ancorado, os autores demonstram que um pequeno conjunto de referência pode ancorar efetivamente o processo de geração, permitindo que o modelo se beneficie do currículo adaptativo do self-play enquanto mantém a robustez a fontes de bugs realistas.

O trabalho destaca que as capacidades de reparação são distintas das de geração de código; modelos que resolvem tarefas do zero podem falhar ao reparar soluções existentes, e vice-versa. O método proposto oferece um caminho para construir ferramentas de programação automatizadas mais confiáveis que generalizam através das fontes heterogêneas de erros encontradas na programação assistida por LM no mundo real.

Limitações: Os autores observam que seus experimentos focam na reparação de funções Python com feedback de teste unitário. O cenário não captura desafios de nível de repositório (falhas multi-arquivo, gerenciamento de dependências) ou uso de ferramentas de longo horizonte. Além disso, o sinal de realismo depende de um modelo de embedding congelado e um pool de referência finito, sugerindo que trabalhos futuros poderiam explorar críticos aprendidos ou recompensas baseadas em preferência.