Udforsk avancerede teknikker til hyperparameteroptimering med Amazon SageMaker Automatic Model Tuning | Amazon Web Services

Oprettelse af high-performance machine learning (ML) løsninger er afhængig af at udforske og optimere træningsparametre, også kendt som hyperparametre. Hyperparametre er de knapper og håndtag, som vi bruger til at justere træningsprocessen, såsom indlæringshastighed, batchstørrelse, regulariseringsstyrke og andre, afhængigt af den specifikke model og opgave. Udforskning af hyperparametre involverer systematisk at variere værdierne af hver parameter og observere indvirkningen på modellens ydeevne. Selvom denne proces kræver yderligere indsats, er fordelene betydelige. Hyperparameteroptimering (HPO) kan føre til hurtigere træningstider, forbedret modelnøjagtighed og bedre generalisering til nye data.

Vi fortsætter vores rejse fra posten Optimer hyperparametre med Amazon SageMaker Automatic Model Tuning. Vi har tidligere udforsket en enkelt joboptimering, visualiseret resultaterne for SageMaker indbyggede algoritme og lært om virkningen af ​​bestemte hyperparameterværdier. Ud over at bruge HPO som en engangsoptimering i slutningen af ​​modeloprettelsescyklussen, kan vi også bruge det på tværs af flere trin på en samtale måde. Hvert tuningjob hjælper os med at komme tættere på en god præstation, men derudover lærer vi også, hvor følsom modellen er over for visse hyperparametre og kan bruge denne forståelse til at informere det næste tuningjob. Vi kan revidere hyperparametrene og deres værdiområder baseret på det, vi har lært, og derfor gøre denne optimeringsindsats til en samtale. Og på samme måde som vi som ML-udøvere samler viden over disse kørsler, Amazon SageMaker Automatic Model Tuning (AMT) med varme starter kan opretholde denne viden erhvervet i tidligere tuning job til det næste tuning job.

I dette indlæg kører vi flere HPO-job med en tilpasset træningsalgoritme og forskellige HPO-strategier såsom Bayesiansk optimering og tilfældig søgning. Vi sætter også varme begyndelser i gang og sammenligner visuelt vores forsøg for at forfine rumudforskningen af ​​hyperparameter.

Avancerede koncepter af SageMaker AMT

I de næste afsnit ser vi nærmere på hvert af følgende emner og viser, hvordan SageMaker AMT kan hjælpe dig med at implementere dem i dine ML-projekter:

• Brug tilpasset træningskode og det populære ML framework Scikit-learn i SageMaker Training
• Definer tilpassede evalueringsmetrikker baseret på logfilerne til evaluering og optimering
• Udfør HPO ved hjælp af en passende strategi
• Brug varme starter til at omdanne en enkelt hyperparametersøgning til en dialog med vores model
• Brug avancerede visualiseringsteknikker ved hjælp af vores løsningsbibliotek til at sammenligne to HPO-strategier og finjustere jobresultater

Uanset om du bruger de indbyggede algoritmer brugt i vores første indlæg eller din egen træningskode, tilbyder SageMaker AMT en problemfri brugeroplevelse til optimering af ML-modeller. Det giver nøglefunktionalitet, der giver dig mulighed for at fokusere på ML-problemet, mens du automatisk holder styr på forsøgene og resultaterne. Samtidig administrerer den automatisk den underliggende infrastruktur for dig.

I dette indlæg bevæger vi os væk fra en SageMaker indbygget algoritme og bruger tilpasset kode. Vi bruger en Random Forest fra SkLearn. Men vi holder os til den samme ML-opgave og datasæt som i vores første indlæg, som registrerer håndskrevne cifre. Vi dækker indholdet af Jupyter-notesbogen 2_avanceret_tuning_med_tilpasset_træning_og_visualisering.ipynb og inviterer dig til at kalde koden side om side for at læse videre.

Lad os dykke dybere og opdage, hvordan vi kan bruge tilpasset træningskode, implementere den og køre den, mens vi udforsker hyperparametersøgerummet for at optimere vores resultater.

Hvordan man bygger en ML-model og udfører hyperparameteroptimering

Hvordan ser en typisk proces til at bygge en ML-løsning ud? Selvom der er mange mulige use cases og et stort udvalg af ML-opgaver derude, foreslår vi følgende mentale model for en trinvis tilgang:

