Einrichten einer AutoML-Trainingsausführung für tabellarische Daten mit der Azure Machine Learning-CLI und dem Python SDK

  • Artikel

GILT FÜR:Azure CLI ML-Erweiterung v2 (aktuell)Python SDK azure-ai-ml v2 (aktuell)

In diesem Leitfaden erfahren Sie, wie Sie einen Trainingsauftrag für automatisiertes maschinelles Lernen (AutoML) mit dem Azure Machine Learning Python SDK v2 einrichten. Das automatisierte ML wählt einen Algorithmus und Hyperparameter für Sie aus und generiert ein Modell, das Sie anschließend bereitstellen können. Dieser Leitfaden enthält Details zu den verschiedenen Optionen, die Sie zum Konfigurieren von automatisierten ML-Experimenten verwenden können.

Wenn Sie lieber ohne Code arbeiten, finden Sie hier Informationen zum Einrichten von AutoML-Training in Azure Machine Learning Studio ohne Code.

Voraussetzungen

Installieren Sie zur Verwendung der SDK-Informationen das Azure Machine Learning SDK v2 für Python.

zum Installieren des SDK können Sie wie folgt vorgehen:

  • Erstellen Sie eine Compute-Instanz, auf der das neueste Azure Machine Learning Python SDK bereits installiert und für ML-Workflows vorkonfiguriert ist. Weitere Informationen finden Sie unter Erstellen einer Azure Machine Learning-Compute-Instanz.
  • Installieren des SDK auf dem lokalen Computer

Einrichten des Arbeitsbereichs

Um eine Verbindung mit einem Arbeitsbereich herzustellen, müssen Sie ein Abonnement, eine Ressourcengruppe und den Namen des Arbeitsbereichs angeben.

Die Arbeitsbereichsdetails werden im MLClient von azure.ai.ml verwendet, um Zugriff auf den gewünschten Azure Machine Learning-Arbeitsbereich zu erhalten.

Im folgenden Beispiel wird die standardmäßige Azure-Authentifizierung zusammen mit der standardmäßigen Arbeitsbereichskonfiguration oder einer beliebigen config.json-Datei verwendet, die Sie möglicherweise in die Ordnerstruktur kopiert haben. Wenn keine config.json gefunden wird, müssen Sie die Werte für „subscription_id“, „resource_group“ und „workspace“ bei der MLClient-Erstellung manuell eingeben.

from azure.identity import DefaultAzureCredential
from azure.ai.ml import MLClient

credential = DefaultAzureCredential()
ml_client = None
try:
    ml_client = MLClient.from_config(credential)
except Exception as ex:
    print(ex)
    # Enter details of your Azure Machine Learning workspace
    subscription_id = "<SUBSCRIPTION_ID>"
    resource_group = "<RESOURCE_GROUP>"
    workspace = "<AZUREML_WORKSPACE_NAME>"
    ml_client = MLClient(credential, subscription_id, resource_group, workspace)

Datenquelle und Datenformat

Um Trainingsdaten für AutoML in SDK v2 bereitzustellen, müssen Sie diese über eine MLTable in die Cloud hochladen.

Voraussetzungen für das Laden von Daten in eine MLTable:

  • Die Daten müssen in Tabellenform vorliegen.
  • Der Wert, der vorhergesagt werden soll (Zielspalte), muss in den Daten vorhanden sein.

Auf die Trainingsdaten muss von der Remotecomputeressource aus zugegriffen werden können. AutoML v2 (Python SDK und CLI/YAML) akzeptiert MLTable-Datenressourcen (v2), unterstützt aber aus Gründen der Abwärtskompatibilität auch tabellarische v1-Datasets (registrierte tabellarische Datasets) über dieselben Eingabedateneigenschaften. Es wird jedoch empfohlen, die in v2 verfügbare MLTable zu verwenden. In diesem Beispiel wird davon ausgegangen, dass die Daten im lokalen Pfad, ./train_data/bank_marketing_train_data.csv, gespeichert sind.

Sie können eine MLTable mit dem mltable Python SDK erstellen, wie im folgenden Beispiel gezeigt:

import mltable

paths = [
    {'file': './train_data/bank_marketing_train_data.csv'}
]

train_table = mltable.from_delimited_files(paths)
train_table.save('./train_data')

