Organiser din maskinlæringsreise med Amazon SageMaker Experiments og Amazon SageMaker Pipelines

Prosessen med å bygge en maskinlæringsmodell (ML) er iterativ til du finner kandidatmodellen som gir gode resultater og er klar til å bli distribuert. Når dataforskere itererer gjennom denne prosessen, trenger de en pålitelig metode for enkelt å spore eksperimenter for å forstå hvordan hver modellversjon ble bygget og hvordan den utførte.

Amazon SageMaker lar teamene dra nytte av et bredt spekter av funksjoner for raskt å forberede, bygge, trene, distribuere og overvåke ML-modeller. Amazon SageMaker-rørledninger gir en repeterbar prosess for iterasjon gjennom modellbyggingsaktiviteter, og er integrert med Amazon SageMaker-eksperimenter. Som standard er hver SageMaker-pipeline assosiert med et eksperiment, og hver kjøring av den pipelinen spores som en prøveversjon i det eksperimentet. Deretter blir iterasjonene dine automatisk sporet uten noen ekstra trinn.

I dette innlegget ser vi nærmere på motivasjonen bak å ha en automatisert prosess for å spore eksperimenter med eksperimenter og de opprinnelige egenskapene innebygd i Pipelines.

Hvorfor er det viktig å holde eksperimentene organisert?

La oss ta et skritt tilbake et øyeblikk og prøve å forstå hvorfor det er viktig å ha eksperimenter organisert for maskinlæring. Når dataforskere nærmer seg et nytt ML-problem, må de svare på mange forskjellige spørsmål, fra datatilgjengelighet til hvordan de vil måle modellytelse.

I starten er prosessen full av usikkerhet og er svært iterativ. Som et resultat kan denne eksperimenteringsfasen produsere flere modeller, hver laget fra sine egne innganger (datasett, treningsskript og hyperparametre) og produsere sine egne utganger (modellartefakter og evalueringsverdier). Utfordringen er da å holde styr på alle disse inngangene og utgangene for hver iterasjon.

Dataforskere trener vanligvis mange forskjellige modellversjoner til de finner kombinasjonen av datatransformasjon, algoritme og hyperparametre som resulterer i den best ytelse versjonen av en modell. Hver av disse unike kombinasjonene er et enkelt eksperiment. Med en sporbar registrering av inngangene, algoritmene og hyperparametrene som ble brukt av den prøven, kan datavitenskapsteamet finne det enkelt å reprodusere trinnene deres.

Å ha en automatisert prosess på plass for å spore eksperimenter forbedrer muligheten til å reprodusere samt distribuere spesifikke modellversjoner som gir gode resultater. Pipelines-integreringen med Experiments gjør det enkelt å automatisk spore og administrere eksperimenter på tvers av pipeline-kjøringer.

Fordeler med SageMaker-eksperimenter

SageMaker Experiments lar dataforskere organisere, spore, sammenligne og evaluere treningsiterasjonene deres.

La oss starte først med en oversikt over hva du kan gjøre med eksperimenter:

• Organiser eksperimenter – Eksperimenter strukturerer eksperimentering med en enhet på toppnivå kalt en eksperiment som inneholder et sett med forsøk. Hver prøveversjon inneholder et sett med trinn kalt prøvekomponenter. Hver prøvekomponent er en kombinasjon av datasett, algoritmer og parametere. Du kan forestille deg eksperimenter som mappen på øverste nivå for å organisere hypotesene dine, forsøkene dine som undermappene for hver gruppetestkjøring, og prøvekomponentene dine som filer for hver forekomst av en testkjøring.
• Spor eksperimenter – Eksperimenter lar dataforskere spore eksperimenter. Det gir muligheten til å automatisk tildele SageMaker-jobber til en prøveversjon via enkle konfigurasjoner og via sporings-SDK-ene.
• Sammenlign og evaluer eksperimenter – Integrasjonen av Eksperimenter med Amazon SageMaker Studio gjør det enkelt å produsere datavisualiseringer og sammenligne ulike forsøk. Du kan også få tilgang til prøvedataene via Python SDK for å generere din egen visualisering ved å bruke dine foretrukne plottebiblioteker.

