Ein szenariobasiertes Evaluationsset für ein Business-KI-System aufbauen

Ein belastbares Evaluationsset beginnt nicht mit einer Sammlung eleganter Prompts, sondern mit einem klar begrenzten Arbeitsablauf. Angenommen, ein interner Assistent prüft Einkaufsanträge: Eine Mappe enthält einen plausiblen Antrag, widersprüchliche Lieferantenangaben, einen fehlgeschlagenen Richtlinienabruf und eine Offerte mit eingebetteten Anweisungen an das System. Erst ein reproduzierbares Szenario zeigt, ob der Assistent die fehlende Evidenz erkennt, seine Befugnisse respektiert und den richtigen nächsten Schritt vorbereitet.

Dafür braucht das Team drei miteinander verbundene Arbeitsmittel: eine Abdeckungskarte für normale und kritische Situationen, einen vollständigen Falldatensatz mit zulässigen und verbotenen Ergebnissen sowie ein versioniertes Register für Entwicklung und Release. Slices, Bewertungsregeln und Gates werden festgelegt, bevor Resultate sichtbar sind. Sonst kann ein überzeugender Durchschnitt genau jene Fehler verdecken, die für den Einsatzentscheid ausschlaggebend wären.

Was muss ein szenariobasiertes Evaluationsset abdecken?

Ein szenariobasiertes Set muss den erwarteten Arbeitsmix abbilden und zugleich seltene, aber wesentliche Grenzen bewusst einschliessen. Ausgangspunkt ist genau eine Systemversion in einem begrenzten Workflow: Wer darf sie nutzen, welche Eingaben sind zulässig, welches Wissen und welche Werkzeuge stehen bereit, und welchen Entscheid soll die Evaluation unterstützen? Realistische, klar definierte Fälle und dokumentierte Methoden sind die Grundlage für eine Messung, die mehr aussagt als eine Demo.

Erstellen Sie danach eine Abdeckungskarte aus autorisierten Arbeitsunterlagen, Supportfällen, Nutzerforschung, Vorfällen und Walkthroughs mit Fachpersonen. Produktionsdaten sind weder automatisch repräsentativ noch ohne Weiteres wiederverwendbar; synthetische Fälle sind umgekehrt nicht automatisch minderwertig. Halten Sie fest, wo die Datengrundlage lückenhaft ist. Bei einem neuen System darf der erwartete Arbeitsmix ausdrücklich eine überprüfbare Hypothese sein, statt eine scheinpräzise Verteilung vorzutäuschen.

Diese vier Familien sind eine redaktionelle Synthese, keine verbindliche Taxonomie. Beim Einkaufsassistenten umfassen sie vollständige Anträge, fehlende Belege, widersprüchliche Beträge oder Lieferantenkennungen, ungenügende Evidenz, Umgehungsversuche, Anweisungen in Uploads und unzuverlässige Richtlinienabfragen. Die konkreten Verbote bleiben organisationsspezifisch. Definieren Sie vor der Ausführung, nach welchen Aufgaben, Rollen, Folgen und Grenzen Resultate aufgeschlüsselt werden und welche Gate-Verletzung einen Release stoppt.

Wie wird jedes Evaluationsszenario reproduzierbar erfasst?

Jedes Szenario wird als Falldatensatz erfasst, mit dem eine andere prüfende Person dieselbe Ausgangslage wiederherstellen und zulässige von unzulässigen Ergebnissen unterscheiden kann. Der Datensatz erhält eine stabile ID, Eigentümerschaft, Versionsgeschichte, Abdeckungs- und Aufgabenfamilie, Slice-Tags, Konsequenz, Herkunft, Berechtigungsnachweis und vorgesehenen Split. Diese Felder sind ein anpassbares Arbeitsmodell und keine von einer einzelnen Quelle vorgeschriebene Norm.