1. Forstå dit ML-scenarie ved hånden, og vælg en algoritme baseret på kravene. For eksempel vil du måske løse en billedgenkendelsesopgave ved hjælp af en overvåget indlæringsalgoritme. I dette indlæg fortsætter vi med at bruge scenariet for håndskrevne billedgenkendelse og det samme datasæt som i vores første indlæg.
2. Bestem hvilken implementering af algoritmen i SageMaker Training du vil bruge. Der er forskellige muligheder, inde i SageMaker eller eksterne. Derudover skal du definere, hvilken underliggende metrik der passer bedst til din opgave, og du vil optimere til (såsom nøjagtighed, F1-score eller ROC). SageMaker understøtter fire muligheder afhængigt af dine behov og ressourcer:
   • Brug en fortrænet model via Amazon SageMaker JumpStart, som du kan bruge ud af æsken eller bare finjustere den.
   • Brug en af ​​de indbyggede algoritmer til træning og tuning, som XGBoost, som vi gjorde i vores tidligere indlæg.
   • Træn og tune en brugerdefineret model baseret på en af ​​de store rammer som Scikit-learn, TensorFlow eller PyTorch. AWS tilbyder et udvalg af forudlavede Docker-billeder til dette formål. Til dette indlæg bruger vi denne mulighed, som giver dig mulighed for hurtigt at eksperimentere ved at køre din egen kode oven på et forudlavet containerbillede.
   • Medbring dit eget brugerdefinerede Docker-billede, hvis du vil bruge en ramme eller software, der ikke på anden måde understøttes. Denne mulighed kræver den største indsats, men giver også den højeste grad af fleksibilitet og kontrol.
3. Træn modellen med dine data. Afhængigt af algoritmeimplementeringen fra det foregående trin, kan dette være så simpelt som at referere til dine træningsdata og køre træningsjobbet eller ved yderligere at levere tilpasset kode til træning. I vores tilfælde bruger vi noget tilpasset træningskode i Python baseret på Scikit-learn.
4. Anvend hyperparameteroptimering (som en "samtale" med din ML-model). Efter træningen ønsker du typisk at optimere ydeevnen af ​​din model ved at finde den mest lovende kombination af værdier for din algoritmes hyperparametre.

Afhængigt af din ML-algoritme og modelstørrelse kan det sidste trin i hyperparameteroptimering vise sig at være en større udfordring end forventet. Følgende spørgsmål er typiske for ML-udøvere på dette stadium og lyder måske bekendt for dig:

• Hvilken slags hyperparametre har betydning for mit ML-problem?
• Hvordan kan jeg effektivt søge i et stort hyperparameterrum for at finde de bedst ydende værdier?
• Hvordan påvirker kombinationen af ​​visse hyperparameterværdier min præstationsmåling?
• Omkostninger betyder noget; hvordan kan jeg bruge mine ressourcer på en effektiv måde?
• Hvilken slags tuning-eksperimenter er umagen værd, og hvordan kan jeg sammenligne dem?

Det er ikke let at besvare disse spørgsmål, men der er gode nyheder. SageMaker AMT tager de tunge løft fra dig og lader dig koncentrere dig om at vælge den rigtige HPO-strategi og værdiintervaller, du ønsker at udforske. Derudover letter vores visualiseringsløsning den iterative analyse- og eksperimenteringsproces for effektivt at finde velfungerende hyperparameterværdier.

I de næste afsnit bygger vi en ciffergenkendelsesmodel fra bunden ved hjælp af Scikit-learn og viser alle disse koncepter i aktion.

Løsningsoversigt

SageMaker tilbyder nogle meget praktiske funktioner til at træne, evaluere og tune vores model. Den dækker al funktionalitet af en end-to-end ML-livscyklus, så vi behøver ikke engang at forlade vores Jupyter-notebook.

I vores første indlæg brugte vi SageMaker indbyggede algoritme XGBoost. Til demonstrationsformål skifter vi denne gang til en Random Forest-klassifikator, fordi vi så kan vise, hvordan du giver din egen træningskode. Vi valgte at levere vores eget Python-script og bruge Scikit-learn som vores ramme. Hvordan udtrykker vi nu, at vi ønsker at bruge en specifik ML-ramme? Som vi vil se, bruger SageMaker en anden AWS-tjeneste i baggrunden til at hente et forudbygget Docker-containerbillede til træning—Amazon Elastic Container Registry (Amazon ECR).

Vi dækker de følgende trin i detaljer, inklusive kodestykker og diagrammer til at forbinde prikkerne. Som nævnt før, hvis du har muligheden, skal du åbne notesbogen og køre kodecellerne trin for trin for at skabe artefakter i dit AWS-miljø. Der er ingen bedre måde til aktiv læring.

1. Indlæs og klargør først dataene. Vi bruger Amazon Simple Storage Service (Amazon S3) for at uploade en fil, der indeholder vores håndskrevne taldata.
2. Forbered derefter træningsscriptet og rammeafhængigheder. Vi leverer den tilpassede træningskode i Python, refererer til nogle afhængige biblioteker og laver en testkørsel.
3. For at definere de tilpassede objektive metrics, lader SageMaker os definere et regulært udtryk for at udtrække de metrics, vi har brug for, fra containerlogfilerne.
4. Træn modellen ved hjælp af scikit-learn rammen. Ved at referere til et forudbygget containerbillede opretter vi et tilsvarende Estimator-objekt og videregiver vores tilpassede træningsscript.
5. AMT giver os mulighed for at afprøve forskellige HPO-strategier. Vi koncentrerer os om to af dem i dette indlæg: tilfældig søgning og Bayesiansk søgning.
6. Vælg mellem SageMaker HPO-strategier.
7. Visualiser, analyser og sammenlign tuning-resultater. Vores visualiseringspakke giver os mulighed for at opdage, hvilken strategi der yder bedre, og hvilke hyperparameterværdier, der leverer den bedste ydeevne baseret på vores metrics.
8. Fortsæt udforskningen af ​​hyperparameterrummet og varmstart HPO-job.

