Jeder, der eine LLM-Anwendung in Produktion gebracht hat, kennt das Bild: Die Demo läuft einwandfrei, die Stakeholder sind begeistert, die ersten Antworten wirken überzeugend. Dann kommt ein Kunde mit einer Frage, die Sie nie getestet haben, und das Modell antwortet mit der Selbstsicherheit eines Experten — und liegt schlicht falsch. Oder nach einem Prompt-Update stellen Sie fest, dass ein Edge-Case, der vorher funktioniert hat, es jetzt nicht mehr tut. Sie wissen nicht wann. Sie wissen nicht warum.
Das Problem liegt nicht im Modell. Das Problem liegt im fehlenden Messen. Dieser Artikel zeigt, wie man eine Eval-Infrastruktur aufbaut, die Ihnen — mit Zahlen, nicht mit Bauchgefühl — sagt, ob Ihre LLM-Anwendung besser oder schlechter ist als gestern.
Warum „sieht gut aus" keine Metrik ist
In klassischer Software haben Sie Unit-Tests, Integrationstests, eine CI-Pipeline. Vor jedem Merge wissen Sie, ob etwas aufgehört hat zu funktionieren. LLM-Ausgaben sind probabilistisch — derselbe Input kann leicht unterschiedliche Ausgaben liefern, und eine falsche Antwort wirft keine Exception. Das Versagen ist lautlos.
Teams ohne Eval-Prozess verlassen sich auf drei Personen, die gelegentlich durch die Anwendung klicken und „scheint OK" sagen. Das funktioniert bis zu den ersten 200 Nutzern. Dann wächst der Use-Case-Raum, Modelle ändern sich, Prompts werden angepasst — und niemand weiß, was gerade kaputtgegangen ist.
Eval (Evaluierung) ist die systematische Messung der Qualität von LLM-Ausgaben anhand definierter Kriterien. Nicht einmalig, sondern als kontinuierlicher Prozess: vor dem Deployment, nach jeder Prompt-Änderung, nach jedem Modell-Upgrade, regelmäßig in der Produktion.
Drei Eval-Typen — und wo jeder hingehört
Bevor wir zu den Tools kommen, ist es wichtig, drei verschiedene Kontexte zu unterscheiden, in denen Evals stattfinden:
Offline-Eval — Sie führen ihn vor dem Deployment auf einem festen Datensatz aus. Das Ergebnis kommt schnell und reproduzierbar. Geeignet für Regressionstests in CI/CD.
Online-Eval — läuft in der Produktion auf realen Anfragen, typischerweise auf einer Stichprobe. Er deckt Verteilungsverschiebungen auf: Echte Nutzer verhalten sich anders als Testszenarien.
Fine-tuning-Eval — ein Sonderfall, bei dem Sie messen, ob ein nachtrainiertes Modell bei Ziel-Aufgaben besser ist als das Basismodell. Ein eigener Artikel beschreibt diesen Fall (Wie man misst, ob Fine-tuning geholfen hat). Gehört hier nicht her.
RAG-Eval — misst Faithfulness (hat das Modell geantwortet, was es zur Verfügung hatte?), Answer Relevancy und Context Recall. Standard dafür ist das RAGAS-Framework, beschrieben im Artikel Wie man RAG evaluiert (RAGAS). Gehört ebenfalls nicht her.
Dieser Artikel konzentriert sich auf Offline- und Online-Eval für eine produktive LLM-Anwendung — Chatbot, Copilot, Agent.
Ein Eval-Set aus realen Fällen aufbauen
Der häufigste Fehler: Das Eval-Set erstellt ein KI-Ingenieur bei einem Wochenend-Brainstorming. Das Ergebnis deckt ab, was er für Edge-Cases hält — nicht das, was echte Nutzer tatsächlich fragen.
Die richtige Vorgehensweise:
- 1.Sammeln Sie echte Logs vom ersten Tag. Jede Anfrage und jede Antwort protokollieren (mit PII-Anonymisierung). Das ist Ihr Goldbestand.
- 2.Identifizieren Sie Fehler. Die ersten 200–500 realen Interaktionen manuell durchgehen. Wo hat das Modell schlecht geantwortet? Wo hat es die Antwort verweigert, obwohl es hätte antworten sollen? Wo war es unnötig vage?
- 3.Kategorisieren Sie Fehler nach Typ. Beispielkategorien: Faktenhaluzination, falsche Verweigerung, falsches Antwortformat, relevante aber unvollständige Antwort, Sicherheitsumgehung.
- 4.Wählen Sie aus jeder Kategorie repräsentative Fälle. Minimales Golden Set: 100–300 Beispiele mit korrekter Antwort oder Bewertungskriterium. Für ein Produktivsystem: 500–1 000+ Fälle.
- 5.Versehen Sie jedes Beispiel mit Ground Truth oder Rubric. Für einfache Fälle: Referenzantwort oder Expected Output. Für komplexe Fälle: Rubric (ein Kriteriensatz, den die Antwort erfüllen muss).
Das Golden Set ist nicht statisch. Fügen Sie jeden Monat neue Fehler aus der Produktion hinzu. Ein altes Set, das Sie nicht aktualisieren, spiegelt das reale Nutzerverhalten nicht mehr wider.
Metriken — präzise, wenn Sie eine Referenz haben
Für eindeutige Aufgaben (Extraktion, Klassifikation, strukturierter Output) funktionieren deterministische Metriken:
- Exact Match — die Ausgabe stimmt entweder mit der Referenz überein oder nicht. Geeignet für Entitätsextraktion, Klassenklassifikation, JSON-Schema.
- F1-Score — misst die Token-Überlappung zwischen Ausgabe und Referenz. Geeignet, wenn mehrere korrekte Formulierungen existieren.
- BLEU / ROUGE — Standard für Übersetzung und Zusammenfassung. In der Praxis selten für allgemeine LLM-Anwendungen genutzt, besser für spezifische NLP-Aufgaben.
Diese Metriken sind schnell, kostengünstig und deterministisch. Sie versagen aber für die meisten produktiven Use-Cases, bei denen eine „richtige Antwort" Dutzende Formulierungen haben kann.
LLM-as-judge — Stärke und Grenzen
Für offene Aufgaben — bei denen eine Referenzantwort nicht existiert oder zu variabel ist — kommt LLM-as-judge zum Einsatz: Ein anderes LLM (größer oder gleich stark) bewertet die Ausgabe anhand eines Rubrics.
Warum funktioniert das? Modelle der GPT-4-Klasse erzielen eine Übereinstimmung von etwa 85 % mit menschlichen Reviewern — das ist eine höhere Konsistenz als die typische Mensch-Mensch-Übereinstimmung (rund 81 %) bei denselben Aufgaben. Zu 500–5 000-mal niedrigeren Kosten als menschliche Annotation.
Aber LLM-as-judge hat fünf dokumentierte Biases, die Sie aktiv kompensieren müssen:
1. Position Bias — der Judge bevorzugt die Antwort, die in der Reihenfolge zuerst (oder zuletzt) steht. Lösung: Vergleichen Sie immer in umgekehrter Reihenfolge (A vs. B → dann B vs. A) und verwenden Sie Mehrheitsentscheid.
2. Verbosity Bias — eine längere Antwort wirkt überzeugender, auch wenn sie weniger präzise ist. Direkte Folge der Art, wie Modelle auf menschlichem Feedback trainiert wurden. Lösung: Rubric bestraft explizit unnötige Länge.
3. Self-preference Bias — das Modell bevorzugt eigene Ausgaben. Claude v1 zeigte bei der Selbstbewertung eine ca. 25 % höhere Win-Rate für eigene Antworten; GPT-4 rund 10 %. Lösung: Verwenden Sie niemals dasselbe Modell als Produzent und Judge.
4. Format Bias — Antworten mit Markdown, Bullet Points oder sauberer Struktur erhalten höhere Scores. Lösung: Der Rubric bewertet den Inhalt, nicht die Präsentation.
5. Calibration Drift — bei langen Batch-Evaluierungen wird der Judge entweder zu nachsichtig oder zu streng. Lösung: Fügen Sie dem Batch immer einige Kalibrierungsbeispiele mit bekanntem Score hinzu und beobachten Sie den Drift.
Empfohlene praktische Struktur für LLM-as-judge-Aufrufe:
- System-Prompt: Rolle des Judges, Liste der Bewertungsdimensionen, numerische Skala (z. B. 1–5 pro Dimension)
- User-Prompt: Frage-Kontext, zu bewertende Antwort, Rubric mit Definitionen jedes Scores
- Few-Shot-Beispiele: 3–5 gut bewertete und 3–5 schlecht bewertete Beispiele (steigern die Konsistenz von ca. 65 % auf ca. 77 %)
Übereinstimmung des Judges mit menschlichen Reviewern: Wenn Sie messen und 75 %+ erreichen, haben Sie ein nutzbares Signal. Unter 65 % produziert der Judge mehr Rauschen als Information — dann ist es Zeit, den Rubric neu zu schreiben.
G-Eval und DAG-Bewertung
Moderne Eval-Frameworks wie DeepEval implementieren Ansätze, die über ein simples „gib eine Bewertung von 1–5" hinausgehen:
G-Eval — der Judge generiert zunächst eine Bewertungsprozedur (Chain-of-Thought-Schritte) und bewertet dann danach. Reduziert die Willkürlichkeit der Bewertung.
DAG-Scoring — zerlegt die Bewertung in einen Bedingungsbaum. Statt „ist es gut?" durchläuft er: „ist es faktisch korrekt?" → wenn ja: „ist es vollständig?" → wenn ja: „ist es sicher?". Jeder Knoten kann eine andere Metrik oder ein LLM-as-judge-Aufruf sein.
Für Produktivsysteme empfehlen wir eine Kombination: deterministische Metriken für alles, was sich objektiv messen lässt, plus LLM-as-judge für Dimensionen wie Kohärenz, Ton und Vollständigkeit.
Regressionstests in CI vor jedem Release
Hier ist der praktische Workflow, den wir Kunden empfehlen:
- 1.Golden Set im Repository — der Eval-Datensatz ist Teil des Codes, versioniert in Git neben den Prompts.
- 2.Eval-CI-Schritt — vor jedem Merge in main wird die Eval-Pipeline ausgeführt. Sinkt der Gesamtscore um mehr als einen definierten Schwellenwert (z. B. 3 Prozentpunkte), wird der Merge blockiert.
- 3.Regressionsspezifische Tests — für jeden aus der Produktion identifizierten Fehler wird ein Test-Case hinzugefügt. Ein einmal erkannter Fehler darf nicht unbemerkt zurückkehren.
- 4.Separates Eval-Environment — die Eval-Pipeline ruft nicht dasselbe Modell/den gleichen Endpoint wie die Produktion auf. Isolierung verhindert, dass Evals die Produktionslogs beeinflussen.
- 5.Ergebnisse sichtbar — nicht nur Pass/Fail. Jeder PR enthält einen Eval-Diff: Welche Metriken haben sich verbessert, welche verschlechtert, um wie viel.
DeepEval ist der De-facto-Standard für CI/CD-Gating — integriert sich als pytest-Plugin, Export nach JUnit XML für CI, schwellenwertbasiertes Gating. Für Stakeholder-Dashboards und Production Traceability ergänzt ihn Braintrust.
Online-Eval — was Offline-Tests entgeht
Der Offline-Eval sagt Ihnen, ob Ihre Anwendung bei Beispielen funktioniert, die Sie kennen. Er sagt Ihnen nicht, ob echte Nutzer auf etwas Neues stoßen.
Online-Eval läuft typischerweise auf 5–10 % der Produktionsanfragen (Sampling wegen der Kosten). Sie suchen nach:
- Verteilungsverschiebung — Nutzer fragen Dinge, die nicht im Golden Set sind. Beobachten Sie Kategorien, in denen der Judge konsistent niedrig bewertet.
- Anomalien — Antworten, die unerwartet kurz oder lang sind, bei wiederholter Ausführung geringe Konsistenz zeigen oder Sicherheitsmuster enthalten.
- Latenz-Qualitäts-Kompromiss — ein schnelleres Modell kann in bestimmten Kategorien schlechter sein.
Online-Eval-Daten fließen regelmäßig zurück ins Golden Set. Der Zyklus: Produktion → Fehler → Golden Set → CI-Tests → Deployment.
Abgrenzung von Fine-tuning-Eval und RAG-Eval
Diese drei Eval-Typen werden häufig verwechselt:
Fine-tuning-Eval — misst, ob ein nachtrainiertes Modell das tut, wofür es trainiert wurde. Vergleicht Basismodell vs. fine-getunetes Modell auf einem aufgabenspezifischen Datensatz. Gehört nicht in die CI-Pipeline einer Produktionsanwendung — das ist ein einmaliges (oder per-Run-)Experiment vor der Modellregistrierung. Mehr im Artikel Wie man misst, ob Fine-tuning geholfen hat.
RAG-Eval (RAGAS) — misst die RAG-Pipeline: Faithfulness (zitiert das Modell nur, was es im Kontext hatte?), Answer Relevancy, Context Precision und Recall. Das Tool RAGAS liefert 8 spezifische Metriken. Das ist eine zusätzliche Schicht — Sie bewerten Retrieval und Generation getrennt. Mehr unter Wie man RAG evaluiert (RAGAS).
Produktiver LLM-Eval (dieser Artikel) — misst die End-to-End-Qualität aus Nutzersicht. Sie interessieren sich nicht dafür, ob das Modell ein Dokument korrekt zitiert hat; Sie interessieren sich dafür, ob die Antwort nützlich, sicher und im Einklang mit den Business-Kriterien war.
EU AI Act und Eval als rechtliche Pflicht
Ab dem 2. August 2026 gilt die vollständige Anwendbarkeit des EU AI Act. Für Unternehmen, die LLM-Systeme in Hochrisikokategorien einsetzen (Gesundheitswesen, kritische Infrastruktur, HR, Bildung), wird die Eval-Dokumentation zur rechtlichen Pflicht.
Konkret: Für Hochrisikosysteme verlangt der AI Act ein dokumentiertes und kontinuierliches Risikomanagement, einschließlich Testing und Validierung, Überwachung von Hallucination Rates, Bias-Mustern und Prompt-Injection-Risiko. Bußgelder für die schwerwiegendsten Verstöße betragen bis zu 35 Millionen Euro oder 7 % des weltweiten Jahresumsatzes.
Die praktische Konsequenz: Wenn Sie Evals ad hoc in einem Notion-Dokument durchführen, erfüllen Sie diese Anforderung nicht. Sie benötigen einen Audit-Trail — Prompt-Version, Modell-Version, Datum des Eval-Laufs, Ergebnisse, wer den Deployment genehmigt hat. Die genauen technischen Anforderungen an das Dokumentationsformat sind auf Ebene der Implementing Acts noch nicht standardisiert, aber die Richtung ist klar: ohne Traceability keine Compliance.
Häufige Fragen
Wie groß muss das Golden Set für den Anfang sein?
Für die erste Inbetriebnahme reichen 100–200 Beispiele aus echten Interaktionen. Wichtiger als die Größe ist die Repräsentativität — Abdeckung der wichtigsten Fehlerkategorien, nicht nur „typischer" Anfragen. Mit wachsendem Produktionsvolumen wächst das Golden Set organisch: Jeden Monat fügen Sie Dutzende neuer Fälle aus Fehlern hinzu.
Kann ich dasselbe Modell als Produzent und LLM-Judge verwenden?
Nein. Self-Preference Bias ist gut dokumentiert — Modelle bewerten ihre eigenen Ausgaben konsistent besser als Alternativen. Wenn Sie Ausgaben mit Claude produzieren, bewerten Sie sie mit einem GPT-4-Klasse-Modell und umgekehrt. Für den Open-Weight-Stack: Produktion auf Llama, Judge auf Qwen oder DeepSeek.
Was kostet LLM-as-judge in der Produktion?
Das hängt vom Modell und vom Volumen ab. Zur Orientierung: Bei 1 000 Anfragen täglich und einer Sampling-Rate von 10 % führen Sie 100 Judge-Aufrufe pro Tag durch. Mit einem Frontier-Modell (Input 2–5 USD, Output 12–25 USD pro Million Tokens) betragen die Kosten bei einem typisch kurzen Judge-Prompt in der Größenordnung von wenigen Dollar pro Tag. Weit weniger als die äquivalente menschliche Annotation.
Was tun, wenn der LLM-Judge inkonsistent ist?
Erster Schritt: Fügen Sie Few-Shot-Beispiele in den Judge-Prompt ein — 3–5 gut und 3–5 schlecht bewertete Fälle mit Erklärung. Die Konsistenz sollte steigen. Wenn nicht, liegt das Problem im Rubric: Die Kriterien sind zu vage oder überschneiden sich. Schreiben Sie sie als konkrete, messbare Bedingungen neu. Ziel: Übereinstimmung des Judges mit menschlichen Reviewern über 75 %.
Kann ich Evals vollständig ohne menschliche Kontrolle automatisieren?
Für die meisten Use-Cases ja — aber mit einer Ausnahme. Für High-Stakes-Systeme (Medizin, Recht, Finanzen) sollte mindestens monatlich eine manuelle Überprüfung einer Ausgaben-Stichprobe stattfinden. LLM-Judge hat blinde Flecken — vor allem bei subtilen Faktenfehlern in Fachbereichen, in denen ihm das Domänenwissen fehlt. Automatisierung reduziert den Arbeitsaufwand, ersetzt aber nicht die fachkundige Beurteilung für kritische Entscheidungen.
*Wenn Sie sich nicht sicher sind, wo Ihre LLM-Anwendung tatsächlich versagt — und die meisten Teams sind sich dessen nicht sicher — ist der erste Schritt einfach: Schauen Sie in die Logs und finden Sie die fünf schlechtesten Antworten des letzten Monats. Damit beginnt jedes gute Eval-Programm. Wir helfen Ihnen gerne, den gesamten Prozess aufzusetzen — vom Golden Set über CI-Gating bis hin zum Produktionsmonitoring.*