Mit diesem Code wird eine neue Datei,./train_data/MLTable, erstellt, die das Dateiformat und die Ladeanweisungen enthält.

./train_data Der Ordner enthält nun die MLTable-Definitionsdatei sowie die Datendatei, bank_marketing_train_data.csv.

Weitere Informationen zu MLTable finden Sie im Artikel mltable-Anleitung.

Trainieren, Überprüfen und Testen von Daten

Sie können separate Trainings- und Validierungsdatasets angeben, aber die Trainingsdaten müssen im Parameter training_data in der factory-Funktion Ihres AutoML-Auftrags angegeben werden.

Wenn Sie keinen validation_data- oder n_cross_validation-Parameter explizit angeben, wendet das automatisierte maschinelle Lernen Standardverfahren an, um zu bestimmen, wie die Überprüfung durchgeführt wird. Diese Bestimmung hängt von der Anzahl der Zeilen im Dataset ab, das Ihrem training_data-Parameter zugewiesen wird.

Umfang der Trainingsdaten Validierungsverfahren
Mehr als 20.000 Zeilen Es wird eine Aufteilung in Trainings- und Validierungsdaten vorgenommen. Standardmäßig werden 10 % des ursprünglichen Trainingsdatasets als Validierungsset verwendet. Dieses Validierungsset wird seinerseits für die Metrikberechnung verwendet.
Weniger als oder gleich 20.000 Zeilen Der Kreuzvalidierungsansatz wird angewendet. Die Standardanzahl der Faltungen (Folds) hängt von der Zeilenanzahl ab.
Wenn das Dataset weniger als 1.000 Zeilen aufweist, werden 10 Faltungen verwendet.
Wenn die Anzahl der Zeilen gleich oder zwischen 1.000 und 20.000 liegt, werden drei Faltungen verwendet.

Computeziel zum Ausführen des Experiments

AutoML-Aufträge mit dem Python SDK v2 (oder CLI v2) werden derzeit nur für Azure Machine Learning-Remotecomputeressourcen unterstützt (Cluster oder Compute-Instanz).

Erfahren Sie mehr über das Erstellen von Compute-Instanzen mit dem Python SDKv2 (oder CLIv2).

Konfigurieren der Experimenteinstellungen

Es gibt mehrere Optionen zum Konfigurieren von Experimenten mit automatisiertem ML. Diese Konfigurationsparameter werden in Ihrer Aufgabenmethode festgelegt. Mit den Einstellungen training und limits können Sie außerdem Einstellungen für das Auftragstraining und Beendigungskriterien festlegen.

Das folgende Beispiel zeigt die erforderlichen Parameter für eine Klassifizierungsaufgabe, die die Genauigkeit als primäre Metrik und eine 5-fache Kreuzvalidierung festlegt.

from azure.ai.ml.constants import AssetTypes
from azure.ai.ml import automl, Input

# note that this is a code snippet -- you might have to modify the variable values to run it successfully

# make an Input object for the training data
my_training_data_input = Input(
    type=AssetTypes.MLTABLE, path="./data/training-mltable-folder"
)

# configure the classification job
classification_job = automl.classification(
    compute=my_compute_name,
    experiment_name=my_exp_name,
    training_data=my_training_data_input,
    target_column_name="y",
    primary_metric="accuracy",
    n_cross_validations=5,
    enable_model_explainability=True,
    tags={"my_custom_tag": "My custom value"}
)

# Limits are all optional
classification_job.set_limits(
    timeout_minutes=600, 
    trial_timeout_minutes=20, 
    max_trials=5,
    enable_early_termination=True,
)

# Training properties are optional
classification_job.set_training(
    blocked_training_algorithms=["logistic_regression"], 
    enable_onnx_compatible_models=True
)

Auswählen des Aufgabentyps für maschinelles Lernen (ML-Problem)

Bevor Sie Ihren AutoML-Auftrag übermitteln können, müssen Sie die Art des ML-Problems bestimmen, das Sie lösen möchten. Dieses Problem bestimmt, welche Funktion Ihr AutoML-Auftrag verwendet und welche Modellalgorithmen angewendet werden.

