Baue ein minimal funktionsfähiges Eval

Die Demo in diesem Video wurde im August 2026 aufgezeichnet. Sie lief auf Claude Haiku 4.5, Claude Sonnet 5 und Claude Opus 5. Bei neueren Modellen werden die Ergebnisse abweichen. Die Demo jeder Lektion ist ein eigener Eval-Lauf, daher stimmen ihre Punktzahlen und Kosten nicht mit denen in anderen Lektionen überein.

Ein Eval ist ein Test, den Modelle ablegen. Es hat drei Teile: realistische Eingaben, die für jede erwartete Antwort und eine Möglichkeit zu bewerten, was jedes Modell zurückgibt. Jedes Modell führt deinen Prompt für jede Eingabe aus. Eine Eingabe zusammen mit ihrer erwarteten Antwort ergibt einen Fall, und die Bewertung jedes Falls ergibt eine Punktzahl.

Der Extraktions-Prompt von Meridian zieht aus jedem monatlichen Projektbericht drei Felder: die Projekt-ID und den Zeitplanstatus, die beides kurze Werte sind, sowie das Hauptrisiko, das ein Satz ist.

Ein Eval zu erstellen ist wie eine Prüfung abzunehmen, wobei du der Lehrer bist und die Modelle die Schüler sind.

Ein LLM-Richter ist ein zweites Modell, das eine Antwort überprüft und entscheidet, ob sie richtig ist. Alles, was eine Antwort bewertet, wird als Bewerter bezeichnet, egal ob es sich um Code, ein Modell oder eine Person handelt. Du wirst Meridians Eval in sechs Schritten aufbauen:

1. Wähle für jedes Feld einen Bewerter
2. Entwirf die Menge der Fälle
3. Schreibe die erwarteten Antworten auf
4. Richte den LLM-Richter für das Hauptrisiko ein
5. Führe die Modelle aus und bewerte ihre Antworten
6. Bewerte eine Stichprobe von Hand, bevor du dem Richter vertraust

Wähle für jedes Feld einen Bewerter

Es gibt drei Möglichkeiten, eine Antwort zu bewerten. Die Regel lautet, die schnellste Methode zu wählen, die auch zuverlässig ist und skaliert.

1. Code-basierte Bewertung. Dein Code prüft, ob eine Antwort genau mit der erwarteten Antwort übereinstimmt oder ob sie eine Schlüsselphrase enthält. Es ist die schnellste und zuverlässigste Methode, und sie skaliert auf jede beliebige Anzahl von Fällen.
2. LLM-Richter. Der Richter eignet sich für Antworten, bei denen zwei unterschiedliche Sätze beide richtig sein können. Er ist ebenfalls schnell, flexibel und skalierbar.
3. Menschliche Bewertung. Eine Person liest jede Antwort, was die beste Qualität liefert, aber langsam und teuer ist, weshalb sie an letzter Stelle steht. Menschen sind nach wie vor die richtigen Bewerter für spezialisierte Arbeiten mit hohem Risiko und für Antworten, bei denen es auf Urteilsvermögen ankommt.

Verwende Code für jedes Feld, das er exakt prüfen kann, und gib dem Richter nur das, was übrig bleibt. So sieht das bei Meridians drei Feldern anhand eines ihrer Fälle aus, Bericht r032.

Nennt ein Bericht jedoch kein Risiko, lautet die erwartete top_risk-Antwort null, der leere Wert von JSON. Code kann das mit einer exakten Übereinstimmung prüfen.

Entwirf die Menge der Fälle

Vier Regeln prägen die gesamte Menge der Fälle. Sie bauen auf den Eval-Design-Prinzipien in den Dokumenten auf.

1. Mache die Fälle aufgabenspezifisch. Erstelle sie aus deinen eigenen echten Berichten, denn Beispieldaten zeigen nur, wie ein Modell bei Beispielen abschneidet.
2. Automatisiere die Bewertung. Du wirst die Menge immer wieder ausführen, also muss die tägliche Bewertung ohne eine Person funktionieren.
3. Bevorzuge Masse vor Feinschliff. Bei gleichem Aufwand sagen viele automatisch bewertete Fälle mehr aus als wenige, die sorgfältig von Hand bewertet wurden.
4. Stratifiziere deine Randfälle. Ein Randfall ist eine ungewöhnliche Eingabe, die der Produktivbetrieb dennoch sendet, etwa ein eingescannter Bericht. Gib jeder Art etwa den Anteil an Fällen, den sie im Produktivbetrieb hat – wenn gescannte Berichte also 5 % dessen ausmachen, was ankommt, mach sie zu etwa 5 % der Menge.

Vor allem sollte die Mischung der Fälle so aussehen wie das, was der Produktivbetrieb dir sendet. Teams verstehen unter Masse oft Hunderte von Fällen, aber eine Menge von 20 bis 50 einfachen Fällen ist ein großartiger Anfang.

Meridian entschied sich für 50 Fälle. Dreißig sind typische Berichte, 10 decken mehrere Projekte ab, und 10 sind Fälle mit fehlendem Risiko, also Berichte ohne Risikoabschnitt. Beide ungewöhnlichen Arten erreichen Meridian oft genug, dass sie abgedeckt werden sollen.

Schreibe die erwarteten Antworten auf

Fälle, deren erwartete Antworten eine Person aufgeschrieben hat, werden als beschriftete Menge bezeichnet. Schreibe jede erwartete Antwort selbst auf, anhand des Berichts, bevor irgendein Modell läuft. Der Code-Bewerter vergleicht die Antworten der Modelle damit.

