Ihr erstes Eval in einer Woche

Der größte Teil dieses Leitfadens ist ein Nachschlagewerk. Diese Seite nicht. Sie ist ein Weg durch den Leitfaden, auf eine Woche zugeschnitten. Am Ende läuft etwas in Ihrer CI. Und dieses Etwas hätte eine Regression abgefangen, die Sie tatsächlich ausgeliefert haben.

Diese Seite sagt Ihnen, was zu tun ist. Die nächste Seite, Eine Woche, durchgerechnet, zeigt ein Team bei genau dieser Arbeit. Dieselben fünf Tage, mit seinen Tickets, Dateien, seinem Code und seinen Zahlen. Planen Sie mit dieser Seite. Prüfen Sie Ihre Arbeit an jener. Wer noch nie ein Eval als Dateien gesehen hat, liest zuerst Ein Eval in fünf Dateien. Das ist eine Bildschirmseite, und Tag 3 baut genau darauf auf.

Diese Seite ist bewusst unvollständig. Sie überspringen Agenten, RAG-Besonderheiten, Mehrsprachigkeit, Sicherheit und den größten Teil der Statistik. All das steht im Rest des Leitfadens. Lesen Sie es, wenn Sie es brauchen. Nicht überspringen können Sie die Reihenfolge. Jeder Tag baut auf dem vorigen auf.

Haben Sie noch keinen Verkehr aus dem laufenden Betrieb? Dann machen Sie Tag 1 anders und den Rest wie beschrieben.

Wann Sie diese Woche nicht brauchen

Dieser Leitfaden wirbt durchgehend für mehr Messung. Deshalb gehört an den Anfang, wann sich Messung nicht lohnt. Vier Fälle:

• Ihr System beantwortet so wenige Anfragen, dass ein Mensch alle lesen kann. Unter etwa 50 Antworten pro Woche brauchen Sie keine Automatik: Lesen Sie jede einzelne. Tag 1 und Tag 2 lohnen sich trotzdem, denn dort tun Sie genau das, nur mit Notizblock. Ein Judge lohnt sich nicht. Ein Modell, das 50 Antworten pro Woche bewertet, kostet mehr Aufwand als das Lesen, das es ersetzen soll.
• Ein Mensch korrigiert jede Ausgabe, bevor sie rausgeht. Dann haben Sie ein Produktmaß, das jedes Eval schlägt: Wie viel vom Entwurf musste die Person ändern? Messen Sie zuerst das. Ein Judge wird erst nötig, wenn Sie wissen wollen, was geändert wurde. Nicht ob. Das Team im durchgerechneten Beispiel ist genau dieser Fall. Hätte es diesen Absatz gelesen, hätte es an Tag null mit der Änderungsrate angefangen.
• Ein Prototyp vor dem ersten Nutzer. Tag 1 mit synthetischen Fällen, Tag 3 mit den Smoke-Prüfungen, sonst nichts. Alles Weitere misst Fehlermodi, die Sie nur geraten haben.
• Ein einmaliger Stapellauf. Stichprobe ziehen, lesen, fertig. Ein Eval ist eine Frage, die Sie immer wieder stellen. Ohne Wiederholung gibt es nichts zu automatisieren.

In allen vier Fällen bleibt eines: Lesen Sie, was das System produziert. Dieser Teil der Woche fällt nie weg.

Tag 1: 100 Traces lesen

Aufgabe: Ziehen Sie 100 echte Interaktionen. Jede davon heißt Trace. Ein Trace umfasst die Eingabe des Nutzers, die Dokumente, die Ihr System nachgeschlagen hat, die aufgerufenen Tools und die endgültige Antwort. Lesen Sie alle 100. Schreiben Sie zu jedem einen Satz über das Erste, was falsch ist. Noch nicht sortieren. Noch nichts reparieren.

Das setzt voraus, dass Sie alle drei Teile protokollieren. Heben Sie heute nur die Endantwort auf? Dann erweitern Sie zuerst Ihr Protokoll um die Eingabe, die gefundenen Dokumente und die Tool-Aufrufe. Online-Evaluation nennt die üblichen Feldnamen. Kommen Sie zurück, sobald eine Woche solcher Traces vorliegt. Endantworten allein sagen Ihnen, dass etwas schiefging. Sie sagen nicht, wo.

