Evals: woher du weißt, dass es funktioniert
Ein geänderter Prompt fühlt sich besser an – bis drei Wochen später etwas anderes kaputt ist. Ein Eval ist ein fester Satz von Fällen, an dem du jede Änderung misst. Wie du ihn in einer Stunde baust.
Boaz Lichtenstein
Wer an einem Agenten arbeitet, ändert ständig etwas: einen Satz im Prompt, ein Werkzeug, das Modell. Jede Änderung fühlt sich wie eine Verbesserung an, weil man sie an dem Fall prüft, der einen gerade geärgert hat. Ob dabei drei andere Fälle kaputtgegangen sind, zeigt sich erst im Betrieb.
Ein Eval beendet dieses Raten. Es ist ein fester Satz von Fällen, den du vor und nach jeder Änderung vollständig laufen lässt.
Der Testsatz in einer Stunde
1. Zehn bis dreißig echte Fälle sammeln. Aus dem Postfach, dem Ticketsystem, dem Verlauf – keine ausgedachten. Ausgedachte Fälle sind zu sauber.
2. Die Fehlschläge einbauen. Mindestens ein Fünftel der Fälle sollten solche sein, an denen der Agent schon gescheitert ist oder scheitern könnte: unvollständige Angaben, widersprüchliche Quellen, die Anfrage, die er hätte ablehnen sollen.
3. Zu jedem Fall das richtige Ergebnis festhalten. Entweder die exakte Antwort oder die Kriterien, die eine gute Antwort erfüllen muss.
4. Einfrieren. Der Satz bleibt, wie er ist. Er wächst nur – siehe unten.
Fall 02 und 03 sind die wertvollen. Ein Agent, der nur Fall 01 kann, ist kein Agent, sondern eine Vorlage.
Drei Arten zu bewerten
Automatisch prüfen. Wo das Ergebnis eine Zahl, eine Kategorie oder ein Feld ist, vergleicht ein kleines Skript mit dem Soll. Das ist die billigste und zuverlässigste Bewertung – nutze sie, wo immer es geht. Oft lohnt es sich, den Agenten das Ergebnis strukturiert ausgeben zu lassen, nur damit es so prüfbar wird.
Mensch mit Kriterienliste. Für Texte: drei bis fünf Ja/Nein-Fragen je Fall. „Nennt die Antwort die Belegnummer?“ lässt sich beantworten. „Ist die Antwort gut?“ nicht.
Modell als Prüfer. Ein zweites Modell bewertet anhand derselben Kriterienliste. Das skaliert – aber der Prüfer irrt auch. Vergleiche seine Urteile regelmäßig an Stichproben mit deinen eigenen, und gib ihm die Kriterien, nicht nur die Frage nach dem Gesamteindruck.
Was du misst
Nicht nur „richtig oder falsch“:
- Trefferquote – wie viele Fälle erfüllen ihre Kriterien?
- Grenzverletzungen – hat der Agent etwas getan, das er nicht durfte? Ein einziger solcher Fall wiegt schwerer als zehn mittelmäßige Antworten.
- Kosten und Dauer je Fall – eine Änderung, die zwei Prozentpunkte bringt und die Kosten verdreifacht, ist selten ein Gewinn.
Und miss mehrmals. Modelle antworten nicht jedes Mal gleich. Drei Durchläufe je Fall zeigen, ob ein Ergebnis stabil ist oder Zufall.
Wann du ihn laufen lässt
- Vor jeder Änderung – das ist die Nulllinie.
- Nach jeder Änderung – an Prompt, Werkzeugen, Regeldatei, Skills.
- Bei jedem Modellwechsel – auch wenn der Anbieter nur die Version hinter demselben Namen austauscht.
- In festen Abständen – weil sich Quellen und Anbindungen ändern, ohne dass du etwas getan hast.
Der Satz wächst mit jedem Fehler
Macht der Agent im Betrieb einen Fehler, wird daraus ein neuer Fall – bevor du den Fehler behebst. Erst siehst du ihn im Eval scheitern, dann änderst du etwas, dann siehst du ihn bestehen. So ist belegt, dass die Korrektur wirkt, und derselbe Fehler kann nicht unbemerkt zurückkommen.
Drei Fallen
Auf den Satz hin optimieren. Wer so lange am Prompt feilt, bis alle dreißig Fälle bestehen, hat einen Agenten für genau diese dreißig. Halte ein paar Fälle zurück, die du nur gelegentlich laufen lässt.
Zu leichte Fälle. Hundert Prozent Trefferquote heißt meist: Der Satz prüft nichts. Ein guter Satz hat Fälle, die scheitern.
Stil statt Sache bewerten. Ob die Antwort freundlich klingt, ist selten das Problem. Ob sie die richtige Zahl nennt, schon.
Mit einem Eval in der Hand lässt sich die nächste Frage beantworten, ohne zu raten: ob ein wiederverwendbarer Ablauf – ein Skill – die Ergebnisse wirklich verbessert.