Qualität messen: geplante Systemtests statt Bauchgefühl

Zwei plausible Systeme, aber nur eines hilft im Prozess

Deine Firma repariert Heizungsanlagen. Jeden Morgen kommen Supportanfragen mit Fehlermeldungen, Fotos und Seriennummern an. Ein KI-System soll daraus einen Antwortentwurf erstellen. Ein Mitarbeiter prüft ihn und schickt ihn ab.

System A schreibt sehr flüssig. Im ersten Versuch erkennt es den Fehlercode, nennt drei mögliche Ursachen und formuliert freundlich. Allerdings stammt die genannte Wartungsfrist aus einem alten Handbuch. Bei fehlender Seriennummer entscheidet es sich einfach für das wahrscheinlichste Gerät. Seine Antwort sieht in der Oberfläche bereits wie eine versandfertige Nachricht aus.

System B klingt etwas nüchterner. Es findet das gültige Handbuch über das Retrieval, nennt die Fundstelle und fragt bei fehlender Seriennummer nach. Die Ausgabe hält das vorgegebene Format ein. Eine Antwort mit Sicherheitsbezug landet immer bei einem erfahrenen Mitarbeiter. Erst dessen Freigabe erlaubt den Versand.

Beide Antworten können in einer Vorführung plausibel wirken. Im wirklichen Ablauf hilft nur System B. Der Unterschied liegt nicht allein im Modell. Kontext, Retrieval, Werkzeuge, Oberfläche, Kontrollen und menschliche Verantwortung verändern das Ergebnis. Kapitel 4 hat diese Systemkarte eingeführt. Jetzt brauchen wir eine Methode, mit der du genau dieses vollständige System prüfst.

Eine gelungene Einzelantwort ist dafür zu wenig. Du musst wissen, wie das System bei gewöhnlichen Fällen, fehlenden Angaben, seltenen Fehlern, ausgefallenen Werkzeugen und manipulierten Dokumenten reagiert. Du musst außerdem messen, wie lange die Prüfung dauert und was ein brauchbares Ergebnis kostet.

Ein geplanter Systemtest heißt Eval

Die ausführliche Bezeichnung lautet Evaluation. Ein Eval besteht aus festgelegten Testfällen, erwarteten Eigenschaften und einer dokumentierten Auswertung. Ein Testfall enthält mindestens eine Eingabe und die Regeln für ein akzeptables Ergebnis.

Halte auch fest, was genau du prüfst. „Wir testen Modell X“ reicht bei einer Anwendung selten aus. Schreibe auf, welche Versionen und Einstellungen du tatsächlich verwendest:

• Modell und Laufzeiteinstellungen
• Systemanweisung und Nutzereingabe
• Kontext, Retrieval und Gedächtnis
• Werkzeuge und ihre Berechtigungen
• Oberfläche, Kontrollen und menschliche Freigaben

Änderst du einen dieser Teile, prüfst du ein anderes System. Das gilt auch für eine neue Dokumentensammlung oder eine scheinbar kleine Änderung am Ausgabeformat. Ein Anbieter kann außerdem das Modell hinter einer Schnittstelle aktualisieren. Halte deshalb Datum, Modellkennung, Prompts, Datenstand und Werkzeugversionen je Testlauf fest.

Zu jedem Fall speicherst du die Eingabe, die Ausgabe und das Ergebnis der Prüfung. Bei schwankenden Antworten gehören auch die Laufnummer und die Einstellungen für die Erzeugung dazu. Wichtige Fälle führst du mehrfach aus. So erkennst du, ob ein Erfolg zuverlässig wiederkehrt oder nur in einem von fünf Versuchen auftaucht.

Öffentliche Benchmarks bleiben nützlich. Sie vergleichen Modelle unter gemeinsamen Bedingungen und können allgemeine Schwächen sichtbar machen. Sie beweisen aber nicht, dass dein Supportprozess funktioniert. Dessen Dokumente, Sprachen, Berechtigungen und Folgen kommen in einer allgemeinen Rangliste gar nicht vor.

