LLMs belohnen Expertise. Bewertete Loops frieren sie ein.

Sean Goedecke argumentiert, dass die wichtigste Fähigkeit beim Prompten die Expertise in der Domäne ist, für die man promptet. Sein Hauptbeleg ist ein Gespräch von Terence Tao mit ChatGPT: Tao kommt weiter als die meisten, nicht weil er allgemein besser promptet, sondern weil er die Mathematik gut genug kennt, um zu wissen, wo er nachbohren muss.

Ich halte das für richtig und fahre seit Monaten danach. Wie ich Arbeit über Modelle verteile ist eine Wette auf genau diese Behauptung: Der Plan entsteht vor dem Code, im Plan steckt das Urteil, und das Modell, das implementiert, macht die billigere Hälfte.

Dann habe ich das Urteil automatisiert, und die Behauptung hielt nicht mehr in der Richtung, die ich erwartet hatte.

Was passiert, wenn man die Expertise aufschreibt

Goedeckes Experte sitzt in der Schleife. Er liest eine Antwort, erkennt sie als subtil falsch und hakt nach. Die Expertise wird laufend angewendet, und sie passt sich dabei an, weil sie noch in einem Kopf steckt.

Eine bewertete Loop funktioniert anders. Du schreibst auf, was gut heißt — präzise genug, dass ein Skript es ausrechnet —, und dann läuft die Sache stundenlang ohne dich. Darin liegt der ganze Gewinn, und der ist echt.

Nur wird die Expertise dabei nicht mehr angewendet. Sie wurde einmal angewendet, beim Schreiben der Spec und beim Bauen der Eval, und danach in Dateien eingefroren, die absichtlich unveränderlich sind — damit sich nichts im Lauf zu einem besseren Score hinbearbeiten kann.

Unveränderlich ist die richtige Bauart. Sie macht die Annahmen des Experten aber auch zum einzigen Teil des Laufs, den niemand mehr revidieren kann.

Sechshundert Szenarien, kein einziger Request

Das Target, an dem mir das passiert ist, ist ein Partner-Attributionssystem. Seine Eval hat 600 Szenarien: 400 Dev, 200 Holdout. Jedes einzelne ist eine vorgefertigte Zustandsdatei — Affiliates, Empfehlungskanten, Events, Links, Offers, Auszahlungen.

In keinem steckt ein HTTP-Request.

Der Lauf ist sauber durchgelaufen. 1,0 auf der Stichprobe, 1,0 auf dem vollen Dev-Set, 1,0 auf dem Probe-Set — ein Gap von exakt null, also die Zahl, die sagt: generalisiert, nicht auswendig gelernt. Nichts wurde ausgetrickst. Die Datenbank war echt. Row-Level Security war echt, unter einer Rolle ohne Superuser- und ohne Bypass-Rechte. Die Append-only-Hash-Kette wurde direkt geprüft und nicht über einen Sonderweg fürs Scoring, weil ich all das in die Constraints geschrieben hatte.

Nicht hineingeschrieben hatte ich den Einstiegspunkt des Produkts. Die Ingestion-Routen — das, worüber jedes echte Event hereinkäme — standen kein einziges Mal auf dem Prüfstand. Sie konnten es nicht. In der Eval gab es nichts, was sie erreicht hätte.

Das ist kein Modellfehler. Das Modell hat gebaut, was verlangt war, korrekt, und hat nachgewiesen, dass es generalisiert. Das ist ein Spezifikationsfehler, und spezifiziert habe ich.

Warum das schlimmer ist als eine Loop, die betrügt

Eine Loop, die ihre Eval austrickst, ist lästig und beherrschbar. Du checksummst das Target, blendest die Antworten aus, lässt einen Lint über die Tricks laufen, die du kennst, und hältst ein Probe-Set zurück. Diese Verteidigungen funktionieren, und wie man sie baut, habe ich beschrieben.

Sie zeigen alle nach innen.

