Ein szenariobasiertes Evaluierungsset für betriebliche KI aufbauen

Ein brauchbares Evaluierungsset beginnt nicht mit einer Sammlung besonders raffinierter Prompts, sondern mit einem klar begrenzten Arbeitsablauf. Man stelle sich einen internen Assistenten für Einkaufsanträge vor: Der Antrag wirkt plausibel, doch die Lieferantennummer widerspricht dem Angebot, die aktuelle Richtlinie lässt sich nicht abrufen und im hochgeladenen Dokument steckt eine Anweisung an das System. Erst ein reproduzierbarer Fall zeigt, ob der Assistent fehlende Evidenz erkennt, keine Genehmigung erfindet und korrekt an eine befugte Person übergibt. Damit Ergebnisse tatsächlich eine Freigabeentscheidung unterstützen, müssen Abdeckung, Fälle, Bewertungsregeln, Sperrkriterien und Datensplits feststehen, bevor die Ausgaben des bevorzugten Systems bekannt sind.

Was muss ein szenariobasiertes Evaluierungsset abdecken?

Ein szenariobasiertes Set muss den gewöhnlichen Arbeitsmix und jene seltenen Situationen abdecken, in denen ein Fehler besonders viel ausmacht. Der Ausgangspunkt ist eine Abdeckungskarte für genau eine Systemversion und einen begrenzten Workflow: erlaubte Rollen, Eingabearten, Wissensquellen, Werkzeuge, Berechtigungen sowie die nachgelagerte Entscheidung. Aufgabenfamilien und relevante Varianten lassen sich aus autorisierten Arbeitsunterlagen, Supportfällen, Nutzerforschung, Vorfallsdaten und fachlichen Begehungen ableiten. Fehlen verlässliche Betriebsdaten, wird die angenommene Verteilung ausdrücklich als Unsicherheit oder Vorab-Hypothese dokumentiert.

Für die praktische Arbeit eignet sich eine anpassbare Karte mit vier Abdeckungsfamilien. Sie verbindet realitätsnahe Verteilungen mit gezielter Risikoprüfung, ist aber keine von einer einzelnen Quelle vorgeschriebene Taxonomie. Häufige Alltagsfälle dürfen entsprechend dem beobachteten Arbeitsmix stärker vertreten sein. Seltene, folgenreiche Grenzen und verbotene Ergebnisse werden dagegen bewusst ergänzt. Bei Verhaltensgrenzen gehören beide Seiten in das Set: Fälle, in denen der Assistent handeln soll, und ähnliche Fälle, in denen er nachfragen, sich enthalten, verweigern oder eskalieren muss.

Beim Einkaufsassistenten umfasst die Karte etwa vollständige Anträge, fehlende Beilagen, widersprüchliche Beträge oder Lieferantendaten, nicht belegbare nächste Schritte, den Versuch einer Genehmigungsumgehung, Anweisungen in hochgeladenen Angeboten und einen ausgefallenen Richtlinienabruf. Ein bestätigter früherer Fehler wird mit minimierten oder synthetischen, sorgfältig geprüften Daten nachgebaut. Produktionsunterlagen sind weder automatisch vollständig noch automatisch zur Wiederverwendung geeignet. Persönliche, vertrauliche, lizenzierte oder sicherheitsrelevante Inhalte benötigen die passende Berechtigung, Zugriffskontrolle und Datenminimierung. Die Regeln des Beispiels bleiben organisationsspezifisch.

Wie wird jedes Evaluierungsszenario reproduzierbar erfasst?

Jedes Szenario wird als versionierter Falldatensatz erfasst, der einer anderen prüfenden Person den Aufbau und die Bewertung ermöglicht. Dazu gehören eine stabile Fall-ID, Eigentümer, Änderungsverlauf, Aufgaben- und Abdeckungsfamilie, relevante Teilgruppen, Konsequenz, Provenienzkategorie, Nutzungsberechtigung und die vorgesehene Zuordnung zum Entwicklungs- oder geschützten Freigabeset. Der Datensatz beschreibt außerdem Rolle und Ziel der handelnden Person, den anfänglichen Workflow-Zustand, Anfragen und Dateien, relevante Vorgeschichte, Systemanweisungen, zulässiges Wissen, Werkzeuge, Berechtigungen, Werkzeugergebnisse und sonstige Testbedingungen.