AMT tager sig af skalering og styring af den underliggende computerinfrastruktur til at køre de forskellige tuningjobs på Amazon Elastic Compute Cloud (Amazon EC2) forekomster. På denne måde behøver du ikke at byrde dig selv til at levere instanser, håndtere eventuelle operativsystem- og hardwareproblemer eller samle logfiler på egen hånd. ML-rammebilledet hentes fra Amazon ECR, og modelartefakter, inklusive tuning-resultater, gemmes i Amazon S3. Alle logfiler og metrics er samlet i amazoncloudwatch for nem adgang og yderligere analyse, hvis det er nødvendigt.

Forudsætninger

Fordi dette er en fortsættelse af en serie, anbefales det, men ikke nødvendigvis, at læse vores første indlæg om SageMaker AMT og HPO. Bortset fra det er grundlæggende kendskab til ML-koncepter og Python-programmering nyttig. Vi anbefaler også at følge med i hvert trin i medfølgende notesbog fra vores GitHub-lager, mens du læser dette indlæg. Notebook'en kan køres uafhængigt af den første, men har brug for noget kode fra undermapper. Sørg for at klone hele depotet i dit miljø som beskrevet i README-filen.

At eksperimentere med koden og bruge de interaktive visualiseringsmuligheder forbedrer i høj grad din læringsoplevelse. Så tjek det venligst ud.

Indlæs og klargør dataene

Som et første skridt sørger vi for, at den downloadede cifre data vi har brug for træning er tilgængelig for SageMaker. Amazon S3 giver os mulighed for at gøre dette på en sikker og skalerbar måde. Se notesbogen for den komplette kildekode, og tilpas den gerne med dine egne data.

sm_sess = sagemaker.session.Session(boto_session=boto_sess, sagemaker_client=sm)
BUCKET = sm_sess.default_bucket()
PREFIX = 'amt-visualize-demo'
s3_data_url = f's3://{BUCKET}/{PREFIX}/data'
digits = datasets.load_digits()
digits_df = pd.DataFrame(digits.data)
digits_df['y'] = digits.target
digits_df.to_csv('data/digits.csv', index=False)
!aws s3 sync data/ {s3_data_url} —exclude '*' —include 'digits.csv'

digits.csv fil indeholder funktionsdata og etiketter. Hvert ciffer er repræsenteret af pixelværdier i et 8×8 billede, som afbildet af det følgende billede for ciffer 4.

Forbered træningsscriptet og rammeafhængigheder

Nu hvor dataene er gemt i vores S3-bøtte, kan vi definere vores tilpassede træningsscript baseret på Scikit-lære i Python. SageMaker giver os mulighed for blot at henvise til Python-filen senere til træning. Enhver afhængighed som Scikit-learn eller pandas biblioteker kan leveres på to måder:

• De kan specificeres eksplicit i en requirements.txt fil
• De er forudinstalleret i det underliggende ML-containerbillede, som enten leveres af SageMaker eller specialbygget

Begge muligheder betragtes generelt som standardmetoder til afhængighedsstyring, så du er måske allerede bekendt med det. SageMaker understøtter en række forskellige ML-rammer i et klar-til-brug administreret miljø. Dette inkluderer mange af de mest populære datavidenskab og ML-rammer som PyTorch, TensorFlow eller Scikit-learn, som i vores tilfælde. Vi bruger ikke en ekstra requirements.txt fil, men du er velkommen til at tilføje nogle biblioteker for at prøve det.

Koden for vores implementering indeholder en metode kaldet fit(), som opretter en ny klassifikator til ciffergenkendelsesopgaven og træner den. I modsætning til vores første indlæg, hvor vi brugte SageMaker indbyggede XGBoost-algoritme, bruger vi nu en RandomForestClassifier leveret af ML biblioteket sklearn. Opkaldet fra fit() metode på klassificeringsobjektet starter træningsprocessen ved hjælp af en delmængde (80 %) af vores CSV-data:

def fit(train_dir, n_estimators, max_depth, min_samples_leaf, max_features, min_weight_fraction_leaf): digits = pd.read_csv(Path(train_dir)/'digits.csv') Xtrain, Xtest, ytrain, ytest = train_test_split(digits.iloc[:, :-1], digits.iloc[:, -1], test_size=.2) m = RandomForestClassifier(n_estimators=n_estimators, max_depth=max_depth, min_samples_leaf=min_samples_leaf, max_features=max_features, min_weight_fraction_leaf=min_weight_fraction_leaf) m.fit(Xtrain, ytrain) predicted = m.predict(Xtest) pre, rec, f1, _ = precision_recall_fscore_support(ytest, predicted, pos_label=1, average='weighted') print(f'pre: {pre:5.3f} rec: {rec:5.3f} f1: {f1:5.3}') return m

Se hele manuskriptet i vores Jupyter-notesbog på GitHub.

Prøvede du at køre scriptet direkte, før du opretter containerressourcer til hele træningsprocessen? Dette er en god praksis for hurtigt at sikre, at koden ikke har nogen syntaksfejl, tjekke for matchende dimensioner af dine datastrukturer og nogle andre fejl tidligt.

Der er to måder at køre din kode på lokalt. For det første kan du køre det med det samme i notesbogen, som også giver dig mulighed for at bruge Python Debugger pdb:

# Running the code from within the notebook. It would then be possible to use the Python Debugger, pdb.
from train import fit
fit('data', 100, 10, 1, 'auto', 0.01)

Alternativt kan du køre togscriptet fra kommandolinjen på samme måde, som du måske vil bruge det i en container. Dette understøtter også indstilling af forskellige parametre og overskrivning af standardværdierne efter behov, for eksempel:

!cd src && python train.py --train ../data/ --model-dir /tmp/ --n-estimators 100

Som output kan du se de første resultater for modellens ydeevne baseret på de objektive metrics præcision, genkaldelse og F1-score. For eksempel, pre: 0.970 rec: 0.969 f1: 0.969.

Ikke dårligt for sådan en hurtig træning. Men hvor kom disse tal fra, og hvad gør vi med dem?

Definer tilpassede målmålinger

Husk, vores mål er fuldt ud at træne og tune vores model baseret på de objektive målinger, vi anser for relevante for vores opgave. Fordi vi bruger et brugerdefineret træningsscript, er vi nødt til at definere disse metrics for SageMaker eksplicit.

Vores script udsender metrics præcision, genkaldelse og F1-score under træning blot ved at bruge print fungere:

print(f'pre: {pre:5.3f} rec: {rec:5.3f} f1: {f1:5.3}')

Standardoutputtet fanges af SageMaker og sendes til CloudWatch som en log-stream. For at hente de metriske værdier og arbejde med dem senere i SageMaker AMT, skal vi give nogle oplysninger om, hvordan man parser det output. Vi kan opnå dette ved at definere regulære udtryksudsagn (for mere information, se Overvåg og analyser træningsjob ved hjælp af Amazon CloudWatch-metrics):

metric_definitions = [ {'Name': 'valid-precision', 'Regex': r'pre:s+(-?[0-9.]+)'}, {'Name': 'valid-recall', 'Regex': r'rec:s+(-?[0-9.]+)'}, {'Name': 'valid-f1', 'Regex': r'f1:s+(-?[0-9.]+)'}] 

Lad os gennemgå den første metriske definition i den foregående kode sammen. SageMaker vil lede efter output i loggen, der starter med pre: og efterfølges af et eller flere mellemrum og derefter et tal, som vi vil udtrække, hvorfor vi bruger den runde parentes. Hver gang SageMaker finder en sådan værdi, forvandler den den til en CloudWatch-metrik med navnet valid-precision.

Træn modellen ved hjælp af Scikit-learn rammen

Efter vi har oprettet vores træningsscript train.py og instruere SageMaker om, hvordan man overvåger metrikkerne i CloudWatch, definerer vi en SageMaker Estimator objekt. Det starter træningsjobbet og bruger den instanstype, vi angiver. Men hvordan kan denne instanstype være forskellig fra den, du kører en Amazon SageMaker Studio notesbog på, og hvorfor? SageMaker Studio kører dine trænings- (og inferens-) jobs på separate computerinstanser end din notebook. Dette giver dig mulighed for at fortsætte med at arbejde i din notesbog, mens opgaverne kører i baggrunden.

Parameteren framework_version henviser til den Scikit-learn-version, vi bruger til vores træningsjob. Alternativt kan vi bestå image_uri til estimator. Du kan kontrollere, om dit foretrukne framework eller ML-bibliotek er tilgængeligt som en forudbygget SageMaker Docker-billede og brug det som det er eller med forlængelser.

Desuden kan vi køre SageMaker træningsjob på EC2 Spot Instances ved at indstille use_spot_instances til True. De er ledige kapacitetsinstanser, der kan spar op til 90 % af omkostningerne. Disse forekomster giver fleksibilitet, når træningsjobene køres.

