🤖 machine learning

Is Code Better Than Language for Algorithmic Reasoning

Dit artikel toont aan dat voor met tools versterkte taalmodellen het prestatievoordeel van code boven natuurlijke taal bij algoritmisch redeneren primair voortkomt uit betrouwbare externe uitvoering in plaats van de intermediaire coderepresentatie zelf, aangezien door code gesimuleerd redeneren geen significante winst oplevert ten opzichte van redeneren in natuurlijke taal.

Oorspronkelijke auteurs: Terry Tong, Yu Feng, Surbhi Goel, Dan Roth

Gepubliceerd 2026-06-16

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Terry Tong, Yu Feng, Surbhi Goel, Dan Roth

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 voor dat je een zeer lastige wiskundepuzzel probeert op te lossen. Je hebt twee hoofdwegen om het antwoord te vinden:

De "Prater"-methode: Je vraagt een slimme assistent om hardop na te denken in gewoon Engels, stap voor stap, en dan het antwoord aan je te vertellen.
De "Coder"-methode: Je vraagt dezelfde assistent om een computerprogramma te schrijven om de puzzel op te lossen, en vervolgens laat je een computer dat programma daadwerkelijk uitvoeren om het antwoord te krijgen.

Een lange tijd merkten mensen op dat de "Coder"-methode meestal veel beter werkte. Maar niemand wist precies waarom. Was het omdat het schrijven van code de assistent dwingt om helderder na te denken? Of was het omdat het laten draaien van de code door een computer simpelweg betrouwbaarder is dan de assistent het werk in zijn hoofd te laten doen?

Dit artikel zet een slim experiment op om uit te zoeken welke factor de echte held is.

Het Drie-Ritten-Experiment

De auteurs creëerden een "drie rijstroken brede snelweg" om dit te testen, met behulp van een benchmark van 40 algoritmische puzzels (zoals het sorteren van lijsten, het vinden van paden of complexe wiskunde doen).

Route 1 (De Pure Prater): De assistent lost het probleem volledig op in het Engels. Hij denkt na, schrijft een paragraaf redenering en geeft het antwoord.
- Resultaat: Hij had ongeveer 17% van de antwoorden goed.
Route 2 (De Nep-Coder): De assistent schrijft de code (zoals Python), maar doet alsof hij deze uitvoert. In plaats van de code aan een computer te geven, leest de assistent zijn eigen code en simuleert de stappen in zijn hoofd, waarna hij het resultaat in het Engels opschrijft.
- Resultaat: Hij had ongeveer 17% van de antwoorden goed.
- De Grote Onthulling: Dit is bijna exact hetzelfde als Route 1. Het schrijven van de code hielp de assistent niet om beter na te denken; het veranderde alleen de vorm van zijn gedachten.
Route 3 (De Echte Coder): De assistent schrijft exact dezelfde code als in Route 2, maar dit keer geeft hij de code door aan een echte computer (een Python-runtime) om deze uit te voeren.
- Resultaat: Hij had ongeveer 49% van de antwoorden goed.

Het "Waarom" Achter de Magie

De auteurs gebruiken een paar creatieve manieren om deze resultaten te verklaren:

1. De "Vertalings"-analogie (Representatie vs. Executie)
Denk aan de "Trace" (de redeneerstappen) als een recept.

Route 1 is een recept geschreven als een lang, bloemrijk verhaal.
Route 2 is hetzelfde recept, maar geschreven als een strikte, gestructureerde lijst.
Route 3 is die strikte lijst, maar in plaats van een menselijke chef die het probeert te lezen en de uitkomst te raden, geef je het aan een robotchef die de instructies perfect opvolgt.

Het experiment toonde aan dat het veranderen van het recept van een verhaal (Engels) naar een lijst (Code) de menselijke chef niet slimmer maakte. De menselijke chef (de LLM) maakte dezelfde fouten of hij nu het verhaal las of de lijst. De enorme sprong in prestaties vond pas plaats toen de robotchef (de computer-executor) het overnam.

2. De "Nuisance"-theorie
De auteurs stellen dat natuurlijke taal vol zit met "ruis". Je kunt hetzelfde op duizend verschillende manieren zeggen ("tel de getallen op", "som ze op", "voeg ze samen"). Deze extra variatie zorgt voor verwarring. Code is strikter; er zijn minder manieren om hetzelfde te zeggen.
Echter, het artikel bewijst dat zelfs al is code "schoner", de assistent het nog steeds niet kan gebruiken om de wiskundige problemen op eigen kracht op te lossen. De code geeft het model niet magisch nieuwe wiskundige vaardigheden.

