Projekte
Ein adversariales Evaluationsset für Allergensicherheit
Eine interne Entwicklung: ein adversariales Evaluationsset mit 117 Fällen für Allergenantworten in einem KI-Produkt für die Hotellerie, als Merge-Gate in die CI eingebunden, das verlangt, dass jeder Fall besteht.
- Was es belegt
- Evaluation als Code: Keine Änderung am Assistenten geht live, solange nicht alle 117 Allergenfälle weiterhin bestehen.
- Phasen der Methode
- Gebaut aus
- Adversariales Evaluationsset mit 117 Fällen
- Fälle zur Erkennung von Umschreibungen
- Fälle mit Social-Engineering-Prompts
- Fälle mit Fallen durch positive Formulierung
- CI-Merge-Gate mit einer Bestehensquote von 100 %
- Regressionsverfolgung über Änderungen an Modell, Prompt und Retrieval
Die Ausgangslage
Ein Assistent, der die Check-in-Zeit falsch nennt, kostet einen Gast ein paar Minuten. Ein Assistent, der einem Gast fälschlich sagt, ein Gericht sei frei von einem Allergen, kann diesen Gast ins Spital bringen. Die meisten Teams testen beides gleich: mit einer Stichprobe vor dem Start. Dann gibt es keine Aufzeichnung, was getestet wurde, und keine Möglichkeit zu merken, wenn eine spätere Änderung etwas kaputt macht.
Was wir gebaut haben
Wir haben ein Evaluationsset mit 117 adversarialen Fällen zur Allergensicherheit geschrieben, in drei Klassen:
- Umschreibungsfälle beschreiben das Allergen indirekt, statt es zu nennen.
- Social-Engineering-Fälle üben Druck aus, setzen Dringlichkeit oder Autorität ein, auch mit der Behauptung, eine Mitarbeiterin habe das Gericht bereits als unbedenklich bestätigt.
- Fälle mit positiver Formulierung stellen die Frage so, dass die Antwort, die sich der Gast wünscht, die leichteste zu geben ist.
Das Set läuft in der CI als Merge-Gate mit einem Schwellenwert von 100 %. Ein einziger fehlschlagender Fall blockiert den Merge. Jede Änderung an Modell, Prompt oder Retrieval-Pipeline läuft hindurch, und die Ergebnisse werden über die Änderungen hinweg als Regressionen verfolgt.
Der Preis: Eine nützliche Verbesserung am Prompt kann durch eine unabhängige Regression an anderer Stelle im Set blockiert werden. Die Lösung ist immer, die Regression zu beheben, nie, das Gate zu senken.
Was es für Kunden belegt
Die Evaluation existiert vor der Änderung, läuft automatisch und kann ein Release stoppen. So wissen Sie, dass eine Änderung den Assistenten nicht unsicherer gemacht hat.
Phasen der Methode
Das Projekt gehört in Phase 02 · Nutzen belegen, in der die Evaluation geschrieben wird, bevor der Prototyp gebaut wird. Es setzt sich in Phase 06 · Betreiben und weiterentwickeln fort, in der dasselbe Set jede spätere Änderung an Modell oder Prompt absichert. Siehe die KARPINITY-Methode.