Condividi tramite

Concetti di Hyperopt

  • Articolo

Nota

La versione open source di Hyperopt non è più gestita.

Hyperopt verrà rimosso nella prossima versione principale di DBR ML. Azure Databricks consiglia di usare Optuna per l'ottimizzazione a nodo singolo o RayTune per un'esperienza simile alla funzionalità di tuning distribuita degli iperparametri di Hyperopt, che è stata deprecata. Altre informazioni sull'uso di RayTune in Azure Databricks.

Questo articolo descrive alcuni dei concetti che è necessario conoscere per usare Hyperopt distribuito.

Contenuto della sezione:

Per esempi che illustrano come usare Hyperopt in Azure Databricks, vedere Hyperopt.

fmin()

fmin() Usare per eseguire un'esecuzione hyperopt. Gli argomenti per fmin() sono mostrati nella tabella; per ulteriori informazioni, consultare la documentazione di Hyperopt . Per esempi di come usare ogni argomento, vedere i notebook di esempio.

Nome dell'argomento Descrizione
fn Funzione Objective. Hyperopt chiama questa funzione con valori generati dallo spazio degli iperparametri fornito nel parametro spazio. Questa funzione può restituire la perdita come valore scalare o in un dizionario (vedere la documentazione di Hyperopt per informazioni dettagliate). Questa funzione contiene in genere codice per il calcolo del training e della perdita del modello.
space Definisce lo spazio degli iperparametri da cercare. Hyperopt offre una grande flessibilità nella definizione di questo spazio. È possibile scegliere un'opzione categorica, ad esempio algoritmo o distribuzione probabilistica per valori numerici, ad esempio uniform e log.
algo Algoritmo di ricerca Hyperopt da usare per cercare lo spazio degli iperparametri. Più comunemente usato sono hyperopt.rand.suggest per la ricerca casuale e hyperopt.tpe.suggest per TPE.
max_evals Numero di impostazioni degli iperparametri da provare (numero di modelli da adattare).
max_queue_len Il numero di configurazioni degli iperparametri che Hyperopt dovrebbe generare in anticipo. Poiché l'algoritmo di generazione TPE Hyperopt può richiedere del tempo, può essere utile aumentare questo valore oltre il valore predefinito 1, ma in genere non più grande dell'impostazione SparkTrialsparallelism.
trials Oggetto Trials o SparkTrials. Usare SparkTrials quando si chiamano algoritmi a computer singolo, ad esempio i metodi scikit-learn nella funzione objective. Usare Trials quando si chiamano algoritmi di training distribuiti, ad esempio metodi MLlib o Horovod nella funzione obiettivo.
early_stop_fn Funzione facoltativa di arresto anticipato per determinare se fmin deve essere interrotta prima max_evals di essere raggiunta. Il valore predefinito è None. La firma di input della funzione è Trials, *args e la firma di output è bool, *args. Il valore booleano di output indica se arrestare o meno. *args è qualsiasi stato, in cui l'output di una chiamata a early_stop_fn funge da input per la chiamata successiva. Trials può essere un SparkTrials oggetto . Quando si usa SparkTrials, la funzione di arresto anticipato non è garantita per l'esecuzione dopo ogni prova e viene invece eseguito il polling. Esempio di una funzione di arresto anticipato

Classe SparkTrials

SparkTrials è un'API sviluppata da Databricks che consente di distribuire un'esecuzione Hyperopt senza apportare altre modifiche al codice Hyperopt. SparkTrials accelera l'ottimizzazione a computer singolo distribuendo le versioni di valutazione ai ruoli di lavoro Spark.

Nota

SparkTrials è progettato per parallelizzare i calcoli per modelli di Machine Learning singolo, ad esempio scikit-learn. Per i modelli creati con algoritmi di Machine Learning distribuiti, ad esempio MLlib o Horovod, non usare SparkTrials. In questo caso il processo di compilazione del modello viene parallelizzato automaticamente nel cluster ed è necessario usare la classe TrialsHyperopt predefinita .

