Freigeben über

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 Artikel 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 Artikel enthält Details zu den verschiedenen Optionen, die Sie zum Konfigurieren von automatisierten ML-Experimenten verwenden können.

Wenn Sie ein No-Code-Konzept bevorzugen, können Sie das Training für automatisiertes maschinelles Lernen für Tabellendaten ohne Code über die Studio-Benutzeroberfläche einrichten.

Voraussetzungen

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

Um das SDK zu installieren, können Sie eine der folgenden Aktionen ausführen:

  • Erstellen Sie eine Compute-Instanz, auf der das neueste Azure Machine Learning Python SDK bereits installiert und für ML-Workflows konfiguriert ist. Weitere Informationen finden Sie unter Erstellen einer Azure Machine Learning-Computeinstanz.
  • 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 Arbeitsbereich 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 Azure-Standardauthentifizierung mit der Standardkonfiguration des Arbeitsbereichs oder der Standardkonfiguration aus einer config.json Datei in der Ordnerstruktur verwendet. Wenn keine config.json gefunden wird, müssen Sie beim Erstellen der MLClientmanuell die Abonnement-ID, Ressourcengruppe und den Arbeitsbereich einführen.

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)

Angeben der Datenquelle und des Formats

Um Trainingsdaten in SDK v2 bereitzustellen, müssen Sie sie ü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. Automatisierte ML v2 (Python SDK und CLI/YAML) akzeptiert MLTable-Datenressourcen (v2). Aus Gründen der Abwärtskompatibilität unterstützt es auch v1 Tabellarische Datasets aus v1, einem registrierten tabellarischen Dataset, über die gleichen Eingabedatensatzeigenschaften. Es wird empfohlen, MLTable zu verwenden, die in v2 verfügbar ist. In diesem Beispiel werden die Daten im lokalen Pfad ./train_data/bank_marketing_train_data.csv gespeichert.

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.

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

Weitere Informationen zu MLTable finden Sie unter Arbeiten mit Tabellen in Azure Machine Learning.

Trainieren, Überprüfen und Testen von Daten

Sie können separate Trainingsdaten und Validierungsdatensätze angeben. Trainingsdaten müssen dem training_data Parameter in der Factoryfunktion Ihres automatisierten Machine Learning-Auftrags bereitgestellt 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). Weitere Informationen zum Erstellen von Compute mit Python SDKv2 oder CLIv2 finden Sie unter Trainieren von Modellen mit Azure Machine Learning CLI, SDK und REST API.

Konfigurieren der Experimenteinstellungen

Es gibt verschiedene Optionen für das Konfigurieren Ihrer automatisierten Machine Learning-Experimente. 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

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 Auftrag verwendet und welche Modellalgorithmen angewendet werden.

Automatisierte ML unterstützt verschiedene Aufgabentypen:

  • Tabellendatenbasierte Aufgaben

    • Klassifizierung
    • Regression
    • Planung

  • Computer-Vision-Aufgaben, einschließlich

    • Bildklassifizierung
    • Objekterkennung

  • Verarbeitungsaufgaben für natürliche Sprachen, einschließlich

    • Textklassifizierung
    • Entitätserkennung

Weitere Informationen finden Sie unter Aufgabentypen. Weitere Informationen zum Einrichten von Prognoseaufträgen finden Sie unter Einrichten von AutoML zum Trainieren eines Zeitreihen-Prognosemodells.

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 oder 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 Tabelle werden die unterstützten Algorithmen pro Machine Learning-Aufgabe untersucht.

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
Mittelwert
Naive
SeasonalAverage

Mit anderen Algorithmen:

Ein Beispiel für Notebooks jedes Aufgabentyps finden Sie unter automl-standalone-jobs.

Primary metric (Primäre Metrik)

Der Parameter primary_metric bestimmt die Metrik, die während des Modelltrainings für die Optimierung verwendet werden soll. Der von Ihnen ausgewählte Aufgabentyp bestimmt die Metriken, die Sie auswählen können.

