KI-Evaluierung

Warum KI einen anderen Testansatz braucht¶

Klassische Software ist deterministisch. Eingabe A → Ausgabe B. Jedes Mal. Der Test ist einfach: assert output == expected.

LLM-Anwendungen sind grundlegend anders. Gleicher Prompt, gleiches Modell, gleiche Temperatur — und Sie bekommen drei verschiedene Antworten. Alle koennen richtig sein. Oder alle falsch. Oder zwei gut und eine halluziniert.

Sie aendern den System-Prompt um zwei Woerter? Die Ausgabe aendert sich unvorhersehbar. Upgrade auf eine neue Modellversion? Manche Antworten verbessern sich, andere verschlechtern sich. Sie fuegen ein Dokument zur RAG-Pipeline hinzu? Retrieval aendert sich, Antworten auch.

Ohne systematische Evaluierung fliegen Sie blind. Sie wissen nicht, ob die letzte Aenderung geholfen oder geschadet hat. Sie wissen nicht, wo das Modell versagt. Sie wissen nicht, ob es sicher ist, eine neue Version zu deployen. Evaluierung ist fuer KI-Anwendungen das, was Tests fuer klassische Software sind — eine Notwendigkeit, kein Nice-to-have.

Golden Datasets¶

Ein Golden Dataset ist Ihre Ground Truth — eine kuratierte Sammlung von Beispielen, gegen die Sie die Qualitaet der KI-Ausgaben messen.

Struktur¶

Jeder Datensatz im Golden Dataset enthaelt:

• Input — Benutzeranfrage, Kontext, Dokumente (fuer RAG)
• Erwartete Ausgabe — Referenzantwort (ideal oder akzeptabel)
• Metadaten — Kategorie, Schwierigkeitsgrad, Edge-Case-Flags
• Bewertungskriterien — was genau wir bewerten (Genauigkeit, Vollstaendigkeit, Ton, Format)

Wie wir Golden Datasets erstellen¶

Von Menschen gelabelte Beispiele: Domaenenexperten erstellen und bewerten Input/Output-Paare. Am teuersten, aber hoechste Qualitaet. Typischerweise 100-200 handgefertigte Beispiele bilden den Kern des Datasets.

Produktionsdaten: Echte Benutzeranfragen mit von Menschen ueberprueften Antworten. Feedback-Schleife — Benutzer melden schlechte Antworten, die als Negativbeispiele hinzugefuegt werden. Authentischste Quelle, da sie reale Use Cases widerspiegelt.

Synthetische Daten: LLM generiert Variationen bestehender Beispiele — Paraphrasen, Edge Cases, Adversarial Inputs. Wir erweitern die Abdeckung ohne linearen Anstieg menschlicher Arbeit. Aber immer mit menschlicher Pruefung — synthetische Daten ohne Kontrolle fuehren Bias ein.

Adversarial-Beispiele: Absichtlich verfaengliche Eingaben zum Aufdecken von Schwachstellen. Prompt-Injection-Versuche, mehrdeutige Anfragen, Out-of-Scope-Themen, kulturell sensible Inhalte. Testen Robustheit, nicht nur den Happy Path.

Pflege¶

Ein Golden Dataset ist nicht statisch. Sie fuegen neue Beispiele aus der Produktion hinzu, entfernen veraltete, aktualisieren erwartete Ausgaben bei Aenderung der Geschaeftslogik. Versioniert in Git wie Code — jede Aenderung ist nachverfolgbar, ueberpruefbar, rueckgaengig machbar.

LLM-as-Judge¶

Menschliche Bewertung ist der Goldstandard, skaliert aber nicht. Sie koennen kein Team von Bewertern bezahlen, das 500 Antworten bei jedem PR liest. LLM-as-Judge automatisiert die Bewertung mit >85% Korrelation mit menschlichem Urteil.

Wie es funktioniert¶

Das Judge-Modell (typischerweise GPT-4o oder Claude Opus) erhaelt:

1. Rubrik — praezise Bewertungskriterien (1-5-Skala fuer Relevanz, Genauigkeit, Vollstaendigkeit)
2. Input — Urspruengliche Benutzeranfrage
3. Referenz — Erwartete Antwort aus dem Golden Dataset
4. Kandidat — Tatsaechliche Antwort des zu bewertenden Modells

Der Judge gibt eine strukturierte Bewertung zurueck: Score fuer jedes Kriterium, Begruendung, identifizierte Probleme. Alles maschinell parsbar.

Bewertungsdimensionen¶

Faithfulness — Entspricht die Antwort den Fakten aus dem bereitgestellten Kontext? Halluziniert das Modell Informationen, die nicht in den Dokumenten stehen? Kritisch fuer RAG-Anwendungen.

Relevanz — Beantwortet die Antwort, was der Benutzer gefragt hat? Nicht off-topic, nicht zu allgemein, deckt die Schluesselpunkte der Anfrage ab.

Vollstaendigkeit — Enthaelt die Antwort alle wichtigen Informationen? Fehlt ein Schluesseldetail? Deckt sie Edge Cases ab, die in der Anfrage erwaehnt werden?

