GrafoLab

GNNs para Prever Chamadas entre Microserviços: O que o GAT Acerta (e Erra)

outubro 24, 2025
Resumo — Arquiteturas de microserviços são poderosas, mas complexas. Uma falha em um serviço pode derrubar dezenas de outros. E se pudéssemos prever novas interações problemáticas antes que elas causem incidentes? Uma pesquisa recente (aceita no ICPE 2025) explora o uso de Graph Neural Networks (GNNs), especificamente a Graph Attention Network (GAT), para modelar o call graph (grafo de chamadas) e prever futuras conexões. Os resultados mostram alta precisão, abrindo caminho para um monitoramento mais proativo.

1. O Problema: A Teia Complexa dos Microserviços

Microserviços trouxeram agilidade, mas também uma complexidade explosiva. Em vez de um monólito, temos centenas (ou milhares) de pequenos serviços conversando entre si. Entender quem chama quem, quando e por quê, é o trabalho da observabilidade.

Ferramentas de tracing (como Jaeger ou Zipkin) nos dão a matéria-prima: os registros de cada chamada. A partir deles, podemos construir o Call Graph: um grafo onde os nós são os serviços e as arestas são as chamadas entre eles.

Mas analisar o passado não é suficiente. Queremos prever o futuro. E se pudéssemos saber que o serviço A está prestes a começar a chamar o serviço B (uma interação nova e talvez inesperada)? Isso permitiria:
- Alertas Proativos: “Atenção: padrão de chamada incomum detectado!”
- Prevenção de Falhas em Cascata: Identificar dependências críticas antes que elas causem um apagão.
- Otimização de Recursos: Alocar capacidade (autoscaling) de forma mais inteligente.
O desafio é: como prever essas futuras arestas em um grafo que muda constantemente?

2. A Solução: GNNs no Grafo de Chamadas Temporal

A pesquisa que discutimos aqui propõe modelar o call graph não como uma foto estática, mas como uma sequência de “filmes” (snapshots temporais) e usar GNNs para aprender a dinâmica dessas interações.

A Modelagem:
- Nós: Cada microserviço/serviço.
- Arestas: Chamadas entre serviços, direcionadas (A -> B). Crucialmente, as arestas são segmentadas por janelas de tempo (ex: snapshots a cada 5 minutos).
- Tarefa: Link Prediction Temporal. Dado o estado do grafo até o tempo t, prever quais arestas (chamadas) existirão na janela t + Δt.
3. Por Que GNNs? E Por Que GAT Especificamente?

As GNNs são uma escolha natural porque elas aprendem a partir da estrutura do grafo. O embedding (representação) de um serviço é influenciado pelos serviços que ele chama e pelos que o chamam.

Mas por que a Graph Attention Network (GAT)? O call graph de microserviços é dinâmico e barulhento:
- O volume de chamadas entre dois serviços pode variar drasticamente.
- Novos serviços surgem, outros morrem.
- Alguns serviços são “hubs” (chamados por muitos), outros são mais isolados.
A GAT usa um mecanismo de atenção. Ao calcular o embedding do serviço A, ela não trata todos os seus vizinhos (quem A chama ou quem chama A) da mesma forma. Ela aprende a dar pesos diferentes a cada vizinho, focando nos mais “informativos” para prever o comportamento futuro de A. A hipótese é que essa capacidade de “focar no que importa” torna a GAT mais robusta a ruídos e mudanças no padrão de tráfego.

4. O Pipeline (Alto Nível)

O fluxo de trabalho proposto no paper segue passos lógicos:
1. Coleta de Dados: Obter traces de chamadas de um sistema de observabilidade.
2. Construção do Grafo Temporal: Processar os traces para criar os snapshots do call graph (ex: um grafo a cada 5 minutos).
3. Amostragem Negativa: Para treinar um modelo de link prediction, precisamos de exemplos de “não-links”. Mas não podemos simplesmente escolher pares aleatórios. O paper usa técnicas para criar “negativos difíceis” – pares de serviços que não se chamaram, mas que poderiam plausivelmente se chamar (ex: estão “próximos” no grafo).
4. Treinamento da GAT: Treinar o modelo GAT em janelas passadas para prever as arestas na janela seguinte.
5. Avaliação Temporal: Testar o modelo em janelas futuras, usando métricas como AUC, Precision, Recall e F1-Score.
5. Resultados e Implicações: Previsão é Possível!

O estudo (aceito no ICPE 2025) reportou resultados promissores em dados reais, alcançando altos valores de AUC, Precision, Recall e F1-Score. Isso sugere que é viável usar GNNs para prever, com razoável antecedência, novas interações entre microserviços.

As implicações práticas são significativas:
- Monitoramento Adaptativo: Em vez de alertas baseados em regras fixas, podemos ter alertas baseados em previsões de comportamento anômalo.
- Prevenção de Incidentes: Se o modelo prevê uma nova chamada de A -> B que sobrecarregaria B, a equipe de SRE pode intervir antes do incidente.
- Planejamento de Capacidade: Usar as previsões para ajustar o autoscaling de forma mais proativa.
6. Desafios e Limitações (O que o GAT “Erra” ou Onde a Estrada é Longa)

A pesquisa é promissora, mas o caminho para a produção tem desafios (alguns discutidos no paper, outros práticos):
- Generalização: O modelo funcionará em diferentes arquiteturas de microserviços e stacks de observabilidade?
- Custo Computacional: Calcular features temporais e rodar GNNs pode ser caro. A inferência precisa ser rápida o suficiente para ser útil.
- Comparação com Baselines: Como a GAT se compara a abordagens mais simples (como Adamic-Adar no grafo temporal) ou outras GNNs (como GraphSAGE ou GNNs Temporais específicas)? É crucial ter baselines fortes.
- Interpretabilidade: Por que o modelo previu a chamada A -> B? Entender a causa raiz é fundamental para a ação.
O título “o que o GAT acerta (e erra)” não significa que a GAT seja ruim, mas sim que, como toda ferramenta, ela tem um ponto ideal de aplicação e enfrenta desafios práticos na implementação real.

Conclusão

Modelar o call graph de microserviços como um grafo dinâmico e aplicar GNNs (como a GAT) abre uma nova fronteira para a observabilidade e o monitoramento proativo. A capacidade de prever futuras interações, mesmo com desafios em aberto, é um passo promissor para construir sistemas distribuídos mais resilientes e eficientes.

Referência Principal (O Artigo)
- Khodabandeh, G.; Ezaz, A.; Babaei, M.; Ezzati-Jivan, N. (2025). Utilizing Graph Neural Networks for Effective Link Prediction in Microservice Architectures. arXiv preprint arXiv:2501.15019. Aceito para publicação no Proceedings of the ACM/SPEC International Conference on Performance Engineering (ICPE), 2025. [arXiv:2501.15019]
Referências Fundacionais
- Veličković, P. et al. (2018). Graph Attention Networks (GAT). ICLR 2018.
Sobre o autor

Rener Menezes
Cofundador & CTO — FitBank

Rener Menezes é cofundador e CTO do FitBank, fintech brasileira de Banking-as-a-Service. Com mais de 25 anos de experiência projetando sistemas financeiros em larga escala, é bacharel em Sistemas de Informação e mestrando na Unifor, onde pesquisa Redes Neurais de Grafos e aprendizado por reforço para detecção de fraude. Interesses: sistemas distribuídos, infraestrutura de pagamentos e graph ML.

Links: LinkedIn · ORCID · contato@grafolab.ia.br
GNNs sob Data Drift em Fraude: GraphSAGE é Mais Robusto que GCN/GAT (IEEE-CIS)

outubro 24, 2025
Resumo — Modelos de Machine Learning em produção sofrem um inimigo silencioso: o Data Drift. As características dos dados mudam com o tempo, degradando a performance. Em detecção de fraudes financeiras, esse problema é ainda pior, pois os fraudadores se adaptam constantemente. Neste post, resumimos nossa pesquisa publicada no IEEE Access, onde investigamos a robustez de três arquiteturas populares de GNNs (Graph Convolutional Network – GCN, Graph Attention Network – GAT e GraphSAGE) ao drift natural em um cenário de fraude em larga escala, usando o dataset IEEE-CIS. Adivinha quem resistiu melhor?

1. O Problema: Data Drift, o Inimigo Silencioso da Detecção de Fraude

Imagine que você treinou um modelo GNN de última geração para detectar fraudes em pagamentos. Ele tem uma performance fantástica no dataset de teste. Você o coloca em produção. No primeiro dia, ele funciona bem. No segundo, também. Mas, semanas depois, você percebe que ele está deixando passar mais fraudes e bloqueando mais clientes bons. O que aconteceu?

O Data Drift. As propriedades estatísticas dos dados de entrada (o comportamento dos usuários, as táticas dos fraudadores) mudaram desde que o modelo foi treinado. Em fraude, esse drift é ainda mais agressivo, pois é um ambiente adversarial: os fraudadores estão ativamente tentando enganar seu modelo.

A maioria dos estudos foca em mitigar o drift (com re-treinamento constante, detectores de drift, etc.). Mas antes disso, uma pergunta fundamental precisa ser respondida: Diferentes arquiteturas de GNN têm diferentes níveis de robustez intrínseca ao drift?

É isso que investigamos em nosso artigo. Queríamos medir o quão bem GCN, GAT e GraphSAGE “aguentam o tranco” do drift natural, sem nenhuma ajuda extra.

2. O Campo de Batalha: Dataset IEEE-CIS e o Grafo de Transações

Para testar isso, usamos um cenário realista e desafiador: o dataset IEEE-CIS Fraud Detection, conhecido por seu grande volume, alto desbalanceamento (poucas fraudes) e atributos anonimizados.

Modelamos o problema como um grafo homogêneo, onde cada nó é uma transação. A pergunta era: como conectar essas transações para que a GNN possa aprender padrões relacionais?