Automatisierte ML unterstützt Aufgaben, die auf tabellarischen Daten basieren (Klassifizierung, Regression, Vorhersage), Aufgaben für maschinelles Sehen (z. B. Bildklassifizierung und Objekterkennung) und Aufgaben zur Verarbeitung natürlicher Sprache (z. B. Textklassifizierung und Entitätserkennung). Weitere Informationen finden Sie in unserem Artikel zu Aufgabentypen. Weitere Informationen zum Einrichten von Vorhersageaufträgen finden Sie in unserem Leitfaden zur Zeitreihenvorhersage.

Unterstützte Algorithmen

Beim automatisierten maschinellen Lernen werden während des Automatisierungs- und Optimierungsprozesses verschiedene Modelle und Algorithmen getestet. Benutzer müssen den Algorithmus nicht angeben.

Die Aufgabenmethode bestimmt die Liste der Algorithmen/Modelle, die angewendet werden sollen. Verwenden Sie die Parameter allowed_training_algorithms oder blocked_training_algorithms in der Konfiguration des AutoML-Auftrags training, um die Iterationen mit den verfügbaren Modellen weiter zu modifizieren, um sie ein- oder auszuschließen.

In der folgenden Liste mit Links können Sie die unterstützten Algorithmen für die unten aufgeführten Machine Learning-Aufgaben erkunden.

Klassifizierung Regression Zeitreihe und Vorhersage
Logistische Regression* Elastisches Netz* AutoARIMA
Light GBM* Light GBM* Prophet
Gradient Boosting* Gradient Boosting* Elastisches Netz
Entscheidungsstruktur* Entscheidungsstruktur* Light GBM
K nächste Nachbarn* K nächste Nachbarn* K nächste Nachbarn
Lineare SVC* LARS-Lasso* Entscheidungsstruktur
Support Vector Classification (SVC)* Stochastisches Gradientenabstiegsverfahren (SGD)* Arimax
Zufällige Gesamtstruktur* Random Forest LARS Lasso
Extremely Randomized Trees* Extremely Randomized Trees* Extremely Randomized Trees*
XGBoost* XGBoost* Random Forest
Naive Bayes* Xgboost TCNForecaster
Stochastisches Gradientenabstiegsverfahren (SGD)* Stochastisches Gradientenabstiegsverfahren (SGD) Gradient Boosting
ExponentialSmoothing
SeasonalNaive
Average
Naiv
SeasonalAverage

Mit zusätzlichen Algorithmen unten.

Unter diesem Link finden Sie Beispielnotebooks für jeden Aufgabentyp.

Primary metric (Primäre Metrik)

Der Parameter primary_metric bestimmt die Metrik, die während des Modelltrainings für die Optimierung verwendet werden soll. Die verfügbaren Metriken, die Sie auswählen können, richten sich nach der Art der ausgewählten Aufgabe.

Bei der Auswahl einer primären Metrik für optimiertes automatisiertes ML muss eine Vielzahl von Faktoren berücksichtigt werden. Der wichtigste Aspekt sollte sein, welche Metrik Ihre Geschäftsanforderungen am besten widerspiegelt. Anschließend sollten Sie überprüfen, ob die Metrik für Ihr Datasetprofil (Datengröße, Datenbereich, Klassenverteilung usw.) geeignet ist. In den folgenden Abschnitten werden die empfohlenen primären Metriken basierend auf dem Aufgabentyp und Geschäftsszenario zusammengefasst.

Informationen zu den speziellen Definitionen dieser Metriken finden Sie unter Grundlagen von Ergebnissen des automatisierten maschinellen Lernens.

Metriken für Szenarien zur Klassifizierung mit mehreren Klassen

Diese Metriken gelten für alle Klassifizierungsszenarien, Tabellendaten, Bilder/maschinelles Sehen und NLP-Text eingeschlossen.

Schwellenwertabhängige Metriken wie accuracy, recall_score_weighted, norm_macro_recall und precision_score_weighted sind möglicherweise nicht optimal für kleine Datensätze, die eine große Klassenschiefe (Klassenungleichgewicht) aufweisen, oder wenn der erwartete Metrikwert sehr nahe bei 0,0 oder 1,0 liegt. In diesen Fällen eignet sich AUC_weighted möglicherweise besser als primäre Metrik. Nach Abschluss des automatisierten ML können Sie das stärkste Modell basierend auf der Metrik auswählen, die sich am besten für Ihre Geschäftsanforderungen eignet.

