Utforsk avanserte teknikker for hyperparameteroptimalisering med Amazon SageMaker Automatic Model Tuning | Amazon Web Services

Å lage løsninger for maskinlæring med høy ytelse (ML) er avhengig av å utforske og optimalisere treningsparametere, også kjent som hyperparametre. Hyperparametere er knottene og spakene som vi bruker for å justere treningsprosessen, for eksempel læringshastighet, batchstørrelse, regulariseringsstyrke og annet, avhengig av den spesifikke modellen og oppgaven. Å utforske hyperparametere innebærer systematisk å variere verdiene til hver parameter og observere innvirkningen på modellens ytelse. Selv om denne prosessen krever ekstra innsats, er fordelene betydelige. Hyperparameteroptimalisering (HPO) kan føre til raskere treningstider, forbedret modellnøyaktighet og bedre generalisering til nye data.

Vi fortsetter vår ferd fra posten Optimaliser hyperparametre med Amazon SageMaker Automatic Model Tuning. Vi har tidligere utforsket en enkelt jobboptimalisering, visualisert resultatene for SageMaker innebygde algoritme og lært om virkningen av bestemte hyperparameterverdier. I tillegg til å bruke HPO som en engangsoptimalisering på slutten av modellopprettingssyklusen, kan vi også bruke den på tvers av flere trinn på en samtale måte. Hver tuning-jobb hjelper oss å komme nærmere en god ytelse, men i tillegg lærer vi også hvor følsom modellen er for visse hyperparametre og kan bruke denne forståelsen til å informere neste tuning-jobb. Vi kan revidere hyperparametrene og deres verdiområder basert på det vi har lært, og derfor gjøre denne optimaliseringsinnsatsen til en samtale. Og på samme måte som vi som ML-utøvere samler kunnskap over disse løpene, Amazon SageMaker Automatic Model Tuning (AMT) med varme starter kan opprettholde denne kunnskapen som er tilegnet i tidligere tuningjobber for neste tuningjobb også.

I dette innlegget kjører vi flere HPO-jobber med en tilpasset opplæringsalgoritme og forskjellige HPO-strategier som Bayesiansk optimalisering og tilfeldig søk. Vi setter også varme oppstarter i gang og sammenligner forsøkene våre visuelt for å avgrense romutforskningen med hyperparameter.

Avanserte konsepter av SageMaker AMT

I de neste avsnittene ser vi nærmere på hvert av de følgende emnene og viser hvordan SageMaker AMT kan hjelpe deg med å implementere dem i ML-prosjektene dine:

• Bruk tilpasset treningskode og det populære ML-rammeverket Scikit-learn i SageMaker Training
• Definer egendefinerte evalueringsberegninger basert på loggene for evaluering og optimalisering
• Utfør HPO ved å bruke en passende strategi
• Bruk varme starter for å gjøre et enkelt hyperparametersøk til en dialog med modellen vår
• Bruk avanserte visualiseringsteknikker ved å bruke løsningsbiblioteket vårt for å sammenligne to HPO-strategier og finjustere jobbresultater

Enten du bruker de innebygde algoritmene som ble brukt i vårt første innlegg eller din egen treningskode, tilbyr SageMaker AMT en sømløs brukeropplevelse for å optimalisere ML-modeller. Den gir nøkkelfunksjonalitet som lar deg fokusere på ML-problemet mens du automatisk holder oversikt over forsøkene og resultatene. Samtidig administrerer den automatisk den underliggende infrastrukturen for deg.

I dette innlegget går vi bort fra en SageMaker innebygd algoritme og bruker tilpasset kode. Vi bruker en Random Forest fra SkLearn. Men vi holder oss til den samme ML-oppgaven og datasettet som i vår første innlegg, som oppdager håndskrevne sifre. Vi dekker innholdet i Jupyter-notisboken 2_advanced_tuning_with_custom_training_and_visualizing.ipynb og inviterer deg til å påkalle koden side ved side for å lese videre.

La oss dykke dypere og oppdage hvordan vi kan bruke tilpasset opplæringskode, distribuere den og kjøre den, mens vi utforsker hyperparametersøkeområdet for å optimalisere resultatene våre.

Hvordan bygge en ML-modell og utføre hyperparameteroptimalisering

Hvordan ser en typisk prosess for å bygge en ML-løsning ut? Selv om det er mange mulige brukstilfeller og et stort utvalg av ML-oppgaver der ute, foreslår vi følgende mentale modell for en trinnvis tilnærming:

1. Forstå ML-scenarioet ditt og velg en algoritme basert på kravene. Det kan for eksempel være lurt å løse en bildegjenkjenningsoppgave ved hjelp av en overvåket læringsalgoritme. I dette innlegget fortsetter vi å bruke scenariet for håndskreven bildegjenkjenning og det samme datasettet som i vårt første innlegg.
2. Bestem hvilken implementering av algoritmen i SageMaker Training du vil bruke. Det finnes ulike alternativer, inne i SageMaker eller eksterne. I tillegg må du definere hvilken underliggende beregning som passer best for oppgaven din og du ønsker å optimalisere for (som nøyaktighet, F1-score eller ROC). SageMaker støtter fire alternativer avhengig av dine behov og ressurser:
   • Bruk en forhåndstrent modell via Amazon SageMaker JumpStart, som du kan bruke ut av esken eller bare finjustere den.
   • Bruk en av de innebygde algoritmene for trening og tuning, som XGBoost, som vi gjorde i vårt forrige innlegg.
   • Tren og juster en tilpasset modell basert på et av de viktigste rammeverkene som Scikit-learn, TensorFlow eller PyTorch. AWS tilbyr et utvalg forhåndslagde Docker-bilder for dette formålet. For dette innlegget bruker vi dette alternativet, som lar deg eksperimentere raskt ved å kjøre din egen kode på toppen av et forhåndslaget beholderbilde.
   • Ta med ditt eget tilpassede Docker-bilde i tilfelle du vil bruke et rammeverk eller programvare som ellers ikke støttes. Dette alternativet krever mest innsats, men gir også den høyeste grad av fleksibilitet og kontroll.
3. Tren modellen med dataene dine. Avhengig av algoritmeimplementeringen fra forrige trinn, kan dette være så enkelt som å referere til treningsdataene dine og kjøre treningsjobben eller ved i tillegg å oppgi egendefinert kode for trening. I vårt tilfelle bruker vi en egendefinert treningskode i Python basert på Scikit-learn.
4. Bruk hyperparameteroptimalisering (som en "samtale" med ML-modellen din). Etter opplæringen ønsker du vanligvis å optimere ytelsen til modellen din ved å finne den mest lovende kombinasjonen av verdier for algoritmens hyperparametre.

Avhengig av ML-algoritmen og modellstørrelsen, kan det siste trinnet i hyperparameteroptimalisering vise seg å være en større utfordring enn forventet. Følgende spørsmål er typiske for ML-utøvere på dette stadiet og kan høres kjent ut for deg:

• Hva slags hyperparametre har betydning for ML-problemet mitt?
• Hvordan kan jeg effektivt søke i et enormt hyperparameterområde for å finne de beste verdiene?
• Hvordan påvirker kombinasjonen av visse hyperparameterverdier ytelsesberegningen min?
• Kostnadene betyr noe; hvordan kan jeg bruke ressursene mine på en effektiv måte?
• Hva slags tuning-eksperimenter er verdt, og hvordan kan jeg sammenligne dem?

Det er ikke lett å svare på disse spørsmålene, men det er gode nyheter. SageMaker AMT tar de tunge løftene fra deg, og lar deg konsentrere deg om å velge riktig HPO-strategi og verdiområder du ønsker å utforske. I tillegg letter visualiseringsløsningen vår den iterative analyse- og eksperimenteringsprosessen for å effektivt finne hyperparameterverdier med god ytelse.

I de neste avsnittene bygger vi en siffergjenkjenningsmodell fra bunnen av ved hjelp av Scikit-learn og viser alle disse konseptene i aksjon.

Løsningsoversikt

SageMaker tilbyr noen veldig nyttige funksjoner for å trene, evaluere og justere modellen vår. Den dekker all funksjonalitet i en ende-til-ende ML-livssyklus, så vi trenger ikke engang å forlate Jupyter-notebooken vår.

I vårt første innlegg brukte vi SageMaker innebygde algoritme XGBoost. For demonstrasjonsformål bytter vi denne gangen til en Random Forest-klassifiser fordi vi da kan vise hvordan du gir din egen treningskode. Vi valgte å tilby vårt eget Python-skript og bruke Scikit-learn som rammeverk. Nå, hvordan uttrykker vi at vi ønsker å bruke et spesifikt ML-rammeverk? Som vi vil se, bruker SageMaker en annen AWS-tjeneste i bakgrunnen for å hente et forhåndsbygd Docker-containerbilde for trening—Amazon Elastic Container Registry (Amazon ECR).