NIST fordert Vergleichswerte, dokumentierte Tests und Bedingungen, die dem späteren Einsatz ähneln. Für einen Unternehmensprozess schlage ich daraus die folgende Arbeitsfolge vor. Der konkrete Testbestand und die Grenzwerte hängen von Aufgabe, Daten und möglichen Folgen ab.

Beginne mit dem heutigen Ablauf und einem Vergleichswert

Beschreibe die Aufgabe zuerst in einem Satz:

„Das System erstellt aus einer eingehenden Supportanfrage einen Antwortentwurf. Ein Mitarbeiter prüft und versendet ihn.“

Dieser Satz klärt Eingabe, Ausgabe und Verantwortung. Er begrenzt die Aufgabe auch. Das System darf einen Entwurf erstellen. Es darf keine Reparatur beauftragen und keine sicherheitsrelevante Anweisung ungeprüft verschicken.

Danach beantwortest du fünf Fragen:

1. Welches Problem löst der heutige Ablauf, und wie gut funktioniert er?
2. Welche Daten verarbeitet das neue System?
3. Woran erkennst du ein gutes Ergebnis?
4. Was geschieht bei einem Fehler?
5. Wer ist fachlich und technisch verantwortlich?

Der Vergleichswert des heutigen Ablaufs vor der Änderung heißt Baseline. Erfasse Bearbeitungszeit, fachliche Fehler, Rückfragen, Kundenzufriedenheit, Beschwerden, notwendige Nacharbeit und Kosten. Bei unserem Supportprozess könnte die Baseline beispielsweise zeigen, wie viele Minuten ein Fall braucht und wie oft ein zweiter Mitarbeiter eingreifen muss.

Die KI muss nicht in jeder einzelnen Zahl besser sein. Vielleicht wird die erste Antwort schneller, während die fachliche Prüfung länger dauert. Dann hat sich der Prozess kaum verbessert. Vielleicht sinkt die Bearbeitungszeit deutlich, aber seltene Sicherheitsfälle werden schlechter. Dann ist der Durchschnitt sogar gefährlich beruhigend.

Ein guter erster Anwendungsfall wiederholt sich, lässt sich prüfen und bleibt bei einem Fehler beherrschbar. Eine seltene Aufgabe kann sich ebenfalls lohnen, wenn sie sehr aufwendig ist. Je schwerer du eine Ausgabe prüfen kannst und je größer ihr möglicher Schaden ist, desto strenger müssen Test und Freigabe ausfallen.

Baue typische, schwierige und zurückgehaltene Testfälle

Für die Heizungsfirma könnten 300 frühere, bereinigte Supportfälle den Ausgangspunkt bilden. Wenn 60 Prozent der echten Anfragen Fehlercodes enthalten, sollte dein Testbestand diesen Alltag ungefähr abbilden. Sonst optimierst du vielleicht eine seltene Aufgabe und übersiehst den größten Teil der Arbeit.

Repräsentativ bedeutet hier: Die Fälle ähneln dem vorgesehenen Einsatz. Dazu gehören typische Geräte, Sprachen, Eingabewege und Nutzergruppen. Die genaue Mischung leitest du aus dem Prozess ab. Der Testbestand soll den beschriebenen Zweck ehrlich abdecken und seine Lücken nennen.

Die typischen Fälle heißen Normalfälle. Ergänze sie gezielt um Grenzfälle, also seltene oder schwierige Situationen an den Rändern der Aufgabe:

• eine fehlende oder widersprüchliche Seriennummer
• ein Foto ohne lesbaren Fehlercode
• ein veraltetes Handbuch neben einer gültigen Fassung
• eine Anfrage in einer tatsächlich genutzten weiteren Sprache
• ein Fall, bei dem das System ablehnen oder nachfragen soll
• eine versteckte Anweisung in einem abgerufenen Dokument
• ein früherer Fehler aus dem echten Betrieb

Solche Fälle darfst du künstlich erstellen, wenn es kaum echte Beispiele gibt. Markiere dann, was aus dem Betrieb stammt und was du konstruiert hast. So verwechselst du eine nützliche Angriffssimulation nicht mit der Häufigkeit im Alltag.