Metrik Beispiel eines Anwendungsfalls
accuracy Bildklassifizierung, Stimmungsanalyse, Vorhersage der Kundenabwanderung
AUC_weighted Betrugserkennung, Bildklassifizierung, Anomalie-/Spamerkennung
average_precision_score_weighted Stimmungsanalyse
norm_macro_recall Vorhersage der Kundenabwanderung
precision_score_weighted

Metriken für Szenarien zur Klassifizierung mit mehreren Bezeichnungen

  • Für die Textklassifizierung mit mehreren Bezeichnungen ist „Genauigkeit“ derzeit die einzige primäre Metrik, die unterstützt wird.

  • Für die Bildklassifizierung mit mehreren Bezeichnungen werden die unterstützten primären Metriken in der ClassificationMultilabelPrimaryMetrics-Enumeration definiert.

Metriken für Szenarien zur Erkennung benannter Entitäten basierend auf NLP-Text

  • Für die Erkennung benannter Entitäten basierend auf NLP-Text ist „Genauigkeit“ derzeit die einzige primäre Metrik, die unterstützt wird.

Metriken für Regressionsszenarien

r2_score, normalized_mean_absolute_error und normalized_root_mean_squared_error versuchen alle, die Vorhersagefehler zu minimieren. r2_score und normalized_root_mean_squared_error minimieren beide die durchschnittlichen quadratischen Abweichungen, während normalized_mean_absolute_error den durchschnittlichen absoluten Wert der Fehler minimiert. Der absolute Wert behandelt Fehler aller Größenordnungen gleich, und quadrierte Fehler haben einen viel größeren Nachteil für Fehler mit größeren absoluten Werten. Je nachdem, ob größere Fehler stärker bestraft werden sollen oder nicht, kann man wählen, ob man den quadratischen Fehler oder den absoluten Fehler optimiert.

Der Hauptunterschied zwischen r2_score und normalized_root_mean_squared_error ist die Art und Weise, wie sie normalisiert werden, und ihre Bedeutung. normalized_root_mean_squared_error ist der mittlere quadratische Fehler, normiert auf den Bereich und kann als durchschnittliche Fehlergröße für die Vorhersage interpretiert werden. r2_score ist der mittlere quadratische Fehler, normalisiert durch eine Schätzung der Varianz der Daten. Es ist der Anteil der Variation, der durch das Modell erfasst werden kann.

Hinweis

r2_score und normalized_root_mean_squared_error verhalten sich auch als primäre Metriken ähnlich. Wenn ein fester Validierungssatz verwendet wird, optimieren diese beiden Metriken dasselbe Ziel, nämlich den mittleren quadratischen Fehler, und werden von demselben Modell optimiert. Wenn nur ein Trainingsset zur Verfügung steht und Kreuzvalidierung angewendet wird, würden sie sich leicht unterscheiden, da der Normalisierer für normalized_root_mean_squared_error als Bereich des Trainingssets festgelegt ist, aber der Normalisierer für r2_score würde für jede Falte variieren, da er die Varianz für jede Falte darstellt.

Wenn der Rang und nicht der genaue Wert von Interesse ist, kann spearman_correlation die bessere Wahl sein, da er die Rangkorrelation zwischen realen Werten und Vorhersagen misst.

AutoML unterstützt derzeit keine primären Metriken, die den relativen Unterschied zwischen Vorhersagen und Beobachtungen messen. Die Metriken r2_score, normalized_mean_absolute_error und normalized_root_mean_squared_error sind Measures der absoluten Differenz. Wenn sich eine Vorhersage beispielsweise von einer Beobachtung um 10 Einheiten unterscheidet, berechnen diese Metriken den gleichen Wert, wenn die Beobachtung 20 Einheiten oder 20.000 Einheiten ist. Im Gegensatz dazu ergibt eine prozentuale Differenz, die ein relatives Maß ist, Fehler von 50 % bzw. 0,05 %! Um relative Unterschiede zu optimieren, können Sie AutoML mit einer unterstützten primären Metrik ausführen und dann das Modell mit dem besten mean_absolute_percentage_error oder root_mean_squared_log_error auswählen. Beachten Sie, dass diese Metriken nicht definiert sind, wenn alle Beobachtungswerte 0 sind, sodass sie möglicherweise nicht immer eine gute Wahl sind.

