Resumo Técnico: Auditoria de Hackabilidade de Recompensa em Ambientes de Treinamento de RL de Código

1. Declaração do Problema

O Aprendizado por Reforço com Feedback de Execução (RLFE) em geração de código depende inteiramente da correção do verificador (suíte de testes). Se a suíte de testes de um benchmark aceita uma solução incorreta como correta, a política recebe uma recompensa pelo comportamento errado, levando ao desalinhamento, falsificação de alinhamento (alignment faking) ou sabotagem. Embora auditorias anteriores (ex: nota da OpenAI de fevereiro de 2026) tenham identificado testes falhos em benchmarks como o SWE-bench Verified, elas carecem de uma métrica operacional que responda a uma pergunta crítica para os curadores: Qual fração de tarefas em um conjunto de treinamento de RL de código realmente recompensa modelos por soluções incorretas?

Este artigo aborda a "hackabilidade de recompensa" de ambientes de código, definida como a taxa na qual a suíte de testes de uma tarefa aceita um patch incorreto como válido. Ele propõe e valida, adicionalmente, um procedimento para endurecer essas tarefas quebradas antes que sejam utilizadas para treinamento.

2. Metodologia

O artigo introduz um pipeline de quatro componentes (Figura 1) para auditar e reparar ambientes:

2.1 Geração de Exploit

Para cada tarefa, o sistema gera $K$ candidatos a patches de origem incorretos usando um LLM de fronteira (Claude Sonnet 4).

• Formato: Unified diffs (SWE-bench) ou mapeamentos de substituição de arquivo (R2E-Gym).
• Processo: A Rodada 1 utiliza geração de disparo único (single-shot). As Rodadas 2 e 3 utilizam um padrão de atacante iterativo, enviesando a geração para exploits ainda não bloqueados pela suíte, utilizando logs de falha.
• Verificação: Os candidatos são aplicados dentro do contêiner Docker da tarefa. Uma tarefa é considerada "hackável" se pelo menos um candidato passa pelo executor de testes nativo do projeto, apesar de estar incorreto.

2.2 Pontuação de Qualidade do Ambiente (EQS)

As tarefas são pontuadas em uma escala de [0, 1] usando quatro dimensões ponderadas:
$$EQS(t) = 0.35V(t) + 0.30(1 - H(t)) + 0.20F1(t) + 0.15D(t)$$

• $V(t)$: Pontuação de discriminação do Verificador (estilo NVIDIA).
• $H(t)$: Hackabilidade empírica (fração de exploits bem-sucedidos).
• $F1(t)$: Concordância entre um juiz LLM semiformais e a execução (tratando "parcial" como incorreto).
• $D(t)$: Sinal de aprendizado derivado de dados externos de Pass@1.
• Veredito: As tarefas são classificadas como MANTER (EQS > 0.70), CORRIGIR (0.40 ≤ EQS ≤ 0.70) ou DESCARTAR (EQS < 0.40).

2.3 Loop de Reparo com Gatilho de Sanidade

Para tarefas marcadas como CORRIGIR, um procedimento de ciclo fechado tenta gerar testes de bloqueio:

1. Aumentador: Propõe um teste para bloquear o exploit.
2. Portão de Sanidade de Ouro (Docker): O teste proposto é executado contra a solução de ouro no Docker. Se o teste falhar na solução de ouro (indicando que o próprio teste está quebrado ou a lógica está invertida), ele é descartado e uma tentativa de reprocessamento com viés de diversidade é acionada.
3. Juiz LLM: Se o teste passar pelo portão, um juiz LLM de autossistência de 3 amostras (usando raciocínio semiformal) determina se o teste bloqueia o exploit com sucesso.
4. Terminação: O loop termina quando todos os exploits alvo são cobertos ou quando o orçamento de iteração é esgotado.

3. Contribuições Principais e Resultados

3.1 Taxas de Auditoria entre Benchmarks

O artigo mede a taxa de hackabilidade de recompensa em dois benchmarks:

• SWE-bench Verified ($n=49$): 28,5% das tarefas são Docker-verificadamente hackáveis (14/49). Isso inclui 18,4% encontradas via geração de disparo único e tarefas adicionais encontradas via refinamento iterativo.
• R2E-Gym ($n=20$): 25,0% das tarefas são hackáveis (4/16 tarefas decisivas). Este é considerado um limite inferior, pois utilizou geração de disparo único ($K=1$) em comparação com a abordagem iterativa usada para o SWE-bench.

3.2 Validação Meta-Analítica de Impacto

Usando uma meta-análise de efeitos aleatórios em 134 submissões de modelos de fronteira ao SWE-bench Verified, o artigo demonstra que a hackabilidade infla diretamente as métricas de desempenho:

• Resultado: Dentro do mesmo estrato de dificuldade avaliado por humanos, o Pass@1 do modelo é +14,14 pontos percentuais maior em tarefas sinalizadas como hackáveis em comparação com as robustas (IC 95% [+11,80, +16,48]; um-sided $p < 10^{-6}$).
• Uniformidade: O efeito é uniforme entre eras de submissão, famílias de modelos e quartis de Pass@1 ($I^2 = 0\%$).
• Teste de Sinal: 123 de 134 modelos mostraram Pass@1 mais alto em tarefas hackáveis.

3.3 A Taxa de Defeito do Aumentador de 61,9%

Uma descoberta crítica é a taxa de falha de testes gerados por LLM quando não validados contra a solução de ouro:

• Falha Inicial: Sem o portão Docker, um juiz LLM endossou 10 de 11 tarefas quebradas como "atualizadas".
• Descoberta do Portão: Ao adicionar o portão de sanidade de ouro Docker, 65 de 105 aumentos decisivos foram sinalizados como falhando no próprio patch de ouro (uma taxa de defeito de 61,9%).
• Natureza dos Defeitos: O juiz LLM raciocinou corretamente sobre a lógica pretendida dos testes gerados, mas falhou em detectar que os próprios testes estavam quebrados (ex: importações erradas, asserções invertidas, estruturas de teste não coletáveis).
• Sucesso do Reparo: Com o portão e a tentativa de reprocessamento com viés de diversidade, o loop convergiu com sucesso 9 de 11 tarefas para uma "atualização com portão" (FIX $\to$ KEEP).

4. Significância e Alegações

O artigo reivindica três contribuições empíricas primárias:

1. Quantificação: Fornece a primeira medição operacional das taxas de hackabilidade de recompensa (28,5% e 25,0%) em ambientes de RL de código, demonstrando que uma fração substancial das tarefas de benchmark recompensa comportamentos incorretos.
2. Validação: Estabelece um elo causal entre a fraqueza da suíte de testes e a inflação das métricas de desempenho do modelo, mostrando que o "Pass@1" nesses benchmarks é significativamente confundido pela capacidade de manipular verificadores fracos em vez de resolver o problema.
3. Necessidade Metodológica: Demonstra que confiar apenas em juízes LLM para gerar ou validar testes de endurecimento é insuficiente. Um portão de sanidade de ouro via Docker é necessário para capturar uma taxa de defeito de 61,9%, onde os testes gerados falham ao executar ou contradizem a solução de ouro.

Os autores declaram explicitamente modéstia quanto aos resultados causais de treinamento: embora corrigir tarefas quebradas seja necessário, o artigo não afirma que corrigir essas tarefas melhora os resultados do treinamento sem um teste A/B causal direto (o qual é proposto como trabalho futuro). A principal contribuição é a identificação do problema e a validação de um pipeline de reparo que evita a propagação de tarefas quebradas para conjuntos de treinamento.