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

Ein belastbares Evaluationsset beginnt nicht mit einer Sammlung besonders raffinierter Prompts, sondern mit einem klar begrenzten Arbeitsablauf. Man stelle sich einen internen Assistenten für Beschaffungsanträge vor: Eine Mappe enthält einen plausiblen Antrag, eine widersprüchliche Lieferantennummer, ein nicht erreichbares Richtliniendokument und ein Angebot mit versteckten Anweisungen an das System. Erst ein reproduzierbarer Fall zeigt, ob der Assistent fehlende Evidenz offenlegt, unerlaubte Anweisungen ignoriert und an die richtige menschliche Stelle übergibt. Ein glänzender Durchschnittswert über bequeme Musterfälle könnte genau diese entscheidenden Fehler verdecken.

Was muss ein szenariobasiertes Evaluationsset abdecken?

Ein szenariobasiertes Set muss den gewöhnlichen Arbeitsmix und zugleich jene seltenen Situationen abdecken, in denen Grenzen, frühere Fehler oder Verbote entscheidend werden. Ausgangspunkt sind eine bestimmte Systemversion, ein abgegrenzter Workflow, erlaubte Rollen und Eingaben, verfügbare Wissensquellen und Werkzeuge sowie die Entscheidung, die das Evaluationsergebnis unterstützen soll. Erst danach werden Aufgabenfamilien und relevante Variationen aus berechtigten Arbeitsnachweisen, Supportfällen, Nutzerforschung, Vorfallaufzeichnungen und Walkthroughs mit Fachleuten abgeleitet. Wo belastbare Betriebsdaten fehlen, wird die Abdeckung als Hypothese oder Unsicherheit gekennzeichnet.

Für den beispielhaften Beschaffungsassistenten gehören dazu vollständige Standardanträge, fehlende Dokumente, widersprüchliche Beträge oder Lieferantenkennungen, nicht verfügbare Richtlinien und Anfragen ohne ausreichende Evidenz. Hinzu kommen Versuche, die menschliche Freigabe zu umgehen, vertrauliche Angaben abzurufen oder Anweisungen aus einem hochgeladenen Angebot durchzusetzen. Diese Regeln sind lediglich organisationsspezifische Beispiele. Die verantwortlichen Rollen definieren vor der Ausführung, welche Aufgabenfamilien und Folgen getrennt ausgewertet werden, welches Verhalten eine Freigabe sperrt und welche Entscheidung das Ergebnis tatsächlich tragen darf.

Wie wird jedes Evaluationsszenario reproduzierbar dokumentiert?

Jedes Szenario wird als versionierter Falldatensatz dokumentiert, mit dem eine andere prüfende Person Ausgangslage, erlaubte Mittel und Bewertung nachvollziehen kann. Der Datensatz erhält eine stabile Kennung, verantwortliche Person, Status, Änderungshistorie, Abdeckungs- und Aufgabenfamilie, relevante Segmente, mögliche Folgen, Herkunftskategorie, Berechtigungsnachweis und vorgesehene Zugehörigkeit zum Entwicklungs- oder Freigabeset. Produktionsmaterial wird nicht ungeprüft kopiert: Personenbezogene, vertrauliche oder sicherheitsrelevante Inhalte müssen entsprechend den geltenden Zuständigkeiten autorisiert und auf das Erforderliche minimiert werden.

• Setup: Rolle und Ziel, ursprünglicher Workflow- und Systemzustand, Anfrage, Dateien, relevante Vorgeschichte sowie die zu testende Variation.
• Verfügbare Mittel: freigegebene Wissensbasis, Richtlinienstand, Werkzeuge, Berechtigungen, vorbereitete Werkzeugergebnisse, Umgebungsbedingungen und Systemanweisungen.
• Erwartungen: erforderliche Fakten oder Zustandsänderungen, zulässige alternative Antworten und Wege sowie Situationen für Rückfrage, Enthaltung, Ablehnung oder Eskalation.
• Verbote und Prüfung: untersagte Ausgaben, Offenlegungen, Werkzeugaufrufe und Zustandsänderungen, dazu Prüfertyp, Rubrik, Sperren und gegebenenfalls eine Referenzlösung.
• Ausführung: Zahl der vorab festgelegten Versuche, falls Nichtdeterminismus relevant ist, Aggregationsregel, Prüferqualifikation, Schlichtungsweg und Versionen von Modell, Prompt, Retrieval-Bestand, Werkzeugen, Richtlinie und Testumgebung.