Die CheckList-Arbeit übertrug Verhaltensprüfungen aus der Softwareentwicklung auf Sprachaufgaben. Damit fanden Teams neue Fehler in bereits ausgiebig geprüften Systemen. Plane deinen Testbestand deshalb auch nach dem Verhalten, das du gezielt herausfordern willst.

Teile den Bestand vor der Anpassung. Mit einem Arbeitsbestand verbesserst du Prompts, Retrieval und Regeln. Ein anderer Teil bleibt bis zur Freigabe unangetastet. Dieser zurückgehaltene Testbestand heißt Holdout. Er prüft, ob deine Änderungen auch bei Fällen funktionieren, auf die du sie nicht zugeschnitten hast.

Wenn du nach jedem Versuch alle Holdout-Ergebnisse ansiehst und danach weiter änderst, wird der Holdout schleichend zum Arbeitsbestand. Cynthia Dwork und ihre Kollegen untersuchten diese wiederholte Anpassung an Testdaten. Lass deshalb nur wenige Freigabeläufe zu, beschränke den Einblick und ergänze regelmäßig neue Fälle.

Kontamination bedeutet, dass Testfälle oder ihre Lösungen bereits in Training, Beispielen oder Anpassungsdaten stecken. Dann kann ein System bekannte Antworten wiederholen, ohne die Aufgabe auf neuen Fällen zu beherrschen. Bei öffentlichen Benchmarks ist die Herkunft großer Trainingssammlungen oft schwer zu prüfen. Bei deinem eigenen Eval kannst du wenigstens verhindern, dass der Holdout in Promptbeispiele, Feinabstimmung oder interne Anleitungen gelangt.

Miss mehrere Eigenschaften statt nur einen Wert

Ein Gesamtscore ist ein zusammengefasster Wert aus mehreren Messungen. HELM untersucht Sprachmodelle in verschiedenen Anwendungssituationen und misst mehrere Eigenschaften nebeneinander. Dazu gehören Korrektheit, Robustheit, Fairness und Effizienz. So werden Zielkonflikte sichtbar. Für ein Unternehmen übertrage ich dieses Prinzip auf das vollständige System und seinen Arbeitsprozess. Mindestens diese sechs Eigenschaften gehören in die Auswertung:

1. Korrektheit. Stimmen Fakten, Berechnungen, Quellen und Vollständigkeit?
2. Format. Hält die Ausgabe das verlangte Schema und die erlaubte Länge ein?
3. Sicherheit. Lehnt das System verbotene Handlungen ab und schützt es Daten sowie Berechtigungen?
4. Antwortzeit. Wie lange dauert ein Fall, und wie oft ist das System verfügbar?
5. Kosten. Was kosten Modell, Retrieval, Werkzeuge und wiederholte Aufrufe?
6. Prüfaufwand. Wie viele Minuten braucht ein Mensch bis zur Freigabe?

Miss außerdem den Anteil der Aufgaben, die das System vollständig abschließt oder richtig an einen Menschen abgibt. Werte alle Größen für wichtige Fallgruppen getrennt aus. Ein Durchschnitt von 90 Prozent kann eine Erfolgsquote von 98 Prozent bei deutschen Standardfällen und 52 Prozent bei anderssprachigen Rückfragen verdecken. Auch das ist nur ein Rechenbeispiel. Die Gruppen müssen aus deinem vorgesehenen Einsatz stammen.

Ordne Fehler zusätzlich nach ihren Folgen. Vier Fragen helfen dabei:

• Auswirkung: Wie groß wäre der Schaden?
• Wahrscheinlichkeit: Wie häufig kann der Fehler auftreten?
• Erkennbarkeit: Bemerkt ihn jemand vor seiner Wirkung?
• Umkehrbarkeit: Lässt sich die Handlung vollständig zurücknehmen?