estimator = SKLearn( 'train.py', source_dir='src', role=get_execution_role(), instance_type= 'ml.m5.large', instance_count=1, framework_version='0.23-1', metric_definitions=metric_definitions, # Uncomment the following three lines to use Managed Spot Training # use_spot_instances= True, # max_run= 60 * 60 * 24, # max_wait= 60 * 60 * 24, hyperparameters = {'n-estimators': 100, 'max-depth': 10, 'min-samples-leaf': 1, 'max-features': 'auto', 'min-weight-fraction-leaf': 0.1}
)

Efter at Estimator-objektet er sat op, starter vi træningen ved at ringe til fit() funktion, der leverer stien til træningsdatasættet på Amazon S3. Vi kan bruge den samme metode til at levere validerings- og testdata. Vi indstiller wait parameter til True så vi kan bruge den trænede model i de efterfølgende kodeceller.

estimator.fit({'train': s3_data_url}, wait=True)

Definer hyperparametre og kør tuningjobs

Indtil videre har vi trænet modellen med ét sæt hyperparameterværdier. Men var de værdier gode? Eller kunne vi kigge efter bedre? Lad os bruge HyperparameterTuner klasse at køre en systematisk søgning over hyperparameterrummet. Hvordan søger vi dette rum med tuneren? De nødvendige parametre er det objektive metriske navn og den objektivtype, der vil guide optimeringen. Optimeringsstrategien er et andet nøgleargument for tuneren, fordi den yderligere definerer søgerummet. Følgende er fire forskellige strategier at vælge imellem:

• Netsøgning
• Tilfældig søgning
• Bayesiansk optimering (standard)
• Hyperbånd

Vi beskriver yderligere disse strategier og udstyrer dig med lidt vejledning til at vælge en senere i dette indlæg.

Før vi definerer og kører vores tunerobjekt, lad os opsummere vores forståelse fra et arkitekturperspektiv. Vi dækkede det arkitektoniske overblik over SageMaker AMT i vores sidste indlæg og gengiv et uddrag af det her for nemheds skyld.

Vi kan vælge hvilke hyperparametre vi vil tune eller lade være statiske. Til dynamiske hyperparametre leverer vi hyperparameter_ranges der kan bruges til at optimere til justerbare hyperparametre. Fordi vi bruger en Random Forest-klassifikator, har vi brugt hyperparametrene fra Scikit-learn Random Forest-dokumentation.

Vi begrænser også ressourcerne med det maksimale antal træningsjob og parallelle træningsjob, som tuneren kan bruge. Vi vil se, hvordan disse grænser hjælper os med at sammenligne resultaterne af forskellige strategier med hinanden.

