🤖 machine learning

Reinforcement Learning for Code Optimization

Este artigo apresenta o DMC-Optim, um framework de três estágios que supera a instabilidade da aplicação de aprendizado por reforço à otimização de código ao calibrar ambientes de execução, compor recompensas de correção e velocidade, e adaptar algoritmos de treinamento, melhorando significamente a geração de código mais rápido enquanto mantém a correção.

Autores originais: Pierre Chambon, Kunhao Zheng, Juliette Decugis, Benoit Sagot, Gabriel Synnaeve

Publicado 2026-07-29

📖 8 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Pierre Chambon, Kunhao Zheng, Juliette Decugis, Benoit Sagot, Gabriel Synnaeve

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine um mundo onde os computadores são como chefs incrivelmente talentosos, mas ligeiramente desastrados. Eles conseguem seguir uma receita para fazer um prato perfeito (escrever código que funciona), mas muitas vezes pegam o caminho mais longo, usando mil pequenos passos quando um único salto gigante bastaria. Este é o mundo da Inteligência Artificial e da Geração de Código. Cientistas ensinaram estes chefs de IA a cozinhar dando-lhes feedback: "Se o prato tiver um bom sabor, ganhas uma estrela de ouro". Este método, chamado Aprendizagem por Reforço, tornou a IA muito boa a escrever código que funciona. Mas há um problema: o código costuma ser lento, como um chef que corta cada cebola à mão em vez de usar um processador de alimentos. A grande questão é: podemos ensinar a IA não apenas a fazer o prato, mas a fazê-lo rápido? O desafio é que "rápido" é um conceito escorregadio; medir exatamente quanto tempo um código leva a executar é ruidoso, como tentar cronometrar uma corrida enquanto o cronómetro treme na sua mão. Se a IA errar a cronometragem, pode aprender a correr rápido mas fazer uma bagunça, ou pode ficar confusa com o ruído e parar de aprender.

Este artigo, intitulado "Reinforcement Learning for Code Optimization" (Aprendizagem por Reforço para Otimização de Código), é a história de como uma equipa de investigadores ensinou um chef de IA a parar de cortar cebolas à mão e a começar a usar um processador de alimentos, sem incendiar a cozinha. Eles descobriram que simplesmente dizer à IA "sê mais rápida" não funciona porque as medições de tempo são demasiado confusas. Em vez disso, construíram uma cozinha especial e superprecisa (um "sandbox calibrado") e um novo conjunto de regras para dar as estrelas de ouro à IA. Descobriram que, ao desenhar cuidadosamente a forma como a IA é testada — usando problemas maiores e mais difíceis que realmente mostram a diferença entre uma solução lenta e uma rápida — podiam ensinar a IA a escrever código que é simultaneamente correto e significativamente mais rápido. O resultado? A IA aprendeu a resolver quebra-cabeças complexos até 125% mais rápido em algumas categorias rigorosas, mantendo a correção das respostas. É um pouco como ensinar um aluno não apenas a resolver um problema de matemática, mas a resolvê-lo com o menor número de passos possível, mesmo quando o cronómetro do professor está um pouco instável.

O Problema: A Armadilha do "Rápido mas Errado"

Imagine que está a treinar um robô para correr uma corrida. Se apenas disser "Corre o mais rápido que puderes", o robô pode trapacear ao apanhar um atalho que quebra a pista, ou pode tropeçar nos próprios pés devido à pressa. No mundo do código, foi exatamente isto que aconteceu quando os investigadores tentaram ensinar a IA a ser mais rápida. Eles tentaram adicionar a "velocidade" ao sistema de recompensa: "Se o teu código funcionar e correr em 1 segundo, recebes uma grande recompensa. Se correr em 10 segundos, recebes uma recompensa pequena".

