Byg en GNN-baseret real-time svindeldetektionsløsning ved hjælp af Amazon SageMaker, Amazon Neptune og Deep Graph Library

Svigagtige aktiviteter påvirker mange industrier alvorligt, såsom e-handel, sociale medier og finansielle tjenester. Svig kan forårsage betydelige tab for virksomheder og forbrugere. Amerikanske forbrugere rapporterede, at de mistede mere end 5.8 milliarder dollars på grund af svig i 2021, en stigning på mere end 70 % i forhold til 2020. Mange teknikker er blevet brugt til at opdage svindlere – regelbaserede filtre, anomalidetektion og maskinlæringsmodeller (ML) for at nævne nogle få.

I data fra den virkelige verden involverer enheder ofte rige relationer med andre enheder. En sådan grafstruktur kan give værdifuld information til påvisning af anomalier. For eksempel, i den følgende figur, er brugere forbundet via delte enheder såsom Wi-Fi-id'er, fysiske placeringer og telefonnumre. På grund af det store antal unikke værdier for disse enheder, som telefonnumre, er det svært at bruge dem i de traditionelle funktionsbaserede modeller - for eksempel ville one-hot-kodning af alle telefonnumre ikke være levedygtig. Men sådanne forhold kan hjælpe med at forudsige, om en bruger er en svindler. Hvis en bruger har delt flere enheder med en kendt svindler, er brugeren mere sandsynligt en svindler.

For nylig er graph neural network (GNN) blevet en populær metode til at opdage svindel. GNN-modeller kan kombinere både grafstruktur og attributter for noder eller kanter, såsom brugere eller transaktioner, for at lære meningsfulde repræsentationer for at skelne ondsindede brugere og hændelser fra legitime. Denne evne er afgørende for at opdage svig, hvor svindlere samarbejder for at skjule deres unormale træk, men efterlader nogle spor af relationer.

Nuværende GNN-løsninger er hovedsageligt afhængige af offline batch-træning og inferenstilstand, som opdager svindlere efter ondsindede hændelser er sket, og tab er opstået. At fange svigagtige brugere og aktiviteter i realtid er dog afgørende for at forhindre tab. Dette gælder især i forretningssager, hvor der kun er én chance for at forhindre svigagtige aktiviteter. For eksempel er kontoregistrering på nogle e-handelsplatforme vidt åben. Svindlere kan kun opføre sig ondsindet én gang med en konto og aldrig bruge den samme konto igen.

Det er vigtigt at forudsige svindlere i realtid. Det er imidlertid en udfordring at bygge en sådan løsning. Fordi GNN'er stadig er nye i branchen, er der begrænsede onlineressourcer til at konvertere GNN-modeller fra batch-servering til real-time-servering. Derudover er det udfordrende at konstruere en streamingdatapipeline, der kan føre indgående begivenheder til en GNN-realtidsserverings-API. Så vidt forfatterne ved, er der ingen referencearkitekturer og eksempler tilgængelige for GNN-baserede realtidsslutningsløsninger, da dette skrives.

For at hjælpe udviklere med at anvende GNN'er til registrering af svindel i realtid viser dette indlæg, hvordan man bruger det Amazon Neptun, Amazon SageMaker, og Deep Graph Library (DGL), blandt andre AWS-tjenester, at konstruere en end-to-end-løsning til real-time svindeldetektion ved hjælp af GNN-modeller.

Vi fokuserer på fire opgaver:

• Behandling af et tabelbaseret transaktionsdatasæt til et heterogent grafdatasæt
• Træning af en GNN-model ved hjælp af SageMaker
• Implementering af de trænede GNN-modeller som et SageMaker-slutpunkt
• Demonstrer realtidsslutning for indgående transaktioner

Dette indlæg udvider det tidligere arbejde i Opdagelse af bedrageri i heterogene netværk ved hjælp af Amazon SageMaker og Deep Graph Library, som fokuserer på de to første opgaver. Du kan henvise til det indlæg for flere detaljer om heterogene grafer, GNN'er og semi-overvåget træning af GNN'er.

