KI-Outputs evaluieren: Qualität messbar machen mit Evals

„Lief in der Demo doch gut” ist die teuerste Aussage in jedem KI-Projekt. Eine bestandene Demo sagt nichts darüber aus, wie sich das System bei den nächsten 10.000 echten Anfragen verhält — und genau dort entstehen die Fehler, die Geld, Vertrauen oder im rechtlich relevanten Fall die Haftung kosten.

Evals (AI Evaluations) sind strukturierte Tests, die die Qualität probabilistischer KI-Outputs messbar machen — über definierte Fehlermodi, Referenzdaten und Metriken statt über Bauchgefühl. Ein LLM zu evaluieren heißt nichts anderes, als diese KI-Evaluation systematisch und wiederholbar aufzusetzen. Sie liefern damit zweierlei in einem Artefakt: die Engineering-Kennzahl, an der Sie ein Feature freigeben, und den Beleg, den Werkvertrag, DSGVO und KI-Verordnung als Qualitätsnachweis verlangen.

Ich schreibe das aus beiden Perspektiven — als Entwickler, der solche Pipelines baut, und als Wirtschaftsjurist, der weiß, wann ein Messwert vor Gericht oder bei der Abnahme zählt. Dieser Artikel zeigt konkret, wie Sie die Messung aufbauen und warum sich derselbe technische Aufwand doppelt auszahlt.

Warum man KI-Qualität nicht mit Bauchgefühl beurteilen kann

Deterministisch vs. probabilistisch

Klassische Software ist deterministisch: gleicher Input, gleicher Output, gleicher Test. Ein generatives KI-Modell ist probabilistisch — derselbe Prompt kann beim zweiten Durchlauf eine andere, ebenfalls plausible Antwort liefern. Eine bestandene Demo beweist deshalb nichts über die nächsten 10.000 echten Anfragen.

Die drei Gründe, warum klassische Softwaretests scheitern

Kein binäres Richtig/Falsch. Qualität bei Texten ist ein Spektrum — eine Antwort kann korrekt, aber im Tonfall unpassend sein. Ein assertEquals greift hier nicht.
Unendlicher Input-Raum. Nutzer formulieren auf unzählige Weisen. Sie können nicht jeden Fall vorab durchtesten, sondern nur eine repräsentative Stichprobe.
Nicht reproduzierbare Fehler. Ein Fehlverhalten tritt sporadisch auf und lässt sich oft nicht zuverlässig wiederholen — Sie können es nicht einfach als roten Testlauf festhalten und „fixen”.

Der unterschätzte Punkt: ohne Messung kein Nachweis

Hier liegt der blinde Fleck vieler KI-Projekte. Wer Qualität nicht misst, kann sie auch nicht nachweisen. Und Nachweisbarkeit ist kein Nice-to-have, sondern in mehreren Rechtsrahmen eine Pflicht — dazu unten mehr. Eval-Werte sind damit zugleich Engineering-Kennzahl und Beweismittel.

Was Evals sind: die drei Bewertungsmethoden

Eine Eval kombiniert in der Praxis meist alle drei der folgenden Methoden. Keine ist für sich allein vollständig.

Methode	Funktionsweise	Stärke	Schwäche	Wann einsetzen
Menschliche Bewertung	Fachleute beurteilen Outputs nach Rubrik	Höchste Differenzierung (Ton, Empathie, Fachlogik)	Teuer, langsam, nicht skalierbar	Ground Truth, Kalibrierung, heikle Fälle
Regelbasierte Tests	Deterministische Checks (Format, verbotene Begriffe, Eskalation)	Schnell, eindeutig, billig	Enge Abdeckung, kein Qualitätsurteil	Harte Muss-Kriterien
LLM-as-a-Judge	Ein KI-Modell bewertet Outputs nach Vorgaben	Skalierbar, günstig, ~80–85 % Übereinstimmung mit Menschen	Bias/Kalibrierung nötig	Großvolumige, nuancierte Bewertung

Menschliche Bewertung (Human Review)

Menschen liefern die feinste Beurteilung — und die Referenz, an der sich alles andere kalibriert. Der Preis: hohe Kosten und mangelnde Skalierbarkeit. Wichtig ist das Inter-Annotator-Agreement: Stimmen zwei Prüfer nicht überein, ist nicht die KI das Problem, sondern Ihre Bewertungsrubrik ist unscharf.

Regelbasierte Tests