Ein einziger Idealsatz ist für offene Aufgaben meist zu eng. Der Fall sollte stattdessen erforderliche Fakten, akzeptable Alternativen und unerlaubte Resultate getrennt beschreiben. Eine bekannte funktionierende Lösung kann belegen, dass ein begrenzter Fall lösbar ist und seine Prüflogik greift; sie macht andere valide Formulierungen oder Arbeitswege jedoch nicht automatisch falsch. Bei mehrstufigen oder schwankenden Systemen werden Zahl der Versuche und Zusammenfassungsregel festgelegt, bevor Ausgaben betrachtet werden. So lässt sich später unterscheiden, ob das System versagte oder ob Aufgabe, Werkzeugumgebung beziehungsweise Prüfer fehlerhaft waren.

Ein guter Evaluationsfall stellt nicht nur eine schwierige Frage: Er rekonstruiert begrenzte Arbeit und macht Erfolg, zulässige Variation und verbotenes Verhalten prüfbar.

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

Jedes Szenario erhält die engste Bewertungsmethode, die Erfolg und Misserfolg valide unterscheiden kann. Objektiv überprüfbare Werte, Schemas, Berechnungen, Werkzeugargumente, Datensatzzustände und verbotene Aktionen eignen sich für deterministische Kontrollen. Sind mehrere Formulierungen oder Wege möglich, aber Fakten und Endzustand begrenzt, dienen Referenzfakten oder eine funktionierende Referenzlösung als Prüfgrundlage. Wirklich offene Merkmale wie Vollständigkeit, Nützlichkeit oder Begründungsqualität benötigen getrennte Rubrikdimensionen mit beobachtbaren Ankern. Modellbasierte Prüfer werden daran mit qualifizierten menschlichen Urteilen im relevanten Kontext kalibriert.

• Deterministische Kontrolle: für eindeutig nachweisbare Antworten, Zustände, Werkzeugaufrufe oder Verbote; zusätzlich prüfen, ob die Kontrolle vollständig und der Fall lösbar ist.
• Referenzfakten oder Referenzlösung: für begrenzte Evidenz und Endzustände mit mehreren zulässigen Ausdrucks- oder Lösungswegen.
• Verankerte Rubrik: für offene Qualität, wobei jede Dimension eigene beobachtbare Kriterien sowie positive, negative und grenzwertige Beispiele erhält.
• Qualifiziertes Fachurteil: wenn Domäneninterpretation oder Folgen nicht valide automatisiert beurteilt werden können; regulierte Entscheidungen verbleiben bei autorisierten Fachrollen.

Teilpunkte sind sinnvoll, wenn Aufgabenkomponenten eine aussagekräftige Abstufung bilden, dürfen aber nicht verdecken, welcher Bestandteil fehlgeschlagen ist. Eine verbotene Offenlegung oder nicht autorisierte Aktion wird als zuvor definierte, nicht kompensierbare Sperre behandelt: Eine elegante Begründung oder ein guter Durchschnitt hebt sie nicht auf. Die konkrete Sperrlogik und ihre Freigabefolge bestimmen zuständige Produkt- und Risikoverantwortliche. Ebenso werden Rubrikversion, Segmentdefinitionen, Aggregation und Entscheidungsregel vor dem Systemvergleich fixiert. Spätere Änderungen sind legitim, werden aber als neue Evaluationsversion dokumentiert und nicht rückwirkend auf bevorzugte Ergebnisse zugeschnitten.

Wie wenden Prüfende die Kriterien konsistent an?

Prüfende wenden Kriterien konsistenter an, wenn sie denselben Arbeitskontext, beobachtbare Bewertungsanker und einen klaren Weg für mangelhafte Fälle erhalten. Vor jeder Ausgabe beschreibt der Leitfaden Workflow-Zweck, handelnde Rolle, verfügbare Evidenz, erlaubtes Verhalten, Produktgrenze und Rubrikversion. Für jede Bewertungsstufe nennt er erkennbare Merkmale sowie positive, negative und grenzwertige Beispiele. Eine Option wie „nicht bewertbar“ verhindert, dass fehlender Kontext, unerreichbare Endzustände oder defekte Werkzeuge fälschlich als Systemleistung verbucht werden. Sie benötigt allerdings eine Begründung und darf kein bequemer Ausweg bei schwierigen Urteilen sein.

1. Kalibrierungsfälle vor der eigentlichen Prüfung unabhängig bewerten und Unterschiede anhand der sichtbaren Kriterien besprechen.
2. Bei Änderungen an Aufgabenmix, Richtlinie, Rubrik oder Prüfergruppe erneut kalibrieren.
3. Systemidentität und Ausgabereihenfolge bei Vergleichsurteilen nach Möglichkeit verbergen.
4. Einzelurteile und Begründungen vor der Diskussion speichern, damit ein frühes Gruppenurteil sie nicht überschreibt.
5. Uneinigkeit als Diagnosehinweis behandeln und einer benannten Schlichtungsrolle vorlegen.