• Akteur, Ziel, anfänglicher Workflow- und Systemzustand
• Anfrage, Dateien, relevante Vorgeschichte und zulässige Variation
• Autorisiertes Wissen, Werkzeuge, Berechtigungen, Werkzeugresultate und Umgebungsbedingungen
• Erforderliche Fakten, Zustandsänderungen und akzeptable alternative Wege
• Pflicht zur Rückfrage, Enthaltung, Ablehnung oder Eskalation bei fehlender Evidenz
• Verbotene Ausgaben, Offenlegungen, Werkzeugaufrufe, Handlungen und Zustandsänderungen
• Grader, Raster, Gates, Referenzlösung, Versuche und vorab bestimmte Aggregationsregel
• Versionen von Modell, Prompt, Wissensbestand, Werkzeugen, Richtlinie und Test-Harness

Eine funktionierende Referenzlösung kann belegen, dass ein begrenzter Fall lösbar ist, und Fehler im Grader aufdecken. Sie ist aber nicht automatisch die einzig akzeptable Formulierung oder Prozessfolge. Bei offenen Aufgaben braucht der Fall deshalb erforderliche Fakten und Endzustände ebenso wie zulässige Alternativen. Wenn Zufall oder ein mehrstufiger Ablauf relevant ist, werden Zahl der Versuche, Aggregation, Qualifikation der Prüfenden und Eskalationsweg vor der Sichtung von Ausgaben festgelegt.

Ein guter Evaluationsfall stellt nicht nur eine schwierige Frage; er macht Arbeit, Erfolg, zulässige Varianten und verbotene Handlungen überprüfbar.

Wie lässt sich ein Szenario bewerten, ohne falsches Verhalten zu belohnen?

Wählen Sie für jeden Fall die engste Bewertungsmethode, die Erfolg und Misserfolg valide unterscheiden kann. Deterministische Prüfungen passen zu objektiv feststellbaren Fakten, Schemas, Berechnungen, Werkzeugargumenten, Zuständen und verbotenen Aktionen. Referenzfakten oder eine Referenzlösung eignen sich, wenn das Ziel begrenzt ist, aber mehrere Formulierungen oder Wege gelten. Ein präziser Check kann trotzdem unvollständig sein oder unbeabsichtigte Abkürzungen belohnen und muss deshalb selbst geprüft werden.

• Deterministischer Check für objektive Resultate, Zustände und Verbote
• Referenzfakten für begrenzte Inhalte mit mehreren gültigen Formulierungen
• Beobachtbar verankertes Raster für offene Qualitäten wie Vollständigkeit oder Nützlichkeit
• Qualifiziertes Fachurteil, wenn Bedeutung oder Folgen nicht automatisiert geklärt werden können
• Getrenntes Gate für Offenlegungen oder Aktionen, die ausdrücklich untersagt sind

Für offene Qualität braucht jede Dimension beobachtbare Anker und Beispiele. Ein modellbasierter Grader ist nicht allein deshalb geeignet, weil er auf bekannten Entwicklungsfällen mit Menschen übereinstimmt; er muss im relevanten Kontext gegen qualifizierte Urteile kalibriert werden. OpenAI berichtet etwa, dass der automatisierte GDPval-Grader erfahrene Fachprüfende nicht zuverlässig ersetzte. Teilpunkte sind für sinnvolle Komponenten möglich, doch ein verbotenes Resultat bleibt ein vorab definiertes, nicht kompensierbares Gate.

Wie wenden Prüfende die Kriterien konsistent an?

Prüfende arbeiten konsistenter, wenn sie vor der Ausgabe denselben Workflowkontext, dieselbe Evidenz, dieselben Systemgrenzen und dieselbe Rasterversion erhalten. Jeder Bewertungsanker beschreibt beobachtbares Verhalten statt unbestimmter Eindrücke. Positive, negative und grenzwertige Beispiele zeigen, wie die Kriterien angewendet werden. Zusätzlich braucht es die Option «nicht bewertbar», falls ein Fall widersprüchlich, unlösbar oder unvollständig ist; ein defekter Fall darf nicht als Systemfehler verbucht werden.