Virksomheder, der leder efter en fuldt administreret AWS AI-tjeneste til afsløring af svindel, kan også bruge Amazon svindeldetektor, hvilket gør det nemt at identificere potentielt svigagtige onlineaktiviteter, såsom oprettelse af falske konti eller svindel med onlinebetalinger.

Løsningsoversigt

Denne løsning indeholder to hoveddele.

Den første del er en pipeline, der behandler dataene, træner GNN-modeller og implementerer de trænede modeller. Det bruger AWS Lim at behandle transaktionsdataene og gemmer de behandlede data til begge Amazon Neptun , Amazon Simple Storage Service (Amazon S3). Derefter udløses et SageMaker-træningsjob for at træne en GNN-model på de data, der er gemt i Amazon S3, for at forudsige, om en transaktion er svigagtig. Den trænede model sammen med andre aktiver gemmes tilbage til Amazon S3 efter afslutningen af ​​træningsjobbet. Endelig er den gemte model implementeret som et SageMaker-slutpunkt. Pipelinen er orkestreret af AWS-trinfunktioner, som vist i den følgende figur.

Den anden del af løsningen implementerer registrering af svigagtige transaktioner i realtid. Det starter fra en RESTful API, der forespørger grafdatabasen i Neptune for at udtrække subgrafen relateret til en indgående transaktion. Den har også en webportal, der kan simulere forretningsaktiviteter og generere onlinetransaktioner med både svigagtige og legitime. Webportalen giver en live visualisering af svindelopdagelsen. Denne del bruger Amazon CloudFront, AWS Amplify, AWS AppSync, Amazon API Gateway, Trinfunktioner og Amazon DocumentDB til hurtigt at bygge webapplikationen. Følgende diagram illustrerer realtidsslutningsprocessen og webportalen.

Implementeringen af ​​denne løsning, sammen med en AWS CloudFormation skabelon, der kan starte arkitekturen i din AWS-konto, er offentligt tilgængelig gennem følgende GitHub repo.

Databehandling

I dette afsnit beskriver vi kort, hvordan man behandler et eksempeldatasæt og konverterer det fra råtabeller til en graf med relationer identificeret mellem forskellige kolonner.

Denne løsning bruger det samme datasæt, den IEEE-CIS svindeldatasæt, som det forrige indlæg Opdagelse af bedrageri i heterogene netværk ved hjælp af Amazon SageMaker og Deep Graph Library. Derfor er grundprincippet i dataprocessen det samme. Kort fortalt inkluderer svindeldatasættet en transaktionstabel og en identitetstabel med næsten 500,000 anonymiserede transaktionsposter sammen med kontekstuelle oplysninger (for eksempel enheder, der bruges i transaktioner). Nogle transaktioner har en binær etiket, der angiver, om en transaktion er svigagtig. Vores opgave er at forudsige, hvilke umærkede transaktioner, der er svigagtige, og hvilke der er legitime.

Den følgende figur illustrerer den generelle proces for, hvordan man konverterer IEEE-tabellerne til en heterogen graf. Vi udtrækker først to kolonner fra hver tabel. En kolonne er altid transaktions-id-kolonnen, hvor vi indstiller hvert unikt Transaktions-ID som én node. En anden kolonne er valgt fra de kategoriske kolonner, såsom kolonnerne ProductCD og id_03, hvor hver unik kategori blev sat som en node. Hvis et TransactionID og en unik kategori vises i samme række, forbinder vi dem med én kant. På denne måde konverterer vi to kolonner i en tabel til én todelt. Derefter kombinerer vi disse todelte sammen med TransactionID-knudepunkterne, hvor de samme TransactionID-noder er slået sammen til én unik node. Efter dette trin har vi en heterogen graf bygget af todelte.

For resten af ​​kolonnerne, der ikke bruges til at bygge grafen, føjer vi dem sammen som funktionen af ​​TransactionID-noderne. TransactionID-værdier, der har isFraud-værdierne, bruges som etiketten for modeltræning. Baseret på denne heterogene graf bliver vores opgave en nodeklassificeringsopgave for TransactionID noderne. For flere detaljer om forberedelse af grafdata til træning af GNN'er, se Funktion ekstraktion , Konstruktion af grafen afsnit af det forrige blogindlæg.