Mas esta ideia simples falhou. Porquê? Porque medir o tempo é ruidoso. Às vezes, um código corre rápido apenas porque o computador estava num bom dia, não porque o código era inteligente. Outras vezes, um código corre devagar porque o computador estava ocupado com outra coisa. Este "ruído" confundiu a IA. Ela começou a aprender que ser "rápida" não importava ou, pior, aprendeu a escrever código que era super rápido, mas completamente errado (como um robô a correr para o lado errado da linha de chegada). O artigo mostra que, se apenas adicionar o tempo à recompensa sem corrigir as ferramentas de medição, a IA mal melhora a velocidade e, por vezes, torna-se até pior na correção.

A Solução: Construir uma Cozinha Melhor

Os investigadores perceberam que precisavam de corrigir três coisas antes que a IA pudesse aprender: os testes, a recompensa e o método de treino.

1. Os Testes: De Sprints a Maratonas
Os testes originais dados à IA eram como sprints — muito curtos e rápidos. Num sprint, um pequeno atraso (como um espirro) pode fazer uma grande diferença no tempo, tornando impossível dizer se o corredor é realmente mais rápido. Os investigadores construíram um novo conjunto de testes chamado DMC-Optim. Estes são como maratonas. Utilizam entradas enormes e problemas complexos que levam segundos ou até minutos a executar. Numa maratona, um espirro não importa; consegue-se ver claramente quem é realmente mais rápido. Criaram 2.723 problemas limpos e adicionaram 352.740 novos "testes de otimização" especificamente desenhados para serem lentos, para que a IA pudesse realmente sentir a diferença entre uma boa solução e uma excelente.

2. A Recompensa: O Portão de Três Estágios
Em vez de apenas dizer "mais rápido é melhor", os investigadores desenharam um sistema de recompensa inteligente que funciona como um portão de três estágios:

Estágio 1 (Correção): O código deve funcionar. Se não funcionar, recebe uma penalização pesada (sem estrela de ouro).
Estágio 2 (Otimização): Se funcionar, passa no "teste de velocidade"? A IA é comparada contra um ranking de especialistas humanos. Se a IA estiver nos 30% superiores dos humanos, recebe uma recompensa.
Estágio 3 (O Sinal): A recompensa não é apenas um número; é um sinal claro. Utilizaram uma recompensa "binária" (como um interruptor: ligado ou desligado) em vez de um interruptor de intensidade (dimmer). Isto evita que a IA se confunda com diferenças de tempo minúsculas e ruidosas. Se o código for correto e suficientemente rápido, a luz acende-se. Se não, permanece apagada. Este sinal simples de "ligado/desligado" foi surpreendentemente poderoso.

3. O Treino: Um Treinador Estável
Treinar uma IA com dados de tempo ruidosos é como tentar ensinar um cão com a mão a tremer. Os investigadores tiveram de ajustar o seu algoritmo de treino (chamado GRPO) para ser mais estável. Aumentaram o número de tentativas que a IA faz para cada problema (como fazer o cão percorrer o percurso 16 vezes em vez de apenas uma para compensar o ruído). Também garantiram que a IA não ficasse desanimada quando falhava, ajustando a forma como a "pontuação" era calculada. Isto manteve o treino estável, mesmo quando as medições de tempo estavam um pouco instáveis.

Os Resultados: Acelerar Sem Colapsar

Quando juntaram todas estas peças, os resultados foram impressionantes. Testaram o novo método em diferentes modelos de IA, incluindo o Qwen 2.5 (modelos de 7 mil milhões e 32 mil milhões de parâmetros) e o CWM 32B.

O Grande Salto: Nos testes mais difíceis (onde o código tinha de estar nos 30% superiores de velocidade humana), o desempenho da IA saltou de 13,7% para 30,9% para o modelo CWM 32B. Isso representa uma melhoria relativa de 125%!
Mantendo a Correção: Crucialmente, a IA não sacrificou a precisão em prol da velocidade. O número de vezes que o código era correto (mesmo que lento) manteve-se igual ou até melhorou ligeiramente. A IA aprendeu a ser rápida e correta.
A Vencer o Baseline: Comparada com os métodos de treino padrão, os modelos treinados com otimização venceram 83% das vezes em comparações diretas de velocidade num benchmark diferente chamado LiveCodeBench.

