Inhalt
Nachdem du einen KI-Agenten gebaut hast, stößt du immer an dieselbe Wand: „Okay, aber funktioniert das wirklich?" Du hast den Prompt geändert, das Modell getauscht, ein Tool ergänzt — und der Mechanismus, mit dem du entscheidest, ob das die Sache besser oder schlechter gemacht hat, und zwar mit Daten statt mit Bauchgefühl, sind Evals (Evaluations).
Ein LLM kann für dieselbe Eingabe jedes Mal eine andere Ausgabe liefern (es ist probabilistisch). Deshalb führt „scheint zu laufen" als Freigabekriterium zu stillen Regressionen und Edge-Case-Fehlern in der Produktion. Dieser Artikel behandelt, was Evals sind, fünf Wege, Qualität zu messen, die agent-spezifische Bewertung und wie du klein anfängst — geschrieben für Praktiker.
Das Wichtigste in 30 Sekunden
Wenn du nur eine Sache liest
1. Warum du Evals brauchst
Gewöhnliche Software ist deterministisch: gleiche Eingabe, gleiche Ausgabe. Deshalb funktioniert ein Unit-Test, der prüft, „stimmt die Ausgabe mit dem erwarteten Wert überein". Ein LLM ist dagegen probabilistisch — selbst dieselbe Frage kommt jedes Mal etwas anders formuliert oder gerahmt zurück. Im Sinne von KI-Agenten vs. RPA ist es keine deterministische „Hand", sondern ein probabilistisches „Gehirn", weshalb Exact-Match-Tests so nicht funktionieren.
Drei Fehlerbilder tauchen hier typischerweise auf.
Du probierst ein paar Beispiele von Hand aus und entscheidest, es „fühlt sich besser an". Dass ein anderer Fall kaputtgegangen ist, bemerkst du nie.
Du änderst einen Prompt oder ein Modell, und nur eine Art von Eingabe wird schlechter. Du erfährst es aus einer Beschwerde in der Produktion.
„Manchmal kommt etwas Seltsames zurück." Weil es probabilistisch ist, reproduziert ein einzelner Versuch den Fehler nicht, sodass du die Ursache nicht nachverfolgen kannst.
Evals verhindern alle drei auf einmal. Bereite ein Bewertungsdatenset vor, bewerte bei jeder Änderung das gesamte Set und vergleiche die Scores — allein das verwandelt „Bauchgefühl" in „Daten" und macht Regressionen sichtbar. Je mehr Urteilsvermögen du an einen Agenten delegierst, desto mehr werden Evals zum Fundament der Qualität, direkt neben Guardrails.
2. Was Evals sind
Evals (Evaluations) = messen, ob die Ausgabe einer KI oder das Verhalten eines Agenten korrekt und stabil wie erwartet funktioniert. Menschlich gesprochen: benoten. Die Bausteine sind einfach und zerfallen in drei Teile.
Die Menge an Eingaben, auf der du bewertest. Sammle reale Nutzungsbeispiele, alte Logs und erwartete Edge Cases.
Wie du aus der Ausgabe einen Score machst: Exact Match, Regelprüfungen oder Benotung durch eine andere KI.
Bewerte das gesamte Set und vergleiche vorher vs. nachher einer Änderung, um über besser oder schlechter zu entscheiden.
Evals sind nicht „einmal bauen und fertig" — der Kern ist, sie als Regressionstest bei jeder Prompt-, Modell- oder Tool-Änderung laufen zu lassen. Wie Testcode sind sie ein Asset, das du wachsen lässt.
3. Fünf Wege, Qualität zu messen
Es gibt fünf repräsentative Bewertungsansätze. Die Faustregel lautet: nach der Natur der Aufgabe auswählen und mehrere kombinieren.
Bereite für jede Eingabe die erwartete Ausgabe (Gold-Label) vor und bewerte über die Trefferquote. Am besten für Aufgaben mit fester Antwort: Klassifikation, Extraktion, Ja/Nein.
Prüfe mechanisch Regex, Exact Match, JSON-Gültigkeit, Vorhandensein erforderlicher Schlüssel. Stark, um „muss immer dieses Format zurückgeben" zu verifizieren — schnell und günstig.
Lass ein anderes LLM anhand einer Rubrik benoten. Für Aufgaben, bei denen die Antwort nicht eindeutig ist: Qualität von Zusammenfassungen, Tonfall, Relevanz.
Vergleiche die Scores auf demselben Datenset vor und nach einer Prompt-/Modelländerung. Fängt eine „versteckte Regression" ab, bei der das Ganze steigt, aber ein Teil fällt.
Bewerte und beobachte fortlaufend Live-Logs. Behalte Fehlerrate, Kosten, Latenz und Input-Drift im Blick, um Verschlechterung früh zu erkennen.
| Methode | Passt zu | Kosten | Objektivität |
|---|---|---|---|
| ① Ground-Truth | Klassifikation, Extraktion, Entscheidungen | Niedrig | ◎ Hoch |
| ② Regelbasiert | Format-/Strukturprüfungen | Niedrig | ◎ Hoch |
| ③ LLM-as-judge | Zusammenfassung, Generierung, Dialogqualität | Mittel | ○ Rubrik-abhängig |
| ④ Regression | Regressionen aus Änderungen erkennen | Mittel | ◎ Relativ |
| ⑤ Produktionsmonitoring | Live-Verschlechterung erkennen | Mittel–Hoch | ○ Laufend |
Der Schlüssel ist die Schichtung: „miss mechanisch, was du kannst (① ②), nutze LLM-as-judge für Qualität, die du nicht messen kannst (③), und lass es durch Regression und Produktion weiterlaufen (④ ⑤)." LLM-as-judge (③) ist praktisch, aber das benotende LLM selbst schwankt, also schreibe die Rubrik explizit aus und kalibriere sie, wo möglich, gegen menschliche Bewertungen.
4. Agent-spezifische Bewertung
Für eine einzelne Antwort (eine Eingabe → eine Ausgabe) genügen die fünf oben. Doch ein KI-Agent durchläuft mehrere Schritte, ruft selbst Tools auf und trifft unterwegs Entscheidungen. Deshalb musst du nicht nur die finale Ausgabe, sondern den Prozess bewerten.
Hat er am Ende das Ziel erreicht (z. B. die richtige Reservierung gebucht)? Die primäre Agent-Metrik.
Hat er das richtige Tool mit den richtigen Argumenten in der richtigen Reihenfolge aufgerufen? Fängt falsche oder redundante Aufrufe ab.
Ist der Pfad aus Schritten und Entscheidungen sinnvoll? Bewerte Umwege, Endlosschleifen und unnötige Wiederholungen.
Bei gleichem Erfolg sind weniger Tokens, Schritte und geringere Latenz besser. Das zählt in der Produktion.
Diese zu beobachten erfordert Tracing, das jeden Schritt festhält (Eingabe, Denken, Tool-Aufruf, Ergebnis). Viele Frameworks und die Tools unten liefern Tracing und Bewertung zusammen. Bei einem Multi-Agenten-Setup behalte hierarchische Traces bei, damit du genau feststellen kannst, welcher Agent versagt hat.
5. Wie du anfängst — klein bauen
Du brauchst ab Tag eins keine perfekte Eval-Plattform. Mit einem Datenset aus 20 Einträgen zu starten ist realistisch.
- Sammle Fehlerbeispiele: zuerst 10–20 „Eingaben, die schiefgingen". Echte Logs und Beschwerden sind eine Goldgrube — das ist der Kern des Eval-Sets.
- Schreibe das erwartete Verhalten auf: hänge an jede Eingabe eine „richtige Antwort" oder „zu erfüllende Bedingungen". Nicht alles braucht eine strenge Antwort (miss Qualität mit ③).
- Wähle einen Scorer: Formatprüfungen → ② regelbasiert; feste Antwort → ① Ground-Truth; Qualität → ③ LLM-as-judge. Ein oder zwei zum Start reichen.
- Einmal laufen lassen und Baseline setzen: notiere den aktuellen Score. Das ist dein Referenzpunkt.
- Bei jeder Änderung laufen lassen: nach einer Prompt-/Modelländerung erneut laufen lassen und mit ④ Regression vergleichen. Fällt er, nicht ausliefern.
- Beobachtung in der Produktion ergänzen: sobald es live ist, überwache mit ⑤ Monitoring weiter Fehlerrate und Kosten und speise schlechte reale Beispiele zurück ins Eval-Set.
💡 Tipp: gewichte dein Eval-Set eher zu „Fehlern, die du nicht willst" als zu „häufigen Erfolgen". Edge Cases, adversariale Eingaben und vage Anfragen einzubeziehen lässt dich proaktiv gegen das absichern, was bei Änderungen kaputtgeht. Eine gute Rubrik wird, wie gutes Prompt-Design, umso reproduzierbarer, je konkreter sie ist.
6. Häufige Fallstricke
- Datenset zu klein / zu einseitig: nur Erfolge zu sammeln verfehlt reale Fehler. Mische bewusst Fehler und Edge Cases hinein.
- LLM-as-judge blind vertrauen: auch das benotende LLM schwankt und hat Verzerrungen. Schreibe die Rubrik explizit aus und kalibriere regelmäßig gegen menschliche Bewertungen. Hüte dich vor Selbstbedienung (dasselbe Modell schreibt und lobt seine eigene Ausgabe).
- Nur auf die finale Ausgabe schauen: für Agenten ist der Prozess alles. Ohne Tool-Aufrufe, Trajektorie und Kosten segnest du ein „aus Glück getroffenes" Ergebnis ab.
- Nach einem Durchlauf entscheiden: da es probabilistisch ist, bei wichtigen Evals mehrmals laufen lassen und die Varianz betrachten.
- Die Evals nicht aktualisieren: Specs und Nutzung ändern sich. Füge dem Eval-Set laufend neue Produktionsfehler hinzu.
7. Wichtige Tools
Du kannst mit eigenen Skripten anfangen, aber es gibt eine wachsende Auswahl an spezialisierten Tools, die Tracing und Bewertung zusammen abwickeln. Repräsentative Beispiele (alle offizielle Seiten).
| Tool | Was es macht |
|---|---|
| Anthropic Console / Evals | Prompts für Claude in einer UI testen und bewerten. Auch zum Vergleichen von Modellauswahlen. |
| OpenAI Evals | Ein OSS-Framework, um Evals zu definieren und auszuführen. Die grundlegende Form aus Datenset + Scorer. |
| LangSmith | Tracing + Bewertung. Zeichnet jeden Agent-Schritt auf, bis hin zu Regression und Produktionsmonitoring. |
| Langfuse | OSS-LLM-Observability. Tracing, Bewertung und Kostenmonitoring in einem. |
| Ragas | Auf RAG (Retrieval-Augmented Generation) spezialisierte Bewertung: Relevanz, Treue und mehr. |
Was du auch nutzt, der Kern bleibt gleich: ein Datenset + ein Scorer + die Disziplin des Vergleichens. Tools machen das nur einfacher. Der beste Start ist ein kleines Eval-Set, selbst in einem Skript auf deinem Rechner.
Zusammenfassung
- Was Evals sind: „Benoten", das KI-Ausgabe und -Verhalten in Zahlen misst — besser/schlechter mit Daten statt Bauchgefühl entscheiden.
- Warum du sie brauchst: LLMs sind probabilistisch und schwanken, sodass Unit-Tests nicht passen und Regressionen und Edge Cases durchrutschen.
- Fünf Methoden: ① Ground-Truth ② regelbasiert ③ LLM-as-judge ④ Regression ⑤ Produktionsmonitoring. Miss mechanisch, was du kannst, beurteile Qualität mit einem LLM und lass es weiterlaufen.
- Agenten brauchen auch Prozessbewertung: Aufgaben-Erfolgsrate, Tool-Aufrufe, Trajektorie, Kosten. Tracing ist die Voraussetzung.
- Wie du anfängst: 20 Fehlerbeispiele. Baseline setzen, dann bei jeder Änderung laufen lassen.
Zwischen „ich habe es gebaut" und „es ist brauchbar" liegt eine Brücke namens Evals. Wenn Guardrails die Verteidigung sind, die Ausreißer-Verhalten stoppt, sind Evals der Angriff, der Qualität misst und immer weiter steigert. Ein einziges kleines Eval-Set verwandelt die Agent-Entwicklung von „Bauchgefühl" in Ingenieurskunst.
FAQ
Q. Wie unterscheiden sich Evals von gewöhnlichen Unit-Tests?
Unit-Tests prüfen, „stimmt die Ausgabe exakt mit dem erwarteten Wert überein". Doch ein LLM ist probabilistisch und liefert jedes Mal eine andere Ausgabe, sodass Exact Match so nicht funktioniert. Evals unterscheiden sich dadurch, dass sie Messverfahren kombinieren, die zu probabilistischer Ausgabe passen — regelbasierte Prüfungen, Benotung durch ein LLM und das Beobachten der Varianz über mehrere Durchläufe — zusätzlich zum Ground-Truth-Abgleich.
Q. Kann ich LLM-as-judge (eine KI benoten lassen) vertrauen?
Es ist praktisch, aber kein Allheilmittel. Das benotende LLM kann schwanken und verzerrt sein. Entscheidend ist, eine konkrete Rubrik zu schreiben, regelmäßig gegen menschliche Bewertungen zu kalibrieren und die Rollen/Modelle für Generierung und Benotung zu trennen, um Selbstbedienung zu vermeiden. Der relative Vergleich (welches von A oder B ist besser) ist tendenziell stabiler als absolute Scores.
Q. Wie viele Eval-Einträge brauche ich?
Du kannst gut mit 10–20 starten. Schon wenige helfen beim relativen Vergleich, „ist der Score nach einer Änderung gestiegen oder gefallen". Realistisch lässt du es wachsen, indem du in der Produktion gefundene Fehler hinzufügst. Wichtiger als die Anzahl ist, Fehler, Ausnahmen und Edge Cases richtig einzubeziehen.
Q. Muss ich wirklich die „Trajektorie" eines Agenten bewerten?
Wenn du ihn in der Produktion betreibst, ja. Selbst wenn die finale Ausgabe korrekt ist, schaden Umwege, unnötige Tool-Aufrufe und Endlosschleifen den Kosten und der Zuverlässigkeit. Ergänze Tracing, das jeden Schritt aufzeichnet, und betrachte den Prozess neben der Aufgaben-Erfolgsrate. Je mehr der Anwendungsfall Berechtigungen und Nebenwirkungen umfasst — wie Anwendungsfälle der Geschäftsautomatisierung oder das Automatisieren von Cloud-Betrieb —, desto mehr zahlt sich Prozessbewertung aus.