Vi dekker følgende trinn i detalj, inkludert kodebiter og diagrammer for å koble sammen prikkene. Som nevnt før, hvis du har sjansen, åpne notisboken og kjør kodecellene trinn for trinn for å lage artefakter i AWS-miljøet ditt. Det finnes ingen bedre måte for aktiv læring.

1. Først last og klargjør dataene. Vi bruker Amazon enkel lagringstjeneste (Amazon S3) for å laste opp en fil som inneholder våre håndskrevne sifferdata.
2. Forbered deretter opplæringsskriptet og rammeavhengigheter. Vi gir den tilpassede opplæringskoden i Python, refererer til noen avhengige biblioteker og gjør en testkjøring.
3. For å definere de egendefinerte målberegningene lar SageMaker oss definere et regulært uttrykk for å trekke ut beregningene vi trenger fra beholderloggfilene.
4. Tren modellen ved hjelp av scikit-learn-rammeverket. Ved å referere til et forhåndsbygd beholderbilde, lager vi et tilsvarende Estimator-objekt og sender vårt tilpassede opplæringsskript.
5. AMT lar oss prøve ut ulike HPO-strategier. Vi konsentrerer oss om to av dem for dette innlegget: tilfeldig søk og Bayesiansk søk.
6. Velg mellom SageMaker HPO-strategier.
7. Visualiser, analyser og sammenlign innstillingsresultater. Visualiseringspakken vår lar oss finne ut hvilken strategi som gir bedre resultater og hvilke hyperparameterverdier som gir best ytelse basert på våre beregninger.
8. Fortsett utforskningen av hyperparameterrommet og varmstart HPO-jobber.

AMT tar seg av skalering og administrasjon av den underliggende datainfrastrukturen for å kjøre de forskjellige tuningjobbene på Amazon Elastic Compute Cloud (Amazon EC2) forekomster. På denne måten trenger du ikke å belaste deg selv med å klargjøre forekomster, håndtere eventuelle operativsystem- og maskinvareproblemer eller samle loggfiler på egen hånd. ML-rammebildet hentes fra Amazon ECR, og modellartefaktene, inkludert innstillingsresultater, lagres i Amazon S3. Alle logger og beregninger er samlet inn Amazon CloudWatch for enkel tilgang og ytterligere analyse om nødvendig.

Forutsetninger

Fordi dette er en fortsettelse av en serie, anbefales det, men ikke nødvendigvis, å lese vårt første innlegg om SageMaker AMT og HPO. Bortsett fra det er grunnleggende kjennskap til ML-konsepter og Python-programmering nyttig. Vi anbefaler også å følge med på hvert trinn i medfølgende notatbok fra vårt GitHub-lager mens du leser dette innlegget. Den bærbare kan kjøres uavhengig av den første, men trenger litt kode fra undermapper. Sørg for å klone hele depotet i miljøet ditt som beskrevet i README-filen.

Å eksperimentere med koden og bruke de interaktive visualiseringsalternativene forbedrer læringsopplevelsen din betraktelig. Så sjekk det ut.

Last inn og klargjør dataene

Som et første trinn sørger vi for at den nedlastede sifre data vi trenger for opplæring er tilgjengelig for SageMaker. Amazon S3 lar oss gjøre dette på en trygg og skalerbar måte. Se notisboken for fullstendig kildekode og tilpass den gjerne 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'

De digits.csv filen inneholder funksjonsdata og etiketter. Hvert siffer er representert av pikselverdier i et 8×8-bilde, som vist av følgende bilde for sifferet 4.

Forbered opplæringsskriptet og rammeavhengigheter

Nå som dataene er lagret i S3-bøtten vår, kan vi definere vårt tilpassede treningsskript basert på Scikit lære i Python. SageMaker gir oss muligheten til å bare referere til Python-filen senere for opplæring. Eventuelle avhengigheter som Scikit-learn- eller panda-bibliotekene kan gis på to måter:

• De kan spesifiseres eksplisitt i en requirements.txt fil
• De er forhåndsinstallert i det underliggende ML-beholderbildet, som enten leveres av SageMaker eller spesialbygget