For å lære mer om Experiments API-er og SDK-er, anbefaler vi følgende dokumentasjon: OpprettEksperiment og Amazon SageMaker Experiments Python SDK.

Hvis du ønsker å dykke dypere, anbefaler vi å se nærmere på amazon-sagemaker-examples/sagemaker-experiments GitHub-depot for ytterligere eksempler.

Integrasjon mellom rørledninger og eksperimenter

Modellbyggingspipelines som er en del av Pipelines er spesialbygd for ML og lar deg orkestrere modellbyggingsoppgavene dine ved hjelp av et pipelineverktøy som inkluderer innebygde integrasjoner med andre SageMaker-funksjoner samt fleksibiliteten til å utvide pipelinen med trinn som kjøres utenfor SageMaker . Hvert trinn definerer en handling som rørledningen utfører. Avhengighetene mellom trinn er definert av en direkte asyklisk graf (DAG) bygget ved hjelp av Pipelines Python SDK. Du kan bygge en SageMaker-pipeline programmatisk via samme SDK. Etter at en pipeline er distribuert, kan du eventuelt visualisere arbeidsflyten i Studio.

Rørledninger integreres automatisk med eksperimenter ved automatisk å opprette et eksperiment og prøveversjon for hver kjøring. Rørledninger oppretter automatisk et eksperiment og en prøveperiode for hver kjøring av rørledningen før du kjører trinnene, med mindre en eller begge disse inngangene er spesifisert. Mens du kjører rørledningens SageMaker-jobb, knytter rørledningen prøven til eksperimentet, og knytter til prøven hver prøvekomponent som opprettes av jobben. Ved å spesifisere ditt eget eksperiment eller prøveversjon programmatisk kan du finjustere hvordan du organiserer eksperimentene dine.

Arbeidsflyten vi presenterer i dette eksemplet består av en rekke trinn: et forbehandlingstrinn for å dele inndatasettet vårt i tog-, test- og valideringsdatasett; et justeringstrinn for å justere hyperparametrene våre og starte treningsjobber for å trene en modell ved hjelp av XGBoost innebygd algoritme; og til slutt et modelltrinn for å lage en SageMaker-modell fra den best trente modellartefakten. Pipelines tilbyr også flere innfødt støttede trinntyper utenfor det som er omtalt i dette innlegget. Vi illustrerer også hvordan du kan spore arbeidsflyten din for pipeline og generere beregninger og sammenligningsdiagrammer. Videre viser vi hvordan du knytter den nye utprøvingen generert til et eksisterende eksperiment som kan ha blitt opprettet før rørledningen ble definert.

SageMaker Pipelines-kode

Du kan se gjennom og laste ned notatboken fra GitHub repository knyttet til dette innlegget. Vi ser på den Pipelines-spesifikke koden for å forstå den bedre.

Pipelines lar deg sende parametere under kjøring. Her definerer vi behandlings- og treningsforekomsttyper og tellinger ved kjøretid med forhåndsinnstilte standarder:

base_job_prefix = "pipeline-experiment-sample"
model_package_group_name = "pipeline-experiment-model-package"

processing_instance_count = ParameterInteger(
  name="ProcessingInstanceCount", default_value=1
)

training_instance_count = ParameterInteger(
  name="TrainingInstanceCount", default_value=1
)

processing_instance_type = ParameterString(
  name="ProcessingInstanceType", default_value="ml.m5.xlarge"
)
training_instance_type = ParameterString(
  name="TrainingInstanceType", default_value="ml.m5.xlarge"
)

Deretter setter vi opp et behandlingsskript som laster ned og deler inndatadatasettet i tog-, test- og valideringsdeler. Vi bruker SKLearnProcessor for å kjøre dette forbehandlingstrinnet. For å gjøre det, definerer vi et prosessorobjekt med forekomsttypen og antallet som trengs for å kjøre behandlingsjobben.

Pipelines lar oss oppnå dataversjon på en programmatisk måte ved å bruke utførelsesspesifikke variabler som ExecutionVariables.PIPELINE_EXECUTION_ID, som er den unike ID-en til en rørledningskjøring. Vi kan for eksempel lage en unik nøkkel for å lagre utdatasettene i Amazon enkel lagringstjeneste (Amazon S3) som knytter dem til en bestemt rørledning. For fullstendig liste over variabler, se Utførelsesvariabler.

