Snowflake Model Registry¶
Bemerkung
Die unter diesem Thema beschriebene Modell-Registry-API ist ab Paketversion 1.5.0 allgemein verfügbar.
Die Snowflake Model Registry ermöglicht das sichere Verwalten von Modellen und deren Metadaten in Snowflake, unabhängig von ihrem Ursprung. Die Modell-Registry speichert Machine-Learning-Modelle als First-Class-Objekte auf Schema-Ebene in Snowflake, sodass sie von anderen in Ihrer Organisation leicht gefunden und verwendet werden können. Unter Verwendung von Python-Klassen der Snowpark ML-Bibliothek können Sie Registrys erstellen und darin Modelle speichern. Modelle können mehrere Versionen haben, und Sie können eine Version als Standardversion festlegen.
Nachdem Sie ein Modell gespeichert haben, können Sie dessen Methoden (gleichbedeutend mit Funktionen oder gespeicherten Prozeduren) aufrufen, um Modelloperationen, wie z. B. Inferenzen, in einem virtuellen Warehouse von Snowflake auszuführen.
Tipp
Ein Beispiel für einen durchgängigen Workflow in Snowpark ML, einschließlich der Snowflake Model Registry, finden Sie unter Einführung in das maschinelle Lernen mit Snowpark ML.
Wenn Sie Modelle in Microsoft Azure Machine Learning oder in Amazon SageMaker haben, finden Sie entsprechende Informationen unter Bereitstellen von Modellen von Azure ML und SageMaker in Snowpark ML.
Die wichtigsten Klassen in der Snowflake Model Registry Python-API sind:
snowflake.ml.registry.Registry: Verwaltet Modelle innerhalb eines Schemas.
snowflake.ml.model.Model: Repräsentiert ein Modell.
snowflake.ml.model.ModelVersion: Repräsentiert eine Version eines Modells.
Die Snowflake Model Registry unterstützt die folgenden Typen von Modellen:
scikit-learn
XGBoost
LightGBM
CatBoost
PyTorch
TensorFlow
MLFlow PyFunc
Sentence Transformer
Hugging Face-Pipeline
Weitere Typen von Modellen über die Klasse
snowflake.ml.model.CustomModel
(siehe Speichern von kundenspezifischen Modellen in der Snowflake Model Registry).
Unter diesem Thema wird beschrieben, wie Sie mit Snowpark ML Registry-Operationen in Python ausführen können. Sie können viele Registry-Operationen auch in SQL ausführen (siehen Befehle für Modelle).
Erforderliche Berechtigungen¶
Um ein Modell zu erstellen, müssen Sie entweder Eigentümer des Schemas sein, in dem das Modell erstellt wird, oder über die Berechtigung CREATE MODEL für dieses Schema verfügen. Um ein Modell zu verwenden, müssen Sie entweder Eigentümer des Modells sein oder über die Berechtigung USAGE für das Modell verfügen. Die Berechtigung USAGE erlaubt es den Berechtigungsempfängern, das Modell für Inferenz zu nutzen, ohne dessen Interna einsehen zu können.
Wenn die Rolle eines Benutzers die USAGE-Berechtigung für ein Modell hat, wird es auf der Modell-Registry-Seite von Snowsight angezeigt. Weitere Details dazu finden Sie unter Zugriffssteuerungsrechte.
Bemerkung
Modelle unterstützen derzeit keine Replikation.
Aktuelle Beschränkungen und Probleme¶
Die Snowflake Model Registry weist derzeit die folgenden Einschränkungen auf:
Die Registry kann nicht in Snowflake Native Apps verwendet werden.
Modelle können nicht freigegeben oder geklont werden und werden bei der Replikation übersprungen.
Die Versionen 1.5.0 und 1.5.1 des snowflake-ml-python
-Pakets haben die folgenden bekannten Probleme. Bis diese Probleme behoben sind, können Sie die jeweils bereitgestellte Problemumgehung verwenden.
In Snowflake Release 8.23 und früher funktioniert die Bibliothek in gespeicherten Prozeduren mit Eigentümerrechten nicht. Verwenden Sie stattdessen gespeicherte Prozeduren mit Aufruferrechten.
In gespeicherten Prozeduren erfordert die Protokollierung eines Modells die Einbettung einer Kopie der lokalen Snowpark ML-Bibliothek in das Modell. Geben Sie die Option
embed_local_ml_library
in dem Aufruflog_model
wie gezeigt an:registry.log_model(..., options={"embed_local_ml_library": True, ...})
Die folgenden Beschränkungen gelten für Modelle und Modellversionen:
Modelle |
|
---|---|
Modell-Versionen |
|
Öffnen der Snowflake Model Registry¶
Modelle sind Snowflake-Objekte erster Klasse und können zusammen mit anderen Snowflake-Objekten in einer Datenbank und einem Schema organisiert werden. Die Snowflake Model Registry stellt eine Python-Klasse zum Verwalten von Modellen innerhalb eines Schemas bereit. Somit kann jedes Snowflake-Schema als Registry verwendet werden. Es ist nicht notwendig, ein Schema für diesen Zweck zu initialisieren oder anderweitig vorzubereiten. Snowflake empfiehlt das Erstellen eines oder mehrerer dedizierter Schemas für diesen Zweck, z. B. ML.REGISTRY. Sie können das Schema mit CREATE SCHEMA erstellen.
Bevor Sie Modelle in der Registry erstellen oder ändern können, müssen Sie die Registry öffnen. Wenn Sie die Registry öffnen, erhalten Sie eine Referenz auf die Registry, mit der Sie neue Modelle hinzufügen und Referenzen auf vorhandene Modelle erhalten können.
from snowflake.ml.registry import Registry
reg = Registry(session=sp_session, database_name="ML", schema_name="REGISTRY")
Registrieren von Modellen und Versionen¶
Das Hinzufügen eines Modells zur Registry wird als Protokollierung (Logging) des Modells bezeichnet. Ein Modell wird protokolliert, indem die log_model
-Methode der Registry aufgerufen wird. Diese Methode serialisiert das Modell — ein Python-Objekt — und erstellt daraus ein Snowflake-Modellobjekt. Diese Methode fügt dem Modell auch Metadaten, wie z. B. eine Beschreibung, hinzu, wie im log_model
-Aufruf angegeben.
Jedes Modell kann unbegrenzt viele Versionen haben. Um weitere Versionen des Modells zu protokollieren, rufen Sie log_model
erneut mit demselben model_name
-Wert, aber einem anderen version_name
-Wert auf.
Sie können einem Modell keine Tags hinzufügen, wenn es der Registry hinzugefügt wird, da Tags Attribute des Modells sind und log_model
eine bestimmte Modellversion hinzufügt, wobei es ein Modell nur beim Hinzufügen der ersten Version erstellt. Sie können aber nach der Protokollierung der ersten Version des Modells die Tags des Modells aktualisieren.
Im folgenden Beispiel ist clf
, kurz für „classifier“, das Python-Modellobjekt, das bereits an anderer Stelle in Ihrem Code erstellt wurde. Sie können beim Registrieren einen Kommentar und Tags hinzufügen, wie hier gezeigt. Die Kombination aus Name und Version muss im Schema eindeutig sein. Sie können conda_dependencies
-Listen angeben; die angegebenen Pakete werden mit dem Modell bereitgestellt.
mv = reg.log_model(clf,
model_name="my_model",
version_name="v1",
conda_dependencies=["scikit-learn"],
comment="My awesome ML model",
metrics={"score": 96},
sample_input_data=train_features,
task=type_hints.Task.TABULAR_BINARY_CLASSIFICATION)
Im Folgenden werden die Argumente von log_model
beschrieben.
Erforderliche Argumente
Argument |
Beschreibung |
---|---|
|
Das Python-Modellobjekt eines unterstützten Modelltyps. Muss serialisierbar („pickleable“) sein. |
|
Name des Modells, der zusammen mit |
Bemerkung
Die Kombination aus Modellname und Version muss im Schema eindeutig sein.
Optionale Argumente
Argument |
Beschreibung |
---|---|
|
Zeichenfolge, die die Version des Modells angibt und zusammen mit dem |
|
Liste der Pfade zu den Verzeichnissen des zu importierenden Codes beim Laden oder Bereitstellen des Modells. |
|
Kommentar, zum Beispiel eine Beschreibung des Modells. |
|
Liste der Conda-Pakete, die für das Modell erforderlich sind. Dieses Argument gibt Paketnamen und optionale Versionen im Conda-Format an, d. h. |
|
Liste der externen Module, die mit dem Modell serialisiert („pickled“) werden sollen. Unterstützt bei Scikit-learn, Snowpark ML, PyTorch, TorchScript und benutzerdefinierten Modellen. |
|
Dictionary mit Kennzahlen, die mit der Modellversion verknüpft sind. |
|
Dictionary mit Optionen für die Modellerstellung. Die folgenden Optionen sind für alle Modelltypen verfügbar.
Einzelne Modelltypen können zusätzliche Optionen unterstützen. Siehe Hinweise zu spezifischen Modelltypen. |
|
Liste der Paketspezifikationen für PyPI-Pakete, die für das Modell erforderlich sind. |
|
Python-Version, in der das Modell ausgeführt werden soll. Der Standardwert ist |
|
Ein DataFrame, das Stichproben-Eingabedaten enthält. Die für das Modell erforderlichen Feature-Namen (Merkmale) und deren Typen werden aus diesem DataFrame extrahiert. Bei allen Modellen außer Snowpark ML- und MLFlow-Modellen sowie Hugging Face-Pipelines muss entweder dieses Argument oder |
|
Methodensignaturen des Modells als Zuordnung des Namens der Zielmethode zu Signaturen von Eingabe und Ausgabe. Bei allen Modellen außer Snowpark ML- und MLFlow-Modellen sowie Hugging Face-Pipelines muss entweder dieses Argument oder |
|
Die Aufgabe, die das Problem definiert, das das Modell lösen soll. Wenn keine Angaben gemacht werden, wird versucht, die Modellaufgabe aus der Klasse des Modells abzuleiten, oder es wird |
log_model
gibt ein snowflake.ml.model.ModelVersion
-Objekt zurück, das die Version des Modells repräsentiert, die der Registry hinzugefügt wurde.
Nach der Registrierung kann das Modell selbst nicht mehr geändert werden (allerdings können seine Metadaten geändert werden). Um ein Modell und alle seine Versionen zu löschen, verwenden Sie die Methode delete_model der Registry.
Verwenden von Modellartefakten¶
Nachdem ein Modell protokolliert wurde, stehen seine Artefakte (die Dateien, die das Modell unterstützen, einschließlich seiner serialisierten Python-Objekte und verschiedener Metadaten-Dateien wie z. B. die Manifest-Datei) in einem internen Stagingbereich zur Verfügung. Artefakte können nicht verändert werden, aber Sie können die Artefakte der Modelle, deren Eigentümer Sie sind, anzeigen oder herunterladen.
Bemerkung
Wenn Sie die USAGE-Berechtigung für ein Modell haben, können Sie nicht auf dessen Artefakte zugreifen, da die Eigentümerschaft erforderlich ist.
Sie können auf Modellartefakte aus einem Stagingbereich zugreifen, indem Sie z. B. den Befehl GET oder sein Äquivalent in Snowpark Python FileOperation.get verwenden.
Allerdings können Sie Modellartefakte nicht mit der üblichen Syntax des Stagingbereichs verwenden. Verwenden Sie stattdessen eine snow://
-URL, was eine allgemeinere Methode zum Angeben des Speicherorts von Objekten in Snowflake ist. Beispielweise kann eine Version innerhalb eines Modells durch eine URL im Format snow://model/<model_name>/versions/<version_name>/
angegeben werden.
Wenn Sie den Namen des Modells und die gewünschte Version kennen, können Sie den Befehl LIST verwenden, um die Artefakte des Modells wie folgt anzuzeigen:
LIST 'snow://model/my_model/versions/V3/';
Die Ausgabe sieht wie folgt aus:
name size md5 last_modified
versions/V3/MANIFEST.yml 30639 2f6186fb8f7d06e737a4dfcdab8b1350 Thu, 18 Jan 2024 09:24:37 GMT
versions/V3/functions/apply.py 2249 e9df6db11894026ee137589a9b92c95d Thu, 18 Jan 2024 09:24:37 GMT
versions/V3/functions/predict.py 2251 132699b4be39cc0863c6575b18127f26 Thu, 18 Jan 2024 09:24:37 GMT
versions/V3/model.zip 721663 e92814d653cecf576f97befd6836a3c6 Thu, 18 Jan 2024 09:24:37 GMT
versions/V3/model/env/conda.yml 332 1574be90b7673a8439711471d58ec746 Thu, 18 Jan 2024 09:24:37 GMT
versions/V3/model/model.yaml 25718 33e3d9007f749bb2e98f19af2a57a80b Thu, 18 Jan 2024 09:24:37 GMT
Um eines dieser Artefakte abzurufen, verwenden Sie den SQL-Befehl GET:
GET 'snow://model/model_my_model/versions/V3/MANIFEST.yml'
Oder das Äquivalent in Snowpark Python:
session.file.get('snow://model/my_model/versions/V3/MANIFEST.yml', 'model_artifacts')
Bemerkung
Die Namen und die Organisation der Artefakte eines Modells können je nach Typ des Modells variieren und sich auch ändern. Das vorangehende Beispiel für eine Artefaktliste dient der Veranschaulichung und ist nicht verbindlich.
Löschen von Modellen¶
Verwenden Sie die delete_model
-Methode der Registry, um ein Modell und alle seine Versionen zu löschen:
reg.delete_model("mymodel")
Tipp
Sie können Modelle auch mit dem SQL-Befehl DROP MODEL löschen.
Abrufen von Modellen aus der Registry¶
Um Informationen zu jedem Modell zu erhalten, verwenden Sie die Methode show_models
:
model_df = reg.show_models()
Tipp
Verwenden Sie in SQL den Befehl SHOW MODELS, um eine Liste der Modelle zu erhalten.
Das Ergebnis von show_models
ist ein pandas-DataFrame. Die verfügbaren Spalten sind hier aufgelistet:
Spalte |
Beschreibung |
---|---|
|
Datum und Uhrzeit der Erstellung des Modells. |
|
Name des Modells. |
|
Datenbank, in der das Modell gespeichert ist. |
|
Schema, in dem das Modell gespeichert ist. |
|
Rolle, die Eigentümer des Modells ist. |
|
Kommentar zum Modell. |
|
JSON-Array mit den Versionen des Modells. |
|
Version des Modells, wenn auf das Modell ohne Versionsangabe verwiesen wird. |
Um stattdessen eine Liste der Modelle in der Registry zu erhalten, jedes als Model
-Instanz, verwenden Sie die Methode models
:
model_list = reg.models()
Um eine Referenz auf ein bestimmtes Modell aus der Registry über den Namen zu erhalten, verwenden Sie die Methode get_model
der Registry:
m = reg.get_model("MyModel")
Bemerkung
Model
-Instanzen sind keine Kopien des ursprünglichen protokollierten Python-Modellobjekts, sie sind Referenzen auf das zugrunde liegende Modellobjekt in der Registry.
Nachdem Sie einen Verweis auf ein Modell haben, entweder eines aus der von der Methode models
zurückgegebenen Liste oder eines, das mit get_model
abgerufen wurde, können Sie deren Metadaten und Versionen weiterverwenden.
Anzeigen und Aktualisieren der Metadaten eines Modells¶
Sie können die in der Registry vorliegenden Metadatenattribute eines Modells anzeigen und aktualisieren, einschließlich Name, Kommentar, Tags und Metriken.
Abrufen und Aktualisieren von Kommentaren¶
Verwenden Sie das Attribut comment
des Modells, um den Kommentar des Modells abzurufen und zu aktualisieren:
print(m.comment)
m.comment = "A better description than the one I provided originally"
Bemerkung
Das Attribut description
ist ein Synonym für comment
. Der vorherige Code kann auch auf diese Weise geschrieben werden:
print(m.description)
m.description = "A better description than the one I provided originally"
Tipp
Sie können auch den Kommentar eines Modells in SQL einstellen, indem Sie ALTER MODEL verwenden.
Umbenennen eines Modells¶
Verwenden Sie die Methode rename
, um ein Modell umzubenennen oder zu verschieben. Geben Sie einen vollqualifizierten Namen als neuen Namen an, um das Modell in eine andere Datenbank oder ein anderes Schema zu verschieben.
m.rename("MY_MODEL_TOO")
Tipp
Sie können ein Modell in SQL auch mit ALTER MODEL umbenennen.
Verwenden von Modellversionen¶
Ein Modell kann beliebig viele Versionen haben, die jeweils durch eine Zeichenfolge identifiziert sind. Sie können für den Versionsnamen jede beliebige Namenskonvention verwenden. Beim Protokollieren eines Modells wird eine spezifische Version des Modells protokolliert. Um weitere Versionen eines Modells zu protokollieren, rufen Sie log_model
erneut mit demselben model_name
-Wert, aber einem anderen version_name
-Wert auf.
Tipp
Verwenden Sie in SQL den Befehl SHOW VERSIONS IN MODEL, um die Versionen eines Modells anzuzeigen.
Eine Version eines Modells wird durch eine Instanz der Klasse snowflake.ml.model.ModelVersion
repräsentiert.
Um eine Liste aller Versionen eines Modells zu erhalten, rufen Sie die Methode versions
des Modellobjekts auf. Das Ergebnis ist eine Liste von ModelVersion
-Instanzen:
version_list = m.versions()
Um stattdessen Informationen zu jedem Modell als DataFrame zu erhalten, rufen Sie die Methode show_versions
des Modells auf:
version_df = m.show_versions()
Der Ergebnis-DataFrame enthält die folgenden Spalten:
Spalte |
Beschreibung |
---|---|
|
Datum und Uhrzeit der Erstellung der Modellversion. |
|
Name der Version. |
|
Datenbank, in der die Version gespeichert ist. |
|
Schema, in dem die Version gespeichert ist. |
|
Name des Modells, zu dem diese Version gehört. |
|
Boolescher Wert, der angibt, ob diese Version die Standardversion des Modells ist. |
|
JSON-Array mit den Namen der in dieser Version verfügbaren Funktionen. |
|
JSON-Objekt, das Metadaten als Schlüssel-Wert-Paare enthält ( |
|
JSON-Objekt aus dem Abschnitt |
Löschen von Modellversionen¶
Sie können eine Version eines Modells löschen, indem Sie die delete_version
-Methode des Modells verwenden:
m.delete_version("rc1")
Tipp
Sie können eine Version eines Modells auch in SQL löschen, indem Sie ALTER MODEL … DROP VERSION verwenden.
Standardversion¶
Eine Version eines Modells kann als Standardmodell festgelegt werden. Sie können das default
-Attribut des Modells abrufen oder festlegen, um die aktuelle Standardversion (als ModelVersion
-Objekt) zu erhalten bzw. zu ändern (unter Verwendung einer Zeichenfolge (String)):
default_version = m.default
m.default = "v2"
Tipp
In SQL verwenden Sie ALTER MODEL, um die Standardversion festzulegen.
Aliasse für Modellversionen¶
Sie können einer Modellversion einen Alias zuweisen, indem Sie den SQL ALTER MODEL-Befehl verwenden. Sie können einen Alias überall dort verwenden, wo ein Versionsname erforderlich ist, z. B. wenn Sie einen Verweis auf eine Modellversion in Python oder in SQL erhalten. Ein bestimmter Alias kann jeweils nur einer Modellversion zugewiesen werden.
Zusätzlich zu den von Ihnen erstellten Aliassen sind die folgenden System-Aliasse in allen Modellen verfügbar:
DEFAULT
bezieht sich auf die Standardversion des Modells.FIRST
bezieht sich auf die älteste Version des Modells gemäß Erstellungszeitpunkt.LAST
bezieht sich auf die neueste Version des Modells gemäß Erstellungszeitpunkt.
Aliasnamen, die Sie erstellen, dürfen nicht mit bestehenden Versionsnamen oder Aliassen im Modell übereinstimmen, einschließlich System-Aliassen.
Abrufen einer Referenz auf eine Modellversion¶
Um eine Referenz auf eine bestimmte Version eines Modells als ModelVersion
-Instanz zu erhalten, verwenden Sie die version
-Methode des Modells. Verwenden Sie das default
-Attribut des Modells, um die Standardversion des Modells abzurufen:
m = reg.get_model("MyModel")
mv = m.version("v1")
mv = m.default
Sobald Sie einen Verweis auf eine bestimmte Version eines Modells haben (wie die Variable mv
in diesem Beispiel), können Sie dessen Kommentare oder Kennzahlen abrufen oder aktualisieren und die Methoden (oder Funktionen) des Modells aufrufen, wie in den folgenden Abschnitten beschrieben.
Abrufen und Aktualisieren von Kommentaren¶
Wie bei Modellen können auch Modellversionen Kommentare haben, die über das Attribut comment
oder description
der Modellversion abgerufen und gesetzt werden können:
print(mv.comment)
print(mv.description)
mv.comment = "A model version comment"
mv.description = "Same as setting the comment"
Tipp
Sie können den Kommentar einer Version eines Modells auch in SQL ändern, indem Sie ALTER MODEL … MODIFY VERSION verwenden.
Abrufen und Aktualisieren von Kennzahlen¶
Kennzahlen (Metriken) sind Schlüssel-Wert-Paare, die dazu dienen, die Vorhersagegenauigkeit und andere Eigenschaften der Modellversion zu überwachen. Sie können die Kennzahlen beim Erstellen einer Modellversion oder mit der Methode set_metric
festlegen. Der Wert einer Kennzahl kann jedes Python-Objekt sein, das in JSON serialisiert werden kann, einschließlich Zahlen, Zeichenfolgen (Strings), Listen und Dictionarys. Im Gegensatz zu Tags müssen die Namen und möglichen Werte von Kennzahlen nicht im Voraus festgelegt werden.
Eine Kennzahl für die Testgenauigkeit kann mit accuracy_score
von sklearn erstellt werden:
from sklearn import metrics
test_accuracy = metrics.accuracy_score(test_labels, prediction)
Die Wahrheitsmatrix (Konfusionsmatrix) kann auf ähnliche Weise mit sklearn generiert werden:
test_confusion_matrix = metrics.confusion_matrix(test_labels, prediction)
Dann können Sie diese Werte als Metriken festlegen:
# scalar metric
mv.set_metric("test_accuracy", test_accuracy)
# hierarchical (dictionary) metric
mv.set_metric("evaluation_info", {"dataset_used": "my_dataset", "accuracy": test_accuracy, "f1_score": f1_score})
# multivalent (matrix) metric
mv.set_metric("confusion_matrix", test_confusion_matrix)
Um die Kennzahlen einer Modellversion als Python-Dictionary abzurufen, verwenden Sie show_metrics
:
metrics = mv.show_metrics()
Um eine Kennzahl zu löschen, rufen Sie delete_metric
auf:
mv.delete_metric("test_accuracy")
Tipp
Sie können auch die Metriken einer Modellversion (die als Metadaten gespeichert sind) in SQL ändern, indem Sie ALTER MODEL … MODIFY VERSION verwenden.
Abrufen von Erklärungen zum Modell¶
Die Modell-Registry kann die Ergebnisse eines Modells erklären und Ihnen sagen, welche Eingabe-Features am meisten zu den Vorhersagen beitragen, indem sie die Shapley-Werte berechnet. Dieses Feature für die Vorschau ist standardmäßig in allen Modellansichten verfügbar, die in Snowflake 8.31 und höher über die explain
-Methode des zugrunde liegenden Modells erstellt wurden. Sie können explain
von SQL oder über die run
-Methode einer Modellansicht in Python aufrufen.
Einzelheiten zu diesem Feature finden Sie unter Erklärbarkeit des Modells.
Exportieren einer Modellversion¶
Verwenden Sie mv.export
, um die Dateien eines Modells in ein lokales Verzeichnis zu exportieren; das Verzeichnis wird erstellt, wenn es nicht existiert:
mv.export("~/mymodel/")
Die exportierten Dateien enthalten standardmäßig den Code, die Umgebung zum Laden des Modells sowie die Modellgewichtungen. Um auch die Dateien zu exportieren, die für das Ausführen des Modells in einem Warehouse benötigt werden, geben Sie export_mode = ExportMode.FULL
an:
mv.export("~/mymodel/", export_mode=ExportMode.FULL)
Laden von Modellversionen¶
Verwenden Sie mv.load
, um das ursprüngliche Python-Modellobjekt zu laden, das ursprünglich der Registry hinzugefügt wurde. Sie können das Modell dann für Inferenz verwenden, als ob Sie es in Ihrem Python-Code definiert hätten:
clf = mv.load()
Um die ordnungsgemäße Funktionalität eines aus der Registry geladenen Modells sicherzustellen, sollte die Python-Zielumgebung (d. h. die Versionen des Python-Interpreters und aller Bibliotheken) mit der Umgebung identisch sein, aus der das Modell protokolliert wurde. Geben Sie force=True
im Aufruf von load
an, um zu erzwingen, dass das Modell geladen wird, auch wenn die Umgebung anders ist.
Tipp
Um sicherzustellen, dass Ihre Umgebung mit derjenigen übereinstimmt, in der das Modell gehostet wird, laden Sie eine Kopie der conda Umgebung aus der Modell-Registry herunter:
conda_env = session.file.get("snow://model/<modelName>/versions/<versionName>/runtimes/python_runtime/env/conda.yml", ".")
open("~/conda.yml", "w").write(conda_env)
Erstellen Sie dann eine neue conda-Umgebung aus dieser Datei:
conda env create --name newenv --file=~/conda.yml
conda activate newenv
Das optionale Argument options
ist ein Dictionary mit Optionen zum Laden des Modells. Derzeit unterstützt das Argument nur die Option use_gpu
.
Option |
Typ |
Beschreibung |
Standard |
---|---|---|---|
|
|
Aktiviert die GPU-spezifische Ladelogik. |
|
Das folgende Beispiel veranschaulicht die Verwendung des options
-Arguments:
clf = mv.load(options={"use_gpu": True})
Aufrufen von Modellmethoden¶
Modellversionen können Methoden haben, d. h. angehängte Funktionen, die ausgeführt werden können, um Inferenzen oder andere Modelloperationen auszuführen. Die Versionen eines Modells können unterschiedliche Methoden haben, und auch die Signaturen dieser Methoden können sich unterscheiden.
Um eine Methode einer Modellversion aufzurufen, verwenden Sie mv.run
, geben den Namen der aufzurufenden Funktion an und übergeben einen Snowpark- oder pandas-DataFrame, der die Inferenzdaten und alle anderen erforderlichen Parameter enthält. Die Methode wird in einem Snowflake-Warehouse ausgeführt.
Der Rückgabewert der Methode ist ein Snowpark- oder pandas-DataFrame, je nach dem Typ des übergebenen DataFrame. Snowpark-DataFrames wird im Lazy-Modus ausgewertet, d. h. die Methode wird nur ausgeführt, wenn die DataFrame-Methode collect
, show
oder to_pandas
aufgerufen wird.
Bemerkung
Beim Aufrufen einer Methode wird diese in dem Warehouse ausgeführt, das in der Sitzung angegeben ist, die Sie für die Verbindung mit der Registry verwenden. Siehe Angeben eines Warehouses.
Im folgenden Beispiel wird die Ausführung der Methode predict
eines Modells gezeigt. Die predict
-Methode dieses Modells benötigt zusätzlich zu den Inferenzdaten (hier test_features
) keine weiteren Parameter. Wenn dies der Fall wäre, würden sie als zusätzliche Argumente nach den Inferenzdaten übergeben werden:
remote_prediction = mv.run(test_features, function_name="predict")
remote_prediction.show() # assuming test_features is Snowpark DataFrame
Um zu erfahren, welche Methoden für ein bestimmtes Modell aufgerufen werden können, rufen Sie mv.show_functions
auf. Der Rückgabewert dieser Methode ist eine Liste von ModelFunctionInfo
-Objekten. Jedes dieser Objekte enthält die folgenden Attribute:
name
: Name der Funktion, die von Python oder SQL aufgerufen werden kann.target_method
: Name der Python-Methode in dem ursprünglich protokollierten Modell.
Tipp
Sie können Modellmethoden auch in SQL aufrufen. Siehe Methoden für Modelle.
Hinweise zu Kosten¶
Für die Verwendung der Snowflake Model Registry fallen die üblichen verbrauchsabhängigen Kosten von Snowflake an. Dazu zählen:
Kosten für die Speicherung von Modellartefakten, Metadaten und Funktionen. Allgemeine Informationen zu den Kosten für den Speicher finden Sie unter Untersuchen der Speicherkosten.
Kosten für das Kopieren von Dateien zwischen Stagingbereichen und Snowflake. Siehe COPY FILES.
Kosten für serverlose Modellobjektoperationen über die Snowsight-UI oder die SQL- oder Python-Schnittstelle, z. B. das Anzeigen von Modellen und Modellversionen und das Ändern der Kommentare, Tags und Kennzahlen von Modellen.
Warehouse-Computekosten, die je nach Typ des Modells und der Menge der für Interferenz verwendeten Daten variieren. Allgemeine Informationen zu den Snowflake-Computekosten finden Sie unter Erläuterungen zu den Computekosten. Warehouse-Computekosten fallen bei:
Operationen zum Erstellen von Modellen und Versionen
Aufrufen der Methoden eines Modells
Hinweise zu spezifischen Modelltypen¶
In diesem Abschnitt finden Sie zusätzliche Informationen zum Protokollieren bestimmter Modelltypen in der Snowflake Model Registry.
Snowpark ML¶
Die Registry unterstützt Modelle, die mit Snowpark ML-Modellierungs-APIs (von snowpark.ml.modeling.framework.base.BaseEstimator
abgeleitete Modelle) erstellt wurden. Die folgenden zusätzlichen Optionen können im options
-Dictionary verwendet werden, wenn Sie log_model
abrufen:
Option |
Beschreibung |
---|---|
|
Liste mit den Namen der für das Modellobjekt verfügbaren Methoden. Snowpark ML-Modelle haben standardmäßig die folgenden Zielmethoden, vorausgesetzt, die Methode existiert: |
Beim Protokollieren eines Snowpark ML-Modells müssen Sie sample_input_data
oder signatures
nicht angeben. Diese Werte werden während der Anpassung automatisch abgeleitet.
Beispiel¶
import pandas as pd
import numpy as np
from sklearn import datasets
from snowflake.ml.modeling.xgboost import XGBClassifier
iris = datasets.load_iris()
df = pd.DataFrame(data=np.c_[iris["data"], iris["target"]], columns=iris["feature_names"] + ["target"])
df.columns = [s.replace(" (CM)", "").replace(" ", "") for s in df.columns.str.upper()]
input_cols = ["SEPALLENGTH", "SEPALWIDTH", "PETALLENGTH", "PETALWIDTH"]
label_cols = "TARGET"
output_cols = "PREDICTED_TARGET"
clf_xgb = XGBClassifier(
input_cols=input_cols, output_cols=output_cols, label_cols=label_cols, drop_input_cols=True
)
clf_xgb.fit(df)
model_ref = registry.log_model(
clf_xgb,
model_name="XGBClassifier",
version_name="v1",
)
model_ref.run(df.drop(columns=label_cols).head(10), function_name='predict_proba')
scikit-learn¶
Die Registry unterstützt Modelle, die mit Scikit-learn erstellt wurden (von sklearn.base.BaseEstimator
oder sklearn.pipeline.Pipeline
abgeleitete Modelle). Die folgenden zusätzlichen Optionen können im options
-Dictionary verwendet werden, wenn Sie log_model
abrufen:
Option |
Beschreibung |
---|---|
|
Liste der Namen der Methoden, die für das Modellobjekt verfügbar sind. Scikit-learn-Modelle haben standardmäßig die folgenden Zielmethoden, vorausgesetzt, die Methode existiert: |
Sie müssen entweder den Parameter sample_input_data
oder signatures
angeben, wenn Sie ein Scikit-learn-Modell protokollieren, damit die Registry die Signaturen der Zielmethoden kennt.
Beispiel¶
from sklearn import datasets, ensemble
iris_X, iris_y = datasets.load_iris(return_X_y=True, as_frame=True)
clf = ensemble.RandomForestClassifier(random_state=42)
clf.fit(iris_X, iris_y)
model_ref = registry.log_model(
clf,
model_name="RandomForestClassifier",
version_name="v1",
sample_input_data=iris_X,
options={
"method_options": {
"predict": {"case_sensitive": True},
"predict_proba": {"case_sensitive": True},
"predict_log_proba": {"case_sensitive": True},
}
},
)
model_ref.run(iris_X[-10:], function_name='"predict_proba"')
XGBoost¶
Die Registry unterstützt Modelle, die mit XGBoost erstellt wurden (von xgboost.XGBModel
oder xgboost.Booster
abgeleitete Modelle). Die folgenden zusätzlichen Optionen können im options
-Dictionary verwendet werden, wenn Sie log_model
abrufen:
Option |
Beschreibung |
---|---|
|
Liste mit den Namen der für das Modellobjekt verfügbaren Methoden. Von |
|
Die Version der CUDA-Laufzeitumgebung, die beim Bereitstellen auf einer Plattform mit GPU verwendet werden soll. Der Standardwert ist 11.7. Wird das Modell manuell auf |
Beim Protokollieren eines XGBoost-Modells müssen Sie entweder den Parameter sample_input_data
oder signatures
angeben, damit die Registry die Signaturen der Zielmethoden kennt.
Beispiel¶
import xgboost
from sklearn import datasets, model_selection
cal_X, cal_y = datasets.load_breast_cancer(as_frame=True, return_X_y=True)
cal_X_train, cal_X_test, cal_y_train, cal_y_test = model_selection.train_test_split(cal_X, cal_y)
params = dict(n_estimators=100, reg_lambda=1, gamma=0, max_depth=3, objective="binary:logistic")
regressor = xgboost.train(params, xgboost.DMatrix(data=cal_X_train, label=cal_y_train))
model_ref = registry.log_model(
regressor,
model_name="xgBooster",
version_name="v1",
sample_input_data=cal_X_test,
options={
"target_methods": ["predict"],
"method_options": {
"predict": {"case_sensitive": True},
},
},
)
model_ref.run(cal_X_test[-10:])
PyTorch¶
Die Registry unterstützt PyTorch-Modelle (von torch.nn.Module
oder torch.jit.ModuleScript
abgeleitete Klassen), wenn die forward
-Methode des Modells eine oder mehrere torch.Tensor
-Instanzen als Eingabe akzeptiert und einen torch.Tensor
-Wert oder ein Tupel davon zurückgibt. Die Registry konvertiert zwischen pandas-DataFrames und Tensoren, wenn sie das Modell aufruft und die Ergebnisse zurückgibt. Tensoren entsprechen den Spalten im Datenframe.
Angenommen, Ihr Modell akzeptiert zwei Tensoren wie die folgenden:
import torch
class TorchModel(torch.nn.Module):
def __init__(self, n_input: int, n_hidden: int, n_out: int, dtype: torch.dtype = torch.float32) -> None:
super().__init__()
self.model = torch.nn.Sequential(
torch.nn.Linear(n_input, n_hidden, dtype=dtype),
torch.nn.ReLU(),
torch.nn.Linear(n_hidden, n_out, dtype=dtype),
torch.nn.Sigmoid(),
)
def forward(self, tensor_1: torch.Tensor, tensor_2: torch.Tensor) -> torch.Tensor:
return self.model(tensor_1) + self.model(tensor_2)
Wenn Sie torch.Tensor([[1,2],[3,4]])
als tensor_1
und torch.Tensor([[5,6], [7,8]])
als tensor_2
übergeben möchten, erstellen Sie eine DataFrame wie diese, um sie an das Modell zu übergeben:
import pandas as pd
tensors = pd.DataFrame([[[1,2],[5,6]],[[3,4],[7,8]]])
Das tensors
-DataFrame sieht dann wie folgt aus:
0 1
0 [1, 2] [5, 6]
1 [3, 4] [7, 8]
Ähnlich verhält es sich, wenn Ihr Modell zwei Tensoren zurückgibt, z. B. (torch.Tensor([[1,2],[3,4]]), torch.Tensor([[5,6], [7,8]]))
: Das Ergebnis ist ein DataFrame wie der obige.
Wenn Sie eine Stichprobe als Eingabedaten für ein PyTorch-Modell bereitstellen, müssen Sie entweder eine Liste von Tensoren (die in einen pandas-DataFrame umgewandelt werden) oder einen DataFrame bereitstellen. Eine Liste kann einen einzelnen Tensor enthalten, aber ein Tensor allein wird nicht akzeptiert.
Protokollieren des Modells¶
Die folgenden zusätzlichen Optionen können im options
-Dictionary verwendet werden, wenn Sie log_model
abrufen:
Option |
Beschreibung |
---|---|
|
Liste mit den Namen der für das Modellobjekt verfügbaren Methoden. Der Standardwert bei PyTorch-Modellen ist |
|
Die Version der CUDA-Laufzeitumgebung, die beim Bereitstellen auf einer Plattform mit GPU verwendet werden soll. Der Standardwert ist 11.7. Wird das Modell manuell auf |
Sie müssen entweder den Parameter sample_input_data
oder signatures
angeben, wenn Sie ein PyTorch-Modell protokollieren, damit die Registry die Signaturen der Zielmethoden kennt.
Beispiel¶
import torch
import numpy as np
class TorchModel(torch.nn.Module):
def __init__(self, n_input: int, n_hidden: int, n_out: int, dtype: torch.dtype = torch.float32) -> None:
super().__init__()
self.model = torch.nn.Sequential(
torch.nn.Linear(n_input, n_hidden, dtype=dtype),
torch.nn.ReLU(),
torch.nn.Linear(n_hidden, n_out, dtype=dtype),
torch.nn.Sigmoid(),
)
def forward(self, tensor: torch.Tensor) -> torch.Tensor:
return self.model(tensor)
n_input, n_hidden, n_out, batch_size, learning_rate = 10, 15, 1, 100, 0.01
dtype = torch.float32
x = np.random.rand(batch_size, n_input)
data_x = torch.from_numpy(x).to(dtype=dtype)
data_y = (torch.rand(size=(batch_size, 1)) < 0.5).to(dtype=dtype)
model = TorchModel(n_input, n_hidden, n_out, dtype=dtype)
loss_function = torch.nn.MSELoss()
optimizer = torch.optim.SGD(model.parameters(), lr=learning_rate)
for _epoch in range(100):
pred_y = model.forward(data_x)
loss = loss_function(pred_y, data_y)
optimizer.zero_grad()
loss.backward()
optimizer.step()
model_ref = registry.log_model(
model,
model_name="torchModel",
version_name="v1",
sample_input_data=[data_x],
)
model_ref.run([data_x])
TensorFlow¶
Modelle, die tensorflow.Module
oder tensorflow.keras.Model
erweitern, werden unterstützt, wenn sie Tensoren akzeptieren und zurückgeben und kompilierbar oder bereits kompiliert sind.
Die
__call__
-Methode für einentensorflow.Module
-Wert oder diecall
-Methode für einentensorflow.keras.Model
-Wert akzeptiert einen oder mehreretensorflow.Tensor
-Werte odertensorflow.Variable
-Werte als Eingabe und gibt einentensorflow.Tensor
- odertensorflow.Variable
-Wert oder ein Tupel eines dieser Typen zurück.Wenn Ihr Modell
Module
erweitert, muss es kompilierbar sein, d. h. die__call__
-Methode ist mit@tensorflow.function
dekoriert. Siehe tf.function-Dokumentation. Wenn esModel
erweitert, muss es kompiliert werden. Siehe Dokumentation zum Kompilieren.
Die Registry konvertiert zwischen pandas-DataFrames und Tensoren, wenn sie das Modell aufruft und die Ergebnisse zurückgibt. Tensoren entsprechen den Spalten im Datenframe.
Angenommen, Ihr Modell akzeptiert zwei Tensoren wie die folgenden:
import tensorflow as tf
class KerasModel(tf.keras.Model):
def __init__(self, n_hidden: int, n_out: int) -> None:
super().__init__()
self.fc_1 = tf.keras.layers.Dense(n_hidden, activation="relu")
self.fc_2 = tf.keras.layers.Dense(n_out, activation="sigmoid")
def call(self, tensor_1: tf.Tensor, tensor_2: tf.Tensor) -> tf.Tensor:
input = tensor_1 + tensor_2
x = self.fc_1(input)
x = self.fc_2(x)
return x
Wenn Sie tf.Tensor([[1,2],[3,4]])
als tensor_1
und tf.Tensor([[5,6], [7,8]])
als tensor_2
übergeben möchten, erstellen Sie eine DataFrame wie diese, um sie an das Modell zu übergeben:
import pandas as pd
tensors = pd.DataFrame([[[1,2],[5,6]],[[3,4],[7,8]]])
Das tensors
-DataFrame sieht dann wie folgt aus:
0 1
0 [1, 2] [5, 6]
1 [3, 4] [7, 8]
Ähnlich verhält es sich, wenn Ihr Modell zwei Tensoren zurückgibt, z. B. (tf.Tensor([[1,2],[3,4]]), tf.Tensor([[5,6], [7,8]]))
: Das Ergebnis ist ein DataFrame wie der obige.
Wenn Sie eine Stichprobe als Eingabedaten für ein TensorFlow-Modell bereitstellen, müssen Sie entweder eine Liste von Tensoren (die in einen pandas-DataFrame umgewandelt werden) oder einen DataFrame bereitstellen. Eine Liste kann einen einzelnen Tensor enthalten, aber ein Tensor allein wird nicht akzeptiert.
Protokollieren des Modells¶
Die folgenden zusätzlichen Optionen können im options
-Dictionary verwendet werden, wenn Sie log_model
abrufen:
Option |
Beschreibung |
---|---|
|
Liste mit den Namen der für das Modellobjekt verfügbaren Methoden. Der Standardwert bei TensorFlow-Modellen ist |
|
Die Version der CUDA-Laufzeitumgebung, die beim Bereitstellen auf einer Plattform mit GPU verwendet werden soll. Der Standardwert ist 11.7. Wird das Modell manuell auf |
Sie müssen entweder den Parameter sample_input_data
oder signatures
angeben, wenn Sie ein TensorFlow-Modell protokollieren, damit die Registry die Signaturen der Zielmethoden kennt.
Beispiel¶
import tensorflow as tf
import numpy as np
class KerasModel(tf.keras.Model):
def __init__(self, n_hidden: int, n_out: int) -> None:
super().__init__()
self.fc_1 = tf.keras.layers.Dense(n_hidden, activation="relu")
self.fc_2 = tf.keras.layers.Dense(n_out, activation="sigmoid")
def call(self, tensor: tf.Tensor) -> tf.Tensor:
input = tensor
x = self.fc_1(input)
x = self.fc_2(x)
return x
n_input, n_hidden, n_out, batch_size, learning_rate = 10, 15, 1, 100, 0.01
dtype = tf.float32
x = np.random.rand(batch_size, n_input)
data_x = tf.convert_to_tensor(x, dtype=dtype)
raw_data_y = tf.random.uniform((batch_size, 1))
raw_data_y = tf.where(raw_data_y > 0.5, tf.ones_like(raw_data_y), tf.zeros_like(raw_data_y))
data_y = tf.cast(raw_data_y, dtype=dtype)
model = KerasModel(n_hidden, n_out)
model.compile(optimizer=tf.keras.optimizers.SGD(learning_rate=learning_rate), loss=tf.keras.losses.MeanSquaredError())
model.fit(data_x, data_y, batch_size=batch_size, epochs=100)
model_ref = registry.log_model(
model,
model_name="tfModel",
version_name="v1",
sample_input_data=[data_x],
)
model_ref.run([data_x])
MLFlow¶
MLFlow-Modelle, die eine PyFunc-Konfiguration bereitstellen, werden unterstützt. Wenn Ihr MLFlow-Modell eine Signatur hat, wird das signature
-Argument aus dem Modell abgeleitet. Andernfalls müssen Sie entweder signature
oder sample_input_data
angeben.
Die folgenden zusätzlichen Optionen können im options
-Dictionary verwendet werden, wenn Sie log_model
abrufen:
Option |
Beschreibung |
---|---|
|
Die URI der Artefakte des MLFlow-Modells. Muss angegeben werden, wenn es in den Metadaten des Modells nicht als |
|
Wenn |
|
Wenn |
Beispiel¶
import mlflow
from sklearn import datasets, model_selection, ensemble
db = datasets.load_diabetes(as_frame=True)
X_train, X_test, y_train, y_test = model_selection.train_test_split(db.data, db.target)
with mlflow.start_run() as run:
rf = ensemble.RandomForestRegressor(n_estimators=100, max_depth=6, max_features=3)
rf.fit(X_train, y_train)
# Use the model to make predictions on the test dataset.
predictions = rf.predict(X_test)
signature = mlflow.models.signature.infer_signature(X_test, predictions)
mlflow.sklearn.log_model(
rf,
"model",
signature=signature,
)
run_id = run.info.run_id
model_ref = registry.log_model(
mlflow.pyfunc.load_model(f"runs:/{run_id}/model"),
model_name="mlflowModel",
version_name="v1",
conda_dependencies=["mlflow<=2.4.0", "scikit-learn", "scipy"],
options={"ignore_mlflow_dependencies": True}
)
model_ref.run(X_test)
Hugging Face-Pipeline¶
Bemerkung
Einzelheiten zu den erwarteten Eingaben und Ausgaben bestimmter Typen von Hugging Face-Pipelines finden Sie unter Abgeleitete Signaturen für Hugging Face-Pipelines.
Die Registry unterstützt Hugging Face-Modellklassen, die als Transformer definiert sind, die von transformers.Pipeline
abgeleitet sind. Der folgende Code ist ein Beispiel für das Protokollieren eines kompatiblen Modells:
lm_hf_model = transformers.pipeline(
task="text-generation",
model="bigscience/bloom-560m",
token="...", # Put your HuggingFace token here.
return_full_text=False,
max_new_tokens=100,
)
lmv = reg.log_model(lm_hf_model, model_name='bloom', version_name='v560m')
Wichtig
Ein auf huggingface_pipeline.HuggingFacePipelineModel
basierendes Modell enthält nur Konfigurationsdaten. Die Modellgewichtungen werden bei jeder Verwendung des Modells vom Hugging Face Hub heruntergeladen.
Die Modell-Registry unterstützt derzeit nur die Bereitstellung von Modellen für Warehouses. Warehouses unterstützen einen Zugriff auf externe Netzwerke nur mit spezieller Konfiguration. Selbst wenn die erforderlichen Integrationen für den externen Zugriff erstellt wurden, gibt es derzeit keine Möglichkeit, anzugeben, welche Integrationen ein bestimmtes Modell benötigt.
Die derzeit Best Practice ist, stattdessen transformers.Pipeline
zu verwenden, wie im obigen Beispiel gezeigt. Dadurch werden die Modellgewichtungen auf Ihr lokales System heruntergeladen und das gesamte Modell in das Warehouse hochgeladen. Das Ergebnis ist ein in sich geschlossenes Modell, das keinen Internetzugang benötigt.
Die Registry leitet das signatures
-Argument nur ab, wenn die Pipeline eine Aufgabe enthält, die in der folgenden Liste aufgeführt sind:
conversational
fill-mask
question-answering
summarization
table-question-answering
text2text-generation
text-classification
(auchsentiment-analysis
genannt)text-generation
token-classification
(auchner
genannt)translation
translation_xx_to_yy
zero-shot-classification
Das Argument sample_input_data
wird bei Hugging Face-Modellen komplett ignoriert. Geben Sie das Argument signatures
an, wenn Sie ein Hugging Face-Modell protokollieren, das nicht in der obigen Liste enthalten ist, damit die Registry die Signaturen der Zielmethoden kennt.
Zum Anzeigen der abgeleiteten Signatur können Sie die show_functions
-Methode verwenden. Der folgende Code ist zum Beispiel das Ergebnis von lmv.show_functions()
, wobei lmv
das oben protokollierte Modell ist:
{'name': '__CALL__',
'target_method': '__call__',
'signature': ModelSignature(
inputs=[
FeatureSpec(dtype=DataType.STRING, name='inputs')
],
outputs=[
FeatureSpec(dtype=DataType.STRING, name='outputs')
]
)}]
Mit diesen Informationen können Sie das Modell wie folgt aufrufen:
import pandas as pd
remote_prediction = lmv.run(pd.DataFrame(["Hello, how are you?"], columns=["inputs"]))
Nutzungshinweise¶
Viele Hugging Face-Modelle sind groß und passen nicht in ein Standard-Warehouse. Verwenden Sie ein Snowpark-optimiertes Warehouse, oder wählen Sie eine kleinere Version des Modells aus. Versuchen Sie zum Beispiel, statt des Modells
Llama-2-70b-chat-hf
das ModellLlama-2-7b-chat-hf
zu verwenden.Snowflake-Warehouses haben keine GPUs. Verwenden Sie nur CPU-optimierte Hugging Face-Modelle.
Einige Hugging Face-Transformatoren geben pro Eingabezeile ein Array von Dictionarys zurück. Die Registry konvertiert solche Ausgaben in eine Zeichenfolge, die eine JSON-Repräsentation des Arrays enthält. Die Mehrfach-Ausgabe der Fragebeantwortungsausgabe sieht zum Beispiel so aus:
[{"score": 0.61094731092453, "start": 139, "end": 178, "answer": "learn more about the world of athletics"}, {"score": 0.17750297486782074, "start": 139, "end": 180, "answer": "learn more about the world of athletics.\""}]
Sie müssen entweder den Parameter sample_input_data
oder signatures
angeben, wenn Sie ein Hugging Face-Modell protokollieren, damit die Registry die Signaturen der Zielmethoden kennt.
Beispiel¶
# Prepare model
import transformers
import pandas as pd
finbert_model = transformers.pipeline(
task="text-classification",
model="ProsusAI/finbert",
top_k=2,
)
# Log the model
mv = registry.log_model(
finbert_model,
model_name="finbert",
version_name="v1",
)
# Use the model
mv.run(pd.DataFrame(
[
["I have a problem with my Snowflake that needs to be resolved asap!!", ""],
["I would like to have udon for today's dinner.", ""],
]
)
)
Ergebnis:
0 [{"label": "negative", "score": 0.8106237053871155}, {"label": "neutral", "score": 0.16587384045124054}]
1 [{"label": "neutral", "score": 0.9263970851898193}, {"label": "positive", "score": 0.05286872014403343}]