Uneinigkeit ist nicht automatisch ein Qualitätsmangel der Prüfenden. Sie kann einen mehrdeutigen Fall, eine unklare Schwelle, fehlende Informationen, legitime Alternativen oder eine noch offene Produktentscheidung aufdecken. Deshalb wird nicht jeder Unterschied in einen erzwungenen Konsens verwandelt. Die Schlichtungsrolle trennt die Korrektur eines defekten Falls von einer Entscheidung über gewünschtes Produktverhalten. Gespeichert werden ursprüngliche Bewertungen, Begründungen, Rubrikversion, Ergebnis der Schlichtung und verbleibende Unsicherheit. Diese Historie ermöglicht spätere Qualitätskontrollen und die erneute Kalibrierung automatisierter Prüfer, ohne menschliche Urteile als grundsätzlich fehlerfrei zu behandeln.

Wie bleibt das Evaluationsset bei Entwicklung und Freigabe aussagekräftig?

Das Set bleibt aussagekräftig, wenn sichtbare Entwicklungsfälle und geschützte Freigabefälle unterschiedliche Aufgaben erfüllen und ihre Exposition dokumentiert wird. Das Entwicklungsteam darf das erste Set wiederholt für Anpassungen an Prompt, Retrieval, Werkzeugen, Richtlinien und Workflow verwenden; seine Resultate sind gerade deshalb Entwicklungsevidenz. Das geschützte Set wird vor routinemäßiger Ausführung zugeordnet, sparsam für abschließende Vergleiche oder Freigaben genutzt und so verwahrt, dass konkrete Fälle, Antworten, Rubriken und Ergebnisse die Iteration nicht steuern. Eine universelle Fallzahl oder feste prozentuale Aufteilung lässt sich daraus nicht ableiten.

• Exakte und ähnliche Dubletten, gemeinsame Quelldatensätze, Paraphrasen und Geschwister aus derselben Szenariovorlage setübergreifend erkennen.
• Zugriffe auf Fallinhalt, Referenzantworten, Rubriken und Ergebnisse protokollieren und Split-Zugehörigkeit schon beim Eintrag ins Register vergeben.
• Bestätigte Fehler, die Diagnose oder Behebung beeinflusst haben, als Entwicklungs- oder Regressionsevidenz führen.
• Dieselbe Fehlerklasse im geschützten Set nur mit unabhängig erstellten, nicht duplizierten Fällen prüfen, die die Änderung nicht gesteuert haben.
• Einen materiell exponierten Freigabefall verschieben und durch einen versionierten neuen Fall ersetzen, statt seine Unabhängigkeit weiter zu behaupten.

Ein kompaktes Register hält je Fall Verantwortlichkeit, Herkunft, Berechtigung, Split, Exposition, Versionen, letzte Prüfung, Änderungsgrund und gegebenenfalls Ausmusterungsgrund fest. Neue verifizierte Vorfälle und Supportsignale können nach Autorisierung, Minimierung und fachlicher Bestätigung ergänzt werden. Eine erneute Abdeckungsprüfung wird fällig, wenn sich Workflow, Nutzergruppen, Richtlinie, Wissensbestand, Modell, Prompt, Werkzeuge, Berechtigungen oder Betriebsumgebung materiell ändern. Dabei werden auch veraltete Referenzen, fehlerhafte Labels, mehrdeutige Aufgaben, unerreichbare Ziele und Prüfer untersucht, die valide Alternativen zurückweisen.

Berichtet wird nicht nur ein Gesamtwert, sondern nach Aufgabenfamilie, Abdeckungsfamilie, relevantem Segment, möglicher Folge und Sperre. Ein bestandener Offline-Test ist dabei Entscheidungsevidenz, kein Zertifikat für Geschäftswert, Sicherheit, Fairness, Compliance oder Produktionsreife. Produkt- und Risikoverantwortliche legen die zulässige Verwendung fest; Fachleute prüfen Workflow-Realismus und Erwartungen. Sobald Datenschutz, Sicherheit, Beschäftigung, Finanzen, Medizin, Recht oder andere regulierte Bereiche berührt werden, bleiben die jeweiligen Urteile bei qualifizierten und autorisierten Personen. Offline-Ergebnisse werden mit Monitoring, Nutzerforschung, Vorfallanalyse und weiterer für das System geeigneter Evidenz verbunden.