framework_version = "0.23-1"

sklearn_processor = SKLearnProcessor(
    framework_version=framework_version,
    instance_type=processing_instance_type,
    instance_count=processing_instance_count,
    base_job_name="sklearn-ca-housing",
    role=role,
)

process_step = ProcessingStep(
    name="ca-housing-preprocessing",
    processor=sklearn_processor,
    outputs=[
        ProcessingOutput(
            output_name="train",
            source="/opt/ml/processing/train",
            destination=Join(
                on="/",
                values=[
                    "s3://{}".format(bucket),
                    prefix,
                    ExecutionVariables.PIPELINE_EXECUTION_ID,
                    "train",
                ],
            ),
        ),
        ProcessingOutput(
            output_name="validation",
            source="/opt/ml/processing/validation",
            destination=Join(
                on="/",
                values=[
                    "s3://{}".format(bucket),
                    prefix,
                    ExecutionVariables.PIPELINE_EXECUTION_ID,
                    "validation",
                ],
            )
        ),
        ProcessingOutput(
            output_name="test",
            source="/opt/ml/processing/test",
            destination=Join(
                on="/",
                values=[
                    "s3://{}".format(bucket),
                    prefix,
                    ExecutionVariables.PIPELINE_EXECUTION_ID,
                    "test",
                ],
            )
        ),
    ],
    code="california-housing-preprocessing.py",
)

Deretter går vi videre til å lage et estimatorobjekt for å trene en XGBoost-modell. Vi setter noen statiske hyperparametre som vanligvis brukes med XGBoost:

model_path = f"s3://{default_bucket}/{base_job_prefix}/ca-housing-experiment-pipeline"

image_uri = sagemaker.image_uris.retrieve(
    framework="xgboost",
    region=region,
    version="1.2-2",
    py_version="py3",
    instance_type=training_instance_type,
)

xgb_train = Estimator(
    image_uri=image_uri,
    instance_type=training_instance_type,
    instance_count=training_instance_count,
    output_path=model_path,
    base_job_name=f"{base_job_prefix}/ca-housing-train",
    sagemaker_session=sagemaker_session,
    role=role,
)

xgb_train.set_hyperparameters(
    eval_metric="rmse",
    objective="reg:squarederror",  # Define the object metric for the training job
    num_round=50,
    max_depth=5,
    eta=0.2,
    gamma=4,
    min_child_weight=6,
    subsample=0.7
)

Vi gjør hyperparameterjustering av modellene vi lager ved å bruke en ContinuousParameter rekkevidde for lambda. Hvis du velger én beregning som objektiv beregning, forteller tuneren (forekomsten som kjører tuningjobbene for hyperparametere) at du vil evaluere treningsjobben basert på denne spesifikke beregningen. Tuneren returnerer den beste kombinasjonen basert på den beste verdien for denne objektive metrikken, som betyr den beste kombinasjonen som minimerer den beste RMSE-feilen.

objective_metric_name = "validation:rmse"

hyperparameter_ranges = {
    "lambda": ContinuousParameter(0.01, 10, scaling_type="Logarithmic")
}

tuner = HyperparameterTuner(estimator,
                            objective_metric_name,
                            hyperparameter_ranges,
                            objective_type=objective_type,
                            strategy="Bayesian",
                            max_jobs=10,
                            max_parallel_jobs=3)

tune_step = TuningStep(
    name="HPTuning",
    tuner=tuner_log,
    inputs={
        "train": TrainingInput(
            s3_data=process_step.properties.ProcessingOutputConfig.Outputs[
                "train"
            ].S3Output.S3Uri,
            content_type="text/csv",
        ),
        "validation": TrainingInput(
            s3_data=process_step.properties.ProcessingOutputConfig.Outputs[
                "validation"
            ].S3Output.S3Uri,
            content_type="text/csv",
        ),
    } 
)

