Machine-Learning-Modell als Untersuchungsgegenstand: Modellversion, Parameter, Datenbasis und Laufzeitumgebung

Machine Learning & KI

Die Bezeichnung „das KI-Modell“ oder ein Dateiname wie model_final.pkl bestimmt noch keinen technisch eindeutigen Untersuchungsgegenstand. Je nach Framework und Persistenzformat können Modellstruktur, gelernte Parameter, Vorverarbeitung, Metadaten und Laufzeitabhängigkeiten unterschiedlich gespeichert sein.

1. Ein Machine-Learning-Modell muss technisch bestimmt werden

Für eine Begutachtung reicht es nicht, dass eine Datei oder ein System lediglich mit einem Modellnamen bezeichnet wird.

Der konkrete Untersuchungsgegenstand kann beispielsweise sein:

• ein serialisiertes Modellartefakt,
• ein PyTorch-Checkpoint,
• ein TensorFlow-SavedModel,
• eine ONNX-Datei,
• ein scikit-learn-Estimator oder eine vollständige Pipeline,
• ein in einem Container bereitgestellter Inferenzdienst,
• ein historischer Modellstand aus einem Modellregister.

2. Modellartefakt und vollständiges KI-System sind nicht dasselbe

Das gespeicherte Modellartefakt kann nur einen Teil des tatsächlich ausgeführten Systems darstellen.

Außerhalb des Modellartefakts können beispielsweise liegen:

• Datenbereinigung,
• Feature-Berechnung,
• Tokenisierung,
• Skalierung oder Normalisierung,
• Auswahl von Eingabefeldern,
• Schwellenwerte,
• Nachverarbeitung von Modelloutputs,
• Geschäftsregeln, die aus einem Modellscore eine Entscheidung ableiten.

Für die Untersuchungsfrage ist deshalb zu klären, ob nur das mathematische Modell oder die vollständige Verarbeitungskette betrachtet werden soll.

3. Das Persistenzformat bestimmt mit, was im Artefakt enthalten ist

Verschiedene Machine-Learning-Frameworks und Persistenzverfahren speichern nicht zwangsläufig denselben technischen Umfang.

Die scikit-learn-Dokumentation unterscheidet beispielsweise zwischen ONNX, skops.io, pickle, joblib und cloudpickle. Die jeweiligen Formate besitzen unterschiedliche Anforderungen an Laufzeitumgebung, Portabilität und Sicherheit.

Deshalb gehört das konkrete Persistenz- oder Exportformat zur technischen Beschreibung des Untersuchungsgegenstands.

4. Ein Dateiname oder eine Bezeichnung beweist keinen Modellstand

Dateinamen wie model_final.pt, classifier_v3.pkl oder production.onnx sind organisatorische Bezeichnungen.

Sie belegen für sich genommen nicht, welcher Bytebestand, welcher Trainingslauf, welcher Commit oder welche Deployment-Version tatsächlich vorliegt.

5. Hashwerte können ein konkretes Modellartefakt technisch identifizieren

Ein kryptografischer Hashwert kann verwendet werden, um einen konkreten Bytebestand eines Modellartefakts technisch zu kennzeichnen.

Der Hashwert belegt dadurch jedoch nicht automatisch, aus welchem Trainingslauf das Artefakt stammt, ob die richtigen Daten verwendet wurden oder ob das Modell fachlich geeignet ist.

6. Modellstruktur und gelernte Parameter sind zu unterscheiden

Besonders deutlich ist diese Trennung beispielsweise bei PyTorch. Ein state_dict bildet Modellparameter und registrierte Zustände auf Schlüssel ab.

Zum Wiederherstellen eines solchen Zustands wird die passende Modellstruktur benötigt, in die der gespeicherte Zustand geladen werden kann.

Deshalb sollte dokumentiert werden, ob ein vorliegendes Artefakt nur Parameterzustände, ein vollständiges Modell, einen Checkpoint oder ein exportiertes Programm enthält.

7. Gelernte Parameter und Hyperparameter sind verschiedene Dinge

