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

Processen med at bygge en maskinlæringsmodel (ML) er iterativ, indtil du finder den kandidatmodel, der klarer sig godt og er klar til at blive implementeret. Efterhånden som dataforskere gentager denne proces, har de brug for en pålidelig metode til nemt at spore eksperimenter for at forstå, hvordan hver modelversion blev bygget, og hvordan den fungerede.

Amazon SageMaker giver teams mulighed for at drage fordel af en bred vifte af funktioner til hurtigt at forberede, bygge, træne, implementere og overvåge ML-modeller. Amazon SageMaker Pipelines giver en gentagelig proces til iteration gennem modelbygningsaktiviteter og er integreret med Amazon SageMaker-eksperimenter. Som standard er hver SageMaker-pipeline knyttet til et eksperiment, og hver kørsel af den pipeline spores som en prøveversion i det pågældende eksperiment. Derefter spores dine iterationer automatisk uden yderligere trin.

I dette indlæg ser vi nærmere på motivationen bag at have en automatiseret proces til at spore eksperimenter med eksperimenter og de indbyggede muligheder indbygget i Pipelines.

Hvorfor er det vigtigt at holde dine eksperimenter organiseret?

Lad os tage et skridt tilbage et øjeblik og prøve at forstå, hvorfor det er vigtigt at have eksperimenter organiseret til maskinlæring. Når dataforskere nærmer sig et nyt ML-problem, skal de besvare mange forskellige spørgsmål, lige fra datatilgængelighed til, hvordan de vil måle modellens ydeevne.

I starten er processen fuld af usikkerhed og meget iterativ. Som et resultat kan denne eksperimenteringsfase producere flere modeller, der hver er skabt ud fra deres egne input (datasæt, træningsscripts og hyperparametre) og producerer deres egne output (modelartefakter og evalueringsmetrikker). Udfordringen er så at holde styr på alle disse input og output fra hver iteration.

Dataforskere træner typisk mange forskellige modelversioner, indtil de finder den kombination af datatransformation, algoritme og hyperparametre, der resulterer i den bedst ydende version af en model. Hver af disse unikke kombinationer er et enkelt eksperiment. Med en sporbar registrering af input, algoritmer og hyperparametre, der blev brugt af det pågældende forsøg, kan datavidenskabsteamet finde det nemt at reproducere deres trin.

At have en automatiseret proces på plads til at spore eksperimenter forbedrer evnen til at reproducere samt implementere specifikke modelversioner, der fungerer godt. Pipelines native integration med Experiments gør det nemt automatisk at spore og administrere eksperimenter på tværs af pipeline-kørsler.

Fordele ved SageMaker-eksperimenter

SageMaker Experiments giver datavidenskabsfolk mulighed for at organisere, spore, sammenligne og evaluere deres træningsgentagelser.

Lad os starte først med en oversigt over, hvad du kan gøre med eksperimenter:

• Organiser eksperimenter – Eksperimenter strukturerer eksperimentering med en enhed på øverste niveau kaldet en eksperiment der indeholder et sæt af forsøg. Hver prøveversion indeholder et sæt trin kaldet prøvekomponenter. Hver prøvekomponent er en kombination af datasæt, algoritmer og parametre. Du kan forestille dig eksperimenter som mappen på øverste niveau til at organisere dine hypoteser, dine forsøg som undermapper for hver gruppetestkørsel og dine prøvekomponenter som dine filer for hver forekomst af en testkørsel.
• Spor eksperimenter – Eksperimenter giver dataforskere mulighed for at spore eksperimenter. Det giver mulighed for automatisk at tildele SageMaker-job til en prøveversion via simple konfigurationer og via sporings-SDK'erne.
• Sammenlign og vurder eksperimenter – Integrationen af ​​Eksperimenter med Amazon SageMaker Studio gør det nemt at producere datavisualiseringer og sammenligne forskellige forsøg. Du kan også få adgang til prøvedataene via Python SDK for at generere din egen visualisering ved hjælp af dine foretrukne plottebiblioteker.

Hvis du vil vide mere om Experiments API'er og SDK'er, anbefaler vi følgende dokumentation: OpretEksperiment , Amazon SageMaker Experiments Python SDK.

Hvis du vil dykke dybere, anbefaler vi at se nærmere på amazon-sagemaker-examples/sagemaker-experiments GitHub-lager for yderligere eksempler.

Integration mellem rørledninger og eksperimenter

Modelbygningspipelines, der er en del af Pipelines, er specialbygget til ML og giver dig mulighed for at orkestrere dine modelbygningsopgaver ved hjælp af et pipelineværktøj, der inkluderer native integrationer med andre SageMaker-funktioner samt fleksibiliteten til at udvide din pipeline med trin, der kører uden for SageMaker . Hvert trin definerer en handling, som pipelinen udfører. Afhængighederne mellem trin er defineret af en direkte acyklisk graf (DAG) bygget ved hjælp af Pipelines Python SDK. Du kan bygge en SageMaker-pipeline programmatisk via den samme SDK. Når en pipeline er implementeret, kan du valgfrit visualisere dens arbejdsgang i Studio.

