Her er det neurale netværk, der kan forudsige din næste onlineven

I dette indlæg fortsætter vi med at arbejde på linkforudsigelse med Twitch-datasættet. Vi vil fokusere på at træne ML-modellen baseret på Graph Neural Networks (GNN'er) og optimere dens hyperparametre. På nuværende tidspunkt har vi allerede grafdataene behandlet og forberedt til modeltræning. De foregående trin er beskrevet i Del 3 - Databehandling, Del 2 - Eksport af data fra DB'en og Del 1 - Indlæsning af data i DB'en.

Læs del 1 her ; del 2 her ; og del 3 her.

VALG AF NEURAL NETVÆRKSTYPE GRAF: GCN'er og R-GCN'er

Vi vil bruge Graph Convolutional Neural Networks ligesom vi gjorde i det lokale link-forudsigelsesindlæg , og selvom Neptune ML bruger den samme DGL.ai -ramme, er den underliggende model en smule anderledes. Neptune ML understøtter både vidensgrafer (homogene grafer med en enkelt nodetype og en enkelt kanttype) og heterogene grafer, der har flere node- og kanttyper. Datasættet, som vi arbejder med, har en enkelt nodetype (bruger) og en enkelt kanttype (venskab). Selvom en Graph Convolutional Network (GCN) eller en Graph Sample and Aggregation (GraphSAGE) model også ville fungere i dette tilfælde, vælger Neptune ML automatisk en Relational Graph Convolutional Network (R-GCN) model for datasæt med nodeegenskaber, der kan variere fra node til node, som forklaret her . Generelt kræver R-GCN'er mere beregning at træne på grund af det øgede antal parametre, der er nødvendige for at håndtere flere node- og kanttyper.

MODEL TRÆNING HYPERPARAMETRE

Under databehandlingsfasen (som vi beskrev i det forrige indlæg TODO LINK), oprettede Neptune ML en fil med navnet model-hpo-configuration.json . Den indeholder modeltypen (R-GCN), opgavetypen (linkforudsigelse), evalueringsmetrikken og frekvensen og 4 lister over parametre: en med faste parametre, der ikke ændres under træningen, og 3 lister over parametre, der skal optimeres, med intervaller og standardværdier. Parametrene er grupperet efter vigtighed. Hvorvidt parametre fra hver af grupperne er tunet afgøres baseret på antallet af tilgængelige tuning-job: 1. tier-parametrene er altid tunet, 2. tier-parametrene tunes, hvis antallet af tilgængelige job er > 10, og 3. tier-parametrene tunes kun, hvis det er > 50. Vores model-hpo-configuration.json -fil ser ud som denne.

 { "models": [ { "model": "rgcn", "task_type": "link_predict", "eval_metric": { "metric": "mrr", "global_ranking_metrics": true, "include_retrieval_metrics": false }, "eval_frequency": { "type": "evaluate_every_pct", "value": 0.05 }, "1-tier-param": [ { "param": "num-hidden", "range": [16, 128], "type": "int", "inc_strategy": "power2" }, { "param": "num-epochs", "range": [3, 100], "inc_strategy": "linear", "inc_val": 1, "type": "int", "edge_strategy": "perM" }, { "param": "lr", "range": [0.001, 0.01], "type": "float", "inc_strategy": "log" }, { "param": "num-negs", "range": [4, 32], "type": "int", "inc_strategy": "power2" } ], "2-tier-param": [ { "param": "dropout", "range": [0.0, 0.5], "inc_strategy": "linear", "type": "float", "default": 0.3 }, { "param": "layer-norm", "type": "bool", "default": true }, { "param": "regularization-coef", "range": [0.0001, 0.01], "type": "float", "inc_strategy": "log", "default": 0.001 } ], "3-tier-param": [ { "param": "batch-size", "range": [128, 512], "inc_strategy": "power2", "type": "int", "default": 256 }, { "param": "sparse-lr", "range": [0.001, 0.01], "inc_strategy": "log", "type": "float", "default": 0.001 }, { "param": "fanout", "type": "int", "options": [[10, 30], [15, 30], [15, 30]], "default": [10, 15, 15] }, { "param": "num-layer", "range": [1, 3], "inc_strategy": "linear", "inc_val": 1, "type": "int", "default": 2 }, { "param": "num-bases", "range": [0, 8], "inc_strategy": "linear", "inc_val": 2, "type": "int", "default": 0 } ], "fixed-param": [ { "param": "neg-share", "type": "bool", "default": true }, { "param": "use-self-loop", "type": "bool", "default": true }, { "param": "low-mem", "type": "bool", "default": true }, { "param": "enable-early-stop", "type": "bool", "default": true }, { "param": "window-for-early-stop", "type": "bool", "default": 3 }, { "param": "concat-node-embed", "type": "bool", "default": true }, { "param": "per-feat-name-embed", "type": "bool", "default": true }, { "param": "use-edge-features", "type": "bool", "default": false }, { "param": "edge-num-hidden", "type": "int", "default": 16 }, { "param": "weighted-link-prediction", "type": "bool", "default": false }, { "param": "link-prediction-remove-targets", "type": "bool", "default": false }, { "param": "l2norm", "type": "float", "default": 0 } ] } ] }

Parametrene for model og opgavetype blev indstillet under dataeksport- og behandlingsstadierne og bør ikke ændres her.

Evalueringsmetrikken blev også automatisk valgt. Mean reciprocal rank (MRR) måler den gennemsnitlige rangering af det korrekte link i de forudsagte resultater, med en højere MRR, der indikerer bedre ydeevne .

Evalueringsfrekvensen er sat til 5 % af træningsforløbet. For eksempel, hvis vi har 100 epoker, vil evalueringen blive udført hver 5. epoker.

Lad os gennemgå nogle af de hyperparametre, der vil blive indstillet:

lr : Indlæringshastighed er en af de mest virkningsfulde hyperparametre for enhver modeltræning. En lavere indlæringshastighed kan føre til langsommere konvergens, men potentielt bedre ydeevne, mens en højere indlæringshastighed kan fremskynde træningen, men måske gå glip af optimale løsninger.

num-hidden : Parameteren num-hidden refererer til antallet af skjulte enheder (neuroner) i hvert lag af R-GCN neurale netværk, specifikt i de skjulte lag. Et større antal skjulte enheder øger modellens kapacitet til at lære komplekse mønstre og relationer fra dataene, hvilket kan forbedre forudsigelsesnøjagtigheden, men kan også føre til overfitting, hvis modellen bliver for kompleks til datasættet.

num-epochs : Dette definerer, hvor længe modellen er trænet i. Flere epoker giver modellen mulighed for at lære mere af dataene, men kan øge risikoen for overfitting.

batch-størrelse : Batchstørrelsen påvirker hukommelsesbrug og konvergensstabilitet. En mindre batchstørrelse kan gøre modellen mere følsom over for dataene, mens en større batchstørrelse kan forbedre træningshastigheden.

num-negs : Negativ sampling påvirker, hvordan modellen lærer at skelne ægte links fra falske. Et højere antal negative prøver kan forbedre kvaliteten af forudsigelserne, men det øger beregningsomkostningerne.

dropout : Frafald hjælper med at forhindre overtilpasning ved tilfældigt at springe nogle neuroner over under træning. En højere frafaldsrate kan reducere overfitting, men det kan gøre indlæring sværere for modellen.

regularization-coef : Regularisering, der har til formål at forhindre, at modellen overfitting.

Du kan ændre standardværdierne, området og trinstørrelsen for hver af disse parametre. Den fulde liste over parametre kan findes her .

Når du har ændret parametrene, skal du bare erstatte den originale model-hpo-configuration.json fil i S3.

IAM ROLLER FOR MODEL TRÆNING OG HPO

Ligesom databehandling beskrevet i del 3 af denne vejledning, kræver modeltræning 2 IAM-roller: en Neptune-rolle, der giver Neptune-adgang til SageMaker og S3, og en Sagemaker-udførelsesrolle, der bruges af SageMaker, mens den kører databehandlingsopgaven og giver den adgang til S3. Disse roller skal have tillidspolitikker, der gør det muligt for Neptune og SageMaker-tjenesterne at påtage sig dem:

 { "Version": "2012-10-17", "Statement": [ { "Sid": "", "Effect": "Allow", "Principal": { "Service": "sagemaker.amazonaws.com" }, "Action": "sts:AssumeRole" }, { "Sid": "", "Effect": "Allow", "Principal": { "Service": "rds.amazonaws.com" }, "Action": "sts:AssumeRole" } ] }

Efter at have oprettet rollerne og opdateret deres tillidspolitikker, føjer vi dem til Neptune-klyngen (Neptune -> Databaser -> YOUR_NEPTUNE_CLUSTER_ID -> Forbindelse og sikkerhed -> IAM-roller -> Tilføj rolle).

START MODEL TRÆNING OG HPO VED BRUG AF NEPTUNE ML API

Nu er vi klar til at starte modeltræning. For at gøre det skal vi sende en anmodning til Neptune-klyngens HTTP API inde fra den VPC, hvor klyngen er placeret. Vi bruger curl på en EC2-instans:

 curl -XPOST https://(YOUR_NEPTUNE_ENDPOINT):8182/ml/modeltraining \ -H 'Content-Type: application/json' \ -d '{ "dataProcessingJobId" : "ID_OF_YOUR_DATAPROCESSING_JOB", "trainModelS3Location" : "s3://OUTPUT_BUCKET/model-artifacts/...", "neptuneIamRoleArn": "arn:aws:iam::123456789012:role/NeptuneMLModelTrainingNeptuneRole", "sagemakerIamRoleArn": "arn:aws:iam::123456789012:role/NeptuneMLModelTrainingSagemakerRole" }'

Kun disse parametre er nødvendige:

• dataProcessingJobId - job-id'et vil blive brugt til at få placeringen af de behandlede data i S3)
• trainModelS3Location - outputplaceringen for artefakterne (modellens vægte)
• Neptune og SageMaker roller (disse roller skal føjes til Neptune DB klyngen)

Der er også parameteren maxHPONumberOfTrainingJobs , der indstiller antallet af træningsjob, der skal køres med forskellige sæt hyperparametre. Som standard er det 2, men AWS anbefaler at køre mindst 10 jobs for at få en nøjagtig model.

Der er også mange valgfrie parametre: for eksempel kan vi manuelt vælge den EC2-instanstype, der skal bruges til modeltræning med trainingInstanceType og indstille dens lagervolumenstørrelse med trainingInstanceVolumeSizeInGB . Den fulde liste over parametre kan findes her .

Klyngen svarer med en JSON, der indeholder ID'et for det databehandlingsjob, vi lige har oprettet:

 {"id":"d584f5bc-d90e-4957-be01-523e07a7562e"}

Vi kan bruge det til at få status for modeltræningsjobbet med denne kommando (brug den samme neptuneIamRoleArn som i den forrige anmodning):

 curl https://YOUR_NEPTUNE_CLUSTER_ENDPOINT:8182/ml/modeltraining/YOUR_JOB_ID?neptuneIamRoleArn='arn:aws:iam::123456789012:role/NeptuneMLModelTrainingNeptuneRole'

Når den først reagerer med noget som dette,

 { "processingJob": { "name": "PROCESSING_JOB_NAME", "arn": "arn:aws:sagemaker:us-east-1:123456789012:processing-job/YOUR_PROCESSING_JOB_NAME", "status": "Completed", "outputLocation": "s3://OUTPUT_BUCKET/model-artifacts/PROCESSING_JOB_NAME/autotrainer-output" }, "hpoJob": { "name": "HPO_JOB_NAME", "arn": "arn:aws:sagemaker:us-east-1:123456789012:hyper-parameter-tuning-job/HPO_JOB_NAME", "status": "Completed" }, "mlModels": [ { "name": "MODEL_NAME-cpu", "arn": "arn:aws:sagemaker:us-east-1:123456789012:model/MODEL_NAME-cpu" } ], "id": "d584f5bc-d90e-4957-be01-523e07a7562e", "status": "Completed" }

vi kan tjekke træningsloggene og artefakterne i destinations S3-spanden.

GENNEMGÅ MODEL TRÆNINGSRESULTATER

Modeltræningen er afsluttet, så lad os tjekke resultaterne i AWS-konsollen: SageMaker -> Træning -> Træningsjob.

For nemheds skyld ændrede vi ikke antallet af HPO-job, da vi startede modeltræning, og standardværdien på 2 blev brugt. De 2 job blev kørt sideløbende. Forekomsttypen blev valgt automatisk: ml.g4dn.2xlarge .

Det første job (det med '001' i navnet) blev udført på 15 minutter, og det andet ('002') blev automatisk stoppet, da SageMaker understøtter tidlig stop, hvis træningsmålingerne ikke forbedres i et stykke tid:

Lad os sammenligne hyperparametrene, der blev brugt i disse job:

Kun 3 parametre har forskellige værdier: num-hidden, num-negs og lr . Den anden model (trænet med Job 2) havde højere indlæringshastighed, mens den havde mindre kapacitet til at fange komplekse mønstre (fordi den havde færre neuroner), og den blev trænet på færre negative prøver. Det førte til væsentligt lavere nøjagtighed, som vi kan se fra valideringsmiddelrangeringen (115 vs 23) og HITS@K :

Gennemsnitlig rang (MR) er den gennemsnitlige rangposition for det korrekte link blandt forudsigelserne. Lavere MR-værdier er bedre, fordi de indikerer, at det korrekte link i gennemsnit er placeret tættere på toppen .

HITS@K-metrikken måler andelen af gange, det korrekte link vises i de øverste K forudsagte resultater.

MODEL ARTEFAKTER

Når træningsjob er udført, oprettes modelartefakter i output S3-bøtten sammen med filer, der indeholder træningsstatistik og metrikker:

Metrikken og parametrene i disse JSON-filer er dem, vi nævnte tidligere. Kun 001-biblioteket indeholder 'output'-underbiblioteket med model.tar.gz-filen, da det er det eneste HPO-job, der blev fuldført. Artefakter til linkforudsigelse indeholder også DGL-grafdata, da det er nødvendigt for at lave faktiske forudsigelser, som forklaret her .

Disse filer vil blive brugt til at skabe et slutningsendepunkt og generere faktiske linkforudsigelser. Det vil blive diskuteret i det næste og sidste indlæg i denne serie.