Crie uma solução de detecção de fraude em tempo real baseada em GNN usando Amazon SageMaker, Amazon Neptune e Deep Graph Library

Atividades fraudulentas afetam severamente muitos setores, como comércio eletrônico, mídia social e serviços financeiros. As fraudes podem causar uma perda significativa para empresas e consumidores. Os consumidores americanos relataram perder mais de US$ 5.8 bilhões em fraudes em 2021, um aumento de mais de 70% em relação a 2020. Muitas técnicas têm sido usadas para detectar fraudadores — filtros baseados em regras, detecção de anomalias e modelos de aprendizado de máquina (ML), para citar alguns.

Em dados do mundo real, as entidades geralmente envolvem relacionamentos ricos com outras entidades. Essa estrutura de gráfico pode fornecer informações valiosas para detecção de anomalias. Por exemplo, na figura a seguir, os usuários estão conectados por meio de entidades compartilhadas, como IDs de Wi-Fi, locais físicos e números de telefone. Devido ao grande número de valores exclusivos dessas entidades, como números de telefone, é difícil usá-los nos modelos tradicionais baseados em recursos — por exemplo, a codificação one-hot de todos os números de telefone não seria viável. Mas essas relações podem ajudar a prever se um usuário é um fraudador. Se um usuário compartilhou várias entidades com um fraudador conhecido, é mais provável que o usuário seja um fraudador.

Recentemente, a rede neural gráfica (GNN) tornou-se um método popular para detecção de fraudes. Os modelos GNN podem combinar a estrutura gráfica e os atributos de nós ou arestas, como usuários ou transações, para aprender representações significativas para distinguir usuários e eventos maliciosos de legítimos. Essa capacidade é crucial para detectar fraudes em que os fraudadores conspiram para ocultar seus recursos anormais, mas deixam alguns vestígios de relações.

As soluções GNN atuais dependem principalmente do treinamento em lote offline e do modo de inferência, que detecta fraudadores após eventos maliciosos e perdas. No entanto, capturar usuários e atividades fraudulentas em tempo real é crucial para evitar perdas. Isso é particularmente verdadeiro em casos de negócios em que há apenas uma chance de evitar atividades fraudulentas. Por exemplo, em algumas plataformas de comércio eletrônico, o registro da conta é amplamente aberto. Os fraudadores podem se comportar maliciosamente apenas uma vez com uma conta e nunca mais usar a mesma conta.

Prever fraudadores em tempo real é importante. Construir tal solução, no entanto, é um desafio. Como os GNNs ainda são novos no setor, há recursos on-line limitados sobre a conversão de modelos GNN de serviço em lote para serviço em tempo real. Além disso, é um desafio construir um pipeline de dados de streaming que possa alimentar eventos de entrada para uma API de serviço GNN em tempo real. Até onde sabemos, não há arquiteturas de referência e exemplos disponíveis para soluções de inferência em tempo real baseadas em GNN no momento da redação deste artigo.

Para ajudar os desenvolvedores a aplicar GNNs à detecção de fraudes em tempo real, esta postagem mostra como usar Amazon Netuno, Amazon Sage Maker, e as Biblioteca de gráficos profundos (DGL), entre outros serviços da AWS, para construir uma solução completa para detecção de fraudes em tempo real usando modelos GNN.

Focamos em quatro tarefas:

• Processando um conjunto de dados de transação tabular em um conjunto de dados de gráfico heterogêneo
• Treinando um modelo GNN usando o SageMaker
• Implantando os modelos GNN treinados como um endpoint do SageMaker
• Demonstrando inferência em tempo real para transações recebidas

Este post estende o trabalho anterior em Detectando fraudes em redes heterogêneas usando o Amazon SageMaker e o Deep Graph Library, que se concentra nas duas primeiras tarefas. Você pode consultar esse post para obter mais detalhes sobre gráficos heterogêneos, GNNs e treinamento semi-supervisionado de GNNs.

As empresas que procuram um serviço AWS AI totalmente gerenciado para detecção de fraudes também podem usar Detector de fraude da Amazon, que facilita a identificação de atividades online potencialmente fraudulentas, como a criação de contas falsas ou fraude de pagamento online.

Visão geral da solução

Esta solução contém duas partes principais.