• Der Probe-Gap fragt, ob die Sache über die Oberfläche generalisiert, die ich abgetastet habe. Ob diese Oberfläche die richtige war, dazu sagt er nichts.
• Die Lints fragen, ob der Code bei der Aufgabe wie spezifiziert geschummelt hat. Eine korrekte Implementierung des falschen Zuschnitts besteht sie alle.
• Das Holdout stammt aus demselben Generator wie das Dev-Set und erbt damit jede Annahme, die das Dev-Set hat.

Die Fassung davon, zu der ich immer wieder zurückkomme: Ein Experte, der Ergebnisse reviewt, kann von ihnen überrascht werden. Ein Experte, der die Eval geschrieben hat, hat vorher festgelegt, was als Überraschung zählt.

Goedeckes Satz lautet, der Mensch sei der Flaschenhals, nicht das Modell. Für eine beaufsichtigte Session würde ich zustimmen. Für einen bewerteten Lauf ist es genauer und weniger schmeichelhaft: Der Mensch ist der Rahmen, und nichts innerhalb eines Rahmens prüft den Rahmen.

Was von der Behauptung übrig bleibt

Nicht „Expertise ist egal" — der Lauf ist überhaupt nur so weit gekommen, weil die Spec gut war, und der meiste Wert entstand beim Spezifizieren, bevor ein einziger Zyklus lief. Dieser Teil von Goedeckes Argument kommt gestärkt heraus, nicht geschwächt.

Was sich ändert: Expertise erledigt offenbar zwei verschiedene Aufgaben, und nur eine davon übersteht das Aufschreiben.

• Die Grenze ziehen. Entscheiden, was zählt, was gemessen wird, was „richtig" für diese Aufgabe heißt. Das lässt sich hervorragend in Dateien überführen. Es ist der größte Teil dessen, was eine gute Spec ausmacht.
• Die Grenze prüfen. Merken, dass das Gemessene nicht das Gewollte ist. Das überträgt sich nicht, weil die Prüfung von außerhalb des Rahmens kommen muss, den die Expertise gezogen hat.

Ich hatte die beiden für eine Fähigkeit gehalten. Sind sie nicht, und die zweite ist die, an deren Automatisierung ich scheitere. Gefunden habe ich den Zuschnittsfehler, indem ich mir das Produkt Wochen später angesehen habe — nicht durch irgendein Instrument im Harness.

Die praktische Fassung für mich lautet also: Je mehr von meinem Urteil ins Target wandert, desto bewusster muss ich den Teil einplanen, der nicht dorthin wandern kann. Nicht das Review des Diffs — darin ist das Scoring der Loop inzwischen besser als ich. Das Review der Frage. Irgendwer muss in irgendeinem Takt das Produkt aufmachen und prüfen, ob die Eval es noch beschreibt.

Bisher ist dieser Irgendwer ich, in keinem bestimmten Takt, aus Versehen.

Next

Was ich will und nicht habe, ist ein Instrument für den Zuschnitt: etwas, das anschlägt, wenn die Eval das Produkt nicht mehr abdeckt, so wie der Probe-Gap anschlägt, wenn die Eval nicht mehr ehrlich ist. Einen Entwurf dafür habe ich nicht. Vielleicht ist es nichts, was ein Skript halten kann — dann wäre die ehrliche Antwort ein Kalendereintrag und kein Harness.

Die billige Variante, die ich zuerst probiere, ist eine End-to-End-Probe pro Target, die über den echten Einstiegspunkt läuft und bewusst nicht bewertet wird. So kann nichts gegen sie optimieren, und sie kann mir nur eines sagen: dass Eval und Produkt auseinandergelaufen sind.

Meine eigene Antwort lautet bisher „gar nicht, ich habe es zufällig gemerkt", und die höre ich lieber von dir zurück als einen Mechanismus, den keiner wirklich betreibt. Also: Falls du Loops gegen eine aufgeschriebene Spec fährst — womit ist dir Zuschnittsdrift je aufgefallen?