Begge alternativene anses generelt som standardmåter for avhengighetshåndtering, så du er kanskje allerede kjent med det. SageMaker støtter en rekke ML-rammeverk i et klart til bruk administrert miljø. Dette inkluderer mange av de mest populære datavitenskapene og ML-rammeverket som PyTorch, TensorFlow eller Scikit-learn, som i vårt tilfelle. Vi bruker ikke en ekstra requirements.txt fil, men legg gjerne til noen biblioteker for å prøve den ut.

Koden for implementeringen vår inneholder en metode som heter fit(), som oppretter en ny klassifisering for oppgaven for siffergjenkjenning og trener den. I motsetning til vårt første innlegg hvor vi brukte SageMaker innebygde XGBoost-algoritme, bruker vi nå en RandomForestClassifier levert av ML-biblioteket sklearn. Oppfordringen til fit() metoden på klassifiseringsobjektet starter opplæringsprosessen ved å bruke et undersett (80 %) av CSV-dataene våre:

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 manuset i Jupyter-notisboken vår GitHub.

Prøvde du å kjøre skriptet direkte før du spinner opp containerressurser for hele opplæringsprosessen? Dette er en god praksis for raskt å sikre at koden ikke har syntaksfeil, se etter samsvarende dimensjoner for datastrukturene dine og noen andre feil tidlig.

Det er to måter å kjøre koden lokalt på. For det første kan du kjøre den med en gang i notatboken, som også lar deg bruke 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 kjøre togskriptet fra kommandolinjen på samme måte som du kanskje vil bruke det i en container. Dette støtter også innstilling av ulike parametere og overskriving av standardverdier etter behov, for eksempel:

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

Som utdata kan du se de første resultatene for modellens ytelse basert på objektive beregninger presisjon, tilbakekalling og F1-score. For eksempel, pre: 0.970 rec: 0.969 f1: 0.969.

Ikke verst for en så rask trening. Men hvor kom disse tallene fra og hva gjør vi med dem?

Definer egendefinerte målberegninger

Husk at målet vårt er å fullt ut trene og justere modellen vår basert på de objektive beregningene vi anser som relevante for oppgaven vår. Fordi vi bruker et tilpasset opplæringsskript, må vi definere disse beregningene for SageMaker eksplisitt.

Skriptet vårt sender ut beregningene presisjon, gjenkalling og F1-poeng under trening ganske enkelt ved å bruke print funksjon:

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

Standardutgangen fanges opp av SageMaker og sendes til CloudWatch som en loggstrøm. For å hente de metriske verdiene og jobbe med dem senere i SageMaker AMT, må vi gi litt informasjon om hvordan vi analyserer utdataene. Vi kan oppnå dette ved å definere regeluttrykk (for mer informasjon, se Overvåk og analyser opplæringsjobber ved å bruke Amazon CloudWatch-målinger):

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.]+)'}] 

La oss gå gjennom den første metriske definisjonen i den foregående koden sammen. SageMaker vil se etter utdata i loggen som starter med pre: og etterfølges av ett eller flere mellomrom og deretter et tall som vi vil trekke ut, og det er derfor vi bruker den runde parentesen. Hver gang SageMaker finner en slik verdi, gjør den den til en CloudWatch-beregning med navnet valid-precision.

Tren modellen ved å bruke Scikit-learn-rammeverket

Etter at vi har laget treningsskriptet vårt train.py og instruere SageMaker om hvordan man overvåker beregningene i CloudWatch, definerer vi en SageMaker Estimator gjenstand. Den starter treningsjobben og bruker forekomsttypen vi spesifiserer. Men hvordan kan denne instanstypen være forskjellig fra den du kjører en Amazon SageMaker Studio notatbok på, og hvorfor? SageMaker Studio kjører trenings- (og slutnings-) jobbene dine på separate dataforekomster enn den bærbare datamaskinen. Dette lar deg fortsette å jobbe i den bærbare datamaskinen mens jobbene kjører i bakgrunnen.

Parameteren framework_version refererer til Scikit-learn-versjonen vi bruker til treningsjobben vår. Alternativt kan vi bestå image_uri til estimator. Du kan sjekke om ditt favorittrammeverk eller ML-bibliotek er tilgjengelig som en forhåndsbygd SageMaker Docker-bilde og bruk den som den er eller med utvidelser.

Dessuten kan vi kjøre SageMaker-treningsjobber på EC2 Spot-instanser ved å stille inn use_spot_instances til True. De er instanser med ledig kapasitet som kan spar opptil 90 % av kostnadene. Disse tilfellene gir fleksibilitet når treningsjobbene kjø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}
)