3. De "Herstel"-test
De auteurs keken naar de gevallen waarin de computer het antwoord goed had, maar de menselijke assistent (die de code simuleerde) het fout had. Dit gebeurde 33% van de tijd.
Omgekeerd keken ze naar gevallen waarin de computer faalde (miss misschien omdat de code kapot was), maar de menselijke assistent toch het juiste antwoord raadde. Dit gebeurde slechts 1,6% van de tijd.
Dit bewijst dat de computer een veel betrouwbaardere "executor" is dan de menselijke assistent een "simulator" van de code is.

De Kernboodschap

De conclusie van het artikel is dat Code niet beter is dan Taal omdat het een betere manier is om te denken.

Het voordeel van het gebruik van code is niet dat het de AI slimmer maakt. Het voordeel is dat Code de AI in staat stelt het werk over te dragen aan een machine die geen wiskundige fouten maakt.

De Bottleneck: Het probleem is niet dat de AI geen goede code kan schrijven; het probleem is dat de AI slecht is in het controleren van zijn eigen werk of het doen van de wiskunde in zijn hoofd.
De Oplossing: De echte kracht komt van het gereedschap (de computer die de code draait), niet van de taal (de code zelf).

Kortom: Als je wilt dat een AI een moeilijk wiskundig probleem oplost, vraag hem dan niet alleen om code te schrijven en hoop dan niet dat hij het antwoord uitrekenen kan. Vraag hem om code te schrijven, en laat vervolgens een computer die code daadwerkelijk uitvoeren. Dat is waar de magie gebeurt.

Technische Samenvatting: Is Code Beter Dan Taal voor Algoritmisch Redeneren?

Probleemstelling

