LLMs können Logikfehler noch nicht selbst korrigieren — ICLR 2024 Ergebnisse und Auswirkungen auf Finance AI

Dieses Paper ist der direkte Gegenpol zu den Arbeiten rund um CRITIC und Reflexion, die ich gelesen habe. Huang et al. (ICLR 2024) liefern ein einfaches, unbequemes Argument: Wenn LLMs versuchen, ihre Logik ohne externes Signal selbst zu korrigieren, verbessern sie sich nicht – sie werden schlechter. Direkt nach LOG-013 über CRITIC, wo werkzeuggestützte Kritik tatsächlich half, klärt dieses Paper, welche Art von „Selbstkorrektur“ real ist und was ein Artefakt des Versuchsaufbaus ist.

Das Paper

„Large Language Models Cannot Self-Correct Reasoning Yet“ von Jie Huang, Xinyun Chen, Swaroop Mishra, Huaixiu Steven Zheng, Adams Wei Yu, Xinying Song und Denny Zhou (Google DeepMind / UIUC) wurde auf der ICLR 2024 veröffentlicht. Die zentrale Behauptung ist eng gefasst, aber verheerend für eine bestimmte Klasse von Agenten-Designs: intrinsische Selbstkorrektur – also die Aufforderung an ein LLM, seine eigene Antwort ausschließlich anhand des eigenen Urteils ohne Ground-Truth-Signal zu überprüfen und zu revidieren – verschlechtert konsequent die Leistung bei Logik-Benchmarks. Die in mehreren früheren Arbeiten zur Selbstkorrektur berichteten Gewinne resultieren nach Ansicht der Autoren aus einem subtilen methodischen Fehler: Diese Arbeiten verwendeten Orakel-Labels (Oracle Labels), um zu entscheiden, wann die Korrektur beendet werden soll. Das bedeutet, dass das Modell nur bereits falsche Antworten korrigiert. Das ist keine Selbstkorrektur, sondern Orakel-gestütztes Filtern.

Kernideen

• Bei GSM8K startet GPT-4 mit einer Genauigkeit von 95,5 %. Nach einer Runde intrinsischer Selbstkorrektur sinkt sie auf 91,5 % und nach einer zweiten Runde auf 89,0 %. GPT-3.5 fällt über zwei Runden von 75,9 % auf 74,7 %.
• Bei CommonSenseQA ist der Abfall noch dramatischer: GPT-3.5 sinkt nach einer einzigen Selbstkorrekturrunde von 75,8 % auf 38,1 %, erholt sich in der zweiten Runde leicht auf 41,8 % – liegt aber immer noch katastrophal unter der Baseline.
• Die Analyse der Antwortänderungen bei GSM8K zeigt, dass das Modell häufiger korrekte Antworten in falsche umwandelt als falsche in korrekte. Die Netto-Richtung der Änderung ist schädlich.
• Orakel-gestützte Selbstkorrektur verbessert die Situation tatsächlich: GPT-4 bei GSM8K mit Orakel-Labels steigt von 95,5 % auf 97,5 %, und GPT-3.5 bei CommonSenseQA von 75,8 % auf 89,7 %. Dies erfordert jedoch das Wissen, welche Antworten falsch sind – was man im Produktiveinsatz nicht weiß.
• Multi-Agenten-Debatten, eine weitere beliebte Idee, schneiden schlechter ab als einfache Selbst-Konsistenz (Self-Consistency), wenn man das Inferenz-Budget angleicht. Mit insgesamt 9 Antworten erreicht Self-Consistency 88,2 % bei GSM8K; Multi-Agenten-Debatten erreichen nur 83,0 %.
• Eingeschränkte Generierung (CommonGen-Hard) scheint zunächst ein Gewinn für die Selbstkorrektur zu sein (44 % → 67 %), aber dieser Gewinn verpufft, wenn man einfach den initialen Prompt verbessert (81,8 %). Wenn der Start-Prompt bereits gut ist, schadet die Selbstkorrektur und senkt die Genauigkeit auf 75,1 %.

Was Bestand hat — und was nicht

Das Kernergebnis ist solide: Die Zahlen sprechen für sich. Wenn man GPT-4 auffordert, seine mathematischen Antworten erneut zu prüfen, ohne ihm zu sagen, welche falsch sind, verschlechtern sich die Antworten im Durchschnitt. Die Intuition des Papers ist ebenfalls richtig – LLMs können die Korrektheit ihrer eigenen Logik nicht zuverlässig beurteilen. Wenn sie sich also entscheiden, eine Antwort zu ändern, raten sie, und sie raten mindestens so oft falsch wie richtig.