Pipelines integreres automatisk med Experiments ved automatisk at oprette et eksperiment og en prøveperiode for hver kørsel. Pipelines opretter automatisk et eksperiment og en prøveperiode for hver kørsel af pipelinen, før trinene køres, medmindre en eller begge af disse input er angivet. Mens pipelinens SageMaker-job køres, forbinder pipelinen forsøget med eksperimentet og knytter alle prøvekomponenter, der oprettes af jobbet, til forsøget. Ved at angive dit eget eksperiment eller prøveversion programmatisk kan du finjustere, hvordan du organiserer dine eksperimenter.

Den arbejdsgang, vi præsenterer i dette eksempel, består af en række trin: et forbehandlingstrin til at opdele vores inputdatasæt i tog-, test- og valideringsdatasæt; et tuning-trin for at tune vores hyperparametre og starte træningsjob for at træne en model ved hjælp af XGBoost indbygget algoritme; og til sidst et modeltrin til at skabe en SageMaker-model fra den bedst trænede modelartefakt. Pipelines tilbyder også flere indbygget understøttede trintyper ud over hvad der diskuteres i dette indlæg. Vi illustrerer også, hvordan du kan spore dit pipeline-workflow og generere metrics og sammenligningsdiagrammer. Desuden viser vi, hvordan man knytter det nye forsøg, der er genereret, til et eksisterende eksperiment, der muligvis er blevet oprettet, før pipelinen blev defineret.

SageMaker Pipelines kode

Du kan gennemgå og downloade notesbogen fra GitHub repository forbundet med dette indlæg. Vi ser på den Pipelines-specifikke kode for at forstå den bedre.

Pipelines giver dig mulighed for at videregive parametre under kørsel. Her definerer vi behandlings- og træningsinstanstyperne og tæller ved kørselstid med forudindstillede standardindstillinger:

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"
)

Dernæst opsætter vi et behandlingsscript, der downloader og opdeler inputdatasættet i tog-, test- og valideringsdele. Vi bruger SKLearnProcessor for at køre dette forbehandlingstrin. For at gøre det definerer vi et processorobjekt med den instanstype og det antal, der er nødvendige for at køre behandlingsjobbet.

Pipelines giver os mulighed for at opnå dataversionering på en programmatisk måde ved at bruge eksekveringsspecifikke variabler som f.eks ExecutionVariables.PIPELINE_EXECUTION_ID, som er det unikke ID for en pipelinekørsel. Vi kan for eksempel oprette en unik nøgle til at gemme outputdatasættene i Amazon Simple Storage Service (Amazon S3), der binder dem til en specifik pipeline-kørsel. Se den fulde liste over variabler Udfø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",
)

Derefter går vi videre med at oprette et estimatorobjekt til at træne en XGBoost-model. Vi indstiller nogle statiske hyperparametre, der almindeligvis bruges 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 laver hyperparameter tuning af de modeller, vi laver ved at bruge en ContinuousParameter rækkevidde for lambda. Hvis du vælger én metrik til at være den objektive metrik, fortæller tuneren (forekomsten, der kører hyperparametrene tuning jobs), at du vil evaluere træningsopgaven baseret på denne specifikke metrik. Tuneren returnerer den bedste kombination baseret på den bedste værdi for denne objektive metrik, hvilket betyder den bedste kombination, der minimerer den bedste RMSE-fejl.

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",
        ),
    } 
)

Tuning-trinnet kører flere forsøg med det mål at bestemme den bedste model blandt de testede parameterområder. Med metoden get_top_model_s3_uri, rangerer vi de 50 bedste versioner af modelartefakten S3 URI og udtrækker kun den bedst ydende version (vi specificerer k=0 for det bedste) for at skabe en SageMaker-model.

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 kører, opretter den prøvekomponenter for hvert hyperparameterjusteringsjob og hvert SageMaker-job, der oprettes af pipelinetrinene.

Du kan yderligere konfigurere integrationen af ​​pipelines med Eksperimenter ved at oprette en PipelineExperimentConfig objektet og videregive det til rørledningsobjektet. De to parametre definerer navnet på det eksperiment, der vil blive oprettet, og det forsøg, der vil referere til hele forløbet af pipelinen.

Hvis du vil knytte en pipelinekørsel til et eksisterende eksperiment, kan du videregive dens navn, og Pipelines vil knytte den nye prøveversion til den. Du kan forhindre oprettelsen af ​​et eksperiment og en prøveperiode for en pipeline, der køres ved at indstille 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 videregiver instanstyperne og tæller som parametre og kæder de foregående trin i rækkefølge som følger. Pipeline-arbejdsgangen er implicit defineret ved, at output fra et trin er input fra et andet trin.

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 fuldgyldige pipeline er nu oprettet og klar til at gå. Vi tilføjer en eksekveringsrolle til pipelinen og starter den. Herfra kan vi gå til SageMaker Studio Pipelines-konsollen og visuelt spore hvert trin. Du kan også få adgang til de linkede logfiler fra konsollen for at fejlsøge en pipeline.

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

