🤖 machine learning

Reinforcement Learning for Code Optimization

Dit artikel introduceert DMC-Optim, een driefasig framework dat de instabiliteit van het toepassen van reinforcement learning op code-optimalisatie overwint door uitvoeringsomgevingen te kalibreren, correctheid en snelheid-beloningen te componeren en trainingsalgoritmen aan te passen, waardoor de generatie van snellere code bij het behoud van correctheid aanzienlijk wordt verbeterd.

Oorspronkelijke auteurs: Pierre Chambon, Kunhao Zheng, Juliette Decugis, Benoit Sagot, Gabriel Synnaeve

Gepubliceerd 2026-07-29

📖 9 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Pierre Chambon, Kunhao Zheng, Juliette Decugis, Benoit Sagot, Gabriel Synnaeve

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je een wereld voor waarin computers lijnen als ongelooflijk getalenteerde, maar ietwat onhandige koks zijn. Ze kunnen een recept volgen om een perfect gerecht te maken (code schrijven die werkt), maar ze nemen vaak de lange weg en gebruiken duizend kleine stapjes terwijl één grote sprong zou volstaan. Dit is de wereld van Artificiële Intelligentie en Code Generatie. Wetenschappers hebben deze AI-koks geleerd te koken door hen feedback te geven: "Als het gerecht goed smaakt, krijg je een gouden ster." Deze methode, genaamd Reinforcement Learning, heeft AI erg goed gemaakt in het schrijven van code die werkt. Maar er is een addertje onder het gras: de code draait vaak traag, als een kok die elke ui met de hand snijdt in plaats van een keukenmachine te gebruiken. De grote vraag is: kunnen we de AI leren om niet alleen het gerecht te maken, maar om het ook snel te maken? De uitdaging is dat "snel" een ongrijpbaar concept is; het precies meten hoe lang een stuk code nodig heeft om te draaien is ruizig, zoals proberen een race te timen terwijl de stopwatch in je hand trilt. Als de AI de timing verkeerd meet, leert hij misschien wel snel te draaien maar maakt hij een puinhoop, of raakt hij in de war door de ruis en stopt hij zelfs met leren.

Dit artikel, getiteld "Reinforcement Learning for Code Optimization," is het verhaal over hoe een team van onderzoekers een AI-kok heeft geleerd om te stoppen met het met de hand snijden van uien en te beginnen met het gebruik van een keukenmachine, zonder de keuken af te branden. Ze ontdekten dat het simpelweg vertellen van de AI "wees sneller" niet werkt omdat de tijdsmetingen te rommelig zijn. In plaats daarvan bouwden ze een speciale, supernauwkeurige keuken (een "gekalibreerde zandbak") en een nieuwe set regels voor hoe ze de AI hun gouden sterren konden geven. Ze ontdekten dat door de manier waarop de AI wordt getest zorgvuldig te ontwerpen—door grotere, moeilijkere problemen te gebruiken die het verschil tussen een trage en een snelle oplossing daadwerkelijk laten zien—ze de AI konden leren om code te schrijven die zowel correct als aanzienlijk sneller is. Het resultaat? De AI leerde complexe puzzels tot wel 125% sneller op te lossen in sommige strikte categorieën, terwijl de antwoorden nog steeds correct waren. Het is een beetje alsof je een student leert om niet alleen een wiskundeprobleem op te lossen, maar om het in de minste stappen mogelijk te doen, zelfs wanneer de stopwatch van de leraar een beetje trilt.

Het Probleem: De "Snel maar Fout" Valstrik

Stel je voor dat je een robot traint om een race te rennen. Als je alleen zegt: "Ren zo snel als je kunt," kan de robot valsspelen door een kortere route te nemen die de baan beschadigt, of hij kan over zijn eigen voeten struikelen omdat hij zich haast. In de wereld van code is dit precies wat er gebeurde toen onderzoekers probeerden de AI sneller te maken. Ze probeerden "snelheid" toe te voegen aan het beloningssysteem: "Als je code werkt en het draait in 1 seconde, krijg je een grote beloning. Als het in 10 seconden draait, krijg je een kleine beloning."

