🤖 machine learning

Is Code Better Than Language for Algorithmic Reasoning

Diese Arbeit zeigt, dass der Leistungsvorteil von Code gegenüber natürlicher Sprache bei werkzeugunterstützten Sprachmodellen im Bereich des algorithmischen Schließens primär auf der zuverlässigen externen Ausführung beruht und nicht auf der intermediären Code-Repräsentation selbst, da durch Code simuliertes Schließen keinen signifikanten Gewinn gegenüber dem Schließen in natürlicher Sprache liefert.

Ursprüngliche Autoren: Terry Tong, Yu Feng, Surbhi Goel, Dan Roth

Veröffentlicht 2026-06-16

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Terry Tong, Yu Feng, Surbhi Goel, Dan Roth

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie versuchen, ein sehr kniffliges mathematisches Rätsel zu lösen. Sie haben zwei Hauptwege, um die Antwort zu finden:

Die „Talker“-Methode (Der Redner): Sie bitten einen intelligenten Assistenten, laut in einfachem Englisch nachzudenken, Schritt für Schritt vorzugehen und Ihnen dann die Antwort zu nennen.
Die „Coder“-Methode (Der Programmierer): Sie bitten denselben Assistenten, ein Computerprogramm zu schreiben, um das Rätsel zu lösen, und lassen dann einen Computer dieses Programm tatsächlich ausführen, um die Antwort zu erhalten.

Lange Zeit bemerkten die Leute, dass die „Coder“-Methode meistens viel besser funktionierte. Aber niemand war sich sicher, warum. War es, weil das Schreiben von Code den Assistenten dazu zwingt, klarer zu denken? Oder war es, weil das Ausführen des Codes durch einen Computer einfach zuverlässiger ist, als dem Assistenten zu vertrauen, der die Mathematik in seinem Kopf erledigt?

Dieses Paper setzt ein kluges Experiment auf, um herauszufinden, welcher Faktor der wahre Held ist.

Das Drei-Routen-Experiment

Die Autoren erstellten eine „Dreispurige Autobahn“, um dies zu testen, indem sie einen Benchmark aus 40 algorithmischen Rätseln verwendeten (wie das Sortieren von Listen, das Finden von Pfaden oder komplexe Mathematik).

Route 1 (Der reine Talker): Der Assistent löst das Problem vollständig in Englisch. Er denkt nach, schreibt einen Absatz mit Begründungen und gibt die Antwort.
- Ergebnis: Er bekam etwa 17 % der Antworten richtig.
Route 2 (Der Fake Coder): Der Assistent schreibt den Code (wie Python), aber tut so, als ob er ihn ausführen würde. Anstatt den Code an einen Computer zu übergeben, liest der Assistent seinen eigenen Code, simuliert die Schritte in seinem Kopf und schreibt das Ergebnis in Englisch auf.
- Ergebnis: Er bekam etwa 17 % der Antworten richtig.
- Die große Enthüllung: Dies ist fast exakt dasselbe wie Route 1. Das Schreiben des Codes half dem Assistenten nicht, besser zu denken; es änderte lediglich das Format seiner Gedanken.
Route 3 (Der echte Coder): Der Assistent schreibt exakt denselben Code wie in Route 2, übergibt diesen aber diesmal einem echten Computer (einer Python-Laufzeitumgebung), um ihn auszuführen.
- Ergebnis: Er bekam etwa 49 % der Antworten richtig.

Das „Warum“ hinter der Magie

Das Paper nutzt einige kreative Wege, um diese Ergebnisse zu erklären:

1. Die „Übersetzungs“-Analogie (Repräsentation vs. Ausführung)
Stellen Sie sich den „Trace“ (die Begründungsschritte) wie ein Rezept vor.

Route 1 ist ein Rezept, geschrieben als eine lange, blumige Geschichte.
Route 2 ist dasselbe Rezept, aber geschrieben als eine strikte, strukturierte Liste.
Route 3 ist diese strikte Liste, aber anstatt dass ein menschlicher Koch versucht, sie zu lesen und das Ergebnis zu erraten, übergeben Sie sie einem Roboter-Koch, der den Anweisungen perfekt folgt.