Koden brugt i denne løsning er tilgængelig i src/scripts/glue-etl.py. Du kan også eksperimentere med databehandling gennem Jupyter notebook src/sagemaker/01.FD_SL_Process_IEEE-CIS_Dataset.ipynb.

I stedet for manuelt at behandle dataene, som gjort i det forrige indlæg, bruger denne løsning en fuldautomatisk pipeline orkestreret af Step Functions og AWS Glue, der understøtter behandling af enorme datasæt parallelt via Apache Spark. Workflowet Trinfunktioner er skrevet ind AWS Cloud Development Kit (AWS CDK). Følgende er en kodestykke for at oprette denne arbejdsgang:

import { LambdaInvoke, GlueStartJobRun } from 'aws-cdk-lib/aws-stepfunctions-tasks';
    
    const parametersNormalizeTask = new LambdaInvoke(this, 'Parameters normalize', {
      lambdaFunction: parametersNormalizeFn,
      integrationPattern: IntegrationPattern.REQUEST_RESPONSE,
    });
    
    ...
    
    const dataProcessTask = new GlueStartJobRun(this, 'Data Process', {
      integrationPattern: IntegrationPattern.RUN_JOB,
      glueJobName: etlConstruct.jobName,
      timeout: Duration.hours(5),
      resultPath: '$.dataProcessOutput',
    });
    
    ...    
    
    const definition = parametersNormalizeTask
      .next(dataIngestTask)
      .next(dataCatalogCrawlerTask)
      .next(dataProcessTask)
      .next(hyperParaTask)
      .next(trainingJobTask)
      .next(runLoadGraphDataTask)
      .next(modelRepackagingTask)
      .next(createModelTask)
      .next(createEndpointConfigTask)
      .next(checkEndpointTask)
      .next(endpointChoice);

Udover at konstruere grafdata til GNN-modeltræning, indlæser denne arbejdsgang også grafdataene i Neptun for at udføre realtidsslutning senere. Denne batchdataindlæsningsproces er demonstreret i følgende kodestykke:

from neptune_python_utils.endpoints import Endpoints
from neptune_python_utils.bulkload import BulkLoad

...

bulkload = BulkLoad(
        source=targetDataPath,
        endpoints=endpoints,
        role=args.neptune_iam_role_arn,
        region=args.region,
        update_single_cardinality_properties=True,
        fail_on_error=True)
        
load_status = bulkload.load_async()
status, json = load_status.status(details=True, errors=True)
load_status.wait()

GNN model uddannelse

Efter at grafdataene til modeltræning er gemt i Amazon S3, en SageMaker træningsjob, som kun oplades, når træningsjobbet kører, udløses for at starte GNN-modeltræningsprocessen i tilstanden Bring Your Own Container (BYOC). Det giver dig mulighed for at pakke dine modeltræningsscripts og afhængigheder i et Docker-billede, som det bruger til at oprette SageMaker-træningsforekomster. BYOC-metoden kan spare betydelige kræfter i opsætningen af ​​træningsmiljøet. I src/sagemaker/02.FD_SL_Build_Training_Container_Test_Local.ipynb, kan du finde detaljer om GNN-modeluddannelsen.

Docker-billede

Den første del af Jupyter notebook-filen er træningen af ​​Docker-billedgenerering (se følgende kodestykke):

*!* aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin 763104351884.dkr.ecr.us-east-1.amazonaws.com
image_name *=* 'fraud-detection-with-gnn-on-dgl/training'
*!* docker build -t $image_name ./FD_SL_DGL/gnn_fraud_detection_dgl

Vi brugte et PyTorch-baseret billede til modeltræningen. Deep Graph Library (DGL) og andre afhængigheder installeres, når Docker-billedet bygges. GNN-modelkoden i src/sagemaker/FD_SL_DGL/gnn_fraud_detection_dgl mappen kopieres også til billedet.

