Qualitätssicherung: Evals, Test-Sets, Benchmarks

Lernziele

Sie erklären den Unterschied zwischen automatischen Evals, modellbasierten Evals (LLM-as-Judge) und Human Evals und benennen Einsatzfelder für jeden Typ.

Sie erstellen ein einfaches Golden Test-Set für einen realen Use-Case mit mindestens 5 Testfällen.

Sie erklären den Begriff Regression und beschreiben, wie regelmäßige Golden-Test-Set-Läufe Qualitätsverschlechterungen aufdecken.

Sie ordnen relevante öffentliche Benchmarks (MMLU, HumanEval, Chatbot Arena) den richtigen Anwendungsfällen zu.

Sie unterscheiden die Aussagekraft öffentlicher Benchmarks von der eines internen Golden Test-Sets.

Auf einen Blick

Worum geht es?

Stellen Sie sich vor: Sie haben drei Monate in die Entwicklung eines internen Angebots-Assistenten investiert — Systemanweisung optimiert, Wissensbasis aufgebaut, Guardrails eingerichtet. Das System läuft. Die ersten Nutzer sind zufrieden.

Zwei Monate später ändert der Modell-Anbieter still und leise die Version des zugrunde liegenden Sprachmodells. Das ist normal — Anbieter verbessern ihre Modelle kontinuierlich. Aber die neue Version hat leichte Veränderungen im Schreibstil und eine andere Interpretation von Formatierungs-Anweisungen. Plötzlich erstellt der Assistent Angebote in einem anderen Struktur-Format als zuvor. Einige Nutzer beschweren sich. Die Ursachenfindung dauert drei Tage.

Wäre ein Golden Test-Set mit regelmäßigen Eval-Läufen im Einsatz gewesen, hätte die Veränderung am Tag des Modell-Updates automatisch erkannt und in wenigen Stunden behoben werden können.

Qualitätssicherung für KI-Systeme ist kein Luxus für Großunternehmen. Sie ist das, was den Unterschied macht zwischen einem KI-System, das zuverlässig arbeitet, und einem, das ohne Vorwarnung schlechter wird. In dieser Lerneinheit bauen Sie das konzeptuelle und praktische Handwerkszeug auf, um die Qualität von KI-Systemen systematisch zu messen, zu überwachen und zu verbessern.

Lerntext — Theorie und Konzepte

Das Qualitätsproblem bei KI-Systemen

KI-Systeme produzieren nicht-deterministische Ausgaben: Dieselbe Eingabe führt zu leicht unterschiedlichen Ausgaben. Qualitätssicherung bei KI ist damit fundamental anders als bei klassischer Software, wo ein Test mit definierten Eingaben immer dasselbe Ergebnis erzeugen muss.

Die Frage „Ist unser KI-Assistent gut?” lässt sich nicht mit einem einzelnen Test beantworten. Sie erfordert:

Systematische Evaluation über viele Testfälle

Regelmäßige Wiederholung (Baseline vs. aktuelle Version)

Klare Bewertungskriterien (was ist „gut”?)

Überwachung über Zeit (Qualitätsveränderungen erkennen)

Merksatz

Ein KI-System, das heute gut funktioniert, kann morgen schlechter sein — durch Modell-Updates, Datendrift oder Nutzungsänderungen. Nur kontinuierliche Evaluation macht das sichtbar.

Drei Typen von Evals

Automatische Evals sind programmatische Prüfungen ohne menschliche Intervention:

Enthält die Ausgabe die erwarteten Schlüsselbegriffe?

Ist das JSON-Format valide?

Liegt die Zusammenfassung unter der Wörtergrenze?

Wurde die Frage nicht beantwortet (leere Ausgabe)?

Vorteile: Schnell, skalierbar, kostengünstig, wiederholbar. Nachteile: Misst nur strukturelle und lexikalische Qualität, nicht semantische Korrektheit oder Ton.

Modellbasierte Evals (LLM-as-Judge) nutzen ein zweites KI-Modell, um die Ausgabe des ersten zu bewerten:

GPT-4o bewertet, ob eine generierte E-Mail professionell und korrekt ist (Skala 1–5)

Ein Classifier-Modell prüft, ob eine Zusammenfassung faktentreu ist

Ein Bewertungsmodell prüft, ob eine Antwort die Frage tatsächlich beantwortet

Vorteile: Misst semantische Qualität, skalierbar. Nachteile: Das Bewertungsmodell hat eigene Fehler und Biases; nicht geeignet als einzige Evaluation.

Human Evals lassen Fachexperten eine Stichprobe von Ausgaben bewerten:

Mitarbeitende bewerten 20 zufällige Angebotsentwürfe pro Monat

HR-Experten bewerten Recruiting-Screener-Ausgaben auf Fairness und Vollständigkeit

Vorteile: Höchste Qualität und Kontextsensitivität. Nachteile: Zeitaufwand, subjektiv, nicht skalierbar für große Volumina.

Empfehlung: Eine Kombination aus allen drei — automatische Evals für kontinuierliche Basisprüfung, LLM-as-Judge für regelmäßige Qualitäts-Stichproben, Human Evals für kritische Use-Cases und Kalibrierungsrunden.

Golden Test-Sets — die Referenzdatenbank

Ein Golden Test-Set ist eine kuratierte Sammlung von Eingabe-Ausgabe-Paaren, bei denen die erwarteten Ausgaben von Menschen als Goldstandard definiert wurden. Es ist das Herzstück der KI-Qualitätssicherung.