Maar dit simpele idee faalde. Waarom? Omdat het meten van tijd ruizig is. Soms draait een code snel omdat de computer een goede dag had, niet omdat de code slim was. Andere keren draait een code traag omdat de computer ergens anders mee bezig was. Deze "ruis" verwarde de AI. De AI begon te leren dat "snel zijn" er niet toe deed, of erger nog, hij leerde code te schrijven die super snel was maar volkomen fout (zoals een robot die de verkeerde kant op rent naar de finishlijn). Het artikel laat zien dat als je tijd toevoegt aan de beloning zonder de meetinstrumenten te repareren, de AI nauwelijks sneller wordt, en soms zelfs slechter wordt in het zijn van correct.

De Oplossing: Een Betere Keuken Bouwen

De onderzoekers realiseerden zich dat ze drie dingen moesten oplossen voordat de AI kon leren: de tests, de beloning en de trainingsmethode.

1. De Tests: Van Sprints naar Marathons
De oorspronkelijke tests die de AI kreeg, waren als sprints—zeer kort en snel. In een sprint kan een kleine vertraging (zoals een niesbui) een enorm verschil maken in de tijd, waardoor het onmogelijk is om te zien of de loper daadwerkelijk sneller is. De onderzoekers bouwden een nieuwe set tests genaamd DMC-Optim. Dit zijn als marathons. Ze gebruiken enorme inputs en complexe problemen die seconden of zelfs minuten duren om te draaien. In een marathon doet een niesbui er niet toe; je kunt duidelijk zien wie er daadwerkelijk sneller loopt. Ze creëerden 2.723 opgeschoonde problemen en voegden 352.740 nieuwe "optimalisatietests" toe die specifiek ontworpen zijn om traag te zijn, zodat de AI het verschil tussen een goede oplossing en een geweldige oplossing daadwerkelijk kan voelen.

2. De Beloning: De Drietrapspoort
In plaats van alleen te zeggen "sneller is beter," ontwierpen de onderzoekers een slim beloningssysteem dat werkt als een drietrapspoort:

Poort 1 (Correctheid): De code moet werken. Als dat niet zo is, volgt er een grote straf (geen gouden ster).
Poort 2 (Optimalisatie): Als de code werkt, slaagt het dan voor de "snelheidstest"? De AI wordt vergeleken met een klassement van menselijke experts. Als de AI tot de top 30% van de mensen behoort, krijgt hij een beloning.
Poort 3 (Het Signaal): De beloning is niet zomaar een getal; het is een duidelijk signaal. Ze gebruikten een "binaire" beloning (zoals een lichtknop: aan of uit) in plaats van een dimmer, om te voorkomen dat de AI in de war raakt door kleine, ruisige verschillen in tijd. Als de code correct en snel genoeg is, gaat het licht aan. Zo niet, dan blijft het uit. Dit eenvoudige "aan/uit"-signaal was verrassend krachtig.

3. De Training: Een Stabiele Coach
Het trainen van een AI met ruisige timingdata is als het proberen te trainen van een hond met een trillende hand. De onderzoekers moesten hun trainingsalgoritme (genaamd GRPO) aanpassen om het stabieler te maken. Ze vergrooten het aantal pogingen dat de AI doet voor elk probleem (zoals de hond de cursus 16 keer laten rennen in plaats van één keer) om de ruis uit te middelen. Ze zorgden er ook voor dat de AI niet ontmoedigd raakte wanneer hij faalde, door de manier waarop de "score" werd berekend aan te passen. Dit hield de training stabiel, zelfs wanneer de timingmetingen een beetje trillerig waren.

De Resultaten: Versnellen Zonder Te Crashen

Toen ze al deze onderdelen samenbrachten, waren de resultaten indrukwekkend. Ze testten hun nieuwe methode op verschillende AI-modellen, waaronder Qwen 2.5 (een model met 7 miljard en 32 miljard parameters) en CWM 32B.

De Grote Sprong: Op de moeilijkste tests (waar de code in de top 30% van de menselijke snelheid moest zitten) steeg de prestatie van de CWM 32B-model van 13,7% naar 30,9%. Dat is een relatieve verbetering van 125%!
Correct Blijven: Cruciaal was dat de AI geen accuratesse opofferde voor snelheid. Het aantal keren dat de code correct was (zelfs als het traag was), bleef gelijk of verbeterde zelfs licht. De AI leerde zowel snel als juist te zijn.
De Baseline Verslaan: Wanneer vergeleken met standaard trainingsmethoden, wonnen de nieuw met optimalisatie getrainde modellen 83% van de tijd in directe snelheid-vergelijkingen op een andere benchmark genaamd LiveCodeBench.