Fordi vi behandler transaktionsdataene til en heterogen graf, vælger vi i denne løsning Relational Graph Convolutional Network (RGCN) model, som er specielt designet til heterogene grafer. Vores RGCN-model kan træne indlæsbare indlejringer for knuderne i heterogene grafer. Derefter bruges de indlærte indlejringer som input til et fuldt tilsluttet lag til at forudsige nodemærkerne.

Hyperparametre

For at træne GNN'en skal vi definere nogle få hyperparametre før træningsprocessen, såsom filnavnene på den konstruerede graf, antallet af lag af GNN-modeller, træningsepokerne, optimeringsværktøjet, optimeringsparametrene og mere. Se følgende kode for en delmængde af konfigurationerne:

edges *=* ","*.*join(map(*lambda* x: x*.*split("/")[*-*1], [file *for* file *in* processed_files *if* "relation" *in* file]))

params *=* {'nodes' : 'features.csv',
          'edges': edges,
          'labels': 'tags.csv',
          'embedding-size': 64,
          'n-layers': 2,
          'n-epochs': 10,
          'optimizer': 'adam',
          'lr': 1e-2}

For mere information om alle hyperparametrene og deres standardværdier, se estimator_fns.py i src/sagemaker/FD_SL_DGL/gnn_fraud_detection_dgl mappe.

Modeltræning med SageMaker

Efter at det tilpassede container Docker-billede er bygget, bruger vi de forbehandlede data til at træne vores GNN-model med de hyperparametre, vi definerede. Træningsjobbet bruger DGL, med PyTorch som backend deep learning framework, til at konstruere og træne GNN. SageMaker gør det nemt at træne GNN-modeller med det tilpassede Docker-billede, som er et input-argument fra SageMaker-estimatoren. For mere information om træning af GNN'er med DGL på SageMaker, se Træn et Deep Graph Network.

SageMaker Python SDK bruger Estimator at indkapsle træning på SageMaker, som kører SageMaker-kompatible brugerdefinerede Docker-containere, så du kan køre dine egne ML-algoritmer ved at bruge SageMaker Python SDK. Følgende kodestykke demonstrerer træning af modellen med SageMaker (enten i et lokalt miljø eller cloud-forekomster):

from sagemaker.estimator import Estimator
from time import strftime, gmtime
from sagemaker.local import LocalSession

localSageMakerSession = LocalSession(boto_session=boto3.session.Session(region_name=current_region))
estimator = Estimator(image_uri=image_name,
                      role=sagemaker_exec_role,
                      instance_count=1,
                      instance_type='local',
                      hyperparameters=params,
                      output_path=output_path,
                      sagemaker_session=localSageMakerSession)

training_job_name = "{}-{}".format('GNN-FD-SL-DGL-Train', strftime("%Y-%m-%d-%H-%M-%S", gmtime()))
print(training_job_name)

estimator.fit({'train': processed_data}, job_name=training_job_name)

Efter træning vises GNN-modellens ydeevne på testsættet som følgende output. RGCN-modellen kan normalt opnå omkring 0.87 AUC og mere end 95 % nøjagtighed. For en sammenligning af RGCN-modellen med andre ML-modeller henvises til Resultater afsnittet i det forrige blogindlæg for flere detaljer.

Epoch 00099 | Time(s) 7.9413 | Loss 0.1023 | f1 0.3745
Metrics
Confusion Matrix:
                        labels positive labels negative
    predicted positive  4343            576
    predicted negative  13494           454019

    f1: 0.3817, precision: 0.8829, recall: 0.2435, acc: 0.9702, roc: 0.8704, pr: 0.4782, ap: 0.4782

Finished Model training

Efter afslutningen af ​​modeltræningen pakker SageMaker den trænede model sammen med andre aktiver, inklusive de trænede node-indlejringer, i en ZIP-fil og uploader den derefter til en specificeret S3-placering. Dernæst diskuterer vi implementeringen af ​​den trænede model til svigagtig opdagelse i realtid.