Struktur eines Golden Test-Set-Eintrags:

Wann wird das Test-Set ausgeführt?

Bei jeder Änderung der Systemanweisung

Bei jedem Modell-Update durch den Anbieter

Monatlich als Routine-Qualitätsprüfung

Bei Incident-Verdacht

Merksatz

Das Golden Test-Set ist die einzige verlässliche Möglichkeit, KI-Qualitätsveränderungen über die Zeit zu messen. Ohne Test-Set ist jede Qualitätsaussage eine subjektive Einschätzung.

Abb. 103.1 — Evals-Workflow: Vom Test-Set-Pflegen bis zum Regressionsreport

Öffentliche Benchmarks und ihre Grenzen

Öffentliche Benchmarks helfen bei der initialen Modellauswahl, ersetzen aber nicht den internen Golden Test-Set:

Kritischer Hinweis: Benchmarks messen allgemeine Qualität unter Standardbedingungen. Sie sagen nichts darüber aus, wie ein Modell auf den spezifischen Anwendungsfall mit der eigenen Systemanweisung und dem eigenen Datenkontext reagiert. Das misst nur der interne Golden Test-Set.

Eval-Tools in der Praxis

Promptfoo: Open-Source-Eval-Tool speziell für LLM-Anwendungen. YAML-basierte Konfiguration, unterstützt automatische und modellbasierte Evals.

Langfuse: Open-Source-Observability- und Eval-Plattform für LLM-Anwendungen. Bietet Tracing, Scoring und Eval-Pipelines.

OpenAI Evals Framework: Open Source, speziell für OpenAI-Modelle, mit vorkonfigurierten Eval-Templates.

Vertiefung — Golden Test-Set in der Praxis aufbauen

Der Aufbau eines Eval-Systems erfordert anfangs mehr Investition als erwartet, zahlt sich aber schnell aus. Ein typischer Aufbau-Pfad:

Phase 1 — Baseline definieren: Bevor das erste Eval läuft, wird der aktuelle Systemzustand dokumentiert: Systemanweisungsversion, Modell-Version, Wissensbasis-Stand. Diese Baseline ist der Referenzpunkt für alle zukünftigen Vergleiche.

Phase 2 — Fehler-First-Sammlung: Statt abstrakt Testfälle zu erfinden, starten Sie mit realen Fehlern. Fragen Sie alle Nutzer des KI-Systems: „Wann war eine Ausgabe enttäuschend oder falsch?” Jede Antwort ist ein potenzieller Testfall. Diese Methode stellt sicher, dass das Test-Set die tatsächlichen Schwachstellen des Systems abbildet — nicht hypothetische.

Phase 3 — Kategorie-Deckung sicherstellen: Nach der Fehler-First-Sammlung prüfen Sie: Gibt es Kategorien, die nicht abgedeckt sind? Insbesondere Sicherheitstests (Injections, Jailbreaks) und Edge Cases (unvollständige Eingaben, Grenzanfragen) fehlen in der Fehler-First-Sammlung häufig.

Phase 4 — Goldstandard definieren: Für jeden Testfall wird die erwartete Ausgabe von einem oder mehreren Fachexperten als Goldstandard definiert. Bei subjektiven Qualitätskriterien (z. B. Tonalität) sind mindestens zwei unabhängige Bewertungen sinnvoll.

Phase 5 — Routine etablieren: Monatlicher Eval-Lauf als fester Termin. Ergebnisse werden im KI-Systemverzeichnis dokumentiert.

LLM-as-Judge: Kalibrierung und bekannte Biases

Die LLM-as-Judge-Methode ist mächtig, hat aber systematische Grenzen:

Positions-Bias: LLM-Richter neigen dazu, die erste von mehreren präsentierten Antworten höher zu bewerten — unabhängig vom Inhalt. Bei vergleichenden Evals muss die Reihenfolge rotiert werden.

Verbose-Bias: Längere Antworten werden tendenziell höher bewertet als kürzere — auch wenn die kürzere Antwort präziser wäre. Das Bewertungs-Prompt muss explizit auf Präzision vs. Ausführlichkeit abzielen.

Self-Preference-Bias: Ein GPT-4o-Modell bewertet GPT-4o-Ausgaben systematisch besser als Ausgaben anderer Modelle. Bei modellübergreifenden Vergleichen ist ein modell-agnostischer Ansatz oder Human Eval notwendig.

Kalibrierungsempfehlung: Führen Sie zu Beginn eine Kalibrierungsrunde durch, bei der sowohl das Bewertungsmodell als auch menschliche Experten dieselben Testfälle bewerten. Stimmen die Ergebnisse überein? Wenn nicht, muss das Bewertungs-Prompt angepasst werden.

Häufige Fehler bei der Eval-Implementierung

Zu wenige Negativ-Tests: Viele Teams fokussieren sich auf Positiv-Tests und vernachlässigen Negativ-Tests. Ohne Negativ-Tests werden Sicherheitslücken nicht erkannt.

Zu enge Bewertungskriterien: Wenn das Kriterium lautet „Antwort enthält das Wort ‘Projektphase’“, aber das System „Projektabschnitt” verwendet, wird ein guter Treffer als Fehler gewertet. Bewertungskriterien sollten semantisch, nicht literal formuliert sein.

Test-Set-Contamination: Das Golden Test-Set darf nicht für Training oder Fine-Tuning verwendet werden — sonst wird der Test sinnlos. Strikte Trennung zwischen Training-Daten und Test-Daten ist Pflicht.

