Detecção de Fraudes em Seguros de Automóveis com Grafos e Machine Learning na AWS

Por Roberto Perillo, arquiteto de soluções enterprise da AWS Brasil.

Anualmente, fraudes em seguros de automóveis custam bilhões de dólares a indústria de seguros. A Coalition Against Insurance Fraud estima que a fraude de seguros custa aos consumidores americanos mais de US$ 308,6 bilhões por ano, em todos os ramos. No fim do dia, quem paga a conta são os consumidores, por meio de prêmios mais altos, mas o problema vai muito além de sinistros individuais mais caros. Existem redes organizadas de fraude que operam esquemas sofisticados e coordenados, envolvendo dezenas de participantes.

Entre os padrões mais comuns estão:

• Acidentes forjados: colisões irreais, encenadas entre veículos de participantes da mesma quadrilha, com testemunhas e oficinas pré-combinadas.
• Colisão forçada: o veículo do fraudador fecha outro veículo propositalmente para provocar uma colisão traseira e gerar um sinistro.
• Passageiros fantasmas: pessoas que não estavam no veículo no momento do acidente aparecem como vítimas para inflar o valor da indenização.
• Colisões no papel: acidentes que nunca aconteceram, registrados com boletins de ocorrência não verificados.
• Advogados e guinchos corruptos: profissionais que direcionam vítimas para oficinas e clínicas fraudulentas em troca de comissões.
• Testemunhas profissionais: pessoas agindo como “bystanders” (espectadores) falsos ou cúmplices que se posicionam estrategicamente para validar versões mentirosas de acidentes forjados, simulados ou manipulados.

O grande desafio é que esses esquemas são difíceis de detectar com métodos tradicionais baseados em regras. Os fraudadores adaptam seus comportamentos, e as conexões entre os participantes de uma rede de fraude ficam escondidas em meio a milhares de sinistros legítimos.

Esse é um dos casos em que a utilização de grafos e machine learning é bastante útil, pelo fato de que os grafos são estruturas ideais justamente para esses casos, por permitirem encontrar conexões que seriam difíceis de serem encontradas em outras estruturas. Em conjunto com machine learning, pode-se determinar scores de fraude com bastante precisão, utilizando o contexto das conexões entre os vértices do grafo.

Neste blog post, é apresentada uma solução completa de detecção de fraudes em seguros de automóveis utilizando Amazon Neptune, como banco de dados em grafos, e Amazon Neptune ML, para inferência de scores de fraude com Graph Neural Networks (GNNs). Um grafo é um conjunto de pontos (vértices) conectados por linhas (arestas) que representam as relações e conexões entre diferentes objetos ou informações.

Um detalhe importante é que o grafo de cada cenário terá vértices específicos, possivelmente diferentes dos aqui apresentados. Ainda assim, é possível carregar o grafo com os dados que se tem e aplicar as técnicas aqui apresentadas, para a predição dos scores de fraude. A solução completa pode ser encontrada neste repositório do Github, no aws-samples.

Grafos Para a Detecção de Fraudes

Em um banco de dados relacional tradicional, cada sinistro é uma linha em uma tabela. Pode-se perfeitamente cruzar dados, mas identificar que o mesmo grupo de pessoas está conectado à mesma oficina, ao mesmo advogado e às mesmas testemunhas em múltiplos sinistros exigiria múltiplos JOINs complexos e custosos.

Já em um banco de dados de grafos, os integrantes de uma rede de fraude e as conexões entre eles são first-class citizens. Cada entidade no grafo (como segurado, sinistro, veículo, acidente, oficina, testemunha, médico, advogado, guincho ou passageiro, por exemplo) é um vértice, e cada relacionamento entre os vertices é uma aresta. O grafo é a estrutura de dados adequada para responder perguntas como “quais segurados compartilham a mesma oficina, testemunha e advogado em sinistros diferentes?”, pois a resposta está intrinsicamente ligada ao relacionamento entre essas entidades.

Grafos e Machine Learning: Amazon Neptune + Amazon Neptune ML

