Messen statt raten – Evaluation für deine laufenden KI-Workflows

Stell dir eine Serviceadresse vor. Jeden Tag laufen dort Mails ein. Ein Prompt sortiert sie nach Anliegen und schlägt eine Antwort vor. Das Ding läuft seit sechs Wochen und macht seinen Job.

Dann änderst du zwei Sätze im Prompt. Du testest mit drei Mails, die du gerade zur Hand hast. Die Antworten wirken runder. Du rollst die Änderung aus.

Eine Woche später beschwert sich jemand, dass eine Frist übersehen wurde. War das deine Änderung? Du weißt es nicht. Du kannst es nicht wissen, weil du nie festgehalten hast, wie gut es vorher war.

Der Unterschied zwischen glauben und wissen

Das ist der Alltagsnutzen, wegen dem sich der Aufwand rechnet. Ein Modellwechsel bricht Prompts. Anbieter tauschen Modelle aus, ohne dich zu fragen. Ein Testset merkt das. Du merkst es sonst beim Kunden.

Die naheliegende Reaktion auf Schritt 1 ist: Wir brauchen ein Werkzeug. Ein Dashboard, eine Metrik, irgendetwas mit Zahlen. Das ist der teuerste Weg, sich Arbeit zu ersparen.

Wer nicht 20 bis 50 echte Outputs von Hand gelesen hat, weiß nicht, was er messen soll. Du kannst keine Metrik bauen für einen Fehler, den du noch nie gesehen hast. Und die Fehler, die deine Anwendung wirklich hat, sind fast nie die, die du erwartet hättest.

Der Ablauf in vier Schritten

1. Fälle sammeln. Echte Durchläufe, keine ausgedachten. Eingabe und Ausgabe zusammen, nicht nur das Ergebnis.
2. Offen notieren. Ein Fall, ein bis zwei Sätze in eigenen Worten. Noch keine Kategorien, noch keine Bewertung.
3. Gruppieren. Notizen nebeneinanderlegen und zusammenschieben, was sich ähnelt. Aus den Gruppen werden Namen.
4. Zählen. Wie oft kommt jede Gruppe vor? Erst hier entstehen Zahlen, und zwar aus dem Material statt aus einem Framework.

Das Verfahren stammt aus der qualitativen Sozialforschung. Erst offen kodieren, dann achsen-kodieren. Der Gruppierungsschritt ist der wichtigste und der, den fast alle überspringen.

Sechs Notizen, und du siehst schon, wohin es geht. Zwei Mails mit demselben Muster, zwei mit einem Zahlen- oder Fristproblem, eine Tonlage, eine Erfindung. Das ist mehr Erkenntnis als jedes Dashboard dir im ersten Monat liefert.

Wer entscheidet, was ein Fehler ist

Eine Person, die die Nutzer wirklich versteht. Nicht das Team im Konsens. Husain nennt das den wohlwollenden Diktator: eine Domänenexpertin, deren Urteil gilt. Klingt unangenehm, spart aber die Diskussionen, in denen Qualitätsstandards zerredet werden.

Jetzt legst du die Notizen nebeneinander und schiebst zusammen, was sich ähnelt. Nicht nach vorgefertigten Kategorien, sondern nach dem, was tatsächlich dasteht. Die Namen der Gruppen entstehen zuletzt.

Und hier passiert das Interessante. Die erfundene Angabe ist der Fehler, der dich am meisten aufregt. Sie kommt zweimal vor. Das übersehene zweite Anliegen regt niemanden auf, es fällt kaum auf, und es passiert elfmal. Wenn du deiner Empörung folgst, arbeitest du am seltensten Fehler.

Wann du aufhören kannst

Wenn ungefähr 20 weitere Fälle keine neue Kategorie mehr hervorbringen, hast du das Feld abgedeckt. Der Fachbegriff dafür ist Sättigung. Du musst nicht jeden möglichen Fehler erwischen, sondern die, die tatsächlich vorkommen.

Aus jeder Fehlerkategorie wird mindestens ein Testfall. Dazu die Grenzfälle, die dir schon mal um die Ohren geflogen sind. Zusammen sind das 10 bis 20 Fälle, nicht 500.

Echte Fälle schlagen ausgedachte, und zwar deutlich. Ausgedachte Testfälle sind ordentlich formuliert, haben ein Anliegen und einen höflichen Ton. Echte Mails haben drei Anliegen, einen Rechtschreibfehler im Namen, eine Frist im Nebensatz und manchmal Wut. Genau daran scheitert dein Prompt.

Die Vorlage

Die letzte Spalte ist die, die am meisten Arbeit macht und am meisten bringt. Sie macht aus einer Liste ein Protokoll. Beim nächsten Lauf siehst du nicht nur, was durchfällt, sondern was neu durchfällt.

Die Reihenfolge ist keine Geschmacksfrage. Geh jede Fehlerkategorie durch und frag: Lässt sich das buchstäblich prüfen? Bei überraschend vielen Fehlern lautet die Antwort ja.

