CRITIC: Warum die LLM-Selbstkorrektur externes Werkzeug-Feedback erfordert

Ich habe CRITIC (Gou et al., ICLR 2024) gelesen und dabei darüber nachgedacht, was passiert, nachdem ein Finanzagent einen Fehler macht. Reflexion hat uns gelehrt, dass Agenten über Episoden hinweg aus Fehlern lernen können. CRITIC stellt eine präzisere Frage: Kann ein LLM seine eigenen Fehler innerhalb eines einzigen Generierungsdurchgangs erkennen und beheben – und wenn ja, was benötigt es dafür tatsächlich?

Das Paper

CRITIC führt ein Framework ein, bei dem ein Sprachmodell eine erste Ausgabe generiert und dann eine Verifizieren-dann-Korrigieren-Schleife unter Verwendung externer Werkzeuge durchläuft – eine Such-API für Faktenbehauptungen, einen Python-Interpreter für Code und Arithmetik sowie einen Toxizitäts-Klassifizierer für die Moderation von Inhalten. Die Schleife läuft über eine feste Anzahl von Iterationen (das Paper berichtet von effektiven Ergebnissen bei etwa drei Korrekturen) und erzeugt eine verfeinerte Ausgabe, die die Autoren anhand von freiformatigen Fragenbeantwortungen (TriviaQA, AmbigNQ, HotpotQA), mathematischer Programmsynthese und Toxizitätsreduzierung bewerten.

Die zentrale Behauptung ist nicht, dass LLMs sich von selbst korrigieren können. Es ist fast das Gegenteil: Der Wert von CRITIC ergibt sich gerade daraus, dass die Kritik in einem externen Signal verankert wird, das das Modell nicht fälschen kann. Ohne die Such-API schrumpfen die QA-Verbesserungen auf fast Null oder kehren sich um. Das Framework funktioniert, weil das Werkzeug dem Modell etwas mitteilt, das es tatsächlich nicht wusste, und nicht, weil das Modell zu einem zuverlässigen Selbstprüfer wird.

Kernideen

• Angewendet auf ChatGPT erzielt CRITIC eine Verbesserung des F1-Scores um durchschnittlich 7,7 Punkte über drei Open-Domain-QA-Aufgaben hinweg sowie absolute Gewinne von 7,0 Prozentpunkten bei drei mathematischen Reasoning-Benchmarks.
• Die Toxizitätsreduzierung ist das beeindruckendste Einzelergebnis: eine Verringerung der Toxizitätswahrscheinlichkeit im evaluierten Datensatz um 79,2 %.
• Das Entfernen der Such-API führt dazu, dass die QA-Leistung entweder stagniert oder abnimmt – die intrinsische Selbstkritik-Fähigkeit des Modells ist für faktenbasierte Aufgaben nahezu nutzlos.
• Die Schleife konvergiert schnell: Drei Korrekturrunden erzielen den Großteil des Gewinns, danach gibt es abnehmende Erträge.
• Das Framework ist modellagnostisch und erfordert kein Fine-Tuning; es funktioniert mit Black-Box-APIs, einschließlich Text-Davinci-003 und ChatGPT.
• CRITIC übertrifft die Selbstkonsistenz (Mehrheitsentscheidung über mehrere Stichproben) bei den meisten Aufgaben, was bedeutend ist, da Selbstkonsistenz keine Werkzeugkosten pro Schritt verursacht.

Was Bestand hat – und was nicht

Das empirische Kernergebnis ist solide: Externes Werkzeug-Feedback verbessert die Ergebnisse erheblich, und die Ablationsstudie, die die Such-API entfernt, ist ein vernichtendes Urteil für Befürworter naiver Selbstkorrektur. Das Paper ist zudem ehrlich in Bezug auf den Mechanismus – die Gewinne stammen vom Werkzeug, nicht von einer neu entstandenen metakognitiven Fähigkeit.

Was meiner Meinung nach zu wenig untersucht wurde, ist die Taxonomie der Fehlermodi. Wann generiert das Modell eine schlechte Kritik, die es weiter von der richtigen Antwort entfernt? Das Paper berichtet über die Durchschnittsleistung, aber die Varianz über Aufgaben und Fragetypen hinweg wäre für den Einsatz enorm wichtig. In einem finanziellen Kontext ist das schlimmste Ergebnis nicht „keine Verbesserung“ – es ist eine plausibel klingende Korrektur, die einen neuen Fehler einführt.

