Resumo Técnico: Engenharia de Recompensa para Aprendizado por Reforço em Tarefas de Software

Declaração do Problema

O Aprendizado por Reforço (RL - Reinforcement Learning) tornou-se um paradigma dominante para tarefas de engenharia de software (SE), incluindo geração de código, sumarização, reparo, teste e otimização. Embora avanços recentes em Grandes Modelos de Linguagem (LLMs) e agentes autônomos tenham demonstrado desempenho de estado da arte em benchmarks como HumanEval, MBPP e SWE-bench, um desafio fundamental permanece: projetar sinais de recompensa eficazes para tarefas de software.

Ao contrário de domínios como jogos, onde as recompensas são números escalares bem definidos, as tarefas de software envolvem múltiplos objetivos, muitas vezes conflitantes (corretude, eficiência, segurança, legibilidade), que são difíceis de quantificar. Um trecho de código pode compilar mas falhar nos testes, passar nos testes mas conter vulnerabilidades, ou ser funcionalmente correto, mas ilegível. As abordagens existentes frequentemente abordam essas preocupações de forma isolada (por exemplo, baseadas em execução para corretude, baseadas em similaridade para correspondência de referências), mas combinar esses sinais introduz desafios relativos à ponderação de recompensas, descasamento de escala e conflitos de objetivos. Além disso, as escolhas de design de recompensa estão intimamente acopladas ao design do ambiente (representação de estado, granularidade de ação), embora essas relações ainda sejam pouco compreendidas. Atualmente, não existe um levantamento sistemático que unifique essas abordagens dispersas para fornecer um panorama abrangente da engenharia de recompensa para RL em software.

Metodologia

Este artigo apresenta o primeiro levantamento sistemático e abrangente sobre o design de recompensa e ambiente para RL em engenharia de software. Os autores realizaram uma revisão da literatura de mais de 50 artigos relacionados publicados entre 2018 e 2025 em conferências de engenharia de software, aprendizado de máquina e processamento de linguagem natural.

A metodologia envolve a organização da literatura ao longo de três dimensões complementares para criar uma taxonomia:

1. Fonte de Recompensa: Como o sinal é derivado.
   • Baseada em Execução: Obtida através da execução de artefatos (compilação, testes unitários, fuzzing).
   • Baseada em Referência: Comparação contra artefatos de verdade fundamental (métricas de similaridade como BLEU, CodeBLEU, similaridade de AST).
   • Baseada em Modelo: Derivada de modelos de recompensa aprendidos ou analisadores externos (modelos de preferência, julgamentos alinhados com humanos).
2. Granularidade da Recompensa: O nível no qual a recompensa é atribuída.
   • Varia desde o nível de token/linha até o nível de função, programa e trajetória (sequência).
3. Estratégia de Agregação: Como sinais heterogêneos são combinados.
   • Inclui sinais únicos, combinações ponderadas e estratégias de mistura aprendidas.

O levantamento categoriza os trabalhos em cinco domínios primários de tarefas de SE: Geração de Código, Compreensão de Código, Manutenção de Código, Segurança de Código e Teste de Código.

Contribuições Principais

A principal contribuição do artigo é o estabelecimento de uma taxonomia unificada e a identificação de padrões de design recorrentes em diversos domínios de SE.

1. Taxonomia de Esquemas de Recompensa

Os autores classificam os métodos existentes em categorias específicas com base nas dimensões acima. Por exemplo:

• NL2Code (Geração de Código): Depende predominantemente de recompensas baseadas em execução (taxas de compilação/passagem de testes), frequentemente aumentadas com sinais de similaridade ou preferência para mitigar a esparsidade. Métodos como o CodeRL utilizam recompensas binárias esparsas, enquanto abordagens baseadas em PRM introduzem Modelos de Recompensa de Processo aprendidos para fornecer feedback denso em nível de passo.
• Preenchimento de Código (Code Completion): Frequentemente depende de similaridade baseada em referência (BLEU, Distância de Edição) ou sinais de preferência aprendidos (DPO), pois a execução é esparsa ou dispendiosa para preenchimentos parciais.
• Manutenção de Código (Resolução de Problemas): Combina múltiplos sinais (similaridade, execução, recuperação, preferência) para guiar edições de múltiplos passos. SWE-RL e SWE-Gym exemplificam abordagens híbridas que equilibram a corretude baseada em testes com a escalabilidade.
• Segurança e Teste: A detecção de vulnerabilidades frequentemente utiliza recompensas densas baseadas em referência devido à inviabilidade de executar código para verificar segurança em escala. O fuzzing combina sinais de cobertura derivados de execução com resultados de oráculos.