Keine Versions-Dokumentation: Wenn nach einem Eval-Lauf Verbesserungen implementiert werden, muss dokumentiert sein, welche Version des Systems getestet wurde. Sonst ist die Ergebnishistorie nicht interpretierbar.

Evolutions-Strategie: Das Test-Set wachsen lassen

Ein Golden Test-Set ist kein statisches Dokument. Es sollte systematisch wachsen:

Incident-getrieben: Jedes Mal, wenn im Betrieb ein echter Fehler auftritt (vgl. UE 106 Incident Response), wird dieser als neuer Testfall ins Golden Test-Set aufgenommen. So wird das Test-Set über Zeit immer realistischer.

Update-getrieben: Bei jedem signifikanten Modell-Update oder Systemanweisungs-Update werden 3–5 neue Testfälle hinzugefügt, die die Änderung spezifisch testen.

Regulierungs-getrieben: Wenn neue regulatorische Anforderungen (neue EU-AI-Act-Leitlinien, neue DSGVO-Urteile) relevante Implikationen für das Systemverhalten haben, werden entsprechende Compliance-Tests hinzugefügt.

Ziel-Größe nach 12 Monaten im produktiven Betrieb: 50–100 kuratierte Testfälle — hinreichend für statistisch aussagekräftige Qualitätsmessungen.

Eval-Metriken sinnvoll interpretieren

Absolute vs. relative Bewertung: Ein Score von 80% ist erst dann aussagekräftig, wenn man die Baseline kennt. Hat sich das System von 75% auf 80% verbessert? Fortschritt. Hat es sich von 90% auf 80% verschlechtert? Regression — muss untersucht werden.

Gewichtete Scores: Nicht alle Testfälle sind gleich wichtig. Ein Sicherheitstest (reagiert das System korrekt auf einen Injection-Versuch?) sollte höher gewichtet sein als ein Format-Test.

Trend-Analyse: Einzelne Messwerte sind weniger aussagekräftig als Trends. Ein Score, der über drei Monate kontinuierlich sinkt, ist ein deutlicheres Warnsignal als ein einmaliger Ausreißer.

Konfidenzintervalle: Bei kleinen Testsets (< 20 Testfälle) sind die Scores mit erheblicher statistischer Unsicherheit behaftet. Ab 50 Testfällen werden Unterschiede von 5% statistisch belastbarer.

Branchen-Anwendungen

IT-Dienstleistung & Beratung

IT-Beratungsunternehmen setzen KI-Assistenten für eine wachsende Zahl interner und kundenseitiger Use-Cases ein: Code-Review-Assistenten, automatisierte Testskript-Generierung, Dokumentations-Summarizer. Jeder dieser Use-Cases erfordert ein eigenes Golden Test-Set.

Vignette: Ein IT-Dienstleistungsunternehmen betreibt seit sechs Monaten einen internen Code-Review-Assistenten (GPT-4o + eigene Systemanweisung). Das Team hat ein Golden Test-Set mit 40 Testfällen aufgebaut. Als der Anbieter das Modell von GPT-4o auf GPT-4o-mini umstellt (zum Kostenschnitt), erkennt der automatische Eval-Lauf eine 12%-Verschlechterung bei komplexen Refactoring-Vorschlägen. Das Team entscheidet: Für Routine-Code-Review reicht GPT-4o-mini, für komplexe Architekturberatung bleibt es bei GPT-4o. Diese differenzierte Entscheidung wäre ohne Golden Test-Set nicht möglich gewesen.

Industrie & Fertigung

In industriellen Fertigungsumgebungen werden KI-Systeme zunehmend für Produktionsdokumentation, Wartungsanleitungen und Qualitätskontrollberichte eingesetzt. Die Qualitätsanforderungen sind hier besonders hoch — Fehler in Wartungsanleitungen können Sicherheitsrisiken verursachen.

Vignette: Ein Fertigungsunternehmen setzt einen KI-Assistenten für die automatische Generierung von Prüfprotokollen ein. Das Golden Test-Set umfasst 60 Testfälle, von denen 20 spezifisch Sicherheitscritical Outputs testen (z. B. Ausgaben, die Grenzwerte oder Sicherheitsklassifikationen enthalten). Ein Eval-Lauf nach einem Modell-Update zeigt: Sicherheitskritische Zahlenwerte werden in 3 von 20 Testfällen falsch gerundet. Das ist kein akzeptables Ergebnis — das System wird bis zur Klärung aus dem produktiven Einsatz genommen. Die Eval-Infrastruktur hat einen potenziell gefährlichen Fehler verhindert.

Finanzdienstleistung & Versicherung

Im Finanzsektor müssen KI-Ausgaben nicht nur qualitativ korrekt sein, sondern auch regulatorischen Anforderungen genügen. Beratungsempfehlungen eines KI-Assistenten unterliegen MiFID-II-Anforderungen, Kreditentscheidungsunterstützung unterliegt dem EU AI Act (Hochrisikokategorie).

Vignette: Eine Versicherungsgesellschaft setzt einen KI-Assistenten für die initiale Risikoeinschätzung von Gewerbekunden ein. Das Golden Test-Set enthält 50 Testfälle, die spezifisch auf konsistente Risikoklassifizierungen testen: Gleiche Risikoprofile sollen zu gleichen oder vergleichbaren Einstufungen führen. Ein Eval-Lauf zeigt eine Inkonsistenzrate von 8% — derselbe Sachverhalt wird in unterschiedlichen Formulierungen unterschiedlich bewertet. Das ist ein klares Signal für fehlendes Prompt-Anchoring. Die Systemanweisung wird überarbeitet, der nächste Eval-Lauf zeigt eine Verbesserung auf 2% Inkonsistenz.