1. Kalibrierungsfälle vor der eigentlichen Prüfung gemeinsam beurteilen.
2. Bei Vergleichsurteilen Systemidentität und Reihenfolge wenn praktikabel verblinden.
3. Einzelurteile und Begründungen vor jeder Diskussion separat erfassen.
4. Abweichungen auf Fall, Schwelle, Kontext oder legitime Vielfalt untersuchen.
5. Eine zuständige Person für Korrektur und fachliche Adjudikation benennen.
6. Labels, Begründungen, Rasterversion und Entscheid dauerhaft speichern.

Kalibrierung ist erneut nötig, wenn sich Aufgabenmix, Richtlinie, Raster oder Kreis der Prüfenden wesentlich verändert. Eine Abweichung ist dabei kein Ärgernis, das möglichst schnell verschwinden soll. Sie kann auf eine unklare Schwelle, fehlenden Kontext, einen schlechten Grader, mehrere gleichwertige Lösungen oder einen noch offenen Produktentscheid hinweisen. Erst die Diagnose entscheidet, ob der Fall korrigiert, das Raster präzisiert oder eine autorisierte fachliche Entscheidung eingeholt werden muss.

Wie bleibt das Evaluationsset während Entwicklung und Release aussagekräftig?

Das Set bleibt aussagekräftig, wenn sichtbare Entwicklungsfälle und geschützte Release-Evidenz getrennte Rollen behalten. Das Entwicklungsteam darf sein Set wiederholt für Prompt-, Retrieval-, Werkzeug-, Richtlinien- und Workflowänderungen verwenden. Dessen Resultate sind jedoch Entwicklungsevidenz, weil das System an bekannten Fällen optimiert wurde. Der geschützte Test wird vor routinemässiger Ausführung zugeteilt, sparsam für Vergleiche oder Release-Entscheide eingesetzt und eng gegen Einsicht kontrolliert.

Prüfen Sie splitübergreifend auf exakte und ähnliche Duplikate, gemeinsame Quelldatensätze, Paraphrasen und Geschwister aus derselben Szenariovorlage. Erfassen Sie Zugriffe auf Fälle, Referenzantworten, Raster und Resultate. Hat ein geschützter Fall Diagnose oder Änderung materiell beeinflusst, gehört er danach in die Entwicklungs- oder Regressionssammlung. Die geschützte Abdeckung derselben Fehlerklasse braucht einen unabhängig erstellten, nicht duplizierten Ersatz in einer neuen Version.

• Eigentümerschaft, Herkunft, Berechtigung und Split jedes Falls
• Exposition von Fallinhalt, Referenz, Raster und Ergebnis
• Versionen von Fall, Label, Richtlinie, System und Harness
• Reviewverlauf, begründete Änderungen und ungelöste Abweichungen
• Grund für Ersatz, Aktualisierung oder Pensionierung
• Resultate nach Aufgabe, Fallfamilie, Slice, Folge und Gate

Überprüfen Sie die Abdeckung neu, wenn sich Nutzerkreis, Workflow, Richtlinie, Wissensbestand, Modell, Prompt, Werkzeuge, Berechtigungen oder Betriebsumgebung wesentlich ändern. Verifizierte Fehler können nach Autorisierung und Datenminimierung ergänzt werden; vertrauliche oder regulierte Produktionsinhalte werden nicht einfach kopiert. Es gibt weder eine allgemeingültige Splitquote noch eine feste Erneuerungsfrist. Ein Register schafft Nachvollziehbarkeit, garantiert aber nicht, dass ein bereits exponierter Test weiterhin unabhängig ist.

Behandeln Sie das Set als Entscheidungsevidenz, nicht als Zertifikat. Produkt- und Risikoverantwortliche definieren Folgen und Release-Gates, Fachpersonen prüfen Realitätsnähe und erwartete Ergebnisse. Wo Datenschutz, Sicherheit, Recht, Finanzen, Medizin, Beschäftigung oder andere regulierte Bereiche berührt sind, bleiben die entsprechenden Entscheide bei qualifizierten und autorisierten Personen. Ein Offline-Pass beweist allein weder Geschäftswert noch Sicherheit, Fairness, Compliance oder Produktionsreife; dazu gehören auch Monitoring, Nutzerforschung und die Auswertung von Vorfällen.