Das Experiment zeigte, dass das Ändern des Rezepts von einer Geschichte (Englisch) zu einer Liste (Code) den menschlichen Koch nicht intelligenter machte. Der menschliche Koch (das LLM) machte dieselben Fehler, egal ob er die Geschichte oder die Liste las. Der massive Leistungssprung trat erst auf, als der Roboter-Koch (der Computer-Executor) übernahm.

2. Die „Nuisance“-Theorie (Die Störfaktor-Theorie)
Die Autoren argumentieren, dass natürliche Sprache voller „Rauschen“ ist. Man kann dasselbe auf tausend verschiedene Arten sagen („add the numbers“, „sum them up“, „put them together“). Diese zusätzliche Varianz verwirrt das Modell. Code ist strenger; er hat weniger Möglichkeiten, dasselbe zu sagen.
Das Paper beweist jedoch, dass das Modell selbst trotz der „Sauberkeit“ des Codes immer noch nicht in der Lage ist, die mathematischen Probleme aus eigener Kraft zu lösen. Der Code verleiht dem Modell nicht magischerweise neue mathematische Fähigkeiten.

3. Der „Recovery“-Test (Wiederherstellungstest)
Die Autoren untersuchten die Fälle, in denen der Computer die Antwort richtig hatte, der menschliche Assistent (der den Code simulierte) jedoch falsch lag. Dies geschah 33 % der Zeit.
Umgekehrt untersuchten sie die Fälle, in denen der Computer scheiterte (vielleicht war der Code fehlerhaft), der menschliche Assistent aber trotzdem die richtige Antwort errat. Dies geschah nur 1,6 % der Zeit.
Dies beweist, dass der Computer ein viel zuverlässigerer „Executor“ ist als der menschliche Assistent bei der „Simulation“ des Codes.

Das Fazit

Das Paper kommt zu dem Schluss: Code ist nicht besser als Sprache, weil er ein besserer Weg zum Denken ist.

Der Vorteil der Verwendung von Code liegt nicht darin, dass er die KI intelligenter macht. Der Vorteil besteht darin, dass Code es der KI ermöglicht, die Arbeit an eine Maschine abzugeben, die keine Rechenfehler macht.

Der Flaschenhals: Das Problem ist nicht, dass die KI keinen guten Code schreiben kann; es ist, dass die KI schlecht darin ist, ihre eigene Arbeit zu überprüfen oder die Mathematik in ihrem Kopf zu erledigen.
Die Lösung: Die wahre Kraft kommt vom Werkzeug (dem Computer, der den Code ausführt), nicht von der Sprache (dem Code selbst).

Kurz gesagt: Wenn Sie möchten, dass eine KI ein schwieriges mathematisches Problem löst, bitten Sie sie nicht nur, Code zu schreiben und hoffen Sie, dass sie die Antwort errät. Bitten Sie sie, Code zu schreiben, und lassen Sie dann einen Computer diesen tatsächlich ausführen. Genau dort geschieht die Magie.

Technisches Resümee: Ist Code besser als Sprache für algorithmisches Denken?

Problemstellung

In Werkzeug-erweiterten Sprachmodell-Systemen (LLM) ist es gut etabliert, dass die Übersetzung von Problemen in solver-ausführbaren Code (die Delegation der Ausführung an ein externes Werkzeug) die End-to-End-Reasoning in natürlicher Sprache (NL) bei komplexen algorithmischen Aufgaben oft übertrifft. Die Quelle dieses Leistungszuwachses bleibt jedoch zweideutig. Vorherige Vergleiche vermischen zwei distinkte Faktoren:

Intermediäre Repräsentation: Der Wechsel von natürlichen Sprachspuren zu Code-Spuren.
Ausführungsmechanismus: Der Wechsel von LLM-basierter Simulation (Forward Pass) zu deterministischer externer Ausführung (z. B. Python-Laufzeitumgebung).

