KI-Agenten evaluieren: So erkennst du, ob dein Agent wirklich funktioniert

Eine Eval für einen KI-Agenten ist ein systematischer Test, der misst, wie gut ein Agent eine bestimmte Aufgabe löst. Jede Eval verbindet eine Aufgabe (ein Szenario, in das du den Agenten stellst) mit einem Grader (Logik, die das Ergebnis bewertet) und macht so aus einem vagen "fühlt sich in letzter Zeit schlechter an" eine Zahl, mit der du arbeiten kannst. Du baust Evals, indem du repräsentative Aufgaben sammelst, Grader schreibst (deterministischer Code für objektive Prüfungen, ein LLM-as-a-Judge für Qualität) und sie bei jeder Änderung neu laufen lässt. So kannst du eine Verbesserung belegen. Vorher hast du nur darauf gehofft.

Das ist die ganze Disziplin in einem Absatz. Der Rest dieses Artikels zeigt, wie das in der Praxis läuft, an einem konkreten Beispiel, zu dem ich immer wieder zurückkehre: ein Agent, der Folien erstellt, über fünf Versionen verbessert, wobei jede Änderung von dem angetrieben wird, was die Evals ans Licht gebracht haben. Ich komme aus der Fertigung (Maschinenbau, danach Automatisierung bei Bosch), und da gilt eine einfache Regel. Aus den Eingaben müssen vorhersagbare Ergebnisse folgen. Kannst du das Ergebnis nicht messen, hast du keinen Prozess, sondern nur die Hoffnung, dass es schon passt.

Warum die Messung von KI-Agenten jetzt zählt

Die meisten Teams können inzwischen einen KI-Agenten bauen. Deutlich weniger können die einzige Frage beantworten, die zählt, sobald er läuft: funktioniert er tatsächlich, und hat die letzte Änderung ihn besser oder schlechter gemacht? Diese Lücke kostet. Gartner prognostizierte im Juni 2025, dass über 40 % der Projekte mit agentenbasierter KI bis Ende 2027 eingestellt werden, und nannte als Gründe steigende Kosten, unklaren geschäftlichen Nutzen und mangelhafte Risikokontrolle. Meine Erfahrung: Es überleben die Projekte, die sich selbst messen können. Still scheitern die, die abgedriftet sind, weil niemand hingesehen hat.

Evals sind das Hinsehen. Sie sind die Brücke von "scheint zu funktionieren" zu "wir wissen, dass es funktioniert, und wir wissen auch, woher wir das wissen". Wenn ich für einen Kunden einen von uns betriebenen KI-Mitarbeiter baue, gehört das Eval-Set vom ersten Tag an dazu. Ein weiteres KI-Abo bringt dir hier nichts. Was zählt, ist KI, die du tatsächlich messen kannst, und ohne Messung gibt es keine Übergabe.

Was ist eine Eval für einen KI-Agenten?

Lass den Jargon weg, dann besteht eine Eval aus zwei zusammengeschraubten Teilen:

einer Aufgabe: ein konkretes Szenario, etwa "erstelle ein Deck mit fünf Folien zum Thema Gehaltsverhandlung", und
einem Grader: Logik, die deine Erwartung festhält und das Ergebnis bewertet, etwa "es sind genau fünf Folien" oder "der Text ist lesbar, bewertet von 0 bis 5".

Kurz gesagt: Eine Eval ist ein Unit-Test für Output, der nicht deterministisch ist. Ein normaler Unit-Test prüft, ob 2 + 2 auch 4 ergibt. Eine Eval prüft etwas Weicheres, das sich schwerer festnageln lässt: taugt dieses Folien-Deck überhaupt etwas? Sie verwandelt die Antwort in einen Wert, den du über Versionen hinweg verfolgen kannst. Ohne sie steckt Qualität als Gefühl in deinem Kopf. Mit ihr wird Qualität zu einem Wert: vergleichbar über die Zeit, auf eine Ursache zurückführbar und unbestreitbar, wenn eine Änderung die Sache verschlechtert. Wenn du das Gesamtbild davon willst, wie verlässliche Agenten aussehen, darüber habe ich unter vertrauenswürdige KI-Agenten geschrieben.