• Erwartungen: erforderliche Fakten, Ergebnisse oder Zustandsänderungen sowie zulässige alternative Formulierungen und Lösungswege.
• Grenzen: Situationen, die Rückfrage, Enthaltung, Verweigerung oder Eskalation verlangen, getrennt von allgemeinen Qualitätsmerkmalen.
• Verbote: unzulässige Ausgaben, Offenlegungen, Werkzeugaufrufe, Aktionen oder Zustandsänderungen als eigene prüfbare Felder.
• Betrieb: Grader, Raster, Sperrkriterien, Referenzlösung, allfällige Versuchszahl und vorab definierte Aggregationsregel.
• Versionen: Modell, Prompt, Retrieval-Bestand, Werkzeuge, Richtlinie, Berechtigungen und Evaluierungsharness sowie Reviewer- und Klärungsweg.

Bei einer offenen Aufgabe ist eine Musterantwort nicht automatisch das einzig richtige Ergebnis. Sinnvoller ist es, erforderliche Fakten und Zustände von akzeptablen Varianten zu trennen. Eine bekannte funktionierende Referenzlösung kann belegen, dass der Fall lösbar ist, und Fehler im Grader sichtbar machen. Für nichtdeterministische oder mehrstufige Systeme werden die nötigen Wiederholungen und deren Zusammenfassung vor der Ausgabeprüfung festgelegt. Auch bekannte Einschränkungen, ungelöste Meinungsverschiedenheiten und die Qualifikation der Bewertenden gehören in den Datensatz, damit spätere Ergebnisse nachvollziehbar bleiben.

Ein guter Evaluierungsfall stellt nicht nur eine schwierige Frage: Er macht Arbeit, zulässige Varianten und verbotene Handlungen überprüfbar.

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

Ein Szenario wird mit der engsten Methode bewertet, die Erfolg und Fehler noch valide unterscheiden kann. Deterministische Prüfungen passen zu objektiv kontrollierbaren Antworten, Schemas, Berechnungen, Werkzeugargumenten, Datensatzständen und verbotenen Aktionen. Referenzfakten oder eine Referenzlösung passen, wenn mehrere Wege möglich, die erforderliche Evidenz oder der Endzustand aber begrenzt sind. Für offene Qualitäten wie Nützlichkeit, Vollständigkeit oder Begründungsqualität braucht es getrennte, beobachtbar verankerte Dimensionen. Modellbasierte Grader werden dabei gegen qualifizierte menschliche Urteile im relevanten Kontext kalibriert, nicht bloß gegen vertraute Entwicklungsbeispiele.

• Deterministische Prüfung: präzise bei überprüfbaren Zuständen, aber nur so gut wie Vollständigkeit und Richtigkeit der implementierten Regel.
• Referenzevidenz: bewertet notwendige Fakten oder Ergebnisse, ohne eine einzige Wortfolge oder einen zufälligen Ausführungspfad zu erzwingen.
• Verankertes Raster: trennt offene Qualitätsdimensionen und beschreibt für jede Stufe beobachtbare positive, negative und grenzwertige Merkmale.
• Fachliches Urteil: bleibt nötig, wenn Kontext oder Folgen durch automatisierte Prüfungen nicht valide aufgelöst werden können.

Teilpunkte sind dort sinnvoll, wo Komponenten einen echten Arbeitsfortschritt darstellen; zugleich muss sichtbar bleiben, welcher Teil gescheitert ist. Eine unzulässige Offenlegung, Genehmigung oder Werkzeugaktion darf ein sprachlich ausgezeichneter Rest nicht ausgleichen. Verantwortliche Produkt- und Risikoverantwortliche definieren solche Sperrkriterien und ihre Freigabefolge vor dem Vergleich der Ausgaben. Ebenso werden Rasterversion, Teilgruppen, Aggregation mehrerer Versuche und Entscheidungsregel vorab fixiert. Jede nachträgliche Änderung erzeugt eine neue Evaluierungsversion, statt das frühere Ergebnis still umzudeuten.

Wie wenden Reviewer die Kriterien konsistent an?

Reviewer arbeiten konsistenter, wenn sie vor jeder Ausgabe denselben klaren Kontext und beobachtbare Bewertungsanker erhalten. Der Leitfaden nennt Zweck des Workflows, Rolle der handelnden Person, verfügbare Evidenz, erlaubtes Verhalten, Produktgrenze und Rasterversion. Für jede Bewertungsstufe enthält er positive, negative und grenzwertige Beispiele. Eine eigene Option für „nicht bewertbar“ oder „unzureichende Evidenz“ verhindert, dass ein defekter Fall als Systemfehler verbucht wird. Kalibrierungsfälle werden vor dem Live-Review eingesetzt und nach Änderungen an Aufgabenmix, Richtlinie, Raster oder Reviewer-Gruppe wiederholt.