Da vorangegangene Studien „NL-Reasoning“ direkt gegen „Code + externe Ausführung“ verglichen haben, konnten sie nicht isolieren, ob die Verbesserung aus der strukturierten Natur des Codes, der Zuverlässigkeit des externen Executors oder beidem resultierte. Diese Arbeit adressiert die Forschungsfrage: Ist die Code-Repräsentation inhärent überlegen gegenüber natürlicher Sprache für algorithmisches Denken, oder wird der Vorteil primär durch die zuverlässige externe Ausführung getrieben?

Methodik: Das Drei-Routen-Framework

Um Repräsentation von Ausführung zu entkoppeln, schlagen die Autoren ein systematisches Drei-Ruten-Framework vor, das die Reasoning-Pipeline in zwei Stadien unterteilt: Spur-Generierung (Trace Generation) und Ausführung (Execution).

Route 1 (Direktes NL): Das LLM generiert eine Chain-of-Thought-Spur in natürlicher Sprache und nutzt anschließend dasselbe LLM, um das Reasoning zu simulieren und eine Antwort zu produzieren.
- Spur: Natürliche Sprache.
- Executor: LLM (NL-Simulation).
Route 2 (Code + NL-Simulation): Das LLM generiert eine Code-Spur (z. B. Python), aber anstatt sie extern auszuführen, simuliert dasselbe LLM die Code-Ausführung in natürlicher Sprache, um eine Antwort zu produzieren.
- Spur: Code.
- Executor: LLM (Code-Simulation).
Route 3 (Code + Solver-Ausführung): Das LLM generiert dieselbe Code-Spur wie in Route 2, aber der Code wird durch eine deterministische externe Python-Laufzeitumgebung ausgeführt.
- Spur: Code.
- Executor: Externer Solver (Deterministisch).

Experimentelles Setup:

Benchmark: Ein verifizierbarer algorithmischer Benchmark mit 40 Aufgaben, der Arithmetik, dynamische Programmierung, Graphalgorithmen, String-Manipulation, Geometrie, Sortierung und NP-schwere Optimierung abdeckt.
Daten: 1.113 eindeutige Probleminstanzen über 3 Zufallssamen (Random Seeds), evaluiert auf 6 Modellen (einschließlich proprietärer Modelle wie GPT-4o-mini und Open-Source-Modellen wie Mixtral-8x22b).
Metriken: Endaufgabengenauigkeit unter 0–1 Loss, analysiert mittels gepaarter statistischer Tests (McNemar) und Cluster-Bootstrap-Konfidenzintervallen.

Zentrale Beiträge

1. Empirische Entkopplung der Faktoren

Das Framework ermöglicht paarweise Vergleiche, die spezifische Variablen isolieren:

Route 1 vs. Route 2 (Isolierung der Repräsentation): Indem der LLM-Executor konstant gehalten und nur die Modalität der Spur (NL vs. Code) geändert wird, testen die Autoren, ob die Code-Repräsentation selbst einen Vorteil bietet.
Route 2 vs. Route 3 (Isolierung der Ausführung): Indem die Code-Spur konstant gehalten und nur der Executor geändert wird (LLM-Simulation vs. Python-Laufzeitumgebung), testen die Autoren, ob der Ausführungsmechanismus der Treiber der Leistung ist.

2. Theoretische Formalisierung (Entscheidungstheoretisches Modell)

Die Autoren formalisieren die Intuition, dass Code eine „Kanonisierung“ natürlicher Sprache ist. Sie schlagen ein lineares Modell vor, bei dem:

Beide Spuren einen Kern ( $B$ ) teilen, der entscheidungsrelevante algorithmische Informationen enthält (z. B. Rekursionsrelationen).
Natürliche Sprachspuren zusätzliche Störvariationen ( $\eta_N$ ) enthalten, wie etwa Paraphrasierung, Verbosität und stilistische Entscheidungen, die die Antwort nicht verändern.
Theorem: Unter diesem Modell ist Code repräsentations-nicht-inferior gegenüber natürlicher Sprache. Die zusätzliche Störung in der natürlichen Sprache erhöht das Risiko (Fehler) für Finite-Sample-Lerner, ohne zusätzlichen Signalwert zu liefern. Somit sollte eine Änderung der Repräsentation allein keine signifikanten Gewinne bringen, sofern die Kerninformation erhalten bleibt.

3. Rekonstruktions-Intervention