Metrik Beispiel eines Anwendungsfalls
spearman_correlation
normalized_root_mean_squared_error Preisvorhersage (Haus/Produkt/Trinkgeld), Vorhersage eines Bewertungsergebnisses
r2_score Verspätungen bei Fluggesellschaften, Gehaltsschätzung, erforderlicher Zeitaufwand bis zur Problemlösung
normalized_mean_absolute_error

Metriken für Szenarien zur Zeitreihenvorhersage

Die Empfehlungen ähneln den Empfehlungen für Regressionsszenarien.

Metrik Beispiel eines Anwendungsfalls
normalized_root_mean_squared_error Preisvorhersage, Bestandoptimierung, Bedarfsvorhersage
r2_score Preisvorhersage, Bestandoptimierung, Bedarfsvorhersage
normalized_mean_absolute_error

Metriken für Szenarien zur Bildobjekterkennung

  • Für die Bildobjekterkennung werden die unterstützten primären Metriken in der ObjectDetectionPrimaryMetrics-Enumeration definiert.

Metriken für Szenarien zur Bildinstanzsegmentierung

  • Für Szenarien zur Bildinstanzsegmentierung werden die unterstützten primären Metriken in der InstanceSegmentationPrimaryMetrics-Enumeration definiert.

Merkmalerstellung für Daten

Bei jedem AutoML-Experiment werden Ihre Daten automatisch in Zahlen und Zahlenvektoren umgewandelt und außerdem skaliert und normalisiert, um Algorithmen zu unterstützen, die empfindlich auf Features in unterschiedlichen Skalierungen reagieren. Diese Datentransformationen werden als Featurisierung bezeichnet.

Hinweis

Die Schritte zur Featurebereitstellung bei automatisiertem maschinellen Lernen (Featurenormalisierung, Behandlung fehlender Daten, Umwandlung von Text in numerische Daten usw.) werden Teil des zugrunde liegenden Modells. Bei Verwendung des Modells für Vorhersagen werden die während des Trainings angewendeten Schritte zur Featurebereitstellung automatisch auf Ihre Eingabedaten angewendet.

Beim Konfigurieren Ihrer automatisierten ML-Aufträge können Sie die featurization-Einstellungen aktivieren/deaktivieren.

Die folgende Tabelle zeigt die akzeptierten Einstellungen für die Featurisierung.

Konfiguration der Featurebereitstellung BESCHREIBUNG
"mode": 'auto' Gibt an, dass im Rahmen der Vorverarbeitung die folgenden Schritte für Datenschutzmaßnahmen und Featurebereitstellung automatisch durchgeführt werden. Standardeinstellung.
"mode": 'off' Gibt an, dass der Featurisierungsschritt nicht automatisch durchgeführt werden soll
"mode": 'custom' Gibt an, dass ein angepasster Featurebereitstellungsschritt verwendet werden soll.

Der folgende Code zeigt, wie Sie die benutzerdefinierte Featurisierung in diesem Fall für einen Regressionsauftrag bereitstellen können.

from azure.ai.ml.automl import ColumnTransformer

transformer_params = {
    "imputer": [
        ColumnTransformer(fields=["CACH"], parameters={"strategy": "most_frequent"}),
        ColumnTransformer(fields=["PRP"], parameters={"strategy": "most_frequent"}),
    ],
}
regression_job.set_featurization(
    mode="custom",
    transformer_params=transformer_params,
    blocked_transformers=["LabelEncoding"],
    column_name_and_types={"CHMIN": "Categorical"},
)

Exit Criteria (Beendigungskriterien)

Sie können in der Funktion set_limits() einige Optionen definieren, um Ihr Experiment vor der Beendigung des Auftrags zu beenden.

Kriterien description
Keine Kriterien Wenn Sie keine Beendigungsparameter definieren, wird das Experiment fortgesetzt, bis kein weiterer Fortschritt bei Ihrer primären Metrik erzielt wird.
timeout Legt fest, wie lange (in Minuten) Ihr Experiment noch ausgeführt werden soll. Ohne diese Angabe beträgt der Gesamttimeout für den Auftrag standardmäßig 6 Tage (8.640 Minuten). Wenn Sie ein Timeout angeben möchten, das kleiner oder gleich 1 Stunde (60 Minuten) ist, stellen Sie sicher, dass die Größe Ihres Datasets maximal 10.000.000 (Zeilen mal Spalte) beträgt, da es andernfalls zu einem Fehler kommt.