Zeit: Drei bis vier Stunden. Es fühlt sich langsam an. Und es ist der wertvollste Tag der Woche.

Noch kein Verkehr? Erzeugen Sie stattdessen ein strukturiertes Set. Benennen Sie die Dimensionen, in denen Ihre Eingaben variieren. Bauen Sie 20 Tupel von Hand. Lassen Sie sie in einem separaten Prompt in natürliche Sprache übersetzen. Datensatz-Design hat das Rezept. Dort stehen auch die vier Fälle, in denen synthetische Daten Sie anlügen.

Am Abend: 100 Freitext-Notizen und ein unangenehmes Gefühl dafür, wie sich Ihr Produkt wirklich verhält.

Kapitel: Fehleranalyse zuerst

Tag 2: Aus Notizen eine Taxonomie machen

Aufgabe: Gruppieren Sie die Notizen zu benannten Fehlermodi. Ein Fehlermodus ist eine Art von Fehler, die Ihr System macht, mit einem Namen, den jeder wiedererkennt: „erfindet Preise“, „antwortet in der falschen Sprache“, „übergeht die zweite Frage“. Die Liste dieser Fehlermodi ist Ihre Fehlertaxonomie, mit einer Anzahl hinter jedem. Fügen Sie die Notizen in ein LLM ein und lassen Sie es Gruppen bilden. Korrigieren Sie das Ergebnis danach. Das Gruppieren ist mühsam, das Benennen ist Ihre Aufgabe. Die Notizen enthalten Kundeninhalte. Nehmen Sie deshalb ein Modell, das Ihr Auftragsverarbeitungsvertrag abdeckt, oder pseudonymisieren Sie vorher. Datensatz-Design erklärt, warum das keine Formalie ist. Zählen Sie, wie viele Traces in jede Kategorie fallen. Sortieren Sie nach Anzahl.

Teilen Sie die Liste dann in zwei Hälften. Auf der einen Seite stehen gewöhnliche Bugs. Beispiele: ein abgeschnittener Kontext, oder ein Tool liefert eine Fehlermeldung und das Modell behandelt sie als Daten. Auf der anderen Seite stehen verhaltensbedingte Fehler. Sie kehren wieder, auch nachdem Sie die offensichtlichen Dinge repariert haben.

Zeit: Ein halber Tag, plus die Zeit für die Bugfixes. Beheben Sie die Bugs jetzt.

Am Abend: Eine nach Anzahl sortierte Fehlertaxonomie und eine kürzere Liste dessen, was wirklich gemessen werden muss. Rechnen Sie damit, dass Sie der oberste Punkt überrascht.

Kapitel: Fehleranalyse zuerst · Datensatz-Design und Annotation

Tag 3: Das Set bauen und bewerten, was Code bewerten kann

Aufgabe: Stellen Sie mindestens 100 Fälle zusammen. Ein Fall ist eine eingefrorene Situation plus die Angabe, was daran geprüft wird, je eine JSON-Datei, genau wie in Ein Eval in fünf Dateien. Die Fälle kommen aus drei Quellen: jeder echte Vorfall aus Tag 1, den Sie nachbauen können, die gewöhnlichen Anfragen Ihres Kernpfads und die Randfälle, die Ihre Taxonomie aus Tag 2 sichtbar gemacht hat. Checken Sie die Dateien ins Repository ein und versehen Sie das Set mit einem Tag, damit zwei Läufe auf denselben Fällen verglichen werden können. Dann verschieben Sie etwa ein Fünftel, also rund 20 Fälle, in ein Verzeichnis, das die CI nie ausführt. Das ist das Testset. Wofür es da ist und wann Sie es anfassen, steht in Datensatz-Design.

Dann schreiben Sie die billigen Grader. Das sind die Codestücke, die entscheiden, ob eine Antwort bestanden hat oder nicht. Alles mit einer richtigen Antwort, einer festen Form oder einer Regel prüft gewöhnlicher Code, nicht ein Modell. Beispiele: Schemavalidierung, Abgleich der Tool-Aufrufe, „jede Zitation verweist auf ein abgerufenes Dokument“, „die Antwort enthält nie den System-Prompt“. Diese Prüfungen kosten im Betrieb nichts. Und sie liefern bei gleicher Eingabe immer dasselbe Urteil.