• Systemidentität und Ausgabereihenfolge werden bei vergleichenden Urteilen soweit praktikabel verblindet.
• Bewertende halten Urteil und Begründung unabhängig fest, bevor eine gemeinsame Diskussion beginnt.
• Abweichungen werden auf fehlenden Kontext, unklare Schwellen, defekte Fälle, legitime Alternativen oder offene Produktentscheidungen untersucht.
• Eine benannte zuständige Person klärt echte Bewertungsfragen; legitime Unterschiede werden nicht in einen Scheinkonsens gezwungen.
• Labels, Begründungen, Rasterversionen und Klärungsergebnisse bleiben für spätere Reviews und Grader-Kalibrierungen erhalten.

Wie bleibt das Evaluierungsset während Entwicklung und Freigabe brauchbar?

Das Set bleibt brauchbar, wenn sichtbare Entwicklungsfälle und geschützte Freigabeevidenz unterschiedliche Aufgaben erfüllen. Das Entwicklungsteam darf sein Set wiederholt für Änderungen an Prompt, Retrieval, Werkzeugen, Richtlinien und Workflow nutzen. Der resultierende Wert ist jedoch Entwicklungsevidenz, weil gegen bekannte Fälle optimiert wurde. Ein separates, zugriffsgeschütztes Set dient sparsamen Schlussvergleichen oder Freigabeentscheidungen. Seine Zuordnung erfolgt beim Eintrag ins Register und vor routinemäßiger Ausführung oder Ergebnisprüfung. Eine universelle Fallzahl oder fixe prozentuelle Aufteilung lässt sich daraus nicht ableiten.

Zwischen den Sets werden exakte Dubletten, nahe Varianten, gemeinsame Ursprungsunterlagen, Paraphrasen und Geschwister desselben Szenario-Templates gesucht. Zugriffe auf Fallinhalte, Referenzantworten, Raster und Ergebnisse werden protokolliert. Hat ein geschützter Fall eine Diagnose oder Änderung wesentlich beeinflusst, wandert er in die Entwicklungs- oder Regressionsevidenz. Die gleiche Fehlerklasse darf im geschützten Set weiterhin vorkommen, aber nur in einem unabhängig erstellten, nicht duplizierten Ersatzfall, der die konkrete Verbesserung noch nicht gelenkt hat.

• Das Register führt Zuständigkeit, Provenienz, Berechtigung, Split, Exposition, Version, Review-Verlauf sowie Änderungs- und Ausmusterungsgrund.
• Bestätigte Vorfälle werden erst nach fachlicher Prüfung und Minimierung sensibler Inhalte als Regression aufgenommen.
• Fallinhalt, Labels, Raster, Richtliniengrundlage und Harness werden gemeinsam versioniert; frühere Ergebnisse werden nicht still überschrieben.
• Die Abdeckung wird nach wesentlichen Änderungen an Workflow, Nutzerkreis, Wissen, Modell, Prompt, Werkzeugen, Berechtigungen oder Betriebsumgebung neu geprüft.

Berichtet wird nicht nur ein Gesamtwert, sondern nach Aufgabenfamilie, Abdeckungsfamilie, relevanter Teilgruppe, Konsequenz und Sperrkriterium. So bleibt sichtbar, ob ein scheinbar gutes Mittel einzelne folgenschwere Fehler verdeckt. Das Register ersetzt dabei keine fachliche Kontrolle: Zuständige Personen prüfen veraltete Referenzen, falsche Labels, mehrdeutige Aufgaben, unerreichbare Zielzustände und Grader, die gültige Alternativen zurückweisen. Ein Set darf mit verifizierten Fällen aus mehreren zulässigen Quellen wachsen, doch jede Ergänzung braucht dokumentierte Provenienz, erwartetes Verhalten und einen nachvollziehbaren Grund.

Ein bestandener Offline-Test ist Entscheidungsevidenz, aber kein Zertifikat für Geschäftswert, Sicherheit, Fairness, Compliance oder Produktionsreife. Produkt- und Risikoverantwortliche legen die folgenbezogenen Gates und den Verwendungszweck fest; Fachleute validieren Arbeitsrealität und erwartete Ergebnisse. Datenschutz, Informationssicherheit, Recht, Compliance oder andere zuständige Funktionen werden einbezogen, sobald ihre geregelten Inhalte oder Beurteilungen betroffen sind. Rechtliche, medizinische, finanzielle, beschäftigungsbezogene, sicherheitskritische und andere regulierte Entscheidungen bleiben bei qualifizierten und autorisierten Personen. Ergänzend braucht es je nach System Produktionsmonitoring, Nutzerforschung, Vorfallsanalyse und weitere passende Evidenz.