Unbedenklichkeit — Enthaelt die Antwort toxischen, voreingenommenen oder gefaehrlichen Inhalt? Respektiert sie Richtlinien und Content Policy?

Format-Compliance — Folgt die Antwort dem geforderten Format? JSON-Schema, Markdown-Struktur, Laenge, Sprache.

Kalibrierung des Judge-Modells¶

LLM-as-Judge ist nicht fehlerfrei. Wir kalibrieren gegen menschliche Bewertung:

1. Menschen bewerten 50-100 Beispiele
2. Judge bewertet dieselben Beispiele
3. Wir messen Korrelation (Cohens Kappa, Spearman)
4. Wir iterieren die Rubrik bis Korrelation > 0,85

Periodische Rekalibrierung — Modelle aendern sich, Datenverteilung aendert sich, Geschaeftsanforderungen aendern sich.

Automatisierte Eval-Pipelines¶

Evaluierungen muessen automatisch laufen. Manuelle Eval „wenn wir daran denken” liefert kein systematisches Feedback.

CI/CD-Integration¶

Die Eval-Pipeline laeuft bei:

• PR mit Prompt-Aenderung — Vergleich neue Version vs. Baseline
• Modell-Upgrade — Neue Version von GPT/Claude/Llama vs. aktuelle
• RAG-Pipeline-Aenderung — Neues Chunking, Embeddings, Retrieval-Strategie
• Geplant — Taegliche/woechentliche Eval auf Produktionsdaten fuer Drift-Erkennung

Pipeline-Architektur¶

Golden Dataset → Inference (model under test) → Judge (LLM-as-judge + heuristic checks) → Metrics → Dashboard → Alert

Inference-Stufe: Wir fuehren das zu testende Modell auf dem gesamten Golden Dataset aus. Wir erfassen Antworten, Latenz, Token-Anzahl, Kosten.

Evaluierungsstufe: Jede Antwort durchlaeuft eine Reihe von Checks: - LLM-as-Judge fuer subjektive Qualitaet (Relevanz, Faithfulness) - Heuristische Checks fuer objektive Metriken (Format, Laenge, verbotene Woerter) - Embedding-Aehnlichkeit fuer semantisches Matching mit der Referenzantwort - Regex/Schema-Validierung fuer strukturierte Ausgaben

Reporting: Ergebnisse aggregiert in einem Dashboard. Trending ueber die Zeit — verbessern wir uns oder degradieren? Aufschluesselung nach Kategorie — wo sind wir stark, wo schwach? Vergleichsansicht — neue Version vs. alte, Seite an Seite.

Metriken¶

Pass Rate — Prozentsatz der Antworten, die alle Kriterien erfuellen. Haupt-KPI.

Score-Verteilung — Histogramm der Scores ueber alle Dimensionen. Verschiebung der Verteilung nach links = Regression.

Kategorie-Aufschluesselung — Pass Rate pro Kategorie (FAQ, technische Anfragen, Edge Cases). Zeigt, wo spezifisch das Modell versagt.

Latenz und Kosten — Nicht nur Qualitaet, sondern auch Effizienz. Neuer Prompt ist besser, aber 3x teurer? Lohnt es sich?

Regressions-Alerts — Automatischer Alert wenn Pass Rate um >5% gegenueber Baseline sinkt. PR wird nicht gemergt.

RAG-Pipeline-Evaluierung¶

RAG-Anwendungen haben spezifische Evaluierungsbeduerfnisse — wir bewerten nicht nur die Generierung, sondern auch das Retrieval.

Retrieval-Metriken¶

Precision@k — Wie viele der Top-k abgerufenen Dokumente sind relevant? Hohe Precision = wenig Rauschen.

Recall — Wie viele relevante Dokumente haben wir von der Gesamtzahl gefunden? Hoher Recall = nichts Wichtiges fehlt.

MRR (Mean Reciprocal Rank) — Wie weit oben steht das erste relevante Dokument? Der Benutzer braucht die Antwort aus dem ersten Chunk, nicht dem zehnten.

End-to-End RAG-Evaluierung¶

Retrieval und Generierung getrennt zu bewerten reicht nicht. E2E-Evaluierung: Anfrage → Retrieval → Generierung → Bewertung der finalen Antwort. Denn gutes Retrieval + schlechte Generierung = schlechte Antwort. Und umgekehrt — das Modell kann schwaches Retrieval mit eigenem Wissen kompensieren (sollte es aber nicht).

Tools und Frameworks¶

Eval-Frameworks: Ragas, DeepEval, Promptfoo, LangSmith, Braintrust.

LLM-as-Judge: GPT-4o, Claude Opus, Gemini Pro — ausgewaehlt nach Kosten/Qualitaets-Tradeoff.

Dataset-Management: Git (Versionierung), DVC (grosse Dateien), Custom Tooling.

Dashboards: Grafana, Streamlit, Custom Web UI.

CI/CD: GitHub Actions, GitLab CI — Eval als Pflichtstep in der Pipeline.

Verwandt mit