Sechs Zeilen, keine davon braucht ein Modell. Zwei der fünf Fehlerkategorien aus Schritt 3 sind damit abgedeckt. Das ist der Grund, warum du nicht mit dem Judge anfängst.

Und die menschliche Rubrik verschwindet nie ganz. Sie ist der Maßstab, an dem alles andere geeicht wird. Ein Judge, der nie gegen menschliches Urteil geprüft wurde, misst nur seine eigene Meinung.

Der erste Reflex beim Bewerten ist eine Skala. Hilfsbereitschaft 1 bis 5. Klarheit 1 bis 5. Am Ende steht ein Dashboard mit Durchschnittswerten, und niemand kann sagen, was sie bedeuten.

Was ist der Unterschied zwischen 3 und 4? Frag zwei Leute, du bekommst zwei Antworten. Frag dieselbe Person nächste Woche nochmal, du bekommst eine dritte. Und wenn der Wert von 4,2 auf 4,7 steigt, weiß niemand, ob das ein Erfolg ist oder Rauschen.

Schwammig wird konkret

Sieh dir die rechte Spalte an. Jede Zeile ist ein konkreter Fehlermodus, kein Gefühl. Und jede lässt sich mit Ja oder Nein beantworten, ohne dass zwei Leute streiten müssen.

Ein Nebeneffekt, der unterschätzt wird: Skalen-Dashboards zerstören Vertrauen. Wenn in einer Runde jemand fragt, was die 4,2 bedeutet, und niemand kann es beantworten, ist die ganze Messung erledigt. "11 von 15 Fällen bestanden" versteht dagegen jeder sofort.

Wenn du einen Judge einsetzt, hast du das Problem nicht gelöst, sondern verschoben. Du hast jetzt zwei Modelle, denen du vertrauen musst, statt einem.

Ein Judge ist ein Prompt, keine Funktion. Eine Funktion gibt bei gleicher Eingabe immer dasselbe zurück. Ein Judge nicht. Er reagiert auf Reihenfolge, auf Länge, auf Formulierung. Und wenn der Anbieter das Modell dahinter austauscht, ändert sich dein Maßstab, ohne dass du etwas angefasst hast.

Vier dokumentierte Verzerrungen

Der Widerspruch, den du selbst nachstellen kannst

Das dauert fünf Minuten und ist überzeugender als jede Studie. Nimm zwei Antworten, die sich wirklich unterscheiden, und lass beide Reihenfolgen laufen.

Die drei Regeln für einen brauchbaren Judge

1. Binär fragen. Eine konkrete Ja/Nein-Frage pro Fehlermodus, nicht eine Gesamtnote.
2. Selbst labeln. Einen Teil der Fälle von Hand bewerten. Das ist dein Maßstab.
3. Den Judge prüfen. Judge-Urteil gegen deine eigenen Labels halten. Wo er abweicht, ist die Rubrik unklar, nicht der Fall schwierig.

Dazu kommt die Buchführung: Judge-Modell, Rubrik-Fassung und Prompt-Vorlage gehören zusammen festgehalten und datiert. Ein Judge-Wechsel ist keine Einstellungsänderung, sondern ein neuer Maßstab. Nach einem Wechsel sind alle alten Ergebnisse nur noch eingeschränkt vergleichbar.

Zurück zur Serviceadresse. Du hast jetzt 15 Fälle in einer Tabelle, binäre Kriterien und einen Stand vom letzten Lauf. Damit wird aus jeder Änderung eine Messung statt einer Hoffnung.

Die letzte Zeile ist die wichtigste und die, die zuerst wegfällt. Ein Testset veraltet. Es prüft die Fehler von damals. Die neuen findest du nur, indem du weiter liest.

Was du ab morgen tun kannst

1. Eine halbe Stunde blocken und 20 echte Outputs lesen. Ohne Werkzeug, ohne Vorbereitung.
2. Notizen gruppieren und zählen. Die häufigste Gruppe ist dein nächstes Thema.
3. Pro Gruppe einen Testfall in eine Tabelle schreiben, Kriterium binär.
4. Prüfen, welche Kriterien sich buchstäblich prüfen lassen. Mit denen anfangen.
5. Den Stand datieren. Beim nächsten Mal hast du einen Vergleich.

Die Gegenposition, ehrlich gesagt

Es gibt das Argument, dass sich das alles erledigt, sobald die Modelle gut genug sind. Wer es vertritt, sagt: Der Aufwand von heute repariert Schwächen, die in zwei Jahren weg sind.

Die sieben Regeln auf einen Blick

Wenn du weiter willst: Agenten zu bewerten ist der schwerere Fall. Dort zählt nicht nur das Ergebnis, sondern der Weg dorthin, mit mehreren Schritten, Werkzeugaufrufen und Zwischenzuständen. Agent-Design-Space und Vom Prompt zum Loop sind die nächsten Stationen.