Wat Heeft de AI Eigenlijk Geleerd?

De onderzoekers keken niet alleen naar de scores; ze bekeken de code zelf om te zien welke trucjes de AI had geleerd. Ze gebruikten een andere AI (een "rechter") om de nieuwe code te vergelijken met de oude code en menselijke oplossingen.

De "I/O" Truc: De meest voorkomende verbetering was Input/Output optimalisatie. De AI leerde gegevens efficiënter te lezen en te schrijven, zoals een kok die stopt met tijd verspillen door constant de koelkastdeur te openen en te sluiten. Dit was verantwoordelijk voor 47% van de overwinningen.
De "Wiskunde" Afkorting: In 6% van de gevallen vond de AI een wiskundige afkorting, waarbij hij besefte dat hij niet alle berekeningen hoefde uit te voeren.
De "Algoritme" Verandering: In 13% van de gevallen veranderde de AI de fundamentele manier waarop hij het probleem oploste (zoals het overstappen van een trage, brute-force methode naar een slimme, efficiënte methode). Dit is de "heilige graal" van optimalisatie.
Mensen Verslaan: Hoewel mensen over het algemeen nog steeds complexere verbeteringen vinden (mensen wonnen 16% van de gevallen van complexiteitsverbetering tegenover de 7% van de AI), slaagde de AI er toch in om de beste menselijke oplossingen te verslaan in 7% van de gevallen waar hij een complexiteitsverbetering vond.

De Limieten en de Toekomst

Het artikel merkt terecht op dat dit geen toverstaf is. De AI worstelt nog steeds met de moeilijkste problemen, en mensen zijn nog steeds beter in het vinden van de meest complexe algoritmische veranderingen (mensen wonnen 22% van de complexiteitsverbeteringen versus de 13% van de AI). Ook leerde de AI soms delen van de code weg te laten om het alleen maar sneller te maken, wat misschien niet veilig is voor real-world software.

Desalniettemin suggereert het artikel dat dit een grote stap voorwaarts is. Door een betere "keuken" te bouwen (de tests en de zandbak) en duidelijkere instructies te geven (het beloningssysteem), hebben ze bewezen dat AI kan leren om efficiënte code te schrijven, en niet alleen correcte code. Dit vormt een fundament voor een toekomst waarin AI niet alleen software schrijft, maar software schrijft die net zo snel draait als een menselijke expert die het zou ontwerpen. De onderzoekers suggereren dat de volgende stap is om de AI nog specifiekere feedback te geven over waarom een oplossing snel is, om het de AI te helpen nog complexere algoritmische trucs te ontdekken.

Technische Samenvatting: Reinforcement Learning voor Code-optimalisatie

Probleemstelling

Hoewel Reinforcement Learning met Verifieerbare Beloningen (RLVR) succesvol de correctheid van code heeft verbeterd, is het er niet in geslaagd om de efficiëntie van code (executiesnelheid) betrouwbaar te verbeteren. Standaard RLVR behandelt executie als een binaire verifieerder: een oplossing wordt beloond als deze voldoet aan de correctheidstests. Het uitbreiden naar optimalisatie door simpelweg de executietijd aan het beloningssignaal toe te voegen, faalt in de praktijk vanwege meetruis, beloningsschaarsheid en trainingsinstabiliteit.

Bestaande benchmarks en trainingsbenaderingen lijden onder drie hoofdzaken:

Meetruis: Op standaard competitieve programmeerdatasets (bijv. DeepMind Code Contests, LiveCodeBench) zijn de testinputs klein en liggen de executietijden vaak in de tientallen milliseconden. Vaste overhead (scheduling, dispatch) domineert het signaal, waardoor het onmogelijk is om correcte oplossingen op basis van snelheid te onderscheiden.
Beloningsschaarsheid en Instabiliteit: Naïeve timing-beloningen (bijv. het belonen van een lagere gemiddelde runtime) leiden vaak tot "snelle-maar-foute" code of falen om een voldoende dicht signaal te bieden voor Gradient-gebaseerde Policy Optimization (GRPO) om te convergeren, vooral wanneer het model moeite heeft om elke correcte oplossing te vinden.
Correctheid-Efficiëntie Afweging: Eerdere pogingen leiden vaak tot een degradatie van de pure correctheidsscores wanneer er wordt geoptimaliseerd voor snelheid, waarbij gefaald wordt om oplossingen te vinden die zowel correct als efficiënt zijn.