Etter at Estimator-objektet er satt opp, starter vi opplæringen ved å ringe fit() funksjon, som gir banen til opplæringsdatasettet på Amazon S3. Vi kan bruke samme metode for å gi validerings- og testdata. Vi setter wait parameter til True slik at vi kan bruke den trente modellen i de påfølgende kodecellene.

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

Definer hyperparametre og kjør innstillingsjobber

Så langt har vi trent modellen med ett sett med hyperparameterverdier. Men var disse verdiene gode? Eller kan vi se etter bedre? La oss bruke HyperparameterTuner klasse å kjøre et systematisk søk ​​over hyperparameterrommet. Hvordan søker vi i denne plassen med tuneren? De nødvendige parameterne er navnet på målberegningen og måltypen som vil lede optimaliseringen. Optimaliseringsstrategien er et annet nøkkelargument for tuneren fordi den definerer søkeområdet ytterligere. Følgende er fire forskjellige strategier å velge mellom:

• Rutenettsøk
• Tilfeldig søk
• Bayesiansk optimalisering (standard)
• Hyperbånd

Vi beskriver disse strategiene videre og utstyrer deg med litt veiledning for å velge en senere i dette innlegget.

Før vi definerer og kjører tunerobjektet vårt, la oss oppsummere forståelsen vår fra et arkitekturperspektiv. Vi dekket den arkitektoniske oversikten over SageMaker AMT i vårt siste innlegg og gjengi et utdrag av det her for enkelhets skyld.

Vi kan velge hvilke hyperparametre vi vil justere eller la være statiske. For dynamiske hyperparametere tilbyr vi hyperparameter_ranges som kan brukes til å optimalisere for justerbare hyperparametre. Fordi vi bruker en Random Forest-klassifiserer, har vi brukt hyperparametrene fra Scikit-learn Random Forest-dokumentasjon.

Vi begrenser også ressurser med maksimalt antall treningsjobber og parallelle treningsjobber tuneren kan bruke. Vi vil se hvordan disse grensene hjelper oss å sammenligne resultatene av ulike strategier med hverandre.

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 } 

Ligner på estimatorens fit funksjon, starter vi en tuning jobb som kaller tunerens fit:

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

Dette er alt vi trenger å gjøre for å la SageMaker drive treningsjobbene (n=50) i bakgrunnen, hver med et annet sett med hyperparametre. Vi utforsker resultatene senere i dette innlegget. Men før det, la oss starte en ny tuning-jobb, denne gangen ved å bruke den Bayesianske optimaliseringsstrategien. Vi vil sammenligne begge strategiene visuelt etter at de er fullført.

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)

Vær oppmerksom på at begge tunerjobbene kan kjøres parallelt fordi SageMaker orkestrerer de nødvendige databehandlingsforekomstene uavhengig av hverandre. Det er ganske nyttig for utøvere som eksperimenterer med forskjellige tilnærminger samtidig, slik vi gjør her.

Velg mellom SageMaker HPO-strategier

Når det gjelder innstillingsstrategier, har du noen få alternativer med SageMaker AMT: rutenettsøk, tilfeldig søk, Bayesiansk optimalisering og Hyperband. Disse strategiene bestemmer hvordan de automatiske innstillingsalgoritmene utforsker de spesifiserte områdene av hyperparametere.

Tilfeldig søk er ganske enkelt. Den velger tilfeldig kombinasjoner av verdier fra de spesifiserte områdene og kan kjøres på en sekvensiell eller parallell måte. Det er som å kaste piler med bind for øynene, i håp om å treffe målet. Vi har startet med denne strategien, men vil resultatene bli bedre med en annen?

Bayesiansk optimalisering tar en annen tilnærming enn tilfeldig søk. Den vurderer historien til tidligere valg og velger verdier som sannsynligvis vil gi de beste resultatene. Hvis du ønsker å lære av tidligere utforskninger, kan du oppnå dette kun ved å kjøre en ny tuning-jobb etter de forrige. Gir mening, ikke sant? På denne måten er Bayesiansk optimalisering avhengig av de tidligere kjøringene. Men ser du hvilken HPO-strategi som tillater høyere parallellisering?

Hyperbånd er en interessant en! Den bruker en multifidelity-strategi, som betyr at den dynamisk allokerer ressurser til de mest lovende treningsjobbene og stopper de som ikke presterer. Derfor er Hyperband beregningseffektiv med ressurser, og lærer av tidligere treningsjobber. Etter å ha stoppet konfigurasjonene som ikke presterer, starter en ny konfigurasjon, og verdiene velges tilfeldig.

