Die Demo funktioniert. Jemand fragt, woher Sie wissen, dass sie nach der nächsten Prompt-Änderung weiter funktioniert — und im Raum wird es still. Diese Stille ist das ganze Problem, und sie hat eine günstige Lösung, die fast niemand früh genug anwendet.

In zwei früheren Artikeln haben wir argumentiert, dass das zählt — dass Evaluierung die Kosten sind, die niemand einplant, und dass Sie keinen Retrieval-Parameter tunen können, den Sie nicht messen. Keiner der beiden sagte wie. Dieser hier tut es.

Warum „sieht gut aus“ irgendwann nicht mehr reicht

Manuelles Prüfen skaliert bis etwa zu den ersten zwanzig Beispielen. Danach brechen drei Dinge gleichzeitig: Niemand prüft die bereits bestandenen Fälle erneut, also landen Regressionen unbemerkt; verschiedene Menschen urteilen verschieden, also sind Ergebnisse von Woche zu Woche nicht vergleichbar; und wer prüft, kennt den Prompt und liest die Ausgabe wohlwollend.

Das daraus entstehende Fehlerbild ist spezifisch und wiedererkennbar. Eine Prompt-Änderung behebt die Beschwerde, die sie ausgelöst hat, und zerstört still zwei Verhaltensweisen, die niemand beobachtet hat. Ohne Suite erfahren Sie es von einer Kundin, etwa einen Monat später, und können nicht sagen, welche Änderung es war.

Die kumulative Wirkung ist schlimmer als der einzelne Vorfall. Ist ein Team zweimal verbrannt worden, ändert es den Prompt nicht mehr — und ein Prompt, den niemand anfassen will, ist ein eingefrorenes Produkt, unter dem der Modellanbieter Versionen abkündigt. Die Eval-Suite ist eigentlich keine Qualitätssicherung. Sie ist die Voraussetzung dafür, überhaupt noch etwas ändern zu können.

Beginnen Sie mit fünfzig Beispielen, nicht mit einem Framework

Der Reflex ist, zuerst eine Evaluierungsbibliothek auszuwählen. Widerstehen Sie ihm eine Woche lang. Die Bibliothek ist austauschbar und in einem Nachmittag gewechselt; die Beispiele sind das Kapital — und der Teil, den nur Ihr Team erzeugen kann.

Eine Beispiel-Evaluierungsdatei mit ID, Eingabefrage, Stichtag der Frage, geforderten und verbotenen Zeichenketten sowie Tags, kommentiert mit der Bedeutung jedes Feldes.
Ein brauchbarer Fall legt fest, was erscheinen muss — und was nicht.

Fünfzig Fälle sind genug, um nützlich zu sein, und wenige genug, um fertig zu werden. Ziehen Sie sie aus echten Nutzerfragen, nicht aus erfundenen, und gewichten Sie sie zu den Stellen, von denen Sie wissen, dass sie schwierig sind: die mehrdeutige Formulierung, die Frage, deren Antwort sich letztes Quartal geändert hat, jene, bei der die richtige Reaktion eine Ablehnung ist.

  • Formulieren Sie die negative Zusicherung. Was nicht erscheinen darf, ist meist besser prüfbar als das, was erscheinen muss. „Erwähnt die 30-Tage-Frist nicht“ fängt genau die Regression, die Sie fürchten.
  • Nehmen Sie die Ablehnungen auf. Ein Viertel Ihres Sets sollten Fragen sein, bei denen „Ich weiß es nicht“ die richtige Antwort ist. Systeme, die nie ablehnen, schneiden gut ab — bis sie öffentlich falsch liegen.
  • Datieren Sie jeden Fall. Ohne Stichtag wird ein Fall zur aktuellen Richtlinie still falsch, sobald sich die Richtlinie ändert — und Sie debuggen einen Nachmittag lang ein Modell, das sich korrekt verhält.