Gelernte Parameter entstehen durch den Trainingsprozess. Dazu gehören je nach Modell beispielsweise Gewichte oder Bias-Werte.

Hyperparameter werden dagegen für Training oder Modellkonfiguration vorgegeben oder ausgewählt. Beispiele können Lernrate, Baumtiefe, Regularisierung, Batchgröße oder Modellarchitekturparameter sein.

Für die Rekonstruktion eines Trainingsprozesses können beide Kategorien relevant sein, sie sollten aber nicht miteinander gleichgesetzt werden.

8. Vorverarbeitung kann Teil des Modells oder ein separates Artefakt sein

Ein Modell kann nur dann mit den erwarteten Eingaben arbeiten, wenn die erforderliche Vorverarbeitung berücksichtigt wird.

Je nach technischer Architektur kann diese Vorverarbeitung im Modellartefakt, in einer Pipeline, in Anwendungscode oder in einem separaten Dienst liegen.

Deshalb sollte geprüft werden, welche Transformationsschritte tatsächlich vor der Inferenz ausgeführt wurden.

9. Das Eingabeschema gehört zur Untersuchungsgrundlage

Für reproduzierbare Inferenz muss hinreichend klar sein, welche Eingaben das Modell erwartet.

Relevant sein können beispielsweise:

• Anzahl und Reihenfolge der Features,
• Datentypen,
• Tensor-Dimensionen,
• Kategorien und Encodings,
• zulässige Wertebereiche,
• Tokenisierungsregeln,
• Regeln für fehlende Werte.

10. Auch das Ausgabeschema muss bestimmt werden

Ein Modelloutput kann beispielsweise eine Klasse, einen Score, eine Wahrscheinlichkeit, einen Vektor, eine Regression oder eine andere technische Ausgabe darstellen.

Erst durch das dokumentierte Ausgabeschema lässt sich nachvollziehen, wie nachfolgende Verarbeitungsschritte den Modelloutput interpretieren.

11. Schwellenwerte und Nachverarbeitung können außerhalb des Modells liegen

Bei Klassifikationssystemen kann ein Modell zunächst einen Score oder eine Wahrscheinlichkeit erzeugen.

Die spätere Zuordnung zu einer Klasse kann von einem Schwellenwert abhängen, der nicht zwingend Bestandteil des gespeicherten Modellartefakts ist.

Dasselbe gilt für Kalibrierung, Rankingregeln oder andere Nachverarbeitung.

12. Die Trainingsdaten gehören zur Modellprovenienz

Ein Modellzustand entsteht nicht unabhängig von seiner Datenbasis.

Für eine technische Rekonstruktion kann deshalb relevant sein, welcher konkrete Trainingsdatensatz, welche Aufbereitung und welche Feature-Erzeugung dem Modell zugrunde lagen.

Zur technischen Bestimmung von Datenherkunft, Datenstand und Transformationen siehe Daten als Untersuchungsgegenstand: Herkunft, Datenstand und Reproduzierbarkeit .

13. Trainings-, Validierungs- und Testdaten haben unterschiedliche Funktionen

Ein Modell kann mit einem Trainingsdatensatz angepasst, mit Validierungsdaten ausgewählt und auf einem separaten Testdatensatz bewertet worden sein.

Für eine konkrete Leistungskennzahl muss deshalb bestimmt werden, auf welchem Datenbestand sie tatsächlich berechnet wurde.

Datenqualität und Referenzgrundlagen solcher Datenbestände können gesondert untersucht werden. Dazu siehe Datenqualität technisch prüfen: Vollständigkeit, Konsistenz, Genauigkeit und Aktualität .

14. Trainingscode und Trainingsrezept sind nicht automatisch im Modell enthalten

Ein persistiertes Modellartefakt enthält nicht zwangsläufig den Code und alle Informationen, die für eine erneute Erzeugung desselben Modellzustands erforderlich wären.

Dazu können beispielsweise gehören:

• Trainingsskript oder Notebook,
• Quellcodeversion,
• Konfigurationsdateien,
• Hyperparameter,
• Daten-Splits,
• verwendete Zufallszustände,
• Bibliotheksversionen.

