Es gibt einen bestimmten Moment, der jemanden, der KI gelegentlich nutzt, von jemandem trennt, der sie tatsächlich als System betreibt.
Es ist der Moment, in dem sie aufhören, diejenigen zu sein, die den Fehler bemerken.
Im Moment sieht die Schleife für die meisten Menschen so aus. Claude um etwas bitten. Die Ausgabe lesen. Etwas falsch bemerken. Darauf hinweisen. Eine korrigierte Version erhalten. Das lesen. Etwas anderes bemerken. Wieder darauf hinweisen. Du bist die Verifikationsschicht, manuell, jedes Mal, für jede einzelne Aufgabe.
Eine selbstkorrigierende Schleife entfernt dich vollständig aus dieser Position. Das System generiert, überprüft seine eigene Arbeit anhand eines realen Standards, erfasst, was es falsch gemacht hat, korrigiert es und zeigt dir erst dann das Ergebnis. Wenn du die Ausgabe siehst, sind die offensichtlichen Fehler bereits erkannt und behoben. Was dir bleibt, ist das Urteil über die Dinge, die wirklich einen Menschen brauchen, nicht das Korrekturlesen des ersten Entwurfs einer Maschine.
Dies ist der vollständige Aufbau. Am Ende wirst du die genaue Architektur, die genauen Prompts und die genauen Fehlermodi haben, um zu testen, bevor du dem Ganzen etwas wirklich Wichtiges anvertraust.
Warum das nicht dasselbe ist wie einfach zweimal zu fragen
Der offensichtliche erste Impuls ist, das Modell einfach zu bitten, seine eigene Arbeit in derselben Unterhaltung zu überprüfen. „Überprüfe, was du gerade geschrieben hast, und korrigiere alle Fehler." Das hilft ein wenig. Es baut jedoch keine echte selbstkorrigierende Schleife auf, und zu verstehen, warum, ist die gesamte Grundlage für das Folgende.
Ein Modell, das seine eigene Ausgabe im selben Kontext überprüft, mit derselben Argumentation, die den Fehler ursprünglich verursacht hat, neigt dazu, seine eigene Arbeit zu verteidigen, anstatt sie wirklich zu hinterfragen. Dies ist kein Fehler, der nur bei einem bestimmten Modell auftritt. Es ist ein strukturelles Problem. Derselbe Durchlauf, der eine plausibel klingende, aber falsche Antwort generiert hat, ist nicht gut positioniert, um zu bemerken, dass sie falsch ist, denn von innen heraus klingt die Antwort immer noch plausibel. Die Frage „Bist du sicher?" führt häufiger zu Beruhigung als zu einer echten erneuten Prüfung.
Die Lösung ist nicht, besser zu fragen. Es ist die Architektur. Eine echte selbstkorrigierende Schleife trennt die Arbeit der Erstellung einer Antwort von der Arbeit der Beurteilung, indem sie einen anderen Durchlauf, einen anderen Prompt und idealerweise einen völlig anderen Bezugsrahmen verwendet, sodass das Urteil nicht durch dieselben blinden Flecken kontaminiert wird, die den Fehler verursacht haben.
Die drei Rollen, die jede selbstkorrigierende Schleife braucht
Jedes funktionierende selbstkorrigierende System, unabhängig von der spezifischen Aufgabe, reduziert sich auf drei verschiedene Rollen. Diese Rollen klar zu verstehen, ist wichtiger als jeder spezifische Prompt unten, denn sobald du sie siehst, kannst du für fast jede Aufgabe eine Schleife bauen, indem du die Einzelheiten ausfüllst.
Der Builder (Ersteller). Produziert die eigentliche Ausgabe. Schreibt den Code, erstellt die Inhalte, recherchiert, führt die Aufgabe aus. Diese Rolle sollte den größten kreativen Spielraum und die wenigsten Einschränkungen erhalten, denn ihre Aufgabe ist es, einen ersten Versuch zu produzieren, keinen perfekten.
Der Judge (Richter). Erstellt nichts. Seine einzige Aufgabe ist es, die Ausgabe des Builders anhand eines spezifischen, schriftlichen Standards zu bewerten, nicht anhand eines vagen Qualitätsgefühls. Besteht der Code seine Tests? Entspricht der Entwurf der Aufgabenstellung? Beantwortet die Recherche tatsächlich die gestellte Frage? Der Judge sollte idealerweise Zugang zu etwas haben, das der Builder nicht hat – das ursprüngliche Quellmaterial, die Testsuite, das tatsächliche Anforderungsdokument –, sodass er eine unabhängige Ground Truth zum Überprüfen hat, anstatt nur dieselbe Ausgabe erneut zu lesen und eine neue Meinung zu bilden.
Der Manager. Liest das Urteil des Judges und entscheidet, was als Nächstes passiert. Zurück zum Builder mit spezifischem Feedback. An einen Menschen eskalieren. Aufgabe als abgeschlossen markieren. Hier lebt auch deine Abbruchbedingung – die Regel, die verhindert, dass die Schleife endlos läuft, wenn etwas nicht automatisch behoben werden kann.
Das entscheidende Gestaltungsprinzip für alle drei Rollen: Die Verifikation muss sich auf etwas außerhalb der eigenen Argumentation des Builders beziehen. Eine Testsuite. Ein ursprüngliches Quelldokument. Eine schriftliche Checkliste. Ein zweiter KI-Aufruf mit einer wirklich anderen Rahmung. Alles, was nicht einfach „dasselbe Modell, noch einmal gefragt, im selben Atemzug" ist.
Die Übergaben konstruieren
Die eigentliche Ingenieursarbeit in einer selbstkorrigierenden Schleife sind nicht clevere Prompts für jede Rolle. Es ist die Struktur dessen, was zwischen ihnen übergeben wird, und das ist der Teil, den die meisten Menschen, die ihre erste Schleife bauen, komplett überspringen und sich dann wundern, warum sich das System unvorhersehbar verhält.
Eine Übergabe benötigt drei Eigenschaften, um zuverlässig zu funktionieren. Ein definiertes Format, damit die empfangende Rolle nicht lockeren Text parsen und raten muss, worauf es ankommt. Ein definierter Auslöser, damit nicht der Builder entscheidet, wann er fertig ist. Und ein definierter Fehlerpfad, damit es einen festgelegten nächsten Schritt gibt, wenn etwas nicht sauber läuft, anstatt dass das System stillschweigend bricht oder endlos schleift.
In der Praxis bedeutet das, dass der Builder etwas Strukturiertes ausgeben sollte, nicht nur Konversationstext. Ein klares Ergebnis plus eine explizite Aussage darüber, bei welchen Punkten er unsicher ist. Der Judge bewertet dann diese strukturierte Ausgabe anhand eines schriftlichen Standards und gibt sein eigenes strukturiertes Urteil zurück – nicht einen Absatz voller abwägender Prosa, sondern ein klares „Bestanden", „Nicht bestanden" oder „Überarbeitung nötig", mit dem spezifischen Grund. Der Manager liest dieses strukturierte Urteil, nicht den Rohinhalt, und entscheidet die nächste Aktion basierend auf im Voraus festgelegten Regeln, nicht indem er im Moment eine spontane Beurteilung improvisiert.
Hier ist eine Vorlagenstruktur, die für die meisten Aufgaben funktioniert, egal ob es sich um Schreiben, Code oder Recherche handelt:
1BUILDER AUSGABEFORMAT2Ergebnis: [die eigentliche Ausgabe]3Vertrauen: [hoch / mittel / niedrig]4Bekannte Unsicherheiten: [alles, worüber du dir nicht sicher bist, explizit genannt]5Getroffene Annahmen: [alles, was du angenommen hast, ohne dass es dir gesagt wurde]67JUDGE URTEILSFORMAT8Urteil: [BESTANDEN / NICHT BESTANDEN / ÜBERARBEITUNG NÖTIG]9Geprüft gegen: [der verwendete spezifische Standard, z.B. die ursprüngliche Aufgabenstellung, die Testsuite, das Quelldokument]10Spezifische gefundene Probleme: [genaue Probleme, kein allgemeiner Eindruck]11Vertrauen in dieses Urteil: [hoch / mittel / niedrig]1213MANAGER AKTION14Bei BESTANDEN: als abgeschlossen markieren, an den Benutzer ausliefern.15Bei NICHT BESTANDEN oder ÜBERARBEITUNG NÖTIG: mit den spezifischen Problemen des Judges an den Builder zurücksenden. Überarbeitungszähler erhöhen.16Wenn der Überarbeitungszähler [N] überschreitet: Schleife stoppen, an einen Menschen eskalieren mit vollständiger Historie dessen, was versucht wurde und warum es fehlschlug.
Das sieht nach mehr Struktur aus als ein lockeres Hin und Her, und das ist es auch. Diese anfängliche Investition erkauft dir ein System, das sich beim hundertsten Durchlauf genauso verhält wie beim ersten, anstatt unvorhersehbar zu driften, während sich der Kontext ansammelt.
Der Judge braucht Ground Truth, nicht nur eine Meinung
Dies ist das wichtigste Prinzip im gesamten System, und es verdient seinen eigenen Abschnitt, weil es, wenn man es falsch macht, leise alles andere untergräbt.
Ein Judge, der nur die Ausgabe des Builders sieht, ohne unabhängige Referenz zum Überprüfen, kann nur die interne Konsistenz bewerten – ob die Ausgabe kohärent und gut formatiert erscheint. Er kann nicht die Korrektheit bewerten – ob die Ausgabe tatsächlich dem entspricht, was gefragt wurde, oder ob sie das eigentliche Problem löst. Eine selbstbewusst falsche Antwort, gut formatiert und intern konsistent, wird an einem Judge ohne Ground Truth jedes Mal vorbeikommen.
Für Codierungsaufgaben ist die Ground Truth die Testsuite, die tatsächliche Ausgabe beim Ausführen des Codes, die Lint-Ergebnisse, der Build-Status. Nicht „sieht dieser Code richtig aus", sondern „hat er tatsächlich bestanden, als er ausgeführt wurde".
Für Inhaltsaufgaben ist die Ground Truth das ursprüngliche Quellmaterial und die ursprüngliche Aufgabenstellung, Seite an Seite mit dem Entwurf. Nicht „liest sich das gut", sondern „lässt sich jede spezifische Behauptung in diesem Entwurf auf etwas tatsächlich in der Quelle zurückführen, und erfüllt das Stück tatsächlich jede Anforderung der Aufgabenstellung".
Für Rechercheaufgaben ist die Ground Truth die tatsächlichen Suchergebnisse und Quelldokumente, auf denen die Recherche basieren sollte. Nicht „klingt diese Zusammenfassung autoritär", sondern „kann jede Behauptung auf eine bestimmte Quelle zurückgeführt werden, und wurden die durchsuchten Quellen tatsächlich die relevanten?"
Wenn du nicht formulieren kannst, was die Ground Truth des Judges für deine spezifische Aufgabe ist, hast du noch keine selbstkorrigierende Schleife. Du hast eine Umformulierungsschleife, bei der der selbstbewusste Fehler des Builders selbstbewusst vom Judge umformuliert wird, anstatt tatsächlich erkannt zu werden.
Die Abbruchbedingung ist nicht optional
Der häufigste Weg, wie eine selbstkorrigierende Schleife zu einem teuren, außer Kontrolle geratenen Durcheinander wird, ist das Fehlen einer expliziten, harten Abbruchbedingung. Ohne eine solche können ein Builder und ein Judge unbegrenzt zyklieren, wobei jede Überarbeitung eine weitere Bewertung auslöst, jede Bewertung eine weitere Überarbeitung, während die Kosten steigen und niemand es bemerkt, bis die Rechnung kommt.
Eine echte Abbruchbedingung benötigt drei Komponenten, und alle drei sollten als explizite Logik erzwungen werden, nicht dem Urteil des Modells im Moment überlassen werden.
Eine maximale Iterationsanzahl. Eine harte Obergrenze für Überarbeitungszyklen, nach deren Erreichen der Manager gezwungen ist, an einen Menschen zu eskalieren, unabhängig davon, ob der Judge bereits zufrieden ist.
Eine Qualitätsschwelle, die tatsächlich messbar ist, nicht wünschenswert. „Gut genug" als Anweisung in einem Prompt ist keine Abbruchbedingung, denn es ist ein Vorschlag, den das Modell unter dem richtigen Druck irgendwann ignorieren kann und wird. Eine spezifische, überprüfbare Hürde – alle elf Testfälle bestanden, oder der Entwurf erfüllt alle fünf genannten Aufgabenanforderungen – ist eine Abbruchbedingung, weil sie mechanisch überprüft werden kann, anstatt jedes Mal subjektiv beurteilt zu werden.
Eine Kosten- oder Zeitobergrenze. Ein absolutes Budget, das die Aufgabe nicht überschreiten darf, unabhängig vom Zustand, in dem sie sich befindet, wenn diese Obergrenze erreicht wird. Dies ist die Schutzleiste, die dich speziell vor dem schlimmsten Fall schützt: einer wirklich unlösbaren Aufgabe, die schleift, bis jemand die Rechnung bemerkt.
ABBRUCHBEDINGUNGEN
Maximale Überarbeitungen: 3. Beim 3. fehlgeschlagenen Urteil anhalten und an einen Menschen
eskalieren, mit der vollständigen Überarbeitungshistorie. Keinen 4. Zyklus automatisch versuchen.
Qualitätsschwelle: Alle Punkte auf der Checkliste des Judges müssen BESTANDEN zeigen,
nicht „größtenteils bestanden" oder „nahe dran".
Budgetobergrenze: Wenn diese Aufgabe mehr als [X] Token oder
[Y] Minuten verbraucht hat, sofort anhalten, unabhängig vom aktuellen Zustand, und melden,
was abgeschlossen wurde und was noch übrig ist.
Schreibe diese in die tatsächliche Logik des Managers, nicht in eine weiche Anweisung innerhalb eines längeren Prompts, von der sich das Modell unter Druck freireden kann.
Ein ausgearbeitetes Beispiel: Selbstkorrigierende Inhaltserstellung
Um dies konkret zu machen, hier genau, wie die drei Rollen und die Abbruchbedingung für eine reale, häufige Aufgabe zusammenkommen: ein Quelldokument in einen fertigen Inhalt zu verwandeln, ohne dass ein Mensch manuell jeden Entwurf korrekturliest.
Der Builder erhält das Quellmaterial und die Aufgabenstellung und produziert einen Entwurf. Seine Ausgabe enthält den Entwurf selbst sowie eine explizite Vertrauensangabe und eine Liste von allem, bei dem er sich beim Schreiben unsicher war – eine bestimmte Zahl, bei der er nicht ganz sicher war, ob sie in der Quelle stand, eine Behauptung, die er eher abgeleitet als direkt gefunden hat.
Der Judge erhält den Entwurf und die Originalquelle nebeneinander, niemals den Entwurf isoliert. Er überprüft drei spezifische Dinge, jedes mit eigenem Bestanden/Nicht bestanden. Lässt sich jede faktische Behauptung im Entwurf auf etwas zurückführen, das tatsächlich in der Quelle vorhanden ist? Erfüllt der Entwurf jede spezifische Anforderung der Aufgabenstellung – Länge, Ton, erforderliche Abschnitte? Ist das Kernargument oder der Aufhänger tatsächlich vorhanden und nicht durch Füllmaterial verwässert? Der Judge gibt ein strukturiertes Urteil mit einem Bestanden oder Nicht bestanden für jede der drei Prüfungen separat zurück, denn dies in eine einzige Gesamtpunktzahl zusammenzufassen, verbirgt genau, welche Dimension fehlgeschlagen ist.
Der Manager liest dieses strukturierte Urteil. Ein sauberes Bestanden in allen drei Bereichen schickt den Entwurf in eine endgültige Ausgabewarteschlange. Ein Fehlschlag bei der Faktenprüfung schickt ihn zurück zum Builder mit der spezifischen nicht verifizierten Behauptung, die direkt markiert ist, nicht mit einer vagen Anweisung, „die Genauigkeit noch einmal zu überprüfen". Ein Fehlschlag bei der Einhaltung der Aufgabenstellung schickt ihn zurück mit der spezifischen fehlenden Anforderung. Nach drei fehlgeschlagenen Zyklen bei derselben spezifischen Prüfung stoppt der Manager die Schleife vollständig und eskaliert an einen Menschen mit der vollständigen Historie dessen, was versucht wurde, anstatt weiterhin ein Problem erneut zu versuchen, von dem das System bereits gezeigt hat, dass es es nicht selbst lösen kann.
Dies ist ein kleines System. Drei Rollen, ein strukturiertes Übergabeformat, eine explizite Abbruchbedingung. Es ist auch ein System, das du wirklich unbeaufsichtigt laufen lassen und der Ausgabe vertrauen könntest, denn jeder Fehlermodus hat einen definierten Pfad anstelle eines undefinierten.
Die Schleife testen, bevor du ihr vertraust
Bevor du dich bei etwas wirklich Wichtigem auf ein selbstkorrigierendes System verlässt, führe es absichtlich durch diese spezifischen Stresstests. Die meisten Schleifen, die im echten Einsatz versagen, hätten einen dieser Tests sofort nicht bestanden, wenn jemand sich die Mühe gemacht hätte, sie vorher zu überprüfen.
Der Test der unlösbaren Aufgabe. Gib dem Builder absichtlich eine Aufgabe, die er nach dem Standard des Judges nicht erfüllen kann. Erreicht der Manager korrekt die Iterationsobergrenze und eskaliert an einen Menschen, oder dreht er sich unbegrenzt weiter und verbrennt Kosten für eine Aufgabe, die nie erfolgreich sein wird?
Der Test der selbstbewussten Falschheit. Füttere den Judge mit einer Ausgabe, von der du bereits weißt, dass sie subtil falsch ist – etwas, das sich gut liest, aber einen spezifischen faktischen oder logischen Fehler enthält. Erwischt der Judge dies mit seiner Ground Truth-Referenz korrekt? Wenn der Judge etwas bestehen lässt, von dem du weißt, dass es kaputt ist, wird deine Ground Truth-Referenz nicht wirklich überprüft, oder die Prüfung ist zu oberflächlich.
Der Test des gleichen Modell-Blindfl ecks. Wenn dein Builder und Judge auf demselben zugrunde liegenden Modell laufen, lohnt es sich, dies direkt zu überprüfen. Füttere den Judge mit einer Ausgabe, die genau die Art von Fehler enthält, die dieses Modell charakteristischerweise macht. Wenn der Judge es durchwinkt, hast du eine Schleife gebaut, die ihre blinden Flecken zwischen den Rollen teilt, was den gesamten Zweck der Trennung zunichte macht. Ziehe in Betracht, ein wirklich anderes Modell oder zumindest eine bedeutungsvoll andere Prompt-Rahmung speziell für die Judge-Rolle zu verwenden.
Der Kostenausreißertest. Berechne den schlimmsten Fall durch dein System: maximale Überarbeitungen, teuerste Modellaufrufe, längste vernünftige Inhaltslänge, und arbeite aus, was das tatsächlich in echten Dollar und echter Zeit kostet. Wenn dich diese Zahl auf einer echten Rechnung erschrecken würde, sind deine Abbruchbedingungen noch nicht streng genug.
Diese vier Tests durchzuführen, bevor du einer selbstkorrigierenden Schleife etwas Reales anvertraust, fängt die überwältigende Mehrheit der Fehler, die sonst zum ersten Mal vor einem Kunden, einem Chef oder deinem eigenen Kontoauszug auftauchen würden.
Häufige Fehler, die ein ansonsten gutes Design leise zerstören
Selbst mit der richtigen Drei-Rollen-Architektur tauchen eine Handvoll spezifischer Implementierungsfehler immer wieder in völlig unterschiedlichen Bereichen auf, und sie im Voraus zu kennen, erspart dir, jeden auf die harte Tour neu zu entdecken.
Dem Judge erlauben, nur die Ausgabe des Builders zu sehen, ohne unabhängige Referenz. Dies ist der mit Abstand häufigste Fehler, und er verwandelt dein System leise von einer Korrektheitsprüfung in eine Kohärenzprüfung. Ein Judge, mit dem nichts zu vergleichen ist, kann dir nur sagen, dass die Ausgabe intern konsistent aussieht, niemals, ob sie tatsächlich richtig ist.
Jeder Rolle dasselbe Modell zu geben, mit nur einem dünnen Instruktionsunterschied obendrauf. Wenn der Judge dasselbe zugrunde liegende Modell wie der Builder ausführt, nur mit einem anderen Prompt, der ihm sagt, er solle „kritisch sein", erbt er oft dieselben blinden Flecken wie der Builder, weil es im Grunde derselbe Argumentationsprozess ist, nur mit einem anderen Hut. Wo das Budget es erlaubt, erzeugt ein wirklich anderes Modell für die Judge-Rolle echte Unabhängigkeit anstatt theatralischer Unabhängigkeit.
Den Manager als einfachen Durchgang zu behandeln, anstatt ihm ein echtes Gedächtnis für frühere Versuche zu geben. Ein Manager ohne Einblick in das, was bei dieser spezifischen Aufgabe bereits versucht wurde, wird bereitwillig dasselbe fehlgeschlagene Feedback ein zweites und drittes Mal an den Builder zurückschicken und jedes Mal dasselbe fehlgeschlagene Ergebnis produzieren, weil nichts im System sich daran erinnert, dass dieser genaue Ansatz bereits einmal fehlgeschlagen ist.
Die vier Stresstests zu überspringen, weil das System in dem einen Demo-Durchlauf, den alle genau beobachtet haben, einwandfrei funktioniert hat. Ein System, das sich korrekt verhält, während du es genau beobachtest, und ein System, das sich korrekt verhält, während es unbeaufsichtigt läuft, sind unterschiedliche Behauptungen. Nur die zweite ist der eigentliche Sinn, eine selbstkorrigierende Schleife überhaupt zu bauen. Wenn du die Fehlermodi nicht absichtlich getestet hast, weißt du nicht tatsächlich, welche Behauptung für dein System zutrifft.
Die Abbruchbedingung als weiche Anweisung statt als harte Logik zu schreiben. „Stopp, wenn es gut genug ist" in einem Prompt ist keine Abbruchbedingung, es ist ein Vorschlag, den das Modell unter dem richtigen Druck irgendwann übergehen kann und wird. Ein harter Iterationszähler, den der Manager mechanisch überprüft, bevor er einen weiteren Zyklus erlaubt, ist eine Abbruchbedingung. Der Unterschied zwischen diesen beiden ist enorm wichtig, wenn sich zum ersten Mal herausstellt, dass eine Aufgabe wirklich unlösbar ist.
Ein zweites ausgearbeitetes Beispiel: Selbstkorrigierender Code
Dasselbe Grundgerüst sieht anders aus, folgt aber identischer Logik, wenn die Aufgabe Code statt Inhalt ist, und der Vergleich beider nebeneinander macht klar, wie wenig sich tatsächlich zwischen den Bereichen ändert.
Der Builder ist hier ein Coding-Agent, der an einer definierten Aufgabe arbeitet – einem Bugfix, einem Feature, einem Refactoring. Seine strukturierte Ausgabe ist nicht nur der Code-Diff, sondern die tatsächliche Befehlsausgabe beim Versuch, ihn auszuführen, die Testergebnisse, die Lint-Ausgabe, der Build-Status, gebündelt in der Übergabe. Ein Builder, der Code produziert, ihn aber nie tatsächlich ausführt, erfüllt die Builder-Rolle nicht richtig, denn syntaktisch plausibler Code, der seine eigene Testsuite nicht besteht, ist schlimmer als gar kein Code, da er fertig aussieht, ohne fertig zu sein.
Der Judge überprüft drei spezifische, überprüfbare Dinge. Hat die Änderung die bestehende Testsuite bestanden, ohne dass die Tests selbst modifiziert wurden – denn ein Builder, der leise einen Test bearbeitet, um ihn bestehen zu lassen, ist ein spezifischer und überraschend häufiger Fehler, den es wert ist, direkt überprüft zu werden. Sind statische Analyse und Linting sauber? Adressiert der Diff tatsächlich die Aufgabe, die zugewiesen wurde, nicht ein verwandtes, aber anderes Problem, das der Builder unterwegs zu lösen beschlossen hat? Jedes davon erhält sein eigenes explizites Bestanden oder Nicht bestanden im strukturierten Urteil.
Der Manager leitet basierend darauf weiter, welche spezifische Prüfung fehlgeschlagen ist. Eine fehlgeschlagene Testsuite geht zurück zum Builder mit der genauen fehlgeschlagenen Testausgabe direkt angehängt, nicht einer generischen Anweisung, „die Tests zu reparieren". Eine Bereichsabweichung, bei der der Diff ein anderes Problem gelöst hat als das zugewiesene, eskaliert sofort an einen Menschen anstatt zu schleifen, denn das ist ein Urteilsfehler darüber, was die Aufgabe tatsächlich war, kein mechanischer Defekt, den der Builder einfach selbst durch Iteration beheben kann.
Beachte, dass das zugrunde liegende Gerüst hier – Builder erstellt und reicht mit Belegen ein, Judge prüft gegen spezifisch benannte Kriterien mit einem Pro-Check-Urteil, Manager leitet basierend auf genau dem weiter, welche Prüfung fehlgeschlagen ist – identisch mit dem obigen Beispiel der Inhaltserstellung ist. Dies ist die eigentliche Lektion, die es wert ist, mitgenommen zu werden, wenn man zwei verschiedene Bereiche nebeneinander sieht. Sobald du das Gerüst richtig hast, ist die Anwendung auf eine neue Art von Aufgabe meistens eine Frage des Schreibens einer neuen, spezifischen Checkliste für den Judge, nicht des Neugestaltens der gesamten Architektur von Grund auf jedes Mal.
Skalierung auf mehrere gleichzeitige Schleifen
Sobald eine einzelne selbstkorrigierende Schleife wirklich zuverlässig ist, ist die nächste echte Frage, wie man mehrere gleichzeitig ausführt, ohne dass das System unhandlich wird – denn genau hier geht der zweite Versuch der meisten Menschen, dies zu skalieren, schief.
Die Versuchung ist, sobald die erste Schleife funktioniert, viele Schleifen gleichzeitig zu starten und fünf verschiedene Aufgaben parallel zu bearbeiten, weil die Architektur es technisch unterstützt. Widerstehe dem länger, als es sich notwendig anfühlt. Jede zusätzliche gleichzeitige Schleife ist ein weiterer Ort, an dem eine Abbruchbedingung stillschweigend fehlschlagen kann, ein weiterer Ort, an dem Kosten unbemerkt davonlaufen können, ein weiterer Ort, an dem die Ground Truth-Referenz eines Judges subtil falsch sein könnte, und zwar auf eine Weise, die sich erst unter realem Volumen zeigt, nicht in einem einzelnen Testlauf.
Der sicherere Skalierungspfad ist sequentielle Erweiterung mit einer echten Vertrauensschwelle bei jedem Schritt. Bringe eine Schleife so zuverlässig zum Laufen, dass du aufgehört hast, ihre Ausgabe genau zu überprüfen – was bedeutet, dass sie konsequent deine eigenen manuellen Stichproben über einen echten Zeitraum hinweg besteht, nicht nur einen einzigen erfolgreichen Demo-Lauf. Füge erst dann eine zweite Schleife für eine andere Aufgabe hinzu. Verfolge die tatsächliche Fehlerrate jeder Schleife im Laufe der Zeit, nicht nur, ob sie bei den Läufen, die du zufällig beobachtet hast, zu funktionieren schien.
Wenn du mehrere Schleifen gleichzeitig ausführst, denke ernsthaft über ein gemeinsames Kosten-Dashboard über alle hinweg nach, nicht über eine Verfolgung pro Schleife in Isolation. Eine einzelne Schleife mit einem angemessenen Budget pro Aufgabe sieht in Isolation völlig in Ordnung aus. Zehn Schleifen, jede einzeln im Rahmen des Budgets, können sich dennoch zu einer wirklich alarmierenden Gesamtsumme summieren, die niemand bemerkt, bis die Sammelrechnung kommt, genau weil die Verfolgung jeder einzelnen Schleife für sich genommen in Ordnung aussah.
Die einzige Gewohnheit, die Skalierungsprobleme verhindert, bevor sie beginnen: Protokolliere jeden Abbruchbedingungsauslöser über jede Schleife hinweg, nicht nur die erfolgreichen Abschlüsse. Eine Schleife, die ihre maximale Iterationsobergrenze erreicht und an einen Menschen eskaliert, tut genau das, was sie tun soll. Aber wenn eine bestimmte Schleife diese Obergrenze ständig erreicht, während andere es selten tun, ist das ein Signal, dass der Standard des Judges für diese bestimmte Aufgabe entweder falsch kalibriert ist, zu streng, um jemals tatsächlich zu bestehen, oder gegen die falsche Ground Truth prüft. Dieses Muster ist unsichtbar, wenn du nur Erfolge verfolgst und jede Eskalation als isoliertes, unauffälliges Ereignis behandelst, anstatt als Datenpunkt über das Design dieser spezifischen Schleife.
Wo du diese Woche anfangen sollst
Versuche nicht, bei deinem ersten Versuch ein vollständig allgemeines selbstkorrigierendes System zu bauen. Wähle eine spezifische, enge, klar definierte Aufgabe, die du bereits regelmäßig erledigst, etwas mit einem klaren Standard, den du aufschreiben könntest, wenn du gefragt wirst, und baue die Drei-Rollen-Schleife zuerst um diese einzelne Aufgabe herum.
Schreibe die Checkliste des Judges explizit auf, bevor du eine einzige Zeile des Builder-Prompts schreibst. Der Standard, gegen den du prüfst, sollte prägen, was du den Builder zu produzieren bittest, nicht umgekehrt. Wenn du die Checkliste noch nicht schreiben kannst, weißt du noch nicht, was „korrekt" für diese Aufgabe bedeutet, um die Prüfung zu automatisieren, und das ist es wert, herauszufinden, bevor du etwas baust.
Führe die vier Stresstests oben durch, bevor du der Schleife etwas wirklich Wichtiges anvertraust, nicht erst, nachdem bereits etwas vor jemandem schiefgegangen ist. Füge die Abbruchbedingung von der allerersten Version an als echte, harte Logik hinzu, nicht als nachträglichen Einfall, nachdem du bereits einmal von einer aus dem Ruder gelaufenen Schleife verbrannt wurdest.
Sobald eine Schleife wirklich zuverlässig ist, unbeaufsichtigt läuft, echte Fehler erfasst, sauber stoppt, wenn sie sollte, geht die zweite viel schneller. Nicht, weil die Prompts direkt übertragbar sind – sie müssen normalerweise für die neue Aufgabe umgeschrieben werden –, sondern weil du bereits die tatsächliche Form des Problems verstehst. Trenne das Erstellen vom Beurteilen. Gib dem Beurteilen etwas Reales zum Überprüfen. Schreibe die Abbruchbedingung als Logik, nicht als Hoffnung.
Diese Form ist die gesamte Disziplin. Alles andere ist nur ihre Anwendung auf die Aufgabe, die vor dir liegt.
Folge @cyrilXBT für die genauen Schleifenvorlagen und Builder-Judge-Manager-Setups hinter allem in diesem Artikel.
