KI-Qualität messen: Testset, Freigabegrenzen und Monitoring im Betrieb
Von Kevin Kröger, Geschäftsführer, Software und PlattformbetriebKI-Qualität wird nicht mit einzelnen überzeugenden Antworten bewertet. Ein belastbarer Nachweis braucht ein versioniertes Testset aus echten Fachfällen, klare Bewertungskriterien, gesonderte Grenzen für kritische Fehler, dokumentierte Modell- und Promptstände sowie eine laufende Überwachung im Betrieb. Erst wenn Qualität, Kosten und Fehlerfolgen gemeinsam sichtbar sind, kann ein KI-System verantwortet werden.
Warum reicht eine gute Demo nicht aus?
Eine Demo zeigt meistens bekannte, gut vorbereitete Fälle. Im Alltag treffen unvollständige Eingaben, widersprüchliche Dokumente, neue Begriffe und seltene Ausnahmen auf das System. Deshalb beginnt die Bewertung mit einer Liste realer Aufgaben und der Frage, welche Fehler jeweils entstehen können. Ein falscher Formulierungsvorschlag hat eine andere Wirkung als eine erfundene Freigabe, eine übersehene Vertragsklausel oder eine unzulässige Datenweitergabe. Der NIST AI RMF verbindet die Bewertung von KI ausdrücklich mit Kontext, Messung und laufender Behandlung von Risiken.
Wie wird ein repräsentatives Testset aufgebaut?
Sammelt normale Vorgänge, schwierige Grenzfälle, veraltete Informationen, absichtlich missverständliche Fragen und Fälle, bei denen das System sicher ablehnen soll. Jeder Fall erhält eine erwartete Eigenschaft statt nur einen Mustersatz. Bewertet etwa fachliche Richtigkeit, Vollständigkeit, Quellenbezug, zulässige Datenverwendung und hilfreiche Unsicherheit. Das Testset wird versioniert, von Fachverantwortlichen geprüft und darf nicht still in die Entwicklung einfließen. Sonst optimiert das Team auf bekannte Prüfungen und überschätzt die spätere Qualität.
Welche Qualitätsgrenzen braucht der Betrieb?
Ein Durchschnittswert verschleiert seltene, aber schwere Fehler. Definiert deshalb mindestens eine Gesamtgrenze und gesonderte Null- oder Niedriggrenzen für kritische Ereignisse. Legt fest, wann eine Antwort automatisch verwendet werden darf, wann eine Person prüfen muss und wann das System abbrechen soll. Diese Entscheidung gehört zum Prozessdesign und nicht allein zum Modell. Dokumentiert außerdem, wer eine neue Modellversion freigibt und welche Nachweise dafür vorliegen müssen.
Was muss nach dem Go-live überwacht werden?
Beobachtet Antwortqualität an Stichproben, Ablehnungsquote, notwendige Korrekturen, Antwortzeit, Kosten je Vorgang und sicherheitsrelevante Ereignisse. Erfasst Modell, Systemanweisung, Wissensstand und relevante Konfiguration je Ausgabe, ohne unnötig vertrauliche Inhalte zu protokollieren. Nutzerfeedback ist ein Signal, aber kein Wahrheitsbeweis. Änderungen an Quellen, Rollen, Modellen oder Werkzeugen lösen gezielte Regressionstests aus. So wird Monitoring zu einem fachlichen Regelkreis statt zu einem reinen Infrastruktur-Dashboard.
Wie wird eine Verschlechterung behandelt?
Für Qualitätsabfälle braucht es denselben Ernst wie für technische Störungen. Definiert Warnschwellen, Verantwortliche, einen Rückweg auf den letzten geprüften Stand und eine Möglichkeit, automatische Aktionen zu stoppen. Trennt die Ursachenanalyse in Modell, Daten, Abruf, Prompt, Berechtigung und Prozess. Ein schneller Modellwechsel kann das Problem verschieben, wenn die eigentliche Ursache eine veraltete Wissensquelle oder ein unklarer Arbeitsauftrag ist. Nach der Korrektur wird das betroffene Muster in das Testset aufgenommen.
Quellen und Grundlage
Zentrale Aussagen dieses Beitrags wurden anhand der folgenden Primärquellen geprüft.
Häufige Fragen
- Wie groß muss ein KI-Testset sein?
- Es gibt keine allgemeine Mindestzahl. Entscheidend sind Abdeckung der wichtigen Aufgaben, kritischen Fehlerfolgen, Nutzergruppen und realen Ausnahmen sowie eine ausreichende Wiederholbarkeit.
- Kann eine automatische Kennzahl die Fachprüfung ersetzen?
- Nein. Automatische Bewertungen helfen bei Wiederholungen, müssen aber selbst gegen fachliche Urteile geprüft werden. Kritische Fälle brauchen nachvollziehbare menschliche Bewertung.
- Wann muss neu getestet werden?
- Bei Änderungen an Modell, Prompt, Wissensbasis, Rollen, Werkzeugen oder Prozess sowie regelmäßig anhand aktueller Produktionsfälle.