A primeira parte é um pipeline que processa os dados, treina modelos GNN e implanta os modelos treinados. Ele usa Cola AWS para processar os dados da transação e salva os dados processados ​​em ambos Amazon Netuno e Serviço de armazenamento simples da Amazon (Amazônia S3). Em seguida, um trabalho de treinamento do SageMaker é acionado para treinar um modelo GNN nos dados salvos no Amazon S3 para prever se uma transação é fraudulenta. O modelo treinado junto com outros ativos são salvos no Amazon S3 após a conclusão do trabalho de treinamento. Por fim, o modelo salvo é implantado como um endpoint do SageMaker. O pipeline é orquestrado por Funções de etapa da AWS, como mostra a figura a seguir.

A segunda parte da solução implementa a detecção de transações fraudulentas em tempo real. Ele começa a partir de uma API RESTful que consulta o banco de dados gráfico no Neptune para extrair o subgráfico relacionado a uma transação recebida. Também possui um portal web que pode simular atividades comerciais, gerando transações online com fraudulentas e legítimas. O portal da web fornece uma visualização ao vivo da detecção de fraude. Esta parte usa Amazon CloudFront, Amplificar AWS, AWS AppSync, Gateway de API da Amazon, Funções de etapa e Amazon DocumentDB para construir rapidamente o aplicativo da web. O diagrama a seguir ilustra o processo de inferência em tempo real e o portal da web.

A implementação desta solução, juntamente com um Formação da Nuvem AWS modelo que pode iniciar a arquitetura em sua conta da AWS, está disponível publicamente por meio do seguinte GitHub repo.

Processamento de dados

Nesta seção, descrevemos brevemente como processar um conjunto de dados de exemplo e convertê-lo de tabelas brutas em um gráfico com relações identificadas entre diferentes colunas.

Esta solução usa o mesmo conjunto de dados, o Conjunto de dados de fraude IEEE-CIS, como no post anterior Detectando fraudes em redes heterogêneas usando o Amazon SageMaker e o Deep Graph Library. Portanto, o princípio básico do processo de dados é o mesmo. Em resumo, o conjunto de dados de fraude inclui uma tabela de transações e uma tabela de identidades, com quase 500,000 registros de transações anônimas junto com informações contextuais (por exemplo, dispositivos usados ​​em transações). Algumas transações têm um rótulo binário, indicando se uma transação é fraudulenta. Nossa tarefa é prever quais transações não rotuladas são fraudulentas e quais são legítimas.

A figura a seguir ilustra o processo geral de como converter as tabelas IEEE em um gráfico heterogêneo. Primeiro extraímos duas colunas de cada tabela. Uma coluna é sempre a coluna de ID da transação, onde definimos cada TransactionID exclusiva como um nó. Outra coluna é selecionada das colunas categóricas, como as colunas ProductCD e id_03, onde cada categoria exclusiva foi definida como um nó. Se um TransactionID e uma categoria exclusiva aparecem na mesma linha, nós os conectamos com uma borda. Dessa forma, convertemos duas colunas de uma tabela em uma bipartida. Em seguida, combinamos essas bipartidas junto com os nós TransactionID, onde os mesmos nós TransactionID são mesclados em um único nó. Após esta etapa, temos um grafo heterogêneo construído a partir de bipartidos.

Para o restante das colunas que não são usadas para construir o gráfico, nós as juntamos como o recurso dos nós TransactionID. Os valores TransactionID que possuem os valores isFraud são usados ​​como rótulo para treinamento de modelo. Com base nesse gráfico heterogêneo, nossa tarefa se torna uma tarefa de classificação de nós dos nós TransactionID. Para obter mais detalhes sobre como preparar os dados do gráfico para treinar GNNs, consulte o Extração de recursos e Construindo o gráfico seções da postagem anterior do blog.

O código utilizado nesta solução está disponível em src/scripts/glue-etl.py. Você também pode experimentar o processamento de dados por meio do notebook Jupyter src/sagemaker/01.FD_SL_Process_IEEE-CIS_Dataset.ipynb.

Em vez de processar os dados manualmente, como feito na postagem anterior, esta solução usa um pipeline totalmente automático orquestrado pelo Step Functions e AWS Glue que oferece suporte ao processamento de grandes conjuntos de dados em paralelo via Apache Spark. O fluxo de trabalho do Step Functions é escrito em Kit de desenvolvimento em nuvem da AWS (AWS CDK). O seguinte é um fragmento de código para criar este fluxo de trabalho:

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