Criamos arestas (bidirecionais) entre as transações usando quatro critérios complementares, buscando capturar diferentes tipos de “proximidade”:
1. Similaridade de Atributos: Transações com vetores de features muito parecidos (similaridade de cosseno alta).
2. Proximidade Temporal: Transações que ocorreram muito próximas no tempo (ex: menos de 2 horas de diferença).
3. Pertencer ao Mesmo Cluster: Transações agrupadas juntas por um algoritmo de clustering (MiniBatchKMeans).
4. Padrões Anômalos Compartilhados: Transações com alta similaridade em features que são conhecidas por indicar fraude.
3. Os Competidores: GCN, GAT e GraphSAGE

Com o grafo construído, colocamos três das arquiteturas de GNN mais populares para competir:
- GCN (Graph Convolutional Network): A GNN “clássica”. Agrega informações de toda a vizinhança imediata (1-hop) de um nó, usando uma média ponderada.
- GAT (Graph Attention Network): Uma GNN mais sofisticada que usa “atenção”. Ela aprende a dar pesos diferentes aos vizinhos ao agregar a informação (ex: “o vizinho A é mais importante que o B”). Usamos uma versão robusta com LayerNorm, conexões residuais e dropout.
- GraphSAGE: Projetada para escalar. Em vez de olhar toda a vizinhança (como a GCN), ela amostra um número fixo de vizinhos e usa um agregador (nós usamos a média, mean aggregator) sobre essa amostra. É uma GNN indutiva.
Todas foram implementadas em PyTorch/PyG com 3 camadas e treinadas para classificar se uma transação (nó) era fraude ou não.

4. Preparando a Arena: Pré-processamento e Luta contra o Desbalanceamento

Antes de alimentar as GNNs, um pipeline robusto de pré-processamento foi aplicado aos dados brutos do IEEE-CIS (38 features finais), incluindo tratamento de valores ausentes, encodings e normalização.

O maior desafio, porém, era o desbalanceamento extremo do dataset (apenas ~3.3% de fraudes). Treinar um modelo diretamente nesses dados resultaria em um modelo que ignora as fraudes. Para combater isso durante o treino, usamos uma estratégia de SMOTE (Synthetic Minority Over-sampling Technique) adaptada para grafos. O SMOTE criou “cópias sintéticas” das transações fraudulentas, elevando a taxa de fraude no conjunto de treino para cerca de 15%. Crucialmente, nenhum SMOTE foi usado nos conjuntos de validação, teste ou monitoramento, para avaliar a performance no mundo real.

5. A Corrida Contra o Tempo: Protocolo Temporal e Métricas Cruciais

Para simular o data drift, usamos um protocolo de avaliação estritamente temporal:
1. Dividimos o dataset em blocos de tempo: Treino $\rightarrow$ Validação $\rightarrow$ Teste $\rightarrow$ Monitoramento.
2. O bloco de Monitoramento foi dividido em 50 janelas diárias sequenciais, cada uma com cerca de 3.000 transações.
3. Treinamos cada GNN uma única vez (usando Treino+Validação) e, em seguida, avaliamos sua performance no dataset de Teste e em cada uma das 50 janelas de monitoramento, sem re-treinar.
Quais métricas usamos? Como é comum em cenários de fraude, Acurácia e ROC-AUC são enganosas aqui, pois o desbalanceamento de classes é severo. Focamos em:
- AUC-PR (Area Under the Precision-Recall Curve): A métrica principal para dados desbalanceados.
- F2-Score: Uma variante do F1-Score que dá mais peso ao Recall (pegar as fraudes) do que à Precisão (evitar falsos positivos), o que é desejável em muitos cenários de fraude.
6. Os Resultados: Quem Venceu (e Quem Desgastou)?

A. Performance Inicial (no Test Set, antes do drift):

No dataset de teste (logo após o treino), a GraphSAGE foi a clara vencedora, seguida pela GCN e depois pela GAT:
- GraphSAGE: AUC-PR = 0.9099, F2-Score = 0.8485
- GCN: AUC-PR = 0.8253, F2-Score = 0.8007
- GAT: AUC-PR = 0.6956, F2-Score = 0.7025
(Todas tiveram Recall alto e ROC-AUC acima de 0.97, mas essas métricas escondem as diferenças cruciais na precisão).

B. Robustez sob Data Drift (ao longo das 50 janelas diárias):

Aqui veio a descoberta mais importante. Medimos a degradação da performance da primeira janela de monitoramento (Dia 1) até a última (Dia 50):
- GCN: Sofreu a maior queda. F2 caiu -28.27%, AUC-PR caiu -40.05%.
- GAT: Também sofreu bastante. F2 caiu -24.85%, AUC-PR caiu -37.25%.
- GraphSAGE: Mostrou-se muito mais estável. F2 caiu apenas -8.88%, AUC-PR caiu apenas -9.32%. Mesmo no Dia 50, a GraphSAGE mantinha um AUC-PR acima de 0.88!
7. A Análise: Por que GraphSAGE Resistiu Melhor?

Nossa hipótese para a robustez superior da GraphSAGE está na sua arquitetura:
- Natureza Indutiva e Amostragem: A GraphSAGE não olha para toda a vizinhança. Ela amostra vizinhos. Isso, combinado com o agregador de média (mean aggregator), tende a “suavizar” variações locais e ruídos que podem surgir com o drift. Ela aprende uma função de agregação mais “generalista”.
- GCN: Por agregar toda a vizinhança de 1-hop, a GCN é mais sensível a mudanças na estrutura local do grafo causadas pelo drift.
- GAT: A atenção é poderosa, mas pode ser volátil. Se os padrões que definem a “importância” de um vizinho mudam com o drift, o mecanismo de atenção pode se “confundir”, levando a uma degradação mais acentuada.
8. Lições para o Mundo Real (Implicações Práticas)

Nossa pesquisa tem implicações diretas para quem opera GNNs em produção:
1. A Arquitetura Importa (e Muito!): A escolha da GNN não afeta apenas a performance inicial, mas também sua robustez ao longo do tempo. GraphSAGE (com agregador de média) parece ser uma escolha mais segura em ambientes dinâmicos como fraude.
2. Monitore as Métricas Certas: Use AUC-PR e F-Beta (como F2) para monitorar a performance. A ROC-AUC pode mascarar problemas sérios de degradação na classe minoritária (a fraude).
3. Planeje a Adaptação: Nenhuma GNN é imune ao drift para sempre. Ter uma estratégia de re-treinamento (baseada em janelas de tempo ou gatilhos de drift) e monitoramento contínuo é essencial.
9. Olhando para o Futuro (Limitações e Próximos Passos)

Como toda pesquisa, nosso trabalho tem limitações: usamos um grafo homogêneo (só transações), o drift é específico do IEEE-CIS, e os resultados dependem dos hiperparâmetros escolhidos.

Os próximos passos naturais são:
- Testar GNNs heterogêneas (incluindo nós de Conta, Dispositivo, etc.) e temporais (que modelam o tempo explicitamente).
- Acoplar detectores de drift e estratégias de mitigação ativa (como re-treinamento online).
- Estudar a interpretabilidade: por que o drift afeta cada arquitetura de forma diferente em nível de nó?
Conclusão

O Data Drift é um desafio real e constante na operação de modelos de ML, especialmente em fraude. Nossa pesquisa mostra que a escolha da arquitetura da GNN tem um impacto significativo na sua robustez a essas mudanças. A GraphSAGE, com sua abordagem indutiva e de amostragem, demonstrou ser notavelmente mais estável que a GCN e a GAT no cenário estudado. Isso reforça a necessidade de monitoramento contínuo com as métricas corretas e um planejamento cuidadoso para a adaptação do modelo ao longo do tempo.

Referência Principal (Nosso Artigo)
- Menezes, R. S.; Filho, R. H. (2025). Investigating the Robustness of Graph Neural Networks to Data Drift: A Case Study on Financial Transaction Data. IEEE Access, vol. 13, pp. 164302-164312, 2025, doi: 10.1109/ACCESS.2025.3611817. (Publicado em 18 de Setembro de 2025).
Referências Fundacionais (GNNs)
- Kipf, T. N., & Welling, M. (2016). Semi-Supervised Classification with Graph Convolutional Networks. arXiv.
- Veličković, P. et al. (2018). Graph Attention Networks (GAT). ICLR 2018.
- Hamilton, W., Ying, Z., & Leskovec, J. (2017). Inductive Representation Learning on Large Graphs (GraphSAGE). NeurIPS 2017.
Sobre o autor

Rener Menezes
Cofundador & CTO — FitBank

Rener Menezes é cofundador e CTO do FitBank, fintech brasileira de Banking-as-a-Service. Com mais de 25 anos de experiência projetando sistemas financeiros em larga escala, é bacharel em Sistemas de Informação e mestrando na Unifor, onde pesquisa Redes Neurais de Grafos e aprendizado por reforço para detecção de fraude. Interesses: sistemas distribuídos, infraestrutura de pagamentos e graph ML.

Links: LinkedIn · ORCID · contato@grafolab.ia.br
Bancos de Grafos 101: Neo4j, Memgraph, Neptune e ArangoDB na Prática

outubro 23, 2025
Resumo — Você modelou seu problema como um grafo. E agora? Onde você armazena e consulta essa rede complexa? Um banco SQL tradicional falha miseravelmente em consultas de “amigo do amigo”. É aqui que entram os Bancos de Dados de Grafos nativos. Mas a escolha não é única. A decisão entre Neo4j, Memgraph, Amazon Neptune ou ArangoDB depende de uma pergunta-chave: qual é o seu modelo de dados, sua necessidade de escala e sua exigência de latência?

1. Por que não usar um Banco de Dados Relacional (SQL)?

A primeira pergunta é sempre: “Eu já tenho um PostgreSQL/MySQL, por que preciso de outro banco?”

A resposta está na natureza da consulta. Em um banco SQL, para encontrar “amigos de amigos” (uma consulta de 2 saltos), você precisa fazer um JOIN da tabela de usuários com ela mesma. Para encontrar amigos de 3 saltos, você precisa de outro JOIN. Para 4 saltos, outro JOIN. Isso fica exponencialmente lento.