O Neptune é o serviço de banco de dados em grafos totalmente gerenciado da AWS, projetado para armazenar e consultar dados altamente conectados de forma eficiente. Ele suporta dois modelos de grafos, que são grafos de propriedades e Resource Description Framework (RDF), e é otimizado para que seja possível encontrar informações na ordem de milissegundos mesmo em grafos que possuam bilhões de dados. E por ser totalmente gerenciado, o Neptune cuida de tarefas operacionais como provisionamento de hardware, patching, backups e replicação de dados, além de permitir a criação de até 15 réplicas de leitura por cluster.

Para aplicações que exigem baixa latência de leitura em múltiplas regiões geográficas e alta disponibilidade, o Neptune pode ser utilizado de forma global. E no quesito segurança, o Neptune oferece autenticação via AWS IAM, criptografia em repouso e em trânsito, e isolamento de VPC, além de suporte a auditoria avançada e conformidade com diversos padrões e certificações internacionais, como HIPAA, ISO, SOC e FedRAMP.

Grafos são especialmente úteis em situações em que os dados são altamente conectados, e as relações entre os dados são tão importantes quanto os próprios dados. Pode-se citar como exemplos de casos em que grafos são a estrutura de dados mais adequada: redes sociais, sistemas de recomendações, sistemas de roteamento e detecções de fraude. Grafos também podem ser utilizados para sistemas de busca, pelo fato de que mantêm performance constante e eliminam o gargalo computacional de múltiplos JOINs. Como referência, pode-se citar o case do IU Docs, do Itaú Unibanco, em que a substituição do SQL Server pelo Neptune reduziu o tempo de resposta da casa dos segundos para milissegundos, viabilizando a busca em uma base de alta escala com extrema eficiência.

O Neptune ML é a integração nativa entre o Neptune e o Amazon SageMaker, que permite treinar modelos de machine learning diretamente sobre dados armazenados no Neptune, sem a necessidade de se extrair features manualmente. O modelo utilizado para treinamento são as chamadas GNNs, que são uma categoria de deep learning projetada para extrair conhecimento a partir dos dados nos grafos, permitindo que a inteligência artificial aprenda não apenas com as características individuais de cada vértice, mas também com as arestas e interdependências entre eles.

As GNNs funcionam por meio de um mecanismo de passagem de mensagens, onde cada ponto da rede atualiza sua própria informação ao “conversar” com seus vizinhos, sendo fundamentais para prever comportamentos em sistemas complexos como redes sociais, cadeias moleculares e fluxos de tráfego.

Na prática, isso significa que a GNN consegue capturar padrões que dependem de um contexto de relacionamento. Por exemplo, um segurado que individualmente parece legítimo pode receber um score de risco elevado se estiver conectado a uma oficina suspeita, a um advogado envolvido em casos de fraude ou uma testemunha profissional. O Neptune ML suporta tarefas como classificação de vértices, predição de arestas e regressão de propriedades, e as predições podem ser consultadas diretamente via Gremlin ou SPARQL, como qualquer outra propriedade do grafo.

@app.post("/claims")
def submit_claim():
    # definção de campos...
    body = app.current_event.json_body
    g = get_neptune_connection()
    g.addV('claim').property(T.id, claim_id).property('amount', claim_amount).property('status', 'pending').property('claimDate', timestamp).next()
    # Integração nativa entre o Neptune e o SageMaker. A partir da palavra-chave “Neptune#ml”, a engine do Neptune consulta
    # a propriedade no SageMaker de forma transparente e adiciona o resultado a query
    result = g.V(claim_id).properties('fraudScore').with_("Neptune#ml.regression").with_("Neptune#ml.inductiveInference").value().next()
    fraud_score = float(result)
    # mais código aqui...

Listagem 1. Predição do score de fraude de um sinistro via Neptune ML.

O Modelo de Dados da Solução

Na solução construída, o grafo representa um ecossistema de sinistros de automóveis, com os seguintes vértices:

• Claimant: o segurado que registrou o sinistro.
• Claim: o sinistro, com valor e status.
• Vehicle: o veículo envolvido.
• Accident: o acidente, com tipo, local e verificação policial.
• Repair Shop: a oficina onde o reparo foi realizado.
• Witness: uma testemunha do acidente.
• Medical Provider: o médico que atendeu o segurado.
• Attorney: o advogado que representou o segurado.
• Tow Company: a empresa de guincho que removeu o veículo.
• Passenger: o passageiro que alegou estar no veículo.

Figura 1. Modelo de dados do grafo contemplado na solução.

Arquitetura da Solução

O sistema de detecção de fraude em seguros de automóveis apresentado neste blog post é uma solução serverless baseada em grafos. A ideia é identificar padrões de fraude em sinistros de seguro de automóveis, analisando as relações entre segurados, veículos, oficinas de reparo, testemunhas, passageiros, médicos e outros envolvidos, e também atribuir scores de fraude a novos sinistros. Em vez de analisar cada sinistro de forma isolada, o sistema modela todo o domínio como um grafo de propriedades, onde as conexões entre entidades revelam comportamentos suspeitos que seriam difíceis de encontrar em outras estratégias de análise.

Frontend

A interface do usuário é uma aplicação web estática desenvolvida em HTML, CSS e JavaScript puro, com suporte a três idiomas (Inglês, Espanhol e Português). Os arquivos são armazenados no Amazon Simple Storage Service (Amazon S3) e entregues globalmente pelo Amazon CloudFront, protegido pelo AWS WAF, com limitação de taxa por IP e regras gerenciadas da OWASP para proteção contra ataques comuns de camada 7, como SQL injection e cross-site scripting.

Figura 2. O frontend da solução.

Autenticação

A autenticação é gerenciada pelo Amazon Cognito, mas o navegador nunca se comunica diretamente com ele. Todas as requisições de login, renovação de token e logout passam pelo Amazon API Gateway e são processadas por uma função AWS Lambda. Após o login bem-sucedido, o frontend recebe um token JWT armazenado em sessionStorage, que é enviado em um header “Authorization: Bearer” (com httpOnly e secure) em todas as chamadas subsequentes à API da solução.

API e Detecção de Fraude

O API Gateway expõe mais de 20 endpoints REST, também protegidos pelo AWS WAF. Todas as requisições são encaminhadas a uma função Lambda de detecção de fraude, que executa consultas Gremlin no Neptune. A função Lambda implementa algoritmos como detecção de comunidades, análise de centralidade, pontuação de velocidade de sinistros e identificação de anéis de colisão, retornando os resultados diretamente ao frontend para visualização interativa com D3.js.

Neptune ML e Pipeline de Treinamento

A solução utiliza o Neptune ML para gerar scores de fraude baseadas em GNNs, que são retornados como valores de propriedades em consultas ao grafo. Uma pipeline orquestrada pelo AWS Step Functions automatiza todo o ciclo de vida da GNN: exportação dos dados do Neptune via AWS Batch, pré-processamento e validação no Amazon S3, treinamento no SageMaker, avaliação de desempenho e implantação do endpoint de inferência. Cada etapa é executada por uma função Lambda específica, e o resultado final é um endpoint SageMaker que determina um score de fraude para cada uma das entidades no grafo.

Segurança de Rede

Todo o processamento ocorre dentro de uma Amazon Virtual Private Cloud (Amazon VPC) privada, sem exposição à internet pública. Exceto a função Lambda de autenticação, todas as funções Lambda são atribuídas a uma VPC, para que a comunicação com cada serviço AWS utilize VPC Endpoints dedicados: Gateway Endpoint para o Amazon S3 e Interface Endpoints para os serviços AWS Batch, SageMaker, Service Quotas, Amazon Elastic Container Registry (Amazon ECR), Amazon Elastic Container Service (Amazon ECS), Amazon Relational Database Service (Amazon RDS) e Amazon CloudWatch. O cluster Neptune também reside dentro da VPC, na qual as funções Lambda são atribuídas, ficando assim acessível exclusivamente dentro da VPC. Dessa forma, nenhuma comunicação entre os componentes da solução trafega pela internet pública.