Zeit: Ein Tag.

Am Abend: Ein versioniertes Eval-Set und ein Grader-Modul, in der Form von Ein Eval in fünf Dateien: ein Verzeichnis cases/, checks.py und run.py. Starten Sie es mit uv run --with openai python evals/run.py. Einige Ihrer Regelprüfungen werden auf echtem Verkehr schon jetzt scheitern, etwa „jede Zitation verweist auf ein Dokument“. Das ist normal. Und es ist kostenloses Signal.

Kapitel: Datensatz-Design und Annotation · Code-basierte und strukturierte Evals

Tag 4: Ein Judge, validiert

Aufgabe: Bauen Sie einen Judge für einen Fehlermodus und messen Sie, wie gut er ist, bevor Sie ihm trauen. Ein Judge ist ein zweites Modell mit einer einzigen Aufgabe: Es liest eine Antwort und sagt bestanden oder nicht bestanden. Sechs Schritte, mit einem Beispiel, das durchläuft.

1. Wählen Sie einen Fehlermodus aus Ihrer Liste von Tag 2. Es muss einer sein, den Code nicht abfangen kann, weil man die Antwort lesen muss, um ihn zu erkennen. „Erfindet Preise“ ist so einer. „Quellenangabe löst nicht auf“ nicht, denn den fängt Tag 3 schon. Nehmen Sie den häufigsten, an dem Sie weiter arbeiten werden. Einen, nicht vier: Jeder Judge braucht eigene Labels und eine eigene Messung. Machen Sie daraus eine einzige Frage. Für „erfindet Preise“ lautet sie: Belegt die zitierte Stelle die Zahl in diesem Entwurf?

2. Sammeln Sie 100 bis 150 Antworten, auf die Ihre Frage passt. Nehmen Sie sie aus dem echten Verkehr, nicht aus dem Eval-Set von Tag 3. Würden Sie die Eval-Fälle labeln und die Begründungen als Beispiele in den Judge legen, hätten Sie die Testfälle in den Prompt geschrieben. Genau vor diesem Leck warnt Datensatz-Design. Behalten Sie nur Antworten, zu denen die Frage passt: Bei „Ist die Zahl belegt?“ sind das Antworten, in denen eine Zahl vorkommt.

3. Lassen Sie Ihren Fachexperten labeln. Jede Antwort bekommt bestanden oder nicht bestanden und einen geschriebenen Satz, warum. Bei anderthalb Minuten pro Stück sind das drei bis vier Stunden. Das ist der größte Posten des Tages, und an ihm lässt sich nicht sparen. Denn aus diesen Sätzen wird der Judge gebaut, und an ihnen wird er gemessen.

4. Teilen Sie die Labels in zwei Stapel, die sich nie berühren. Der Aufbaustapel enthält 30 bis 40 Antworten, bewusst zur Hälfte bestanden und zur Hälfte nicht bestanden. Aus ihm schreiben Sie die Anweisung für den Judge: die Frage aus Schritt 1, die Sätze des Fachexperten als Beispiele, und die Regel, dass er erst begründet und dann urteilt. Der versiegelte Stapel ist der Rest. Er muss mindestens 20 bis 25 echte Fehler enthalten. Sind es weniger, sagt die Messung in Schritt 5 nichts: Eine Trefferquote aus fünf Fehlern kann irgendwo zwischen 0 und 100 % liegen, und selbst aus 25 hat sie noch eine Spanne von ±15 bis 20 Punkten. Haben Sie weniger Fehler, labeln Sie weiter, bevor Sie messen.

5. Messen Sie den Judge auf dem versiegelten Stapel. Der Judge hat ihn nie gesehen. Auch nicht „zum kurzen Nachschauen, ob der eine Fall knifflig ist“. Berichten Sie zwei Zahlen, jede mit ihrer Anzahl: Wie viele der echten Fehler hat er abgefangen („17 von 25“)? Wie viele der guten Antworten hat er in Ruhe gelassen („50 von 55“)? Berichten Sie nicht „wie oft war er unserer Meinung“. Diese Zahl schmeichelt einem Judge, der zu allem „bestanden“ sagt.