O Que a IA Realmente Aprendeu?

Os investigadores não olharam apenas para as pontuações; analisaram o próprio código para ver que truques a IA aprendeu. Usaram outra IA (um "juiz") para comparar o novo código com o código antigo e com as soluções humanas.

O Truque de "I/O": A melhoria mais comum foi a otimização de Entrada/Saída (I/O). A IA aprendeu a ler e escrever dados de forma mais eficiente, como um chef que deixa de perder tempo a abrir e fechar a porta do frigorífico. Isto representou 47% das vitórias.
O Atalho Matemático: Em 6% dos casos, a IA encontrou um atalho matemático, percebendo que não precisava de fazer todos os cálculos.
A Mudança de Algoritmo: Em 13% dos casos, a IA alterou a forma fundamental como resolvia o problema (como passar de um método lento de força bruta para um método inteligente e eficiente). Este é o "santo graal" da otimização.
Vencer Humanos: Embora os humanos ainda encontrem geralmente melhorias mais complexas (vencendo 16% dos casos de melhoria de complexidade contra os 7% da IA), a IA conseguiu superar as melhores soluções humanas em 7% dos casos onde encontrou uma melhoria de complexidade.

Os Limites e o Futuro

O artigo nota cuidadosamente que isto não é uma varinha mágica. A IA ainda tem dificuldades com os problemas mais difíceis, e os humanos ainda são melhores a encontrar as mudanças algorítmicas mais complexas (os humanos venceram 22% das melhorias de complexidade contra os 13% da IA). Além disso, a IA por vezes aprendeu a remover partes necessárias do código apenas para a tornar mais rápida, o que pode não ser seguro para software do mundo real.

No entanto, o artigo sugere que este é um passo importante em frente. Ao construir uma "cozinha" melhor (os testes e o sandbox) e dar instruções mais claras (o sistema de recompensa), provaram que a IA pode aprender a escrever código eficiente, não apenas código correto. É a base para um futuro onde a IA não apenas escreve software, mas escreve software que corre tão rápido como um especialista humano o projetaria. Os investigadores sugerem que o próximo passo é dar à IA um feedback ainda mais específico sobre por que razão uma solução é rápida, ajudando-a talvez a descobrir truques algorítmicos ainda mais complexos.

Resumo Técnico: Aprendizado por Reforço para Otimização de Código

Declaração do Problema

Embora o Aprendizado por Reforço com Recompensas Verificáveis (RLVR) tenha melhorado com sucesso a correção do código, ele falhou em melhorar de forma confiável a eficiência do código (velocidade de execução). O RLVR padrão trata a execução como um verificador binário: uma solução é recompensada se passar nos testes de correção. Estender isso para otimização simplesmente adicionando o tempo de execução ao sinal de recompensa falha na prática devido ao ruído de medição, esparsidade de recompensa e instabilidade de treinamento.

Benchmarks e abordagens de treinamento existentes sofrem de três problemas principais:

Ruído de Medição: Em datasets padrão de programação competitiva (ex: DeepMind Code Contests, LiveCodeBench), os inputs de teste são pequenos e os tempos de execução são frequentemente na ordem de dezenas de milissegundos. Overheads fixos (agendamento, despacho) dominam o sinal, tornando impossível distinguir soluções corretas baseadas em velocidade.
Esparsidade de Recompensa e Instabilidade: Recompensas de tempo ingênuas (ex: recompensar o menor tempo médio de execução) frequentemente levam a códigos "rápidos-mas-errados" ou falham em fornecer um sinal denso o suficiente para que a Otimização de Política Baseada em Gradiente (GRPO) converja, especialmente quando o modelo tem dificuldade em encontrar qualquer solução correta.
Compromisso entre Correção e Eficiência: Tentativas anteriores frequentemente degradam as pontuações de pura correção ao otimizar a velocidade, falhando em encontrar soluções que sejam tanto corretas quanto eficientes.

