Eval-getriebene Entwicklung bedeutet, dass du den bewerteten Test schreibst, bevor du das Feature baust. Du definierst eine Menge benoteter Fälle, die kodieren, wie eine korrekte Antwort aussieht, verdrahtest sie in die CI und lässt sie jede Änderung am KI-Pfad absichern. Ein Pull Request, der den Score senkt, wird nicht gemergt. Das Eval-Set ist der Vertrag; der Code muss ihn erfüllen.
Der Grund, im Finanzbereich so zu arbeiten, ist, dass die üblichen Qualitätssignale dich belügen. Ein Modell, das einen Kontoauszug liest und eine selbstsichere, sauber formatierte, falsche Einkommenszahl zurückgibt, sieht in der Demo gut aus und bei der manuellen Stichprobe ebenfalls. Es scheitert am zwölften Auszugstyp, an den niemand gedacht hat. Ohne ein dauerhaftes Eval-Set findest du dieses Versagen in Produktion, mitten in einer Straight-Through-Decision, nachdem ein Prüfer gefragt hat, wie die Zahl zustande kam. Die Eval verschiebt diese Entdeckung nach links, vor die Ship-Linie.
Bau das Eval-Set vor dem Feature
Das Eval-Set ist ein versioniertes Artefakt, das im Repository neben dem Code liegt, den es benotet. Jeder Fall ist ein Input, ein erwartetes Ergebnis und ein Grader, der über Pass oder Fail entscheidet. Du schreibst es zuerst, weil der Akt des Schreibens dich zwingt, festzuhalten, was das Feature leisten soll, in Begriffen, die spezifisch genug sind, um bewertet zu werden.
Woher die Fälle stammen, zählt mehr als ihre Anzahl. Zieh aus drei Quellen:
- Echte Produktions-Traces, gesampelt über Dokumenttypen, Kreditnehmer und Berichtsperioden hinweg, damit die Verteilung dem entspricht, was das System tatsächlich sieht, statt dem, was bequem zu testen ist.
- Vergangene Vorfälle. Jede falsche Zahl, die einen Menschen erreicht hat, wird zu einem dauerhaften Fall. Das ist die Regressions-Eval; sobald ein Bug im Set ist, kann er nicht mehr stillschweigend zurückkehren.
- Adversariale Fälle, die du bewusst konstruierst: die berichtigte Meldung, der Auszug mit einer Lookahead-Falle, bei der eine spätere Seite einer früheren widerspricht, der Name, der zu zwei verschiedenen Gegenparteien auflöst.
Die Point-in-Time-Correctness verdient eigene Aufmerksamkeit. Wenn deine Eval dem Modell Daten füttert, die es zum Entscheidungszeitpunkt nicht gegeben hätte, testest du gegen Leakage und deine Scores sind aufgebläht. Frier jeden Fall auf die zum As-of-Datum verfügbare Information ein und benote die Antwort gegen das, was damals wissbar war.
Benote mit der striktesten Methode, die die Aufgabe erlaubt. Eine berechnete Zahl bekommt eine exakte oder toleranzbasierte numerische Prüfung. Eine Quellenangabe bekommt einen Resolver, der bestätigt, dass das referenzierte Dokument und die Zeile tatsächlich existieren und das aussagen, was das Modell behauptet. Reserviere LLM-bewertete Rubriken für wirklich graduelle Qualitäten wie Vollständigkeit oder Tonalität, und das erst, nachdem du die Übereinstimmung des Judges mit menschlichen Labels auf einem Holdout geprüft hast. Ein unvalidierter Judge ist ein Zufallszahlengenerator mit guter Grammatik.
Sichere jede Änderung in der CI ab
Sobald das Set existiert, läuft die Eval in der Continuous Integration bei jedem Pull Request, der den KI-Pfad berührt: Prompts, Retrieval, Chunking, Modellversion, Tool-Definitionen, Post-Processing. Der Job bewertet den aktuellen Build und vergleicht ihn gegen eingefrorene Schwellenwerte pro Metrik. Fällt er bei irgendeiner geschützten Metrik unter den Schwellenwert, scheitert der Check und blockiert den Pull Request genauso, wie es ein fehlgeschlagener Unit-Test täte.
Ein paar Praktiken halten das ehrlich.
- Trenne die Metriken, statt sie zu einer Zahl zu vermischen. Verfolge Exact-Match-Accuracy, Citation-Validity, die Refusal-Rate bei Out-of-Scope-Inputs und dein False-Positive-Budget unabhängig voneinander. Ein gemischter Score lässt einen Gewinn an einer Stelle eine Regression an anderer verbergen.
- Pinne Modell und Decoding-Parameter und protokolliere sie im Lauf. Wenn der Score sich bewegt, musst du wissen, ob sich der Code geändert hat oder der Anbieter. Begrenze Nichtdeterminismus mit festen Seeds, wo es sie gibt, und indem du auf ein stabiles Aggregat läufst, wo es sie nicht gibt.
- Halte einen Holdout-Slice, den die Entwickler, die Prompts schreiben, nie zu Gesicht bekommen. Tuning gegen jeden sichtbaren Fall überpasst den Prompt irgendwann an die Eval, und der Holdout ist die Art, wie du das aufdeckst.
Setz die Schwellenwerte konservativ. Du pinnst sie nicht auf den aktuellen Score und verbietest jede Bewegung; du setzt einen Boden, der die versprochenen Verhaltensweisen schützt, und lässt gewöhnliches Rauschen durch. Einen Schwellenwert anzuheben ist eine Entscheidung, die im Review getroffen wird, mit der Trace-Lineage, die zeigt, welche Fälle sich bewegt haben und warum.
Behandle die Eval als governtes Artefakt
Ein Eval-Set, das Produktionsentscheidungen absichert, ist selbst Teil des Audit-Trails. Versioniere es, prüfe Änderungen daran in Pull Requests und verlange eine Begründung, wenn ein Fall bearbeitet oder entfernt wird. Einen unbequemen Fall zu löschen oder still einen Schwellenwert zu senken, ist das KI-Äquivalent dazu, den Test zu bearbeiten, damit der Build grün wird, und es sollte so sichtbar sein wie jede andere Änderung an einer Kontrolle. Unter einer Model-Risk-Rahmung wie SR 11-7 ist das Eval-Set ein großer Teil dessen, wie “Ongoing Monitoring” und “Effective Challenge” für ein Sprachmodell konkret aussehen, und DORAs Anforderungen an Resilienz-Tests für kritische Systeme weisen in dieselbe Richtung.
Der Nutzen kumuliert sich. Jeder Vorfall, der zu einem Fall wird, macht die nächste Regression billiger aufzuspüren. Jeder neue Dokumenttyp, der ins Set gesampelt wird, weitet aus, was das Gate schützt. Über ein Quartal wird das Eval-Set zur genauesten Beschreibung, die du davon hast, was das System tut, Drift und allem, weil es die eine Beschreibung ist, die bei jeder Änderung ausgeführt wird, statt einmal geschrieben und dem Verfall überlassen zu werden. Wenn ein Prüfer fragt, warum du einem Modell zutraust, ein Hauptbuch oder eine Adverse-Action-Entscheidung anzufassen, ist das Eval-Set die Antwort, und seine Versionshistorie und der Nachweis blockierter Merges sind die Belege dahinter.
Häufige Fragen
Wie viele Fälle brauchen wir, bevor ein Eval-Set nützlich wird?
Weniger, als Teams erwarten. Dreißig bis fünfzig Fälle pro Verhalten, gezogen aus echten Produktions-Traces und vergangenen Vorfällen, fangen die meisten Regressionen ab. Die Präzision der Labels zählt weit mehr als die Menge; hundert schlampig bewertete Fälle sind schlechter als vierzig saubere.
Kann ein LLM die Eval bewerten, oder brauchen wir menschliche Labels?
Beides. Verwende von Menschen gelabelte erwartete Antworten für alles mit einer belastbaren Ground Truth, etwa eine berechnete Kennzahl oder eine Quellenangabe, die auflösbar sein muss. Setze einen LLM-Judge nur für bewertete Rubriken wie Tonalität oder Vollständigkeit ein, und validiere den Judge gegen menschliche Labels, bevor du seinem Score vertraust.
Was blockiert einen Merge, wenn die Eval regrediert?
Ein Abfall unter den eingefrorenen Schwellenwert bei irgendeiner geschützten Metrik lässt den CI-Job scheitern, genauso wie ein fehlgeschlagener Unit-Test. Der Pull Request kann nicht gemergt werden, bis der Score sich erholt oder der Schwellenwert im Review bewusst neu ausgehandelt wird.