Um diese Theorie empirisch zu validieren, führen die Autoren eine „Rekonstruktions-Intervention“ durch. Sie nehmen Code-Spuren, die vom Modell generiert wurden, und übersetzen sie mittels einer festen Transformation zurück in natürliche Sprache. Sie stellen fest, dass diese übersetzten NL-Spuren eine Leistung erreichen, die mit den nativen NL-Spuren vergleichbar ist. Dies bestätigt, dass Code alle entscheidungsrelevanten Informationen beibehält und dass der „Verlust“ im NL-Reasoning nicht auf fehlenden algorithmischen Inhalten beruht, sondern auf der Präsenz von Störvariationen.

Ergebnisse

Leistungsvergleich

Auf dem 40-Aufgaben-Benchmark ergeben sich folgende Resultate:

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

Statistische Befunde:

Route 1 vs. Route 2: Der Unterschied beträgt +0,15 Prozentpunkte (pp), mit einem 95 % Konfidenzintervall von $[-0,30, +0,61]$ pp ( $p=0,39$ ). Dies deutet darauf hin, dass es keinen statistisch signifikanten Unterschied zwischen natürlicher Sprach-Reasoning und Code-Simulation gibt, wenn der Executor dasselbe LLM ist.
Route 2 vs. Route 3: Der Unterschied beträgt +31,47 pp, mit einem 95 % CI von $[+29,20, +33,71]$ pp ( $p < 0,001$ ). Dies deutet auf einen massiven, statistisch signifikanten Vorteil für die deterministische externe Ausführung gegenüber der LLM-Simulation hin, selbst wenn die Code-Spur identisch ist.

Skalierung der Schwierigkeit

Mit zunehmender Aufgabenkomplexität (gesteuert durch Parameter wie Stellenlänge oder Matrixgröße) behält Route 3 eine hohe Genauigkeit bei, während die Routen 1 und 2 signifikant degradieren.

Recovery-Analyse

Die Autoren analysieren Fälle, in denen Route 2 (Simulation) erfolgreich ist, aber Route 3 (Ausführung) fehlschlägt („Recovery Mass“).

Recovery Mass: 1,61 % (Fälle, in denen das LLM fehlerhaften Code korrekt simuliert oder den Ausführungsfehler ignoriert).
Execution-Win Mass: 33,08 % (Fälle, in denen die Ausführung erfolgreich ist, die LLM-Simulation jedoch fehlschlägt).
Dies bestätigt, dass das LLM Ausführungsfehler selten kompensiert; umgekehrt übertrifft der externe Solver die Fähigkeit des LLM zur Code-Simulation konsistent.

Bedeutung und Behauptungen

Das Paper behauptet, dass im evaluierten Kontext des algorithmischen Denkens gilt:

Die Repräsentation ist nicht der Flaschenhals: Die intermediäre Intervention der Verwendung von Code-Spuren verbessert die Leistung gegenüber natürlichen Sprachspuren nicht signifikant, wenn der Ausführungsmechanismus ein LLM bleibt. Die Leistungslücke zwischen Route 1 und Route 2 ist vernachlässigbar.
Die Ausführung ist der Flaschenhals: Der primäre Treiber der beobachteten Leistungssteigerungen in werkzeug-erweiterten Systemen ist die Zuverlässigkeit des externen Executors, nicht die strukturierte Natur der Code-Repräsentation selbst.
Mechanismus der Werkzeugnutzung: Der Vorteil der werkzeugbasierten Code-Nutzung ergibt sich daraus, dass sie die Übergabe einer generierten Spur an einen deterministischen Solver ermöglicht. Die Code-Repräsentation dient primär als Vehikel, um diese zuverlässige Ausführung zu ermöglichen, anstatt als überlegeres Reasoning-Substrat für das LLM selbst zu fungieren.

Die Autoren kommen zu dem Schluss, dass bei algorithmischen Aufgaben mit verifizierbaren Antworten der zentrale Vorteil der Werkzeugnutzung in der Fähigkeit besteht, die Ausführung an eine deterministische Umgebung zu delegieren, und nicht in der inhärenten Überlegenheit von Code als Reasoning-Format gegenüber natürlicher Sprache.