Manche Kriterien sind binär und deterministisch messbar: Wird bei einer Krisen-Anfrage zuverlässig an einen Menschen weitergeleitet? Bleibt das Ausgabeformat valides JSON? Solche Tests sind schnell und eindeutig, decken aber nur einen schmalen, klar definierbaren Ausschnitt ab.

LLM-as-a-Judge — kann man einer KI bei der Bewertung trauen?

Beim Ansatz „KI bewertet KI” beurteilt ein Modell die Outputs eines anderen anhand klarer Kriterien. Das skaliert günstig und erreicht nach aktuellen Messungen rund 80–85 % Übereinstimmung mit menschlichen Bewertern — vergleichbar damit, wie stark zwei Menschen übereinstimmen (Galileo, Confident AI).

Vertrauen ist aber nur mit Vorsicht angebracht. Dokumentierte Verzerrungen sind real: Self-Preference-Bias (Modelle bevorzugen ihre eigenen Ausgaben — der gemessene Effekt ist substanziell und je nach Modell und Setup zweistellig), Positions- und Verbosity-Bias (arXiv 2410.21819, Future AGI). Konsequenz: Den Judge gegen eine menschlich gelabelte Referenzmenge kalibrieren und seine Übereinstimmung selbst messen — sonst bewerten Sie die Bewertung nicht.

Das löst die scheinbare Henne-Ei-Frage — wenn der Judge ohnehin Menschen als Maßstab braucht, wozu dann der Judge — pragmatisch: Menschen labeln einmalig eine kleine Referenzmenge (die ~50–100 kritischen Fälle), gegen die der Judge geeicht wird; danach übernimmt er die laufende Bewertung der großen Volumina. Die teure menschliche Arbeit fällt also einmal zur Kalibrierung an, nicht pro Output — genau darin liegt der Skalierungsgewinn. Driftet die Übereinstimmung, eichen Sie mit einer frischen Stichprobe nach.

So baut man eine Eval auf: Failure Modes → Golden Dataset → Metriken → Continuous Evaluation

Eine belastbare Eval ist kein Ad-hoc-Skript, sondern eine Pipeline mit vier Stufen und einer Rückkopplungsschleife. Jeder produktive Fehler fließt zurück ins Golden Dataset — so wird die Messung mit der Zeit härter statt schwächer.

Vier-Stufen-Pipeline zum Aufbau einer KI-Eval von Failure Modes über Golden Dataset und Metriken bis zur Continuous Evaluation mit Rückkopplungsschleife

Die Eval-Pipeline als geschlossener Kreislauf: Fehlermodi definieren, Referenzfälle kuratieren, passende Metriken messen, im Betrieb überwachen — und jeden echten Fehler zurück in den Datensatz spielen.

Schritt 1 — Failure Modes definieren

Erst die Fehler verstehen, dann messen. Sammeln Sie die konkreten Arten, wie Ihr System falsch liegen kann: Halluzination (frei erfundene Fakten), falscher Tonfall, Compliance-Verstoß, Bias, Formatbruch, unzulässige Rechts-/Gesundheitsauskunft. Jeder Failure Mode wird später zu einem messbaren Kriterium. Praktischer Einstieg: Lassen Sie das System 50–100 reale Anfragen beantworten, lesen Sie die Outputs durch und clustern Sie die Fehler — diese induktive Fehleranalyse („open coding”) deckt mehr auf als jede vorab erdachte Checkliste.

Schritt 2 — Golden Dataset bauen

Ein Golden Dataset ist ein kuratierter Satz von Referenzbeispielen mit Soll-Antwort (Ground Truth): Frage + idealer Antwort + nötigem Kontext. Realistisch starten Sie mit 50–100 sorgfältig ausgewählten Fällen, die Ihre echten und Ihre kritischen Szenarien abdecken — Qualität schlägt Menge (Kinde). Dieses Set wächst mit jedem realen Fehler, der im Betrieb auftaucht.

Schritt 3 — Metriken wählen

Die richtige Metrik hängt vom Aufgabentyp ab. Für klassische Aufgaben sind etablierte Maße verfügbar; für RAG-Systeme (Antworten aus eigenen Dokumenten) liefert das RAGAS-Framework spezialisierte Metriken.