Avhengig av dine behov og typen av modellen din, kan du velge mellom tilfeldig søk, Bayesiansk optimalisering eller Hyperband som tuningstrategi. Hver har sin egen tilnærming og fordeler, så det er viktig å vurdere hvilken som fungerer best for din ML-utforskning. Den gode nyheten for ML-utøvere er at du kan velge den beste HPO-strategien ved å visuelt sammenligne virkningen av hver utprøving på den objektive beregningen. I neste avsnitt ser vi hvordan du visuelt identifiserer virkningen av ulike strategier.

Visualiser, analyser og sammenlign innstillingsresultater

Når tuningjobbene våre er fullførte, blir det spennende. Hvilke resultater gir de? Hva slags løft kan du forvente på beregningen vår sammenlignet med basismodellen din? Hva er de beste hyperparametrene for vårt bruksområde?

En rask og enkel måte å se HPO-resultatene på er ved å besøke SageMaker-konsollen. Under Hyperparameter tuning jobber, kan vi se (per innstillingsjobb) kombinasjonen av hyperparameterverdier som har blitt testet og levert den beste ytelsen målt av vår objektive beregning (valid-f1).

Er det alt du trenger? Som ML-utøver er du kanskje ikke bare interessert i disse verdiene, men du vil absolutt lære mer om den indre funksjonen til modellen din for å utforske dens fulle potensiale og styrke intuisjonen din med empiriske tilbakemeldinger.

Et godt visualiseringsverktøy kan i stor grad hjelpe deg med å forstå forbedringen av HPO over tid og få empirisk tilbakemelding på designbeslutninger for ML-modellen din. Den viser innvirkningen av hver enkelt hyperparameter på målberegningen din og gir veiledning for å optimalisere tuningresultatene ytterligere.

Vi bruker amtviz tilpasset visualiseringspakke for å visualisere og analysere innstillingsjobber. Den er enkel å bruke og har nyttige funksjoner. Vi demonstrerer fordelen ved å tolke noen individuelle diagrammer, og til slutt sammenligne tilfeldige søk side om side med Bayesiansk optimalisering.

La oss først lage en visualisering for tilfeldig søk. Vi kan gjøre dette ved å ringe visualize_tuning_job() fra amtviz og passerer vårt 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 la oss ta det steg for steg. Det første spredningsplottet fra utdataene ser ut som følgende og gir oss allerede noen visuelle ledetråder vi ikke ville gjenkjenne i noen tabell.

Hver prikk representerer ytelsen til en individuell treningsjobb (målet vårt valid-f1 på y-aksen) basert på starttiden (x-aksen), produsert av et spesifikt sett med hyperparametre. Derfor ser vi på ytelsen til modellen vår etter hvert som den utvikler seg over varigheten av tuningjobben.

Den stiplede linjen fremhever det beste resultatet så langt og indikerer forbedring over tid. De to beste treningsjobbene oppnådde en F1-score på rundt 0.91.

I tillegg til den stiplede linjen som viser den kumulative fremgangen, ser du en trend i diagrammet?

Sannsynligvis ikke. Og dette er forventet, fordi vi ser på resultatene av den tilfeldige HPO-strategien. Hver treningsjobb ble kjørt ved hjelp av et annet, men tilfeldig valgt sett med hyperparametre. Hvis vi fortsatte tuning-jobben (eller kjørte en annen med samme innstilling), ville vi sannsynligvis se noen bedre resultater over tid, men vi kan ikke være sikre. Tilfeldighet er en vanskelig ting.

De neste diagrammene hjelper deg med å måle innflytelsen av hyperparametre på den generelle ytelsen. Alle hyperparametre er visualisert, men for korthets skyld fokuserer vi på to av dem: n-estimators og max-depth.

Våre to beste treningsjobber brukte n-estimators på rundt 20 og 80, og max-depth på henholdsvis rundt 10 og 18. De nøyaktige hyperparameterverdiene vises via verktøytips for hver prikk (treningsjobb). De er til og med dynamisk fremhevet på tvers av alle diagrammer og gir deg en flerdimensjonal visning! Så du det? Hver hyperparameter er plottet mot den objektive beregningen, som et eget diagram.

Nå, hva slags innsikt får vi om n-estimators?