Warum reichen öffentliche Benchmarks nicht?

Öffentliche Benchmarks messen allgemeine Fähigkeiten. Deine konkrete Aufgabe ist eine andere Frage. Wenn ein neues Modell erscheint, kommt es mit einem Zeugnis: SWE-bench Verified fürs Coden, OSWorld und τ-bench für die Tool-Nutzung, ARC-AGI fürs Schlussfolgern. Das sind auch Evals, und sie sind wirklich nützlich, um Modelle in ihren allgemeinen Fähigkeiten miteinander zu vergleichen. SWE-bench Verified etwa gibt einem Agenten echte GitHub-Issues und bewertet einen Fix, indem es die Testsuite laufen lässt; Anthropic merkt an, dass Modelle darin in etwa einem Jahr von rund 40 % auf über 80 % geklettert sind.

Aber ein öffentliches Leaderboard sagt dir fast nichts über deinen Anwendungsfall. Dein Agent macht kein "Coden im Allgemeinen". Er baut deine Folien-Decks, sortiert deine Leads vor, textet deine Newsletter, alles an deinen Maßstäben und deiner Vorstellung von fertig gemessen. Ein Modell, das einen Benchmark anführt, kann trotzdem Output liefern, den deine Nutzer ablehnen, weil der Benchmark eine andere Aufgabe gemessen hat. Die Regel, auf die jedes ernsthafte Team am Ende kommt: bau deine eigenen Evals und miss die Modelle an deiner Arbeit statt umgekehrt.

Welche drei Arten von Gradern gibt es?

Ein Grader ist schlicht die Art, wie du einen Output bewertest, und du hast drei Familien, zwischen denen du abwägst: deterministischer Code, ein LLM-Judge und ein menschlicher Experte.

Code-Grader sind deterministische Logik: ein String-Abgleich, ein Regex, ein Zählen. Ist eine Datei entstanden? Sind es genau fünf Folien? Wie viele Emojis tauchen auf? Sie sind schnell, günstig und perfekt wiederholbar, aber spröde und blind fürs Feine: Sie können bestätigen, dass ein Deck existiert, nicht, dass es gut ist. Greif auf sie zurück, wann immer eine Antwort objektiv prüfbar ist; LLM-Judges neigen bei objektiven Aufgaben dazu, unnötig unzuverlässig zu sein.

Modell-Grader, der LLM-as-a-Judge, bewerten einen Output anhand einer Bewertungsvorlage: "bewerte die Lesbarkeit dieser Folie von 0 bis 5". Das ist der einzig praktikable Weg, weiche Qualitäten wie Kohärenz, Layout und Geschmack zu bewerten. Er bewältigt Ermessensfragen, an die kein Zählen herankommt, und läuft über Hunderte Fälle, ohne dass du zusiehst. Der Preis dafür: Er ist nicht deterministisch, kostet Geld und braucht sorgfältige Kalibrierung. Die Technik ist verlässlicher, als sie klingt: OpenAI berichtet, dass starke LLM-Judges über 80 % Übereinstimmung mit menschlichen Bewertern erreichen, etwa das Niveau, das Menschen untereinander erreichen. Zwei Kniffe heben die Decke weiter an: der paarweise Vergleich (frag, welcher von zwei Outputs besser ist, denn Modelle beurteilen relative Qualität besser als absolute Noten) und der Konsens mehrerer Judges (mehrere Judges stimmen ab, die Mehrheit gewinnt, was ein Stück Determinismus zurückbringt).

Menschliche Grader sind Fachexperten, die den Output direkt prüfen. Sie erkennen, was kein Modell und kein Zähler je erkennen wird, aber sie sind die langsamsten und teuersten, also setzt du sie am seltensten ein: für Stichproben, A/B-Vergleiche und, entscheidend, um deine Modell-Grader zu kalibrieren. Anthropics Rat lautet: Sobald ein System verlässlich ist, reicht gelegentliche menschliche Prüfung. Das ist auch der Punkt, an dem du aufhören kannst, den Agenten zu bemuttern und ihn laufen lässt.