15. Zufallszustände können die Reproduzierbarkeit beeinflussen

Training und Datenaufteilung können stochastische Schritte enthalten.

Deshalb können dokumentierte Zufallsparameter beziehungsweise Seeds Teil der technischen Untersuchungsgrundlage sein. Ein Seed allein garantiert jedoch nicht für jede Software- und Hardwarekonstellation vollständige Reproduzierbarkeit.

16. Die Laufzeitumgebung kann für das Laden des Modells entscheidend sein

Bei Python-basierten scikit-learn-Persistenzformaten hängt die Wiederverwendbarkeit von passenden Abhängigkeiten und Versionsständen ab.

Für eine technische Untersuchung sollten deshalb gegebenenfalls dokumentiert werden:

• Python-Version,
• Framework-Version,
• NumPy- und weitere Bibliotheksversionen,
• Betriebssystem,
• Container- oder Image-Version,
• verwendeter Inferenzruntime.

17. Softwareversion und Modellversion sind getrennte Angaben

Eine Modellversion bezeichnet nicht automatisch die Version des Frameworks, mit dem das Modell erzeugt oder ausgeführt wurde.

Ebenso ist eine Bibliotheksversion nicht mit einer fachlichen Modellversion gleichzusetzen.

Beide Angaben können für die technische Reproduktion erforderlich sein.

18. Hardware und Inferenzruntime können zum Prüfkontext gehören

Je nach Framework, Operatoren und Deployment können CPU, GPU, Beschleuniger, Laufzeitbibliotheken oder Execution Provider für das konkrete Verhalten relevant sein.

Deshalb sollte die technische Umgebung nicht pauschal als unwesentlich behandelt werden, wenn gerade Reproduzierbarkeit oder Abweichungen zwischen zwei Ausführungen untersucht werden.

19. Der Inferenzmodus kann das Modellverhalten beeinflussen

PyTorch weist beispielsweise darauf hin, dass für Inferenz der Evaluationsmodus mit model.eval() gesetzt werden muss, damit unter anderem Dropout- und Batch-Normalization-Layer entsprechend betrieben werden.

Damit kann auch ein Ausführungsmodus Teil der Untersuchungsbedingungen sein.

20. Persistierte Modellartefakte können ein Sicherheitsrisiko darstellen

Die technische Untersuchung eines unbekannten Modellartefakts darf nicht mit einem unkontrollierten Laden gleichgesetzt werden.

Die scikit-learn-Dokumentation weist ausdrücklich darauf hin, dass Pickle-basierte Formate beim Laden Code ausführen können.

21. TensorFlow SavedModel besitzt einen anderen Artefaktumfang

TensorFlow beschreibt ein SavedModel als vollständiges TensorFlow-Programm mit trainierten Parametern und Berechnung.

Das verdeutlicht, dass die Frage „Was enthält die Modelldatei?“ nicht frameworkunabhängig beantwortet werden kann.

22. ONNX trennt mehrere Versionsebenen

Bei ONNX sind IR-Version, Operator- beziehungsweise Opset-Version und Modellversion getrennte Versionsebenen.

Ein ONNX-Modell kann unter anderem Angaben wie ir_version, opset_import, producer_version und model_version enthalten.

Für eine technische Begutachtung sollte deshalb nicht nur eine einzige Zahl pauschal als „die Modellversion“ bezeichnet werden, wenn unterschiedliche Versionsebenen gemeint sein können.

23. Deployment-Artefakt und Trainingsartefakt können voneinander abweichen

Ein Modell kann nach dem Training exportiert, konvertiert, quantisiert, optimiert oder in ein anderes Format überführt worden sein.

Damit kann der im Produktivsystem ausgeführte Zustand von dem ursprünglichen Trainingsartefakt abweichen.

Wird Produktionsverhalten untersucht, ist deshalb grundsätzlich der tatsächlich verwendete Deployment-Stand zu bestimmen.

24. Ein Modellartefakt belegt noch keine Modellqualität