Drei Arten von Prüfung, nach Kosten geordnet

Drei gestapelte Stufen: eine breite Basis deterministischer Prüfungen, eine schmalere mittlere Stufe mit Modell-als-Judge gegen ein Rubric und eine kleine oberste Stufe menschlicher Prüfung, mit Achsen für steigende Kosten je Fall und sinkendes Volumen.
Günstige Prüfungen laufen über alles. Teure über das, was übrig bleibt.

Die meisten Teams greifen direkt zur mittleren Stufe, weil sie nach der anspruchsvollen Antwort aussieht. Der Ertrag liegt in der untersten. Deterministische Prüfungen kosten im Betrieb nichts, erzeugen kein falsches Vertrauen und fangen die Mehrzahl der Regressionen, die tatsächlich in Produktion gelangen — fehlerhaftes JSON, eine fehlende Quellenangabe, eine durchgesickerte E-Mail-Adresse, eine Antwort viermal länger als die Oberfläche darstellen kann.

Eine brauchbare Regel: Wenn sich eine Prüfung als assert schreiben lässt, gehört sie in die unterste Stufe und niemals an ein Modell. Reservieren Sie den Judge für die wirklich subjektive Frage — ist diese Antwort hilfreich, stimmt der Ton, geht sie tatsächlich auf das Gefragte ein.

Wenn Sie die konkrete Startliste wollen: Diese fünf deterministischen Prüfungen lohnen sich in fast jedem retrieval-gestützten Feature, und alle fünf sind ein Vormittag Arbeit. Die Antwort parst gegen das Schema, das Sie der Oberfläche zugesagt haben; jede Quellenangabe verweist auf ein Dokument, das tatsächlich abgerufen wurde; keine Zeichenkette aus der Verbotsliste taucht auf; keine E-Mail-Adresse und keine Kennung, die nicht in der Eingabe stand, erscheint in der Ausgabe; und die Antwort passt in die Länge, die die Oberfläche darstellen kann.

Eine Quellenangabe, die ins Leere zeigt, ist eine Halluzination, die sich mit einem Datenbank-Lookup fangen lässt.

Ein Modell als Judge — und was das an Vertrauen kostet

Ein Modell, das die Ausgabe eines anderen Modells gegen ein schriftliches Rubric bewertet, ist eine wirklich nützliche Technik. Es ist auch der Punkt, an dem Ihre Evaluierung eine Abhängigkeit erwirbt, die selbst evaluiert werden muss — und diesen zweiten Schritt überspringen Teams.

Zwei gegenübergestellte Felder: Test-Retest-Reliabilität über 0,95 neben Positionsverzerrung über 0,10 bei denselben produktiv eingesetzten Judges, darunter ein Hinweis auf 33 bis 41 Prozentpunkte Abstand zwischen roher Übereinstimmung und Cohens Kappa auf MT-Bench.
Hohe Test-Retest-Reliabilität und starke Positionsverzerrung — in denselben Judges.

Die bislang größte systematische Studie untersuchte 21 Judges von neun Anbietern und benannte die Falle präzise: Reliabilität ohne Validität. Manche Judges zeigen eine Test-Retest-Reliabilität über 0,95 — zweimal gefragt, dieselbe Antwort — und gleichzeitig eine Positionsverzerrung über 0,10: Der Gewinner wechselt, wenn man tauscht, welcher Kandidat zuerst gezeigt wird. arXiv:2606.19544.

Die Zahl, die man verinnerlichen sollte, ist die Kappa-Lücke: Zwischen roher Übereinstimmung und Cohens Kappa fand die Studie auf MT-Bench einen Abfall von 33 bis 41 Prozentpunkten. Rohe Übereinstimmung zählt die Fälle mit, die der Judge zufällig richtig hatte; Kappa nicht. Ein mit „85 % Übereinstimmung mit Menschen“ ausgewiesener Judge liegt womöglich kaum besser als eine zur häufigen Antwort hin gewichtete Münze.