Das Handwerk besteht darin, den Grader zur Frage passend zu wählen. "Wie viele Wörter stehen auf dieser Folie?" ist zählbar, also nimm einen Code-Grader. "Überlappt der Text oder läuft er über den Rand hinaus?" ist eine Ermessensfrage, also nimm einen Modell-Grader oder ein menschliches Auge.

Wie baust du Evals? Ein durchgespieltes Beispiel

Am klarsten lernst du das, wenn du es an einem echten Agenten beobachtest. Nimm einen einfachen: einen Agenten, dessen ganzer Auftrag lautet "du bist ein Agent, der Folien erstellt; wenn der Nutzer dir ein Thema gibt, erstelle eine PowerPoint-Datei; du hast eine Shell mit python-pptx". Hier ist die Schleife, Version für Version. (Die Werte unten stammen aus der Live-Demo einer öffentlichen Engineering-Session von Anthropic. Sie veranschaulichen die Methode, sie sind keine formalen Benchmarks.)

Version 1, die Ausgangsbasis. Lass sie laufen, und du bekommst technisch fünf Folien: überlappender Text, verstreute Emojis, auf jeder Folie dasselbe Türkis. Niemand würde das an einen Kunden schicken. Genau jetzt stellst du die Frage, die ein Eval-Set aufbaut: schauen wir uns an, was gescheitert ist, was sollten wir messen? Die Fehler schreiben die Liste: Code-Grader für Folienzahl, Emoji-Zahl, Formen pro Folie (ein Näherungswert für Überladung), winzige Schriften, textlastige Folien; Modell-Grader für Farbe, Bild, Layout und Textqualität, jeweils von 0 bis 5 bewertet. Lass sie laufen, und die erste Lektion sitzt sofort: Dieses wirklich schwache Deck bekam bei den Judges zwischen 2,8 und 4,0. Schau dir das Deck an, dann die Werte, und beides passt nicht zusammen. Die Grader sind nicht großzügig, weil der Agent gut ist; sie sind falsch kalibriert. Ein unkalibrierter Judge belügt dich höflich.

Version 2, bring ihm Geschmack bei. Ergänze im Prompt Regeln zu Typografie und Dichte: Schriftgrößen, genug Weißraum, linksbündiger Text, und ausdrücklich "vermeide die verräterischen KI-Muster": keine dekorativen Emojis. Die Decks werden sichtbar sauberer. Aber das Zeugnis meldet jetzt eine Emoji-Zahl von 20 auf einem Deck, auf dem keiner zu sehen ist, und eine "textlastig"-Markierung auf Folien, die ein Mensch in Ordnung fände. Der Agent wurde besser; die Eval hat ihre eigenen Bugs offengelegt. Also reparierst du den Grader und lässt den Agenten in Ruhe, und genau diesen Zug verpassen die meisten Teams.

Version 3, verlange Belege. Fordere ein echtes Diagramm auf jeder Folie. Die Decks bekommen Substanz, wo sie sich vorher durch Bulletpoints geschwafelt haben. Besser, aber der Bild-Judge liefert "3,8" und sonst nichts. Eine nackte Zahl, mit der du nichts anfangen kannst, und schuld daran ist, wie der Judge gefragt wurde (dazu unten mehr).

Version 4, lass ihn seine eigene Arbeit prüfen. Ergänze eine QA-Schleife, adversarial angewiesen: geh davon aus, dass es Probleme gibt; deine Aufgabe ist, sie zu finden; behandle QA als Bug-Jagd, nicht als Bestätigungsschritt; rendere das Deck zu Bildern, prüfe jede Folie, korrigiere, rendere neu, und hör nicht auf, bis du mindestens einen Zyklus aus Korrigieren und Prüfen abgeschlossen hast. Der Agent wird zu seinem eigenen Kritiker, und die Judges klettern auf 4,2 bis 4,4.