Die eindeutige Identifikation eines Modells beantwortet zunächst die Frage nach dem Untersuchungsgegenstand.

Aussagen über Genauigkeit, Robustheit, Fairness, Generalisierung oder sonstige Leistungsmerkmale benötigen zusätzlich einen geeigneten Prüfmaßstab, eine definierte Datenbasis und eine passende Metrik.

25. Reproduzierbarkeit von Inferenz und Reproduzierbarkeit von Training sind verschieden

Es ist methodisch zu unterscheiden, ob lediglich überprüft werden soll, ob ein vorhandener Modellzustand unter dokumentierten Bedingungen dieselben Ausgaben erzeugt, oder ob der gesamte Trainingsprozess erneut nachvollzogen werden soll.

Für eine Inferenzreproduktion können Modellartefakt, Eingaben, Vorverarbeitung und Laufzeitumgebung genügen. Für eine Trainingsreproduktion werden regelmäßig zusätzliche Angaben zu Daten, Trainingscode, Hyperparametern und Zufallszuständen benötigt.

26. Fehlende Artefakte begrenzen die technische Aussage

Fehlt beispielsweise die Modellstruktur, kann ein isolierter Parameterzustand unter Umständen nicht vollständig interpretiert werden.

Fehlt die historische Laufzeitumgebung, kann möglicherweise nicht überprüft werden, ob ein altes Artefakt unter den damaligen Bedingungen dasselbe Verhalten gezeigt hat.

Fehlen Trainingsdaten oder Trainingscode, kann der vorhandene Modellzustand zwar untersucht werden, ohne dass dadurch sein vollständiger Entstehungsprozess reproduzierbar wird.

27. Technischer Modellbefund und rechtliche Würdigung bleiben getrennt

Ein technisches Gutachten kann beispielsweise feststellen, welches Modellartefakt vorlag, welche Parameter oder Versionsstände dokumentiert sind, ob ein Ergebnis reproduziert werden kann oder welche Bestandteile fehlen.

28. Praktische Dokumentationsstruktur für einen Modellstand

Für einen technisch bestimmten Machine-Learning-Modellstand können beispielsweise folgende Angaben dokumentiert werden:

• Modellbezeichnung,
• Artefaktdatei oder Verzeichnis,
• kryptografischer Hashwert,
• Persistenz- oder Exportformat,
• Modellstruktur,
• gelernter Parameterzustand,
• relevante Hyperparameter,
• Vorverarbeitung,
• Ein- und Ausgabeschema,
• Schwellenwerte und Nachverarbeitung,
• Trainings-, Validierungs- und Testdatenstände,
• Trainingscode beziehungsweise Quellcodeversion,
• Framework- und Bibliotheksversionen,
• Inferenzmodus,
• Laufzeit- und gegebenenfalls Hardwareumgebung,
• bekannte Unsicherheiten und Aussagegrenzen.

Weiterführende Beiträge

Wie Trainings-, Validierungs- und Testdaten nach Herkunft, Datenstand und Transformationen bestimmt werden, erläutert Daten als Untersuchungsgegenstand: Herkunft, Datenstand und Reproduzierbarkeit .

Zur technischen Untersuchung der Qualität eines bestimmten Datenbestands siehe Datenqualität technisch prüfen: Vollständigkeit, Konsistenz, Genauigkeit und Aktualität .

Wie eine technische Fragestellung zu einem Daten- oder KI-System in prüfbare Teilfragen überführt werden kann, erläutert Welche technische Fragestellung kann ein IT-Sachverständiger tatsächlich beantworten? .

Der allgemeine Quellen- und Dokumentationsstandard ist unter Quellen und Methodik beschrieben.

Machine-Learning- und KI-Systeme untersuchen

Wenn Modellversion, Modellartefakt, Parameterzustand, Datenbasis, Vorverarbeitung oder Inferenzumgebung technisch untersucht werden sollen, können Untersuchungsgegenstand und erforderliche Artefakte zunächst fachlich eingegrenzt werden.

Data-Science- & KI-Gutachten ansehen