Além de construir os dados do gráfico para o treinamento do modelo GNN, esse fluxo de trabalho também carrega em lote os dados do gráfico no Neptune para realizar inferências em tempo real posteriormente. Este processo de carregamento de dados em lote é demonstrado no seguinte trecho de código:

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

Treinamento do modelo GNN

Depois que os dados do gráfico para treinamento do modelo são salvos no Amazon S3, um Trabalho de treinamento SageMaker, que é cobrado apenas quando o trabalho de treinamento está em execução, é acionado para iniciar o processo de treinamento do modelo GNN no modo Bring Your Own Container (BYOC). Ele permite que você empacote seus scripts e dependências de treinamento de modelo em uma imagem do Docker, que ele usa para criar instâncias de treinamento do SageMaker. O método BYOC pode economizar um esforço significativo na configuração do ambiente de treinamento. Dentro src/sagemaker/02.FD_SL_Build_Training_Container_Test_Local.ipynb, você pode encontrar detalhes do treinamento do modelo GNN.

Imagem Docker

A primeira parte do arquivo do notebook Jupyter é a geração da imagem do Docker de treinamento (veja o seguinte trecho de código):

*!* 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

Usamos uma imagem baseada em PyTorch para o treinamento do modelo. A Deep Graph Library (DGL) e outras dependências são instaladas ao construir a imagem do Docker. O código do modelo GNN no src/sagemaker/FD_SL_DGL/gnn_fraud_detection_dgl pasta também é copiada para a imagem.

Como processamos os dados da transação em um gráfico heterogêneo, nesta solução escolhemos o Rede Convolucional de Gráfico Relacional (RGCN), que é projetado especificamente para gráficos heterogêneos. Nosso modelo RGCN pode treinar embeddings que podem ser aprendidos para os nós em grafos heterogêneos. Em seguida, os embeddings aprendidos são usados ​​como entradas de uma camada totalmente conectada para prever os rótulos dos nós.

Hiperparâmetros

Para treinar o GNN, precisamos definir alguns hiperparâmetros antes do processo de treinamento, como os nomes dos arquivos do gráfico construído, o número de camadas dos modelos GNN, as épocas de treinamento, o otimizador, os parâmetros de otimização e muito mais. Consulte o código a seguir para obter um subconjunto das configurações:

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}

Para obter mais informações sobre todos os hiperparâmetros e seus valores padrão, consulte estimator_fns.py no src/sagemaker/FD_SL_DGL/gnn_fraud_detection_dgl pasta.

Treinamento de modelos com o SageMaker

Depois que a imagem personalizada do Docker do contêiner é criada, usamos os dados pré-processados ​​para treinar nosso modelo GNN com os hiperparâmetros que definimos. O trabalho de treinamento usa o DGL, com o PyTorch como a estrutura de aprendizado profundo de back-end, para construir e treinar o GNN. O SageMaker facilita o treinamento de modelos GNN com a imagem personalizada do Docker, que é um argumento de entrada do estimador do SageMaker. Para obter mais informações sobre como treinar GNNs com o DGL no SageMaker, consulte Treine uma rede Deep Graph.

O SDK Python do SageMaker usa Estimador para encapsular o treinamento no SageMaker, que executa contêineres personalizados do Docker compatíveis com SageMaker, permitindo que você execute seus próprios algoritmos de ML usando o SDK do Python do SageMaker. O snippet de código a seguir demonstra o treinamento do modelo com o SageMaker (em um ambiente local ou em instâncias de nuvem):

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)

Após o treinamento, o desempenho do modelo GNN no conjunto de teste é exibido como as saídas a seguir. O modelo RGCN normalmente pode atingir cerca de 0.87 AUC e mais de 95% de precisão. Para uma comparação do modelo RGCN com outros modelos de ML, consulte o Resultados seção da postagem anterior do blog para obter mais detalhes.

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

Após a conclusão do treinamento do modelo, o SageMaker empacota o modelo treinado junto com outros ativos, incluindo as incorporações de nós treinados, em um arquivo ZIP e, em seguida, carrega-o em um local S3 especificado. Em seguida, discutimos a implantação do modelo treinado para detecção fraudulenta em tempo real.

Implantação do modelo GNN

O SageMaker simplifica a implantação de modelos de ML treinados. Nesta etapa, usamos a classe PyTorchModel do SageMaker para implantar o modelo treinado, pois nosso modelo DGL depende do PyTorch como estrutura de back-end. Você pode encontrar o código de implantação no src/sagemaker/03.FD_SL_Endpoint_Deployment.ipynb arquivo.