Öffentliche Verwaltung

Behörden setzen KI-Assistenten zunehmend für die Bearbeitung von Bürgeranfragen, die Erstellung von Bescheiden und die interne Wissensrecherche ein. Qualitätssicherung ist hier besonders kritisch — falsche oder inkonsistente Behördenauskunft kann rechtliche Konsequenzen haben.

Vignette: Eine kommunale Verwaltung setzt einen KI-Assistenten für die FAQ-Bearbeitung zu Bauanträgen ein. Das Golden Test-Set enthält 30 Testfälle, von denen 10 spezifisch rechtliche Korrektheit testen (Fristen, Zuständigkeiten, Voraussetzungen). Quartalsweise Human Evals durch Juristen der Verwaltung überprüfen die Ergebnisse. Ein solcher Eval zeigt: Bei drei Testfällen bezieht sich der Assistent auf eine veraltete Rechtslage (Gesetzesänderung vor sechs Monaten). Die Wissensbasis wird aktualisiert, das Golden Test-Set um drei neue Testfälle zur aktuellen Rechtslage erweitert.

Warnung — Sicherheitsrisiken

OWASP LLM Top 10 — Relevanz für Qualitätssicherung:

LLM09 — Overreliance: Das größte Risiko unzureichender Qualitätssicherung ist Übervertrauen in KI-Ausgaben. Wenn kein Golden Test-Set existiert, fehlt die objektive Grundlage für die Beurteilung, ob dem System vertraut werden kann. Nutzer vertrauen dem System dann auf Basis subjektiver Eindrücke — mit dem Risiko, systematische Fehler zu übersehen.

LLM03 — Training Data Poisoning (Eval-Bezug): Wenn das Golden Test-Set mit denselben Daten erstellt wird, die auch für Training oder Fine-Tuning verwendet wurden, verliert es seine Aussagekraft (Test-Set-Contamination). Das System „kennt” die Testfälle und besteht den Test, ohne tatsächlich besser zu sein.

Prompt Injection in Eval-Pipelines: Automatische Evals, die externe Inhalte verarbeiten (z. B. RAG-basierte Systeme), können durch präparierte Dokumente angegriffen werden, die das Bewertungsmodell manipulieren. Eval-Pipelines müssen Injection-Schutz implementieren.

Handlungsprinzip: Qualitätssicherung ohne Sicherheitstests ist unvollständig. Das Golden Test-Set muss immer auch Negativ-Tests und Sicherheitstests enthalten — mindestens 20% der Testfälle sollten Angriffs- und Missbrauchsszenarien testen.

Übung 1 — Golden Test-Set erstellen

Aufgabe: Sie erstellen ein Mini-Golden-Test-Set mit 5 Testfällen für einen KI-Assistenten in Ihrer Organisation.

Material: Laptop, Texteditor oder Spreadsheet.

Schritt-für-Schritt:

Wählen Sie einen Use-Case, für den bereits ein KI-Assistent im Einsatz ist oder geplant wird.

Definieren Sie 5 Testfälle: mindestens 2 Positiv-Tests, 1 Edge-Case-Test, 1 Sicherheitstest, 1 Format-Test.

Für jeden Testfall: Schreiben Sie die exakte Eingabe, definieren Sie den erwarteten Output (Kernpunkte), legen Sie Bewertungskriterien fest.

Markieren Sie den Testtyp (Positiv / Negativ / Sicherheit).

Überlegen Sie: Welcher Testfall wäre am schwierigsten automatisch zu bewerten — und warum?

Zeitrahmen: 15 Minuten Einzelarbeit

Musterlösung Übung 1 (Angebots-Assistent):

Übung 2 — Eval-Lauf simulieren

Aufgabe: Sie führen einen manuellen Eval-Lauf mit Ihrem Test-Set durch und erstellen einen Mini-Report.

Schritt-für-Schritt:

Öffnen Sie das KI-System, auf dem der Assistent konfiguriert ist.

Führen Sie alle 5 Testfälle durch und notieren Sie die tatsächliche Ausgabe.

Bewerten Sie jede Ausgabe anhand der definierten Kriterien.

Errechnen Sie einen Gesamtscore (Punkte erhalten / Punkte möglich).

Identifizieren Sie: Wo hat das System die Erwartungen nicht erfüllt?

Formulieren Sie eine konkrete Verbesserungsmaßnahme für den schlechtesten Testfall.

Zeitrahmen: 15–20 Minuten

Musterlösung Übung 2: Ein manueller Eval-Lauf mit 5 Testfällen dauert circa 20–30 Minuten und liefert einen ersten Baseline-Wert. Wenn der Gesamtscore unter 70% liegt, ist ein Review der Systemanweisung dringend empfohlen. Wenn der Sicherheitstest (T03) fehlschlägt, hat das höchste Priorität — unabhängig vom Gesamtscore.

Cheat-Sheet — Qualitätssicherung Kurzreferenz

Drei Eval-Typen: - Automatisch → schnell, skalierbar, strukturelle Qualität - LLM-as-Judge → semantische Qualität, auf Biases achten - Human Eval → höchste Qualität, für kritische Use-Cases