In questa sezione viene descritto come configurare gli argomenti passati agli SparkTrials aspetti di implementazione e .SparkTrials

Argomenti

SparkTrials accetta due argomenti facoltativi:

  • parallelism: numero massimo di versioni di valutazione da valutare contemporaneamente. Un numero maggiore consente di aumentare il numero di test delle impostazioni degli iperparametri. Poiché Hyperopt propone nuove prove basate sui risultati passati, c'è un compromesso tra parallelismo e adattabilità. Per un valore fisso max_evals, un maggiore parallelismo velocizza i calcoli, ma un parallelismo inferiore può portare a risultati migliori poiché ogni iterazione ha accesso a risultati più passati.

    Impostazione predefinita: numero di executor Spark disponibili. Massimo: 128. Se il valore è maggiore del numero di attività simultanee consentite dalla configurazione del cluster, SparkTrials riduce il parallelismo a questo valore.

  • timeout: numero massimo di secondi che può essere eseguita una fmin() chiamata. Quando questo numero viene superato, tutte le esecuzioni vengono terminate e fmin() vengono chiuse. Le informazioni sulle esecuzioni completate vengono salvate.

Implementazione

Quando si definisce la funzione fn obiettivo passata a fmin()e quando si seleziona una configurazione del cluster, è utile comprendere in che modo SparkTrials distribuisce le attività di ottimizzazione.

In Hyperopt, una versione di valutazione corrisponde in genere all'adattamento di un modello su un'impostazione di iperparametri. Hyperopt genera in modo iterativo le prove, le valuta e si ripete.

Con SparkTrials, il nodo driver del cluster genera nuove versioni di valutazione e i nodi di lavoro valutano tali versioni di valutazione. Ogni versione di valutazione viene generata con un processo Spark che ha un'attività e viene valutata nell'attività in un computer di lavoro. Se il cluster è configurato per eseguire più attività per ogni lavoratore, è possibile valutare più prove contemporaneamente su quel lavoratore.

SparkTrials e MLflow

Databricks Runtime ML supporta la registrazione a MLflow dai ruoli di lavoro. È possibile aggiungere codice di registrazione personalizzato nella funzione obiettivo passata a Hyperopt.

SparkTrials registra i risultati di ottimizzazione come viene eseguito MLflow annidato come segue:

  • Esecuzione principale o padre: la chiamata a fmin() viene registrata come esecuzione principale. Se è presente un'esecuzione attiva, SparkTrials accede a questa esecuzione attiva e non termina l'esecuzione quando fmin() viene restituita. Se non è presente alcuna esecuzione attiva, SparkTrials crea una nuova esecuzione, vi registra e termina l'esecuzione prima fmin() di restituire.
  • Esecuzioni figlio: ogni impostazione degli iperparametri testata (una "versione di valutazione") viene registrata come esecuzione figlio nell'esecuzione principale. I record di log di MLflow dei ruoli di lavoro vengono archiviati anche nelle esecuzioni figlio corrispondenti.

Quando si chiama fmin(), Databricks consiglia la gestione dell'esecuzione MLflow attiva, ovvero eseguire il wrapping della chiamata a fmin() all'interno di un'istruzione with mlflow.start_run(): . In questo modo, ogni chiamata fmin() viene registrata in un'esecuzione principale MLflow separata e semplifica la registrazione di tag, parametri o metriche aggiuntive per quella esecuzione.

Nota

Quando si chiama fmin() più volte all'interno della stessa esecuzione attiva di MLflow, MLflow registra tali chiamate alla stessa esecuzione principale. Per risolvere i conflitti di nomi per i parametri e i tag registrati, MLflow aggiunge un UUID ai nomi con conflitti.

Quando si esegue la registrazione dai ruoli di lavoro, non è necessario gestire le esecuzioni in modo esplicito nella funzione obiettivo. Chiamare mlflow.log_param("param_from_worker", x) nella funzione obiettivo per registrare un parametro all'esecuzione figlio. È possibile registrare parametri, metriche, tag e artefatti nella funzione obiettivo.