In door instrumenten versterkte taalmodel-systemen (LLM's) is het algemeen bekend dat het vertalen van problemen naar een door een solver uitvoerbare code (waarbij de uitvoering wordt gedelegeerd aan een extern instrument) vaak beter presteert dan end-to-end redeneren in natuurlijke taal (NL) bij complexe algoritmische taken. De bron van deze prestatiewinst blijft echter ambigu. Eerdere vergelijkingen vervuilen twee onderscheidende factoren:

Intermediaire Representatie: De verschuiving van natuurlijke taal-traces naar code-traces.
Executiemechanisme: De verschuiving van LLM-gebaseerde simulatie (forward pass) naar deterministische externe uitvoering (bijv. Python runtime).

Omdat eerdere studies "NL-redeneren" direct vergeleken met "Code + Externe Uitvoering," konden ze niet isoleren of de verbetering voortkwam uit de gestructureerde aard van code, de betrouwbaarheid van de externe executor, of beide. Dit artikel adresseert de onderzoeksvraag: Is de coderepresentatie inherent superieur aan natuurlijke taal voor algoritmisch redeneren, of wordt het voordeel primair gedreven door betrouwbare externe uitvoering?

Methodologie: Het Drie-Route-Framework

Om representatie van uitvoering te ontrafelen, stellen de auteurs een systematisch Drie-Route-Framework voor dat de redeneerpipeline deelt in twee stadia: Trace Generatie en Executie.

Route 1 (Directe NL): De LLM genereert een Chain-of-Thought trace in natuurlijke taal en gebruikt vervolgens dezelfde LLM om de redenering te simuleren en een antwoord te produceren.
- Trace: Natuurlijke Taal.
- Executor: LLM (NL simulatie).
Route 2 (Code + NL Simulatie): De LLM genereert een code-trace (bijv. Python), maar in plaats van deze extern uit te voeren, simuleert de dezelfde LLM de code-executie in natuurlijke taal om een antwoord te produceren.
- Trace: Code.
- Executor: LLM (Code simulatie).
Route 3 (Code + Solver Executie): De LLM genereert dezelfde code-trace als Route 2, maar de code wordt uitgevoerd door een deterministische externe Python runtime.
- Trace: Code.
- Executor: Externe Solver (Deterministisch).

Experimentele Opzet:

Benchmark: Een 40-taken verificeerbare algoritmische benchmark die rekenkunde, dynamisch programmeren, graafalgoritmen, stringmanipulatie, geometrie, sorteren en NP-harde optimalisatie omvat.
Data: 1.113 unieke probleeminstanties over 3 willekeurige seeds, geëvalueerd op 6 modellen (inclusief closed-source zoals GPT-4o-mini en open-source zoals Mixtral-8x22b).
Metrieken: End-task accuratesse onder 0–1 loss, geanalyseerd via gepaarde statistische tests (McNemar) en cluster-bootstrap betrouwbaarheidsintervallen.

Belangrijkste Bijdragen

1. Empirische Ontrafeling van Factoren

Het framework maakt pairwise vergelijkingen mogelijk die specifieke variabelen isoleren:

Route 1 vs. Route 2 (Isoleren van Representatie): Door de LLM-executor constant te houden en alleen de trace-modaliteit te veranderen (NL vs. Code), testen de auteurs of de coderepresentatie zelf een voordeel biedt.
Route 2 vs. Route 3 (Isoleren van Executie): Door de code-trace constant te houden en alleen de executor te veranderen (LLM simulatie vs. Python runtime), testen de auteurs of het executiemechanisme de drijfveer van de prestatie is.

2. Theoretische Formalisering (Besluitvormingstheoretisch Model)

De auteurs formaliseren de intuïtie dat code een "canonicalisering" is van natuurlijke taal. Ze stellen een lineair model voor waarbij:

Beide traces een kern ( $B$ ) delen die beslissingsrelevante algoritmische informatie bevat (bijv. recursieve relaties).
Natuurlijke taal-traces bevatten aanvullende nuisance variatie ( $\eta_N$ ) zoals parafrasering, verbositeit en stilistische keuzes die het antwoord niet veranderen.
Stelling: Onder dit model is code representatie-niet-inferieur aan natuurlijke taal. De extra nuisance in natuurlijke taal vergroot het risico (fout) voor finite-sample learners zonder extra signaal te bieden. Hetzij het veranderen van de representatie alleen zou geen significante winst opleveren als de kerninformatie behouden blijft.

3. Reconstructie-Interventie

Om de theorie empirisch te valideren, voeren de auteurs een "reconstructie-interventie" uit. Ze nemen code-traces gegenereerd door het model en vertalen deze terug naar natuurlijke taal met behulp van een vaste transformatie. Ze stellen vast dat deze getranslateerde NL-traces prestaties herstellen die vergelijkbaar zijn met native NL-traces. Dit bevestigt dat code alle beslissingsrelevante informatie behoudt en dat het "verlies" in NL-redeneren niet komt door ontbrekende algoritmische inhoud, maar door de aanwezigheid van nuisance variatie.

Resultaten

Prestatievergelijking

Op de 40-taken benchmark zijn de resultaten als volgt:

Route 1 (NL + NL): 17,21% accuratesse.
Route 2 (Code + NL Sim): 17,37% accuratesse.
Route 3 (Code + Python Exec): 48,84% accuratesse.

Statistische Bevindingen:

Route 1 vs. Route 2: Het verschil is +0,15 procentpunt (pp), met een 95% betrouwbaarheidsinterval van $[-0,30, +0,61]$ pp ( $p=0,39$ ). Dit geeft aan dat er geen statistisch significant verschil is tussen redeneren in natuurlijke taal en code-simulatie wanneer de executor dezelfde LLM is.
Route 2 vs. Route 3: Het verschil is +31,47 pp, met een 95% CI van $[+29,20, +33,71]$ pp ( $p < 0,001$ ). Dit wijst op een enorm, statistisch significant voordeel voor deterministische externe uitvoering boven LLM-simulatie, zelfs wanneer de code-trace identiek is.

Schaling van Moeilijkheidsgraad

Naarmate de taakcomplexiteit toeneemt (gecontroleerd door parameters zoals het aantal cijfers of de matrixgrootte), behoudt Route 3 een hoge accuratesse terwijl Routes 1 en 2 significant degraderen.

Herstel-Analyse

De auteurs analyseren gevallen waarin Route 2 (simulatie) slaagt maar Route 3 (executie) faalt ("recovery mass").

Recovery Mass: 1,61% (Gevallen waarin de LLM foutieve code correct simuleert of executiefouten negeert).
Execution-Win Mass: 33,08% (Gevallen waarin uitvoering slaagt maar de LLM-simulatie faalt).
Dit bevestigt dat de LLM zelden compenseert voor executiefouten; omgekeerd presteert de externe solver consequent beter dan het vermogen van de LLM om de code te simuleren.

Betekenis en Claims

Het artikel claimt dat in de geëvalueerde setting van algoritmisch redeneren:

Representatie niet de bottleneck is: De intermediaire interventie van het gebruik van code-traces verbetert de prestaties niet betekenisvol ten opzichte van natuurlijke taal-traces wanneer het executiemechanisme een LLM blijft. Het prestatieverschil tussen Route 1 en Route 2 is verwaarloosbaar.
Executie de bottleneck is: De primaire drijfveer van de geobserveerde prestatiewinsten in door instrumenten versterkte systemen is de betrouwbaarheid van de externe executor, en niet de gestructureerde aard van de coderepresentatie zelf.
Mechanisme van Instrumentgebruik: Het voordeel van code-gebaseerd instrumentgebruik komt voort uit het mogelijk maken van de overdracht van een gegenereerde trace naar een deterministische solver. De coderepresentatie dient primair als een voertuig om deze betrouwbare uitvoering mogelijk te maken, in plaats van te fungeren als een superieur redeneer-substraat voor de LLM zelf.

De auteurs concluderen dat voor algoritmische taken met verifieerbare antwoorden, het centrale voordeel van instrumentgebruik het vermogen is om de uitvoering te delegeren aan een deterministische omgeving, in plaats van de inherente superioriteit van code als redeneervorm boven natuurlijke taal.