2. Identificação de Padrões de Design

O levantamento identifica três padrões recorrentes no design de recompensa:

• (P1) Recompensas de Resultado Verificáveis e Baseadas em Ferramentas: As recompensas mais confiáveis são ancoradas em oráculos externos (compilação, testes unitários). Estas permanecem como o "âncora" para tarefas onde a corretude funcional é o objetivo primário.
• (P2) Recompensas Híbridas: Para reduzir a fragilidade, muitos trabalhos combinam sinais de execução (para corretude) com sinais de similaridade (para densidade/aprendizado). Este padrão de "corretude + proximidade" é comum quando as recompensas puras de execução são muito esparsas.
• (P3) Observabilidade de Granularidade de Rastreamento: A granularidade da recompensa alinha-se com a disponibilidade de feedback intermediário. Quando sinais intermediários confiáveis existem (ex: feedback do compilador, pontuações de PRM), os métodos migram para recompensas de nível de passo mais densas. Quando apenas a corretude final é significativa, as recompensas permanecem esparsas e terminais.

3. Desafios e Recomendações

O artigo delineia desafios críticos e fornece recomendações para trabalhos futuros:

• Desalinhamento de Recompensa: Recompensas de proxy (ex: similaridade) podem ser fáceis de otimizar, mas falham em melhorar o comportamento a jusante (downstream). Os autores recomendam priorizar recompensas de métricas de jusante quando medidas de avaliação claras existem.

• Feedback Esparso e Caro: Recompensas baseadas em ferramentas incorrem em altos custos de avaliação. Estratégias de mitigação incluem cache, avaliação incremental e aprendizado de currículo.

• Sensibilidade ao Peso: Somas ponderadas ingênuas de recompensas heterogêneas são instáveis. Trabalhos futuros devem reportar estratégias de normalização e realizar ablação de sensibilidade de peso, especialmente quando os objetivos genuinamente competem.

Resultados e Descobertas

O levantamento não apresenta novos resultados experimentais, mas sintetiza descobertas da literatura revisada para revelar o estado atual do campo:

• Dominância da Execução: Para tarefas onde o código deve ser executado (geração, reparo, teste), as recompensas baseadas em execução são a principal fonte de supervisão.
• Mudança para Modelos Híbridos: Recompensas puras de execução são frequentemente esparsas demais para um treinamento estável, levando a uma tendência de aumentá-las com críticos aprendidos, modelos de preferência ou métricas de similaridade.
• Nuances Específicas de Tarefa:
  • Recuperação de Código (Code Retrieval) favorece métricas centradas em recuperação (MRR, NDCG) em vez de similaridade.
  • Refatoração de Código requer recompensas de múltiplas ferramentas (validade sintática, compilação, detecção de intenção) porque a execução sozinha é insuficiente.
  • Reparo de Vulnerabilidades frequentemente depende de recompensas densas de similaridade e de preferência julgadas por modelos, devido à falta de testes confiáveis e à multiplicidade de patches válidos.

Significância

O artigo afirma sua significância como o primeiro levantamento sistemático a reunir abordagens dispersas de engenharia de recompensa em tarefas de software. Ao estruturar a literatura ao longo de origem, granularidade e agregação, ele fornece aos praticantes um framework unificado para:

1. Compreender como diferentes formulações de recompensa se comparam.
2. Determinar quando usar recompensas baseadas em execução versus recompensas aprendidas.
3. Analisar como as escolhas de design de ambiente interagem com a eficácia da recompensa.

Os autores posicionam este trabalho como um recurso fundamental para guiar o design de agentes de RL mais robustos para engenharia de software, abordando a lacuna onde levantamentos anteriores focavam na seleção de algoritmos ou domínios de aplicação, enquanto tratavam as funções de recompensa meramente como detalhes de implementação. O artigo conclui reconhecendo a rápida evolução do campo e comprometendo-se a manter um repositório de acompanhamento para rastrear novos desenvolvimentos.