Basert på det venstre diagrammet ser det ut til at svært lave verdiområder (under 10) oftere gir dårlige resultater sammenlignet med høyere verdier. Derfor kan høyere verdier hjelpe modellen din til å prestere bedre – interessant.

I kontrast er korrelasjonen av max-depth hyperparameter til vår objektive beregning er ganske lav. Vi kan ikke tydelig si hvilke verdiområder som gir bedre resultater fra et generelt perspektiv.

Oppsummert kan tilfeldig søk hjelpe deg med å finne et sett med hyperparametere med god ytelse selv på relativt kort tid. Det er heller ikke partisk mot en god løsning, men gir et balansert syn på søkeområdet. Ressursutnyttelsen din er kanskje ikke særlig effektiv. Den fortsetter å kjøre treningsjobber med hyperparametere i verdiområder som er kjent for å gi dårlige resultater.

La oss undersøke resultatene av vår andre tuning jobb ved hjelp av Bayesiansk optimalisering. Vi kan bruke amtviz å visualisere resultatene på samme måte som vi gjorde så langt for den tilfeldige søketuneren. Eller enda bedre, vi kan bruke funksjonen til å sammenligne begge innstillingsjobbene i et enkelt sett med diagrammer. Ganske hendig!

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

Det er flere prikker nå fordi vi visualiserer resultatene av alle treningsjobber for begge, det tilfeldige søket (oransje prikker) og Bayesiansk optimalisering (blå prikker). På høyre side kan du se et tetthetsdiagram som visualiserer fordelingen av alle F1-poeng. Et flertall av treningsjobbene oppnådde resultater i den øvre delen av F1-skalaen (over 0.6) – det er bra!

Hva er nøkkelen her? Spredningsplottet viser tydelig fordelen med Bayesiansk optimalisering. Den gir bedre resultater over tid fordi den kan lære av tidligere kjøringer. Det er derfor vi oppnådde betydelig bedre resultater ved bruk av Bayesian sammenlignet med tilfeldig (0.967 vs. 0.919) med samme antall treningsjobber.

Det er enda mer du kan gjøre med amtviz. La oss bore inn.

Hvis du gir SageMaker AMT instruksjonen om å kjøre et større antall jobber for tuning, kan det bli rotete å se mange forsøk samtidig. Det er en av grunnene til at vi gjorde disse diagrammene interaktive. Du kan klikke og dra på hvert hyperparameterspredningsplott for å zoome inn til bestemte verdiområder og avgrense den visuelle tolkningen av resultatene. Alle andre diagrammer oppdateres automatisk. Det er ganske nyttig, ikke sant? Se de neste diagrammene som et eksempel og prøv det selv i notatboken din!

Som innstillingsmaksimalist kan du også bestemme at å kjøre en annen hyperparameterinnstillingsjobb kan forbedre modellens ytelse ytterligere. Men denne gangen kan et mer spesifikt utvalg av hyperparameterverdier utforskes fordi du allerede vet (omtrent) hvor du kan forvente bedre resultater. Du kan for eksempel velge å fokusere på verdier mellom 100–200 for n-estimators, som vist i diagrammet. Dette lar AMT fokusere på de mest lovende treningsjobbene og øker tuningeffektiviteten din.

For å oppsummere, amtviz gir deg et rikt sett med visualiseringsfunksjoner som lar deg bedre forstå effekten av modellens hyperparametre på ytelsen og muliggjør smartere beslutninger i tuning-aktivitetene dine.

Fortsett utforskningen av hyperparameterrommet og varmstart HPO-jobber

Vi har sett at AMT hjelper oss å utforske hyperparametersøkerommet effektivt. Men hva om vi trenger flere runder med tuning for å iterativt forbedre resultatene våre? Som nevnt innledningsvis ønsker vi å etablere en optimaliseringstilbakemeldingssyklus - vår "samtale" med modellen. Trenger vi å starte fra bunnen av hver gang?

La oss se nærmere på konseptet med å kjøre en varmstart hyperparameter tuning jobb. Den starter ikke nye tuningjobber fra bunnen av, den gjenbruker det som har blitt lært i de tidligere HPO-kjøringene. Dette hjelper oss å være mer effektive med tuningtiden og beregningsressursene. Vi kan videre iterere på toppen av våre tidligere resultater. For å bruke varme starter lager vi en WarmStartConfig og spesifiser warm_start_type as IDENTICAL_DATA_AND_ALGORITHM. Dette betyr at vi endrer hyperparameterverdiene, men vi endrer ikke dataene eller algoritmen. Vi ber AMT overføre forkunnskapen til vår nye tuning-jobb.