Justeringstrinnet kjører flere forsøk med mål om å bestemme den beste modellen blant parameterområdene som er testet. Med metoden get_top_model_s3_uri, rangerer vi de 50 beste versjonene av modellartefakten S3 URI og trekker bare ut versjonen med best ytelse (vi spesifiserer k=0 for det beste) for å lage en SageMaker-modell.

model_bucket_key = f"{default_bucket}/{base_job_prefix}/ca-housing-experiment-pipeline"
model_candidate = Model(
    image_uri=image_uri,
    model_data=tune_step.get_top_model_s3_uri(top_k=0, s3_bucket=model_bucket_key),
    sagemaker_session=sagemaker_session,
    role=role,
    predictor_cls=XGBoostPredictor,
)

create_model_step = CreateModelStep(
    name="CreateTopModel",
    model=model_candidate,
    inputs=sagemaker.inputs.CreateModelInput(instance_type="ml.m4.large"),
)

Når pipelinen kjører, oppretter den prøvekomponenter for hver hyperparameterjusteringsjobb og hver SageMaker-jobb opprettet av pipeline-trinnene.

Du kan videre konfigurere integreringen av rørledninger med eksperimenter ved å opprette en PipelineExperimentConfig objektet og send det til rørledningsobjektet. De to parameterne definerer navnet på eksperimentet som skal opprettes, og prøven som vil referere til hele rørledningen.

Hvis du ønsker å knytte en pipeline-kjøring til et eksisterende eksperiment, kan du gi dens navn, og Pipelines vil knytte den nye prøveversjonen til den. Du kan forhindre opprettelsen av et eksperiment og prøveversjon for en pipeline som kjøres ved å angi pipeline_experiment_config til None.

#Pipeline experiment config
ca_housing_experiment_config = PipelineExperimentConfig(
    experiment_name,
    Join(
        on="-",
        values=[
            "pipeline-execution",
            ExecutionVariables.PIPELINE_EXECUTION_ID
        ],
    )
)

Vi videreformidler instanstyper og teller som parametere, og lenker de foregående trinnene i rekkefølge som følger. Rørledningsarbeidsflyten er implisitt definert ved at utgangene til et trinn er inngangene til et annet trinn.

pipeline_name = f"CAHousingExperimentsPipeline"

pipeline = Pipeline(
    name=pipeline_name,
    pipeline_experiment_config=ca_housing_experiment_config,
    parameters=[
        processing_instance_count,
        processing_instance_type,
        training_instance_count,
        training_instance_type
    ],
    steps=[process_step,tune_step,create_model_step],
)

Den fullverdige rørledningen er nå opprettet og klar til bruk. Vi legger til en utførelsesrolle i rørledningen og starter den. Herfra kan vi gå til SageMaker Studio Pipelines-konsollen og visuelt spore hvert trinn. Du kan også få tilgang til de koblede loggene fra konsollen for å feilsøke en pipeline.

pipeline.upsert(role_arn=sagemaker.get_execution_role())
execution = pipeline.start()

Det foregående skjermbildet viser i grønt en rørledning som ble kjørt. Vi henter beregningene for en prøveperiode fra en kjøring av rørledningen med følgende kode:

# SM Pipeline injects the Execution ID into trial component names
execution_id = execution.describe()['PipelineExecutionArn'].split('/')[-1]
source_arn_filter = Filter(
    name="TrialComponentName", operator=Operator.CONTAINS, value=execution_id
)

source_type_filter = Filter(
    name="Source.SourceType", operator=Operator.EQUALS, value="SageMakerTrainingJob"
)

search_expression = SearchExpression(
    filters=[source_arn_filter, source_type_filter]
)

trial_component_analytics = ExperimentAnalytics(
    sagemaker_session=sagemaker_session,
    experiment_name=experiment_name,
    search_expression=search_expression.to_boto()
)

analytic_table = trial_component_analytics.dataframe()
analytic_table.head()

Sammenlign beregningene for hver prøvekomponent

Du kan plotte resultatene av hyperparameterinnstilling i Studio eller via andre Python-plottingbiblioteker. Vi viser begge måter å gjøre dette på.

Utforsk trenings- og evalueringsberegningene i Studio

Studio tilbyr et interaktivt brukergrensesnitt der du kan generere interaktive plott. Trinnene er som følger:

1. Velg Eksperimenter og forsøk fra SageMaker-ressurser ikonet på venstre sidefelt.
2. Velg eksperimentet ditt for å åpne det.
3. Velg (høyreklikk) prøveversjonen av interesse.
4. Velg Åpne i prøvekomponentliste.
5. Press Skift for å velge prøvekomponentene som representerer treningsjobbene.
6. Velg Legg til diagram.
7. Velg Nytt diagram og tilpass den for å plotte de innsamlede beregningene du vil analysere. For vår brukssituasjon, velg følgende:
   1. Til Data-typeå velge Sammendragsstatistikk.
   2. Til Diagramtypeå velge Spredningsplott.
   3. Til X-akse, velg lambda.
   4. Til Y-aksen, velg validation:rmse_last.

Det nye diagrammet vises nederst i vinduet, merket som '8'.

Du kan inkludere flere eller færre opplæringsjobber ved å trykke Skift og velge øyeikonet for en mer interaktiv opplevelse.

Analytics med SageMaker-eksperimenter

Når pipeline-kjøringen er fullført, kan vi raskt visualisere hvordan ulike varianter av modellen er sammenlignet med hensyn til beregningene som samles inn under trening. Tidligere eksporterte vi alle prøveverdier til en pandaer DataFrame ved hjelp av ExperimentAnalytics. Vi kan reprodusere plottet oppnådd i Studio ved å bruke Matplotlib-biblioteket.

analytic_table.plot.scatter("lambda", "validation:rmse - Last", grid=True)

konklusjonen

Den opprinnelige integrasjonen mellom SageMaker Pipelines og SageMaker Experiments lar dataforskere automatisk organisere, spore og visualisere eksperimenter under modellutviklingsaktiviteter. Du kan lage eksperimenter for å organisere alt modellutviklingsarbeidet ditt, for eksempel følgende:

• En forretningsbrukssak du tar opp, for eksempel å lage et eksperiment for å forutsi kundefragang
• Et eksperiment eid av datavitenskapsteamet angående markedsanalyse, for eksempel
• Et spesifikt datavitenskap og ML-prosjekt

I dette innlegget dykket vi inn i Pipelines for å vise hvordan du kan bruke det sammen med eksperimenter for å organisere en helautomatisert ende-til-ende arbeidsflyt.

Som et neste trinn kan du bruke disse tre SageMaker-funksjonene – Studio, Eksperimenter og Pipelines – for ditt neste ML-prosjekt.

Foreslåtte avlesninger

Om forfatterne

Paolo Di Francesco er løsningsarkitekt i AWS. Han har erfaring innen telekommunikasjon og programvareutvikling. Han er lidenskapelig opptatt av maskinlæring og fokuserer for tiden på å bruke sin erfaring til å hjelpe kundene med å nå sine mål på AWS, spesielt i diskusjoner rundt MLOps. Utenom jobben liker han å spille fotball og lese.

Mario Bourgoin er Senior Partner Solutions Architect for AWS, en AI/ML-spesialist, og den globale tech lead for MLOps. Han jobber med bedriftskunder og partnere som distribuerer AI-løsninger i skyen. Han har mer enn 30 års erfaring med maskinlæring og AI ved oppstart og i bedrifter, og starter med å lage et av de første kommersielle maskinlæringssystemene for big data. Mario bruker fritiden sin på å leke med sine tre belgiske Tervurens, lage middag til familien og lære om matematikk og kosmologi.

Ganapathi Krishnamoorthi er senior ML Solutions Architect hos AWS. Ganapathi gir foreskrivende veiledning til oppstarts- og bedriftskunder og hjelper dem med å designe og distribuere skyapplikasjoner i stor skala. Han er spesialisert i maskinlæring og er fokusert på å hjelpe kunder med å utnytte AI/ML for deres forretningsresultater. Når han ikke er på jobb, liker han å utforske utendørs og høre på musikk.

Valerie Sounthakith er en løsningsarkitekt for AWS, jobber i spillindustrien og med partnere som distribuerer AI-løsninger. Hun har som mål å bygge sin karriere rundt Computer Vision. På fritiden bruker Valerie den til å reise, oppdage nye matsteder og endre interiøret i huset.