Dieses Timeout schließt Setup, Featurisierung und Trainingsausführungen ein, nicht jedoch die Ensembling- und Modellerklärbarkeitsausführungen am Ende des Prozesses, da diese Aktionen erst nach Abschluss aller Testläufe (Unteraufträge) ausgeführt werden müssen.
trial_timeout_minutes Die maximale Dauer in Minuten, die jeder Testlauf (Unterauftrag) ausgeführt werden kann, bevor er beendet wird. Sofern nicht angegeben, wird der Wert auf 1 Monat bzw. 43.200 Minuten festgelegt.
enable_early_termination Gibt an, ob der Auftrag beendet wird, wenn sich die Bewertung kurzfristig nicht verbessert.
max_trials Die maximale Anzahl von Testläufen/Ausführungen mit unterschiedlichen Kombinationen von Algorithmen und Hyperparametern, die während eines AutoML-Auftrags ausprobiert werden. Sofern nicht angegeben, wird der Wert standardmäßig auf 1.000 Testläufe festgelegt. Bei Verwendung von enable_early_termination kann die Anzahl der verwendeten Testläufe niedriger sein.
max_concurrent_trials Repräsentiert die maximale Anzahl von Testläufen (Unteraufträge), die parallel ausgeführt werden sollen. Es empfiehlt sich, diese Zahl an die Anzahl der Knoten Ihres Clusters anzupassen.

Ausführen des Experiments

Hinweis

Wenn Sie ein Experiment mit denselben Konfigurationseinstellungen und derselben primären Metrik mehrmals durchführen, werden Sie wahrscheinlich bei jedem Experiment eine Abweichung in der abschließenden metrischen Bewertung und in den generierten Modellen sehen. Die Algorithmen, die beim automatisierten maschinellen Lernen eingesetzt werden, weisen eine inhärente Zufälligkeit auf, die zu geringfügigen Abweichungen bei den im Experiment ausgegebenen Modellen und der abschließenden metrischen Bewertung eines empfohlenen Modells führen kann, z. B. bei der Genauigkeit. Sie werden wahrscheinlich auch Ergebnisse mit demselben Modellnamen, aber unterschiedlichen verwendeten Hyperparametern erhalten.

Warnung

Wenn Sie für Ihren Arbeitsbereich Firewallregeln und/oder eine Netzwerksicherheitsgruppe festgelegt haben, vergewissern Sie sich, dass die erforderlichen Berechtigungen für den ein- und ausgehenden Netzwerkdatenverkehr gemäß der Definition in Konfigurieren von ein- und ausgehendem Netzwerkdatenverkehr erteilt wurden.

Übermitteln Sie das auszuführende Experiment, um ein Modell zu generieren. Mit dem im Rahmen der erforderlichen Vorbereitungen erstellten MLClient können Sie den folgenden Befehl im Arbeitsbereich ausführen.


# Submit the AutoML job
returned_job = ml_client.jobs.create_or_update(
    classification_job
)  # submit the job to the backend

print(f"Created job: {returned_job}")

# Get a URL for the status of the job
returned_job.services["Studio"].endpoint

Mehrere untergeordnete Ausführungen auf Clustern

Untergeordnete Ausführungen von automatisierten ML-Experimenten können auf einem Cluster durchgeführt werden, auf dem bereits ein anderes Experiment ausgeführt wird. Das Timing hängt jedoch davon ab, über wie viele Knoten der Cluster verfügt und ob diese Knoten zur Ausführung eines anderen Experiments zur Verfügung stehen.

Jeder Knoten im Cluster fungiert als einzelner virtueller Computer (VM), der eine einzelne Trainingsausführung durchführen kann. Für automatisiertes ML bedeutet dies eine untergeordnete Ausführung. Wenn alle Knoten ausgelastet sind, wird ein neues Experiment in die Warteschlange gestellt. Wenn es jedoch freie Knoten gibt, führt das neue Experiment untergeordnete Ausführungen von automatisiertem ML parallel auf den verfügbaren Knoten/VMs aus.