Bei der Auswahl einer primären Metrik für ein optimiertes automatisiertes maschinelles Lernen müssen eine Vielzahl von Faktoren berücksichtigt werden. Der wichtigste Aspekt sollte sein, welche Metrik Ihre Geschäftsanforderungen am besten widerspiegelt. Überlegen Sie dann, ob die Metrik für Ihr Datasetprofil geeignet ist, einschließlich Datengröße, Bereich und Klassenverteilung. In den folgenden Abschnitten werden die empfohlenen primären Metriken basierend auf dem Aufgabentyp und Geschäftsszenario zusammengefasst.

Informationen zu den spezifischen Definitionen dieser Metriken finden Sie unter Auswerten der Ergebnisse des automatisierten maschinellen Lernens.

Metriken für Szenarien zur Klassifizierung mit mehreren Klassen

Diese Metriken gelten für alle Klassifizierungsszenarien, einschließlich tabellarischer Daten, Bilder oder Computervisionen sowie Textverarbeitung natürlicher Sprache (NLP-Text).

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 maschinellen Lernens können Sie das beste Modell basierend auf der Metrik auswählen, die sich am besten für Ihre Geschäftsanforderungen eignet.

Metrik Beispiele für Anwendungsfälle
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 NLP-Text namens Erkennung benannter Entitäten

Für die Erkennung benannter Entitäten (NER) 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, die das Modell erfassen 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 anstelle des genauen Werts von Interesse ist, kann spearman_correlation eine bessere Wahl sein. Es misst die Rangkorrelation zwischen realen Werten und Vorhersagen.

Automatisches ML 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 Automatisches ML 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. Diese Metriken sind nicht definiert, wenn alle Beobachtungswerte 0 sind, sodass sie möglicherweise nicht immer eine gute Wahl sind.

Metrik Beispiele für Anwendungsfälle
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 Beispiele für Anwendungsfälle
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

In jedem automatisierten ML-Experiment werden Ihre Daten automatisch in Zahlen und Vektoren von Zahlen transformiert. Die Daten werden auch skaliert und normalisiert, um Algorithmen zu unterstützen, die für Features sensibel sind, die sich auf unterschiedlichen Skalierungen befinden. Diese Datentransformationen werden als Featurisierung bezeichnet.

Hinweis

Die Schritte zur Featurisierung bei automatisiertem maschinellem Lernen (z. B. Featurenormalisierung, Behandlung fehlender Daten und Umwandlung von Text in numerische Daten) 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.

Wenn Sie automatisierte Machine Learning-Aufträge konfigurieren, können Sie die featurization Einstellungen aktivieren oder 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. Dieser Wert ist die 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. Wenn keine Angabe erfolgt ist, wird als Wert „1 Monat“ oder „43.200 Minuten“ verwendet.
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 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

Übermitteln Sie das auszuführende Experiment, um ein Modell zu generieren.

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 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.

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 einen einzelnen Trainingslauf ausführen kann. Für automatisierte ML bedeutet dies eine untergeordnete Ausführung. Wenn alle Knoten ausgelastet sind, wird ein neues Experiment in die Warteschlange gestellt. Wenn es freie Knoten gibt, wird das neue Experiment parallel in den verfügbaren Knoten oder virtuellen Computern ausgeführt.

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. Siehe Bereitstellen Ihres Modells.

Verwenden von AutoML in Pipelines

Um automatisierte ML in Ihren Workflows für maschinelle Lernvorgänge zu verwenden, können Sie Ihren Azure Machine Learning Pipelines AutoML-Auftragsschritte hinzufügen. Mit diesem Ansatz können Sie Ihren gesamten Workflow automatisieren, indem Sie Ihre Datenvorbereitungsskripts mit automatisiertem ML verbinden. Registrieren und überprüfen Sie dann das resultierende beste Modell.

Dieser Code ist eine Beispielpipeline mit einer Komponente zur automatisierten ML-Klassifizierung und einer Befehlskomponente, die die resultierende Ausgabe anzeigt. Der Code verweist auf die Eingaben (Trainings- und Validierungsdaten) und die Ausgaben (bestes Modell) in verschiedenen Schritten.

# 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 zum Einschließen von automatisiertem ML in Ihre Pipelines finden Sie im Beispielrepository.

Nutzen Sie AutoML im großen Stil: verteiltes Training

Für Große Datenszenarien unterstützt Automatisiertes ML 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 200 GB

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 Automatisiertes ML 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 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 den 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 Dieser Wert 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.

Zugehöriger Inhalt