Den Judge selbst validieren

RAND veröffentlichte im März 2026 ein Judge Reliability Harness, das einen Judge als Paar aus Modell und Rubric behandelt und ihn belastet. Bei der Untersuchung von vier Judges über Benchmarks zu Sicherheit, Überzeugung, Missbrauch und Agentenverhalten kamen die Autoren zu dem Schluss, dass kein Judge durchgängig zuverlässig war — die Konsistenz brach bei Formatierungsänderungen, Umformulierungen und veränderter Ausführlichkeit.

Sie brauchen diesen Apparat nicht, um den Großteil des Schutzes zu erhalten. Drei günstige Gewohnheiten decken die obigen Fehlerbilder ab.

  1. Lassen Sie Menschen dreißig bereits vom Judge bewertete Fälle labeln und messen Sie die Übereinstimmung mit Cohens Kappa statt mit einem rohen Prozentwert. Liegt Kappa unter etwa 0,6, ist der Judge nicht bereit, irgendetwas zu blockieren.
  2. Führen Sie jeden paarweisen Vergleich in beiden Reihenfolgen aus und mitteln Sie. Das kostet doppelt und beseitigt die Positionsverzerrung vollständig — den größten gemessenen Effekt.
  3. Führen Sie eine feste Stichprobe erneut aus, wenn Sie Judge-Modell oder Rubric ändern, und vergleichen Sie mit den gespeicherten Werten. Ein Judge-Upgrade, das Ihre Historie still neu bewertet, ist von einer Produktregression nicht zu unterscheiden.

Und halten Sie das Rubric kurz. Ein Rubric mit neun Kriterien erzeugt Urteile, die mit nichts Bestimmtem korrelieren; drei konkrete Kriterien mit Beispielen für bestanden und nicht bestanden erzeugen etwas, worüber man streiten kann.

Evals in die CI einbauen

Pipeline vom Pull Request über eine deterministische Stufe im Sekundenbereich und eine Judge-Stufe im Minutenbereich beim Merge bis zu einem Score-Vergleich mit der Baseline, der den Merge blockieren kann.
Schnelle Prüfungen bei jedem Commit, teure beim Merge, Gate relativ zur Baseline.

Eine Eval-Suite, die läuft, wenn jemand daran denkt, ist kein Gate. Die deterministische Stufe ist schnell und günstig genug für jeden Commit; die Judge-Stufe kostet echtes Geld und gehört an den Merge nach main — oder in einen Nightly-Lauf, wenn selbst das bei Ihrem Volumen teuer wird.

Beim Schwellenwert irren die meisten Teams. Eine absolute Marke — „muss über 90 % liegen“ — blockiert entweder alles an dem Tag, an dem Sie schwierige Fälle ergänzen, oder wird so lange gesenkt, bis sie nie auslöst. Steuern Sie stattdessen über das Delta: Fehlschlag, wenn die Bestehensquote mehr als zwei Punkte unter den letzten main-Build fällt, und bedingungsloser Fehlschlag, wenn ein als kritisch markierter Fall regressiert. Das löst nur bei Änderungen aus, die Sie verursacht haben.

Pinnen Sie die Version des Judge-Modells ausdrücklich. Ein ungepinnter Judge bedeutet, dass Ihre Baseline sich verschiebt, sobald der Anbieter das Modell aktualisiert — und Sie suchen einen Tag lang in Ihrem eigenen Code nach einer Regression, die es nicht gibt.

Die Betriebskosten sind kleiner, als befürchtet, und das sollte man klar sagen. Zweihundert Fälle durch ein Mittelklasse-Modell, mit beiden Reihenfolgen für die paarweisen Vergleiche, kosten wenige Euro pro vollständigem Lauf — deutlich weniger als die wartende Entwicklerin. Nutzen Sie ein günstiges Modell für die gelegentlichen Ermessensfragen der deterministischen Stufe und reservieren Sie das teure für das Rubric; lassen Sie die Suite nachts laufen, statt zu blockieren, wenn Latenz die Randbedingung ist. Der Grund, warum Teams keine Evals fahren, ist fast nie die Token-Rechnung.

