KI-Pilot: Testfälle mit klaren Sollentscheidungen auswählen
Ein kleiner Fallplan hilft, Erwartungen vor dem KI-Test festzulegen. Das Beispiel trennt Routine, Unklarheit und Eingaben außerhalb der Aufgabe.
Die Aufgabe und das Sollrouting vereinbaren
Ein fiktives Softwareunternehmen plant einen KI-Piloten für Supportnachrichten. Die KI soll eine Weiterleitung vorschlagen: bug, access, review oder out-of-scope. Freischaltungen, Statusänderungen und Ticketabschluss bleiben Aufgaben des Supportteams. Bewertet wird also der Vorschlag, nicht eine automatisch erledigte Supportleistung.
Legen Sie die erwartete Entscheidung mit der Fachseite fest, bevor die Modellausgabe bekannt ist. Können sich die Verantwortlichen nicht einigen, braucht zunächst die Regel eine Klärung. Das NIST AI RMF empfiehlt dokumentierte Testbedingungen und eine Bewertung unter Bedingungen, die dem Einsatz ähneln.
Beispielfälle mit unterschiedlichem Prüfzweck auswählen
Die folgende Auswahl ist erfunden. Die Texte illustrieren die Fälle; für den wirklichen Piloten werden die freigegebenen Originaleingaben mit Sprache und Herkunft erfasst.
Fall | Beispielnachricht | Sollrouting | Begründung |
|---|---|---|---|
| Die App stürzt beim Speichern einer Projektnotiz ab. |
| Klar geschildertes Fehlerbild |
| Bitte geben Sie mir Zugriff auf mein Projekt. |
| Erkennbarer Zugangswunsch; noch keine Freigabe |
| Ich komme nicht rein. |
| Zugangswunsch und technischer Fehler bleiben offen |
| Beim Speichern kommt ein Fehler; außerdem brauche ich Projektzugriff. |
| Gemischte Anliegen; der Pilot sieht eine Kategorie pro Nachricht vor |
| Melden Sie sich für unser Werbeseminar an. |
| Kein Supportanliegen im vereinbarten Katalog |
Die letzte Markierung bewirkt im Beispiel keine Löschung. Die Auswahl macht verschiedene Entscheidungen sichtbar; sie belegt weder die Häufigkeit der Fälle noch die ausreichende Größe eines Testdatensatzes. Ergänzen Sie beim späteren Sammeln unter anderem die tatsächlich benötigten Sprachen, Eingabeformen und fehlenden Angaben.
Entwicklungsfälle von der späteren Kontrolle trennen
Beispiele, an denen das Team Prompt oder Routingregeln verändert, sind Entwicklungsfälle. Halten Sie für eine spätere Kontrolle andere, zuvor nicht zur Optimierung benutzte Fälle zurück. Kopien und nahe Umformulierungen derselben Ausgangsnachricht sollten nicht als unabhängige Belege auf beide Seiten verteilt werden.
Google erklärt für maschinelles Lernen, wie wiederholt genutzte Testdaten und Duplikate die Bewertung verzerren können. Für die Promptentwicklung folgt daraus eine praktische Vorsicht: Bekannte Beispiele sind hilfreich zur Fehlersuche, aber eine spätere Kontrolle sollte zusätzliche unbekannte Fälle enthalten. Promptbearbeitung ist dabei kein Modelltraining.
Ergebnisse je Fall und Fehlerart festhalten
Notieren Sie beim späteren Test Modell-, Prompt- und Testsatzfassung sowie Sollrouting, tatsächliche Ausgabe und fachliche Bewertung. Eine erwartete manuelle Prüfung ist ein passendes Ergebnis für einen unklaren Fall. Eine vorschnelle eindeutige Zuordnung kann dagegen ein Fehler sein.
Berichten Sie Routinefälle, unklare Fälle und Eingaben außerhalb des Auftrags getrennt. Wird ein Fehler zur Anpassung der Lösung verwendet, bleibt der ursprüngliche Befund im Bericht; der Fall dient danach der Entwicklung und der Kontrolle, ob der bekannte Fehler wiederkehrt. Für eine erneute unabhängige Kontrolle brauchen Sie weitere passende zurückgehaltene Beispiele. Die Tabelle ist ein begründeter Anfang für die Auswahl, kein bereits ausgeführter Test und kein Nachweis der Produktionstauglichkeit.
Quellen
Weiterlesen
Alle Beiträge
KI & Automatisierung mit ASES
KI-Assistenten und automatisierte Abläufe