Selbstkorrektur-Schleifen: Wenn das Modell seine eigene Arbeit prüft

Die Idee klingt bestechend einfach: Wenn die erste Antwort des Modells nicht gut genug ist, soll das Modell sie eben selbst prüfen und nachbessern. Ein zweiter Durchlauf, vielleicht ein dritter, und die Qualität steigt wie von selbst. So landet die Selbstkorrektur-Schleife in vielen Architekturen, oft ohne dass jemand gemessen hätte, was sie tatsächlich bringt.

Die ehrliche Antwort aus der Praxis ist unbequem: Manchmal verbessert der zweite Durchlauf das Ergebnis deutlich, manchmal verdoppelt er nur Kosten und Latenz, und gelegentlich macht er die Antwort sogar schlechter. Welcher Fall eintritt, hängt nicht vom Modell ab, sondern von der Art des Fehlers, den die Schleife korrigieren soll. Wer das versteht, kann Selbstkorrektur gezielt einsetzen statt flächendeckend.

Reflection und Critic: zwei Muster, ein Prinzip

Zwei Grundmuster dominieren. Bei der Reflection bekommt dasselbe Modell seine eigene Antwort mit einem Prüfauftrag zurück: Lies das noch einmal, prüfe gegen die Anforderungen, verbessere, was fehlt. Beim Critic-Muster ist die Prüfung eine getrennte Rolle mit eigenem Prompt, oft mit einem anderen, manchmal kleineren Modell besetzt. Der Critic bewertet gegen definierte Kriterien und liefert strukturiertes Feedback, der Erzeuger überarbeitet auf dieser Grundlage.

Das gemeinsame Prinzip: Aus einem Durchlauf werden zwei oder mehr, und man tauscht Kosten und Latenz gegen die Hoffnung auf Qualität. Der Critic ist dabei meist die stärkere Variante, weil die getrennte Rolle mit expliziten Kriterien weniger dazu neigt, die eigene Arbeit wohlwollend durchzuwinken. Aber auch er ist nur so gut wie die Kriterien, die man ihm gibt.

Wo Selbstkorrektur zuverlässig hilft

Es gibt eine Klasse von Fehlern, bei der die Schleife verlässlich funktioniert: Fehler, die sich anhand expliziter Kriterien erkennen lassen und deren Prüfung leichter ist als die Erzeugung.

• Format und Struktur: fehlende Pflichtfelder, verletzte Schemata, überschrittene Längenvorgaben. Der Prüfauftrag ist eindeutig, das Urteil ebenso.
• Vollständigkeit gegen explizite Anforderungen: Wenn die Aufgabe fünf Punkte verlangt und die Antwort vier enthält, ist das für einen zweiten Durchlauf gut erkennbar und gut behebbar.
• Verstöße gegen klar formulierte Regeln: verbotene Inhalte, falscher Ton, fehlende Quellenangabe, sofern die Regel im Prüf-Prompt präzise steht.

Der gemeinsame Nenner: Das Kriterium liegt außerhalb des strittigen Inhalts. Das Modell muss nicht wissen, ob eine Aussage wahr ist, sondern nur, ob die Antwort einer überprüfbaren Vorgabe genügt. Genau dafür sind Sprachmodelle als Prüfer brauchbar.

Wo sie wenig bringt

Die Enttäuschung beginnt bei der faktischen Korrektheit. Ein Modell, das eine Angabe erfunden hat, erkennt sie beim zweiten Lesen selten als erfunden, denn es fehlt die externe Referenz. Die Schleife bestätigt dann mit großer Geste, was schon vorher falsch war. Ohne Zugriff auf eine Quelle, ein Dokument oder ein Tool, das Fakten nachschlagen kann, bleibt die faktische Prüfung durch das Modell selbst ein Ratespiel.

Die zweite Schwäche sind vage Kriterien. Ein Prüfauftrag wie mach es besser erzeugt keine Konvergenz, sondern Oszillation: Der Critic findet immer etwas, der Erzeuger formuliert um, die nächste Runde findet wieder etwas. Dazu kommt die Neigung zur Überkorrektur, bei der auch richtige Teile der Antwort verschlimmbessert werden. Eine Schleife ohne präzises Kriterium ist kein Qualitätsmechanismus, sondern ein Token-Verbrenner mit gutem Gewissen.

Abbruchkriterien und Retry-Budgets

Jede Schleife braucht ein definiertes Ende, sonst definiert es die Kostenabrechnung. Bewährt haben sich drei Abbruchbedingungen, die gemeinsam gelten:

• Eine harte Obergrenze an Durchläufen. Ein bis zwei Korrekturrunden reichen in der Regel. Was danach noch falsch ist, wird durch weitere Runden selten richtig.
• Abbruch bei Bestehen. Sobald der Prüfer keine Beanstandung mehr hat, endet die Schleife. Das klingt trivial, fehlt aber erstaunlich oft.
• Abbruch bei Stagnation. Kommt dieselbe Beanstandung zweimal, dreht die Schleife durch. Dann ist Eskalation der richtige Weg: an einen Menschen, in einen Fehlerpfad oder in einen degradierten Modus.

Dazu gehört ein Retry-Budget in Tokens oder Kosten pro Vorgang, damit ein einzelner hartnäckiger Fall nicht unbemerkt teuer wird. Und vor allem gehört die Schleife in die Evals: Wie oft korrigiert sie tatsächlich etwas, wie oft ändert sie nichts, wie oft verschlechtert sie. Ohne diese Messung ist jede Selbstkorrektur ein Glaubensbekenntnis.

Deterministische Checks zuerst

Der günstigste Prüfer ist kein Modell. Vieles, wofür Teams einen Critic einsetzen, prüft gewöhnlicher Code schneller, billiger und ohne Restzweifel: Schema-Validierung, Pflichtfelder, Längen, verbotene Begriffe, gültige Verweise. Bei generiertem Code ist die Messlatte noch klarer: Kompiliert er, bestehen die Tests. Ein Testlauf ist der ehrlichste Critic, den es gibt.

Daraus ergibt sich die sinnvolle Reihenfolge: erst die deterministischen Checks, und nur was dort besteht und trotzdem weiche Kriterien offen lässt, geht in die modellbasierte Prüfung. Häufig zeigt sich dabei, dass der deterministische Teil den Großteil der Fehler abfängt und die teure Schleife nur noch für einen kleinen Rest gebraucht wird. Das ist kein Schönheitsfehler der Architektur, sondern ihr Erfolg.

Fazit

Selbstkorrektur-Schleifen sind ein Werkzeug mit klarem Einsatzprofil, kein allgemeiner Qualitätsverstärker. Sie lohnen sich, wo explizite, prüfbare Kriterien existieren, allen voran Format und Vollständigkeit, und sie enttäuschen bei Fakten und vagen Ansprüchen. Wer sie einsetzt, gibt ihnen harte Abbruchkriterien und ein Budget, misst ihre Wirkung in Evals und lässt deterministische Checks den ersten Zugriff. Die Frage ist am Ende nicht, ob das Modell seine Arbeit prüfen kann, sondern ob es für diesen Fehlertyp der richtige Prüfer ist. Oft ist es das nicht, und ein Stück gewöhnlicher Code tut es besser.