Modellkatalog

Modellkatalog

Der Modellkatalog ist ein zentralisiertes und verwaltetes Repository mit Modellartefakten. Im Modellkatalog gespeicherte Modelle können von den Mitgliedern eines Teams gemeinsam verwendet und wieder in eine Notizbuchsession geladen werden. Beispiel: Modelle im Modellkatalog können auch als HTTP-Endpunkte mit einem Modell-Deployment bereitgestellt werden.

Ein Modelleintrag im Modellkatalog besteht aus zwei Komponenten:

• Ein Modellartefakt ist ein ZIP-Archiv mit dem gespeicherten Modellobjekt. einem Python-Skript, das Anweisungen zur Verwendung des Modells für Inferenzzwecke enthält (score.py) und eine Datei zur Dokumentation der Laufzeitumgebung des Modells (runtime.yaml). Sie können Beispiele für Artefakte, score.py und runtime.yaml aus Github abrufen.

• Metadaten zur Herkunft des Modells, einschließlich Git-bezogene Informationen und Skript oder Notizbuch, das zum Übertragen des Modells in den Katalog verwendet wurde. Sie können die Ressource, in der das Modell trainiert wurde (entweder eine Notizbuchsession oder ein Joblauf), und die Git-Referenz zum Trainingsquellcode dokumentieren. Diese Metadaten werden automatisch aus der Notizbuchsessionumgebung extrahiert, wenn Sie das Modellartefakt mit ADS speichern.

Im Modellkatalog gespeicherte Modellartefakte können nicht geändert werden. Wenn Sie ein Modell ändern möchten, müssen Sie ein neues Modell erstellen. Unveränderlichkeit verhindert unerwünschte Änderungen und stellt sicher, dass jedes Modell in der Produktion bis zum genauen Artefakt hinter den Modellvorhersagen verfolgt werden kann.

Modelle dokumentieren

Mit diesen Optionen können Sie das Training des Modells, den Anwendungsfall und die erforderlichen Vorhersagefeatures dokumentieren.

Herkunft

Durch Dokumentation der Modellherkunft können Sie die Reproduzierbarkeit und Auditierbarkeit von Modellen verbessern. Sie können die Ressource, in der das Modell trainiert wurde (entweder eine Notizbuchsession oder ein Joblauf), und die Git-Referenz zum Trainingsquellcode dokumentieren. Diese Parameter werden automatisch extrahiert, wenn Sie ein Modell mit dem ADS-SDK speichern.

Wenn Sie in einem Git-Repository arbeiten, kann ADS Git-Informationen abrufen und die Metadatenfelder der Modellherkunft automatisch für Sie ausfüllen.

Taxonomie

Mit der Taxonomie können Sie das Modell beschreiben, das Sie im Modellkatalog speichern. Mit voreingestellten Feldern können Sie Folgendes dokumentieren:

• Anwendungsfall für maschinelles Lernen

• Framework des ML-Modells

• Version

• Schätzerobjekt

• Hyperparameter

• Artefakttestergebnisse

Sie können auch benutzerdefinierte Metadaten erstellen.

Modellintrospektionstests

Die Introspektion im Kontext von Modellen für maschinelles Lernen ist eine Reihe von Tests und Prüfungen, die mit einem Modellartefakt ausgeführt werden, um alle Aspekte des Betriebszustands des Modells zu testen. Diese Tests werden an den Dateien score.py und runtime.yaml mit dem Ziel durchgeführt, einige allgemeine Fehler und Probleme des Modellartefakts zu erfassen. Die Ergebnisse von Introspektionstests sind Teil der vordefinierten Modellmetadaten. Wenn Sie Ihr Modell mit der Konsole speichern, können Sie die Testergebnisse im JSON-Format im Feld "Artefakttestergebnisse" speichern, wenn Sie Modelltaxonomie dokumentieren auswählen. Wenn Sie das Modell mit dem OCI-Python-SDK speichern möchten, verwenden Sie den Metadatenschlüssel ArtifactTestResults.

Im Rahmen unserer Modellartefaktvorlage haben wir ein Python-Skript aufgenommen, das eine Reihe von Introspektionstestdefinitionen enthält. Diese Tests sind optional. Sie können sie ausführen, bevor Sie das Modell im Modellkatalog speichern. Anschließend können Sie die Testergebnisse als Teil der Modellmetadaten speichern, die in der OCI-Konsole angezeigt werden sollen.

Unser Data Science-Blog enthält weitere Informationen zur Verwendung der Modellintrospektion.

Ein- und Ausgabeschemas für Modelle

Die Schemadefinition ist eine Beschreibung der Features, die für eine erfolgreiche Modellvorhersage erforderlich sind. Die Schemadefinition ist ein Vertrag, der definiert, welche Eingabe-Payload die Clients des Modells bereitstellen müssen. Die Definitionen der Eingabe- und Ausgabeschemas werden in diesem Release des Modellkatalogs nur zu Dokumentationszwecken verwendet. Schemas haben das JSON-Dateiformat.

Sie können beide Schemas definieren. Für Modellvorhersagen ist mindestens ein Eingabeschema erforderlich.

Das Ausgabeschema ist möglicherweise nicht immer erforderlich. Beispiel: Wenn das Modell einen einfachen Gleitkommawert zurückgibt, ist die Definition eines Schemas für eine derartig einfache Ausgabe nicht unbedingt sinnvoll. Sie könnten diese Informationen in der Beschreibung des Modells übermitteln.