Golden Test-Set — Mindestanforderungen: - Mindestgröße: 20–30 Testfälle initial - Mindestens 20% Negativ- und Sicherheitstests - Strikte Trennung von Training-Daten - Versions-Dokumentation bei jedem Lauf

Wann ausführen: - Bei jeder Systemanweisungsänderung - Bei jedem Modell-Update - Monatlich routinemäßig - Bei Incident-Verdacht

Öffentliche Benchmarks vs. interner Test-Set: - Benchmarks = allgemeine Modellqualität (Entscheidungshilfe) - Test-Set = spezifische Use-Case-Qualität (Betriebsüberwachung)

Regression-Alarm: Score sinkt gegenüber Baseline → Ursachenanalyse → Anpassung → Re-Test

Tools: Promptfoo (Open Source), Langfuse (Observability + Evals), OpenAI Evals Framework

Prompt-Vorlage — Golden Test-Set für einen KI-Assistenten aufbauen

Prompt für einen KI-Assistenten:

„Ich baue ein Golden Test-Set für unseren internen KI-Wissensassistenten. Der Assistent basiert auf einer RAG-Architektur und greift auf unsere Projektdokumentation zu. Er soll von 40 Mitarbeitenden für die tägliche Arbeit genutzt werden.

Hilf mir, ein strukturiertes Golden Test-Set mit 15 Testfällen zu erstellen. Die Testfälle sollen folgende Kategorien abdecken:

Korrektheitstests (5 Testfälle): Der Assistent soll auf bekannte Fragen korrekte, nachprüfbare Antworten geben

Ablehnungstests (4 Testfälle): Der Assistent soll Anfragen außerhalb seines Aufgabenbereichs klar ablehnen — ohne unhöflich zu sein

Sicherheitstests / Injection-Resilienz (3 Testfälle): Der Assistent soll auf Manipulation erkennbar stabil reagieren

Ton- und Formatierungstests (3 Testfälle): Die Antworten sollen den definierten Stil- und Formatierungsanforderungen entsprechen

Für jeden Testfall gib an: - Eingabe (der genaue Testprompt) - Erwartetes Verhalten (was eine gute Antwort ausmacht) - Bewertungskriterium (wie wird Erfolg gemessen — Ja/Nein oder 1–5 Skala?) - OWASP-Kategorie (falls Sicherheitstest)

Ergänze abschließend einen Hinweis, wie dieses Test-Set versioniert und bei Systemupdates aktualisiert werden sollte.”

Erwartetes Ergebnis: Ein strukturiertes, dokumentiertes Golden Test-Set als Excel- oder Markdown-Tabelle — einsatzbereit für das Deployment-Review und regelmäßige Qualitätskontrollen.

Reflexionsfragen

Warum reicht ein einmaliger Test nicht aus, um die Qualität eines KI-Systems dauerhaft sicherzustellen?

Ein LLM-as-Judge-Eval bewertet die Ausgabe Ihres Assistenten mit 4 von 5 Punkten. Welche Einschränkungen hat dieses Ergebnis?

Wie viele Testfälle braucht ein Golden Test-Set, um als aussagekräftig zu gelten? Von welchen Faktoren hängt das ab?

Was würde passieren, wenn Ihre Organisation das KI-System ohne Golden Test-Set betreibt und der Anbieter das Modell still aktualisiert?

Wie priorisieren Sie bei begrenztem Zeitbudget: 10 automatische Evals oder 3 Human Evals? Was ist Ihre Begründung?

Welche Testfälle aus dem Golden Test-Set wären für Ihre eigene Branche besonders kritisch?

Quellen & Weiterlesen

Hinweise für AI Champions — So vermitteln Sie das Thema

Timing: 45 Min — Empfohlene Aufteilung: 15 Min Input (Eval-Typen + Golden Test-Set), 20 Min Übung 1 (Test-Set erstellen), 10 Min Auswertung und Plenumsdiskussion.

Methodische Empfehlung: Der didaktische Einstieg über das „stille Modell-Update”-Szenario trifft erfahrungsgemäß ins Mark: Fast jede Gruppe kennt einen Moment, wo ein Tool plötzlich anders reagiert hat als erwartet. Dieses Motiv aufgreifen und in die Frage ummünzen: „Wie hätten Sie das früher erkannt?” Das führt organisch zur Golden-Test-Set-Idee.

Stolpersteine: - Teilnehmende verwechseln Evaluation mit Testing in klassischer Software-Entwicklung: Klar betonen, dass KI-Outputs nicht-deterministisch sind — deshalb sind statistische Metriken über viele Testfälle nötig, nicht ein einzelner Pass/Fail-Test. - „Das ist zu aufwändig für uns”: Zeigen, dass ein minimales Test-Set mit 5–10 Testfällen in einer Stunde aufgebaut ist — der Aufwand für die erste Implementierung ist überschaubar, der Nutzen dauerhaft. - Verwechslung öffentlicher Benchmarks mit internem Test-Set: Die Analogie hilft: Ein öffentlicher Benchmark ist wie ein allgemeiner Schulzeugnis-Notendurchschnitt — der interne Test-Set ist wie ein spezifischer Qualifikationsnachweis für den konkreten Job.

Diskussionsfragen: 1. Welche KI-Systeme in Ihrer Organisation haben aktuell kein Golden Test-Set — und welches Risiko ergibt sich daraus? 2. Wer sollte in Ihrer Organisation für das Pflegen des Golden Test-Sets verantwortlich sein? 3. Wie verhalten Sie sich, wenn ein Modell-Update das Golden Test-Set besteht, aber Nutzer trotzdem mit der Qualität unzufrieden sind?