tuner_parameters = { 'estimator': estimator, 'base_tuning_job_name': 'random', 'metric_definitions': metric_definitions, 'objective_metric_name': 'valid-f1', 'objective_type': 'Maximize', 'hyperparameter_ranges': hpt_ranges, 'strategy': 'Random', 'max_jobs': n, # 50 'max_parallel_jobs': k # 2 } 

Svarende til estimatorens fit funktion starter vi et tuningjob, der kalder tunerens fit:

random_tuner = HyperparameterTuner(**tuner_parameters)
random_tuner.fit({'train': s3_data_url}, wait=False)

Dette er alt, hvad vi skal gøre for at lade SageMaker køre træningsjob (n=50) i baggrunden, hver ved hjælp af et andet sæt hyperparametre. Vi udforsker resultaterne senere i dette indlæg. Men før det, lad os starte endnu et tuning-job, denne gang ved at anvende den Bayesianske optimeringsstrategi. Vi vil sammenligne begge strategier visuelt efter deres afslutning.

tuner_parameters['strategy'] = 'Bayesian'
tuner_parameters['base_tuning_job_name'] = 'bayesian'
bayesian_tuner = HyperparameterTuner(**tuner_parameters)
bayesian_tuner.fit({'train': s3_data_url}, wait=False)

Bemærk, at begge tunerjob kan køre parallelt, fordi SageMaker orkestrerer de påkrævede computerforekomster uafhængigt af hinanden. Det er ganske nyttigt for praktikere, der eksperimenterer med forskellige tilgange på samme tid, som vi gør her.

Vælg mellem SageMaker HPO-strategier

Når det kommer til tuning-strategier, har du et par muligheder med SageMaker AMT: gittersøgning, tilfældig søgning, Bayesiansk optimering og Hyperband. Disse strategier bestemmer, hvordan de automatiske tuning-algoritmer udforsker de specificerede områder af hyperparametre.

Tilfældig søgning er ret ligetil. Den vælger tilfældigt kombinationer af værdier fra de angivne områder og kan køres på en sekventiel eller parallel måde. Det er som at kaste pile med bind for øjnene i håb om at ramme målet. Vi er begyndt med denne strategi, men vil resultaterne blive bedre med en anden?

Bayesiansk optimering tager en anden tilgang end tilfældig søgning. Den tager højde for historikken for tidligere valg og vælger værdier, der sandsynligvis vil give de bedste resultater. Hvis du vil lære af tidligere udforskninger, kan du kun opnå dette ved at køre et nyt tuningjob efter de foregående. Giver mening, ikke? På denne måde er Bayesiansk optimering afhængig af de tidligere kørsler. Men kan du se, hvilken HPO-strategi giver mulighed for højere parallelisering?

Hyperbånd er en interessant en! Den bruger en multi-fidelity-strategi, hvilket betyder, at den dynamisk allokerer ressourcer til de mest lovende træningsjob og stopper dem, der er underpræsterende. Derfor er Hyperband beregningseffektiv med ressourcer og lærer af tidligere træningsjob. Efter at have stoppet de underpræsterende konfigurationer, starter en ny konfiguration, og dens værdier vælges tilfældigt.

Afhængigt af dine behov og arten af ​​din model, kan du vælge mellem tilfældig søgning, Bayesiansk optimering eller Hyperband som din tuning-strategi. Hver har sin egen tilgang og fordele, så det er vigtigt at overveje, hvilken der fungerer bedst til din ML-udforskning. Den gode nyhed for ML-udøvere er, at du kan vælge den bedste HPO-strategi ved visuelt at sammenligne virkningen af ​​hvert forsøg på den objektive metrik. I næste afsnit ser vi, hvordan man visuelt identificerer virkningen af ​​forskellige strategier.

Visualiser, analyser og sammenlign tuning-resultater

Når vores tuning-opgaver er færdige, bliver det spændende. Hvilke resultater giver de? Hvilken form for boost kan du forvente på vores metrisk sammenlignet med din basismodel? Hvad er de bedst ydende hyperparametre til vores use case?

En hurtig og ligetil måde at se HPO-resultaterne på er ved at besøge SageMaker-konsollen. Under Hyperparameter tuning job, kan vi se (pr. tuningjob) kombinationen af ​​hyperparameterværdier, der er blevet testet og leveret den bedste ydeevne målt ved vores objektive metric (valid-f1).

Er det alt hvad du behøver? Som ML-praktiker er du måske ikke kun interesseret i disse værdier, men du vil helt sikkert gerne lære mere om din models indre virkemåde for at udforske dens fulde potentiale og styrke din intuition med empirisk feedback.

Et godt visualiseringsværktøj kan i høj grad hjælpe dig med at forstå forbedringen af ​​HPO over tid og få empirisk feedback på designbeslutninger af din ML-model. Det viser virkningen af ​​hver enkelt hyperparameter på din objektive metrik og giver vejledning til yderligere at optimere dine tuning-resultater.

Vi bruger amtviz tilpasset visualiseringspakke til at visualisere og analysere tuning-job. Det er nemt at bruge og giver nyttige funktioner. Vi demonstrerer fordelene ved at fortolke nogle individuelle diagrammer og til sidst sammenligne tilfældig søgning side om side med Bayesiansk optimering.

Lad os først oprette en visualisering til tilfældig søgning. Det kan vi gøre ved at ringe visualize_tuning_job() fra amtviz og sender vores første tunerobjekt som et argument:

from amtviz import visualize_tuning_job
visualize_tuning_job(random_tuner, advanced=True, trials_only=True)

Du vil se et par diagrammer, men lad os tage det trin for trin. Det første scatterplot fra outputtet ser ud som følgende og giver os allerede nogle visuelle ledetråde, som vi ikke ville genkende i nogen tabel.

Hver prik repræsenterer udførelsen af ​​et individuelt træningsjob (vores mål valid-f1 på y-aksen) baseret på dets starttidspunkt (x-aksen), produceret af et specifikt sæt hyperparametre. Derfor ser vi på vores models ydeevne, efterhånden som den skrider frem i løbet af tuning-jobbet.

Den stiplede linje fremhæver det hidtil bedste resultat og indikerer forbedring over tid. De to bedste træningsjob opnåede en F1-score på omkring 0.91.

Udover den stiplede linje, der viser de kumulative fremskridt, ser du en tendens i diagrammet?

Sikkert ikke. Og det forventes, fordi vi ser resultaterne af den tilfældige HPO-strategi. Hvert træningsjob blev kørt ved hjælp af et andet, men tilfældigt udvalgt sæt hyperparametre. Hvis vi fortsatte vores tuning-job (eller kørte en anden med samme indstilling), ville vi sandsynligvis se nogle bedre resultater over tid, men vi kan ikke være sikre. Tilfældighed er en vanskelig ting.

De næste diagrammer hjælper dig med at måle hyperparametrenes indflydelse på den samlede ydeevne. Alle hyperparametre er visualiseret, men for korthedens skyld fokuserer vi på to af dem: n-estimators , max-depth.

Vores to bedste træningsjob brugte n-estimators på omkring 20 og 80, og max-depth på henholdsvis 10 og 18. De nøjagtige hyperparameterværdier vises via værktøjstip for hver prik (træningsjob). De er endda dynamisk fremhævet på tværs af alle diagrammer og giver dig en multidimensionel visning! Så du det? Hver hyperparameter plottes mod den objektive metrik som et separat diagram.

Nu, hvilken slags indsigt får vi om n-estimators?

Baseret på det venstre diagram ser det ud til, at meget lave værdiområder (under 10) oftere giver dårlige resultater sammenlignet med højere værdier. Derfor kan højere værdier hjælpe din model til at præstere bedre - interessant.

I modsætning hertil er korrelationen af max-depth hyperparameter til vores objektive metric er ret lav. Vi kan ikke klart fortælle, hvilke værdiintervaller der klarer sig bedre set fra et generelt perspektiv.

Sammenfattende kan tilfældig søgning hjælpe dig med at finde et velfungerende sæt hyperparametre selv på relativt kort tid. Desuden er det ikke forudindtaget i retning af en god løsning, men giver et afbalanceret overblik over søgeområdet. Din ressourceudnyttelse er dog muligvis ikke særlig effektiv. Det fortsætter med at køre træningsjob med hyperparametre i værdiintervaller, der er kendt for at levere dårlige resultater.

Lad os undersøge resultaterne af vores andet tuningjob ved hjælp af Bayesiansk optimering. Vi kan bruge amtviz at visualisere resultaterne på samme måde, som vi hidtil har gjort for den tilfældige søgetuner. Eller endnu bedre, vi kan bruge funktionen til at sammenligne begge tuning-job i et enkelt sæt diagrammer. Ganske praktisk!

visualize_tuning_job([random_tuner, bayesian_tuner], advanced=True, trials_only=True)

Der er flere prikker nu, fordi vi visualiserer resultaterne af alle træningsjob for begge, den tilfældige søgning (orange prikker) og den Bayesianske optimering (blå prikker). På højre side kan du se et tæthedsdiagram, der visualiserer fordelingen af ​​alle F1-scores. Et flertal af træningsjobene opnåede resultater i den øverste del af F1-skalaen (over 0.6) – det er godt!

Hvad er den vigtigste takeaway her? Scatter-plottet viser tydeligt fordelen ved Bayesiansk optimering. Det giver bedre resultater over tid, fordi det kan lære af tidligere kørsler. Det er derfor, vi opnåede væsentligt bedre resultater ved brug af Bayesian sammenlignet med tilfældig (0.967 vs. 0.919) med det samme antal træningsjob.

Der er endnu mere, du kan gøre med amtviz. Lad os bore ind.

Hvis du giver SageMaker AMT instruktionen om at køre et større antal job til tuning, kan det blive rodet at se mange forsøg på én gang. Det er en af ​​grundene til, at vi har gjort disse diagrammer interaktive. Du kan klikke og trække på hvert hyperparameter-spredningsplot for at zoome ind på bestemte værdiområder og forfine din visuelle fortolkning af resultaterne. Alle andre diagrammer opdateres automatisk. Det er ret nyttigt, ikke? Se de næste diagrammer som et eksempel, og prøv det selv i din notesbog!

Som tuning-maksimalist kan du også beslutte, at kørsel af endnu et hyperparameter-tuningjob kan forbedre din models ydeevne yderligere. Men denne gang kan et mere specifikt udvalg af hyperparameterværdier undersøges, fordi du allerede ved (omtrent) hvor du kan forvente bedre resultater. For eksempel kan du vælge at fokusere på værdier mellem 100-200 for n-estimators, som vist i diagrammet. Dette lader AMT fokusere på de mest lovende træningsjob og øger din tuning effektivitet.

For at opsummere det, amtviz giver dig et rigt sæt af visualiseringsfunktioner, der giver dig mulighed for bedre at forstå effekten af ​​din models hyperparametre på ydeevnen og muliggør smartere beslutninger i dine tuning-aktiviteter.

Fortsæt udforskningen af ​​hyperparameterrummet og varmstart HPO-job

Vi har set, at AMT hjælper os med at udforske hyperparametersøgerummet effektivt. Men hvad nu hvis vi har brug for flere runder af tuning for iterativt at forbedre vores resultater? Som nævnt i begyndelsen ønsker vi at etablere en optimeringsfeedback-cyklus - vores "samtale" med modellen. Skal vi starte fra bunden hver gang?

Lad os se nærmere på konceptet med at køre en varm start hyperparameter tuning job. Den starter ikke nye tuningjobs fra bunden, den genbruger det, der er blevet lært i de tidligere HPO-kørsler. Dette hjælper os med at være mere effektive med vores tuning-tid og beregningsressourcer. Vi kan yderligere iterere oven på vores tidligere resultater. For at bruge varme starter skaber vi en WarmStartConfig og specificer warm_start_type as IDENTICAL_DATA_AND_ALGORITHM. Det betyder, at vi ændrer hyperparameterværdierne, men vi ændrer ikke data eller algoritme. Vi beder AMT om at overføre den tidligere viden til vores nye tuningjob.

Ved at henvise til vores tidligere Bayesianske optimerings- og tilfældige søge-tuning-job som parents, vi kan bruge dem begge til den varme start:

warm_start_config = WarmStartConfig(warm_start_type=WarmStartTypes.IDENTICAL_DATA_AND_ALGORITHM, parents=[bayesian_tuner_name, random_tuner_name])
tuner_parameters['warm_start_config'] = warm_start_config

Se de følgende skemaer for at se fordelene ved at bruge varme starter. Disse er genereret af amtviz på samme måde som vi gjorde tidligere, men denne gang har vi tilføjet endnu et tuningjob baseret på en varm start.

I det venstre diagram kan vi observere, at nye tuningjob for det meste ligger i det øverste højre hjørne af den præstationsmetriske graf (se prikker markeret med orange). Den varme start har faktisk genbrugt de tidligere resultater, hvorfor disse datapunkter er i topresultaterne for F1-score. Denne forbedring afspejles også i tæthedsdiagrammet til højre.

Med andre ord vælger AMT automatisk lovende sæt hyperparameterværdier baseret på dets viden fra tidligere forsøg. Dette er vist i næste diagram. For eksempel ville algoritmen teste en lav værdi for n-estimators sjældnere, fordi disse er kendt for at give dårlige F1-scores. Det spilder vi ingen ressourcer på, takket være varme starter.

Ryd op

For at undgå at pådrage sig uønskede omkostninger, når du er færdig med at eksperimentere med HPO, skal du fjerne alle filer i din S3-bøtte med præfikset amt-visualize-demo og også lukke SageMaker Studio-ressourcer.

Kør følgende kode i din notesbog for at fjerne alle S3-filer fra dette indlæg:

!aws s3 rm s3://{BUCKET}/amt-visualize-demo --recursive

Hvis du ønsker at beholde datasættene eller modelartefakterne, kan du ændre præfikset i koden til amt-visualize-demo/data kun at slette data eller amt-visualize-demo/output for kun at slette modelartefakter.

Konklusion

Vi har lært, hvordan kunsten at bygge ML-løsninger involverer at udforske og optimere hyperparametre. Justering af disse knapper og håndtag er en krævende, men alligevel givende proces, der fører til hurtigere træningstider, forbedret modelnøjagtighed og generelt bedre ML-løsninger. SageMaker AMT-funktionaliteten hjælper os med at køre flere tuning-job og starte dem varmt og giver datapunkter til yderligere gennemgang, visuel sammenligning og analyse.

I dette indlæg undersøgte vi HPO-strategier, som vi bruger med SageMaker AMT. Vi startede med tilfældig søgning, en ligetil, men effektiv strategi, hvor hyperparametre udtages tilfældigt fra et søgerum. Dernæst sammenlignede vi resultaterne med Bayesiansk optimering, som bruger probabilistiske modeller til at guide søgningen efter optimale hyperparametre. Efter at vi havde identificeret en passende HPO-strategi og gode hyperparameterværdiintervaller gennem indledende forsøg, viste vi, hvordan man bruger varme starter til at strømline fremtidige HPO-job.

Du kan udforske hyperparametersøgerummet ved at sammenligne kvantitative resultater. Vi har foreslået den visuelle sammenligning side om side og leveret den nødvendige pakke til interaktiv udforskning. Fortæl os i kommentarerne, hvor nyttigt det var for dig på din rejse til justering af hyperparameter!

Om forfatterne

Ümit Yoldas er Senior Solutions Architect med Amazon Web Services. Han arbejder med virksomhedskunder på tværs af industrier i Tyskland. Han er drevet af at oversætte AI-koncepter til løsninger i den virkelige verden. Uden for arbejdet nyder han tid med familien, nyder god mad og dyrker fitness.

Elina Lesyk er en Solutions Architect beliggende i München. Hun fokuserer på virksomhedskunder fra den finansielle sektor. I sin fritid kan du finde Elina, der bygger applikationer med generativ AI på nogle IT-møder, driver en ny idé om at rette op på klimaforandringerne hurtigt eller løbe i skoven for at forberede et halvmaraton med en typisk afvigelse fra den planlagte tidsplan.

Mariano Kamp er en Principal Solutions Architect med Amazon Web Services. Han arbejder med banker og forsikringsselskaber i Tyskland om maskinlæring. I sin fritid nyder Mariano at vandre med sin kone.

• SEO Powered Content & PR Distribution. Bliv forstærket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk dig selv. Adgang her.
• PlatoAiStream. Web3 intelligens. Viden forstærket. Adgang her.
• PlatoESG. Kulstof, CleanTech, Energi, Miljø, Solenergi, Affaldshåndtering. Adgang her.
• PlatoHealth. Bioteknologiske og kliniske forsøgs intelligens. Adgang her.
• Kilde: https://aws.amazon.com/blogs/machine-learning/explore-advanced-techniques-for-hyperparameter-optimization-with-amazon-sagemaker-automatic-model-tuning/