Um die Verwaltung von untergeordneten Ausführungen und deren Zeitpunkt der Durchführung zu erleichtern, empfehlen wir Ihnen, einen dedizierten Cluster pro Experiment zu erstellen und die Anzahl von max_concurrent_iterations Ihres Experiments an die Anzahl der Knoten im Cluster anzupassen. Auf diese Weise verwenden Sie alle Clusterknoten gleichzeitig mit der von Ihnen gewünschten Anzahl von gleichzeitigen untergeordneten Ausführungen/Iterationen.

Konfigurieren Sie max_concurrent_iterations in der limits-Konfiguration. Wenn es nicht konfiguriert ist, ist standardmäßig nur eine gleichzeitige untergeordnete Ausführung/Iteration pro Experiment zulässig. Im Fall einer Compute-Instanz kann max_concurrent_trials auf die gleiche Anzahl von Kernen wie auf dem virtuellen Computer der Compute-Instanz festgelegt werden.

Untersuchen von Modellen und Metriken

Automatisiertes ML bietet Ihnen Möglichkeiten zur Überwachung und Auswertung Ihrer Trainingsergebnisse.

Über die Seite „Modelle“ in der Benutzeroberfläche von Azure Machine Learning können Sie auch die Hyperparameter anzeigen, die beim Training eines bestimmten Modells verwendet werden. Außerdem können Sie den verwendeten Trainingscode des internen Modells anzeigen und anpassen.

Registrieren und Bereitstellen von Modellen

Nachdem Sie ein Modell getestet und entschieden haben, es in der Produktion einzusetzen, können Sie es zur späteren Verwendung registrieren.

Tipp

Für registrierte Modelle steht in Azure Machine Learning Studio die Bereitstellung mit nur einem Klick zur Verfügung. Weitere Informationen finden Sie unter Bereitstellen registrierter Modelle aus Studio.

AutoML in Pipelines

Um AutoML in Ihren MLOps-Workflows zu nutzen, können Sie AutoML-Auftragsschritte Ihren Azure Machine Learning-Pipelines hinzufügen. Damit können Sie Ihren gesamten Workflow automatisieren, indem Sie Ihre Datenvorbereitungsskripts mit AutoML verbinden und dann das daraus resultierende beste Modell registrieren und validieren.

Nachfolgend finden Sie ein Beispiel für eine Pipeline mit einer AutoML-Klassifizierungskomponente und einer Befehlskomponente, die die resultierende AutoML-Ausgabe zeigt. Beachten Sie, dass auf die Eingaben (Trainings- und Validierungsdaten) und Ausgaben (bestes Modell) in verschiedenen Schritten Bezug genommen wird.

# Define pipeline
@pipeline(
    description="AutoML Classification Pipeline",
    )
def automl_classification(
    classification_train_data,
    classification_validation_data
):
    # define the automl classification task with automl function
    classification_node = classification(
        training_data=classification_train_data,
        validation_data=classification_validation_data,
        target_column_name="y",
        primary_metric="accuracy",
        # currently need to specify outputs "mlflow_model" explictly to reference it in following nodes 
        outputs={"best_model": Output(type="mlflow_model")},
    )
    # set limits and training
    classification_node.set_limits(max_trials=1)
    classification_node.set_training(
        enable_stack_ensemble=False,
        enable_vote_ensemble=False
    )

    command_func = command(
        inputs=dict(
            automl_output=Input(type="mlflow_model")
        ),
        command="ls ${{inputs.automl_output}}",
        environment="AzureML-sklearn-0.24-ubuntu18.04-py37-cpu:latest"
    )
    show_output = command_func(automl_output=classification_node.outputs.best_model)


pipeline_job = automl_classification(
    classification_train_data=Input(path="./training-mltable-folder/", type="mltable"),
    classification_validation_data=Input(path="./validation-mltable-folder/", type="mltable"),
)

# set pipeline level compute
pipeline_job.settings.default_compute = compute_name

# submit the pipeline job
returned_pipeline_job = ml_client.jobs.create_or_update(
    pipeline_job,
    experiment_name=experiment_name
)
returned_pipeline_job

# ...
# Note that this is a snippet from the bankmarketing example you can find in our examples repo -> https://github.com/Azure/azureml-examples/tree/main/sdk/python/jobs/pipelines/1h_automl_in_pipeline/automl-classification-bankmarketing-in-pipeline

Weitere Beispiele dafür, wie Sie AutoML in Ihre Pipelines einbeziehen können, finden Sie in unserem Beispielrepository.

