Begriff
Agent Evaluation (Evals)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Wenn du klassische Software programmierst, schreibst du Tests: "Ist 2 + 2 = 4?". Die Antwort ist immer eindeutig Ja oder Nein. Bei KI-Agenten ist das anders. Du fragst: "Schreibe eine E-Mail an den Kunden." Der Agent schreibt heute "Hallo", morgen "Moin", übermorgen "Sehr geehrte Damen und Herren". Alles ist "richtig", aber ist es auch gut? Agent Evaluation (Evals) ist der Prozess, die Qualität von KI-Antworten messbar zu machen. Statt "Gefühl" ("Die KI wirkt heute dümmer") nutzt man harte Daten und Scores. Ohne Evals ist jeder Prompt-Change ein Blindflug.
Merksatz: Systematische Methoden und Metriken zur quantitativen und qualitativen Bewertung von KI-Agenten, oft unter Einsatz von "LLM-as-a-Judge", um Korrektheit, Relevanz und Sicherheit sicherzustellen.
Du brauchst drei Dinge:
- Dataset: Eine Liste von 50 Fragen und (optional) den idealen Antworten ("Ground Truth").
- Metriken: Was willst du messen?
Faithfulness: Halluziniert der Agent oder bleibt er bei den Fakten?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du brauchst drei Dinge: 1. Dataset: Eine Liste von 50 Fragen und (optional) den idealen Antworten ("Ground Truth"). 2. Metriken: Was willst du messen? Faithfulness: Halluziniert der Agent oder bleibt er bei den Fakten? Answer Relevance: Beantwortet er die Frage oder labert er herum? Tone: Ist er höflich? 3. Tooling: Frameworks wie Ragas, DeepEval oder LangSmith. Du lässt den Test laufen, das Framework vergleicht die Agenten-Antworten mit den Kriterien und gibt dir einen Score: "82/100".Answer Relevance: Beantwortet er die Frage oder labert er herum?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du brauchst drei Dinge: 1. Dataset: Eine Liste von 50 Fragen und (optional) den idealen Antworten ("Ground Truth"). 2. Metriken: Was willst du messen? Faithfulness: Halluziniert der Agent oder bleibt er bei den Fakten? Answer Relevance: Beantwortet er die Frage oder labert er herum? Tone: Ist er höflich? 3. Tooling: Frameworks wie Ragas, DeepEval oder LangSmith. Du lässt den Test laufen, das Framework vergleicht die Agenten-Antworten mit den Kriterien und gibt dir einen Score: "82/100".Tone: Ist er höflich?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du brauchst drei Dinge: 1. Dataset: Eine Liste von 50 Fragen und (optional) den idealen Antworten ("Ground Truth"). 2. Metriken: Was willst du messen? Faithfulness: Halluziniert der Agent oder bleibt er bei den Fakten? Answer Relevance: Beantwortet er die Frage oder labert er herum? Tone: Ist er höflich? 3. Tooling: Frameworks wie Ragas, DeepEval oder LangSmith. Du lässt den Test laufen, das Framework vergleicht die Agenten-Antworten mit den Kriterien und gibt dir einen Score: "82/100".
- Tooling: Frameworks wie Ragas, DeepEval oder LangSmith. Du lässt den Test laufen, das Framework vergleicht die Agenten-Antworten mit den Kriterien und gibt dir einen Score: "82/100".
1. LLM-as-a-Judge
Klassische Metriken aus dem NLP (wie BLEU oder ROUGE) prüfen nur Wort-Überlappung. Das versagt bei Chatbots. Die moderne Lösung: LLM-as-a-Judge. Du nimmst ein sehr starkes Modell (GPT-4) und gibst ihm einen Bewertungs-Prompt:
"Du bist ein strenger Lehrer. Bewerte die folgende Antwort des Schülers auf einer Skala von 1-5 basierend auf diesen Kriterien: Faktentreue, Kürze, Stil. Gib Output als JSON."
Studien zeigen, dass GPT-4 als Richter eine sehr hohe Korrelation (0.8+) mit menschlichen Experten hat. Das ermöglicht automatisierte CI/CD-Pipelines für Prompts.
2. RAG Triad (Ragas Framework)
Speziell für RAG-Systeme misst man das Dreieck:
- Context Precision: Hat das Retrieval die richtigen Dokumente gefunden? (Vergleich: Retrieve vs Ground Truth Chunks).
Context Recall: Hat das Retrieval alle nötigen Infos gefunden?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du brauchst drei Dinge: 1. Dataset: Eine Liste von 50 Fragen und (optional) den idealen Antworten ("Ground Truth"). 2. Metriken: Was willst du messen? Faithfulness: Halluziniert der Agent oder bleibt er bei den Fakten? Answer Relevance: Beantwortet er die Frage oder labert er herum? Tone: Ist er höflich? 3. Tooling: Frameworks wie Ragas, DeepEval oder LangSmith. Du lässt den Test laufen, das Framework vergleicht die Agenten-Antworten mit den Kriterien und gibt dir einen Score: "82/100".Faithfulness: Hat die Generation (Answer) sich nur auf den Context gestützt?
Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du brauchst drei Dinge: 1. Dataset: Eine Liste von 50 Fragen und (optional) den idealen Antworten ("Ground Truth"). 2. Metriken: Was willst du messen? Faithfulness: Halluziniert der Agent oder bleibt er bei den Fakten? Answer Relevance: Beantwortet er die Frage oder labert er herum? Tone: Ist er höflich? 3. Tooling: Frameworks wie Ragas, DeepEval oder LangSmith. Du lässt den Test laufen, das Framework vergleicht die Agenten-Antworten mit den Kriterien und gibt dir einen Score: "82/100".
3. Pairwise Comparison (A/B Testing)
Oft ist eine absolute Note (4/5) schwer. Einfacher ist der Vergleich: Modell A antwortet. Modell B antwortet. Richter: "Welche Antwort ist besser? A, B oder Tie?" Daraus berechnet man ein ELO-Rating (wie im Schach) für seine Agenten-Versionen.
1. Das Problem der "Contamination" (Data Leakage)
In der Forschung ist Contamination die größte Gefahr. Wenn du deinen Agenten mit einem Standard-Benchmark (wie MMLU oder HumanEval) testen willst, ist die Chance groß, dass diese Testdaten bereits im Trainingsmaterial des Modells enthalten waren. Ergebnis: Der Agent liefert perfekte Antworten, aber nicht weil er intelligent ist, sondern weil er die Lösung "auswendig" gelernt hat. Production-Evals müssen daher immer dynamisch sein. Man nutzt "Private Evals", also handgeschriebene Datensätze, die niemals im Internet veröffentlicht werden, um sicherzustellen, dass man die Reasoning-Fähigkeit testet und nicht das Gedächtnis.
2. Multi-Step & Trajectory Evaluation
Bei Agenten reicht es nicht, nur die finale Antwort zu prüfen. Ein Agent macht 5 Schritte: Werkzeug suchen -> API aufrufen -> Ergebnis parsen -> Nachdenken -> Antwort. Man evaluiert die Trajectory (den Pfad). Ein Tool wie LangSmith visualisiert diesen Graph. Ein Judge bewertet dann: "War Schritt 2 logisch? Wurde das Tool effizient genutzt?". Häufiger Production-Fehler: Der Agent liefert die richtige Antwort, hat aber 3-mal das falsche Tool aufgerufen und damit unnötig Kosten und Latenz verursacht. Ein "Trajectory-Score" bestraft solche Ineffizienz.
3. Bootstrap & Synthetic Data Evals
Wie baut man Evals, wenn man keine Experten hat, die hunderte Antworten labeln? Man nutzt Synthetic Data Generation. Ein starkes LLM nimmt einen Haufen Rohdaten (Dokumente) und generiert daraus automatisch Frage-Antwort-Paare. Danach fungiert das gleiche (oder ein stärkeres) Modell als Richter. Dieses "KI testet KI" Prinzip erlaubt es, innerhalb von Stunden tausende Testfälle aufzubauen. Kritisch ist hierbei der Bias: Ein GPT-4 Judge neigt dazu, Antworten, die wie GPT-4 klingen (lang, höflich, korrekt formatiert), besser zu bewerten, selbst wenn sie faktisch falsch sind (Self-Preference Bias).
Quick-Check
Warum brauche ich "Ground Truth"?
Um zu wissen, was richtig ist. Ohne ideale Antwort kann der Richter nur Stil und Plausibilität prüfen, aber nicht die Fakten. Ground Truths sind teuer zu erstellen (Expertenzeit), aber unverzichtbar ("Golden Dataset").Testet man im Training oder in Production?
Beides. "Offline Evals" passieren vor dem Deployment (Datensatz). "Online Evals" passieren live (User Thumbs Up/Down oder implizites Feedback wie "User fragt nochmal nach -> schlecht").Kostet das nicht doppelt?
Mindestens. Wenn du für jeden Agenten-Call nochmal einen Judge-Call machst, verdoppelst du Kosten und Latenz. Deshalb macht man Evals meistens im Testing ("Offline") oder nur stichprobenartig ("Sampled Online Evals").