6. Enttäuscht die Trefferquote, lesen Sie die verpassten Fälle. Nicht die Gesamtzahl. Überarbeiten Sie die Anweisung und messen Sie erneut auf demselben versiegelten Stapel. Zwei oder drei Runden sind normal. Das Praxisbeispiel zeigt jeden Schritt mit seinen Zahlen, einschließlich einer ersten Fassung, die nur 14 von 25 fand.

Zeit: Ein Tag, überwiegend Labeln. Reicht er nicht, darf das Labeln in Tag 5 hineinragen. Das Messen nicht.

Am Abend: Ein Judge mit bekannter Fehlerrate und bekannter Spanne dieser Rate. Fängt er nur die Hälfte der echten Fehler, haben Sie etwas Wichtiges gelernt. Und zwar bevor Sie ihm vertraut haben. Genau darum geht es.

Kapitel: Einen ausgerichteten LLM-Judge bauen · Wo LLM-Judges versagen

Tag 5: Dafür sorgen, dass es ohne Sie läuft

Aufgabe: Zwei Stufen, beide in der CI verdrahtet. Die CI ist das System, das ohnehin Ihre Tests laufen lässt, sobald jemand Code pusht.

Eine Smoke-Suite mit den deterministischen Prüfungen bei jedem Push. Sie ist schnell, kostenlos und darf einen Merge blockieren. Eine Regressions-Suite mit Ihrem Set aus Tag 3 bei jedem Pull Request. Sie blockiert nur bei den deterministischen Prüfungen. Die Werte des Judge vergleicht sie Fall für Fall mit dem vorigen Ergebnis, und zwar mitsamt ihrer Fehlerspanne. Nicht als nackte Zahl. Ein Rückgang um zwei Punkte bei 100 Fällen ist meist Rauschen. Ein Gate, das bei Rauschen auslöst, wird bald abgeschaltet.

Nageln Sie Modellversion, Judge-Version und Datensatzversion in einer Konfiguration fest. Diese Konfiguration liegt im Repository. Legen Sie die erzeugten Antworten in einen Cache. So zahlt eine Grader-Änderung nicht für eine neue Erzeugung.

Zeit: Ein halber Tag, wenn Ihre CI schon existiert.

Am Abend: Eine Pipeline, die Ihnen meldet, wenn eine Prompt-Änderung etwas kaputt macht.

Kapitel: Evals in der CI · Das Offline-Harness · Statistik für kleine Eval-Sets

Was Sie haben und was nicht

Nach einer Woche haben Sie fünf Dinge. Eine Fehlertaxonomie, die auf echten Traces beruht. Ein versioniertes Eval-Set. Deterministische Grader bei jedem Push. Einen validierten Judge. Und eine Regressionssuite an den Pull Requests. Das ist mehr Eval-Infrastruktur, als die meisten Teams mit LLM-Features im Betrieb haben. Und alles davon zielt auf Fehler, die Sie tatsächlich beobachtet haben.

Was Sie nicht haben und auch nicht behaupten sollten:

Die Woche danach

Tragen Sie sich einen festen Termin von 30 Minuten ein. Darin überfliegen Sie 10–20 Traces, mit Schwerpunkt auf Ausreißern. Alle zwei bis vier Wochen wiederholen Sie Tag 1 mit 100 frischen Traces. Prüfen Sie, ob die Taxonomie noch trägt.

Dieser Teil verfällt still. Nichts geht kaputt, wenn ein Team aufhört, Traces zu lesen. Die Dashboards produzieren weiter Zahlen. Die Zahlen entsprechen nur nichts mehr.

Häufiger Fehler: Tag 4 zuerst machen, weil ein Judge sich nach der eigentlichen Arbeit anfühlt. Ein Judge, der vor der Fehleranalyse entsteht, misst einen geratenen Fehlermodus. Sie werden nicht merken, dass es der falsche war. Denn er liefert weiterhin plausible Werte.