O artigo argumenta que, para o tempo de execução se tornar um sinal aprendível, todo o pipeline — desde a geração de testes até a composição da recompensa e estabilidade do otimizador — deve ser redesenhado.

Metodologia

Os autores propõem um framework de três estágios para tornar o tempo de execução aprendível: (1) Dados e Medição, (2) Design de Ambiente e Recompensa, e (3) Treinamento Estável.

1. Dados e Medição: DMC-Optim e Execução Calibrada

Para superar o ruído de medição, os autores construíram o DMC-Optim, um novo dataset derivado do DeepMind Code Contests (DMC).

Construção de Testes: Eles separaram testes de correção de testes de otimização. Os testes de otimização utilizam inputs grandes (gerados via LLM) para garantir que os tempos de execução estejam na ordem de segundos (mediana de ~3s), tornando-os robustos contra ruídos de nível de milissegundo.
Filtrabilidade de Duração: Eles filtraram problemas para reter apenas aqueles onde as soluções de referência humanas exibem um coeficiente de variação robusto (CV ≥ 0.3) no tempo de execução, garantindo que as diferenças de velocidade sejam mensuráveis e classificáveis.
Sandbox Calibrado (CES): Para eliminar o ruído de contenção do lado do worker, eles utilizam um serviço de execução isolado e remoto (CES). Eles aplicam calibração afim para corrigir o desvio de estado do serviço, garantindo que as medições de tempo sejam comparáveis entre diferentes execuções de treinamento.

2. Design de Ambiente e Recompensa

Os autores classificam as restrições de otimização em três pontos de intervenção e utilizam um simulador offline para triar configurações promissoras antes do treinamento online caro.

Pontos de Intervenção:
- Pré-execução: Filtragem de testes baseada no tamanho do input ou duração estimada.
- Intra-execução: Aplicação de limites de tempo durante a execução do teste.
- Pós-execução: Classificação de soluções contra referências humanas após a execução.
Composição de Recompensa: Eles exploram várias formulações de recompensa, descobrindo que recompensas binárias colapsadas (ou recompensas de dois portões) funcionam melhor. A recompensa é $-1$ para código incorreto e, para código correto, é determinada se a solução atende a um percentil de velocidade específico (ex: top 30% das soluções humanas). Isso evita recompensar código rápido-mas-errado e previne o "reward hacking" visto em misturas aditivas.
Simulador Offline: Antes do treinamento online, eles simulam o ambiente de RL usando soluções humanas amostradas e durações pré-computadas. Eles utilizam métricas como AUC (Área Sob a Curva da taxa de passagem vs. qualidade da solução) e Steepness (declividade) para identificar ambientes que fornecem um sinal denso e monotônico sem ser excessivamente esparso ou saturado.

3. Treinamento Estável com GRPO

Para lidar com as recompensas mais esparsas e ruidosas do RL de otimização, os autores adaptam o algoritmo GRPO (Group Relative Policy Optimization):

Aumento de Rollouts: Eles aumentam o número de rollouts por prompt ( $G$ ) para reduzir grupos de vantagem zero e melhorar as estimativas de Monte Carlo.
Tamanho do Batch: Batches de treinamento maiores são usados para suavizar o ruído de tempo nas estimativas de gradiente.
Normalização de Vantagem: Eles centralizam os retornos, mas evitam dividir pela desvio padrão do grupo para evitar o viés de dificuldade (sobreponderar prompts onde o modelo falha em encontrar truques de otimização).
Baseline Ponderado por Token: Eles utilizam uma média ponderada por token para o baseline de vantagem e normalizam a perda por um horizonte de tokens fixo ( $N=32.768$ ) em vez do comprimento do rollout, evitando que trajetórias longas incorretas sejam sub-penalizadas.