AutoML im großen Stil: verteiltes Training

Für Große Datenszenarien unterstützt AutoML verteiltes Training für eine begrenzte Gruppe von Modellen:

Verteilter Algorithmus Unterstützte Aufgaben Grenzwert für die Datengröße (ungefähr)
LightGBM Klassifizierung, Regression 1 TB
TCNForecaster Vorhersagen 200GB

Verteilte Trainingsalgorithmen partitionieren und verteilen Ihre Daten für das Modelltraining automatisch auf mehrere Computeknoten.

Hinweis

Kreuzvalidierung, Ensemblemodelle, ONNX-Unterstützung und Codegenerierung werden im verteilten Trainingsmodus derzeit nicht unterstützt. Außerdem kann AutoML Entscheidungen treffen, z. B. das Einschränken verfügbarer Featurizer und Subsamplingdaten, die für die Validierung, Erklärbarkeit und Modellauswertung verwendet werden.

Verteiltes Training für Klassifizierung und Regression

Um verteiltes Training für Klassifizierung oder Regression zu verwenden, müssen Sie die Eigenschaften training_mode und max_nodes des Auftragsobjekts festlegen.

Eigenschaft BESCHREIBUNG
training_mode Gibt den Trainingsmodus an; distributed oder non_distributed. Wird standardmäßig auf non_distributed festgelegt.
max_nodes Die Anzahl der Knoten, die für das Training durch jede AutoML-Testversion verwendet werden sollen. Diese Einstellung muss größer als oder gleich 4 sein.

Das folgende Codebeispiel zeigt ein Beispiel für diese Einstellungen für einen Klassifizierungsauftrag:

from azure.ai.ml.constants import TabularTrainingMode

# Set the training mode to distributed
classification_job.set_training(
    allowed_training_algorithms=["LightGBM"],
    training_mode=TabularTrainingMode.DISTRIBUTED
)

# Distribute training across 4 nodes for each trial
classification_job.set_limits(
    max_nodes=4,
    # other limit settings
)

Hinweis

Derzeit unterstützt verteiltes Training für Klassifizierungs- und Regressionsaufgaben mehrere gleichzeitige Testversionen nicht. Modelltests werden sequenziell mit jeder Testversion mithilfe von max_nodes-Knoten ausgeführt. Die Grenzwerteinstellung max_concurrent_trials wird derzeit ignoriert.

Verteiltes Training für Vorhersagen

Informationen dazu, wie verteiltes Training für Vorhersageaufgaben funktioniert, finden Sie in unserem Artikel Vorhersagen im großen Stil. Um verteiltes Training für Vorhersagen zu verwenden, müssen Sie die Eigenschaften training_mode, enable_dnn_training, max_nodes und optional max_concurrent_trials des Auftragsobjekts festlegen.

Eigenschaft BESCHREIBUNG
training_mode Gibt den Trainingsmodus an; distributed oder non_distributed. Wird standardmäßig auf non_distributed festgelegt.
enable_dnn_training Flag, um Deep Neural Network-Modelle zu aktivieren.
max_concurrent_trials Dies ist die maximale Anzahl von Testmodellen, die parallel trainiert werden. Der Standardwert lautet 1.
max_nodes Die Gesamtanzahl der Knoten, die für das Training verwendet werden sollen. Diese Einstellung muss größer als oder gleich 2 sein. Für Vorhersageaufgaben wird jedes Testmodell mithilfe der Knoten $\text{max}\left(2, \text{floor}( \text{max_nodes} / \text{max_concurrent_trials}) \right)$ trainiert.

Das folgende Codebeispiel zeigt ein Beispiel für diese Einstellungen für einen Vorhersageauftrag:

from azure.ai.ml.constants import TabularTrainingMode

# Set the training mode to distributed
forecasting_job.set_training(
    enable_dnn_training=True,
    allowed_training_algorithms=["TCNForecaster"],
    training_mode=TabularTrainingMode.DISTRIBUTED
)

# Distribute training across 4 nodes
# Train 2 trial models in parallel => 2 nodes per trial
forecasting_job.set_limits(
    max_concurrent_trials=2,
    max_nodes=4,
    # other limit settings
)

Beispiele für vollständigen Konfigurationscode finden Sie in den vorherigen Abschnitten zur Konfiguration und Auftragsübermittlung.

Nächste Schritte