REngine : Moteur de Recommandation Graph-Based

Le Défi

L’objectif de REngine est de transformer les données transactionnelles d’une boutique e-commerce (Sylius/MySQL) en un moteur de recommandation intelligent. Le défi majeur consistait à passer d’une base de données relationnelle classique à un graphe de connaissances Neo4j, permettant d’analyser les relations complexes entre clients et produits en temps réel.

Architecture du Système

Le projet repose sur un pipeline analytique découpé en quatre services spécialisés :

1. Synchronisation (ETL) : Migration des données MySQL (clients, produits, commandes) vers Neo4j avec filtrage du “bruit” (exclusion du top 1% des produits les plus vendus pour éviter les fausses affinités).
2. Affinités : Calcul des centres d’intérêt via les relations INTERESTED_IN.
3. Similarités : Identification des clients aux profils proches via un filtrage collaboratif.
4. API REST : Exposition des recommandations via FastAPI.

Choix Techniques

Pourquoi Neo4j & FastAPI ?

• Neo4j : Contrairement au SQL, le graphe permet d’interroger les relations “amis d’amis” ou “acheteurs de ce produit ont aussi acheté…” avec une performance constante, même avec des millions de nœuds.
• FastAPI : Choisi pour sa rapidité et sa gestion native de l’asynchronisme, idéal pour servir les résultats du graphe via une interface REST.
• Pandas : Utilisé pour le calcul de similarité client-client en mémoire, permettant de traiter des matrices de relations.

Analyse des Recommandations

1. Le tri sélectif : Éliminer le “bruit”

Avant toute analyse, le système effectue un tri chirurgical pour ne garder que les données significatives. J’ai choisi d’ignorer les produits « Best-seller » (le top 1% des ventes) car ils attirent des profils trop variés pour être discriminants. De même, les produits offerts ou promotionnels sont écartés afin de ne pas fausser les goûts réels des clients.

2. Similarité Client : La puissance de Neo4j GDS

Pour identifier les profils proches, l’algorithme repère les clients partageant au moins trois produits en commun. Pour aller plus loin qu’une simple jointure Pandas, j’ai utilisé l’extension Neo4j Graph Data Science (GDS). En exploitant des algorithmes de similarité, le système génère des relations SIMILAR_TO pondérées directement dans le graphe, permettant de quantifier précisément la “proximité” entre deux clients.

3. Moteur de Recommandation : GraphAware & APOC

Pour structurer les suggestions, je me suis appuyé sur le framework GraphAware Recommendation Engine. Cet outil m’a permis de définir des moteurs de recommandation robustes et d’utiliser des procédures optimisées pour le calcul des scores. En complément, les fonctions de l’extension APOC ont facilité les calculs de masse pour l’analyse du panier (Market Basket Analysis).

4. La création de “Tribus” (L’effet miroir)

C’est le cœur du système : le moteur compare les profils d’achat pour créer des liens de parenté (SIMILAR_TO).

Si vous avez acheté les mêmes produits que dix autres personnes, vous rejoignez leur “tribu”. [cite_start]Le système regarde alors ce que votre tribu achète le plus pour vous le proposer. [cite: 148, 149]

L’Intelligence Anti-Doublon

Rien n’est plus frustrant qu’une recommandation inutile. J’ai intégré une sécurité pour éviter les répétitions.

• Exemple : Si vous consultez un médicament en format 30 gélules, le moteur comprend que vous proposer la version 60 gélules n’est pas une recommandation utile, mais un doublon. Il l’écarte pour proposer un complément plus pertinent.

Performance : 19 millisecondes

C’est là que le choix du graphe prend tout son sens. Grâce au pré-calcul des liens d’affinité en mémoire vive, les requêtes de recommandation s’exécutent en moyenne en 19 ms en local. C’est une réactivité quasi instantanée pour l’utilisateur final.

Le Problème : Le bruit des produits “communs”

Lors des premiers tests, les sacs réutilisables ou les articles de base créaient des liens entre presque tous les clients, faussant totalement la pertinence des recommandations.

La Solution : Analytics Service

J’ai intégré un service de filtrage qui identifie le top 1% des ventes. Ces produits reçoivent un label spécial CommonProduct et sont exclus du calcul des similarités pour garantir que les recommandations se basent sur des centres d’intérêt réels et non sur des achats de nécessité.

Ce que j’ai appris

• Puissance du Cypher : Découverte du langage de requête de Neo4j permet de remplacer des centaines de lignes de code procédural par une simple requête de graphe.
• Performance In-Memory : L’utilisation de Pandas pour orchestrer les données entre deux bases (MySQL et Neo4j) a été un excellent exercice d’optimisation mémoire.
• Architecture en couches : Le découpage strict entre Migrators, Services et Repositories rend le moteur facile à maintenir et à faire évoluer.

Ce projet m’a montré que la structure des données est aussi importante que l’algorithme lui-même. En passant d’une logique de “tables” à une logique de “relations”, on simplifie radicalement des problèmes complexes. J’ai aussi appris à utiliser des outils spécialisés comme GraphAware et GDS pour transformer un simple graphe en un véritable outil d’intelligence prédictive.

Rétrospective

Ce prototype (PoC) valide la viabilité technique de l’approche par graphes. Pour une mise en production complète, l’étape suivante serait d’automatiser le cycle d’analyse pour intégrer les nouveaux comportements d’achat en temps réel via un rafraîchissement périodique des calculs.