ISA-Bench: Wo LLMs beim Ausführen den Faden verlieren

Das Paper, das Datum, die Methode

Aditya Pola, Arkaprava Majumdar und Vineeth N. Balasubramanian haben ISA-Bench am 19. September 2026 auf arXiv veröffentlicht^[1]: ein Benchmark aus Programmierspielen mit reduzierten Befehlssätzen, gebaut um das rechnerische Schlussfolgern großer Sprachmodelle zu messen.

Die Designentscheidung verdient Aufmerksamkeit noch vor den Ergebnissen. Für jedes Spiel liefern die Autoren einen vollständigen Ausführungsstack: Parser, virtuelle Maschine und Verifizierer.

Dieser Stack macht die Bewertung automatisch und erzeugt strukturiertes Feedback. Das Modell erhält ein Urteil über das erzeugte Programm und versucht, es zu korrigieren. Der Code ist offen, das Protokoll bleibt also für Dritte überprüfbar.

Der Gegenstand der Messung verschiebt sich gegenüber der Tradition der Code-Benchmarks. Hier lautet die Frage, wie gut ein Modell innerhalb eines Rechenmodells schlussfolgert, das es kaum gesehen hat.

Python und Java als Zerrspiegel

Die Autoren gehen von einer klaren Feststellung aus: Benchmarks zur Code-Generierung bewerten überwiegend Sprachen, die in den Trainingsdaten gut vertreten sind, Python und Java an erster Stelle. Innerhalb dieses Rahmens arbeitet das Modell mit Mustern, die es millionenfach gelesen hat.

Die Form dieser Tests hat ein präzises Geburtsdatum. Die Arbeit von 2021, die HumanEval einführte, 164 handgeschriebene Programmieraufgaben in Python^[2], hat ein Format festgeschrieben, das die Literatur jahrelang reproduziert hat.

Dieses Format misst eine reale Kompetenz. Es misst auch eine enge Kompetenz: idiomatischen Code in einer Sprache zu schreiben, die das Modell in großer Menge gelesen hat.

Der logische Sprung kommt später, in den Folien der Entscheider. Ein hoher Wert bei Python wird zum Beweis, dass das System «programmieren kann», und von dort zum Beweis, dass es über unbekannte Probleme schlussfolgern kann. Die mit diesem Benchmark gesammelte Evidenz trennt diese beiden Dinge.

Arithmetik aus einer einzigen Instruktion

Die beschriebenen Aufgaben verlangen etwas anderes als Anwendungscode. Der Text nennt drei Beispiele: Arithmetik aus einer einzigen Subtraktionsinstruktion herleiten, parallele Programme auf kommunizierenden Knoten koordinieren, Logikgatter in Schaltkreisen verdrahten.

Es sind Probleme, bei denen die Strategie mehr zählt als die Bibliothek.

Ein Modell, das die Subtraktion als einzige Primitive vorfindet, muss Addition, Multiplikation und Kontrollfluss von dort aus konstruieren. Das Gedächtnis für Python-Muster hilft dabei wenig. Nötig sind eine korrekte Kette von Schritten und eine getreue Übertragung in einen kargen Befehlssatz.

Diese Aufgabenfamilie hat eine für Evaluatoren nützliche Eigenschaft: Kontamination durch Trainingsdaten bleibt unwahrscheinlich. Die Instruktionen sind künstlich, die Verifizierer deterministisch, die Punktzahl stammt aus der tatsächlichen Ausführung des Programms.

Reasoning-Modelle legen zu, unbekannte Syntax hält stand

Das erste Ergebnis betrifft die Hierarchie zwischen Modellfamilien. Reasoning-Modelle erzielen höhere durchschnittliche Lösungsquoten als codespezialisierte Modelle und als Generalisten.

Die Unterscheidung zwischen diesen Familien ist auch anderswo dokumentiert. Der Qwen3 Technical Report von 2025^[3] beschreibt eine Architektur, die erweitertes Denken und direkte Antwort im selben Modell vereint, mit regulierbarem Reasoning-Budget.

Das zweite Ergebnis relativiert das erste. Unbekannte Syntax bleibt eine vorrangige Fehlerquelle, auch bei den Modellen, die besser schlussfolgern.

Beide Befunde zusammen gelesen, verändert sich die Diagnose. Erweitertes Schlussfolgern hilft, den Weg zu finden, und lässt das Problem offen, ihn in einer Sprache aufzuschreiben, die das Modell kaum beherrscht. Der Zugewinn endet vor der Auslieferung.