Além do arquivo de modelo e ativos treinados, o SageMaker requer um arquivo de ponto de entrada para a implantação de um modelo personalizado. O arquivo de ponto de entrada é executado e armazenado na memória de uma instância de terminal de inferência para responder à solicitação de inferência. No nosso caso, o arquivo de ponto de entrada é o fd_sl_deployment_entry_point.py arquivo no src/sagemaker/FD_SL_DGL/code pasta, que executa quatro funções principais:

• Receba solicitações e analise o conteúdo das solicitações para obter os nós a serem previstos e seus dados associados
• Converta os dados em um gráfico heterogêneo DGL como entrada para o modelo RGCN
• Execute a inferência em tempo real por meio do modelo RGCN treinado
• Retornar os resultados da previsão para o solicitante

Seguindo as convenções do SageMaker, as duas primeiras funções são implementadas no input_fn método. Veja o código a seguir (para simplificar, excluímos alguns códigos de comentários):

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)

O gráfico DGL construído e os recursos são então passados ​​para o predict_fn método para cumprir a terceira função. predict_fn recebe dois argumentos de entrada: as saídas de input_fn e o modelo treinado. Veja o seguinte código:

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]

O modelo usado em perdict_fn é criado pelo model_fn quando o endpoint é chamado pela primeira vez. A função model_fn carrega o arquivo de modelo salvo e os ativos associados do model_dir argumento e a pasta de modelo do SageMaker. Veja o seguinte código:

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

A saída do predict_fn O método é uma lista de dois números, indicando os logits para classe 0 e classe 1, onde 0 significa legítimo e 1 significa fraudulento. O SageMaker pega essa lista e a passa para um método interno chamado output_fn para completar a função final.

Para implantar nosso modelo GNN, primeiro agrupamos o modelo GNN em uma classe PyTorchModel do SageMaker com o arquivo de ponto de entrada e outros parâmetros (o caminho do arquivo ZIP salvo, a versão da estrutura do PyTorch, a versão do Python e assim por diante). Em seguida, chamamos seu método deploy com configurações de instância. Veja o seguinte código:

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

Os procedimentos e trechos de código anteriores demonstram como implantar seu modelo GNN como um endpoint de inferência online de um notebook Jupyter. No entanto, para produção, recomendamos usar o pipeline MLOps mencionado anteriormente orquestrado pelo Step Functions para todo o fluxo de trabalho, incluindo processamento de dados, treinamento do modelo e implantação de um endpoint de inferência. Todo o pipeline é implementado por um AWS CDK Formulário on line, que pode ser facilmente replicado em diferentes regiões e contas.

Inferência em tempo real

Quando uma nova transação chega, para realizar a previsão em tempo real, precisamos concluir quatro etapas:

1. Inserção de nós e arestas – Extraia as informações da transação, como TransactionID e ProductCD como nós e arestas, e insira os novos nós nos dados de gráfico existentes armazenados no banco de dados Neptune.
2. Extração de subgrafo – Defina o nó de transação a ser previsto como o nó central e extraia um subgrafo n-hop de acordo com os requisitos de entrada do modelo GNN.
3. Extração de recursos – Para os nós e arestas no subgrafo, extraia seus recursos associados.
4. Chame o endpoint de inferência – Empacote o subgráfico e os recursos no conteúdo de uma solicitação e, em seguida, envie a solicitação para o terminal de inferência.

Nesta solução, implementamos uma API RESTful para obter a predicação fraudulenta em tempo real descrita nas etapas anteriores. Consulte o pseudocódigo a seguir para previsões em tempo real. A implementação completa está em o arquivo de código-fonte completo.

Para previsão em tempo real, as três primeiras etapas exigem menor latência. Portanto, um banco de dados de grafos é uma escolha ideal para essas tarefas, particularmente para a extração de subgrafos, que pode ser alcançada de forma eficiente com consultas ao banco de dados de grafos. As funções de sublinhado que suportam o pseudocódigo são baseadas nas consultas gremlin do Neptune.

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