Um banco de dados de grafo nativo não armazena dados em tabelas, mas sim como nós e arestas. A consulta “amigo do amigo do amigo” é trivial e extremamente rápida, pois o banco foi projetado para “caminhar” por essas conexões.

2. As Duas Grandes Filosofias: Property Graph vs. RDF

Antes de escolher um produto, você precisa entender as duas formas principais de se modelar um grafo:

1. O Modelo de Grafo de Propriedades (Property Graph) Esta é a abordagem mais intuitiva e popular para aplicações de ML e análise de dados. Pense nela como um diagrama em um quadro branco:
- Nós: Têm rótulos (ex: Pessoa, Empresa) e propriedades (ex: {nome: "Rener", idade: 30}).
- Arestas: Têm um tipo (ex: TRABALHA_EM), direção (seta) e também podem ter propriedades (ex: {cargo: "CTO", desde: 2020}).
É o modelo usado por Neo4j, Memgraph e ArangoDB. A linguagem de consulta mais comum é o Cypher (ou openCypher), que é muito declarativa e se parece com “arte ASCII”.

Exemplo de Cypher (encontre colegas de trabalho): MATCH (p1:Pessoa {nome: "Rener"})-[:TRABALHA_EM]->(e:Empresa)<-[:TRABALHA_EM]-(p2:Pessoa) RETURN p2.nome

2. O Modelo RDF (Triplestore) Esta é a abordagem padrão da “Web Semântica” e de dados ligados (Linked Data). O RDF não pensa em “objetos”, mas sim em “fatos”, chamados de triplas:
- (Sujeito, Predicado, Objeto)
- Ex: (Rener, é_um, Engenheiro), (Rener, trabalha_em, GrafoLab), (GrafoLab, é_um, Blog).
É um modelo muito poderoso para integração de dados heterogêneos e inferência lógica. É o modelo usado pelo Amazon Neptune (junto com o Property Graph) e Blazegraph. A linguagem de consulta é o SPARQL.

Regra de bolso: Para a maioria das aplicações de detecção de fraude, recomendação e análise de rede social, o modelo Property Graph é o mais intuitivo e comumente usado.

3. Os Contendores: Uma Comparação Prática

Qual banco escolher? Depende do seu caso de uso:
- Neo4j: O Líder Maduro
  - Modelo: Property Graph (líder, criou o Cypher).
  - Força: Ecossistema imenso, estabilidade comprovada, documentação fantástica e a biblioteca de algoritmos APOC (Awesome Procedures on Cypher). É o “padrão de mercado” para a maioria das aplicações OLTP (transacionais).
  - Ideal para: Aplicações de propósito geral onde a maturidade, o suporte da comunidade e um ecossistema rico são importantes.
- Memgraph: O Foco em Tempo Real (Streaming)
  - Modelo: Property Graph (compatível com openCypher/Neo4j).
  - Força: É um banco in-memory (reside na RAM). Isso o torna absurdamente rápido, projetado desde o início para consumir dados de streaming (como Kafka) e rodar análises de grafo em tempo real.
  - Ideal para: Detecção de fraude no exato momento da transação, IoT e qualquer caso de uso que exija latência de milissegundos sobre dados que acabaram de chegar.
- Amazon Neptune (AWS): O Gerenciado Multi-Modelo
  - Modelo: Suporta ambos, Property Graph (com Cypher) e RDF (com SPARQL).
  - Força: É um serviço totalmente gerenciado pela AWS. Você não se preocupa com infraestrutura, backups ou escalabilidade (ela é elástica).
  - Ideal para: Empresas que já estão profundamente integradas ao ecossistema AWS e que precisam de uma solução de grafo “sem dor de cabeça” operacional.
- ArangoDB: O “Multi-Modelo”
  - Modelo: É um banco de dados “multi-modelo” nativo.
  - Força: Seus dados podem ser armazenados e consultados como Documentos (JSON, como o MongoDB), Pares Chave/Valor E Grafos, tudo no mesmo banco e na mesma consulta.
  - Ideal para: Casos de uso onde seus dados têm “formas” diferentes e você não quer manter dois ou três bancos de dados separados.
4. Onde Usamos Isso? (Conectando os Pontos)

Os bancos de grafos são a infraestrutura que torna possíveis os posts anteriores do GrafoLab:
- Recomendação: (Veja PinSage ou Amazon) Permite armazenar o grafo (Item)-[:SIMILAR_A]-(Item) ou (Usuário)-[:COMPROU]-(Item).
- Grafos de Conhecimento (KGs): (Veja nosso post sobre GraphRAG) São a base para armazenar as entidades e relações que alimentam os LLMs.
- Análise de Redes Sociais: (Veja LinkedIn) Permite consultas (amigo-de-amigo) em escala.
5. Armadilhas Comuns de Operação (Pitfalls)

Um banco de grafos não é uma bala de prata. Operá-lo em produção tem armadilhas:
1. Misturar OLTP vs. OLAP: Esta é a armadilha mais comum. Não rode sua consulta analítica (OLAP) de 30 minutos (ex: “Calcular PageRank em 50 milhões de nós”) no mesmo cluster que está servindo seu aplicativo em tempo real (OLTP) (ex: “Mostrar amigos do usuário em 10ms”). Um vai matar a performance do outro.
2. Modelagem de Dados Ruim: Performance em grafos depende totalmente da modelagem. Você usou Rótulos (Labels) corretos nos nós? Você criou Índices nas propriedades que você mais busca (ex: CPF, email)?
3. Consultas “Chatty” (N+1): A praga do desenvolvedor que não sabe Cypher. Em vez de uma única consulta de grafo que traz o que você quer, o código faz:
  - Consulta 1: Traz o usuário (1 query).
  - Consulta 2: Traz os 50 amigos dele (1 query).
  - Consultas 3-52: Faz um loop e uma nova query para cada um dos 50 amigos (50 queries). Isso é chamado de N+1 e destrói a performance. O Cypher (ou SPARQL) foi feito para evitar isso.
Conclusão

A escolha do banco de grafos correto não é sobre “qual é o melhor”, mas sobre “qual é o certo para o seu problema“. A decisão depende do seu modelo (Property Graph é o mais comum), da sua necessidade de latência (Memgraph para tempo real) e do seu ecossistema (Neptune para AWS).

Referências

Para bancos de dados, as fontes mais canônicas são as documentações oficiais e white papers técnicos, pois as implementações mudam rapidamente.
Sobre o autor

Rener Menezes
Cofundador & CTO — FitBank

Rener Menezes é cofundador e CTO do FitBank, fintech brasileira de Banking-as-a-Service. Com mais de 25 anos de experiência projetando sistemas financeiros em larga escala, é bacharel em Sistemas de Informação e mestrando na Unifor, onde pesquisa Redes Neurais de Grafos e aprendizado por reforço para detecção de fraude. Interesses: sistemas distribuídos, infraestrutura de pagamentos e graph ML.

Links: LinkedIn · ORCID · contato@grafolab.ia.br
Detecção de Comunidades: Louvain, Leiden e Aplicações que Importam

outubro 22, 2025
Resumo — Um grafo não é apenas um “emaranhado” de nós. Quase sempre, ele possui uma “estrutura média” (meso-estrutura): grupos de nós que são mais densamente conectados entre si do que com o resto da rede. Encontrar esses “bairros” ou “clusters” é o trabalho da Detecção de Comunidades. Algoritmos como Louvain e seu sucessor, Leiden, são as ferramentas padrão da indústria para isso, permitindo-nos encontrar grupos em redes de bilhões de arestas de forma eficiente.

1. O Que é uma “Boa” Comunidade? A Ideia da Modularidade

Como sabemos que uma divisão de um grafo em grupos é “boa”?

Imagine uma rede de amigos. Uma divisão “boa” colocaria amigos que se conhecem muito no mesmo grupo. Uma divisão “ruim” os separaria, ou colocaria estranhos juntos.

A métrica mais popular para medir a “qualidade” dessa divisão é a Modularidade (Q).

A Intuição: A Modularidade é um score (geralmente entre -0.5 e 1.0) que compara a densidade de conexões dentro das comunidades que encontramos com a densidade que esperaríamos ter se as conexões fossem totalmente aleatórias.
- Q > 0 (Positivo): Bom! Nossos grupos têm significativamente mais conexões internas do que o acaso. Encontramos uma estrutura real.
- Q ≈ 0 (Zero): Ruim. Nossos grupos não são melhores do que uma divisão aleatória.
- Q < 0 (Negativo): Péssimo. Nossos grupos são menos conectados internamente do que o acaso.
O “trabalho” de um algoritmo de detecção de comunidades é, portanto, encontrar a divisão de nós (a “partição”) que maximiza o score de Modularidade Q.

2. Os Algoritmos de Otimização: Louvain vs. Leiden

Encontrar a Modularidade perfeita em um grafo grande é um problema computacionalmente intratável (NP-hard). Por isso, usamos heurísticas rápidas e “gulosas” (greedy) para encontrar uma solução muito boa de forma eficiente. As duas mais famosas são Louvain e Leiden.

A. O Clássico: Método de Louvain (Blondel et al., 2008)

O Louvain é talvez o algoritmo de comunidade mais famoso por uma razão: ele é extremamente rápido e escala para grafos massivos. Ele funciona em duas fases repetitivas:
1. Fase 1 (Otimização Local): Para cada nó, o algoritmo testa “movê-lo” para a comunidade de cada um de seus vizinhos. Ele move o nó para a comunidade que resulta no maior ganho local de modularidade. Isso é repetido para todos os nós até que nenhum movimento melhore a modularidade.
2. Fase 2 (Agregação): O algoritmo “contrai” o grafo. Todos os nós que terminaram na mesma comunidade são fundidos em um único “super-nó”. As arestas entre as comunidades são somadas.
O algoritmo então repete a Fase 1 e 2 no novo grafo agregado. Isso continua até que apenas um único super-nó permaneça, revelando uma hierarquia de comunidades.