Version 5, tausch den Motor. Wirf den ausgeklügelten Prompt weg, kehr zum einfachen zurück und lass ihn auf einem stärkeren Modell laufen. Der Output ist der beste von allen fünfen: standardmäßig keine Emojis, lesbare Schriften, durchweg hohe Werte. Zwei Dinge lernst du hier. Manchmal liegt der richtige Hebel beim Modell, während der Prompt längst gut genug ist, und deine Evals sind genau das, was dir das sagt. Und wenn jeder Judge alles hoch bewertet, haben deine Evals aufgehört zu unterscheiden; sie sind gesättigt, und das ist das Zeichen, sie härter zu machen.

Welche Fehler lassen Evals lügen?

Evals zu bauen ist leicht. Evals zu bauen, denen du trauen kannst, verlangt die eigentliche Disziplin. Drei Fehlermuster machen den meisten Ärger aus.

Vage Bewertungsvorlagen. "Bewerte das von 0 bis 5" gibt einem Judge nichts, woran er sich festhalten kann, also landet er in einer höflichen Mitte. Genau deshalb bekam dieses erste schlechte Deck eine 3,5. Die Lösung: die Bewertungsvorlage mit Beispielen verankern, zeig dem Judge, wie eine 0 aussieht und wie eine 5. Diese Kalibrierung ist fummelig und langsam, und aus ihr kommt tatsächlich der größte Teil der Qualität eines Eval-Sets.

Die Reihenfolgen-Falle. Wenn du einen Judge erst nach einer Note und danach nach seiner Begründung fragst, bekommst du eine schlechtere Note. Sprachmodelle sind autoregressiv (jedes Token wird von den vorherigen geformt), also wird ein Judge, der sich zuerst auf eine "4" festlegt, seine Begründung damit verbringen, die 4 zu verteidigen, egal wie schlecht der Output ist. Dreh die Reihenfolge um: frag zuerst nach den Gründen, dann nach der Note. Anthropic und LangChain empfehlen beide, den Judge begründen zu lassen, bevor er bewertet, gerade weil die Zahl dann am Ende einer Überlegung steht und die Begründung nicht mehr hinterhergeschoben wird. Anthropic formuliert es so: "Bewerte nicht den Weg, den der Agent genommen hat, bewerte, was er produziert hat."

Sättigung. Evals sind ein lebendiges Artefakt. Du legst sie einmal an und schärfst sie danach immer wieder nach. Während der Agent besser wird, hören Grader, die einst Gut von Schlecht getrennt haben, auf zu unterscheiden, und alles besteht. Das ist Sättigung: Die Eval liefert dir keine Information mehr, mit der du arbeiten kannst, und es ist Zeit für eine härtere. Plane Budget fürs Auffrischen von Evals ein, so wie du Budget fürs Bauen einplanst. Bei Urteilen mit hohem Einsatz und ohne saubere richtige Antwort, etwa dem Zusammenfassen eines Rechtsfalls, kombinierst du den Konsens mehrerer Judges mit adversarialer Widerlegung (ein Agent bringt Probleme ans Licht, ein zweiter versucht, jedes zu widerlegen), denn auch Grader halluzinieren. Dieses Fehlermuster grabe ich unter selbstbewusst falsch genauer aus.

Wie viele Eval-Beispiele brauchst du?

Weniger, als die meisten Teams erwarten. Anthropics Rat lautet, dass 20 bis 50 Beispiele oft für den Anfang reichen, weil frühe Änderungen große Effekte haben und sich kleine Sets günstig neu laufen lassen. Fang mit einem Workflow an, der dir wichtig ist, mit einer ehrlichen Antwort auf "wie sieht gut aus?" und der kleinsten Eval, die das festhält: ein Code-Grader für das, was immer stimmen muss, und ein kalibrierter Judge für das, was am meisten zählt. Lass sie vor und nach deiner nächsten Änderung laufen. Diese eine Zahl, die sich in die richtige Richtung bewegt, ist die ganze Idee. Baue das Set nach und nach auf rund hundert Fälle aus, während der Workflow in den Produktivbetrieb geht.

Häufig gestellte Fragen

Was ist eine Eval bei KI?

Eine Eval ist ein systematischer Test, der misst, wie gut ein KI-System eine bestimmte Aufgabe löst. Sie verbindet eine Aufgabe (das Szenario) mit einem Grader (Logik, die den Output bewertet) und erzeugt eine Zahl, die du über die Zeit verfolgen kannst. Evals sind der übliche Weg, mit dem Teams subjektive Qualitätseindrücke in messbare, wiederholbare Signale verwandeln.