Metrik	Misst was	Aufgabentyp	Beispiel-Tool
F1 / Precision / Recall	Trefferqualität bei Klassifikation	Kategorisierung, Extraktion	scikit-learn
ROUGE / RougeL	Wortüberlappung mit Referenz	Zusammenfassung	Hugging Face
sacreBLEU	Übereinstimmung mit Referenzübersetzung	Übersetzung	sacreBLEU
BERTScore	Semantische Nähe (nicht nur Wortgleichheit)	Generierung allgemein	BERTScore
Faithfulness	Treue der Antwort zum gelieferten Kontext = Halluzinationsmaß	RAG	RAGAS
Answer Relevancy	Wie gut die Antwort die Frage trifft	RAG	RAGAS
Context Precision / Recall	Güte der abgerufenen Dokumente	RAG	RAGAS

Für RAG gilt die nützliche Trennung: Context Precision/Recall messen, wie gut das Retrieval die richtigen Dokumente holt; Faithfulness und Answer Relevancy messen, wie gut das Modell daraus die Antwort erzeugt (RAGAS-Doku, Confident AI). Wann ein RAG-Aufbau überhaupt der richtige Weg ist und wann Fine-Tuning, klärt der Vergleich RAG vs. Fine-Tuning für Unternehmen.

Wie messe ich, ob mein RAG-System halluziniert?

Über die Faithfulness-Metrik. Sie prüft, ob jede Aussage der Antwort durch den abgerufenen Kontext gedeckt ist. Ein niedriger Faithfulness-Wert bedeutet: Das Modell erfindet Inhalte, die nicht in Ihren Quellen stehen — das technische Maß für Halluzination im RAG-Kontext.

Schritt 4 — Offline-Eval vor Go-Live, dann Continuous Evaluation

Vor dem Live-Gang messen Sie offline gegen das Golden Dataset (Abnahmegate). Danach läuft Continuous Evaluation im Betrieb: Stichproben echter Anfragen, Monitoring gegen Drift (Qualität sinkt, wenn sich Daten, Nutzerverhalten oder das zugrunde liegende Modell ändern). Bei jedem Prompt- oder Modellwechsel fahren Sie die Eval als Regressionstest erneut. Qualität ist kein einmaliges Ereignis, sondern ein Zustand, den Sie laufend halten müssen.

Tools — sachlich eingeordnet, nicht beworben

Im Feld verbreitet sind unter anderem DeepEval, RAGAS, Langfuse und für regelbasierte Guardrails NeMo Guardrails. Welches passt, hängt von Stack, Aufgabe und Datenschutz-Anforderung ab — das ist keine bezahlte Empfehlung, sondern eine neutrale Orientierung. Entscheidend ist die Methodik, nicht die Wahl des Werkzeugs.

Evals als Compliance-Nachweis: was Recht und Regulierung verlangen

Hinweis: Dieser Abschnitt erklärt allgemeine Rechtsrahmen und ist keine Rechtsberatung im Einzelfall. Ob und welche Pflichten für Ihr konkretes System gelten, hängt vom Einzelfall ab.

KI-Verordnung — gemessene Genauigkeit und Robustheit

Für Hochrisiko-KI-Systeme verlangt die EU-KI-Verordnung in Art. 15 ein angemessenes Maß an Genauigkeit und Robustheit über den gesamten Lebenszyklus — inklusive der Pflicht, die relevanten Genauigkeitsmetriken in der Gebrauchsanweisung anzugeben. Art. 9 fordert ein Risikomanagementsystem, Art. 17 ein Qualitätsmanagementsystem (artificialintelligenceact.eu Art. 15, Art. 9). „Genauigkeitsmetriken angeben” heißt im Klartext: ohne Eval kein technischer Nachweis.

Stand März 2026 — Fristen im Fluss: Über das „Digital-Omnibus”-Paket wird derzeit verhandelt; es würde mehrere Hochrisiko-Fristen verschieben. Ohne diese Verschiebung greifen die Hochrisiko-Regeln zum 2. August 2026 (Gibson Dunn, White & Case). Das ist ein Schwebezustand — Termine bitte tagesaktuell prüfen lassen, nicht als vollendete Tatsache behandeln. Und ehrlich für den Mittelstand: Die meisten Anwendungen sind kein Hochrisiko, sondern fallen unter „begrenztes Risiko” mit reinen Transparenzpflichten (KI-Kennzeichnung). Keine Pflicht-Übertreibung — die Eval-Disziplin lohnt sich trotzdem, weil DSGVO-Richtigkeit und Werkvertrags-Abnahme (unten) unabhängig vom Risikograd greifen. Welche Pflichten aus KI-Verordnung und DSGVO konkret auf Unternehmen zukommen, ordnet der Überblick EU AI Act & DSGVO — was Unternehmen jetzt tun müssen ein.