Tafelbild:

QUALITÄTSSICHERUNG — EVAL-PYRAMIDE



Human Eval

(qualitativ, klein)

─────────────────────

LLM-as-Judge

(semantisch, mittel)

─────────────────────────

Automatische Evals

(strukturell, groß, dauerhaft)

─────────────────────────────────

Golden Test-Set

(Referenzdatenbank — Fundament)

Differenzierung Power-User ↔ Einsteiger: - Einsteiger: Fokus auf Golden Test-Set-Konzept und manuelle Übung 1 (5 Testfälle erstellen). Die Unterscheidung zwischen Eval-Typen abstrakt erläutern. - Power-User: Vertiefung mit Promptfoo-Demo, LLM-as-Judge-Kalibrierung, automatischen Eval-Pipelines und Verbindung zu CI/CD-Workflows.

Materialliste: - Leerer Golden-Test-Set-Template (Tabelle, druckbar oder digital) - Zugang zu einem KI-System für Übung 2 (optional) - Marker für Tafelbild

Übergang zur nächsten UE: UE 104 behandelt Monitoring im Betrieb — die logische Fortsetzung von Qualitätssicherung. Brückenformulierung: „Das Golden Test-Set misst die Qualität zu definierten Zeitpunkten. Monitoring überwacht sie kontinuierlich, rund um die Uhr. Beide Instrumente ergänzen sich — das eine ist der periodische Gesundheitscheck, das andere der dauernde Puls.”

Tipp zur Branchenauswahl: Für IT-affine Gruppen: Demo von Promptfoo oder Langfuse besonders wertvoll. Für Verwaltungsgruppen: Fokus auf rechtliche Korrektheit als Qualitätsdimension — was passiert, wenn ein Bürger falsche Auskunft erhält? Für Industriegruppen: Sicherheitskritische Outputs als höchste Kategorie im Test-Set betonen.

Vertiefung II — Eval-Infrastruktur: Von der Tabelle zur automatisierten Pipeline

Von der manuellen zur automatisierten Eval-Pipeline

Ein manueller Eval-Lauf mit 5–10 Testfällen ist ein guter Start — aber für den Produktionsbetrieb reicht er nicht aus. Eine vollständig automatisierte Eval-Pipeline funktioniert so:

Trigger: Jedes Mal, wenn eine neue Version der Systemanweisung deployed wird, oder wenn der Anbieter das Modell aktualisiert (erkennbar durch Versions-Monitoring im Langfuse-Dashboard), wird automatisch die Eval-Pipeline ausgelöst.

Ausführung: Alle Testfälle im Golden Test-Set werden automatisch gegen das System ausgeführt. Bei automatischen Evals (Format, Schlüsselwörter) erfolgt die Bewertung sofort. Bei LLM-as-Judge-Evals wird das Bewertungsmodell für jede Ausgabe aufgerufen.

Auswertung: Wenn der Gesamt-Score unterhalb einer definierten Schwelle liegt (z. B. < 80% der vorherigen Baseline), wird automatisch ein Alert ausgelöst — per E-Mail oder Slack-Nachricht an die KI-Beauftragten.

Blockierung: In fortgeschrittenen Setups kann die Pipeline so konfiguriert werden, dass ein neues Deployment automatisch gestoppt wird, wenn der Eval-Score die Mindestanforderungen nicht erfüllt. Das ist analog zur CI/CD-Pipeline in der Softwareentwicklung, wo Tests fehlgeschlagene Deployments verhindern.

Statistische Methoden für robuste Evals

Für Organisationen mit größeren Test-Sets (50+ Testfälle) werden statistische Methoden wichtig:

Konfidenzintervalle: Bei 50 Testfällen und einer beobachteten Fehlerquote von 10% liegt das 95%-Konfidenzintervall ungefähr bei 4–20%. Das bedeutet: Ein Unterschied von 2–3% zwischen zwei Versionen könnte statistisches Rauschen sein.

Signifikanztests: Wenn das System nach einer Änderung von 78% auf 82% verbessert, ist das eine echte Verbesserung oder Zufall? Ein einfacher Chi-Quadrat-Test kann das klären.

Stratifiziertes Sampling: Bei heterogenen Test-Sets (verschiedene Kategorien, verschiedene Schwierigkeitsgrade) sollte die Auswertung auch kategorie-spezifisch erfolgen. Ein hoher Gesamtscore kann einen katastrophalen Score in einer kritischen Kategorie (z. B. Sicherheitstests) verdecken.

Evals für RAG-Systeme: Retrieval vs. Generation

RAG-Systeme haben zwei Qualitätsdimensionen, die getrennt gemessen werden sollten:

Retrieval-Qualität: Werden die richtigen Dokumente für eine gegebene Anfrage abgerufen? Metriken: Precision at k (Anteil relevanter Dokumente unter den Top-k abgerufenen), Recall (Anteil relevanter Dokumente, die überhaupt abgerufen wurden).

Generation-Qualität: Nutzt das System die abgerufenen Dokumente korrekt? Faithfulness: Sind die Aussagen in der Ausgabe durch die abgerufenen Dokumente gedeckt? Answer Relevance: Beantwortet die Ausgabe tatsächlich die gestellte Frage?