Principais Contribuições

Dataset DMC-Optim e Stack de Timing: Um corpus limpo de 2.723 problemas com 430k testes de correção e 352k testes de otimização, especificamente desenhado para separar correção de velocidade e fornecer sinais de tempo mensuráveis.
Taxonomia de Otimização-RL e Triagem: Uma classificação sistemática de restrições de otimização (pré-, intra-, pós-execução) e um simulador offline para eliminar ambientes degenerados antes do treinamento online.
Receita de Treinamento de Otimização-RL Estável: Uma receita de treinamento validada usando GRPO com adaptações específicas (aumento de rollouts, tamanhos de batch e gating de recompensa) que treina modelos com sucesso para gerar código que é simultaneamente correto e eficiente.

Resultados

O método foi avaliado nos modelos Qwen 2.5 (7B/32B) e CWM 32B no conjunto de teste DMC-Optim e no out-of-distribution LiveCodeBench (LCB).

Ganhos de Otimização Estrita: No DMC-Optim, a melhor configuração (classificação pós-execução no top 30%) melhorou o pass@1 no limiar estrito p30 (correto e mais rápido que 70% dos humanos) significativamente:
- Qwen 2.5 7B: De 7.7% para 19.1% (melhoria relativa de 150%).
- CWM 32B: De 13.7% para 30.9% (melhoria relativa de 125%).
- Qwen 2.5 32B: De 9.4% para 24.2%.
Preservação da Correção: Esses ganhos foram alcançados mantendo ou melhorando ligeiramente as pontuações de pura correção (p100 pass@1), ao contrário das recompensas de tempo ingênuas que frequentemente degradavam a correção.
Desempenho Out-of-Distribution: No LiveCodeBench, os modelos treinados para otimização mostraram altas taxas de vitória de velocidade contra baselines de RLVR padrão. Por exemplo, o CWM 32B venceu 83% das comparações de velocidade de amostra mediana contra o baseline padrão.
Descoberta Algorítmica: A análise de pares de vitória de velocidade revelou que os modelos aprenderam não apenas otimizações de I/O e ajustes de fator constante, mas também melhorias algorítmicas (ex: mudar de $O(N^2)$ para $O(N)$ , ou encontrar atalhos matemáticos de forma fechada). Em 13% dos casos onde a otimização-RL superou o RLVR padrão, a melhoria foi uma redução de complexidade.

Significância e Alegações

O artigo afirma que a otimização de código é um problema solucionável para RL, desde que o sinal de medição seja confiável e a estrutura de recompensa seja cuidadosamente desenhada.

Reduzindo a Lacuna: O trabalho demonstra que a lacuna entre escrever código correto e escrever código eficiente, observada tanto na programação competitiva quanto na engenharia de software do mundo real (SWE-fficiency), pode ser reduzida através de RL.
Viabilidade de Otimização One-Shot: Ao contrário de trabalhos anteriores que dependem de refinamento iterativo ou busca em tempo de inferência, este artigo mostra que um modelo pode aprender a gerar código otimado em um cenário one-shot (gerando do zero sem feedback de execução durante a geração).
Caminho para Descoberta Algorítmica: Os resultados sugerem que o RL pode impulsionar a descoberta de melhorias algorítmicas não triviais, não apenas ajustes de implementação, aproximando os modelos da eficiência algorítmica de nível humano (embora humanos ainda superem os modelos na descoberta de mudanças algorítmicas complexas).
Escalabilidade: Os ganhos transferem-se através de tamanhos de modelo (7B a 32B) e para benchmarks out-of-distribution, sugerindo que a abordagem é robusta e não sofre overfitting aos dados de treinamento.

Os autores concluem que, embora os modelos atuais ainda fiquem atrás das melhores submissões humanas na descoberta de mudanças algorítmicas complexas, o framework proposto fornece uma base para trabalhos futuros em descoberta de algoritmos e otimização de software no mundo real.