Weniger überzeugend ist das Paper bei seinen Verallgemeinerungsansprüchen. Es testet ausschließlich Logik- und Wissensaufgaben. Es gibt Bereiche – Schreibstil, Einhaltung von Formatvorgaben, Reduzierung von Toxizität –, in denen iterative Überarbeitung wohl hilft, und das Paper klammert diese weitgehend aus. Die Autoren räumen dies beiläufig ein und stellen fest, dass „Selbstkorrektur bei Aufgaben, bei denen die Bewertung einfacher ist, effektiver sein kann“, testen dies jedoch nicht sorgfältig. Das CommonGen-Experiment zur eingeschränkten Generierung ist vielversprechend, aber einen unzureichenden initialen Prompt als Baseline zu verwenden und die resultierende Verbesserung als „Selbstkorrektur“ zu bezeichnen, ist derselbe methodische Fehler, den das Paper an anderen Arbeiten kritisiert.

Das Paper befasst sich auch nicht mit der Frage der trainierten Selbstkorrektur. Ein Follow-up aus dem Jahr 2025 (SCoRe, ICLR 2025, arXiv:2409.12917) zeigt, dass RL-trainierte Selbstkorrektur auf den eigenen Ausgaben des Modells +15,6 % bei MATH und +9,1 % bei HumanEval erreicht – eine echte intrinsische Verbesserung. Der Titel „cannot self-correct yet“ (können noch nicht selbst korrigieren) ist also besser gealtert als eine strengere Interpretation zulassen würde; die korrekte Interpretation lautet „können nicht durch Prompts zur Selbstkorrektur bewegt werden“, nicht „können nicht lernen, sich selbst zu korrigieren“.

Warum dies für Finance AI wichtig ist

Die Implikation für Ledger-Write-Back-Agenten ist konkret. Ein Agent, der eine Beancount-Journalbuchung generiert, sich dann selbst fragt „sieht das richtig aus?“ und revidiert, holt keine zweite Meinung ein – er führt Rauschen ein. Die Daten zeigen hier: Wenn die erste Antwort falsch war, ist die Eigenbewertung genauso wahrscheinlich dabei, eine richtige Antwort zu korrumpieren, wie eine falsche zu korrigieren.

Was dieses Paper bestätigt, ist die Design-Einschränkung, die ich aus CRITIC gezogen habe: Selbst-Validierung ohne externes Orakel ist unzuverlässig. Speziell für Beancount ist das externe Orakel verfügbar und günstig – Saldenprüfungen (Balance Assertions) laufen in Millisekunden ab, Kontonamen werden gegen einen bekannten Kontenrahmen validiert, Beträge müssen auf den Cent genau aufgehen. Eine Agenten-Architektur, die eine vorläufige Buchung einreicht, bean-check ausführt und jeden Fehler als konkret strukturiertes Feedback zurückleitet, unterscheidet sich grundlegend von einer, die das Modell bittet, „deine Journalbuchung zu überprüfen“. Erstere nutzt die Ledger-Engine als Orakel. Letztere verlässt sich auf denselben Logikmechanismus, der den Fehler überhaupt erst verursacht hat.

Es gibt hier auch eine subtilere Lektion über Prompt-Design. Das CommonGen-Experiment zeigt, dass die Selbstkorrektur die Leistung verschlechtert, wenn der Prompt bereits präzise und explizit ist. Das bedeutet: Wenn wir Mühe in das Schreiben sehr klarer Transaktions-Parsing-Prompts investieren – solche, die alle Beancount-Syntaxregeln explizit nennen –, kann das Hinzufügen einer Selbstkorrekturschleife obendrauf die Genauigkeit aktiv beeinträchtigen. Die richtige Architektur schaltet die Selbstkorrektur wahrscheinlich nur bei einer fehlgeschlagenen externen Prüfung ein, nicht bei jeder Generierung.

Was man als Nächstes lesen sollte

• SCoRe: Training Language Models to Self-Correct via Reinforcement Learning (arXiv:2409.12917, ICLR 2025) — RL-basierter Ansatz, der die ersten echten intrinsischen Selbstkorrekturgewinne erzielt; notwendiger Kontext, um zu verstehen, was das aktuelle Paper ausschließt oder zulässt.
• When Can LLMs Actually Correct Their Own Mistakes? A Critical Survey of Self-Correction of LLMs (TACL 2024) — systematische Taxonomie, wann Selbstkorrektur funktioniert, mit Unterscheidung zwischen intrinsischen, trainingsbasierten und werkzeuggestützten Varianten.
• Self-Refine: Iterative Refinement with Self-Feedback (NeurIPS 2023) — das primäre Paper, das Huang et al. kritisieren; das Lesen beider Papers nacheinander klärt genau, wo die Annahme der Orakel-Labels eingebettet ist.