DSGVO — der Grundsatz der Richtigkeit

Verarbeitet Ihre KI personenbezogene Daten, greift Art. 5 Abs. 1 lit. d DSGVO: Daten müssen sachlich richtig und auf dem neuesten Stand sein. Erzeugt ein Modell eine falsche Aussage über eine Person, ist das ein Richtigkeitsproblem mit Rechtsfolge. Messbare Genauigkeit — und das Logging, welche Antwort wann erzeugt wurde — ist der Beleg dafür, dass Sie diese Pflicht ernst nehmen.

Werkvertrag — Eval-Schwellen als Abnahmekriterien

Wer KI-Software bauen lässt oder einkauft, unterliegt Abnahme und Gewährleistung (§§ 633 ff. BGB). „Gefühlt gut” ist kein abnahmefähiges Kriterium. Definierte Eval-Schwellen (z. B. „Faithfulness ≥ 0,9 auf dem Golden Dataset, null kritische Failure Modes”) machen die Abnahme objektiv prüfbar — und schützen beide Seiten vor Streit.

Die Naht: Messung und Nachweis sind ein Artefakt

Genau hier verbindet sich Technik mit Recht. Dieselbe Pipeline, die F1 und Faithfulness misst, erzeugt mit Audit-Trail und Logging zugleich den prüffesten Nachweis für KI-VO, DSGVO-Richtigkeit und Werkvertrags-Abnahme. Wer KI selbst baut und die Nachweispflicht versteht, baut die Messung von Anfang an so, dass sie doppelt zählt. Wer erst messen lässt und dann eine menschliche Kontrollschicht für KI-Ausgaben ergänzt, schließt die Lücke vollständig: erst messen, dann absichern.

FAQ

Was sind Evals (AI Evaluations) und wozu braucht man sie?

Evals sind strukturierte Tests, die die Qualität von KI-Outputs messbar machen — über definierte Fehlermodi, Referenzdaten und Metriken. Man braucht sie, weil generative KI probabilistisch ist: Eine gelungene Demo beweist nicht, dass das System im echten Betrieb verlässlich liefert.

Wie kann ich Qualität messen, wenn es kein eindeutiges „richtig” gibt?

Indem Sie die Beurteilung in drei Bausteine zerlegen: zuerst die Fehlermodi definieren, dann ein Golden Dataset mit Soll-Antworten kuratieren, dann passende Metriken (z. B. Faithfulness für RAG) anlegen. So wird ein Qualitäts-Spektrum in vergleichbare, reproduzierbare Zahlen übersetzt.

Was ist ein Golden Dataset und wie groß muss es sein?

Ein Golden Dataset ist ein kuratierter Satz von Referenzbeispielen mit idealer Antwort und Kontext. Realistisch starten Sie mit 50–100 sorgfältig gewählten Fällen, die Ihre häufigen und Ihre kritischen Szenarien abdecken. Es wächst mit jedem im Betrieb gefundenen Fehler.

Kann man einer KI bei der Bewertung anderer KI trauen?

Bedingt. LLM-as-a-Judge erreicht rund 80–85 % Übereinstimmung mit menschlichen Bewertern, hat aber dokumentierte Verzerrungen (Self-Preference-, Positions-, Verbosity-Bias). Vertrauenswürdig wird er erst, wenn Sie ihn gegen eine menschlich gelabelte Referenz kalibrieren und seine Übereinstimmung selbst messen.

Muss ich die Qualität meiner KI rechtlich nachweisen?

Das hängt vom System ab. Bei Hochrisiko-KI fordert die KI-Verordnung gemessene Genauigkeit und Qualitätsmanagement (Art. 9/15/17); bei personenbezogenen Daten greift die DSGVO-Richtigkeitspflicht (Art. 5); bei beauftragter Software die Abnahme/Gewährleistung (§§ 633 ff. BGB). Ohne Eval-Pipeline fehlt der technische Nachweis. Dies ist keine Rechtsberatung im Einzelfall.

Stand: März 2026. Autor: Leon Lotz, Wirtschaftsjurist + Entwickler (MusketierSoftware).

Sie wollen ein KI-Feature live schalten und brauchen messbare statt gefühlte Qualität? Ich setze Ihre Eval-Pipeline so auf, dass die Ergebnisse zugleich als Abnahme- und Compliance-Nachweis taugen — technische Umsetzung und rechtliche Einordnung in einer Person. Erstgespräch anfragen.

Quellen — Stand 15.03.2026