Woher weißt du, dass dein AI-Feature gut ist? Evals mit Rubrics

Das AI-Feature ist gebaut. Die Demo lief großartig, der Kunde war begeistert, alles ist live. Und dann änderst du zwei Wochen später eine Kleinigkeit am Prompt – und fragst dich: Ist der Output jetzt besser geworden? Schlechter? Woher soll ich das wissen?

Genau an dieser Stelle merkt man, dass klassisches Testen nicht mehr funktioniert. Ein Unit Test prüft: Eingabe X ergibt exakt Ausgabe Y. Ein LLM liefert aber jedes Mal eine andere Formulierung. Alle sind irgendwie richtig, keine ist exakt gleich. assertEquals läuft ins Leere.

Was die meisten Teams dann machen: Sie schauen sich ein paar Outputs an, nicken, und shippen. Das ist kein Testen. Das ist Hoffen.

Das Problem: „Sieht gut aus" skaliert nicht

Am Anfang geht das gut. Du liest zehn generierte Antworten, sie wirken vernünftig, fertig. Aber dieses Vorgehen bricht an drei Stellen zusammen:

Nach jeder Prompt-Änderung müsstest du alles neu lesen. Machst du natürlich nicht. Also schleichen sich Verschlechterungen ein, die niemand bemerkt – bis ein Nutzer sich beschwert.
Du liest mit rosaroter Brille. Man sieht, was man sehen will, besonders beim eigenen Prompt. Ein systematischer Fehler, der in jedem fünften Output steckt, fällt beim Durchscrollen nicht auf.
Modell-Updates passieren ohne dich. Der Anbieter tauscht das Modell unter der Haube, dein Prompt bleibt gleich, dein Output nicht. Ohne Messung merkst du es schlicht nicht.

Mir ist das selbst passiert: Eine Prompt-Änderung, die einen Fall verbessern sollte, hat drei andere leise verschlechtert. Aufgefallen ist es erst Tage später. Seitdem behandle ich LLM-Output wie jeden anderen Code: Er wird getestet. Nur eben anders.

Rubrics: Bewertungsraster statt Bauchgefühl

Die Lösung ist unspektakulär und stammt aus der Schule: eine Rubric – ein Bewertungsraster. Statt zu fragen „ist der Output gut?", zerlegst du „gut" in einzelne, prüfbare Kriterien.

Beispiel: Ein Feature generiert Antwortvorschläge für Kundenanfragen. Die Rubric dafür:

Beantwortet die eigentliche Frage – nicht eine ähnliche, die eigentliche.
Erfindet nichts – keine Preise, Fristen oder Features, die es nicht gibt.
Trifft den Ton – professionell, aber nicht steif.
Hält die Länge – drei bis fünf Sätze, kein Aufsatz.
Eskaliert im Zweifel – bei Rechtsfragen oder Beschwerden: Verweis an einen Menschen.

Jedes Kriterium wird einzeln mit pass oder fail bewertet. Keine Punkteskalen – dazu gleich mehr. Das Entscheidende: „Gut" ist jetzt keine Geschmacksfrage mehr, sondern eine Checkliste. Über die Kriterien kann man streiten, und genau das ist der Punkt – die Diskussion passiert einmal beim Schreiben der Rubric, nicht bei jedem einzelnen Output aufs Neue.

LLM-as-Judge: Das Modell bewertet mit

Jetzt der Teil, der zunächst zirkulär klingt: Die Bewertung übernimmt wieder ein LLM. Man gibt einem zweiten Modell den Output plus die Rubric und lässt es jedes Kriterium prüfen.

Warum funktioniert das? Weil Bewerten leichter ist als Erzeugen. Ein Modell, das beim Generieren einen Preis erfindet, erkennt ziemlich zuverlässig, dass in einem fremden Text ein Preis steht, der nicht in den Quelldaten vorkommt. Prüfen ist die einfachere Aufgabe – so wie Korrekturlesen leichter ist als Schreiben.

Damit wird aus dem Bauchgefühl ein Testlauf: 30 typische Eingaben, jede durch das Feature geschickt, jeden Output vom Judge gegen die Rubric geprüft. Nach jeder Prompt-Änderung läuft das Set erneut. Vorher 28 von 30 bestanden, nachher 23? Dann weißt du Bescheid, bevor es ein Nutzer merkt.

Was ich dabei gelernt habe

Pass/fail schlägt Punkteskalen. „Bewerte den Ton von 1 bis 10" liefert heute eine 7 und morgen eine 8 für denselben Text. „Ist der Ton professionell, ohne steif zu sein – ja oder nein?" ist stabil. Skalen driften, Entscheidungen nicht.
Ein Kriterium pro Frage. Ein Judge, der fünf Dinge gleichzeitig prüfen soll, übersieht welche. Fünf einzelne Prüfungen sind zuverlässiger als eine große – und du siehst, welches Kriterium kippt.
Klein anfangen reicht. 20 bis 50 Testfälle decken erstaunlich viel ab. Wichtiger als die Menge: echte Fälle aus der Produktion, vor allem die unbequemen. Jedes Mal, wenn im Betrieb etwas schiefgeht, wandert der Fall ins Set.
Die Rubric ist Code. Sie liegt im Repo, sie wird versioniert, Änderungen laufen über Review. Eine Rubric, die in einem Google Doc verstaubt, ist keine.
Der Judge ersetzt den Menschen nicht. Er skaliert ihn. Ich lese weiterhin Stichproben – aber der Judge liest alles. Und ab und zu prüfe ich den Judge selbst: bewertet er die Fälle so, wie ich es täte? Wenn nicht, wird die Rubric geschärft, nicht das Urteil ignoriert.

Wann sich der Aufwand lohnt

Ehrliche Antwort: nicht immer. Für einen internen Prototyp, dessen Output ohnehin ein Mensch prüft, ist eine Eval-Pipeline Overkill.

Die Grenze ist für mich dieselbe wie bei Tests: Sobald eine Prompt-Änderung dir ein mulmiges Gefühl macht, weil du nicht weißt, was sie kaputtmacht – dann ist es Zeit. Bei Software nennt man das Regressionstests. Bei LLM-Features heißt es Evals. Es ist dasselbe Bedürfnis: ändern können, ohne Angst zu haben.

Und wie bei Tests gilt: Wer sie nicht hat, spart die Zeit nicht ein. Er verschiebt sie nur – vom Entwickeln ins Debuggen, nachdem sich der Nutzer beschwert hat.

Fazit: Messen statt hoffen

LLM-Features fühlen sich am Anfang an wie Magie, und Magie testet man nicht – man staunt. Genau das ist die Falle. Der Output ist nicht magisch, er ist nur nichtdeterministisch. Und Nichtdeterminismus ist kein Grund, aufs Messen zu verzichten. Er ist der Grund, anders zu messen.

Eine Rubric mit klaren Kriterien, ein Judge, der sie prüft, ein Testset aus echten Fällen – mehr braucht es für den Anfang nicht. Kein Framework, keine Plattform, keine Data-Science-Abteilung.

Ein AI-Feature ohne Evals ist ein Auto ohne Tacho. Es fährt – du weißt nur nicht, wie schnell, und du merkst erst am Knall, dass es zu schnell war.