Der Reasoning-Execution-Gap, im Klartext

Der methodische Beitrag der Arbeit ist die Analyse des Reasoning-Execution-Gap, von den Autoren zu REG abgekürzt. Es geht um den Abstand zwischen zwei Momenten: eine plausible Rechenstrategie zu erkennen und sie als korrektes Programm in der Ziel-ISA auszudrücken.

Die Autoren beschreiben diese Kluft als wiederkehrend.

Das Wort «wiederkehrend» wiegt schwerer, als es scheint. Es zeigt einen strukturellen Defekt des Generierungsprozesses an, im Unterschied zu einem zufälligen Stolpern über eine schwierige Aufgabe. Die Strategie ist da, ihr Ausdruck gibt nach.

Für wer Benchmark-Werte liest, ist der REG die fehlende Variable. Eine aggregierte Lösungsquote summiert zwei verschiedene Fehler: das Problem falsch durchdacht und eine gute Idee falsch übertragen. Die beiden Ursachen verlangen unterschiedliche Investitionen, und ein einzelner Wert vermischt sie in einer einzigen Zahl.

Iteratives Feedback wirkt mit unterschiedlicher Intensität

Der Ausführungsstack erlaubt einen zweiten, informierten Versuch: der Verifizierer sagt, was schiefgelaufen ist, das Modell probiert erneut. Mit diesem Zyklus lösen die Modelle mehr Aufgaben.

Das interessante Detail liegt in der Streuung. Die Autoren schreiben, dass die Zugewinne zwischen den verschiedenen Befehlssatzarchitekturen erheblich schwanken.

Eine hohe Varianz zwischen Umgebungen deutet darauf hin, dass Feedback dort hilft, wo das Modell schon eine brauchbare Repräsentation der Zielsprache besitzt. Wo diese Repräsentation dürftig ist, bringt der Korrekturzyklus wenig. Feedback verstärkt vorhandene Kompetenz mehr, als es sie erzeugt.

Diese Lesart trifft agentische Architekturen unmittelbar. Ein Agent, der sich in einer vertrauten Domäne selbst korrigiert, verbessert sich schnell; derselbe Agent dreht in einer seltenen Domäne leer und verbraucht bei jedem Durchgang Rechenbudget.

Was der öffentliche Text sagt und was er verschweigt

Hier braucht es Präzision über die Grenzen der Quelle. Das öffentliche Abstract nennt Richtungen («höher», «schwanken erheblich») und lässt die Größenordnungen aus: Zahl der Spiele, Zahl der getesteten Modelle, Lösungsquoten pro Architektur, operationale Definition des REG.

Die Arbeit ist in vollständiger Fassung sowie auf alphaXiv^[4] einsehbar, wo die öffentliche Diskussion den Text begleitet.

Eine richtungsweisende Angabe hat einen anderen Wert als eine quantifizierte. Sie stützt eine qualitative Diagnose, und sie stützt kaum einen Anbietervergleich oder eine feine Allokationsentscheidung.

Die Methode bleibt der belastbare Teil der Ankündigung. Ein Benchmark mit Parser, virtueller Maschine und Verifizierer für jede Aufgabe erzeugt replizierbare Messungen, und der offene Code öffnet die Tür zur unabhängigen Prüfung durch andere Forschungsgruppen.

Was sich für Budgetverantwortliche ändert

Für ein Investitionskomitee ist die Konsequenz begrenzt und konkret. Ein Wert zur Code-Generierung in Python misst eine spezifische Kompetenz, und seine prädiktive Gültigkeit für ressourcenarme Domänen bleibt eine eigene Dimension, weitgehend noch zu quantifizieren.

Die Kluft zwischen der richtigen Strategie und dem korrekten Programm ist der Ort, an dem das Auslieferungsrisiko wohnt.

Für einen Chief Analytics Officer berührt der Punkt die Infrastruktur. Ein nützlicher Korrekturzyklus verlangt, was die Autoren gebaut haben: einen deterministischen Verifizierer, eine Ausführungsumgebung, ein für das Modell lesbares Fehlersignal. Viele Unternehmenspipelines bieten stattdessen eine Logdatei.

Für ein Board ist die zu revidierende These die bequemste: dass Kompetenz im Programmieren eine einzige, übertragbare Fähigkeit sei. Die Evidenz dieser Arbeit zerlegt sie in zwei Teile, und die zwei Teile verbessern sich in unterschiedlichem Tempo.