Hyperopt-begrepp

  • Artikel

Den här artikeln beskriver några av de begrepp som du behöver känna till för att använda distribuerad Hyperopt.

I det här avsnittet:

Exempel som illustrerar hur du använder Hyperopt i Azure Databricks finns i Hyperparameterjustering med Hyperopt.

fmin()

Du använder fmin() för att köra en Hyperopt-körning. Argumenten för fmin() visas i tabellen. Mer information finns i Hyperopt-dokumentationen . Exempel på hur du använder varje argument finns i exempelanteckningsböckerna.

Argumentnamn Beskrivning
fn Objektiv funktion. Hyperopt anropar den här funktionen med värden som genereras från hyperparameterutrymmet i blankstegsargumentet. Den här funktionen kan returnera förlusten som ett skalärt värde eller i en ordlista (se Hyperopt-dokument för mer information). Den här funktionen innehåller vanligtvis kod för modellträning och förlustberäkning.
space Definierar hyperparameterutrymmet som ska sökas. Hyperopt ger stor flexibilitet i hur det här utrymmet definieras. Du kan välja ett kategoriskt alternativ, till exempel algoritm eller probabilistisk distribution för numeriska värden som uniform och logg.
algo Hyperopt-sökalgoritm som ska användas för att söka i hyperparameterutrymme. De vanligaste är hyperopt.rand.suggest för slumpmässig sökning och hyperopt.tpe.suggest för TPE.
max_evals Antal hyperparameterinställningar som ska provas (antalet modeller som ska passa).
max_queue_len Antal hyperparameterinställningar som Hyperopt ska generera i förväg. Eftersom algoritmen för Hyperopt TPE-generering kan ta lite tid kan det vara bra att öka detta utöver standardvärdet 1, men vanligtvis inte större än SparkTrials inställningen parallelism.
trials Ett Trials eller SparkTrials -objekt. Använd SparkTrials när du anropar algoritmer för en enda dator, till exempel scikit-learn-metoder i målfunktionen. Använd Trials när du anropar distribuerade träningsalgoritmer som MLlib-metoder eller Horovod i målfunktionen.
early_stop_fn En valfri funktion för tidig stoppning för att avgöra om fmin ska stoppas innan max_evals den nås. Standardvärdet är None. Indatasignaturen för funktionen är Trials, *args och utdatasignaturen är bool, *args. Utdata booleskt värde anger om du vill stoppa eller inte. *args är ett tillstånd där utdata från ett anrop till early_stop_fn fungerar som indata till nästa anrop. Trials kan vara ett SparkTrials objekt. När du använder SparkTrialskommer funktionen för tidigt stopp inte garanterat att köras efter varje utvärderingsversion och avsöks i stället. Exempel på en funktion för tidig stoppning

Klassen SparkTrials

SparkTrials är ett API som utvecklats av Databricks som gör att du kan distribuera en Hyperopt-körning utan att göra andra ändringar i Hyperopt-koden. SparkTrials påskyndar justering av enskilda datorer genom att distribuera utvärderingsversioner till Spark-arbetare.

Observera

SparkTrials är utformad för att parallellisera beräkningar för ML-modeller med en dator, till exempel scikit-learn. För modeller som skapats med distribuerade ML-algoritmer som MLlib eller Horovod ska du inte använda SparkTrials. I det här fallet parallelliseras modellskapandeprocessen automatiskt i klustret och du bör använda standardklassen TrialsHyperopt .

Det här avsnittet beskriver hur du konfigurerar de argument som du skickar till SparkTrials och implementeringsaspekterna av SparkTrials.

Argument

SparkTrials tar två valfria argument:

  • parallelism: Maximalt antal utvärderingsversioner som ska utvärderas samtidigt. Med ett högre tal kan du skala ut testning av fler hyperparameterinställningar. Eftersom Hyperopt föreslår nya försök baserade på tidigare resultat finns det en kompromiss mellan parallellitet och anpassningsbarhet. För en fast max_evals, påskyndar större parallellitet beräkningar, men lägre parallellitet kan leda till bättre resultat eftersom varje iteration har åtkomst till fler tidigare resultat.

    Standard: Antal Tillgängliga Spark-utförare. Max: 128. Om värdet är större än antalet samtidiga uppgifter som tillåts av klusterkonfigurationen SparkTrials minskar parallelliteten med det här värdet.

  • timeout: Maximalt antal sekunder som ett fmin() samtal kan ta. När det här antalet överskrids avslutas alla körningar och fmin() avslutas. Information om slutförda körningar sparas.

Genomförandet

När du definierar den målfunktion fn som skickas till fmin()och när du väljer en klusterkonfiguration är det bra att förstå hur SparkTrials justeringsuppgifter distribueras.

I Hyperopt motsvarar en utvärderingsversion vanligtvis en modell på en inställning av hyperparametrar. Hyperopt genererar iterativt utvärderingsversioner, utvärderar dem och upprepar.

Med SparkTrialsgenererar drivrutinsnoden i klustret nya utvärderingsversioner och arbetsnoderna utvärderar dessa utvärderingsversioner. Varje utvärderingsversion genereras med ett Spark-jobb som har en uppgift och utvärderas i uppgiften på en arbetsdator. Om klustret har konfigurerats för att köra flera uppgifter per arbetare kan flera utvärderingsversioner utvärderas samtidigt på den arbetaren.

SparkTrials och MLflow

Databricks Runtime ML stöder loggning till MLflow från arbetare. Du kan lägga till anpassad loggningskod i den målfunktion som du skickar till Hyperopt.

SparkTrials loggar som justerar resultat när kapslade MLflow körs på följande sätt:

  • Huvudkörning eller överordnad körning: Anropet till fmin() loggas som huvudkörningen. Om det finns en aktiv körning SparkTrials loggar du till den här aktiva körningen och avslutar inte körningen när fmin() den returneras. Om det inte finns någon aktiv körning SparkTrials skapar du en ny körning, loggar till den och avslutar körningen innan fmin() den returneras.
  • Underordnade körningar: Varje hyperparameterinställning som testas (en "utvärderingsversion") loggas som en underordnad körning under huvudkörningen. MLflow-loggposter från arbetare lagras också under motsvarande underordnade körningar.

När du anropar fmin()rekommenderar Databricks aktiv MLflow-körningshantering, dvs. omsluter anropet till fmin() i en with mlflow.start_run(): instruktion. Detta säkerställer att varje fmin() anrop loggas till en separat MLflow-huvudkörning och gör det enklare att logga extra taggar, parametrar eller mått för den körningen.

Observera

När du anropar fmin() flera gånger inom samma aktiva MLflow-körning loggar MLflow dessa anrop till samma huvudkörning. För att lösa namnkonflikter för loggade parametrar och taggar lägger MLflow till ett UUID i namn med konflikter.

När du loggar från arbetare behöver du inte hantera körningar explicit i målfunktionen. Anropa mlflow.log_param("param_from_worker", x) i målfunktionen för att logga en parameter till den underordnade körningen. Du kan logga parametrar, mått, taggar och artefakter i målfunktionen.