Infraestrutura como Código

Toda a infraestrutura é definida como código em Amazon CloudFormation, organizada em stacks aninhadas (VPC, Neptune, Lambda, API Gateway, Amazon Cognito, AWS WAF, VPC Endpoints, Step Functions, entre outras) e implantada por um único stack raiz. Para facilitar o deploy, também foram preparados dois scripts Bash, sendo um que automatiza todo o processo de deploy (empacotamento e upload das funções Lambda, upload dos templates para o Amazon S3, implantação do CloudFormation, configuração do frontend e inicialização da pipeline de treinamento da GNN), e outro que automatiza o processo de remoção da solução.

O último passo do script de deploy é a execução da pipeline de treinamento da GNN no SageMaker, mas antes, o script executa uma função Lambda que popula o grafo com dados aleatórios, para que seja possível treinar a GNN e testar a solução. Em um cenário real, alguns pontos da solução precisarão ser customizados para contemplar os dados específicos que se tem para a detecção de fraude, como por exemplo, a função Lambda de detecção de fraude, que atua nos vértices do modelo apresentado na Figura 1, as telas do frontend, e a função Lambda StartNeptuneExport, que define a propriedade de score de fraude e as features, para treinamento da GNN.

Figura 3. Arquitetura da solução.

Como o Neptune ML Funciona

O Neptune ML integra o Neptune com o SageMaker para o treinamento de GNNs diretamente sobre os dados do grafo, sem que seja necessário extrair features manualmente. E, de forma simplificada, para que a GNN possa ser treinada no SageMaker a partir dos dados do Neptune, o seguinte processo deve acontecer:

• Exportação dos dados. Os dados do grafo são exportados do Neptune para o Amazon S3 em um formato que preserva a estrutura de vértices e arestas.
• Processamento. Os dados exportados são convertidos em um formato otimizado para treinamento de GNNs, incluindo a geração automática de features a partir das propriedades dos vértices e arestas.
• Treinamento. Uma GNN é treinada no Amazon SageMaker. A GNN “aprende” representações (embeddings) para cada vértice do grafo, levando em conta não apenas suas propriedades, mas também sua vizinhança e contexto, ou seja, com quem e como cada vértice se conecta.
• Deploy. A GNN treinada é implantada em um endpoint do SageMaker, permitindo inferências em tempo real.
• Inferência. Quando se consulta o score de fraude de uma entidade, como o código apresentado na Listagem 1, o Neptune consulta o SageMaker de forma transparente e combina o resultado da consulta com a estrutura do grafo, e retorna os dados.

A vantagem das GNNs para detecção de fraude é que elas capturam padrões estruturais. Um segurado pode parecer legítimo isoladamente, mas se ele está conectado a uma oficina suspeita, a um advogado que representa outros fraudadores e a uma testemunha profissional, a GNN vai considerar esse contexto e calcular um score de risco mais elevado.