GNN-modelimplementering

SageMaker gør implementeringen af ​​trænede ML-modeller enkel. I denne fase bruger vi SageMaker PyTorchModel-klassen til at implementere den trænede model, fordi vores DGL-model afhænger af PyTorch som backend-ramme. Du kan finde implementeringskoden i src/sagemaker/03.FD_SL_Endpoint_Deployment.ipynb fil.

Udover den trænede modelfil og aktiver kræver SageMaker en indgangsfil til implementering af en tilpasset model. Entry point-filen køres og lagres i hukommelsen af ​​en inferensslutpunktsinstans for at svare på inferensanmodningen. I vores tilfælde er entry point-filen fd_sl_deployment_entry_point.py fil i src/sagemaker/FD_SL_DGL/code mappe, som udfører fire hovedfunktioner:

• Modtag anmodninger og analyser indholdet af anmodninger for at få de noder, der skal forudsiges, og deres tilknyttede data
• Konverter dataene til en heterogen DGL-graf som input til RGCN-modellen
• Udfør realtidsslutningen via den trænede RGCN-model
• Returner forudsigelsesresultaterne til anmoderen

Efter SageMaker-konventioner implementeres de to første funktioner i input_fn metode. Se følgende kode (for nemheds skyld sletter vi noget kommentarkode):

def input_fn(request_body, request_content_type='application/json'):

    # --------------------- receive request ------------------------------------------------ #
    input_data = json.loads(request_body)

    subgraph_dict = input_data['graph']
    n_feats = input_data['n_feats']
    target_id = input_data['target_id']

    graph, new_n_feats, new_pred_target_id = recreate_graph_data(subgraph_dict, n_feats, target_id)

    return (graph, new_n_feats, new_pred_target_id)

Den konstruerede DGL-graf og funktioner sendes derefter til predict_fn metode til at opfylde den tredje funktion. predict_fn tager to input-argumenter: output af input_fn og den trænede model. Se følgende kode:

def predict_fn(input_data, model):

    # ---------------------  Inference ------------------------------------------------ #
    graph, new_n_feats, new_pred_target_id = input_data

    with th.no_grad():
        logits = model(graph, new_n_feats)
        res = logits[new_pred_target_id].cpu().detach().numpy()

    return res[1]

Modellen brugt i perdict_fn er oprettet af model_fn metode, når endepunktet kaldes første gang. Funktionen model_fn indlæser den gemte modelfil og tilhørende aktiver fra model_dir argument og SageMaker-modelmappen. Se følgende kode:

def model_fn(model_dir):

    # ------------------ Loading model -------------------
    ntype_dict, etypes, in_size, hidden_size, out_size, n_layers, embedding_size = 
    initialize_arguments(os.path.join(BASE_PATH, 'metadata.pkl'))

    rgcn_model = HeteroRGCN(ntype_dict, etypes, in_size, hidden_size, out_size, n_layers, embedding_size)

    stat_dict = th.load('model.pth')

    rgcn_model.load_state_dict(stat_dict)

    return rgcn_model

Output fra predict_fn metode er en liste med to tal, der angiver logits for klasse 0 og klasse 1, hvor 0 betyder legitim og 1 betyder svigagtig. SageMaker tager denne liste og sender den til en indre metode kaldet output_fn for at fuldføre den endelige funktion.

For at implementere vores GNN-model pakker vi først GNN-modellen ind i en SageMaker PyTorchModel-klasse med indgangspunktsfilen og andre parametre (stien til den gemte ZIP-fil, PyTorch-rammeversionen, Python-versionen og så videre). Så kalder vi dens implementeringsmetode med instansindstillinger. Se følgende kode:

env = {
    'SAGEMAKER_MODEL_SERVER_WORKERS': '1'
}

print(f'Use model {repackged_model_path}')