Ein System mit 99 Prozent richtigen Antworten kann ungeeignet sein, wenn das verbleibende Prozent zu unzulässigen Zahlungen oder falschen medizinischen Anweisungen führt. Die 99 Prozent sind hier ein Rechenbeispiel und kein gemessener Forschungswert. Risikotoleranz bedeutet, welche verbleibenden Risiken deine Organisation für diesen Zweck trägt. Von ihr, den einzelnen Fehlern und den Kontrollen hängt die Freigabe ab.

Eine interne Ideensammlung verträgt andere Fehler als eine Kreditentscheidung. Ein falscher Entwurf kann oft vor dem Versand korrigiert werden. Eine automatisch ausgelöste Zahlung ist schwerer umkehrbar. Richte Kontrollen deshalb nach der möglichen Folge aus und nicht danach, wie beeindruckend eine Funktion wirkt.

Offene Ausgaben brauchen Bewertungsregeln und Urteile

Bei einer Artikelnummer ist die Prüfung einfach. Entweder stimmt die Nummer oder sie stimmt nicht. Auch Kategorien, Datumswerte und vorgeschriebene Datenformate kannst du oft automatisch vergleichen. Programmcode lässt sich ausführen und mit Tests prüfen.

Ein Antwortentwurf hat dagegen mehrere gute Formen. Der exakte Vergleich mit einem Mustersatz würde korrekte Varianten ablehnen. Dafür brauchst du ein Bewertungsraster, häufig Rubrik genannt. Eine Rubrik beschreibt vor dem Test, welche Eigenschaften zählen und wie Prüfer sie bewerten.

Für die Heizungsantwort könnte sie festlegen:

• Der richtige Fehlercode und die gültige Quelle müssen enthalten sein.
• Fehlende Angaben führen zu einer klaren Rückfrage.
• Sicherheitsanweisungen dürfen nur aus der freigegebenen Quelle stammen.
• Der Text darf keine Reparatur oder Erstattung versprechen.

Gib jeder Regel klare Stufen und möglichst echte Vergleichsfälle. „Gut geschrieben“ ist zu vage. „Nennt Fehlercode, Fundstelle und nächsten erlaubten Schritt“ lässt sich prüfen. Teste das Raster zuerst mit zwei Fachleuten. Wenn sie denselben Fall unterschiedlich bewerten, klärst du die Regel, bevor du 1.000 Ausgaben benotest.

Willst du zwei Systeme vergleichen, kann ein paarweises Urteil leichter sein. Der Prüfer sieht Antwort A und B und wählt die bessere nach derselben Rubrik. Tausche bei einem Teil der Fälle die Reihenfolge. So bemerkst du, ob die erste oder zweite Position das Urteil beeinflusst.

Ein separates Sprachmodell kann ebenfalls als Prüfer dienen. Dieses Verfahren heißt LLM-as-a-Judge, also Sprachmodell als Bewerter. Die MT-Bench-Arbeit verglich solche Modellurteile mit menschlichen Präferenzen. Sie dokumentierte auch Vorlieben für Position, Länge und eigene Modellfamilien. Vergleiche einen solchen Prüfer deshalb mit fachlichen Urteilen auf einem getrennten Bestand. Prüfe seine Fehler je Rubrikpunkt. Bei wichtigen Entscheidungen darf er nicht einfach dieselbe unbelegte Aussage wiederholen wie das erzeugende Modell.

Menschliche Prüfung ist ebenfalls kein automatisch richtiger Maßstab. Fachleute können uneinig oder unaufmerksam sein. Halte deshalb Regeln, Schulungsfälle und Abweichungen fest. Für kritische Fälle sind zwei unabhängige Urteile oder eine gezielte Zweitprüfung oft sinnvoller als eine große Menge hastiger Bewertungen.

Suche Fehlergruppen statt eines schönen Gesamtscores

Nehmen wir an, System B besteht 264 von 300 Fällen. Das sind 88 Prozent. Diese Zahl sagt noch nicht, was du ändern solltest. Öffne die 36 Fehler und bilde Fehlercluster, also Gruppen mit ähnlicher Ursache.

