Run Klasse
Definiert die Basisklasse für alle Azure Machine Learning-Experimentausführungen.
Ein Run-Objekt repräsentiert die Ausführung eines einzelnen Testlauf eines Experiments. Ausführungen werden verwendet, um die asynchrone Ausführung einer Testversion zu überwachen, Metriken zu protokollieren und die Ausgabe der Testversion zu speichern sowie um die Ergebnisse zu analysieren und auf Artefakte zuzugreifen, die von der Testversion generiert wurden.
Ausführungsobjekte werden erstellt, wenn Sie ein Skript übermitteln, um ein Modell in vielen verschiedenen Szenarien in Azure Machine Learning zu trainieren, einschließlich HyperDrive-Ausführungen, Pipelineausführungen und AutoML-Ausführungen. Ein Ausführungsobjekt wird auch erstellt, wenn Sie submit oder start_logging mit der Experiment-Klasse ausführen.
Informationen zu den ersten Experimenten und Ausführungen finden Sie hier:
Initialisieren Sie das Run-Objekt.
- Vererbung
-
azureml._run_impl.run_base._RunBaseRun
Konstruktor
Run(experiment, run_id, outputs=None, **kwargs)
Parameter
Name | Beschreibung |
---|---|
experiment
Erforderlich
|
Das enthaltende Experiment. |
run_id
Erforderlich
|
Die ID der Ausführung. |
outputs
|
Die nachzuverfolgenden Ausgaben. Standardwert: None
|
_run_dto
Erforderlich
|
<xref:azureml._restclient.models.run_dto.RunDto>
Nur interne Verwendung. |
kwargs
Erforderlich
|
Ein Wörterbuch mit zusätzlichen Konfigurationsparametern. |
experiment
Erforderlich
|
Das enthaltende Experiment. |
run_id
Erforderlich
|
Die ID der Ausführung. |
outputs
Erforderlich
|
Die nachzuverfolgenden Ausgaben. |
kwargs
Erforderlich
|
Ein Wörterbuch mit zusätzlichen Konfigurationsparametern. |
Hinweise
Ein Run-Objekt repräsentiert die Ausführung eines einzelnen Testlauf eines Experiments. Ein Ausführungsobjekt dient dazu, die asynchrone Ausführung eines Testlaufs zu überwachen, Metriken zu protokollieren und die Ausgabe des Testlaufs zu speichern. Außerdem analysiert es die Ergebnisse und greift auf die Artefakte zu, die beim Testlauf generiert wurden.
Die Ausführung wird im Experimentiercode verwendet, um Metriken und Artefakte im Ausführungsverlaufsdienst zu protokollieren.
Die Ausführung wird außerhalb Ihrer Experimente verwendet, um den Fortschritt zu überwachen und die generierten Metriken und Ergebnisse abzufragen und zu analysieren.
Zur Funktionalität einer der Klasse Run gehört Folgendes:
Speichern und Abrufen von Metriken und Daten
Hoch- und Herunterladen von Dateien
Unkompliziertes Suchen nach früheren Ausführungen mithilfe von Tags und der untergeordneten Hierarchie
Registrieren gespeicherter Modelldateien als Modell, das operationalisiert werden kann
Speichern, Ändern und Abrufen von Eigenschaften einer Ausführung
Laden der aktuellen Ausführung aus einer Remoteumgebung mithilfe der get_context-Methode
Effizientes Erstellen einer Momentaufnahme einer Datei oder eines Verzeichnisses zum Reproduzieren
Diese Klasse nutzt Experiment in den folgenden Szenarios:
Erstellen einer Ausführung durch Ausführen von Code mithilfe von submit
Interaktives Erstellen einer Ausführung in einem Notebook mithilfe von start_logging
Protokollieren von Metriken und Hochladen von Artefakten in Ihrem Experiment, z. B. bei Verwendung von log
Lesen von Metriken und Herunterladen von Artefakten beim Analysieren von Experimentergebnissen, z. B. bei Verwendung von get_metrics
Um eine Ausführung zu übermitteln, erstellen Sie ein Konfigurationsobjekt, das beschreibt, wie das Experiment ausgeführt wird. Im Folgenden finden Sie Beispiele für die verschiedenen Konfigurationsobjekte, die Sie verwenden können:
azureml.train.automl.automlconfig.AutoMLConfig
azureml.train.hyperdrive.HyperDriveConfig
azureml.pipeline.core.Pipeline
azureml.pipeline.core.PublishedPipeline
azureml.pipeline.core.PipelineEndpoint
Die folgenden Metriken können während des Trainings eines Experiments zu einem Durchlauf hinzugefügt werden.
Skalar
Protokollieren Sie einen Zahlen- oder Zeichenfolgenwert für die Ausführung unter dem jeweiligen Namen unter Verwendung von log. Wenn Sie eine Metrik für eine Ausführung protokollieren, wird diese Metrik in der Ausführungsaufzeichnung des Experiments gespeichert. Sie können dieselbe Metrik innerhalb einer Ausführung mehrmals protokollieren, wobei das Ergebnis als Vektor dieser Metrik betrachtet wird.
Ein Beispiel:
run.log("accuracy", 0.95)
Liste
Protokollieren einer Liste mit Werten für die Ausführung unter dem jeweiligen Namen unter Verwendung von log_list.
Ein Beispiel:
run.log_list("accuracies", [0.6, 0.7, 0.87])
Zeile
Mithilfe von log_row wird eine Metrik mit mehreren Spalten erstellt, wie in
kwargs
beschrieben. Jeder benannte Parameter erzeugt eine Spalte mit dem angegebenen Wert.log_row
kann einmal aufgerufen werden, um ein beliebiges Tupel zu protokollieren, oder mehrmals in einer Schleife, um eine vollständige Tabelle zu erzeugen.Ein Beispiel:
run.log_row("Y over X", x=1, y=0.4)
Tabelle
Protokollieren eines Wörterbuchobjekts in der Ausführung mit dem angegebenen Namen unter Verwendung von log_table.
Ein Beispiel:
run.log_table("Y over X", {"x":[1, 2, 3], "y":[0.6, 0.7, 0.89]})
Image
Protokollieren Sie ein Image für die Ausführungsaufzeichnung. Verwenden Sie log_image, um eine Imagedatei oder einen Matplotlib-Plot für die Ausführung zu protokollieren. Diese Images werden angezeigt und können mit der Ausführungsaufzeichnung verglichen werden.
Ein Beispiel:
run.log_image("ROC", path)
Methoden
add_properties |
Der Ausführung unveränderliche Eigenschaften hinzufügen. Tags und Eigenschaften (beide dict[str, str]) unterscheiden sich in ihrer Veränderlichkeit. Eigenschaften sind unveränderlich, sodass sie eine permanente Aufzeichnung zu Überwachungszwecken erstellen. Tags sind veränderlich. Weitere Informationen zum Arbeiten mit Tags und Eigenschaften finden Sie unter Markieren und Suchen von Ausführungen. |
add_type_provider |
Erweiterbarkeitshook für benutzerdefinierte Ausführungstypen, die im Ausführungsverlauf gespeichert sind. |
cancel |
Die Ausführung als abgebrochen markieren. Etwaige zugeordnete Aufträge mit einem gesetzten „cancel_uri“-Feld werden ebenso beendet. |
child_run |
Erstellt eine untergeordnete Ausführung. |
clean |
Entfernt die Dateien der aktuellen Ausführung in dem in der Ausführungskonfiguration angegebenen Ziel. |
complete |
Warten, bis die Aufgabenwarteschlange verarbeitet wurde. Die Ausführung wird als abgeschlossen markiert. Dies wird in der Regel Szenarien mit einem interaktiven Notebook verwendet. |
create_children |
Erstellt mindestens eine untergeordnete Ausführung. |
download_file |
Eine zugeordnete Datei aus dem Speicher herunterladen. |
download_files |
Dateien aus einem bestimmten Speicherpräfix (Ordnername) oder dem gesamten Container herunterladen, wenn das Präfix nicht angegeben ist. |
fail |
Die Ausführung als fehlgeschlagen markieren. Legen Sie optional für die Error-Eigenschaft der Ausführung eine Meldung oder Ausnahme fest, die an |
flush |
Warten, bis die Aufgabenwarteschlange verarbeitet wurde. |
get |
Die Ausführung für diesen Arbeitsbereich mit der zugehörigen Ausführungs-ID abrufen. |
get_all_logs |
Alle Protokolle für die Ausführung in ein Verzeichnis herunterladen. |
get_children |
Alle untergeordneten Elemente der aktuellen Ausführung abrufen, die von den festgelegten Filtern ausgewählt wurden. |
get_context |
Gibt den aktuellen Dienstkontext zurück. Verwenden Sie diese Methode, um den aktuellen Dienstkontext zum Protokollieren von Metriken und Hochladen von Dateien abzurufen. Wenn |
get_detailed_status |
Den aktuellen Status der Ausführung abrufen. Wenn der Status der Ausführung „Queued“ (In Warteschlange) lautet, werden die Details angezeigt. |
get_details |
Definition, Statusinformationen, aktuelle Protokolldateien und andere Details der Ausführung abrufen. |
get_details_with_logs |
Den Ausführungsstatus einschließlich Protokolldateiinhalt zurückgeben. |
get_environment |
Die Umgebungsdefinition abrufen, die von dieser Ausführung verwendet wurde. |
get_file_names |
Die Dateien auflisten, die in Verbindung mit der Ausführung gespeichert sind. |
get_metrics |
Die bei der Ausführung protokollierten Metriken abrufen. Metriken für Ausführungen aus der untergeordneten Baumstruktur der jeweiligen Ausführung abrufen, wenn |
get_properties |
Die neuesten Eigenschaften der Ausführung aus dem Dienst abrufen. |
get_secret |
Den Geheimniswert aus dem Kontext einer Ausführung abrufen. Den Geheimniswert für den angegebenen Namen abrufen. Der Geheimnisname verweist auf einen Wert, der in einer Ihrem Arbeitsbereich zugeordneten Azure Key Vault-Instanz gespeichert ist. Ein Beispiel für die Arbeit mit Geheimnissen finden Sie unter Verwenden von Geheimnissen in Trainingsausführungen. |
get_secrets |
Die Geheimniswerte für eine angegebene Liste von Geheimnisnamen abrufen. Ein Wörterbuch mit gefundenen und nicht gefundenen Geheimnissen für die Liste der angegebenen Namen abrufen. Jeder Geheimnisname verweist auf einen Wert, der in einer Ihrem Arbeitsbereich zugeordneten Azure Key Vault-Instanz gespeichert ist. Ein Beispiel für die Arbeit mit Geheimnissen finden Sie unter Verwenden von Geheimnissen in Trainingsausführungen. |
get_snapshot_id |
Die ID der neuesten Momentaufnahme abrufen. |
get_status |
Den aktuellen Status der Ausführung abrufen. Zu den häufig zurückgegebenen Werten zählen „Running“ (Wird ausgeführt), „Completed“ (Abgeschlossen) und „Failed“ (Fehlgeschlagen). |
get_submitted_run |
VERALTET. Verwenden Sie get_context. Die übermittelte Ausführung für dieses Experiment abrufen. |
get_tags |
Die neuesten veränderlichen Tags bei der Ausführung vom Dienst abrufen. |
list |
Eine Liste von Ausführungen in einem Experiment abrufen, das durch optionale Filter angegeben wird. |
list_by_compute |
Eine Liste von Ausführungen in einem Computeziel abrufen, das durch optionale Filter angegeben wird. |
log |
Protokollieren Sie einen Metrikwert für die Ausführung mit dem angegebenen Namen. |
log_accuracy_table |
Eine Genauigkeitstabelle im Artefaktspeicher protokollieren. Die Metrik der Genauigkeitstabelle ist eine nicht skalare Mehrzweckmetrik, die verwendet werden kann, um mehrere Arten von Liniendiagrammen zu erzeugen, die im Bereich der vorhergesagten Wahrscheinlichkeiten kontinuierlich variieren. Beispiele für diese Diagramme sind ROC-, Precision-Recall- und Prognosegütekurven. Die Berechnung der Genauigkeitstabelle ähnelt der Berechnung einer ROC-Kurve. Eine ROC-Kurve speichert True Positive- und False Positive-Raten an vielen verschiedenen Wahrscheinlichkeitsschwellenwerten. In der Genauigkeitstabelle wird die rohe Anzahl von True Positives, False Positives, True Negatives und False Negatives bei vielen Wahrscheinlichkeitsschwellenwerten gespeichert. Es gibt zwei Methoden zum Auswählen von Schwellenwerten: „Wahrscheinlichkeit“ und „Perzentil“. Sie unterscheiden sich darin, wie sie aus dem Bereich der vorhergesagten Wahrscheinlichkeiten Stichproben entnehmen. Wahrscheinlichkeitsschwellenwerte sind Schwellenwerte mit einheitlichem Abstand zwischen 0 und 1. Wenn NUM_POINTS 5 ist, sind die Wahrscheinlichkeitsschwellenwerte [0,0, 0,25, 0,5, 0,75, 1,0]. Perzentilschwellenwerte werden entsprechend der Verteilung der vorhergesagten Wahrscheinlichkeiten verteilt. Jeder Schwellenwert entspricht dem Perzentil der Daten an einem Wahrscheinlichkeitsschwellenwert. Wenn NUM_POINTS z. B. 5 ist, liegt der erste Schwellenwert beim 0. Perzentil, der zweite beim 25. Perzentil, der dritte am 50. usw. Die Wahrscheinlichkeitstabellen und die Perzentiltabellen sind beides 3D-Listen, wobei die erste Dimension die Klassenbezeichnung, die zweite Dimension die Stichprobe mit einem Schwellenwert (Skalen mit NUM_POINTS) darstellt und die dritte Dimension immer 4 Werte hat: TP, FP, TN, FN, immer in dieser Reihenfolge. Die Konfusionswerte (TP, FP, TN, FN) werden auf Grundlage der One-vs-Rest-Strategie berechnet. Weitere Informationen finden Sie unter dem folgenden Link: https://en.wikipedia.org/wiki/Multiclass_classification N = Anzahl der Stichproben im Validierungsdataset (z. B. 200) M = Anzahl der Schwellenwerte = Anzahl der Stichproben aus dem Wahrscheinlichkeitsbereich (5 im Beispiel) C = Anzahl der Klassen im vollständigen Dataset (3 im Beispiel) Einige Invarianten der Genauigkeitstabelle:
Hinweis: M kann ein beliebiger Wert sein und steuert die Auflösung der Diagramme. Dies ist unabhängig vom Dataset, wird beim Berechnen von Metriken definiert und gleicht Speicherplatz, Berechnungszeit und Auflösung aus. Klassenbezeichnungen sollten Zeichenfolgen sein, Konfusionswerte sollten ganze Zahlen sein, und Schwellenwerte sollten Gleitkommawerte sein. |
log_confusion_matrix |
Eine Konfusionsmatrix im Artefaktspeicher protokollieren. Hierdurch wird ein Wrapper um die Sklearn-Konfusionsmatrix protokolliert. Die Metrikdaten enthalten die Klassenbezeichnungen und eine 2D-Liste für die Matrix selbst. Weitere Informationen zur Berechnung der Metrik finden Sie unter dem folgenden Link: https://scikit-learn.org/stable/modules/generated/sklearn.metrics.confusion_matrix.html |
log_image |
Protokollieren Sie eine Imagemetrik für die Ausführungsaufzeichnung. |
log_list |
Eine Liste von Metrikwerten in der Ausführung mit dem gegebenen Namen protokollieren. |
log_predictions |
Vorhersagen im Artefaktspeicher protokollieren. Hierdurch wird ein Metrikscore protokolliert, der verwendet werden kann, um die Verteilungen von echten Zielwerten mit der Verteilung der vorhergesagten Werte für eine Regressionsaufgabe zu vergleichen. Für die Vorhersagen wird ein Binning durchgeführt, Standardabweichungen werden berechnet, um Fehlerbalken in einem Liniendiagramm zu erstellen. |
log_residuals |
Restdaten im Artefaktspeicher protokollieren. Hierdurch werden die Daten protokolliert, die zum Anzeigen eines Histogramms von Restdaten für eine Regressionsaufgabe erforderlich sind. Die Restdaten werden vorhergesagt – tatsächlich. Es sollte eine Kante mehr als die gezählte Anzahl vorhanden sein. Beispiele für die Verwendung von Anzahl und Kanten zur Darstellung eines Histogramms finden Sie in der Dokumentation zum numpy-Histogramm. https://docs.scipy.org/doc/numpy/reference/generated/numpy.histogram.html |
log_row |
Eine Zeilenmetrik für die Ausführung mit dem angegebenen Namen protokollieren. |
log_table |
Protokollieren Sie einen Tabellenmetrik für die Ausführung mit dem angegebenen Namen. |
register_model |
Ein Modell für die Operationalisierung registrieren. |
remove_tags |
Die Liste der veränderlichen Tags bei dieser Ausführung löschen. |
restore_snapshot |
Eine Momentaufnahme als ZIP-Datei wiederherstellen. Gibt den Pfad zur ZIP-Datei zurück. |
set_tags |
Eine Gruppe von Tags für die Ausführung hinzufügen oder ändern. Tags, die nicht im Wörterbuch übergeben werden, bleiben unverändert. Sie können auch einfache Zeichenfolgentags hinzufügen. Wenn diese Tags in das Tagwörterbuch als Schlüssel aufgenommen wurden, haben sie den Wert „None“. Weitere Informationen finden Sie unter Markieren und Suchen von Ausführungen. |
start |
Die Ausführung als gestartet markieren. Dies wird in der Regel in erweiterten Szenarios verwendet, wenn die Ausführung von einem anderen Akteur erstellt wurde. |
submit_child |
Ein Experiment übermitteln und die aktive untergeordnete Ausführung zurückgeben. |
tag |
Kennzeichnen Sie die Ausführung mit einem Zeichenfolgenschlüssel und einem optionalen Zeichenfolgenwert. |
take_snapshot |
Eine Momentaufnahme der Eingabedatei oder des Eingabeordners speichern. |
upload_file |
Laden Sie eine Datei in die Ausführungsaufzeichnung hoch. |
upload_files |
Dateien in die Ausführungsaufzeichnung hochladen. |
upload_folder |
Den angegebenen Ordner an den vorgegebenen Präfixnamen hochladen. |
wait_for_completion |
Auf den Abschluss dieser Ausführung warten. Gibt das Statusobjekt nach dem Wartezustand zurück. |
add_properties
Der Ausführung unveränderliche Eigenschaften hinzufügen.
Tags und Eigenschaften (beide dict[str, str]) unterscheiden sich in ihrer Veränderlichkeit. Eigenschaften sind unveränderlich, sodass sie eine permanente Aufzeichnung zu Überwachungszwecken erstellen. Tags sind veränderlich. Weitere Informationen zum Arbeiten mit Tags und Eigenschaften finden Sie unter Markieren und Suchen von Ausführungen.
add_properties(properties)
Parameter
Name | Beschreibung |
---|---|
properties
Erforderlich
|
Die ausgeblendeten Eigenschaften, die im Ausführungsobjekt gespeichert sind. |
add_type_provider
Erweiterbarkeitshook für benutzerdefinierte Ausführungstypen, die im Ausführungsverlauf gespeichert sind.
static add_type_provider(runtype, run_factory)
Parameter
Name | Beschreibung |
---|---|
runtype
Erforderlich
|
Der Wert von Run.type, für den die Factory aufgerufen wird. Beispiele hierfür sind „hyperdrive“ oder „azureml.scriptrun“, es können aber benutzerdefinierte Typen hinzugefügt werden. |
run_factory
Erforderlich
|
<xref:function>
Eine Funktion mit Signatur (Experiment, RunDto) - > Ausführung, die beim Auflisten von Ausführungen aufgerufen werden soll. |
cancel
Die Ausführung als abgebrochen markieren.
Etwaige zugeordnete Aufträge mit einem gesetzten „cancel_uri“-Feld werden ebenso beendet.
cancel()
child_run
Erstellt eine untergeordnete Ausführung.
child_run(name=None, run_id=None, outputs=None)
Parameter
Name | Beschreibung |
---|---|
name
|
Ein optionaler Name für die untergeordnete Ausführung, der in der Regel für einen „Teil“ angegeben ist. Standardwert: None
|
run_id
|
Eine optionale Ausführungs-ID für die untergeordnete Ausführung; wird andernfalls automatisch generiert. Dieser Parameter ist in der Regel nicht festgelegt. Standardwert: None
|
outputs
|
Optionales Ausgabeverzeichnis zur Nachverfolgung für das untergeordnete Element. Standardwert: None
|
Gibt zurück
Typ | Beschreibung |
---|---|
Die untergeordnete Ausführung. |
Hinweise
Wird verwendet, um einen Teil einer Ausführung in einem Unterabschnitt zu isolieren. Dies kann für identifizierbare „Teile“ einer Ausführung erfolgen, deren Aufteilung interessant ist, oder um unabhängige Metriken über eine Interaktion eines Teilprozesses hinweg zu erfassen.
Wenn ein Ausgabeverzeichnis für die untergeordnete Ausführung festgelegt ist, wird der Inhalt dieses Verzeichnisses nach Abschluss der untergeordneten Ausführung in die untergeordnete Ausführungsaufzeichnung hochgeladen.
clean
Entfernt die Dateien der aktuellen Ausführung in dem in der Ausführungskonfiguration angegebenen Ziel.
clean()
Gibt zurück
Typ | Beschreibung |
---|---|
Eine Liste der gelöschten Dateien. |
complete
Warten, bis die Aufgabenwarteschlange verarbeitet wurde.
Die Ausführung wird als abgeschlossen markiert. Dies wird in der Regel Szenarien mit einem interaktiven Notebook verwendet.
complete(_set_status=True)
Parameter
Name | Beschreibung |
---|---|
_set_status
|
Gibt an, ob das Statusereignis zur Nachverfolgung gesendet werden soll. Standardwert: True
|
create_children
Erstellt mindestens eine untergeordnete Ausführung.
create_children(count=None, tag_key=None, tag_values=None)
Parameter
Name | Beschreibung |
---|---|
count
|
Eine optionale Anzahl untergeordneter Elemente, die erstellt werden sollen. Standardwert: None
|
tag_key
|
Ein optionaler Schlüssel zum Auffüllen des Tags-Eintrags in allen erstellten untergeordneten Elementen. Standardwert: None
|
tag_Values
Erforderlich
|
Eine optionale Liste von Werten, die Tags[tag_key] für die Liste der erstellten Ausführungen zugeordnet werden. |
tag_values
|
Standardwert: None
|
Gibt zurück
Typ | Beschreibung |
---|---|
Die Liste der untergeordneten Ausführungen. |
Hinweise
Entweder Parameter count
ODER Parameter tag_key
UND tag_values
müssen festgelegt werden.
download_file
Eine zugeordnete Datei aus dem Speicher herunterladen.
download_file(name, output_file_path=None, _validate_checksum=False)
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Name des herunterzuladenden Artefakts. |
output_file_path
Erforderlich
|
Der lokale Pfad, in dem das Artefakt gespeichert werden soll. |
download_files
Dateien aus einem bestimmten Speicherpräfix (Ordnername) oder dem gesamten Container herunterladen, wenn das Präfix nicht angegeben ist.
download_files(prefix=None, output_directory=None, output_paths=None, batch_size=100, append_prefix=True, timeout_seconds=None)
Parameter
Name | Beschreibung |
---|---|
prefix
Erforderlich
|
Das Dateipfadpräfix innerhalb des Containers, aus dem alle Artefakte heruntergeladen werden sollen. |
output_directory
Erforderlich
|
Ein optionales Verzeichnis, das von allen Artefaktpfaden als Präfix verwendet wird. |
output_paths
Erforderlich
|
[str]
Optionale Dateipfade, in denen die heruntergeladenen Artefakte gespeichert werden sollen. Sollte eindeutig sein und mit der Länge der Pfade übereinstimmen. |
batch_size
Erforderlich
|
Die Anzahl der Dateien, die pro Batch heruntergeladen werden sollen. Der Standardwert ist 100 Dateien. |
append_prefix
Erforderlich
|
Ein optionales Flag, das festlegt, ob das angegebene Präfix aus dem finalen Ausgabedateipfad angefügt werden soll. Bei „False“ wird das Präfix aus dem Ausgabedateipfad entfernt. |
timeout_seconds
Erforderlich
|
Das Timeout für das Herunterladen von Dateien. |
fail
Die Ausführung als fehlgeschlagen markieren.
Legen Sie optional für die Error-Eigenschaft der Ausführung eine Meldung oder Ausnahme fest, die an error_details
übergeben wird.
fail(error_details=None, error_code=None, _set_status=True)
Parameter
Name | Beschreibung |
---|---|
error_details
|
str oder
BaseException
Optionale Fehlerdetails. Standardwert: None
|
error_code
|
Optionaler Fehlercode des Fehlers für die Fehlerklassifizierung. Standardwert: None
|
_set_status
|
Gibt an, ob das Statusereignis zur Nachverfolgung gesendet werden soll. Standardwert: True
|
flush
Warten, bis die Aufgabenwarteschlange verarbeitet wurde.
flush(timeout_seconds=300)
Parameter
Name | Beschreibung |
---|---|
timeout_seconds
|
Gibt an, wie lange (in Sekunden) auf die Verarbeitung der Aufgabenwarteschlange gewartet werden soll. Standardwert: 300
|
get
Die Ausführung für diesen Arbeitsbereich mit der zugehörigen Ausführungs-ID abrufen.
static get(workspace, run_id)
Parameter
Name | Beschreibung |
---|---|
workspace
Erforderlich
|
Der beinhaltende Arbeitsbereich. |
run_id
Erforderlich
|
Die Ausführungs-ID. |
Gibt zurück
Typ | Beschreibung |
---|---|
Die übermittelte Ausführung. |
get_all_logs
Alle Protokolle für die Ausführung in ein Verzeichnis herunterladen.
get_all_logs(destination=None)
Parameter
Name | Beschreibung |
---|---|
destination
|
Der Zielpfad zum Speichern von Protokollen. Wenn keine Angabe erfolgt, wird im Projektverzeichnis ein Verzeichnis mit dem Namen der Ausführungs-ID erstellt. Standardwert: None
|
Gibt zurück
Typ | Beschreibung |
---|---|
Eine Liste mit den Namen der heruntergeladenen Protokolle. |
get_children
Alle untergeordneten Elemente der aktuellen Ausführung abrufen, die von den festgelegten Filtern ausgewählt wurden.
get_children(recursive=False, tags=None, properties=None, type=None, status=None, _rehydrate_runs=True)
Parameter
Name | Beschreibung |
---|---|
recursive
|
Gibt an, ob alle Nachfolger rekursiv durchlaufen werden sollen. Standardwert: False
|
tags
|
Wenn angegeben, werden Ausführungen zurückgegeben, die zu dem angegebenen „tag“ oder {„tag“: „value“} passen. Standardwert: None
|
properties
|
Wenn angegeben, werden Ausführungen zurückgegeben, die zu dem angegebenen „property“ oder {„property“: „value“} passen. Standardwert: None
|
type
|
Wenn angegeben, werden Ausführungen zurückgegeben, die zu diesem Typ passen. Standardwert: None
|
status
|
Wenn angegeben, werden Ausführungen mit dem Status „status“ zurückgegeben. Standardwert: None
|
_rehydrate_runs
|
Gibt an, ob eine Ausführung des ursprünglichen Typs oder der Basisversion instanziiert werden soll. Standardwert: True
|
Gibt zurück
Typ | Beschreibung |
---|---|
Eine Liste von Run-Objekten. |
get_context
Gibt den aktuellen Dienstkontext zurück.
Verwenden Sie diese Methode, um den aktuellen Dienstkontext zum Protokollieren von Metriken und Hochladen von Dateien abzurufen. Wenn allow_offline
„True“ ist (standardmäßig), werden Aktionen für das Ausführungsobjekt an die Standardausgabe ausgegeben.
get_context(allow_offline=True, used_for_context_manager=False, **kwargs)
Parameter
Name | Beschreibung |
---|---|
cls
Erforderlich
|
Gibt die Klassenmethode an. |
allow_offline
|
Zulassen, dass der Dienstkontext in den Offlinemodus zurückfällt, sodass das Trainingsskript lokal getestet werden kann, ohne einen Auftrag mit dem SDK zu übermitteln. Der Standardwert lautet „true“. Standardwert: True
|
kwargs
Erforderlich
|
Ein Wörterbuch mit zusätzlichen Parametern. |
used_for_context_manager
|
Standardwert: False
|
Gibt zurück
Typ | Beschreibung |
---|---|
Die übermittelte Ausführung. |
Hinweise
Diese Funktion wird allgemein verwendet, um das authentifizierte Ausführungsobjekt innerhalb eines Skripts abzurufen, das zur Ausführung mithilfe von experiment.submit() übermittelt werden soll. Dieses Ausführungsobjekt ist sowohl ein authentifizierter Kontext für die Kommunikation mit Azure Machine Learning-Diensten als auch ein konzeptioneller Container, der Metriken, Dateien (Artefakte) und Modelle enthält.
run = Run.get_context() # allow_offline=True by default, so can be run locally as well
...
run.log("Accuracy", 0.98)
run.log_row("Performance", epoch=e, error=err)
get_detailed_status
Den aktuellen Status der Ausführung abrufen. Wenn der Status der Ausführung „Queued“ (In Warteschlange) lautet, werden die Details angezeigt.
get_detailed_status()
Gibt zurück
Typ | Beschreibung |
---|---|
Aktuelle Statusinformationen und Details |
Hinweise
status: Der aktuelle Status der Ausführung. Der gleiche Wert, der von get_status() zurückgegeben wird.
details: Die ausführlichen Informationen zum aktuellen Status.
run = experiment.submit(config)
details = run.get_detailed_status()
# details = {
# 'status': 'Queued',
# 'details': 'Run requested 1 node(s). Run is in pending status.',
# }
get_details
Definition, Statusinformationen, aktuelle Protokolldateien und andere Details der Ausführung abrufen.
get_details()
Gibt zurück
Typ | Beschreibung |
---|---|
Die Details für die Ausführung zurückgeben. |
Hinweise
Das zurückgegebene Wörterbuch enthält die folgenden Schlüssel-Wert-Paare:
runId: ID dieser Ausführung.
Ziel
status: Der aktuelle Status der Ausführung. Der gleiche Wert, der von get_status() zurückgegeben wird.
startTimeUtc: UTC-Zeit des Starts dieser Ausführung, Angabe in ISO8601.
endTimeUtc: UTC-Zeit des Beendens dieser Ausführung (entweder „Abgeschlossen“ oder „Fehlgeschlagen“), Angabe in ISO8601.
Dieser Schlüssel ist nicht vorhanden, wenn die Ausführung noch läuft.
properties: Unveränderliche Schlüssel-Wert-Paare, die der Ausführung zugeordnet sind. Zu den Standardeigenschaften gehören die Momentaufnahme-ID der Ausführung und Informationen zum Git-Repository, aus dem die Ausführung erstellt wurde (sofern vorhanden). Einer Ausführung können mit add_properties zusätzliche Eigenschaften hinzugefügt werden.
inputDatasets: Eingabedatasets, die der Ausführung zugeordnet sind.
outputDatasets: Ausgabedatasets, die der Ausführung zugeordnet sind.
logFiles
submittedBy
run = experiment.start_logging()
details = run.get_details()
# details = {
# 'runId': '5c24aa28-6e4a-4572-96a0-fb522d26fe2d',
# 'target': 'sdk',
# 'status': 'Running',
# 'startTimeUtc': '2019-01-01T13:08:01.713777Z',
# 'endTimeUtc': '2019-01-01T17:15:65.986253Z',
# 'properties': {
# 'azureml.git.repository_uri': 'https://example.com/my/git/repo',
# 'azureml.git.branch': 'master',
# 'azureml.git.commit': '7dc972657c2168927a02c3bc2b161e0f370365d7',
# 'azureml.git.dirty': 'True',
# 'mlflow.source.git.repoURL': 'https://example.com/my/git/repo',
# 'mlflow.source.git.branch': 'master',
# 'mlflow.source.git.commit': '7dc972657c2168927a02c3bc2b161e0f370365d7',
# 'ContentSnapshotId': 'b4689489-ce2f-4db5-b6d7-6ad11e77079c'
# },
# 'inputDatasets': [{
# 'dataset': {'id': 'cdebf245-701d-4a68-8055-41f9cf44f298'},
# 'consumptionDetails': {
# 'type': 'RunInput',
# 'inputName': 'training-data',
# 'mechanism': 'Mount',
# 'pathOnCompute': '/mnt/datasets/train'
# }
# }],
# 'outputDatasets': [{
# 'dataset': {'id': 'd04e8a19-1caa-4b1f-b318-4cbff9af9615'},
# 'outputType': 'RunOutput',
# 'outputDetails': {
# 'outputName': 'training-result'
# }
# }],
# 'runDefinition': {},
# 'logFiles': {},
# 'submittedBy': 'Alan Turing'
# }
get_details_with_logs
Den Ausführungsstatus einschließlich Protokolldateiinhalt zurückgeben.
get_details_with_logs()
Gibt zurück
Typ | Beschreibung |
---|---|
Gibt den Status der Ausführung mit Protokolldateiinhalten zurück. |
get_environment
Die Umgebungsdefinition abrufen, die von dieser Ausführung verwendet wurde.
get_environment()
Gibt zurück
Typ | Beschreibung |
---|---|
Gibt das environment-Objekt zurück. |
get_file_names
Die Dateien auflisten, die in Verbindung mit der Ausführung gespeichert sind.
get_file_names()
Gibt zurück
Typ | Beschreibung |
---|---|
Die Liste der Pfade für vorhandene Artefakte |
get_metrics
Die bei der Ausführung protokollierten Metriken abrufen.
Metriken für Ausführungen aus der untergeordneten Baumstruktur der jeweiligen Ausführung abrufen, wenn recursive
„True“ ist (standardmäßig „False“).
get_metrics(name=None, recursive=False, run_type=None, populate=False)
Parameter
Name | Beschreibung |
---|---|
name
|
Der Name der Metrik. Standardwert: None
|
recursive
|
Gibt an, ob alle Nachfolger rekursiv durchlaufen werden sollen. Standardwert: False
|
run_type
|
Standardwert: None
|
populate
|
Gibt an, ob der Inhalt externer Daten abgerufen werden soll, die mit der Metrik verknüpft sind. Standardwert: False
|
Gibt zurück
Typ | Beschreibung |
---|---|
Ein Wörterbuch mit den Metriken der Benutzer. |
Hinweise
run = experiment.start_logging() # run id: 123
run.log("A", 1)
with run.child_run() as child: # run id: 456
child.log("A", 2)
metrics = run.get_metrics()
# metrics = { 'A': 1 }
metrics = run.get_metrics(recursive=True)
# metrics = { '123': { 'A': 1 }, '456': { 'A': 2 } } note key is runId
get_properties
Die neuesten Eigenschaften der Ausführung aus dem Dienst abrufen.
get_properties()
Gibt zurück
Typ | Beschreibung |
---|---|
Die Eigenschaften der Ausführung. |
Hinweise
Eigenschaften sind unveränderliche vom System generierte Informationen wie Dauer, Ausführungsdatum, Benutzer sowie benutzerdefinierte Eigenschaften, die mit der add_properties-Methode hinzugefügt wurden. Weitere Informationen finden Sie unter Markieren und Suchen von Ausführungen.
Wenn beim Übermitteln eines Auftrags an Azure Machine Learning Quelldateien in einem lokalen Git-Repository gespeichert werden, dann werden Informationen zum Repository als Eigenschaften gespeichert. Diese Git-Eigenschaften werden beim Erstellen einer Ausführung oder beim Aufrufen von „Experiment.submit“ hinzugefügt. Weitere Informationen zu Git-Eigenschaften finden Sie unter Git-Integration für Azure Machine Learning.
get_secret
Den Geheimniswert aus dem Kontext einer Ausführung abrufen.
Den Geheimniswert für den angegebenen Namen abrufen. Der Geheimnisname verweist auf einen Wert, der in einer Ihrem Arbeitsbereich zugeordneten Azure Key Vault-Instanz gespeichert ist. Ein Beispiel für die Arbeit mit Geheimnissen finden Sie unter Verwenden von Geheimnissen in Trainingsausführungen.
get_secret(name)
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Geheimnisname, für den ein Geheimnis zurückgegeben werden soll. |
Gibt zurück
Typ | Beschreibung |
---|---|
Der Geheimniswert. |
get_secrets
Die Geheimniswerte für eine angegebene Liste von Geheimnisnamen abrufen.
Ein Wörterbuch mit gefundenen und nicht gefundenen Geheimnissen für die Liste der angegebenen Namen abrufen. Jeder Geheimnisname verweist auf einen Wert, der in einer Ihrem Arbeitsbereich zugeordneten Azure Key Vault-Instanz gespeichert ist. Ein Beispiel für die Arbeit mit Geheimnissen finden Sie unter Verwenden von Geheimnissen in Trainingsausführungen.
get_secrets(secrets)
Parameter
Name | Beschreibung |
---|---|
secrets
Erforderlich
|
Eine Liste mit Geheimnisnamen, für die Geheimniswerte zurückgegeben werden sollen. |
Gibt zurück
Typ | Beschreibung |
---|---|
Gibt ein Wörterbuch mit gefundenen und nicht gefundenen Geheimnissen zurück. |
get_snapshot_id
Die ID der neuesten Momentaufnahme abrufen.
get_snapshot_id()
Gibt zurück
Typ | Beschreibung |
---|---|
Die ID der neuesten Momentaufnahme. |
get_status
Den aktuellen Status der Ausführung abrufen.
Zu den häufig zurückgegebenen Werten zählen „Running“ (Wird ausgeführt), „Completed“ (Abgeschlossen) und „Failed“ (Fehlgeschlagen).
get_status()
Gibt zurück
Typ | Beschreibung |
---|---|
Der aktuelle Status. |
Hinweise
„NotStarted“ (Nicht gestartet): Dies ist ein temporärer Zustand, in dem sich clientseitige Ausführungsobjekte vor der Cloudübermittlung befinden.
Starting: Die Verarbeitung der Ausführung in der Cloud hat begonnen. Die aufrufende Funktion besitzt zu diesem Zeitpunkt eine Ausführungs-ID.
Bereitstellung: Wird zurückgegeben, wenn bedarfsorientiertes Compute für eine bestimmte Auftragsübermittlung erstellt wird.
Preparing: Die Ausführungsumgebung wird vorbereitet:
Erstellen des Docker-Images
Einrichten der Conda-Umgebung
Queued: Der Auftrag wird im Computeziel in die Warteschlange eingereiht. Beispielsweise befindet sich der Auftrag in BatchAI in der Warteschlange,
während darauf gewartet wird, dass alle angeforderten Knoten bereit sind.
Running: Die Ausführung des Auftrags auf dem Computeziel hat begonnen.
Finalizing: Die Verarbeitung des Benutzercodes wurde abgeschlossen und die Ausführung befindet sich in den Nachbearbeitungsphasen.
CancelRequested: Für den Auftrag wurde ein Abbruch angefordert.
Completed: Die Ausführung wurde erfolgreich abgeschlossen. Dies schließt sowohl den Benutzercode als auch die
Nachbearbeitungsphasen der Ausführung ein.
Failed: Die Ausführung ist fehlgeschlagen. In der Regel liefert die Eigenschaft „Error“ einer Ausführung Details zur Ursache.
Canceled: Folgt einer Abbruchanforderung und gibt an, dass die Ausführung jetzt erfolgreich abgebrochen wurde.
„NotResponding“ (Reagiert nicht): Für eine Ausführung, für die Heartbeats aktiviert ist, wurde vor Kurzem kein Heartbeat gesendet.
run = experiment.submit(config)
while run.get_status() not in ['Completed', 'Failed']: # For example purposes only, not exhaustive
print('Run {} not in terminal state'.format(run.id))
time.sleep(10)
get_submitted_run
VERALTET. Verwenden Sie get_context.
Die übermittelte Ausführung für dieses Experiment abrufen.
get_submitted_run(**kwargs)
Gibt zurück
Typ | Beschreibung |
---|---|
Die übermittelte Ausführung. |
get_tags
Die neuesten veränderlichen Tags bei der Ausführung vom Dienst abrufen.
get_tags()
Gibt zurück
Typ | Beschreibung |
---|---|
Die im Ausführungsobjekt gespeicherten Tags. |
list
Eine Liste von Ausführungen in einem Experiment abrufen, das durch optionale Filter angegeben wird.
static list(experiment, type=None, tags=None, properties=None, status=None, include_children=False, _rehydrate_runs=True)
Parameter
Name | Beschreibung |
---|---|
experiment
Erforderlich
|
Das enthaltende Experiment. |
type
|
Wenn angegeben, werden Ausführungen zurückgegeben, die zum angegebenen Typ passen. Standardwert: None
|
tags
|
Wenn angegeben, werden Ausführungen zurückgegeben, die zu dem angegebenen „tag“ oder {„tag“: „value“} passen. Standardwert: None
|
properties
|
Wenn angegeben, werden Ausführungen zurückgegeben, die zu dem angegebenen „property“ oder {„property“: „value“} passen. Standardwert: None
|
status
|
Wenn angegeben, werden Ausführungen mit dem Status „status“ zurückgegeben. Standardwert: None
|
include_children
|
Wenn auf „true“ festgelegt, werden alle Ausführungen abgerufen, nicht nur die Ausführungen der obersten Ebene. Standardwert: False
|
_rehydrate_runs
|
Wenn diese Einstellung (standardmäßig) auf „true“ festgelegt ist, wird der registrierte Anbieter verwendet, um ein Objekt für diesen Typ anstelle der Basisversion zu reinstanziieren. Standardwert: True
|
Gibt zurück
Typ | Beschreibung |
---|---|
Eine Liste von Ausführungen. |
Hinweise
Das folgende Codebeispiel zeigt einige Anwendungsmöglichkeiten der list
-Methode.
favorite_completed_runs = Run.list(experiment, status='Completed', tags='favorite')
all_distinct_runs = Run.list(experiment)
and_their_children = Run.list(experiment, include_children=True)
only_script_runs = Run.list(experiment, type=ScriptRun.RUN_TYPE)
list_by_compute
Eine Liste von Ausführungen in einem Computeziel abrufen, das durch optionale Filter angegeben wird.
static list_by_compute(compute, type=None, tags=None, properties=None, status=None)
Parameter
Name | Beschreibung |
---|---|
compute
Erforderlich
|
Das enthaltende Computeziel. |
type
|
Wenn angegeben, werden Ausführungen zurückgegeben, die zum angegebenen Typ passen. Standardwert: None
|
tags
|
Wenn angegeben, werden Ausführungen zurückgegeben, die zu dem angegebenen „tag“ oder {„tag“: „value“} passen. Standardwert: None
|
properties
|
Wenn angegeben, werden Ausführungen zurückgegeben, die zu dem angegebenen „property“ oder {„property“: „value“} passen. Standardwert: None
|
status
|
Wenn angegeben, werden Ausführungen mit dem Status „status“ zurückgegeben. Die einzigen zulässigen Werte sind „Running“ und „Queued“. Standardwert: None
|
Gibt zurück
Typ | Beschreibung |
---|---|
<xref:builtin.generator>
|
Ein Generator von „~_restclient.models.RunDto“. |
log
Protokollieren Sie einen Metrikwert für die Ausführung mit dem angegebenen Namen.
log(name, value, description='', step=None)
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Name der Metrik. |
value
Erforderlich
|
Der Wert, der an den Dienst gesendet werden soll. |
description
Erforderlich
|
Eine optionale Beschreibung der Metrik. |
step
|
Eine optionale Achse zum Angeben der Wertreihenfolge innerhalb einer Metrik. Standardwert: None
|
Hinweise
Wenn Sie eine Metrik für eine Ausführung protokollieren, wird diese Metrik in der Ausführungsaufzeichnung des Experiments gespeichert. Sie können dieselbe Metrik innerhalb einer Ausführung mehrmals protokollieren, wobei das Ergebnis als Vektor dieser Metrik betrachtet wird. Wenn ein Schritt für eine Metrik angegeben wird, muss er für alle Werte angegeben werden.
log_accuracy_table
Eine Genauigkeitstabelle im Artefaktspeicher protokollieren.
Die Metrik der Genauigkeitstabelle ist eine nicht skalare Mehrzweckmetrik, die verwendet werden kann, um mehrere Arten von Liniendiagrammen zu erzeugen, die im Bereich der vorhergesagten Wahrscheinlichkeiten kontinuierlich variieren. Beispiele für diese Diagramme sind ROC-, Precision-Recall- und Prognosegütekurven.
Die Berechnung der Genauigkeitstabelle ähnelt der Berechnung einer ROC-Kurve. Eine ROC-Kurve speichert True Positive- und False Positive-Raten an vielen verschiedenen Wahrscheinlichkeitsschwellenwerten. In der Genauigkeitstabelle wird die rohe Anzahl von True Positives, False Positives, True Negatives und False Negatives bei vielen Wahrscheinlichkeitsschwellenwerten gespeichert.
Es gibt zwei Methoden zum Auswählen von Schwellenwerten: „Wahrscheinlichkeit“ und „Perzentil“. Sie unterscheiden sich darin, wie sie aus dem Bereich der vorhergesagten Wahrscheinlichkeiten Stichproben entnehmen.
Wahrscheinlichkeitsschwellenwerte sind Schwellenwerte mit einheitlichem Abstand zwischen 0 und 1. Wenn NUM_POINTS 5 ist, sind die Wahrscheinlichkeitsschwellenwerte [0,0, 0,25, 0,5, 0,75, 1,0].
Perzentilschwellenwerte werden entsprechend der Verteilung der vorhergesagten Wahrscheinlichkeiten verteilt. Jeder Schwellenwert entspricht dem Perzentil der Daten an einem Wahrscheinlichkeitsschwellenwert. Wenn NUM_POINTS z. B. 5 ist, liegt der erste Schwellenwert beim 0. Perzentil, der zweite beim 25. Perzentil, der dritte am 50. usw.
Die Wahrscheinlichkeitstabellen und die Perzentiltabellen sind beides 3D-Listen, wobei die erste Dimension die Klassenbezeichnung, die zweite Dimension die Stichprobe mit einem Schwellenwert (Skalen mit NUM_POINTS) darstellt und die dritte Dimension immer 4 Werte hat: TP, FP, TN, FN, immer in dieser Reihenfolge.
Die Konfusionswerte (TP, FP, TN, FN) werden auf Grundlage der One-vs-Rest-Strategie berechnet. Weitere Informationen finden Sie unter dem folgenden Link: https://en.wikipedia.org/wiki/Multiclass_classification
N = Anzahl der Stichproben im Validierungsdataset (z. B. 200) M = Anzahl der Schwellenwerte = Anzahl der Stichproben aus dem Wahrscheinlichkeitsbereich (5 im Beispiel) C = Anzahl der Klassen im vollständigen Dataset (3 im Beispiel)
Einige Invarianten der Genauigkeitstabelle:
- TP + FP + TN + FN = N für alle Schwellenwerte für alle Klassen
- TP + FN sind bei allen Schwellenwerten für jede Klasse identisch.
- TN + FP sind bei allen Schwellenwerten für jede Klasse identisch.
- Wahrscheinlichkeitstabellen und Perzentiltabellen haben eine Form [C, M, 4].
Hinweis: M kann ein beliebiger Wert sein und steuert die Auflösung der Diagramme. Dies ist unabhängig vom Dataset, wird beim Berechnen von Metriken definiert und gleicht Speicherplatz, Berechnungszeit und Auflösung aus.
Klassenbezeichnungen sollten Zeichenfolgen sein, Konfusionswerte sollten ganze Zahlen sein, und Schwellenwerte sollten Gleitkommawerte sein.
log_accuracy_table(name, value, description='')
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Name der Genauigkeitstabelle. |
value
Erforderlich
|
JSON mit Name, Version und Dateneigenschaften. |
description
Erforderlich
|
Eine optionale Beschreibung der Metrik. |
Hinweise
Beispiel für einen gültigen JSON-Wert:
{
"schema_type": "accuracy_table",
"schema_version": "1.0.1",
"data": {
"probability_tables": [
[
[82, 118, 0, 0],
[75, 31, 87, 7],
[66, 9, 109, 16],
[46, 2, 116, 36],
[0, 0, 118, 82]
],
[
[60, 140, 0, 0],
[56, 20, 120, 4],
[47, 4, 136, 13],
[28, 0, 140, 32],
[0, 0, 140, 60]
],
[
[58, 142, 0, 0],
[53, 29, 113, 5],
[40, 10, 132, 18],
[24, 1, 141, 34],
[0, 0, 142, 58]
]
],
"percentile_tables": [
[
[82, 118, 0, 0],
[82, 67, 51, 0],
[75, 26, 92, 7],
[48, 3, 115, 34],
[3, 0, 118, 79]
],
[
[60, 140, 0, 0],
[60, 89, 51, 0],
[60, 41, 99, 0],
[46, 5, 135, 14],
[3, 0, 140, 57]
],
[
[58, 142, 0, 0],
[56, 93, 49, 2],
[54, 47, 95, 4],
[41, 10, 132, 17],
[3, 0, 142, 55]
]
],
"probability_thresholds": [0.0, 0.25, 0.5, 0.75, 1.0],
"percentile_thresholds": [0.0, 0.01, 0.24, 0.98, 1.0],
"class_labels": ["0", "1", "2"]
}
}
log_confusion_matrix
Eine Konfusionsmatrix im Artefaktspeicher protokollieren.
Hierdurch wird ein Wrapper um die Sklearn-Konfusionsmatrix protokolliert. Die Metrikdaten enthalten die Klassenbezeichnungen und eine 2D-Liste für die Matrix selbst. Weitere Informationen zur Berechnung der Metrik finden Sie unter dem folgenden Link: https://scikit-learn.org/stable/modules/generated/sklearn.metrics.confusion_matrix.html
log_confusion_matrix(name, value, description='')
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Name der Konfusionsmatrix. |
value
Erforderlich
|
JSON mit Name, Version und Dateneigenschaften. |
description
Erforderlich
|
Eine optionale Beschreibung der Metrik. |
Hinweise
Beispiel für einen gültigen JSON-Wert:
{
"schema_type": "confusion_matrix",
"schema_version": "1.0.0",
"data": {
"class_labels": ["0", "1", "2", "3"],
"matrix": [
[3, 0, 1, 0],
[0, 1, 0, 1],
[0, 0, 1, 0],
[0, 0, 0, 1]
]
}
}
log_image
Protokollieren Sie eine Imagemetrik für die Ausführungsaufzeichnung.
log_image(name, path=None, plot=None, description='')
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Name der Metrik. |
path
Erforderlich
|
Der Pfad oder Stream des Images. |
plot
Erforderlich
|
<xref:matplotlib.pyplot>
Der Plot, der als Image protokolliert werden soll. |
description
Erforderlich
|
Eine optionale Beschreibung der Metrik. |
Hinweise
Verwenden Sie diese Methode, um eine Imagedatei oder einen Matplotlib-Plot für die Ausführung zu protokollieren. Diese Images werden angezeigt und können mit der Ausführungsaufzeichnung verglichen werden.
log_list
Eine Liste von Metrikwerten in der Ausführung mit dem gegebenen Namen protokollieren.
log_list(name, value, description='')
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Name der Metrik. |
value
Erforderlich
|
Die Werte der Metrik. |
description
Erforderlich
|
Eine optionale Beschreibung der Metrik. |
log_predictions
Vorhersagen im Artefaktspeicher protokollieren.
Hierdurch wird ein Metrikscore protokolliert, der verwendet werden kann, um die Verteilungen von echten Zielwerten mit der Verteilung der vorhergesagten Werte für eine Regressionsaufgabe zu vergleichen.
Für die Vorhersagen wird ein Binning durchgeführt, Standardabweichungen werden berechnet, um Fehlerbalken in einem Liniendiagramm zu erstellen.
log_predictions(name, value, description='')
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Name der Vorhersagen. |
value
Erforderlich
|
JSON mit Name, Version und Dateneigenschaften. |
description
Erforderlich
|
Eine optionale Beschreibung der Metrik. |
Hinweise
Beispiel für einen gültigen JSON-Wert:
{
"schema_type": "predictions",
"schema_version": "1.0.0",
"data": {
"bin_averages": [0.25, 0.75],
"bin_errors": [0.013, 0.042],
"bin_counts": [56, 34],
"bin_edges": [0.0, 0.5, 1.0]
}
}
log_residuals
Restdaten im Artefaktspeicher protokollieren.
Hierdurch werden die Daten protokolliert, die zum Anzeigen eines Histogramms von Restdaten für eine Regressionsaufgabe erforderlich sind. Die Restdaten werden vorhergesagt – tatsächlich.
Es sollte eine Kante mehr als die gezählte Anzahl vorhanden sein. Beispiele für die Verwendung von Anzahl und Kanten zur Darstellung eines Histogramms finden Sie in der Dokumentation zum numpy-Histogramm. https://docs.scipy.org/doc/numpy/reference/generated/numpy.histogram.html
log_residuals(name, value, description='')
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Name der Restdaten. |
value
Erforderlich
|
JSON mit Name, Version und Dateneigenschaften. |
description
Erforderlich
|
Eine optionale Beschreibung der Metrik. |
Hinweise
Beispiel für einen gültigen JSON-Wert:
{
"schema_type": "residuals",
"schema_version": "1.0.0",
"data": {
"bin_edges": [50, 100, 200, 300, 350],
"bin_counts": [0.88, 20, 30, 50.99]
}
}
log_row
Eine Zeilenmetrik für die Ausführung mit dem angegebenen Namen protokollieren.
log_row(name, description=None, **kwargs)
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Name der Metrik. |
description
|
Eine optionale Beschreibung der Metrik. Standardwert: None
|
kwargs
Erforderlich
|
Ein Wörterbuch mit zusätzlichen Parametern. In diesem Fall die Spalten der Metrik. |
Hinweise
Mit log_row
wird eine Tabellenmetrik mit Spalten erstellt, wie in kwargs beschrieben. Jeder benannte Parameter erzeugt eine Spalte mit dem angegebenen Wert.
log_row
kann einmal aufgerufen werden, um ein beliebiges Tupel zu protokollieren, oder mehrmals in einer Schleife, um eine vollständige Tabelle zu erzeugen.
citrus = ['orange', 'lemon', 'lime']
sizes = [ 10, 7, 3]
for index in range(len(citrus)):
run.log_row("citrus", fruit = citrus[index], size=sizes[index])
log_table
Protokollieren Sie einen Tabellenmetrik für die Ausführung mit dem angegebenen Namen.
log_table(name, value, description='')
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Name der Metrik. |
value
Erforderlich
|
Der Tabellenwert der Metrik, ein Wörterbuch, in dem Schlüssel Spalten sind, die an den Dienst gesendet werden sollen. |
description
Erforderlich
|
Eine optionale Beschreibung der Metrik. |
register_model
Ein Modell für die Operationalisierung registrieren.
register_model(model_name, model_path=None, tags=None, properties=None, model_framework=None, model_framework_version=None, description=None, datasets=None, sample_input_dataset=None, sample_output_dataset=None, resource_configuration=None, **kwargs)
Parameter
Name | Beschreibung |
---|---|
model_name
Erforderlich
|
Der Name des Modells. |
model_path
|
Der relative Cloudpfad zum Modell, z. B. „Ausgaben/Modellname“.
Wenn nicht angegeben (None), wird Standardwert: None
|
tags
|
Ein Wörterbuch mit Schlüssel-Wert-Tags, die dem Modell zugewiesen werden sollen. Standardwert: None
|
properties
|
Ein Wörterbuch mit Schlüssel-Wert-Eigenschaften, die dem Modell zugewiesen werden sollen. Diese Eigenschaften können nach der Erstellung des Modells nicht mehr geändert werden. Es können jedoch neue Schlüssel-Wert-Paare hinzugefügt werden. Standardwert: None
|
model_framework
|
Das Framework des zu registrierenden Modells. Derzeit unterstützte Frameworks: TensorFlow, ScikitLearn, Onnx, Custom, Multi Standardwert: None
|
model_framework_version
|
Die Frameworkversion des registrierten Modells. Standardwert: None
|
description
|
Eine optionale Beschreibung des Modells. Standardwert: None
|
datasets
|
Eine Liste von Tupeln, wobei das erste Element die Beziehung zwischen Dataset und Modell beschreibt und das zweite Element das Dataset ist. Standardwert: None
|
sample_input_dataset
|
Optional. Beispieleingabedataset für das registrierte Modell Standardwert: None
|
sample_output_dataset
|
Optional. Beispielausgabedataset für das registrierte Modell Standardwert: None
|
resource_configuration
|
Optional. Eine Ressourcenkonfiguration zum Ausführen des registrierten Modells Standardwert: None
|
kwargs
Erforderlich
|
Optionale Parameter. |
Gibt zurück
Typ | Beschreibung |
---|---|
Das registrierte Modell. |
Hinweise
model = best_run.register_model(model_name = 'best_model', model_path = 'outputs/model.pkl')
remove_tags
Die Liste der veränderlichen Tags bei dieser Ausführung löschen.
remove_tags(tags)
Parameter
Name | Beschreibung |
---|---|
tags
Erforderlich
|
Eine Liste zu entfernender Tags. |
Gibt zurück
Typ | Beschreibung |
---|---|
Die im Ausführungsobjekt gespeicherten Tags. |
restore_snapshot
Eine Momentaufnahme als ZIP-Datei wiederherstellen. Gibt den Pfad zur ZIP-Datei zurück.
restore_snapshot(snapshot_id=None, path=None)
Parameter
Name | Beschreibung |
---|---|
snapshot_id
|
Die wiederherzustellende Momentaufnahme-ID. Wenn nicht angegeben, wird die neueste verwendet. Standardwert: None
|
path
|
Der Pfad, unter dem die heruntergeladene ZIP-Datei gespeichert wird. Standardwert: None
|
Gibt zurück
Typ | Beschreibung |
---|---|
Der Pfad. |
set_tags
Eine Gruppe von Tags für die Ausführung hinzufügen oder ändern. Tags, die nicht im Wörterbuch übergeben werden, bleiben unverändert.
Sie können auch einfache Zeichenfolgentags hinzufügen. Wenn diese Tags in das Tagwörterbuch als Schlüssel aufgenommen wurden, haben sie den Wert „None“. Weitere Informationen finden Sie unter Markieren und Suchen von Ausführungen.
set_tags(tags)
Parameter
Name | Beschreibung |
---|---|
tags
Erforderlich
|
Die im Ausführungsobjekt gespeicherten Tags. |
start
Die Ausführung als gestartet markieren.
Dies wird in der Regel in erweiterten Szenarios verwendet, wenn die Ausführung von einem anderen Akteur erstellt wurde.
start()
submit_child
Ein Experiment übermitteln und die aktive untergeordnete Ausführung zurückgeben.
submit_child(config, tags=None, **kwargs)
Parameter
Name | Beschreibung |
---|---|
config
Erforderlich
|
Die zu übermittelnde Konfiguration. |
tags
|
Tags, die der übermittelten Ausführung hinzugefügt werden sollen, z. B. {"tag": "value"}. Standardwert: None
|
kwargs
Erforderlich
|
Zusätzliche Parameter, die in der Submit-Funktion für Konfigurationen verwendet werden. |
Gibt zurück
Typ | Beschreibung |
---|---|
Ein Ausführungsobjekt. |
Hinweise
„Submit“ ist ein asynchroner Aufruf an die Azure Machine Learning-Plattform, mit dem ein Test auf lokaler oder Remotehardware ausgeführt wird. Abhängig von der Konfiguration bereitet „Submit“ automatisch Ihre Ausführungsumgebungen vor, führt Ihren Code aus und erfasst den Quellcode und die Ergebnisse im Ausführungsverlauf des Experiments.
Zum Übermitteln eines Experiments müssen Sie zunächst ein Configuration-Objekt erstellen, das beschreibt, wie das Experiment ausgeführt werden soll. Die Konfiguration richtet sich nach dem benötigten Testtyp.
Das folgende Beispiel zeigt, wie Sie ein untergeordnetes Experiment vom lokalen Computer mithilfe von ScriptRunConfig übermitteln:
from azureml.core import ScriptRunConfig
# run a trial from the train.py code in your current directory
config = ScriptRunConfig(source_directory='.', script='train.py',
run_config=RunConfiguration())
run = parent_run.submit_child(config)
# get the url to view the progress of the experiment and then wait
# until the trial is complete
print(run.get_portal_url())
run.wait_for_completion()
Weitere Informationen zum Konfigurieren einer Ausführung finden Sie unter submit.
tag
Kennzeichnen Sie die Ausführung mit einem Zeichenfolgenschlüssel und einem optionalen Zeichenfolgenwert.
tag(key, value=None)
Parameter
Name | Beschreibung |
---|---|
key
Erforderlich
|
Der Tagschlüssel. |
value
|
Ein optionaler Wert für das Tag. Standardwert: None
|
Hinweise
Sowohl Tags als auch Eigenschaften in einer Ausführung sind „Zeichenfolge -> Zeichenfolge“-Wörterbücher. Der Unterschied zwischen ihnen liegt in der Veränderlichkeit: Tags können festgelegt, aktualisiert und gelöscht werden, während Eigenschaften nur hinzugefügt werden können. Hierdurch eigenen sich Eigenschaften besser für system-/workflowbezogene Verhaltenstrigger, während Tags für die Nutzer des Experiments sichtbar sind und eine Bedeutung für sie haben.
run = experiment.start_logging()
run.tag('DeploymentCandidate')
run.tag('modifiedBy', 'Master CI')
run.tag('modifiedBy', 'release pipeline') # Careful, tags are mutable
run.add_properties({'BuildId': os.environ.get('VSTS_BUILD_ID')}) # Properties are not
tags = run.get_tags()
# tags = { 'DeploymentCandidate': None, 'modifiedBy': 'release pipeline' }
take_snapshot
Eine Momentaufnahme der Eingabedatei oder des Eingabeordners speichern.
take_snapshot(file_or_folder_path)
Parameter
Name | Beschreibung |
---|---|
file_or_folder_path
Erforderlich
|
Die Datei oder der Ordner, die bzw. der den Quellcode der Ausführung enthält. |
Gibt zurück
Typ | Beschreibung |
---|---|
Gibt die Momentaufnahme-ID zurück. |
Hinweise
Momentaufnahmen sollen der Quellcode sein, der zum Ausführen der Experimentausführung verwendet wird. Diese werden mit der Ausführung gespeichert, sodass die Testläufe in Zukunft wiederholt werden können.
Hinweis
Momentaufnahmen werden automatisch erstellt, wenn submit aufgerufen wird. In der Regel ist die take_snapshot-Methode nur für interaktive Ausführungen (Notebook) erforderlich.
upload_file
Laden Sie eine Datei in die Ausführungsaufzeichnung hoch.
upload_file(name, path_or_stream, datastore_name=None)
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Name der hochzuladenden Datei. |
path_or_stream
Erforderlich
|
Der relative lokale Pfad oder Stream zur hochzuladenden Datei. |
datastore_name
Erforderlich
|
Optionaler DataStore-Name |
Gibt zurück
Typ | Beschreibung |
---|---|
Hinweise
run = experiment.start_logging()
run.upload_file(name='important_file', path_or_stream="path/on/disk/file.txt")
Hinweis
Ausführungen erfassen die Datei im angegebenen Ausgabeverzeichnis. Die ist für die meisten Ausführungstypen standardmäßig „./outputs“. Verwenden Sie upload_file nur, wenn zusätzliche Dateien hochgeladen werden müssen, oder kein Ausgabeverzeichnis angegeben ist.
upload_files
Dateien in die Ausführungsaufzeichnung hochladen.
upload_files(names, paths, return_artifacts=False, timeout_seconds=None, datastore_name=None)
Parameter
Name | Beschreibung |
---|---|
names
Erforderlich
|
Die Namen der hochzuladenden Dateien. Falls festgelegt, müssen ebenfalls Pfade festgelegt werden. |
paths
Erforderlich
|
Die relativen lokalen Pfade zu den hochzuladenden Dateien. Falls festgelegt, sind Namen erforderlich. |
return_artifacts
Erforderlich
|
Gibt an, dass für jede hochgeladene Datei ein Artefaktobjekt zurückgegeben werden soll. |
timeout_seconds
Erforderlich
|
Das Timeout für das Hochladen von Dateien. |
datastore_name
Erforderlich
|
Optionaler DataStore-Name |
Hinweise
upload_files
hat die gleichen Auswirkungen wie upload_file
auf separate Dateien, es gibt jedoch Vorteile bei Leistung und Ressourcennutzung bei Verwendung von upload_files
.
import os
run = experiment.start_logging()
file_name_1 = 'important_file_1'
file_name_2 = 'important_file_2'
run.upload_files(names=[file_name_1, file_name_2],
paths=['path/on/disk/file_1.txt', 'other/path/on/disk/file_2.txt'])
run.download_file(file_name_1, 'file_1.txt')
os.mkdir("path") # The path must exist
run.download_file(file_name_2, 'path/file_2.txt')
Hinweis
Ausführungen erfassen Dateien automatisch im angegebenen Ausgabeverzeichnis. Dies ist für die meisten Ausführungstypen standardmäßig „./outputs“. Verwenden Sie „upload_file“ nur, wenn zusätzliche Dateien hochgeladen werden müssen oder kein Ausgabeverzeichnis angegeben ist.
upload_folder
Den angegebenen Ordner an den vorgegebenen Präfixnamen hochladen.
upload_folder(name, path, datastore_name=None)
Parameter
Name | Beschreibung |
---|---|
name
Erforderlich
|
Der Name des Ordners mit den hochzuladenden Dateien. |
folder
Erforderlich
|
Der relative lokale Pfad zum hochzuladenden Ordner. |
datastore_name
Erforderlich
|
Optionaler DataStore-Name |
Hinweise
run = experiment.start_logging()
run.upload_folder(name='important_files', path='path/on/disk')
run.download_file('important_files/existing_file.txt', 'local_file.txt')
Hinweis
Ausführungen erfassen Dateien automatisch im angegebenen Ausgabeverzeichnis. Dies ist für die meisten Ausführungstypen standardmäßig „./outputs“. Verwenden Sie „upload_folder“ nur, wenn zusätzliche Dateien hochgeladen werden müssen oder kein Ausgabeverzeichnis angegeben ist.
wait_for_completion
Auf den Abschluss dieser Ausführung warten. Gibt das Statusobjekt nach dem Wartezustand zurück.
wait_for_completion(show_output=False, wait_post_processing=False, raise_on_error=True)
Parameter
Name | Beschreibung |
---|---|
show_output
|
Gibt an, ob die Ausgabe der Ausführung in sys.stdout angezeigt werden soll. Standardwert: False
|
wait_post_processing
|
Gibt an, ob nach Abschluss der Ausführung auf den Abschluss der Nachverarbeitung gewartet werden soll. Standardwert: False
|
raise_on_error
|
Gibt an, ob ein Fehler ausgelöst wird, wenn sich die Ausführung in einem fehlgeschlagenen Zustand befindet Standardwert: True
|
Gibt zurück
Typ | Beschreibung |
---|---|
Das Statusobjekt. |
Attribute
description
Gibt die Ausführungsbeschreibung zurück.
Die optionale Beschreibung der Ausführung ist eine vom Benutzer angegebene Zeichenfolge, die zum Beschreiben einer Ausführung nützlich ist.
Gibt zurück
Typ | Beschreibung |
---|---|
Die Ausführungsbeschreibung. |
display_name
Gibt den Anzeigenamen der Ausführung zurück.
Der optionale Anzeigename der Ausführung ist eine benutzerdefinierte Zeichenfolge, die zur späteren Identifizierung der Ausführung nützlich ist.
Gibt zurück
Typ | Beschreibung |
---|---|
Der Anzeigename der Ausführung. |
experiment
Ruft das Experiment ab, das die Ausführung enthält.
Gibt zurück
Typ | Beschreibung |
---|---|
Ruft das der Ausführung zugehörige Experiment ab. |
id
Ruft die Ausführungs-ID ab.
Die ID der Ausführung ist ein Bezeichner, der für das enthaltende Experiment eindeutig ist.
Gibt zurück
Typ | Beschreibung |
---|---|
Die Ausführungs-ID. |
name
VERALTET. Verwenden Sie display_name.
Der optionale Name der Ausführung ist eine benutzerdefinierte Zeichenfolge, die zur späteren Identifizierung der Ausführung nützlich ist.
Gibt zurück
Typ | Beschreibung |
---|---|
Die Ausführungs-ID. |
number
Die Ausführungsnummer abrufen.
Eine monoton steigende Zahl, die die Reihenfolge der Ausführungen innerhalb eines Experiments darstellt.
Gibt zurück
Typ | Beschreibung |
---|---|
Die Ausführungsnummer. |
parent
Die übergeordnete Ausführung dieser Ausführung aus dem Dienst abrufen.
Ausführungen können über ein optionales übergeordnetes Element verfügen, sodass potenziell eine Strukturhierarchie von Ausführungen bestehen kann. Um Metriken für eine übergeordnete Ausführung zu protokollieren, verwenden Sie die log-Methode des übergeordneten Objekts, z. B. run.parent.log()
.
Gibt zurück
Typ | Beschreibung |
---|---|
Die übergeordnete Ausführung oder „None“ (Keine), wenn keine festgelegt ist. |
properties
Gibt die unveränderlichen Eigenschaften dieser Ausführung zurück.
Gibt zurück
Typ | Beschreibung |
---|---|
Die lokal zwischengespeicherten Eigenschaften der Ausführung. |
Hinweise
Zu den Eigenschaften gehören unveränderliche vom System generierte Informationen wie Dauer, Ausführungsdatum, Benutzer usw.
status
Gibt den Status des Ausführungsobjekts zurück.
tags
Gibt die veränderlichen Tags dieser Ausführung zurück.
Gibt zurück
Typ | Beschreibung |
---|---|
Die im Ausführungsobjekt gespeicherten Tags. |
type
Ruft den Ausführungstyp ab.
Gibt an, wie die Ausführung erstellt oder konfiguriert wurde.
Gibt zurück
Typ | Beschreibung |
---|---|
Der Ausführungstyp. |