Existem diversos tipos de GNNs (como Graph Convolutional Network (GCN) , Graph Attention Networks (GAT) e Line Graph Neural Networks (LGNN), cada um com uma estratégia diferente para agregar informações dos nós vizinhos. Nesta solução, o autotrainer do Neptune ML seleciona automaticamente o tipo RGCN (Relational Graph Convolutional Network) como GNN mais adequada para o problema, por se tratar de um grafo heterogêneo com múltiplos tipos de vértices (segurado, veículos, oficinas, testemunhas, etc.) e múltiplos tipos de arestas (filed_claim, repaired_at, witnessed_by, etc.).

Ao contrário de uma GCN simples, nas RGCNs se aplicam matrizes de pesos distintas para cada tipo de relação, permitindo que a GNN aprenda, por exemplo, que a influência de uma oficina conectada via repaired_at é diferente da influência de uma testemunha conectada via witnessed_by na predição do score de fraude.

Vale destacar uma limitação importante do Neptune ML: ele não suporta múltiplos tipos de vértices como alvo de treinamento simultaneamente. Ao tentar configurar mais de um tipo de vértice-alvo no arquivo training-data-configuration.json (gerado pelo utilitário neptune-export.jar durante a exportação do grafo, a partir do payload passado para a execução de exportação), o job de processamento falha com um erro interno na biblioteca dgl_graphloader.

Para contornar essa limitação, o modelo de grafo desta solução utiliza um vértice específico para armazenando de scores de fraude, o fraudEntity, que concentra a propriedade fraudScore de todas as entidades suspeitas (oficinas, testemunhas, advogados, etc.), conectado a cada entidade por uma aresta has_fraud_score, e é essa propriedade que indicamos como target para treinamento da GNN. Essa abordagem contorna a limitação e permite que o autotrainer dispare múltiplos jobs de treinamento em paralelo via HPO (Hyperparameter Optimization) no SageMaker, testando diferentes arquiteturas e hiperparâmetros, e selecione automaticamente o modelo com menor validation loss para implantação no endpoint, sem qualquer intervenção manual. Os vértices claimants e vehicles não têm um vértice fraudEntity correspondente, dado que o score de fraude desse vértices é calculado nas queries, considerando os sinistros conectados a ele.

Para o cálculo dos scores de fraude, utiliza-se uma estratégia de fallback em 3 níveis para obter o score de fraude de cada vértice. Primeiro, é feito o cálculo do score em tempo real através do endpoint do Neptune ML implantado no SageMaker, usando inferência indutiva (Neptune#ml.inductiveInference). Isso quer dizer que mesmo que o vértice já possua um score armazenado, a GNN é consultada para gerar uma predição baseada no estado atual do grafo. Se a inferência por machine learning falhar (por exemplo, se o endpoint ainda não estiver implantado no momento da consulta), o sistema recorre ao score armazenado no vértice fraudEntity vinculado através da aresta has_fraud_score.

Especificamente para os vértices claimants e vehicles, que não têm um vértice fraudEntity correspondente, calcula-se a média dos scores de fraude dos sinistros conectadas. No caso de claimants, percorrendo a aresta filed_claim, e no caso de vehicles, percorrendo o caminho vehicle → accident → claim → fraudEntity. Uma flag _ml_available é mantida em cache durante cada invocação da Lambda para evitar chamadas repetidas a um endpoint inexistente: se a inferência por machine learning falhar uma vez, as consultas subsequentes na mesma requisição vão direto para o score armazenado.

Figura 4. Cada vértice de cada tipo que possui um score de fraude recebe um vértice fraudEntity correspondente, o que permite contornar a limitação do Neptune ML.

Dessa forma, o payload para a exportação do grafo pelo neptune-export.jar, no passo de exportação de dados no grafo, fica como mostrado na Listagem abaixo.

json_payload = {
    'command': 'export-pg',
    'outputS3Path': f's3://{s3_bucket}/neptune-export/',
    'params': {
        'endpoint': f'{neptune_endpoint}:8182',
        'profile': 'neptune_ml',
        'useIamAuth': True
    },
    'additionalParams': {
        'neptune_ml': {
            'version': 'v2.0',
            'targets': [
                {'node': 'fraudEntity', 'property': 'fraudScore', 'type': 'regression'}
            ],
            'features': [
                {'node': 'claim', 'property': 'amount', 'type': 'numerical'},
                {'node': 'claim', 'property': 'isFraud', 'type': 'category'},
                {'node': 'accident', 'property': 'accidentType', 'type': 'category'},
                {'node': 'accident', 'property': 'maneuverType', 'type': 'category'},
                {'node': 'accident', 'property': 'policeVerified', 'type': 'category'},
                {'node': 'repairShop', 'property': 'suspicious', 'type': 'category'},
                {'node': 'repairShop', 'property': 'rating', 'type': 'numerical'},
                {'node': 'witness', 'property': 'professional', 'type': 'category'},
                {'node': 'medicalProvider', 'property': 'specialty', 'type': 'category'},
                {'node': 'vehicle', 'property': 'year', 'type': 'numerical'}
            ]
        }
    }
}

Listagem 2. Payload de exportação de dados do grafo.

A Pipeline de Machine Learning

Para que a GNN tenha um bom nível de acurácia, é preciso que ele esteja treinado com dados tão atualizados quanto possível. Para isso, foi construída uma pipeline utilizando-se Step Functions, que automatiza todo o ciclo de vida da GNN.

Cada etapa é executada por uma função Lambda dedicada:

1. Solicitar cotas: garante que as cotas de SageMaker necessárias estão disponíveis.
2. Exportar dados do Neptune: inicia um job de exportação via AWS Batch, extraindo o grafo completo para o Amazon S3.
3. Aguardar e verificar exportação: monitora o status do job de exportação em loop até a conclusão.
4. Processar dados exportados: converte os dados para o formato de treinamento do Neptune ML.
5. Validar dados de treinamento: verifica a integridade dos dados antes do treinamento, prevenindo model poisoning (ou “envenenamento do modelo”). Se a validação falhar, a pipeline é interrompida.
6. Treinar a GNN: inicia o treinamento da GNN no SageMaker.
7. Testar performance: avalia as métricas da GNN treinada. Se a performance estiver abaixo do aceitável, a pipeline falha, sendo assim mais uma proteção contra modelos comprometidos.
8. Deploy do endpoint: faz o deploy da GNN aprovada em um endpoint do SageMaker para inferência em tempo real. Além disso, o endpoint da GNN é definido como parêmetro no parameter group do Neptune, para que seja possível omiti-lo nas queries feitas no grafo.

Figura 5. Etapas da pipeline de treinamento da GNN no SageMaker.

Nessa solução, a pipeline é executada automaticamente a cada 15 dias via Amazon EventBridge Scheduler, garantindo que a GNN se mantenha atualizada conforme novos sinistros são registrados. A regra pode ser customizada para que a GNN seja treinada em um intervalo mais adequado para cada situação.

Endpoints Para Detecção de Fraude

A solução expõe as seguintes APIs REST Amazon API Gateway, com o seguintes endpoints organizados em categorias:

• Autenticação
  • Login e logout com Amazon Cognito, usando tokens JWT e cookies httpOnly e secure.
• Análise de sinistros
  • Submissão de novos sinistros com detecção de fraude em tempo real via machine learning.
  • Consulta de detalhes e histórico de sinistros.
  • Velocidade de sinistros por segurado (claim velocity).
• Detecção de padrões de fraude
  • Anéis de colisão. Detecta 6 tipos de anéis de colisão: acidentes forjados, colisão traseira induzida, passageiros fantasmas, colisões em papel (sem boletim verificado), advogados corruptos e guinchos corruptos.
  • Testemunhas profissionais. Identifica testemunhas que aparecem em múltiplos sinistros não relacionados.
  • Indicadores de conluio. Detecta padrões de conluio entre entidades.
  • Padrões de sinistros cruzados. Identifica padrões suspeitos entre sinistros diferentes.
• Redes de fraude
  • Segurados influentes. Identifica segurados centrais em redes de fraude.
  • Anéis organizados. Detecta redes organizadas de fraude com múltiplos participantes coordenados.
  • Hubs de fraude. Detecta oficinas, provedores médicos e advogados que concentram múltiplos segurados fraudulentos, com score de conluio.
  • Conexões entre fraudadores. Mapeia as conexões entre entidades suspeitas.
  • Anéis isolados: identifica grupos de fraude desconectados do restante do grafo.
• Análise com machine learning
  • Score de risco de segurados. Predição de fraude via GNN.
  • Análise completa de fraude por segurado. Combina algoritmos de grafo e machine learning em uma análise abrangente.
  • Histórico de fraude de veículos. Análise de veículos envolvidos em sinistros suspeitos.
  • Análise de provedores médicos. Identifica clínicas e médicos com padrões anômalos.
  • Consulta de entidades individuais. Detalhes de segurados, veículos, oficinas, provedores médicos, advogados, testemunhas, guincheiros e passageiros.
• Analytics
  • Tendências de fraude. Visão temporal dos padrões de fraude, incluindo exposição financeira estimada.
  • Hotspots geográficos. Concentração geográfica de sinistros suspeitos por tipo de entidade.

Com essa solução, uma seguradora pode:

• Detectar fraudes em tempo real. Ao submeter um novo sinistro, o sistema retorna imediatamente um score de risco baseado na GNN e na posição da entidade no grafo.
• Detectar padrões de fraude. Com esta solução, empresas de seguros podem identificar padrões de fraude em tempo real (como anéis de colisão, testemunhas profissionais, oficinas e provedores médicos suspeitos, advogados e empresas de reboque corruptos, e segurados que abrem sinistros em série), que seriam difíceis identificar sem a utilização de grafos e machine learning.
• Identificar redes organizadas. Os algoritmos de grafo revelam conexões ocultas entre segurados, oficinas, advogados e testemunhas que seriam invisíveis em análises tradicionais.
• Manter a GNN atualizada. A pipeline automatizada retreina a GNN a cada 15 dias, incorporando novos dados e adaptando-se a novos padrões de fraude.
• Operar com segurança. A arquitetura segue as melhores práticas de segurança da AWS, com autenticação em todas as camadas, rede isolada e proteção contra ataques comuns.

Conclusão

Neste blog post, é apresentada uma solução AWS para a detecção de fraudes em um ecossistema de seguros de automóveis. Ao modelar esse ecossistema como um grafo no Neptune, torna-se mais fácil detectar padrões de fraude, pelo fato de que esses padrões são inerentemente uma questão de conexões entre conceitos, que podem ser mais fácil de serem detectados a partir de algoritmos de busca em grafos. O Neptune ML complementa essa capacidade ao treinar redes neurais de grafos (GNNs), que aprendem diretamente da estrutura do grafo, permitindo predições em tempo real sobre novos sinistros através de inferência indutiva, mesmo para entidades que não existiam durante o treinamento da GNN. Com uma arquitetura serverless, segurança em múltiplas camadas e uma pipeline de machine learning orquestrada, o sistema pode ser implantado em aproximadamente 16 minutos e está pronto para uso imediato.

O objetivo do blog post é apresentar a solução de detecção de fraude baseada em grafos e machine learning, utilizando Neptune e Neptune ML, e também mostrar como é possível utilizar esses dois serviços AWS para criar soluções em que o grafo é a estratégia mais adequada para armazenamento de dados, como redes sociais e detecção de fraude, e como é possível fazer predições utilizando machine learning, sejam elas predições de propriedades de vértices do tipo classification ou regression, ou predições de existência de arestas entre dois vértices. O código completo da solução está disponível para download a partir do repositório Git, no aws-samples.

No modelo de domínio implementado na solução, foram definidos vértices que não necessariamente existem em todas as situações. Ainda assim, a ideia é mostrar como as técnicas podem ser aplicadas, utilizando-se principalmente Neptune e Neptune ML para a detecção de padrões de fraude. A partir de algumas customizações, como a função Lambda de detecção de fraude, as telas do frontend, e a função Lambda StartNeptuneExport, que define a propriedade de score de fraude e as features para treinamento da GNN, a solução pode ser utilizada com diferentes modelos de domínio e em diferentes cenários.

Sobre o Autor

Roberto Perillo é arquiteto de soluções enterprise da AWS Brasil especialista em serverless, atendendo a clientes da indústria financeira, e atua na indústria de software desde 2001. Atuou por quase 20 anos como arquiteto de software e desenvolvedor Java antes de ingressar na AWS, em 2022. Possui graduação em Ciência da Computação, especialização em Engenharia de Software e mestrado também em Ciência da Computação. Um eterno aprendiz. Nas horas vagas, gosta de estudar, tocar guitarra, e também jogar boliche e futebol de botão com seu filho, Lorenzo!