Meridian bewahrt seine beschriftete Menge in einer Datei auf, golden.json, mit einem Datensatz für jeden Fall. Ein Datensatz enthält die id des Falls, seine category und die erwartete Antwort für jedes Feld. Die category ist typical, multi_project oder missing_risk.

Richte den LLM-Richter für das Hauptrisiko ein

Das Feld top_risk enthält einen Satz. Code kann nicht erkennen, ob zwei unterschiedliche Sätze dasselbe Risiko benennen, daher geht dieses Feld an den Richter. Es ist die Aufsatzfrage, und wie die Hilfskraft braucht der Richter einen Bewertungsleitfaden.

Dieser Leitfaden ist eine Rubrik, ein schriftliches Regelwerk dafür, was als richtig und was als falsch gilt. Sie sollte detailliert und klar sein.

Der Prompt des Richters enthält den Bericht, die Antwort und die Rubrik. Jedes steht in eigenen XML-Tags, sodass der Richter sie weniger leicht durcheinanderbringt. Deine erwartete Antwort steht nicht im Prompt, weil der Richter anhand des Berichts selbst entscheidet. So verliert eine Antwort keine Punkte, nur weil sie das Risiko anders formuliert als du. Behalte deine erwartete Antwort trotzdem, denn sie ist deine Aufzeichnung der richtigen Antwort, wenn du eine Stichprobe von Hand bewertest.

Die Entscheidung des Richters zu einer Antwort wird als ihr Urteil bezeichnet. Ein Urteil ist nur nützlich, wenn es in einer Form zurückkommt, die dein Code zählen kann. Strukturierte Ausgaben geben dir das. Du sendest ein JSON-Schema mit der Anfrage, und die Antwort muss ihm entsprechen. Ein JSON-Schema beschreibt, welche Felder das JSON enthalten darf und was in jedes davon kommen kann.

Meridians Schema hat zwei Felder, explanation und verdict. Das Urteil muss correct, incorrect oder unknown sein. Die Erklärung ist eine kurze Darstellung, warum der Richter so entschieden hat, also liest du sie, wenn du wissen willst, was bei einer Antwort schiefgelaufen ist.

Der wichtigste Wert ist unknown. Er gibt dem Richter einen Ausweg, eine Möglichkeit zu sagen, dass er es nicht beurteilen kann. Ohne ihn muss der Richter zwischen den beiden anderen raten, wann immer er sich nicht sicher ist.

Führe die Modelle aus und bewerte ihre Antworten

Bevor irgendetwas bewertet werden kann, brauchst du Antworten. Führe deinen Prompt für jeden Fall mit jedem Modell aus, das du testest, und speichere jede Antwort in einer Datei. Meridian führte seinen Extraktions-Prompt für alle 50 Fälle mit Claude Haiku 4.5, Claude Sonnet 5 und Claude Opus 5 aus.

Teste den Richter einmal an Fällen, die Code ebenfalls bewerten kann, um zu sehen, ob die beiden Bewerter übereinstimmen. Meridians erster Richterlauf nahm nur die 10 Fälle mit fehlendem Risiko, was über die drei Modelle hinweg 30 Antworten ergab. Ihre erwartete Antwort ist null, sodass Code sie ebenfalls bewerten konnte. Speichere jedes Urteil neben seiner Antwort, damit du den Richter später von Hand überprüfen kannst.

Der erste Lauf des Richters, an den 10 Fällen mit fehlendem Risiko, die auch Code bewerten konnte.

Für Berichte ohne Risikoabschnitt hat Meridian jetzt für jedes Modell eine Zahl, wo es früher Meinungen hatte.

Die fünf falschen Antworten von Haiku 4.5 sind alle derselbe Fehlertyp, und Fall r045 zeigt einen davon.

Die Erklärung des Richters benennt die Art des Fehlers, den die Antwort gemacht hat. Dieser Fehler stammt aus dem Extraktions-Prompt, der nie sagt, was zu tun ist, wenn ein Bericht kein Risiko nennt.

Bewerte eine Stichprobe von Hand, bevor du dem Richter vertraust

Der Richter stimmte bei allen 30 Antworten mit Code überein, aber Code konnte diese ohnehin prüfen. Die eigentliche Aufgabe des Richters ist es, Freitext zu bewerten, wo Code nicht helfen kann. Bevor du ihm diese Aufgabe gibst, teste, ob er zuverlässig ist. Zwei Vorgehensweisen helfen dabei.

1. Bewerte eine Stichprobe selbst. Bewerte eine Handvoll gespeicherter Antworten von Hand und vergleiche deine Bewertungen mit den Urteilen des Richters, denn ein Richter sollte eng mit menschlichen Experten übereinstimmen. Wo du und der Richter nicht übereinstimmen, mach die Rubrik klarer und führe sie erneut aus.
2. Verwende einen Richter, der die Antworten nicht geschrieben hat. Es ist im Allgemeinen am besten, mit einem anderen Modell zu bewerten als dem, das die Ausgabe geschrieben hat.

Zusammengefasst

1. Bewerte mit Code, wo eine exakte Prüfung funktioniert, mit einem Richter, wo zwei unterschiedliche Sätze beide richtig sein können, und mit Menschen, wo es auf Urteilsvermögen ankommt.
2. Schreibe die erwarteten Antworten auf, bevor irgendein Modell läuft, und baue eine Menge von Fällen auf, die wie der Produktivbetrieb aussieht.
3. Gib dem Richter eine Rubrik, ein Schema, dem sein Urteil entsprechen muss, und die Möglichkeit, unknown zu sagen.
4. Bewerte eine Stichprobe der Arbeit des Richters von Hand, bevor du ihr vertraust.