Bis zu den vorigen Kapiteln haben wir Agenten entworfen, die Werkzeuge besitzen, Gedächtnis nutzen und sich zu mehreren aufteilen. Hier stoßen viele Entwickler an eine Wand: das Problem „Gebaut ist er ja, aber ob er wirklich richtig läuft, weiß ich nicht.“ Weil ein Agent probabilistisch handelt, läuft er selbst bei gleicher Anweisung nicht jedes Mal exakt gleich. Gerade deshalb werden „ein Mechanismus zum Messen (Evaluierung)“ und „ein Mechanismus zum Sichtbarmachen (Beobachtbarkeit)“ zur Lebensader des Praxiseinsatzes. In diesem Kapitel bauen wir das Fundament, um die Qualität in Zahlen zu fassen, Fehler zu reproduzieren und die Verbesserung fortlaufend zu drehen.
Das Ziel: „den Agenten nicht nach Gefühl, sondern mit gemessenen Zahlen verbessern“
Warum Evaluierung das Wichtigste ist
Ein normales Programm liefert bei gleicher Eingabe dasselbe Ergebnis. Doch im Zentrum eines Agenten steht ein LLM, und seine Ausgabe ist probabilistisch. Selbst bei gleicher Anweisung ändern sich das gewählte Werkzeug, die Schritte und die Formulierung jedes Mal ein wenig. Das heißt: Nur weil es einmal gut lief, gibt es keine Garantie, dass es beim nächsten Mal wieder gut geht.
Hier liegt ein Fallstrick, den es nur in der Agentenentwicklung gibt. In der Demo lief es glänzend, doch kaum bittet ein echter Nutzer etwas anders, bricht es zusammen – das ist nichts Seltenes. Die Ursache ist simpel: „lief = richtig“ stimmt nicht zwangsläufig. Vielleicht hat es nur zufällig die richtige Antwort erwischt und irrt sich in 3 von 10 Fällen. Um das zu wissen, bleibt nur, zu zählen.
💡 Was man nicht messen kann, kann man nicht verbessern. „Fühlt sich irgendwie besser an“ ist keine Verbesserung. Hat sich, nachdem Sie den Prompt geändert haben, die Erfolgsrate erhöht oder verringert? Ist es, nachdem Sie ein Werkzeug ergänzt haben, unnötig langsamer und teurer geworden? Erst wenn man in Zahlen vergleichen kann, lässt sich beurteilen, ob eine Änderung Fortschritt oder Rückschritt ist. Evaluierung ist keine „Hausaufgabe fürs Danach“, sondern das Fundament der Entwicklung.
Ebenso wichtig ist, die Evaluierung nicht aufzuschieben. Ein perfektes Evaluierungsfundament braucht es von Anfang an nicht. Geht man aber „erst bauen, und wenn es läuft, über Evaluierung nachdenken“ vor, wird die Evaluierung meist auf ewig nicht gebaut. Wenn auch klein, gleich nach dem ersten Agenten mit dem Messen zu beginnen, ist scheinbar ein Umweg und in Wahrheit die kürzeste Route. Das Gesamtbild der Evaluierung bietet der Praxisleitfaden zur KI-Agenten-Evaluierung, und was überhaupt gemeint ist, erklärt der Einstieg Was sind Agenten-Evaluierungen (Evals).
Was man evaluiert – Ergebnis und Verlauf
Hört man „evaluieren“, denken viele nur an, ob die endgültige Antwort stimmt. Das ist zwar der Ausgangspunkt, reicht bei Agenten aber nicht. Denn bei einem Agenten ist „was er unterwegs getan hat“ sehr wichtig. Selbst wenn er zur richtigen Antwort gelangt: Hat er zehnmal unnötig Werkzeuge aufgerufen und Zeit und Kosten verschwendet, ist er in der Praxis unbrauchbar. Umgekehrt gibt es Fälle, in denen die Antwort knapp danebenlag, das Urteil unterwegs aber richtig war.
Deshalb teilen wir den Gegenstand der Evaluierung in vier Aspekte. Hat man diese vier im Kopf, verschwindet die Ratlosigkeit „Ich weiß nicht, was ich messen soll“.
Wurde das übergebene Ziel erreicht? Ist die Antwort korrekt, erfüllt sie die Anforderungen? Der grundlegendste Indikator.
Welche Werkzeuge in welcher Reihenfolge, warum aufgerufen. Ist der Prozess sinnvoll? Gibt es Umwege oder unnötige Schritte?
Wurde das richtige Werkzeug mit den richtigen Argumenten aufgerufen? Wurde ein nicht existierendes Werkzeug aufgerufen oder ein Fehler ignoriert?
Die pro Ausführung verbrauchte Token-Menge, Gebühr und Dauer. Steht das im Verhältnis zur Qualität?
📊 Den „Verlauf“ zu messen ist das Herz der Agenten-Evaluierung. Während die Evaluierung normaler KI-Ausgabe ein „Antwortabgleich“ ist, betrachtet die Agenten-Evaluierung „die Antwort plus den Weg dorthin“. Ein Agent mit unsauberem Prozess bricht leicht zusammen, sobald sich die Bedingungen etwas ändern. Umgekehrt kann sich ein Agent mit stimmigem Prozess auch bei leichten Abweichungen wieder fangen. Gerade weil man den Prozess betrachtet, findet man Ansatzpunkte zur Verbesserung.
Die fünf Methoden der Evaluierung
„Wie also misst man?“ – hier liegt das Zentrum der Praxis. Es gibt mehrere Arten von Evaluierungsmethoden, und jede hat andere Stärken und Schwächen. Statt sich auf eine zu verlassen, ist es der Standard, sie je nach Messgegenstand zu kombinieren. Sehen wir uns fünf typische mit Vor- und Nachteilen an.
Eine vorab bereitgestellte „Musterlösung“ mit der Ausgabe des Agenten abgleichen und die Übereinstimmung messen. Passt zu Aufgaben mit einer eindeutigen Antwort wie Klassifikation, Extraktion und Berechnung.
Stärke: klar, gut automatisierbar, schwankungsfrei.
Schwäche: für freie Texte, bei denen „die Antwort nicht eindeutig ist“, schwer nutzbar.
Nach festen Bedingungen maschinell prüfen: „Ist das Pflichtwort enthalten?“, „Ist es korrektes JSON-Format?“, „Fehlen verbotene Wörter?“.
Stärke: schnell und günstig, stark bei Format- und Sicherheitsprüfungen.
Schwäche: vage Qualität wie „ob der Sinn stimmt“ lässt sich nicht messen.
Einem anderen LLM Benotungskriterien übergeben und die Ausgabe bewerten lassen. Misst Aufgaben ohne eindeutige Antwort wie die Qualität einer Zusammenfassung oder die Hilfsbereitschaft einer Antwort.
Stärke: freie Texte und subjektive Qualität in großer Menge automatisch bewerten.
Schwäche: der Benoter selbst schwankt/verzerrt. Verschriftlichte Kriterien und Stichprobenkontrolle von Hand nötig.
Typische Aufgaben in einem Testset bündeln und bei jeder Änderung gesammelt durchlaufen lassen. Ein Mechanismus, der „ob das, was bis gestern durchlief, mit der heutigen Änderung kaputtgeht“ absichert.
Stärke: Verschlechterung (Regression) durch Änderungen früh erkennen.
Schwäche: Aufbau und Pflege des Testsets kosten Aufwand.
Nach dem Release die Ausführungen echter Nutzer fortlaufend beobachten. Verlauf von Erfolgsrate, Kosten und Latenz sowie Nutzerbewertungen (👍/👎) sammeln und die reale Leistung verfolgen.
Stärke: Probleme, die nur real auftreten, und unerwartete Nutzungen entdecken.
Schwäche: nachträglich. Probleme zeigen sich erst „nachdem sie passiert sind“. Kombination mit Vorab-Evaluierung vorausgesetzt.
⚠️ Kombination ist Grundprinzip. Format und Sicherheit regelbasiert, Eindeutiges per Abgleich mit der Musterlösung, freie Texte per LLM-as-judge, bei jeder Änderung per Regressionstest, und nach dem Release per Produktions-Monitoring. Versuchen Sie nicht, mit einer Methode alles abzudecken. Siebt man den Großteil mit den günstigen, schnellen Methoden (①②) vor und setzt die teure Methode (③) nur dort ein, wo nötig, hält man die Kosten gering und die Genauigkeit hoch. Genaueres in Was ist LLM-Evaluierung.
Wie man Evaluierungsdaten (Testsets) erstellt
Egal welche Methode – das Fundament ist „der Stoff, an dem gemessen wird“ = die Evaluierungsdaten (das Testset). Das ist im Grunde eine Sammlung typischer Aufgaben nach dem Muster „bei dieser Eingabe soll dieses Ergebnis herauskommen“. Ist das dürftig, ist keine noch so prächtige Evaluierungsmethode verlässlich. Umgekehrt: Hat man ein gutes Testset, ist die Evaluierung schon zu 80 Prozent gelungen.
Die Erstellung ist simpel und geht in dieser Reihenfolge. Statt nach Perfektion zu streben, gilt die eiserne Regel, zunächst klein zu beginnen und wachsen zu lassen.
Anfragen, die dem Agenten tatsächlich gestellt werden könnten, sammeln – inklusive typischer, Grenz- und fehleranfälliger Fälle.
Das „So soll es sein“ jeder Aufgabe notieren. Das darf die Musterlösung, eine zu erfüllende Bedingung oder ein Benotungskriterium sein.
Am Anfang genügen 10 bis 20 Stück. Statt Menge die „Qualität“, die die reale Lage abbildet, priorisieren.
In der Produktion gefundene Fehlerbeispiele ins Testset aufnehmen. Es wird zum Vermögen, das mit dem Gebrauch klüger wird.
✅ Unterschätzen Sie „nur 10 Stück“ nicht. Vielleicht meinen Sie, „zu wenige Stichproben, das bringt nichts“. Doch sorgfältig gewählte 10 Stück sind weit nützlicher als achtlos gesammelte 1000. Zuerst 10 typische Fälle, in denen es real hakt, messbar machen. Allein damit können Sie an Ort und Stelle beurteilen, ob eine Prompt- oder Werkzeugänderung in die gute oder schlechte Richtung geht. Ein Testset ist nicht mit dem einmaligen Erstellen fertig, sondern ein lebendiges Vermögen, das mit jedem gefundenen Fehler um ein Stück wächst.
Beobachtbarkeit – das Verhalten sichtbar machen
Ist Evaluierung „gut oder schlecht messen“, so ist Beobachtbarkeit (Observability) „nachvollziehbar machen, warum es so wurde“. Selbst wenn die Evaluierung „die Erfolgsrate ist gesunken“ zeigt, gilt: Sieht man nicht, was darin passiert ist, lässt es sich nicht reparieren. Weil ein Agent intern mehrere Schritte dreht, wird er von außen leicht zur Blackbox: „Man gibt eine Eingabe hinein, irgendetwas geschieht, und ein Ergebnis kommt heraus.“ Diese zu öffnen und ins Innere blicken zu lassen, ist Beobachtbarkeit.
Die Beobachtbarkeit tragen im Wesentlichen drei Elemente.
Eine Ausführung von Anfang bis Ende durchgehend aufgezeichnet. Den ganzen Ablauf „Eingabe → Denken → Werkzeugaufruf → Ergebnis → nächste Entscheidung“ zeitlich lückenlos nachverfolgen.
In jedem einzelnen Schritt, welchen Prompt gesendet, mit welchen Argumenten das Werkzeug aufgerufen, was zurückkam. Auch Token-Verbrauch und Dauer hier festhalten.
Eine problematische Ausführung mit gleicher Eingabe und gleichem Zustand noch einmal nachvollziehen können. Erst mit Reproduzierbarkeit gelingen Ursachenbestimmung und Prüfung der Korrektur.
Man kann all das von Hand ins Log schreiben, doch in der Praxis nutzt man üblicherweise Tracing-Werkzeuge. Ein Tracing-Werkzeug fängt jeden Schritt des Agenten automatisch ein und visualisiert ihn übersichtlich als zeitlichen Baum. „In welchem Schritt es lange dauerte“, „wo ein Werkzeugaufruf scheiterte“, „bei welcher Entscheidung es in die falsche Richtung abbog“ – all das wird auf einen Blick ersichtlich.
📊 Der Trace ist das „Auge des Debuggings“. Im Beispiel oben scheitert bei ④ der Werkzeugaufruf, und bei ⑤ fängt der Agent sich selbst wieder. Sieht man nur das Ergebnis, ist es „Erfolg“, doch der Trace zeigt die Schwäche „verwechselt leicht die Spaltennummer“. Diese Erkenntnis führt zur nächsten Verbesserung. Die Denkweise der Beobachtbarkeit erklärt Was ist KI-Beobachtbarkeit (Observability) systematisch.
Die Verbesserungsschleife drehen
Die bisherige Ausrüstung – Evaluierung und Testset sowie Beobachtbarkeit – ist einzeln nützlich, entfaltet ihren wahren Wert aber erst, wenn man sie als eine Schleife dreht. Agentenentwicklung ist nicht „einmal bauen und fertig“, sondern eine Tätigkeit, die durch den Kreislauf messen, Schwäche finden, reparieren und wieder messen Stück für Stück besser wird.
Gegen das Testset die Evaluierung laufen lassen und Erfolgsrate, Kosten und Latenz in Zahlen ausgeben.
Den Trace der gescheiterten Ausführung lesen und feststellen, wo und warum es schiefging.
Prompt, Werkzeugbeschreibung, Ablauf oder Rollenteilung – den ursächlichen Teil um eine Sache ändern.
Mit demselben Testset erneut evaluieren und prüfen, ob die angepeilte Verbesserung eintrat und nichts anderes sich verschlechtert hat.
Für diese Schleife gibt es einen wichtigen Kniff: Ändern Sie auf einmal möglichst nur eine Sache. Ändert man Prompt, Werkzeug und Ablauf gleichzeitig, weiß man selbst bei gestiegener Erfolgsrate nicht mehr, „welche Änderung gewirkt hat“. Gerade weil man einzeln ändert und misst, verbindet sich die Ursache zwischen Änderung und Ergebnis, und Wissen sammelt sich an. Unscheinbar, aber das ist die Trennlinie zwischen „ungefährer Verbesserung“ und „sicherer Verbesserung“.
✅ Die Schleife schnell und klein drehen. Statt einmal eine große Überarbeitung durchzudrücken, wird es letztlich schneller besser, wenn man kleine Änderungen rasch und oft dreht. Hat man 10 Stück im Testset, kann man nach einer Änderung sofort messen. Ist dieser Rhythmus „ändern → sofort messen“ verinnerlicht, verwandelt sich Agentenentwicklung vom Gefühlsraten in eine ingenieurmäßige Arbeit, die verlässlich voranschreitet.
- Ein Agent ist probabilistisch, und „lief = richtig“ stimmt nicht zwangsläufig. Ohne Messen keine Verbesserung.
- Der Evaluierungsgegenstand hat vier Aspekte – Endergebnis, Verlauf unterwegs, Werkzeugaufrufe, Kosten und Latenz. Besonders der „Verlauf“ ist das Herz der Agenten-Evaluierung.
- Die Methoden sind fünf – Abgleich mit der Musterlösung, regelbasiert, LLM-as-judge, Regressionstests, Produktions-Monitoring – je nach Gegenstand kombiniert.
- Evaluierungsdaten mit wenigen typischen Aufgaben beginnen. Sorgfältige 10 schlagen achtlose 1000. Mit Fehlern wachsen lassen.
- Beobachtbarkeit sind Ausführungs-Trace, Log jedes Schritts, Reproduktion des Fehlers. Mit einem Tracing-Werkzeug das Verhalten sichtbar machen.
- Verbesserung ist die Schleife messen → Schwäche finden → reparieren → wieder messen. Änderungen einzeln, klein und schnell drehen.
Kann man Qualität messen und das Verhalten sichtbar machen, folgt als Nächstes: „wie man Amoklauf, Fehlbedienung und Missbrauch verhindert“. Lernen wir den Entwurf, um die im vorigen Kapitel 4 „Multi-Agenten-Design“ vermehrte Autonomie sicher zu handhaben. Weiter zu Kapitel 6 „Guardrails und Sicherheit“.