Det foregående skærmbillede viser med grønt en velfungerende pipeline. Vi opnår metrics for et forsøg fra en kørsel af pipelinen 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 metrics for hver prøvekomponent

Du kan plotte resultaterne af hyperparameterjustering i Studio eller via andre Python-plotbiblioteker. Vi viser begge måder at gøre dette på.

Udforsk trænings- og evalueringsmålingerne i Studio

Studio tilbyder en interaktiv brugergrænseflade, hvor du kan generere interaktive plots. Trinene er som følger:

1. Vælg Eksperimenter og forsøg fra SageMaker ressourcer ikon i venstre sidebjælke.
2. Vælg dit eksperiment for at åbne det.
3. Vælg (højreklik) prøveversionen af ​​interesse.
4. Vælg Åbn i prøvekomponentlisten.
5. Presse Flytte at vælge de prøvekomponenter, der repræsenterer træningsjob.
6. Vælg Tilføj diagram.
7. Vælg Nyt diagram og tilpasse den til at plotte de indsamlede metrics, som du vil analysere. Til vores brugssag skal du vælge følgende:
   1. Til DatatypeVælg Sammenfattende statistik.
   2. Til Chart typenVælg Scatter Plot.
   3. Til X-akse, vælg lambda.
   4. Til Y-akse, vælg validation:rmse_last.

Det nye diagram vises nederst i vinduet, mærket som '8'.

Du kan inkludere flere eller færre uddannelsesjobs ved at trykke på Flytte og ved at vælge øjenikonet for en mere interaktiv oplevelse.

Analyse med SageMaker Experiments

Når pipeline-kørslen er færdig, kan vi hurtigt visualisere, hvordan forskellige variationer af modellen sammenligner sig med hensyn til de målinger, der indsamles under træning. Tidligere eksporterede vi alle prøvedata til en pandas DataFrame ved brug af ExperimentAnalytics. Vi kan gengive plottet opnået i Studio ved at bruge Matplotlib-biblioteket.

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

Konklusion

Den native integration mellem SageMaker Pipelines og SageMaker Experiments giver datavidenskabsfolk mulighed for automatisk at organisere, spore og visualisere eksperimenter under modeludviklingsaktiviteter. Du kan oprette eksperimenter for at organisere alt dit modeludviklingsarbejde, såsom følgende:

• En virksomhedsbrugssag, du behandler, f.eks. oprettelse af et eksperiment for at forudsige kundeafgang
• Et eksperiment ejet af data science-teamet vedrørende marketinganalyse, for eksempel
• Et specifikt datavidenskab og ML-projekt

I dette indlæg dykkede vi ind i Pipelines for at vise, hvordan du kan bruge det sammen med eksperimenter til at organisere en fuldautomatisk end-to-end workflow.

Som et næste trin kan du bruge disse tre SageMaker-funktioner – Studio, Experiments og Pipelines – til dit næste ML-projekt.

Foreslåede aflæsninger

Om forfatterne

Paul DiFrancesco er løsningsarkitekt hos AWS. Han har erfaring inden for telekommunikation og software engineering. Han brænder for machine learning og fokuserer i øjeblikket på at bruge sin erfaring til at hjælpe kunder med at nå deres mål på AWS, især i diskussioner omkring MLOps. Uden for arbejdet nyder han at spille fodbold og læse.

Mario Bourgoin er Senior Partner Solutions Architect for AWS, en AI/ML specialist og den globale tech lead for MLOps. Han arbejder med virksomhedskunder og partnere, der implementerer AI-løsninger i skyen. Han har mere end 30 års erfaring med maskinlæring og kunstig intelligens ved startups og i virksomheder, begyndende med at skabe et af de første kommercielle maskinlæringssystemer til big data. Mario bruger sin fritid på at lege med sine tre belgiske Tervurens, lave mad til sin familie og lære om matematik og kosmologi.

Ganapathi Krishnamoorthi er Senior ML Solutions Architect hos AWS. Ganapathi giver foreskrivende vejledning til startup- og virksomhedskunder, der hjælper dem med at designe og implementere cloud-applikationer i stor skala. Han er specialiseret i maskinlæring og er fokuseret på at hjælpe kunder med at udnytte AI/ML til deres forretningsresultater. Når han ikke er på arbejde, nyder han at udforske udendørs og lytte til musik.

Valerie Sounthakith er en løsningsarkitekt for AWS, der arbejder i spilindustrien og med partnere, der implementerer AI-løsninger. Hun sigter mod at bygge sin karriere op omkring Computer Vision. I sin fritid bruger Valerie den på at rejse, opdage nye madsteder og ændre sit husinteriør.