Reflection
Bei Reflection kritisiert ein Modell seine eigene Ausgabe und überarbeitet sie anschließend, wobei es die Kritik als Feedback nutzt. Es ist eine leichtgewichtige Methode für ein einzelnes Modell, um Fehler zu finden und die Qualität bei Denk-, Codierungs- und Schreibaufgaben zu verbessern – auf Kosten zusätzlicher Aufrufe.
Definition
Reflection ist ein Pattern, bei dem ein Modell seine eigene Ausgabe anhand expliziter Kriterien überprüft, kritisiert und anschließend überarbeitet, wobei zusätzliche Inferenz für eine höhere Qualität in Kauf genommen wird.
Problem
Modelle liefern oft eine fehlerhafte erste Antwort, die sie verbessern könnten, wenn sie aufgefordert würden, ihre eigene Arbeit zu überprüfen. Ein einziger Durchlauf gibt ihnen jedoch keine Gelegenheit dazu.
Wann zu verwenden
Verwenden Sie Reflection, wenn ein Selbstüberprüfungsschritt die Ausgabe messbar verbessert und Sie eine einfachere Alternative zu einer Evaluator-Schleife mit zwei Modellen suchen – was bei Denk- und Codierungsaufgaben häufig der Fall ist.
Lösung
Fordern Sie dasselbe Modell nach der Generierung einer Antwort auf, diese im Hinblick auf das Ziel (und jegliches Tool-Feedback wie Testergebnisse oder Fehler) zu kritisieren und anschließend eine überarbeitete Antwort auf Basis dieser Kritik zu erstellen. Wiederholen Sie dies für eine begrenzte Anzahl von Iterationen.
Reflection funktioniert am besten, wenn sie auf realen Signalen basiert – Ausführungsfehlern, Testausgaben, abgerufenen Fakten – und nicht auf reiner Selbsteinschätzung, die zu übermäßigem Vertrauen (Overconfidence) neigen kann.
Komponenten
Vorteile
- Verbessert die Qualität mit einem einzigen Modell – kein zweites System erforderlich.
- Effektiv, wenn auf Tool- oder Test-Feedback gestützt.
- Einfach in einen bestehenden Aufruf zu integrieren.
Risiken
- Selbstkritik kann zu optimistisch sein oder eigene Fehler übersehen.
- Zusätzliche Aufrufe erhöhen Latenz und Kosten.
- Ohne Grounding sind die Qualitätsgewinne begrenzt.
Wann nicht zu verwenden
- Wenn Sie eine objektive externe Prüfung haben – nutzen Sie Evaluator-Optimizer.
- Wenn ein einziger Durchlauf die Anforderungen bereits erfüllt.
- Wenn das Latenzbudget sehr knapp bemessen ist.
Technologien
Beispiele
- Ein Coding-Agent, der Testfehler liest und seinen eigenen Patch korrigiert.
- Eine Denkaufgabe (Reasoning), bei der das Modell seine Schritte vor der Antwort nochmals überprüft.
- Ein Entwurf, den das Modell vor der Fertigstellung auf Lücken überprüft.
Praxisbelege
- Kontext
- Aufgaben, bei denen die Ausgabequalität wichtiger ist als Latenz oder Kosten – wie Entwurfserstellung, Codegenerierung, Analyse – und bei denen Fehler bei der Überprüfung erkennbar sind.
- Szenario
- Nach der Erstellung einer ersten Antwort bewertet das Modell (oder ein separater Kritiker) diese anhand konkreter Kriterien und erstellt eine überarbeitete Version; die Schleife ist auf ein oder zwei Durchläufe begrenzt.
- Technologie
- Eine Prompt-Kette nach dem Prinzip „Kritik, dann Überarbeitung“, idealerweise gestützt durch externe Signale (Tests, Tools, ein separater Evaluator) für kritische Aufgaben.
- Last
- Jeder Reflection-Durchlauf verdoppelt mindestens die Anzahl der Aufrufe, weshalb er gezielt nur auf Ausgaben angewendet wird, die diesen Mehraufwand rechtfertigen.
- Ergebnisse
- Beobachtetes Muster: Reflection steigert die Qualität dort, wo das Modell seine eigenen Fehler tatsächlich erkennen kann, kann jedoch korrekte Antworten übermäßig überarbeiten (Over-Revision) und verdoppelt mindestens die Kosten. Messen Sie die Qualitätssteigerung anhand eines Evaluierungs-Sets, bevor Sie darauf vertrauen, und bevorzugen Sie bei kritischen Aufgaben externe Signale.
KPIs
- Qualitätssteigerung durch Reflection
- Gemessene Verbesserung der Ausgabequalität mit dem Reflection-Schritt im Vergleich zu ohne; wenn sie nicht messbar ist, rechtfertigt der Schritt seine Kosten nicht.
- Selbstkorrekturrate
- Anteil echter Fehler, die das Modell bei der Überprüfung erkennt und behebt – im Unterschied zu rein kosmetischen Bearbeitungen.
- Zusätzliche Latenz & Kosten
- Reflection verdoppelt mindestens die Anzahl der Aufrufe; stellen Sie den Mehraufwand der gewonnenen Qualität gegenüber.
- Over-Revision-Rate
- Wie oft Reflection eine bereits gute Antwort durch nachträgliches Zweifeln verschlechtert.
Beobachtete Fehlermuster
- Blinde Flecken bei der Selbsteinschätzung: Ein Modell kann seine eigenen Fehler oft nicht erkennen, sodass Reflection diese übersieht.
- Over-Revision: Das Modell „korrigiert“ eine richtige Antwort und verschlechtert sie dadurch.
- Kosten und Latenz verdoppeln sich (oder mehr) bei nur geringem oder gar keinem Qualitätsgewinn.
- Falsches Vertrauen: Das Modell behauptet, die Ausgabe sei nun korrekt, obwohl sie es nicht ist.
Lessons Learned
- Messen Sie die Steigerung; Reflection lohnt sich nur dort, wo sie die Qualität nachweislich verbessert.
- Bevorzugen Sie bei kritischen Aufgaben externe Signale (Tests, Tools, einen separaten Evaluator) gegenüber reiner Selbstkritik.
- Begrenzen Sie Reflection auf ein oder zwei Durchläufe – der Nutzen nimmt schnell ab und die Kosten summieren sich.
- Geben Sie dem Reflection-Schritt konkrete Kriterien an die Hand, statt eines vagen „Verbessere dies“.
FAQs
- Reflection oder Evaluator-Optimizer?
- Reflection nutzt ein einziges Modell zur Selbstkritik (einfacher); Evaluator-Optimizer nutzt einen separaten Evaluator (präziser, weniger voreingenommen). Wählen Sie danach aus, wie zuverlässig die Selbsteinschätzung für Ihre Aufgabe ist.
- Hilft Reflection immer?
- Sie hilft am meisten, wenn sie auf realem Feedback wie Testergebnissen oder Fehlern basiert. Reine Selbsteinschätzung kann zu optimistisch sein und bringt oft wenig Mehrwert.
- Wie viele Reflection-Runden sind sinnvoll?
- Halten Sie es in Grenzen – oft ein oder zwei. Aufgrund abnehmender Erträge und steigender Kosten lohnen sich lange Schleifen selten.