Was ist der Unterschied zwischen einem Code-Grader und einem LLM-as-a-Judge?

Ein Code-Grader nutzt deterministische Logik (String-Abgleiche, Zählungen, Regex) und ist schnell, günstig und perfekt wiederholbar, aber blind fürs Feine. Ein LLM-as-a-Judge nutzt ein Modell, um Output anhand einer Bewertungsvorlage zu bewerten, was der einzig praktikable Weg ist, subjektive Qualitäten wie Kohärenz und Layout zu bewerten, dafür ist er nicht deterministisch und braucht Kalibrierung. Nimm Code-Grader für objektiv prüfbare Dinge und Modell-Grader für Qualitätsurteile.

Sind LLM-as-a-Judge-Bewertungen verlässlich?

Sie können es sein, wenn sie kalibriert sind. OpenAI berichtet, dass starke LLM-Judges über 80 % Übereinstimmung mit menschlichen Bewertern erreichen, vergleichbar mit der Übereinstimmung zwischen zwei Menschen. Verlässlichkeit hängt davon ab, die Bewertungsvorlage mit Beispielen zu verankern, den Judge begründen zu lassen, bevor er bewertet, bekannte Verzerrungen wie Position und Wortmenge zu kontrollieren und regelmäßig gegen menschliches Urteil zu prüfen.

Wie viele Beispiele brauche ich, um einen KI-Agenten zu evaluieren?

Oft nur 20 bis 50. Anthropics Rat lautet, dass kleine Eval-Sets am Anfang reichen, weil Änderungen große Effekte haben und sich die Sets günstig neu laufen lassen. Fang klein mit den Fällen an, die am meisten zählen, und baue dann auf rund 100 aus, während der Agent in den Produktivbetrieb geht.

Warum reichen Benchmarks wie SWE-bench nicht?

Öffentliche Benchmarks messen allgemeine Fähigkeiten und helfen bei der Modellwahl, aber sie messen nicht deinen konkreten Anwendungsfall, deine Maßstäbe oder deine Definition von "fertig". Ein Modell kann ein Leaderboard anführen und trotzdem Output liefern, den deine Nutzer ablehnen. Du brauchst deine eigenen Evals, an deiner eigenen Arbeit gemessen.

Quellen und Weiterführendes

Anthropic: Demystifying evals for AI agents (Engineering-Leitfaden).
OpenAI: Evaluation best practices.
Gartner: Pressemitteilung, Juni 2025: über 40 % der Projekte mit agentenbasierter KI werden bis Ende 2027 eingestellt.
SWE-bench (Jimenez et al., Princeton, 2023): swebench.com.
Das durchgespielte Beispiel stammt aus einer öffentlichen Engineering-Session von Anthropic zu Evals (Agent zur Folienerstellung). Die zitierten Werte sind aus der Live-Demo dieser Session und veranschaulichen die Methode, sie sind keine formalen Benchmarks.

KI-Workflows im Mittelstand scheitern selten daran, dass das Modell nicht fähig genug war. Sie scheitern, weil nichts gemessen hat, ob der Workflow seine Aufgabe erfüllt, also driftete er still ab, bis jemandem etwas auffiel. Deshalb wird jeder KI-Mitarbeiter, den ich betreibe, mit seinem eigenen Eval-Set ausgeliefert: Code-Grader für das, was immer stimmen muss, kalibrierte Judges für Qualität und ein fester Rhythmus zum Auffrischen, damit die Evals nicht verstummen. Wir halten das System ehrlich, so wie wir unsere eigene Agentur damit betreiben. Eine ehrliche Grenze gibt es dabei. Wenn du nicht definieren kannst, wie "gut" aussieht, wenn du die Eval nicht schreiben kannst, dann ist dieser Anwendungsfall noch nicht bereit für den Livebetrieb, und das sage ich dir dann auch. Wenn du Hilfe dabei willst, diese Grenze für deine eigenen Workflows zu ziehen, lass uns ins Gespräch kommen.