Prüfungen
ML-Modelle testen: alle Winkel
Jede Zeile ist eine Frage, eine Prüfung als Code und ein Kriterium. Das Kriterium ist ein Beispiel; im Projekt kommt es aus der Risikoanalyse. «Im Demo» heisst: Ein Ausschnitt davon läuft oben im Beleg wirklich (zum Beispiel nur die Sensitivität, nur exakte Zeilen-Hashes). Alle anderen Zeilen sind Methode; welche davon ein Projekt braucht, folgt aus der Risikoanalyse. Hier wird sie nicht vorgeführt.
| Winkel | Frage | Prüfung als Code | Beispielkriterium |
|---|---|---|---|
| Daten | |||
| Qualität und Schema | Stimmen Typen, Wertebereiche, Pflichtfelder, Duplikate? | Schema- und Bereichstests bei jedem Datenimport | 0 Verstösse oder dokumentierte Ausnahme |
| Leckage und Aufteilung Im Demo (Ausschnitt): T01 | Steckt ein Testfall im Training, auch indirekt (gleiche Person, gleicher Kunde, Zukunft)? | Zeilen-Hash-Schnitt, Gruppen- und Zeit-Split (im Demo nur der Hash-Schnitt) | 0 Überschneidung |
| Repräsentativität und Labels | Decken die Daten den echten Einsatz ab? Sind die Labels verlässlich? | Verteilungsvergleich, zwei Beurteilende, Übereinstimmung κ | κ ≥ 0,8; Abweichung zum Einsatz dokumentiert |
| Herkunft und Rechte | Woher stammen die Daten, mit welcher Lizenz, mit welchen Personendaten? | Herkunftsregister, Personendaten-Scanner, Aufbewahrungsregel | Herkunft, Lizenz und Personendatenbezug jeder Quelle dokumentiert; rechtliche Beurteilung durch Anwältin oder Anwalt |
| Modell | |||
| Leistung mit Vertrauensbereich Im Demo (Ausschnitt): T02 | Wie oft liegt es richtig, gewichtet nach Fehlerkosten? | Sensitivität und Spezifität mit Wilson-Grenze, nicht nur Accuracy | Untere 95-%-Grenze ≥ Schwelle |
| Teilgruppen und Fairness Im Demo (Ausschnitt): T03 | Gilt die Leistung für jede Gruppe (Sprache, Region, Gerät, Alter)? | Auswertung je Teilgruppe mit Mindestfallzahl | Jede Gruppe ≥ Schwelle, sonst ausgeschlossen |
| Kalibrierung und Unsicherheit Im Demo (Ausschnitt): T06, T08 | Stimmen die genannten Wahrscheinlichkeiten? Weiss es, wann es nichts weiss? | ECE, Zuverlässigkeitsdiagramm, Weiterleitung an Menschen | ECE ≤ 0,05; Fehlerrate der Auto-Fälle begrenzt |
| Verhalten Im Demo (Ausschnitt): T05 | Verhält es sich in bekannten Situationen wie verlangt? | Invarianz-, Richtungs- und Mindestfunktionstests (CheckList), metamorphe Tests | 0 Verletzungen |
| Robustheit Im Demo (Ausschnitt): T04 | Hält es Rauschen, Tippfehler, Formatwechsel, Sprachwechsel aus? | Gestörte Eingaben, Kippquote messen | Kippquote ≤ 1 % |
| Angriffe | Lässt es sich täuschen, vergiften oder ausspähen? | Adversariale Beispiele, Datenvergiftungs-Test, Extraktions-Test | Gefundene Angriffe mit Gegenmassnahme |
| Datenschutz | Gibt es Trainingsdaten oder Personendaten preis? | Memorisierungs- und Membership-Inference-Test, PII-Scan der Ausgaben | 0 Treffer im Prüfsatz |
| Erklärbarkeit | Stützen die Gründe die Entscheidung, oder schmücken sie nur? | Plausibilitätstests der Attribution, Gegenfaktische | Erklärung ändert sich mit der Entscheidung |
| Wiederholbarkeit Im Demo (Ausschnitt): T07 | Liefert derselbe Stand dasselbe Ergebnis? | Seeds, Versionen, Daten-Hash, bitgleicher Vergleich | Hash gleich |
| System | |||
| Integration und Vertrag | Was passiert bei Zeitüberschreitung, Fehlern, leerer Antwort? | Vertragstests der Schnittstelle, Fehlerpfad-Tests, Rückfall ohne KI | Jeder Fehlerpfad endet sicher |
| Last, Zeit, Kosten | Hält es Last aus, was kostet eine Anfrage? | Lasttest, p95-Latenz, Kosten je Anfrage, Budgetgrenze | p95 und Budget im Rahmen |
| Mensch und Prozess (UAT) | Nutzen echte Leute die Kontrolle wirklich? | Abnahme mit Nutzenden, Köderfälle, Schulungs-Nachtest | Köder-Fundquote ≥ 90 % |
| Lieferkette | Woher kommen Modell und Bibliotheken, sind sie fixiert? | Versionen und Prüfsummen fixiert, Stückliste (SBOM, ML-BOM), Lizenzen dokumentiert | Alles gepinnt, Stückliste aktuell |
| Betrieb | |||
| Drift und Überwachung | Ändert sich die Welt unter dem Modell? | Drift-Index (PSI) auf Eingaben, Stichproben-Prüfung der Ausgaben, Alarmschwellen | PSI < 0,25; Alarm hat eine zuständige Person |
| Vorfälle und Stopp | Wer stoppt es, wie schnell, wie geht es zurück? | Stopp-Schalter und Rollback als Übung, Vorfallregister | Übung bestanden, Zeit gemessen |
| Änderung und Re-Freigabe | Was passiert bei neuer Version, neuem Prompt, neuen Daten? | Jede Änderung löst das ganze Gate aus | Keine Änderung ohne grünes Gate |
Antworten
Was prüft man bei einem ML-Modell ausser der Genauigkeit?
Bei einem ML-Modell prüft man ausser der Genauigkeit die Daten (Qualität, Leckage, Repräsentativität), das Verhalten (Teilgruppen, Kalibrierung, Robustheit), das System (Integration, Last, Mensch im Ablauf) und den Betrieb (Drift, Vorfälle, Änderungen). Die Checkliste unterscheidet zwanzig Prüfungen. Welche für dein Modell nötig sind, folgt aus der Risikoanalyse.
Wie erkenne ich Drift bei einem KI-Modell im Betrieb?
Drift erkennt man, indem man die Eingaben im Betrieb laufend mit den Trainingsdaten vergleicht, zum Beispiel mit dem Population Stability Index (PSI). Ein PSI über 0,25 gilt oft als Faustregel für eine deutliche Verschiebung; die Schwelle legst du pro Eingangsgrösse fest. Wichtig ist, dass jeder Alarm eine zuständige Person hat.
Warum genügt eine einzige Kennzahl nicht?
Eine einzige Kennzahl genügt nicht, weil verschiedene Fehler dieselbe Zahl liefern können. In der Demo behält ein zu vorsichtig gestauchtes Modell dieselbe Sensitivität und fällt nur bei Kalibrierung und Automatik-Abdeckung durch. Darum werden Daten, Verhalten, Robustheit, Teilgruppen, Kalibrierung und Betrieb getrennt geprüft.
Kontakt
Schick mir den Einsatz in zwei Sätzen. Ich melde mich und sage dir, ob und wie sich dein Vorhaben prüfen lässt. Ob ich den Auftrag übernehmen kann, hängt von meiner Auslastung ab.