Vielleicht stammen 14 Fehler aus fehlenden Seriennummern. Neun Fälle nutzen das falsche Handbuch. Sechs Antworten scheitern am vorgeschriebenen Datenformat. Vier Fälle betreffen eine bestimmte Sprache. Drei enthalten versteckte Anweisungen, die das Retrieval aus einem Dokument übernommen hat.

Jetzt hilft die Systemkarte aus Kapitel 4. Das Modell kann einen fachlichen Zusammenhang falsch fortsetzen. Der Kontext kann eine wichtige Angabe abschneiden. Das Retrieval kann die alte Anleitung liefern. Ein Werkzeug kann eine Einheit falsch umrechnen. Die Oberfläche kann eine Quellenwarnung verbergen. Eine Kontrolle kann einen unerlaubten Aufruf durchlassen. Die Evaluierung kann eine ganze Fallgruppe vergessen. Menschliche Verantwortung fehlt, wenn niemand diese Fehler annimmt und entscheidet.

Kennzeichne für jeden Fehler beobachtetes Verhalten, mögliche Ursache, Folge und zuständigen Teil. Eine Vermutung bleibt dabei eine Vermutung. Erst ein gezielter Gegentest trennt beispielsweise ein Retrievalproblem von einem Modellproblem. Gib dem Modell einmal den richtigen Abschnitt direkt im Kontext. Wird die Antwort dann korrekt, liegt der nächste Prüfpunkt beim Retrieval.

Ein Fehlercluster führt zu einer Änderung und zu neuen Tests. Frühere Fehler bleiben dauerhaft im Arbeitsbestand. Neue Vorfälle aus dem Betrieb kommen hinzu. Der Holdout bleibt davon getrennt, bis du ihn planmäßig erneuerst.

So wird aus 88 Prozent eine Arbeitsliste. Ein einzelner Wert sortiert Systeme. Die Fehleranalyse zeigt dir, was du am Prozess ändern solltest.

Entscheide mit den Kosten pro akzeptablem Ergebnis

Ein billiger Modellaufruf kann einen teuren Prozess erzeugen. Vielleicht braucht der Mitarbeiter danach fünf Minuten, um Quellen zu suchen und das Format zu reparieren. Ein teurerer Aufruf mit gutem Retrieval kann am Ende weniger kosten.

Definiere zuerst ein akzeptables Ergebnis. Es erfüllt alle zwingenden Regeln für Korrektheit, Format und Sicherheit. Danach berechnest du eine praktische Betriebskennzahl für diesen Prozess:

Gesamtkosten des geprüften Ablaufs geteilt durch die Zahl akzeptabler Ergebnisse.

Zu den Gesamtkosten gehören Modellaufrufe, Retrieval, Werkzeuge, Wiederholungen und menschliche Prüfzeit. Für eine Pilotentscheidung kannst du auch Einrichtung und laufende Überwachung getrennt ausweisen. Vermische einmalige Projektkosten nicht unbemerkt mit jedem späteren Fall.

Nehmen wir 1.000 Supportfälle an. System A kostet 70 Euro für technische Nutzung. Die Prüfung braucht 90 Stunden zu je 40 Euro. Insgesamt sind das 3.670 Euro. 760 Ergebnisse erfüllen alle Regeln. Ein akzeptables Ergebnis kostet damit 4,83 Euro.

System B kostet technisch 180 Euro. Die Prüfung braucht 45 Stunden. Insgesamt sind das 1.980 Euro. 820 Ergebnisse sind akzeptabel. Damit kostet ein akzeptables Ergebnis 2,41 Euro. Das technisch teurere System ist im ganzen Prozess günstiger.

Vergleiche beide Werte mit der Baseline des heutigen Ablaufs. Berücksichtige auch Fälle, die das System korrekt an einen Menschen abgibt. Eine gute Rückfrage oder eine sichere Ablehnung kann ein akzeptables Ergebnis sein, wenn du das vorher so definiert hast.

Senke nie erst die Qualitätsgrenze, damit die Kosten schön aussehen. Lege zwingende Regeln vor dem Vergleich fest. Optimiere danach unter den Systemen, die diese Regeln bestehen.