Uma advertência sobre a detecção de fraude em tempo real usando GNNs é o modo de inferência GNN. Para cumprir a inferência em tempo real, precisamos converter a inferência do modelo GNN do modo transdutivo para o modo indutivo. Os modelos GNN no modo de inferência transdutiva não podem fazer previsões para nós e arestas recém-aparecidas, enquanto no modo indutivo, os modelos GNN podem lidar com novos nós e arestas. Uma demonstração da diferença entre o modo transdutivo e indutivo é mostrada na figura a seguir.

No modo transdutivo, os nós e arestas previstos coexistem com nós e arestas rotulados durante o treinamento. Os modelos os identificam antes da inferência e podem ser inferidos no treinamento. Modelos no modo indutivo são treinados no grafo de treinamento, mas precisam prever nós não vistos (aqueles em círculos pontilhados vermelhos à direita) com seus vizinhos associados, que podem ser novos nós, como o nó triângulo cinza à direita.

Nosso modelo RGCN é treinado e testado em modo transdutivo. Ele tem acesso a todos os nós em treinamento e também treinou uma incorporação para cada nó sem recursos, como endereço IP e tipos de cartão. No estágio de teste, o modelo RGCN usa esses embeddings como recursos de nó para prever nós no conjunto de teste. Quando fazemos inferência em tempo real, no entanto, alguns dos nós sem recursos recém-adicionados não possuem tais embeddings porque não estão no gráfico de treinamento. Uma maneira de resolver esse problema é atribuir a média de todos os embeddings no mesmo tipo de nó aos novos nós. Nesta solução, adotamos esse método.

Além disso, esta solução fornece um portal da web (como visto na captura de tela a seguir) para demonstrar previsões fraudulentas em tempo real da perspectiva dos operadores de negócios. Ele pode gerar as transações online simuladas e fornecer uma visualização ao vivo das informações de transações fraudulentas detectadas.

limpar

Quando terminar de explorar a solução, você pode limpar os recursos para evitar cobranças.

Conclusão

Neste post, mostramos como construir uma solução de detecção de fraude em tempo real baseada em GNN usando SageMaker, Neptune e DGL. Esta solução tem três grandes vantagens:

• Tem bom desempenho em termos de precisão de previsão e métricas de AUC
• Ele pode realizar inferência em tempo real por meio de um pipeline de MLOps de streaming e endpoints do SageMaker
• Ele automatiza todo o processo de implantação com o modelo CloudFormation fornecido para que os desenvolvedores interessados ​​possam testar facilmente esta solução com dados personalizados em sua conta

Para obter mais detalhes sobre a solução, consulte o GitHub repo.

Depois de implantar esta solução, recomendamos personalizar o código de processamento de dados para se adequar ao seu próprio formato de dados e modificar o mecanismo de inferência em tempo real, mantendo o modelo GNN inalterado. Observe que dividimos a inferência em tempo real em quatro etapas sem otimização adicional da latência. Essas quatro etapas levam alguns segundos para obter uma previsão no conjunto de dados de demonstração. Acreditamos que otimizar o design do esquema de dados do gráfico do Neptune e as consultas para extração de subgrafos e recursos podem reduzir significativamente a latência de inferência.

Sobre os autores

Jian Zhang é um cientista aplicado que usa técnicas de aprendizado de máquina para ajudar os clientes a resolver vários problemas, como detecção de fraudes, geração de imagens de decoração e muito mais. Ele desenvolveu com sucesso o aprendizado de máquina baseado em gráficos, particularmente redes neurais de gráficos, soluções para clientes na China, EUA e Cingapura. Como esclarecedor dos recursos gráficos da AWS, Zhang fez muitas apresentações públicas sobre o GNN, a Deep Graph Library (DGL), Amazon Neptune e outros serviços da AWS.

Mengxin Zhu é gerente de arquitetos de soluções da AWS, com foco em projetar e desenvolver soluções reutilizáveis ​​da AWS. Ele está envolvido no desenvolvimento de software há muitos anos e foi responsável por várias equipes de startups de vários tamanhos. Ele também é um defensor do software de código aberto e foi um Eclipse Committer.

Haozhu Wang é pesquisador do Amazon ML Solutions Lab, onde co-lidera o Reinforcement Learning Vertical. Ele ajuda os clientes a criar soluções avançadas de aprendizado de máquina com as pesquisas mais recentes sobre aprendizado de gráficos, processamento de linguagem natural, aprendizado por reforço e AutoML. Haozhu recebeu seu PhD em Engenharia Elétrica e de Computação pela Universidade de Michigan.