KI-Agenten evaluieren: von Evals zum zuverlässigen Produktivbetrieb
Wie man autonome Agenten bewertet, denen man vertrauen kann — LLM-as-a-Judge richtig gemacht, die Metriken, die zählen, und CI/CD-Quality-Gates gegen Regressionen.
Definition
Agenten-Evaluierung (Evals) ist die systematische Messung der Qualität eines Agenten anhand definierter Kriterien — Aufgabenerfolg, Tool-Nutzung, Faithfulness, Kosten und Latenz. Sie verbindet automatisiertes Scoring, oft mit einem LLM-Judge, und menschliche Prüfung als wiederholbares Gate statt als Einmaltest.
Eine Demo beweist, dass ein Agent einmal funktionieren kann. Die Evaluierung beweist, dass er zuverlässig funktioniert, und beweist es weiter, während sich Modell, Prompts und Tools darunter ändern. Ohne Evals ist jedes Deploy ein Ratespiel.
Warum sind Agenten schwer zu evaluieren?
Ein klassischer Test prüft eine feste Ausgabe. Agenten sind nicht-deterministisch und offen: Es gibt viele akzeptable Antworten, der Pfad variiert, und „korrekt“ heißt oft faithful, nützlich und sicher statt zeichengleich. Die Evaluierung verschiebt sich daher von Assertions zum Scoring — dem Bewerten von Ausgaben anhand von Kriterien, in großem Maßstab.
LLM-as-a-Judge, richtig gemacht
Der praktische Weg zum Scoring im großen Maßstab ist LLM-as-a-Judge: Ein Modell bewertet oder vergleicht Ausgaben. Es ist günstig und schnell — und falsch, wenn Sie die Kalibrierung überspringen. Judges tragen vorhersehbare Bias:
- Positions-Bias (Reihenfolge der Optionen)30%
- Verbosity-Bias (länger = besser)28%
- Self-Enhancement (bevorzugt eigenen Stil)24%
- Formatierungs- / Autoritätssignale18%
Kalibrierung ist nicht optional. Labeln Sie 100–200 Beispiele von Hand, lassen Sie den Judge darauf laufen und messen Sie die Übereinstimmung — Ziel ist Cohens Kappa über etwa 0,6. Randomisieren Sie die Optionsreihenfolge gegen Positions-Bias und nutzen Sie Rubriken statt vager „1–10“-Prompts.
| Judge-Bias | Worum es geht | Wie mildern |
|---|---|---|
| Positions-Bias | Bevorzugt die zuerst oder zuletzt gezeigte Option | Reihenfolge randomisieren; über Tausch mitteln |
| Verbosity-Bias | Bewertet längere Antworten höher | Gegen Rubrik bewerten, nicht nach Länge |
| Self-Enhancement | Zieht eigenen Stil oder Modell vor | Anderen Judge nutzen; menschlich stichproben |
| Formatierungssignale | Lässt sich von Formatierung beeinflussen | Substanz bewerten; Styling entfernen |
Die Metriken, die zählen
- Task-Completion-Rate — hat der Agent die Aufgabe erledigt?
- Faithfulness / Halluzinationsrate — ist die Ausgabe fundiert?
- Tool-Auswahl-Genauigkeit — hat er die richtigen Tools gewählt und aufgerufen?
- Kosten und Latenz pro Aufgabe — ist es bezahlbar und schnell genug?
Erfassen Sie diese auf einem festen Testset, damit eine Score-Änderung eine Änderung des Agenten bedeutet, nicht der Daten.
Evals gehören in CI/CD
Am wirkungsvollsten ist es, ein kuratiertes Fallset als Golden Dataset zu behandeln und bei jeder Änderung auszuführen. Eine Prompt-Änderung, die einen Fall hebt, kann fünf andere versenken; nur eine Regressionssuite fängt das ab. Setzen Sie Schwellen — Completion-Rate, Faithfulness — und lassen Sie den Build fehlschlagen, wenn sie fallen. Das ist Eval-Driven Development: Sie ändern den Agenten gegen eine messbare Latte, nicht gegen ein Bauchgefühl.
Eine Einstiegsschleife
- Bauen Sie ein kleines Golden Set aus realen, vielfältigen Fällen.
- Bewerten Sie mit einem kalibrierten Judge plus stichprobenartiger menschlicher Prüfung.
- Gaten Sie Deploys über Completion-Rate und Faithfulness.
- Erweitern Sie das Set bei jedem neuen Produktionsfehler.
Zuverlässige Agenten sind evaluierte Agenten. Die hier nachgewiesene Zuverlässigkeit macht auch menschliche Aufsicht und Governance glaubwürdig. Begriffe stehen im Glossar.
Häufige Fragen
Kann ein LLM ein anderes LLM zuverlässig bewerten?
Ja, aber erst nach Kalibrierung gegen menschliches Urteil, und ein unkalibrierter Judge ist schlimmer als nutzlos, weil er seine eigenen Vorlieben misst und dabei autoritativ wirkt. Das praktische Vorgehen ist, ein repräsentatives Set von 100 bis 200 Beispielen von Hand zu labeln, den Judge darauf laufen zu lassen und die Übereinstimmung mit den menschlichen Labels zu messen — Cohens Kappa über etwa 0,6 ist eine vernünftige Latte, bevor Sie dem Judge etwas anvertrauen, das ein Deploy gatet. Das zählt, weil Judges gut dokumentierte, vorhersehbare Bias tragen: Sie bevorzugen die zuerst oder zuletzt gezeigte Option, bewerten längere Antworten unabhängig von der Qualität höher, ziehen den eigenen Stil vor und lassen sich von selbstbewusster Formatierung beeinflussen. Kalibrierung plus ein paar defensive Gewohnheiten — Optionsreihenfolge randomisieren, gegen eine explizite Rubrik statt eines vagen Eins-bis-zehn-Prompts bewerten und gelegentlich gegen frische menschliche Labels nachprüfen — machen aus einem Judge statt einer Belastung einen schnellen, günstigen Scorer. Behandeln Sie den Judge selbst als etwas, das Sie evaluieren, nicht als angenommene Grundwahrheit.
Was ist die nützlichste einzelne Agenten-Metrik?
Die Task-Completion-Rate, gemessen gegen ein festes Testset, denn sie beantwortet die Frage, die wirklich darüber entscheidet, ob der Agent nützlich ist — erledigt er die Aufgabe, end-to-end — und die meisten anderen Metriken sind Verfeinerungen, sobald Sie das beantworten können. Der Teil mit dem festen Set gibt ihr Biss: Gegen dieselben kuratierten Fälle jedes Mal gemessen, bedeutet ein Rückgang der Completion-Rate, dass sich der Agent geändert hat, nicht dass der Traffic des Tages schwerer war, und genau das macht aus einer stillen Regression eine sichtbare. Es ist zudem die Metrik, die ein Modell-Upgrade oder eine Prompt-Änderung als stabiler Vergleichspunkt übersteht, sodass Sie erkennen, ob eine Änderung half oder still eine Klasse von Aufgaben brach. Allerdings kann Completion allein täuschen, wenn Fehlschläge still und schädlich sind, also koppeln Sie sie mit Faithfulness und, wo der Agent handelt, damit, ob die Fehlschläge abgefangen werden. Beginnen Sie mit der Completion-Rate als Schlagzeile und ergänzen Sie dann die anderen als Nebenrollen.
Wie passen Evals in CI/CD?
Behandeln Sie ein kuratiertes Set repräsentativer Fälle als Golden Dataset und führen Sie es automatisch bei jeder Änderung an Modell, Prompts oder Tools aus, genau wie Sie Unit-Tests auf Code laufen lassen. Setzen Sie explizite Schwellen — eine minimale Completion-Rate, eine maximale Halluzinationsrate — und lassen Sie den Build fehlschlagen, wenn eine Änderung eine Metrik darüber hinausschiebt, damit eine Regression blockiert wird, bevor sie ausgeliefert wird, statt von Nutzern entdeckt zu werden. Das ist gemeint, wenn man von Eval-Driven Development spricht: Sie ändern den Agenten gegen eine messbare Latte statt gegen den subjektiven Eindruck, dass es besser scheint. Die entscheidende Disziplin ist, dass eine Prompt-Änderung, die einen Fall hebt, routinemäßig mehrere andere verschlechtert, und nur eine als Gate laufende Regressionssuite fängt diesen Tausch ab. Halten Sie das Golden Set klein genug, um bei jedem Commit zu laufen, aber repräsentativ genug, um aussagekräftig zu sein, und erweitern Sie es jedes Mal, wenn die Produktion einen neuen Fehlermodus zeigt, sodass die Suite genau dort stärker wird, wo sich der Agent als schwach erwiesen hat.
Wie groß muss ein Golden-Eval-Set sein?
Kleiner, als die meisten Teams zu Beginn erwarten, und die richtige Größe wird von Abdeckung und Stabilität bestimmt, nicht von einer rohen Zahl. Beginnen Sie mit einigen Dutzend bis ein paar hundert Fällen, gewählt, um die reale Verteilung der Arbeit abzudecken — die häufigen Happy Paths, die wichtigen Randfälle und die konkreten Fehlschläge, die Sie bereits gesehen haben —, denn ein kleines Set, das die Arten abdeckt, wie der Agent tatsächlich versagt, ist weit nützlicher als ein großes Set aus Beinahe-Duplikaten. Der praktische Test ist statistische Stabilität: Wenn ein erneuter Lauf desselben Agenten auf dem Set jedes Mal eine stark abweichende Punktzahl ergibt, ist das Set zu klein oder zu verrauscht, um darauf zu gaten; ist die Punktzahl stabil und bewegt eine echte Regression sie, tut es seinen Dienst. Halten Sie es klein genug, um bei jeder Änderung zu laufen, ohne das Team auszubremsen, und erweitern Sie es bewusst, indem Sie bei jedem in der Produktion sichtbaren neuen Fehlermodus einen Fall hinzufügen, sodass die Suite über die Zeit an Wert gewinnt. Qualität und Abdeckung der Fälle schlagen schiere Menge, und einige hundert gut gewählte Beispiele übertreffen Tausende redundanter.