Feste Freigabebedingungen für das geprüfte System

Ein Release-Gate ist eine festgelegte Bedingung, die eine Freigabe erlaubt oder stoppt. Damit wird aus dem Eval eine betriebliche Entscheidung. NIST beschreibt dafür ausdrücklich dokumentierte Freigabeentscheidungen und Prüfungen unter einsatzähnlichen Bedingungen.

Für unseren Supportassistenten könnte eine Organisation folgende Bedingungen wählen:

• kein beobachteter unerlaubter Werkzeugaufruf im Sicherheitsbestand
• mindestens 95 Prozent fachlich akzeptable Antworten im repräsentativen Holdout
• 100 Prozent gültiges Ausgabeformat vor der Übergabe an das Ticketsystem
• höchstens zwei Minuten mittlere menschliche Prüfzeit
• höchstens 3 Euro pro akzeptablem Ergebnis

Diese Zahlen sind ein Beispiel. Sie sind keine allgemeine Empfehlung. Auch „kein beobachteter Fehler“ beweist bei einem kleinen Test nicht, dass der Fehler unmöglich ist. Dokumentiere daher Fallzahl, Testgrenzen und verbleibendes Risiko.

Die Freigabe braucht benannte Verantwortliche. Eine mögliche Aufteilung sieht so aus:

• Der fachliche Prozessverantwortliche definiert Aufgabe, akzeptable Ergebnisse und Folgen eines Fehlers.
• Der technische Verantwortliche versioniert Modell, Kontext, Retrieval, Werkzeuge und Oberfläche.
• Der Testverantwortliche pflegt Fälle, Rubriken, Holdout und Auswertung.
• Zuständige für Sicherheit, Datenschutz oder Recht prüfen die für den Einsatz relevanten Grenzen.
• Eine benannte Freigabestelle trifft die Entscheidung über Start, Stopp oder Rückkehr zum bisherigen Ablauf.

Das ist ein Vorschlag für die Prüfung und ihre Freigabeentscheidung. In einem kleinen Team können mehrere Rollen bei derselben Person liegen. Die Entscheidungen und Prüfpflichten sollten trotzdem sichtbar bleiben.

Führe die Freigabetests erneut aus, wenn sich Modell, Prompts, Datenquellen, Retrieval, Werkzeuge, Berechtigungen oder Oberfläche ändern. Kapitel 18 erklärt, wie die Organisation freigegebene Systeme überwacht, Vorfälle behandelt und bei Bedarf auf einen früheren Ablauf zurückgeht.

Aus Messwerten werden Handlungsgrenzen

Nimm einen geplanten oder bestehenden KI-Prozess in deiner Firma. Beantworte dazu diese Fragen:

1. Welches vollständige System prüfst du, und wie hältst du seine Version fest?
2. Wie funktioniert der heutige Ablauf, und welche Baseline misst du?
3. Welche Normalfälle und Grenzfälle bilden den echten Einsatz ab?
4. Welcher Bestand bleibt als Holdout von Anpassungen getrennt?
5. Wie verhinderst oder dokumentierst du Kontamination?
6. Wie misst du Korrektheit, Format, Sicherheit, Antwortzeit, Kosten und Prüfaufwand?
7. Welche Rubrik und welche menschlichen Urteile braucht eine offene Ausgabe?
8. Welche Fehlercluster liegen hinter dem Gesamtscore?
9. Was kostet ein akzeptables Ergebnis im Vergleich zum heutigen Prozess?
10. Welche Release-Gates gelten, und wer darf freigeben oder stoppen?

Kapitel 17 ergänzt Agenten. Sie rufen Werkzeuge auf, beobachten Ergebnisse und entscheiden über weitere Schritte. Damit wird aus einer Antwort eine Folge von Handlungen. Die Begriffe dieses Kapitels bleiben gleich. Testfälle müssen dann zusätzlich Werkzeugwahl, Berechtigungen, Zwischenzustände, Abbruchregeln und die gesamte Handlungskette prüfen.