Die Entscheidung, bei drei Iterationen zu deckeln, wird eher als praktische Bequemlichkeit denn als prinzipielles Abbruchkriterium dargestellt. Drei Runden mögen für TriviaQA funktionieren, wo es eine Grundwahrheit gibt, auf die man hinarbeiten kann. In einem Bereich wie der Hauptbuch-Abstimmung, in dem die „richtige“ Antwort eine Argumentation über mehrere Dokumente und Domänenwissen erfordert, ist es nicht offensichtlich, dass drei Werkzeugaufrufe ausreichen – oder dass eine allgemeine Such-API überhaupt das richtige Verifizierungssignal liefert.

Das begleitende ICLR-2024-Paper „Large Language Models Cannot Self-Correct Reasoning Yet“ (Huang et al., arXiv:2310.01798) bestätigt CRITICs eigenen Befund aus der anderen Richtung: Ohne externes Feedback verschlechtert die Selbstkorrektur zuverlässig die Genauigkeit der Argumentation. Diese beiden Paper bilden zusammen ein kohärentes Bild – das, was man als „Selbstkorrektur“ bezeichnete, ist meist eine durch externes Feedback gesteuerte Verfeinerung, und diese Unterscheidung ist wichtig.

Warum dies für Finanz-KI wichtig ist

Die CRITIC-Schleife lässt sich natürlich auf das Problem der Rückschreibsicherheit bei Beancount-Agenten übertragen. Wenn ein LLM-Agent derzeit einen Buchungssatz vorschlägt – zum Beispiel die Kategorisierung einer Transaktion oder die Aufteilung einer Ausgabe –, gibt es keinen prinzipiellen Weg für ihn, seine eigene Ausgabe zu verifizieren, bevor sie auf die Festplatte geschrieben wird. Die Architektur von CRITIC schlägt ein konkretes Muster vor: Generieren Sie einen Kandidateneintrag, führen Sie dann eine Verifizierung gegen ein Werkzeug durch (eine Saldenprüfungsfunktion, eine Regel-Engine, eine Dublettenprüfung) und nutzen Sie die Ausgabe des Werkzeugs für eine Revision, bevor der Schreibvorgang erfolgt.

Das Toxizitäts-Ergebnis ist eine Analogie, die ich nützlich finde: Eine Reduzierung der Richtlinienverstöße um 79,2 % resultiert nicht daraus, dass das Modell die Regeln verinnerlicht – sie stammt von einem Klassifizierer, der Verstöße an das Modell zurückmeldet. Für ein Beancount-Hauptbuch wäre das Äquivalent ein Regel-Prüfer, der doppelt erfasste Transaktionen oder Kategorieverletzungen markiert und dieses Signal in den Revisionsdurchgang des Agenten einspeist. Der Agent muss nicht unabhängig wissen, dass die Regeln verletzt wurden; er benötigt das Signal des Werkzeugs.

Die entscheidende Einschränkung für den Finanzbereich ist die Abhängigkeit von der Such-API. Finanzagenten benötigen Verifizierungswerkzeuge, die domänenspezifisch sind: Integritätsprüfungen für Kontostände, Validatoren für den Kontenplan, Abfragen von Steuerregeln. Eine generische Websuche wird eine falsch klassifizierte Ausgabe wahrscheinlich nicht erkennen. Der Aufbau der richtigen Werkzeugebene für eine Korrektur im CRITIC-Stil im Rechnungswesen ist die eigentliche technische Arbeit – und das Paper geht auf das Design domänenspezifischer Werkzeuge überhaupt nicht ein.

Was Sie als Nächstes lesen sollten

• „Large Language Models Cannot Self-Correct Reasoning Yet“ (Huang et al., 2023, arXiv:2310.01798) – das direkte empirische Argument, dass intrinsische Selbstkorrektur scheitert; sollte zusammen mit CRITIC gelesen werden, da sie denselben Mechanismus aus entgegengesetzten Richtungen beleuchten.
• „Tree of Thoughts: Deliberate Problem Solving with Large Language Models“ (Yao et al., NeurIPS 2023, arXiv:2305.10601) – erweitert die Idee der einpfadigen Kritik und Korrektur auf einen Suchbaum über Zwischenschritte; relevant für mehrstufige Abstimmungen, bei denen der Agent verschiedene Wege erkunden und zurückkehren muss.
• „ToolBench: Facilitating Large Language Models in Mastering 16000+ Real-world APIs“ (Qin et al., 2023, arXiv:2307.16789) – untersucht, wie Agenten lernen, Werkzeugaufrufe auszuwählen und zu verketten, was das vorgelagerte Problem ist, das CRITIC als gegeben voraussetzt.