Het artikel betoogt dat voor executietijd om een leerbaar signaal te worden, de gehele pijplijn — van testgeneratie tot beloningscompositie en optimizer-stabiliteit — opnieuw ontworpen moet worden.

Methodologie

De auteurs stellen een driefasig framework voor om executietijd leerbaar te maken: (1) Data en Meting, (2) Omgeving en Beloningsontwerp, en (3) Stabiele Training.

1. Data en Meting: DMC-Optim en Gekalibreerde Executie

Om de meetruis te overwinnen, hebben de auteurs DMC-Optim geconstrueerd, een nieuwe dataset afgeleid van DeepMind Code Contests (DMC).

Testconstructie: Ze hebben correctheidstests gescheiden van optimalisatietests. Optimalisatietests gebruiken grote inputs (gegenereerd via LLM's) om ervoor te zorgen dat de executietijden in de secondenrange liggen (mediaan ~3s), wat ze robuust maakt tegen milliseconde-niveau ruis.
Duur Filterbaarheid: Ze hebben problemen gefilterd om alleen die te behouden waar menselijke referentiedata een robuuste coëfficiënt van variatie (CV ≥ 0,3) vertonen in executietijd, wat ervoor zorgt dat snelheidsverschillen meetbaar en rangschikbaar zijn.
Gekalibreerde Sandbox (CES): Om ruis door contention aan de worker-zijde te elimineren, gebruiken ze een afgelegen, geïsoleerde executiedienst (CES). Ze passen affine kalibratie toe om drift in de service-status te corr corrected, waardoor timing-metingen vergelijkbaar blijven over verschillende trainingsruns heen.

2. Omgeving en Beloningsontwerp

De auteurs classificeren optimalisatiebeperkingen in drie interventiepunten en gebruiken een offline simulator om veelbelovende configuraties te screenen voordat er dure online training plaatsvindt.

Interventiepunten:
- Pre-executie: Filteren van tests op basis van inputgrootte of geschatte duur.
- Intra-executie: Afdwingen van tijdslimieten tijdens de uitvoering van de test.
- Post-executie: Rangschikken van oplossingen tegen menselijke referenties na uitvoering.
Beloningscompositie: Ze onderzoeken verschillende beloningsformuleringen en ontdekken dat gecomprimeerde binaire beloningen (of twee-poort beloningen) het beste werken. De beloning is $-1$ voor onjuiste code, en voor correcte code wordt deze bepaald door of de oplossing voldoet aan een specifiek snelheidspercentiel (bijv. de top 30% van de menselijke oplossingen). Dit voorkomt het belonen van snelle-maar-foute code en voorkomt de "reward hacking" die wordt gezien bij additieve mengvormen.
Offline Simulator: Voordat de online training begint, simuleren ze de RL-omgeving met gesamplede menselijke oplossingen en vooraf berekende duur. Ze gebruiken metrieken zoals AUC (Area Under the Curve van de pass-rate versus oplossingskwaliteit) en Steepness om omgevingen te identificeren die een dicht, monotoon signaal bieden zonder te schaars of verzadigd te zijn.

3. Stabiele Training met GRPO

Om de scharcere en ruisiger beloningen van optimalisatie-RL te hanteren, passen de auteurs het GRPO (Group Relative Policy Optimization) algoritme aan:

Verhoogde Rollouts: Ze verhogen het aantal rollouts per prompt ( $G$ ) om zero-advantage groepen te verminderen en Monte Carlo-schattingen te verbeteren.
Batch Size: Grotere trainingsbatches worden gebruikt om de timingruis in gradientschattingen te middelen.
Advantage Normalisatie: Ze centreren de returns maar vermijden het delen door de groepsstandaarddeviatie om bias door moeilijkheidsgraad te voorkomen (het overmatig zwaar wegen van prompts waarbij het model geen optimalisatietrucs vindt).
Token-Gewogen Baseline: Ze gebruiken een token-gewogen gemiddelde voor de advantage baseline en normaliseren de loss door een vaste token-horizon ( $N=32.768$ ) in plaats van de rollout-lengte, wat voorkomt dat lange, onjuiste trajecten te weinig worden bestraft.

Belangrijkste Bijdragen

DMC-Optim Dataset en Timing Stack: Een opgeschoonde corpus van 2.723 problemen met 430k correctheidstests en 352k optimalisatietests, specifiek ontworpen om correctheid van snelheid te scheiden en meetbare timing-signalen te bieden.
Optimization-RL Taxonomie en Screening: Een systematische classificatie van optimalisatiebeperkingen (pre-, intra-, post-executie) en een offline simulator om degeneratieve omgevingen te elimineren vóór online training.
Stabiel Optimalisatie-RL Recept: Een gevalideerd trainingsrecept met gebruik van GRPO met specifieke aanpassingen (verhoogde rollouts, batchgroottes en beloningspoorten) die er succesvol in slaagt modellen te trainen om code te genereren die zowel correct als efficiënt is.

Resultaten

De methode werd geëvalueerd op Qwen 2.5 (7B/32B) en CWM 32B modellen op de DMC-Optim testset en de out-of-distribution LiveCodeBench (LCB).

Strikte Optimalisatie Winsten: Op DMC-Optim verbeterde de beste configuratie (post-executie ranking op top 30%) de pass@1 bij de strikte p30 drempel (correct en sneller dan 70% van de mensen) aanzienlijk:
- Qwen 2.5 7B: Van 7,7% naar 19,1% (150% relatieve verbetering).
- CWM 32B: Van 13,7% naar 30,9% (125% relatieve verbetering).
- Qwen 2.5 32B: Van 9,4% naar 24,2%.
Behoud van Correctheid: Deze winsten werden behaald terwijl de pure correctheidsscores (p100 pass@1) gelijk bleven of zelfs licht verbeterden, in tegen tegenstelling tot naïeve timing-beloningen die vaak de correctheid verslechteren.
Out-of-Distribution Prestaties: Op LiveCodeBench vertoonden de met optimalisatie getrainde modellen hoge speed win rates tegenover standaard RLVR-baselines. Bijvoorbeeld, CWM 32B won 83% van de median-sample snelheidvergelijkingen tegen de standaard baseline.
Algoritmische Ontdekking: Analyse van speed-win paren onthulde dat de modellen niet alleen I/O-optimalisaties en constante-factor aanpassingen leerden, maar ook algoritmische verbeteringen (bijv. veranderen van $O(N^2)$ naar $O(N)$ , of het vinden van gesloten wiskundige shortcuts). In 13% van de gevallen waarin optimalisatie-RL de standaard RLVR versloeg, was de verbetering een complexiteitsreductie.

Betekenis en Claims

Het artikel claimt dat code-optimalisatie een oplosbaar probleem is voor RL, mits het meetsignaal betrouwbaar is en de beloningsstructuur zorgvuldig is ontworpen.

De Kloof Overbruggen: Het werk demonstreert dat de kloof tussen het schrijven van correcte code en het schrijven van efficiënte code, geobserveerd in zowel competitief programmeren als real-world software engineering (SWE-fficiency), kan worden verkleind door RL.
Haalbaarheid van One-Shot Optimalisatie: In tegen tegenstelling tot eerder werk dat vertrouwt op iteratieve verfijning of inference-time search, laat dit artikel zien dat een model kan leren om geoptimaliseerde code te genereren in een one-shot setting (genereren vanuit het niets zonder executie-feedback tijdens de generatie).
Pad naar Algoritmische Ontdekking: De resultaten suggeren dat RL kan leiden tot de ontdekking van niet-triviale algoritmische verbeteringen, niet alleen implementatie-tweaks, waardoor modellen dichter bij menselijke niveau van algoritmische efficiëntie komen (hoewel mensen nog steeds beter presteren in het vinden van complexe algoritmische wijzigingen).
Schaalbaarheid: De winsten zijn overdraagbaar op verschillende modelgroottes (7B tot 32B) en naar out-of-distribution benchmarks, wat suggereert dat de aanpak robuust is en niet overfit is op de trainingsdata.

De auteurs concluderen dat hoewel huidige modellen nog steeds achterlopen op de beste menselijke inzendingen bij het vinden van complexe algoritmische wijzigingen, het voorgestelde framework een fundament biedt voor toekomstig werk op het gebied van algoritmische ontdekking en real-world software optimalisatie.