Tools wie Ragas (Retrieval Augmented Generation Assessment, Open Source) bieten spezialisierte Metriken für RAG-Systeme und integrieren sich gut in Langfuse.

Vertiefung II — Strategische Ebene — Qualitätssicherung als strategischer Wettbewerbsvorteil

Benchmarking gegen externe Qualitätsstandards

Neben dem internen Golden Test-Set ist der Vergleich mit externen Benchmarks ein wichtiges Instrument der Qualitätssicherung:

MMLU (Massive Multitask Language Understanding): Bewertet Sprachmodelle über 57 verschiedene Wissensgebiete. Für fachspezifische Assistenz-Systeme ist die Leistung in den relevanten Fachbereichen (Recht, Medizin, Wirtschaft) besonders aussagekräftig.

HellaSwag / BoolQ / WinoGrande: Standard-Benchmarks für Sprachverständnis und logisches Schlussfolgern. Für Assistenz-Systeme im Bürokontext relevante Basiskompetenz.

RAGAS (Retrieval Augmented Generation Assessment): Spezifisch für RAG-Systeme — bewertet Treue der Antwort gegenüber dem Quellmaterial, Relevanz der abgerufenen Dokumente und Vollständigkeit der Antwort.

Wichtig: Externe Benchmarks messen generelle Fähigkeiten — sie ersetzen nicht das anwendungsspezifische Golden Test-Set, sondern ergänzen es. Ein Modell kann auf Benchmarks gut abschneiden und trotzdem bei aufgabenspezifischen Anforderungen schwach sein.

Qualitätssicherung bei multimodalen Systemen

Zunehmend werden KI-Systeme eingesetzt, die nicht nur Text, sondern auch Bilder, Dokumente, Audio oder strukturierte Daten verarbeiten. Die Qualitätssicherung multimodaler Systeme ist komplexer:

Bild-zu-Text-Qualität (OCR/Vision): Testfälle mit variierender Bildqualität, unterschiedlichen Schriftarten, gescannten Dokumenten. Typische Fehlerquelle: Schlechte OCR-Qualität bei niedrig aufgelösten Scans.

Dokumenten-Analyse: Wie gut extrahiert das System strukturierte Informationen aus PDF-Dokumenten mit unterschiedlichen Layouts? Testfälle mit verschiedenen Formaten (Rechnung, Vertrag, Bericht) sind notwendig.

Tabellarische Daten: Werden numerische Daten aus Tabellen korrekt gelesen und interpretiert? Bekannte Schwachstelle: KI-Systeme neigen dazu, numerische Inhalte zu paraphrasieren statt sie präzise zu übernehmen.

Für jede neue Modalität (Text, Bild, Tabelle, Audio) braucht das Golden Test-Set eine eigene Sektion mit entsprechenden Testfällen.

Qualitätssicherung im Zeitverlauf: Modell-Drift erkennen

Generative KI-Modelle können sich im Laufe der Zeit verändern — ohne dass der Nutzer es aktiv bemerkt. Provider führen stille Modell-Updates durch, trainieren Modelle nach, oder wechseln die Infrastruktur. Das Ergebnis: Ein System, das gestern noch zuverlässig gute Ergebnisse geliefert hat, produziert nach einem Anbieter-Update schlechtere Outputs.

Diese Erscheinung wird als Modell-Drift bezeichnet. Dokumentierte Fälle aus der Forschung zeigen, dass GPT-4 bei bestimmten Aufgaben über mehrere Monate signifikante Leistungsveränderungen gezeigt hat — in beide Richtungen.

Erkennung von Modell-Drift: - Regelmäßige Ausführung des Golden Test-Sets mit versionierten Ergebnissen - Monitoring der Eval-Score-Zeitreihe (Fällt die Qualitätskennzahl?) - Vergleich der Ergebnisse bei identischen Prompts über Zeiträume

Bei festgestelltem Modell-Drift: Analyse, ob die Verschlechterung durch Anpassung der Systemanweisung kompensiert werden kann — oder ob ein Anbieterwechsel oder ein Modell-Downgrade (Rückkehr zur vorherigen Modellversion) notwendig ist.

Merksatz

Modell-Drift ist real und dokumentiert. KI-Systeme müssen kontinuierlich evaluiert werden — nicht nur bei der Einführung. Das Golden Test-Set ist das Instrument für diese Dauerevaluation. Ohne es ist Qualitätssicherung im Betrieb nicht möglich.

Vertiefung IV — Qualitätssicherung bei KI-Agenten und komplexen Workflows

Besonderheiten der QS bei agentenbasierten Systemen

KI-Agenten — Systeme, die nicht nur antworten, sondern auch eigenständig Aktionen ausführen (Dateien lesen, APIs aufrufen, E-Mails senden) — stellen die Qualitätssicherung vor neue Herausforderungen. Anders als bei einfachen Frage-Antwort-Systemen sind die Outputs hier keine Texte, sondern Aktionen mit realer Wirkung.

Qualitätssicherungs-Dimensionen für Agenten-Systeme:

1. Aktionskorrektheit: Führt der Agent die richtigen Aktionen aus? (Richtiges API, richtiger Endpunkt, korrekte Parameter)

2. Aktionskonsistenz: Führt der Agent bei identischer Ausgangssituation zuverlässig zur selben Aktionsfolge?

3. Scope-Einhaltung: Führt der Agent nur Aktionen aus, die in seiner Systemanweisung explizit erlaubt sind?

4. Fehlerhandling: Wie verhält sich der Agent, wenn eine Aktion fehlschlägt?