Was Sie nach dem Launch messen

Ein vierstufiger Kreislauf: Produktions-Traces, Beschwerden und negative Bewertungen, neue Golden Cases und die Eval-Suite in der CI, die zurück in die Produktion führt.
Jeder Produktionsfehler wird zu einem Testfall. Nur so bleibt die Suite ehrlich.

Das vor dem Launch gebaute Eval-Set misst die Fehler, die Sie sich vorstellen konnten. Die Produktion misst jene, die Sie sich nicht vorstellen konnten — und im Abstand zwischen beiden Mengen liegt die interessante Arbeit. Jede Beschwerde, jede negative Bewertung, jedes Support-Ticket, das mit „der Assistent hat mir gesagt“ beginnt, ist ein Fall, der darauf wartet, aufgeschrieben zu werden.

  • Ablehnungsquote. Eine gegen null laufende Quote heißt meist, dass das System gelernt hat, Dinge zu beantworten, die es ablehnen sollte — nicht, dass es klüger wurde.
  • Quote leerer Retrievals. Wie oft das Modell ohne abgerufenen Kontext geantwortet hat. Diese Antworten stammen aus den Gewichten, nicht aus Ihren Dokumenten — Ihr Halluzinationsrisiko, konzentriert in einer Kennzahl.
  • Übersteuerungsquote durch Menschen. Wo eine prüfende Person eingebunden ist, ist das Ihr ehrlichstes Qualitätssignal — und es kostet nichts.

Eine Warnung zur Schleife: Für jede Beschwerde einen Fall zu ergänzen macht die Suite mit der Zeit zu einem Museum vergangener Vorfälle, gewichtet nach dem, was am lautesten schiefging. Lesen Sie das Set jedes Quartal erneut und fragen Sie, ob es dem heutigen Verkehr noch ähnelt. Entfernen Sie Fälle, deren Feature es nicht mehr gibt. Es ist dasselbe Wartungsargument, das der AI Act für deklarierte Genauigkeit macht: Eine verteidigungsfähige Kennzahl muss auf Daten gemessen werden, die abbilden, was das System heute tatsächlich tut.

Wo Sie anfangen

  • Schreiben Sie diese Woche fünfzig Fälle. In einer YAML-Datei, im Repository, neben dem Code. Kein Framework, keine Plattform, keine Beschaffung.
  • Automatisieren Sie zuerst die Zusicherungen. Schema, verbotene Zeichenketten, geforderte Quellenangaben. Sie werden überrascht sein, wie viele echte Regressionen allein das fängt.
  • Ergänzen Sie einen Judge erst, wenn Sie ein Rubric haben. Drei Kriterien, ausgearbeitete Beispiele und dreißig menschlich gelabelte Fälle zur Gegenprüfung. Ohne die haben Sie eine Abhängigkeit ergänzt, keine Messung.
  • Steuern Sie über das Delta, nicht über einen Absolutwert. Und pinnen Sie die Judge-Version, damit die Baseline nächsten Monat dasselbe bedeutet wie heute.
  • Erweitern Sie die Suite nur aus echten Fehlern. Ein neuer Fall pro Produktionsbeschwerde. Eine Suite, die anders wächst, misst Ihre Vorstellungskraft.

Nichts davon erfordert eine Plattform, und der gesamte erste Durchgang passt in einen Nachmittag. Dass es selten passiert, liegt daran, dass es keine Demo hervorbringt — nur die Fähigkeit, nächsten Monat etwas zu ändern und vor der Kundin zu wissen, ob Sie es kaputt gemacht haben.