sagemakerSession = sm.session.Session(boto3.session.Session(region_name=current_region))
fd_sl_model = PyTorchModel(model_data=repackged_model_path, 
                           role=sagemaker_exec_role,
                           entry_point='./FD_SL_DGL/code/fd_sl_deployment_entry_point.py',
                           framework_version='1.6.0',
                           py_version='py3',
                           predictor_cls=JSONPredictor,
                           env=env,
                           sagemaker_session=sagemakerSession)
                           
fd_sl_predictor *=* fd_sl_model*.*deploy(instance_type*=*'ml.c5.4xlarge',
                                     initial_instance_count*=*1,)

De foregående procedurer og kodestykker viser, hvordan du implementerer din GNN-model som et online-slutpunkt fra en Jupyter-notebook. Til produktion anbefaler vi dog at bruge den tidligere nævnte MLOps-pipeline orkestreret af Step Functions til hele arbejdsgangen, inklusive behandling af data, træning af modellen og implementering af et inferensendepunkt. Hele pipelinen er implementeret af en AWS CDK ansøgning, som nemt kan replikeres i forskellige regioner og konti.

Realtidsslutning

Når en ny transaktion ankommer, skal vi udføre fire trin for at udføre forudsigelse i realtid:

1. Node og kant indsættelse – Udtræk transaktionens oplysninger såsom TransactionID og ProductCD som noder og kanter, og indsæt de nye noder i de eksisterende grafdata, der er gemt i Neptune-databasen.
2. Subgraf-udtrækning – Indstil den transaktionsknude, der skal forudsiges, som den midterste knude, og udtræk en n-hop-undergraf i henhold til GNN-modellens inputkrav.
3. Funktion ekstraktion – For knudepunkter og kanter i undergrafen, udtræk deres tilknyttede funktioner.
4. Kald slutningsendepunktet – Pak undergrafen og funktionerne ind i indholdet af en anmodning, og send derefter anmodningen til inferensendepunktet.

I denne løsning implementerer vi en RESTful API for at opnå svigagtig forudsigelse i realtid beskrevet i de foregående trin. Se følgende pseudo-kode for forudsigelser i realtid. Den fulde implementering er klar den komplette kildekodefil.

For forudsigelse i realtid kræver de første tre trin lavere latenstid. Derfor er en grafdatabase et optimalt valg til disse opgaver, især til subgraf-ekstraktion, som kunne opnås effektivt med grafdatabaseforespørgsler. Understregningsfunktionerne, der understøtter pseudokoden, er baseret på Neptuns gremlin-forespørgsler.

def handler(event, context):
    
    graph_input = GraphModelClient(endpoints)
    
    # Step 1: node and edge insertion
    trans_dict, identity_dict, target_id, transaction_value_cols, union_li_cols = 
        load_data_from_event(event, transactions_id_cols, transactions_cat_cols, dummied_col)
    graph_input.insert_new_transaction_vertex_and_edge(trans_dict, identity_dict , target_id, vertex_type = 'Transaction')
    
    
    # Setp 2: subgraph extraction
    subgraph_dict, transaction_embed_value_dict = 
        graph_input.query_target_subgraph(target_id, trans_dict, transaction_value_cols, union_li_cols, dummied_col)
    

    # Step 3 & 4: feature extraction & call the inference endpoint
    transaction_id = int(target_id[(target_id.find('-')+1):])
    pred_prob = invoke_endpoint_with_idx(endpointname = ENDPOINT_NAME, target_id = transaction_id, subgraph_dict = subgraph_dict, n_feats = transaction_embed_value_dict)
       
    function_res = {
                    'id': event['transaction_data'][0]['TransactionID'],
                    'flag': pred_prob > MODEL_BTW,
                    'pred_prob': pred_prob
                    }
       
    return function_res

En advarsel om svigdetektion i realtid ved hjælp af GNN'er er GNN-inferenstilstanden. For at opfylde inferens i realtid skal vi konvertere GNN-modellens inferens fra transduktiv tilstand til induktiv tilstand. GNN-modeller i transduktiv inferenstilstand kan ikke lave forudsigelser for nyligt dukkede noder og kanter, hvorimod i induktiv tilstand kan GNN-modeller håndtere nye noder og kanter. En demonstration af forskellen mellem transduktiv og induktiv tilstand er vist i den følgende figur.