Ved å referere til våre tidligere Bayesianske optimaliserings- og tilfeldige søk tuning jobber som parents, vi kan bruke dem begge til den varme starten:

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

For å se fordelene med å bruke varme starter, se følgende diagrammer. Disse er generert av amtviz på lignende måte som vi gjorde tidligere, men denne gangen har vi lagt til en ny tuningjobb basert på en varm start.

I det venstre diagrammet kan vi observere at nye tuning jobber for det meste ligger i øvre høyre hjørne av ytelsesberegningsgrafen (se prikker merket med oransje). Den varme starten har faktisk gjenbrukt de tidligere resultatene, og det er grunnen til at disse datapunktene er i toppresultatene for F1-poengsum. Denne forbedringen gjenspeiles også i tetthetsdiagrammet til høyre.

Med andre ord velger AMT automatisk lovende sett med hyperparameterverdier basert på kunnskapen fra tidligere forsøk. Dette er vist i neste diagram. For eksempel vil algoritmen teste en lav verdi for n-estimators sjeldnere fordi disse er kjent for å gi dårlige F1-score. Vi kaster ikke bort noen ressurser på det, takket være varme starter.

Rydd opp

For å unngå å pådra deg uønskede kostnader når du er ferdig med å eksperimentere med HPO, må du fjerne alle filene i S3-bøtten din med prefikset amt-visualize-demo og også slå av SageMaker Studio-ressurser.

Kjør følgende kode i notatboken for å fjerne alle S3-filer fra dette innlegget:

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

Hvis du ønsker å beholde datasettene eller modellartefaktene, kan du endre prefikset i koden til amt-visualize-demo/data å bare slette dataene eller amt-visualize-demo/output å bare slette modellartefakter.

konklusjonen

Vi har lært hvordan kunsten å bygge ML-løsninger innebærer å utforske og optimalisere hyperparametre. Å justere disse knottene og spakene er en krevende, men likevel givende prosess som fører til raskere treningstider, forbedret modellnøyaktighet og generelt bedre ML-løsninger. SageMaker AMT-funksjonaliteten hjelper oss med å kjøre flere tuningjobber og starte dem varm, og gir datapunkter for videre gjennomgang, visuell sammenligning og analyse.

I dette innlegget så vi på HPO-strategier som vi bruker med SageMaker AMT. Vi startet med tilfeldig søk, en enkel, men effektiv strategi der hyperparametre er tilfeldig samplet fra et søkerom. Deretter sammenlignet vi resultatene med Bayesiansk optimalisering, som bruker sannsynlighetsmodeller for å veilede søket etter optimale hyperparametre. Etter at vi identifiserte en passende HPO-strategi og gode hyperparameterverdiområder gjennom innledende forsøk, viste vi hvordan man kan bruke varmestarter for å effektivisere fremtidige HPO-jobber.

Du kan utforske hyperparametersøkeområdet ved å sammenligne kvantitative resultater. Vi har foreslått den visuelle sammenligningen side om side og gitt den nødvendige pakken for interaktiv utforskning. Gi oss beskjed i kommentarfeltet hvor nyttig det var for deg på reisen din med hyperparameterinnstilling!

Om forfatterne

Ümit Yoldas er en senior løsningsarkitekt med Amazon Web Services. Han jobber med bedriftskunder på tvers av bransjer i Tyskland. Han er drevet av å oversette AI-konsepter til virkelige løsninger. Utenom jobben nyter han tid med familien, nyter god mat og driver trening.

Elina Lesyk er en løsningsarkitekt lokalisert i München. Hun fokuserer på bedriftskunder fra finansnæringen. På fritiden kan du finne Elina som bygger applikasjoner med generativ AI på enkelte IT-treff, driver en ny idé om å fikse klimaendringer raskt, eller løper i skogen for å forberede seg til et halvmaraton med et typisk avvik fra den planlagte timeplanen.

Mariano Kamp er en hovedløsningsarkitekt med Amazon Web Services. Han jobber med banker og forsikringsselskaper i Tyskland om maskinlæring. På fritiden liker Mariano å gå tur med kona.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://aws.amazon.com/blogs/machine-learning/explore-advanced-techniques-for-hyperparameter-optimization-with-amazon-sagemaker-automatic-model-tuning/