A Armadilha do Louvain: Apesar de rápido, o Louvain tem uma falha documentada. Por ser “guloso” e focar apenas no ganho local, ele pode, às vezes, criar “comunidades” que são, na verdade, mal conectadas internamente. É possível que ele junte dois grupos que estão ligados apenas por uma ou duas arestas fracas, criando partições que não fazem sentido prático.

B. O Sucessor: Algoritmo de Leiden (Traag et al., 2019)

O Leiden é um sucessor direto do Louvain, projetado especificamente para corrigir sua maior falha.

Ele usa a mesma ideia de otimização local (Fase 1) e agregação (Fase 2), mas adiciona uma etapa de refinamento inteligente. Após mover um nó para uma nova comunidade, o Leiden verifica se essa comunidade ainda é bem conectada internamente. Ele pode “quebrar” comunidades que o Louvain teria deixado unidas, garantindo que todos os grupos resultantes sejam coesos.

Resultado: O Leiden não é apenas mais rápido que o Louvain em implementações modernas, mas também produz partições de melhor qualidade (maior modularidade) e com a garantia de que as comunidades são bem conectadas.

3. Onde Usar Isso na Prática?

Encontrar grupos coesos é útil em quase todas as áreas:
- Redes Sociais: Encontrar clusters temáticos, grupos de afinidade ou “bolhas” políticas.
- Recomendação: No grafo de Produto $\leftrightarrow$ Produto (como o da Amazon), comunidades representam “categorias” de produtos que são frequentemente comprados juntos (ex: “itens de churrasco”, “literatura de ficção científica”).
- Detecção de Fraude: Fraudadores frequentemente formam “conluios” ou anéis. No grafo de transações, esses grupos aparecem como comunidades pequenas, densas e muitas vezes estranhamente isoladas do resto do grafo “saudável”.
4. Armadilhas e Configurações (O “Cuidado”)

Usar esses algoritmos não é só apertar um botão. Você precisa estar ciente de duas coisas:
1. O Parâmetro de Resolução ( $\gamma$ ): A Modularidade tem um “limite de resolução”: ela naturalmente favorece comunidades de um certo tamanho e pode “esconder” comunidades menores, mesmo que sejam óbvias. Para contornar isso, usamos um parâmetro de resolução ( $\gamma$ ):
  - : Aumenta o “zoom”. Encontra comunidades menores e mais granulares.
  - $\gamma < 1.0$ : Diminui o “zoom”. Encontra comunidades maiores e mais abrangentes. Escolher o $\gamma$ correto é crucial para a sua análise.
2. Interpretação: Um algoritmo de comunidade é uma ferramenta matemática. Ele sempre vai encontrar grupos, mesmo em um grafo totalmente aleatório. Uma comunidade não é um “tema” até que você a valide. Após rodar o algoritmo, você precisa inspecionar os nós dentro do grupo para entender o que eles têm em comum (ex: “Ah, 90% dos nós na Comunidade 5 são fãs de esporte”).
Conclusão

A Detecção de Comunidades é a ferramenta que nos permite ver a “floresta” (os clusters) em vez de apenas as “árvores” (os nós). Algoritmos como Louvain e, especialmente, Leiden, nos dão uma forma escalável e robusta de transformar um grafo caótico em um mapa organizado de “bairros”, revelando a estrutura oculta que impulsiona o comportamento da rede.

Referências
- Blondel, V. D., Guillaume, J.-L., Lambiotte, R., & Lefebvre, E. (2008). Fast unfolding of communities in large networks. Journal of Statistical Mechanics: Theory and Experiment.
- Traag, V. A., Waltman, L., & van Eck, N. J. (2019). From Louvain to Leiden: guaranteeing well-connected communities. Scientific Reports.
- Fortunato, S. (2010). Community detection in graphs. Physics Reports. (O survey clássico e mais citado sobre o tema).
Sobre o autor

Rener Menezes
Cofundador & CTO — FitBank

Rener Menezes é cofundador e CTO do FitBank, fintech brasileira de Banking-as-a-Service. Com mais de 25 anos de experiência projetando sistemas financeiros em larga escala, é bacharel em Sistemas de Informação e mestrando na Unifor, onde pesquisa Redes Neurais de Grafos e aprendizado por reforço para detecção de fraude. Interesses: sistemas distribuídos, infraestrutura de pagamentos e graph ML.

Links: LinkedIn · ORCID · contato@grafolab.ia.br

Centralidade em Grafos: O que é “Importância”? (Grau, Betweenness e PageRank)

outubro 22, 2025

Diagrama comparativo de centralidade. Quatro painéis mostram o mesmo grafo, cada um destacando um nó diferente: 'Grau' (o hub mais conectado), 'Betweenness' (a ponte entre clusters), 'Closeness' (os nós centrais) e 'PageRank' (o hub influente).

Resumo — O que torna um nó “importante” em um grafo? A resposta não é única. Depende do que você quer medir. Um nó pode ser popular (alto Grau), ser uma “ponte” crítica (alta Betweenness) ou ter “influência” recursiva (alto PageRank). Escolher a métrica errada de centralidade pode levar a decisões de negócio desastrosas. Este post é um guia fundamental sobre as principais medidas de centralidade e, o mais importante, quando usar cada uma.

1. “Importância” é Relativa

Em análise de redes, “centralidade” é a palavra técnica para “importância”. Mas assim como no mundo real, a importância pode significar coisas diferentes:

O influencer com mais seguidores é importante? (Sim, Grau).
A pessoa quieta que conecta dois departamentos que não se falam é importante? (Sim, Betweenness).
A pessoa que é amiga de outras pessoas importantes é importante? (Sim, PageRank).

Vamos quebrar as quatro medidas de centralidade mais essenciais.

2. As Quatro Medidas de Centralidade Essenciais

A. Grau (Degree Centrality)

A Intuição: A medida mais simples de “popularidade”. É, literalmente, a contagem de conexões (arestas) que um nó possui.

O Conceito Técnico: É uma medida puramente local. O nó não sabe nada sobre o resto do grafo, apenas sobre seus vizinhos imediatos. Em grafos dirigidos (como o Twitter), ela se divide em:

In-Degree (Grau de Entrada): Quantas arestas apontam para o nó. (ex: Quantos seguidores você tem).
Out-Degree (Grau de Saída): Quantas arestas saem do nó. (ex: Quantas pessoas você segue).

Quando usar: Para encontrar “hubs” locais e identificar popularidade imediata. É rápido, barato e ótimo como um primeiro filtro.

B. Betweenness (Centralidade de Intermediação)

A Intuição: Esta medida não se importa com quantas conexões você tem. Ela mede o quanto você atua como uma “ponte” entre outros nós. Se você é a única conexão entre dois grandes grupos de amigos, você tem alta betweenness. Remover você “quebraria” o grafo.

O Conceito Técnico: A Betweenness Centrality de um nó é a contagem de quantas vezes ele aparece nos caminhos mais curtos (shortest paths) entre todos os outros pares de nós na rede. É uma medida de “gargalo” ou “fluxo de informação”.

Quando usar: Para encontrar pontos únicos de falha, gargalos de comunicação, ou mediadores críticos em uma rede (ex: em detecção de fraude, o “laranja” que conecta vários esquemas).

C. Closeness (Centralidade de Proximidade)

A Intuição: Mede quão “rápido” um nó consegue alcançar todos os outros nós na rede. Um nó com alta closeness é um bom “centro de transmissão”, pois a informação que sai dele se espalha rapidamente para todo mundo.

O Conceito Técnico: É o inverso da soma da distância de um nó para todos os outros nós.

Armadilha: A closeness tradicional quebra em grafos desconexos (pois a distância para um componente separado é infinita). Por isso, na prática, quase sempre usamos a Closeness Harmônica, que lida bem com grafos desconexos.

Quando usar: Para identificar os melhores “difusores” de informação em uma rede conectada (ex: escolher o “paciente zero” ideal para uma campanha de marketing viral).

D. PageRank (Centralidade de Importância Recursiva)

A Intuição: A ideia genial de que “não é sobre quantos amigos você tem, é sobre quem são seus amigos”. Ter uma conexão de uma pessoa muito importante (um nó de alto score) vale mais do que 10 conexões de nós irrelevantes. É uma medida de “influência” ou “autoridade”.

O Conceito Técnico: O PageRank (como vimos em detalhes no nosso post sobre o Google) é uma variante da Centralidade de Eigenvector. Ele calcula a importância de forma recursiva. A grande sacada do PageRank é adicionar o “fator de teleporte” (controlado por , geralmente 0.85), que impede o algoritmo de ficar “preso” em ciclos e garante que ele sempre convirja para uma solução estável.

Quando usar: Para encontrar a “autoridade” ou “influência” global em um grafo dirigido (ex: rankear páginas na web, artigos científicos por citação, ou contas mais influentes no Twitter).

3. Tabela Resumo: Quando Usar Cada Métrica

Métrica	Pergunta que Responde	Exemplo de Caso de Uso
Grau (Degree)	Quem é o mais popular localmente?	Identificar o “influenciador” mais visível (com mais seguidores).
Betweenness	Quem é a ponte ou gargalo mais crítico?	Encontrar o intermediário (“laranja”) em uma rede de lavagem de dinheiro.
Closeness	Quem consegue espalhar informação mais rápido?	Escolher o ponto de partida ideal para uma campanha de marketing viral.
PageRank	Quem é a autoridade ou influenciador global?	Rankear páginas na web (Google) ou artigos científicos (citações).

4. Armadilhas de Engenharia: Custo e Aproximações

Não podemos simplesmente rodar todas as métricas em qualquer grafo. Elas têm custos computacionais drasticamente diferentes:

Grau: É extremamente barata de calcular (complexidade $O(E)$ ou $O(N)$ `, dependendo da representação).
PageRank: É rápida. Usa o método de power iteration, que converge em poucas passadas e escala muito bem.
Closeness (Harmônica): É cara. Ela requer o cálculo dos caminhos mais curtos de cada nó para todos os outros (ex: rodando um BFS a partir de cada nó), o que em grafos não ponderados tem complexidade de .
Betweenness: É extremamente cara. O cálculo exato tem complexidade de (Nós vezes Arestas) ou pior.

Regra de bolso: Nunca rode Betweenness ou Closeness exata em um grafo com mais de algumas dezenas de milhares de nós. Em grafos grandes (milhões/bilhões de nós), usamos aproximações, que estimam os scores “amostrando” um subconjunto de nós ou caminhos, em vez de calcular todos eles.

Conclusão

“Importância” não é um conceito único. Escolher a métrica de centralidade errada pode levar a conclusões erradas. Antes de calcular, pergunte-se: estou procurando a popularidade local (Grau), o gargalo (Betweenness), o difusor rápido (Closeness) ou a autoridade recursiva (PageRank)? A resposta a essa pergunta definirá o sucesso da sua análise de rede.

Referências

Freeman, L. C. (1977). A set of measures of centrality based on betweenness. Sociometry.
Bonacich, P. (1987). Power and centrality: A family of measures. American Journal of Sociology.
Brin, S., & Page, L. (1998). The Anatomy of a Large-Scale Hypertextual Web Search Engine. Proc. WWW.
Newman, M. E. J. (2018). Networks. Oxford University Press. (Um livro-texto fundamental sobre o assunto).

Sobre o autor

Rener Menezes
Cofundador & CTO — FitBank

Rener Menezes é cofundador e CTO do FitBank, fintech brasileira de Banking-as-a-Service. Com mais de 25 anos de experiência projetando sistemas financeiros em larga escala, é bacharel em Sistemas de Informação e mestrando na Unifor, onde pesquisa Redes Neurais de Grafos e aprendizado por reforço para detecção de fraude. Interesses: sistemas distribuídos, infraestrutura de pagamentos e graph ML.

Links: LinkedIn · ORCID · contato@grafolab.ia.br

Fraude em Pagamentos com Grafos: Do Link Prediction às GNNs em Produção

outubro 21, 2025
Resumo — Fraudadores não agem sozinhos. Eles operam em redes, usando um emaranhado de contas, cartões, dispositivos e e-mails para esconder suas trilhas. Modelos de ML tradicionais, que olham para transações de forma isolada, falham em ver a “conspiração”. A detecção de fraudes moderna é um problema de grafos. Este post explica como modelamos o ecossistema de pagamentos como um grafo heterogêneo e como evoluímos de heurísticas simples para GNNs (Graph Neural Networks) para encontrar os padrões que os fraudadores tentam esconder.

1. O Problema: Fraude é um Problema de Rede

Por que a detecção de fraudes é um problema de grafos? Porque a fraude é relacional. Um modelo tradicional pode ver uma transação e dizer: “O valor é baixo, o local é comum, o produto é normal. Parece legítimo.”

Esse modelo perde o contexto crucial:
- O cartão usado nessa transação foi usado em 30 dispositivos diferentes na última hora.
- O dispositivo usado nessa transação está ligado a 50 contas recém-criadas.
- O e-mail da conta está conectado a 10 cartões que já foram reportados como roubados.
Isoladamente, cada entidade parece normal. Conectadas, elas formam um “bairro ruim” digital. A única forma de ver isso é modelando o problema como um grafo heterogêneo.

Nesse grafo, temos diferentes tipos de nós e arestas:
- Nós (Entidades): Conta, Cartão, CPF/CNPJ, Dispositivo (device ID), Endereço IP, E-mail, Telefone, Merchant (Lojista).
- Arestas (Relações): transaciona (conta $\rightarrow$ merchant), usa (conta $\rightarrow$ dispositivo), pertence (cartão $\rightarrow$ conta), compartilha (dispositivo $\rightarrow$ IP).
As arestas são temporais: elas possuem um timestamp (carimbo de tempo) de quando a relação ocorreu, o que é fundamental para a análise.

2. O Ponto de Partida: Baselines Fortes (Antes das GNNs)

Antes de pular para o deep learning, é crucial estabelecer baselines (pontos de comparação). Muitas vezes, heurísticas de grafos simples já capturam 80% do problema:
1. Heurísticas de Vizinhança (Features de Grafo): A forma mais simples de usar o grafo é criar features para um modelo tabular (como um XGBoost). Respondemos perguntas como:
  - Quantos cartões usaram este Dispositivo nos últimos 7 dias?
  - Quantos IPs únicos esta Conta usou nas últimas 24 horas?
  - Qual o valor médio transacionado pelos outros dispositivos que compartilharam o IP desta conta? (agregação k-hop)
2. Personalized PageRank (PPR): Como vimos no post sobre o Twitter, o PPR é um algoritmo de “proximidade”. Em fraudes, nós o usamos para medir a “culpa por associação”:
  - Começamos com um conjunto de nós “sementes” (fraudes já confirmadas).
  - Rodamos um PPR a partir desses nós.
  - O resultado é um score para todos os outros nós do grafo (contas, dispositivos, IPs) que mede sua “proximidade” com fraudes conhecidas. Esse score é uma feature incrivelmente poderosa.
3. A Revolução das GNNs: Aprendendo Padrões Complexos

As heurísticas são poderosas, mas são manuais. Nós, humanos, temos que pensar na regra (“quantos cartões por dispositivo?”).

E se um modelo de ML pudesse aprender sozinho qual é o padrão de uma fraude? E se ele aprendesse que o padrão perigoso não é “50 cartões em 1 dispositivo”, mas sim “um dispositivo conectado a 3 contas novas, que usaram 5 cartões diferentes, que transacionaram em 10 merchants que nunca foram vistos antes”?

Isso é o que as Graph Neural Networks (GNNs) fazem.

Uma GNN (como a GraphSAGE ou LightGCN) aprende um embedding (um vetor “DNA”) para cada nó, baseado na agregação das informações de sua vizinhança. Para grafos heterogêneos como o de pagamentos, arquiteturas como R-GCN ou HAN são usadas, pois elas aprendem pesos diferentes para tipos de arestas diferentes (ex: a GNN aprende que uma aresta compartilha_dispositivo é 10x mais suspeita que uma aresta usa_mesmo_merchant).

O modelo pode ser treinado para duas tarefas:
- Classificação de Nós: O nó Conta XYZ é fraudulento?
- Classificação de Arestas: A Transação ABC é fraudulenta?
4. A Métrica que Importa: AUPRC (Não se Engane com a Acurácia)

Este é o ponto mais crítico na avaliação de um modelo de fraude: o desbalanceamento de classes é severo. Em um sistema de pagamentos saudável, a esmagadora maioria das transações (muitas vezes 97%, 99%, ou mais, dependendo do contexto) são legítimas.

Se você criar um modelo que simplesmente diz “tudo é legítimo”, ele terá uma acurácia altíssima (97%-99%+), mas será 100% inútil.

Em cenários assim, a Acurácia e a ROC-AUC são métricas enganosas. A métrica que realmente importa é a AUPRC (Area Under the Precision-Recall Curve), ou “Área sob a Curva de Precisão-Recall”.
- Recall: De todas as fraudes reais que aconteceram, quantas o seu modelo conseguiu pegar?
- Precision (Precisão): De todas as transações que o seu modelo marcou como fraude, quantas eram realmente fraude?
Há um trade-off: para pegar mais fraudes (aumentar o Recall), você inevitavelmente vai bloquear mais transações legítimas (diminuir a Precisão), o que irrita bons clientes. O AUPRC mede a qualidade desse trade-off. O objetivo de negócio é encontrar o “ponto de equilíbrio” (limiar de score) que maximize a detecção de fraude (Recall) ao mesmo tempo que minimiza o impacto em clientes legítimos (a Taxa de Falsos Positivos, ou FPR).

5. Armadilhas de Produção: Vazamento de Dados e Drift

Colocar um modelo de grafos em produção para fraudes é um campo minado. As duas maiores armadilhas são:
1. Vazamento de Dados (Leakage): É o erro mais fácil de cometer.
  - Vazamento Temporal: Você não pode treinar seu modelo com dados do futuro. A separação treino/validação/teste deve ser feita por tempo (ex: treinar com Janeiro-Março, validar com Abril, testar com Maio).
  - Vazamento de Vizinhança: Se uma transação de teste em Maio compartilha o mesmo dispositivo que uma transação de treino em Janeiro (que era fraude), o modelo “vê” a resposta. Você deve garantir que seus conjuntos de treino e teste sejam separados não apenas por tempo, mas também por “componentes” do grafo.
2. Drift (Mudança de Padrão): Os fraudadores não dormem. O padrão de fraude que seu modelo aprendeu em Maio será diferente do padrão de Julho. Os fraudadores se adaptam.
  - Solução: Re-treinamento constante (diário ou semanal), monitoramento de data drift (as features de entrada estão mudando?) e model drift (a performance do modelo está caindo?).
Conclusão

Grafos não são apenas “mais uma ferramenta” para detecção de fraudes; eles são a representação correta do problema. A fraude é um fenômeno de rede. Ao modelar o problema como um grafo heterogêneo e temporal, podemos usar desde heurísticas simples e poderosas (como PPR) até arquiteturas de GNNs sofisticadas para encontrar os padrões de “culpa por associação” que os fraudadores tentam esconder.

Referências

Surveys (Visão Geral):
- Liu, Z. et al. (2021). Graph Neural Networks for Anomaly Detection in Financial Networks. arXiv:2108.06798. (Um survey focado em GNNs para redes financeiras).
- Zha, D. et al. (2020). Data Mining for Financial Fraud Detection: A Survey. arXiv:2008.09459. (Uma visão geral mais ampla das técnicas de mineração de dados para fraude).
Arquitetura, Métricas e Prática:
- (GNNs na Indústria): NVIDIA Technical Blog (2025). Supercharging Fraud Detection in Financial Services with Graph Neural Networks. (Um excelente post técnico que discute a combinação de GNNs com XGBoost para fraude, muito alinhado com a prática da indústria).
- (AUPRC e Desbalanceamento): Hancock, J. T., & Filar, J. (2023). Evaluating classifier performance with highly imbalanced Big Data. Journal of Big Data. (Uma referência acadêmica crucial que valida por que o AUPRC é uma métrica superior ao ROC-AUC em cenários de fraude).
- (Exemplo de Arquitetura GNN): Tang, J. et al. (2022). Rethinking Graph Neural Networks for Anomaly Detection. ICML 2022. (Um paper que analisa por que certas arquiteturas de GNN funcionam para detecção de anomalias).
Sobre o autor

Rener Menezes
Cofundador & CTO — FitBank

Rener Menezes é cofundador e CTO do FitBank, fintech brasileira de Banking-as-a-Service. Com mais de 25 anos de experiência projetando sistemas financeiros em larga escala, é bacharel em Sistemas de Informação e mestrando na Unifor, onde pesquisa Redes Neurais de Grafos e aprendizado por reforço para detecção de fraude. Interesses: sistemas distribuídos, infraestrutura de pagamentos e graph ML.

Links: LinkedIn · ORCID · contato@grafolab.ia.br

Graph Embeddings 101: DeepWalk e Node2Vec vs. GNNs

outubro 20, 2025

Comparativo de embeddings de grafo. À esquerda (DeepWalk/Node2Vec), 'random walks' (trilhas de luz) exploram o grafo para gerar um embedding. À direita (GNN), vizinhos imediatos enviam 'mensagens' (setas) para um nó central para 'agregar' um embedding.

Resumo — Como transformamos um grafo complexo em números que um modelo de Machine Learning possa entender? A resposta é Graph Embeddings: a criação de um “DNA” numérico (um vetor) para cada nó da rede. Existem duas filosofias principais para isso: a “clássica”, baseada em caminhadas aleatórias (como DeepWalk e Node2Vec), e a “moderna”, baseada em agregação de mensagens (GNNs). Este post explica a intuição por trás de cada uma e, o mais importante, quando usar cada uma.

1. O Que é um Graph Embedding e Por Que Precisamos Dele?

Um grafo é uma estrutura de conexões. Um modelo de ML (como um classificador ou um sistema de recomendação) não entende “conexões”; ele entende números. Um embedding é a tradução.

É um vetor de números (ex: [0.2, -0.9, 0.5, ... 0.1]) que captura a “posição” e o “papel” de um nó no grafo. Nós que são “similares” no grafo devem ter vetores de embedding similares.

Uma vez que temos esses embeddings, podemos usá-los para tarefas como:

Link Prediction: Prever se dois nós deveriam ter uma aresta (ex: “Você conhece o Fulano?”).
Classificação de Nós: Rotular um nó (ex: “Este usuário é um bot ou um humano?”).
Visualização: Encontrar clusters e comunidades na rede.

A grande questão é: como calcular esses vetores?

2. Método 1: Aprender “Andando” (DeepWalk & Node2Vec)

A primeira família de algoritmos se baseia em uma intuição poderosa: “Diga-me com quem andas, e te direi quem és.”

Para entender um nó, esses métodos simulam “passeios aleatórios” (random walks) que começam nele, como um andarilho pulando de nó em nó. A sequência de nós visitados (ex: Nó A -> Nó C -> Nó F -> Nó B) é tratada como uma “frase” que descreve o ponto de partida.

DeepWalk (Perozzi et al., 2014)

O DeepWalk foi o pioneiro. Sua ideia foi uma genial “reciclagem” de uma técnica de NLP (Processamento de Linguagem Natural):

Faça Passeios: A partir de cada nó, gere milhares de random walks curtos.
Use Word2Vec: Trate esses passeios como se fossem frases e os nós como se fossem palavras.
Treine o Skip-gram: Use o algoritmo Skip-gram (do Word2Vec) para aprender os embeddings. O Skip-gram é treinado para prever as “palavras de contexto” (nós vizinhos no passeio) dado um nó central.

O resultado? Nós que aparecem frequentemente nos mesmos “passeios” (ou seja, são estruturalmente próximos) acabarão com vetores de embedding muito similares.

Node2Vec (Grover & Leskovec, 2016)

O Node2Vec refinou essa ideia. Ele argumentou que “passeios aleatórios” puros são muito simples. O Node2Vec introduziu “passeios enviesados” (biased random walks), controlados por dois parâmetros:

(Return parameter): Controla a chance de o passeio “voltar” para o nó que acabou de visitar. Um alto incentiva o passeio a explorar novos territórios.
(In-out parameter): Controla a chance de o passeio ir para longe (DFS-like) ou ficar na vizinhança local (BFS-like).

Ao ajustar e , o Node2Vec permite ao pesquisador escolher se quer embeddings que capturem homofilia (quem são seus vizinhos imediatos, tipo BFS) ou similaridade estrutural (quem tem o mesmo “papel” na rede que você, como ser uma “ponte” entre comunidades, tipo DFS).

3. Método 2: Aprender “Agregando” (GNNs)

A segunda família de algoritmos, as Graph Neural Networks (GNNs), tem uma filosofia diferente. Em vez de “andar”, ela se baseia na intuição: “Diga-me o que seus vizinhos dizem.”

Uma GNN aprende o embedding de um nó através de um processo de agregação de mensagens (message passing). Em cada “camada” da GNN, o embedding de um nó é atualizado com base em duas coisas:

O embedding atual do próprio nó.
Uma “agregação” das mensagens (embeddings) de seus vizinhos imediatos.

Arquiteturas famosas de GNN fazem isso de formas diferentes:

GCN (Graph Convolutional Network): Agrega os vizinhos usando uma “média normalizada”. É simples e eficaz.
GraphSAGE (Hamilton et al., 2017): Pode usar agregadores mais complexos, como um max-pooling ou um LSTM, e é projetado para escalar massivamente.
GAT (Graph Attention Network): Usa um mecanismo de “atenção” para dar pesos diferentes a vizinhos diferentes (ex: o “vizinho A” é mais importante que o “vizinho B” para definir quem eu sou).

A maior vantagem das GNNs é que elas podem naturalmente incorporar features (atributos) dos nós. O embedding final de um nó não é apenas sua posição na rede, mas uma combinação de sua posição E seus atributos (ex: idade, foto de perfil, texto, etc.).

4. O Duelo: Quando Usar Cada Abordagem?

Não existe “bala de prata”. A escolha depende do seu problema e dos seus recursos.

Característica	DeepWalk / Node2Vec (Walkers)	GNNs (GCN, GraphSAGE, etc.)
Filosofia Principal	Aprende por proximidade (caminhadas)	Aprende por agregação (vizinhança)
Uso de Atributos	Não (apenas estrutura do grafo)	Sim (estrutura + atributos dos nós/arestas)
Supervisão	Não-supervisionado	Supervisionado (mais comum)
Custo (Treino)	Rápido, paralelizável	Lento, mais complexo de treinar
Ponto Forte	Grafos gigantes, baselines rápidos, tarefas não-supervisionadas	Tarefas com atributos ricos, performance de ponta
Risco	Pode perder sinais de atributos	Over-smoothing (nós ficam parecidos demais)

Regra de bolso:

Se seu grafo é enorme, você tem poucos (ou nenhuns) atributos de nós, e você precisa de um baseline rápido e não-supervisionado, comece com DeepWalk ou Node2Vec.
Se você tem atributos ricos nos nós (texto, imagens, números), um rótulo claro para treinar (classificação, regressão), e precisa da melhor performance possível, use uma GNN.

5. A Tática Híbrida (O Melhor dos Dois Mundos)

Uma tática de especialista é usar os dois:

Rode o DeepWalk/Node2Vec no seu grafo gigante para gerar embeddings estruturais (não-supervisionados).
Use esses embeddings como as features iniciais (atributos de nó) para alimentar uma GNN.

Dessa forma, a GNN começa com um conhecimento profundo da estrutura do grafo e foca seu aprendizado em como refinar esse conhecimento usando os outros atributos e os rótulos supervisionados.

Conclusão

Tanto os “walkers” (DeepWalk, Node2Vec) quanto os “aggregators” (GNNs) são ferramentas essenciais no arsenal de quem trabalha com grafos. Os walkers são rápidos, escaláveis e ótimos para capturar a estrutura pura. As GNNs são mais caras, mas muito mais poderosas, pois combinam a estrutura do grafo com os atributos dos dados, permitindo um aprendizado end-to-end mais rico.

Referências

Perozzi, B., Al-Rfou, R., & Skiena, S. (2014). DeepWalk: Online Learning of Social Representations. KDD 2014.
Grover, A., & Leskovec, J. (2016). Node2Vec: Scalable Feature Learning for Networks. KDD 2016.
Kipf, T. N., & Welling, M. (2016). Semi-Supervised Classification with Graph Convolutional Networks. arXiv.
Hamilton, W., Ying, Z., & Leskovec, J. (2017). Inductive Representation Learning on Large Graphs (GraphSAGE). NeurIPS 2017.
Veličković, P. et al. (2018). Graph Attention Networks (GAT). ICLR 2018.

Sobre o autor

Rener Menezes
Cofundador & CTO — FitBank

Links: LinkedIn · ORCID · contato@grafolab.ia.br

Amazon e a Revolução do “Item-Item”: Como Grafos de Similaridade Mudaram o E-commerce

outubro 20, 2025
Resumo — “Clientes que compraram este item também compraram…”. Esta frase, popularizada pela Amazon, é o resultado de um dos algoritmos de grafos mais elegantes e impactantes do e-commerce: o Item-Item Collaborative Filtering (CF). Em vez de tentar encontrar usuários “gêmeos” (o que é lento e instável), a Amazon focou em calcular a similaridade entre os itens. A ideia é projetar o imenso grafo bipartido (usuário-item) em um novo grafo (item-item), onde as arestas representam a similaridade.

1. O Problema: Um Grafo Bipartido Instável

Como a maioria dos sistemas de recomendação, o problema da Amazon começa com um grafo bipartido, exatamente como vimos no nosso post sobre a Netflix.
- Nós do tipo A: Usuários.
- Nós do tipo B: Itens (produtos).
- Arestas: Interações (comprou, avaliou, clicou).
Uma abordagem inicial popular era o “User-User CF”: para me recomendar algo, o sistema primeiro encontrava “gêmeos” de gosto — outros usuários que compraram e avaliaram coisas de forma parecida comigo. O problema? Os gostos das pessoas mudam constantemente, e encontrar esses “gêmeos” em um grafo de milhões de usuários é computacionalmente caríssimo.

2. A Grande Virada: Focar nos Itens

A equipe da Amazon (liderada por Sarwar et al. em seu famoso paper de 2001) teve uma percepção fundamental: as relações entre os itens são muito mais estáveis do que as relações entre os usuários.

Um livro de “Teoria dos Grafos” será sempre similar a um livro de “Algoritmos”, independentemente de quem os compra. A solução, então, foi mudar a pergunta de “Quais usuários são parecidos com você?” para “Quais itens são parecidos com os que você já comprou?”.

Para isso, eles “projetaram” o grafo bipartido em um novo grafo, muito menor e mais estável: um grafo Item-Item.

3. Construindo o Grafo de Similaridade Item-Item

Neste novo grafo, os nós são apenas os Itens. A aresta entre dois itens (ex: Livro A $\leftrightarrow$ Livro B) representa o quão “similares” eles são.

Mas como calcular essa similaridade? Olhando para os usuários que interagiram com ambos.

Imagine que cada item é um “vetor” onde cada posição corresponde a um usuário, e o valor é a nota que aquele usuário deu. Para saber se o Livro A e o Livro B são similares, o algoritmo compara seus vetores de avaliação.

Em termos técnicos, a métrica de similaridade mais comum é a Similaridade de Cosseno (Cosine Similarity):

Traduzindo a matemática: Esta equação trata os vetores de avaliação de dois itens ( e ) e mede o “ângulo” entre eles. Se as mesmas pessoas avaliaram os dois itens de forma idêntica, o ângulo é zero (similaridade máxima). Se pessoas completamente diferentes avaliaram os itens, o ângulo é de 90 graus (similaridade zero).

Outras métricas, como Adjusted Cosine ou Pearson Correlation, também são usadas para ajustar por bias (ex: usuários que só dão notas altas ou só notas baixas).

Uma vez que essa similaridade é calculada para todos os pares de itens, o grafo Item-Item está pronto.

4. Gerando Recomendações: Uma Soma Ponderada

Agora, a parte mágica e simples. Quando você () visita a página de um produto, como o sistema gera a lista “também compraram”?
1. Ele olha para o seu histórico de compras e avaliações (os itens que você consumiu).
2. Para cada item que você gostou, ele busca no grafo Item-Item os vizinhos mais similares (ex: os 20 itens mais similares a ).
3. Ele gera uma “pontuação” para cada item candidato , somando as similaridades de acordo com o quanto você gostou dos itens originais.
A fórmula de pontuação para um candidato é uma soma ponderada:

Traduzindo a matemática: A “pontuação” de um novo item para você é uma soma. Se você amou (nota ) o Livro A, e o Livro B é muito similar (similaridade ) ao Livro A, o Livro B ganha uma pontuação alta (5 * 0.9 = 4.5). O sistema soma essas pontuações de todo o seu histórico e mostra os itens com os maiores scores.

5. Desafios do Mundo Real: Recência e Cold-Start

Esse sistema é poderoso, mas tem dois desafios clássicos que a engenharia precisa resolver:
- Recência (Recency): Um livro lançado hoje não tem histórico de co-compra. Para evitar que o sistema só recomende itens antigos, as interações mais recentes (compras de ontem) devem ter um “peso” maior do que as do ano passado (usando uma função de decaimento temporal).
- Cold-Start (Item Novo): Um item novo não tem interações. Como calcular sua similaridade? A solução é um fallback para filtragem baseada em conteúdo. O sistema assume que o novo item é similar a outros itens que compartilham os mesmos atributos (mesma categoria, mesmo autor, mesmas palavras-chave na descrição).
6. Por que Item-Item Ainda é Relevante?

No mundo das GNNs e do Deep Learning, por que esse algoritmo de 2001 ainda é tão importante?
1. Explicabilidade: É fácil de explicar. “Recomendamos X porque você comprou Y, e pessoas que compraram Y também compraram X.” Isso é muito mais claro do que “Recomendamos X porque o produto vetorial dos fatores latentes 3, 17 e 42 foi alto”.
2. Escalabilidade: O grafo Item-Item é (relativamente) pequeno e estável. Ele pode ser pré-calculado e atualizado de forma incremental (só recalculando os itens afetados por novas compras) e armazenado em índices esparsos para consulta em milissegundos.
3. Desempenho: É um baseline (ponto de comparação) extremamente difícil de bater. Muitas soluções complexas de deep learning falham em superá-lo em cenários do mundo real.
Conclusão

O Item-Item Collaborative Filtering da Amazon é uma das ideias mais fundamentais na história da recomendação. É um exemplo perfeito de modelagem de grafos: ele nos ensina que, às vezes, a melhor maneira de resolver um problema em um grafo complexo (o bipartido usuário-item) é projetá-lo em um grafo novo e mais simples (o item-item) que captura a essência da relação que realmente importa.

Referências
- Sarwar, B. et al. (2001). Item-based collaborative filtering recommendation algorithms. Proceedings of the 10th International Conference on World Wide Web (WWW).
- Herlocker, J. L. et al. (2004). Evaluating collaborative filtering recommender systems. ACM Transactions on Information Systems (TOIS).
Sobre o autor

Rener Menezes
Cofundador & CTO — FitBank

Rener Menezes é cofundador e CTO do FitBank, fintech brasileira de Banking-as-a-Service. Com mais de 25 anos de experiência projetando sistemas financeiros em larga escala, é bacharel em Sistemas de Informação e mestrando na Unifor, onde pesquisa Redes Neurais de Grafos e aprendizado por reforço para detecção de fraude. Interesses: sistemas distribuídos, infraestrutura de pagamentos e graph ML.

Links: LinkedIn · ORCID · contato@grafolab.ia.br
LinkedIn e a Mágica do “People You May Know”: Uma Aula de Grafos

outubro 20, 2025
Resumo — Como o LinkedIn sabe que você talvez conheça aquela pessoa que trabalhou na sua antiga empresa há 10 anos? Não é mágica, é um dos melhores exemplos de previsão de arestas (link prediction) em um grafo social. O recurso “People You May Know” (PYMK) é uma máquina de recomendação sofisticada que vai além dos “amigos em comum”, usando a estrutura do grafo profissional (como empresas e escolas) para encontrar conexões relevantes e de alto valor.

1. O Problema: Prever Conexões em um Grafo Profissional

No seu núcleo, o LinkedIn é um grafo social:
- Nós: São os perfis das pessoas.
- Arestas: São as conexões de 1º grau (“Fulano está conectado com Ciclano”).
O desafio do “People You May Know” é um problema clássico de link prediction: quais arestas que não existem hoje têm a maior probabilidade de serem criadas no futuro?

Se o LinkedIn fosse apenas uma rede social comum, a resposta seria simples. Mas ele é uma rede profissional, o que torna o problema muito mais rico.

2. A Intuição Principal: O Poder dos “Triângulos”

A intuição mais básica por trás de qualquer sistema de recomendação social é o Fechamento Triádico (ou Triadic Closure).

A ideia é simples: “O amigo do meu amigo tem grande chance de ser meu amigo.”

Se você está conectado ao Rener, e o Rener está conectado à Ana, o sistema vê um “caminho de 2 saltos” (Você $\rightarrow$ Rener $\rightarrow$ Ana) e percebe que a aresta (Você $\rightarrow$ Ana) está “faltando” para fechar o triângulo.

Algoritmos clássicos de grafos medem a força dessa sugestão:
- Common Neighbors (Amigos em Comum): Quantos amigos em comum vocês têm? Se você e Ana têm 10 amigos em comum, a chance de se conhecerem é altíssima.
- Adamic-Adar (Peso dos Comuns): Uma versão mais inteligente. Ela diz que ter um amigo em comum “raro” (uma pessoa com poucas conexões) é um sinal muito mais forte do que ter um amigo em comum que é um “super-conector” (alguém com 30.000 conexões).
3. O “Molho Secreto” do LinkedIn: Além dos Amigos

Aqui é onde o PYMK do LinkedIn brilha. Ele sabe que conexões profissionais são formadas por mais do que apenas amizades. Elas são formadas por afiliações compartilhadas.

O grafo do LinkedIn não é apenas de pessoas; ele é um grafo heterogêneo que inclui nós de Empresas, Instituições de Ensino, Habilidades (Skills), e Localizações.

O sistema de recomendação usa esses nós como features poderosíssimas:
- Co-afiliação de Empresa: Você e Ana trabalharam na Empresa X, mesmo que em períodos diferentes? Sinal fortíssimo.
- Co-afiliação de Escola: Vocês dois estudaram na mesma universidade?
- Similaridade de Perfil: Vocês têm o mesmo cargo? (ex: “Engenheiro de Dados”). Vocês listam as mesmas skills raras no perfil?
Uma pessoa que é seu “amigo de amigo” E que também trabalhou na sua antiga empresa não é mais uma sugestão; é quase uma certeza.

4. O Motor de Ranking: Juntando Todas as Pistas

O sistema do LinkedIn não usa apenas um desses sinais. Ele calcula dezenas, talvez centenas, de “pistas” (features) e as joga em um modelo de Machine Learning (como Gradient Boosting ou uma rede neural) que aprende a ponderar a importância de cada uma.

Esse modelo de ranking é alimentado por um conjunto de features, que incluem:
- Sinais de Grafo Social: O score de Adamic-Adar, o número de amigos em comum.
- Sinais de Proximidade (PPR): O score de Personalized PageRank (PPR) pode ser usado para encontrar pessoas “próximas” de você no grafo, mesmo que a 3 ou 4 saltos de distância, como vimos no caso do Twitter.
- Sinais de Afiliação: “Trabalhou na mesma empresa?” (sim/não), “Estudou na mesma universidade?” (sim/não), “Mesmo período?” (sim/não).
- Sinais de Perfil: Similaridade de títulos, sobreposição de skills.
O modelo de ranking aprende, por exemplo, que “mesma empresa” + “mesmo período” é um sinal 10x mais forte do que apenas “mesma universidade”.

5. Engenharia e Desafios em Escala

Entregar essas recomendações em tempo real para centenas de milhões de usuários é um desafio de engenharia gigantesco.
- Pré-Cálculo: O sistema não calcula tudo na hora. Ele pré-calcula “listas de candidatos” (ex: todas as suas conexões de 2º grau) e as armazena em caches de alta velocidade.
- Filtros de Privacidade: O sistema precisa obedecer rigorosamente às suas configurações de privacidade e bloquear pessoas que você possa ter bloqueado.
- Saturação: Você já rejeitou a sugestão de “Fulano” 5 vezes? O sistema precisa aprender a parar de sugeri-lo, para não saturar sua experiência.
- Combate a Spam: O modelo também precisa filtrar perfis falsos ou de baixa qualidade que tentam se conectar em massa para ganhar visibilidade.
Conclusão

O “People You May Know” é um exemplo perfeito de um sistema de recomendação moderno. Ele é híbrido: começa com a fundação da Teoria dos Grafos (fechamento triádico, Adamic-Adar, PPR) para entender a estrutura da rede e, em seguida, enriquece essa estrutura com features de perfil (empresa, escola, skills), usando Machine Learning para rankear e entregar a sugestão mais relevante.

É a fusão da estrutura do grafo com os atributos dos nós que cria a “mágica”.

Referências
- Adamic, L. A., & Adar, E. (2003). Friends and Neighbors on the Web. Social Networks.
- Liben-Nowell, D., & Kleinberg, J. (2007). The Link-Prediction Problem for Social Networks. Journal of the American Society for Information Science and Technology (JASIST).
- (Recomendo adicionar links para 1-2 posts do blog de engenharia do LinkedIn sobre PYMK, se você os encontrar. Eles dão ainda mais autoridade).
Sobre o autor

Rener Menezes
Cofundador & CTO — FitBank

Rener Menezes é cofundador e CTO do FitBank, fintech brasileira de Banking-as-a-Service. Com mais de 25 anos de experiência projetando sistemas financeiros em larga escala, é bacharel em Sistemas de Informação e mestrando na Unifor, onde pesquisa Redes Neurais de Grafos e aprendizado por reforço para detecção de fraude. Interesses: sistemas distribuídos, infraestrutura de pagamentos e graph ML.

Links: LinkedIn · ORCID · contato@grafolab.ia.br
PinSage: A GNN que Redefiniu a Recomendação em Grafos no Pinterest

outubro 20, 2025
Resumo — O feed do Pinterest parece mágico: como ele sabe exatamente qual pin de receita ou decoração você quer ver, dentre bilhões de opções? A resposta é um dos papers mais influentes da área de grafos: o PinSage. O Pinterest modelou seu ecossistema como um imenso grafo de usuários, pins e pastas, e desenvolveu uma GNN (Graph Neural Network) para “passear” por esse grafo e aprender o “DNA” (embedding) de cada pin. O resultado é um sistema de recomendação que escala para bilhões de itens e definiu uma geração de GNNs industriais.

1. O Problema: Um Grafo (Tri)partido de Bilhões de Arestas

Para entender o PinSage, primeiro precisamos ver o Pinterest como um grafo. Ele não é apenas uma coleção de imagens, mas sim um mapa de conexões:
- Nós (Entidades): Temos principalmente Usuários, Pins (as imagens/links) e Boards (as pastas onde os pins são salvos).
- Arestas (Relações): As conexões são ações como (usuário salvou o pin ) ou (pin pertence ao board ).
Isso forma um grafo gigantesco e heterogêneo. O desafio de recomendação é: dado um pin que você está vendo agora (o “query pin”), quais são os outros pins que são mais parecidos ou relevantes para ele, em todo o universo de bilhões de pins?

Abordagens “clássicas” (como as que vimos no post da Netflix) teriam dificuldades. A Fatoração Matricial pura, por exemplo, não aproveitaria o rico conteúdo de cada pin (a imagem em si e o texto da descrição).

2. A Ideia-Chave do PinSage: GNNs com “Passeios Aleatórios”

A solução do Pinterest foi criar uma Graph Neural Network (GNN) para aprender um embedding — um “DNA” numérico — para cada pin. A grande ideia do PinSage é que o DNA de um pin deve ser uma combinação de duas coisas:
1. O Conteúdo do Pin: O que a imagem mostra e o que o texto diz (isso é extraído por modelos de visão computacional e NLP).
2. A Vizinhança do Pin: Quais outros pins estão “perto” dele no grafo? (ex: pins que são salvos nas mesmas pastas).
Aqui surge o desafio de engenharia: como você “olha” a vizinhança de um nó em um grafo com bilhões de conexões? A resposta do PinSage é brilhante: você não olha tudo, você amostra de forma inteligente.

O PinSage introduziu duas inovações cruciais:

Inovação 1: Amostragem por “Passeios Aleatórios” (Random Walks) Em vez de tentar processar todos os vizinhos de um pin (o que seria impossível), o PinSage simula “passeios aleatórios” a partir dele. É como soltar 50 “exploradores” virtuais que pulam de pin em pin, seguindo as conexões do grafo (ex: de um pin para uma pasta, dessa pasta para outro pin).

Os nós que são visitados com mais frequência por esses “exploradores” são considerados os vizinhos mais importantes. O PinSage foca seu poder computacional apenas nesses vizinhos amostrados.

Inovação 2: Agregação por Importância Uma vez que temos a amostra de vizinhos importantes, a GNN “agrega” a informação deles. O PinSage usa um agregador (como uma média ponderada ou um pooling) para combinar os embeddings dos vizinhos e fundi-los com o embedding de conteúdo do pin original. O resultado desse processo é o embedding final do PinSage: um vetor denso que captura tanto o conteúdo quanto o contexto do pin no grafo.

3. O Pipeline de Produção: Um Funil de Duas Etapas

Na prática, gerar recomendações em tempo real exige velocidade. O PinSage (que é pesado para rodar) é usado “offline” para calcular os embeddings de todos os pins. O sistema de recomendação ao vivo funciona como um funil:

Etapa 1: Geração de Candidatos (Rápida) Quando você precisa de uma recomendação, o sistema pega o embedding do seu “pin-query” e usa um sistema de busca por similaridade ultrarrápido (como ANN – Approximate Nearest Neighbors, ex: FAISS ou ScaNN) para encontrar os pins (ex: ) cujos embeddings são mais parecidos. Esta etapa é um “filtro grosso” que reduz bilhões de opções para mil.

Etapa 2: Re-ranqueamento (Inteligente) Esses 1000 pins candidatos são então passados para um segundo modelo, mais complexo e caro (que pode ser outra GNN ou um modelo de ML mais pesado). Este modelo de “re-ranking” analisa os 1000 candidatos com mais cuidado, usando features adicionais (como recência, seu histórico, diversidade), e gera a lista final de 10-20 pins que você vê na tela.

4. Lições do PinSage: O Blueprint da GNN Industrial

O paper do PinSage (KDD 2018) é considerado um marco porque foi a primeira vez que uma arquitetura GNN (baseada na GraphSAGE) foi comprovadamente escalada para um grafo de recomendação de tamanho web-scale (bilhões de nós).

Ele estabeleceu um blueprint de engenharia que é usado até hoje:
1. Amostragem é a Chave: O Random walk sampling (ou suas variantes) tornou as GNNs viáveis em grafos gigantes.
2. Features + Estrutura: A forma mais poderosa de GNN é aquela que combina features de conteúdo (texto, imagem) com a estrutura do grafo.
3. Treinamento com Negativos Difíceis: O PinSage foi treinado para diferenciar um pin “bom” não de um pin aleatório (fácil), mas de um pin “ruim” que é muito parecido com o bom. Isso torna o modelo muito mais robusto.
4. Evolução: O PinSage abriu caminho para arquiteturas mais recentes e eficientes, como a LightGCN (que simplifica a GNN) e a NGCF (que foca na estrutura), que se tornaram baselines fortes na área.
Conclusão

O PinSage é um estudo de caso fundamental que vai além do Pinterest. Ele é a prova de que as GNNs não são apenas conceitos acadêmicos, mas ferramentas de engenharia robustas capazes de resolver problemas de recomendação em uma escala que era impensável com algoritmos anteriores. Ele uniu, de forma elegante, a teoria dos grafos (random walks), o deep learning (GNNs) e a engenharia de sistemas (ANN) para criar valor de negócio real.

Referências
- Ying, R. et al. (2018). Graph Convolutional Neural Networks for Web-Scale Recommender Systems (PinSage). KDD 2018.
- He, X. et al. (2020). LightGCN: Simplifying and Powering Graph Convolutional Networks for Recommendation. SIGIR 2020.
- Wang, X. et al. (2019). Neural Graph Collaborative Filtering (NGCF). SIGIR 2019.
- Adamic, L. A., & Adar, E. (2003). Friends and Neighbors on the Web. Social Networks.
Sobre o autor

Rener Menezes
Cofundador & CTO — FitBank

Rener Menezes é cofundador e CTO do FitBank, fintech brasileira de Banking-as-a-Service. Com mais de 25 anos de experiência projetando sistemas financeiros em larga escala, é bacharel em Sistemas de Informação e mestrando na Unifor, onde pesquisa Redes Neurais de Grafos e aprendizado por reforço para detecção de fraude. Interesses: sistemas distribuídos, infraestrutura de pagamentos e graph ML.

Links: LinkedIn · ORCID · contato@grafolab.ia.br