I transduktiv tilstand sameksisterer forudsagte noder og kanter med mærkede noder og kanter under træning. Modeller identificerer dem før inferens, og de kunne udledes i træning. Modeller i induktiv tilstand trænes på træningsgrafen, men skal forudsige usete noder (dem i røde prikkede cirkler til højre) med deres tilknyttede naboer, som kan være nye noder, som den grå trekantknude til højre.

Vores RGCN-model er trænet og testet i transduktiv tilstand. Den har adgang til alle noder i træning og trænede også en indlejring for hver funktionsfri node, såsom IP-adresse og korttyper. I testfasen bruger RGCN-modellen disse indlejringer som nodefunktioner til at forudsige noder i testsættet. Når vi foretager realtidsinferens, har nogle af de nyligt tilføjede funktionsløse noder ingen sådanne indlejringer, fordi de ikke er i træningsgrafen. En måde at løse dette problem på er at tildele gennemsnittet af alle indlejringer i den samme nodetype til de nye noder. I denne løsning bruger vi denne metode.

Derudover giver denne løsning en webportal (som vist på det følgende skærmbillede) til at demonstrere svigagtige forudsigelser i realtid fra virksomhedsoperatørers perspektiv. Det kan generere de simulerede online transaktioner og give en live visualisering af opdagede svigagtige transaktionsoplysninger.

Ryd op

Når du er færdig med at udforske løsningen, kan du rense ressourcerne for at undgå gebyrer.

Konklusion

I dette indlæg viste vi, hvordan man bygger en GNN-baseret real-time svindeldetektionsløsning ved hjælp af SageMaker, Neptune og DGL. Denne løsning har tre store fordele:

• Den har en god ydeevne med hensyn til forudsigelsesnøjagtighed og AUC-målinger
• Den kan udføre inferens i realtid via en streaming MLOps-pipeline og SageMaker-endepunkter
• Det automatiserer hele implementeringsprocessen med den medfølgende CloudFormation-skabelon, så interesserede udviklere nemt kan teste denne løsning med tilpassede data på deres konto

For flere detaljer om løsningen, se GitHub repo.

Når du har implementeret denne løsning, anbefaler vi, at du tilpasser databehandlingskoden, så den passer til dit eget dataformat og modificerer realtidsslutningsmekanismen, mens GNN-modellen holdes uændret. Bemærk, at vi opdeler realtidsslutningen i fire trin uden yderligere optimering af latensen. Disse fire trin tager et par sekunder at få en forudsigelse på demodatasættet. Vi mener, at optimering af Neptune-grafdataskemadesignet og forespørgsler til subgraf- og featureekstraktion kan reducere inferensforsinkelsen betydeligt.

Om forfatterne

Jian Zhang er en anvendt videnskabsmand, der har brugt maskinlæringsteknikker til at hjælpe kunder med at løse forskellige problemer, såsom opdagelse af svindel, generering af dekorationsbilleder og mere. Han har med succes udviklet grafbaseret maskinlæring, især grafiske neurale netværk, løsninger til kunder i Kina, USA og Singapore. Som en oplyser af AWS's graffunktioner har Zhang holdt mange offentlige præsentationer om GNN, Deep Graph Library (DGL), Amazon Neptune og andre AWS-tjenester.

Mengxin Zhu er leder af Solutions Architects hos AWS, med fokus på at designe og udvikle genanvendelige AWS-løsninger. Han har beskæftiget sig med softwareudvikling i mange år og har været ansvarlig for flere startup-teams af forskellig størrelse. Han er også en fortaler for open source-software og var en Eclipse Committer.

Haozhu Wang er forsker ved Amazon ML Solutions Lab, hvor han medleder Reinforcement Learning Vertical. Han hjælper kunder med at bygge avancerede maskinlæringsløsninger med den seneste forskning om grafindlæring, naturlig sprogbehandling, forstærkningsindlæring og AutoML. Haozhu modtog sin ph.d. i elektro- og computerteknik fra University of Michigan.