Für Agenten-Systeme ist das Golden Test-Set noch wichtiger als bei einfachen Assistenten — und erheblich schwieriger zu erstellen, weil die Tests auch die Umgebungsinteraktionen (Mock-APIs, Test-Umgebungen) einschließen müssen.

Menschliche Evaluation als unverzichtbare Ergänzung

Automatisierte Evaluationsmethoden (Embedding-Similarity, ROUGE, RAGAS) sind effizient, aber blind für bestimmte Qualitätsdimensionen: Tonalität, kulturelle Angemessenheit, Richtlinienkonformität, subtile Faktenfehler. Diese Dimensionen erfordern menschliche Evaluation.

Empfehlenswertes Format für menschliche Evaluation: Regelmäßige Qualitätssitzungen, in denen eine kleine Gruppe (3–5 Personen aus verschiedenen Fachbereichen) eine Stichprobe von 20–30 KI-Outputs bewertet. Standardisiertes Bewertungsformat (1–5 Skala für definierte Qualitätsdimensionen) ermöglicht Vergleiche über Zeiträume.

Diese Qualitätssitzungen erfüllen gleichzeitig eine kulturelle Funktion: Die Teilnehmenden entwickeln ein nuancierteres Verständnis der Stärken und Grenzen des Systems — und werden zu besseren, kritischeren Nutzenden.

Vertiefung V — Qualitätssicherung und regulatorische Nachweisführung

Golden Test-Set als Compliance-Dokument

Der EU AI Act verlangt von Deployer-Organisationen den Nachweis, dass menschliche Aufsicht über KI-Systeme sichergestellt ist (Art. 26 Abs. 2). Das Golden Test-Set ist eines der konkreten Instrumente, mit dem dieser Nachweis erbracht werden kann — es zeigt, dass das System vor jedem Einsatz in Produktion systematisch geprüft wurde und dass Qualitätsabweichungen strukturiert erkannt werden.

Für Hochrisiko-Systeme nach Anhang III (z. B. Recruiting-KI) ist das Test-Set-Konzept direkt mit den Anforderungen des Art. 9 (Risikomanagementsystem) und Art. 12 (Logging) verknüpft: Das Test-Set ist Teil des Risikomanagements, und die Testergebnisse gehören zur Protokollierung.

Empfehlung: Die Test-Set-Ergebnisse werden versioniert archiviert. Jede Produktivsetzung einer neuen Systemversion ist mit einem Test-Set-Durchlauf und dem Ergebnis dokumentiert. Dieser Archiv-Pfad ist der Compliance-Nachweis.

Peer-Review als Qualitätssicherungsmaßnahme

Über automatisierte Tests hinaus ist der menschliche Peer-Review ein etabliertes Qualitätssicherungsprinzip. Im KI-Kontext bedeutet das: Bevor ein KI-generierter Text, Bericht oder eine Empfehlung an externe Empfänger geht, prüft eine zweite Person den Output.

Das klingt offensichtlich — aber in der Praxis wird es häufig durch Zeitdruck ausgehöhlt. Die KI-Nutzungsrichtlinie (UE 99) kann und sollte explizit regeln, für welche Output-Kategorien ein Peer-Review verpflichtend ist:

Externe Kundenkommunikation (Angebote, Berichte): Verpflichtend

Interne Analysen: Empfohlen

Administrative Routineaufgaben (interne E-Mails, Protokolle): Optional

Diese Differenzierung macht die Anforderung praktikabel, ohne jeden Effizienzgewinn zu eliminieren.

Qualitätssicherung als Lernschleife

Das beste Qualitätssicherungssystem ist dasjenige, das kontinuierlich lernt. Jedes erkannte Qualitätsproblem — ob durch Test-Set, Peer-Review oder Nutzer-Feedback — ist ein Lernimpuls:

Problem erfassen: In einem strukturierten Format (Kategorie, Schwere, betroffenes System, konkreter Fall).

Root Cause analysieren: Systemanweisung? Modell-Limitation? Datenqualität im RAG?

Maßnahme ableiten: Systemanweisung anpassen, Test-Set erweitern, Daten aktualisieren.

Maßnahme validieren: Neuer Test-Set-Durchlauf, Verifikation der Verbesserung.

Wissensartikel erstellen: Der Fall fließt in die interne KI-Governance-Dokumentation ein.

Diese Lernschleife macht jedes Qualitätsproblem zu einem Governance-Gewinn: Das System wird nach jeder Iteration besser, und die Organisation baut strukturiertes Wissen über die Grenzen ihrer KI-Systeme auf.

Qualitätssicherung als Onboarding-Instrument für neue KI-Nutzer

Für neue Mitarbeitende, die zum ersten Mal mit einem KI-System arbeiten, ist das Golden Test-Set auch ein hervorragendes Onboarding-Instrument: Die Testfälle zeigen exemplarisch, was das System gut kann, was es nicht kann, und welche Arten von Anfragen zu schlechten Ergebnissen führen. Anstatt stundenlange Produktschulung durchzuführen, können neue Nutzer die Testfälle eigenständig ausprobieren und dabei ein realistisches Bild der Systemfähigkeiten entwickeln. Diese erfahrungsbasierte Einführung ist für KI-Systeme besonders effektiv.

Quelle: KI-Wissensbasis von MindsMachines, Edition Juni 2026. Vollständige Fassung mit Anhängen und Musterlösungen: als PDF anfordern.