Leyton — mission de conseil
Personnalisation temps réel avec un pipeline de personas RAG
Une plateforme cosmétique recommandait par segments figés, en ignorant tout le texte qu’elle possédait déjà. Passage à une recommandation par personne, en temps réel, construite sur de la récupération documentaire — et explicable par l’équipe métier.
- Rôle
- Consultant data science
- Période
- Septembre 2023 — février 2024
Stack
Le problème
Le segment n’est pas la personne. « Femme, 25-34, peau mixte » regroupe des gens dont les besoins n’ont rien en commun : la recommandation moyenne ne convient précisément à personne.
Et le signal le plus riche dormait. Descriptions produits, compositions, avis clients, contenus éditoriaux : beaucoup de texte non structuré, plein d’information, totalement invisible pour un moteur à base de règles.
Les contraintes
Temps réel : la recommandation arrive pendant la session, dans un budget de latence de page web. Un batch nocturne était hors sujet.
Démarrage à froid : un visiteur nouveau n’a pas d’historique, et le système devait être utile dès la première interaction.
Explicabilité : l’équipe métier devait pouvoir répondre à « pourquoi ce produit ? ». Personne n’accepte de céder son merchandising à une boîte noire.
Mission de conseil : ce qui n’était pas repris par les équipes internes après mon départ n’avait aucune valeur.
Ce que j’ai construit
Une couche de personas alimentée par RAG. Plutôt qu’un embedding produit brut, un espace intermédiaire interprétable entre l’utilisateur et le catalogue, construit par récupération sur le corpus textuel. C’est ce qui résout l’explicabilité : la recommandation n’est pas « le modèle a dit », c’est « ce profil correspond à ce persona, qui correspond à ces produits, pour ces raisons textuelles ». L’équipe métier lit le raisonnement et peut le contester.
Deux vitesses, pas une. Hors ligne : embeddings, personas, associations produits — coûteux, précalculé. En ligne : signal de session, appariement, classement final — léger, à la requête. Le temps réel n’est pas « tout calculer vite », c’est précalculer tout ce qui peut l’être.
Un service volontairement simple. Flask, MongoDB, Docker, AWS. L’équipe interne devait pouvoir reprendre la maintenance, donc rien d’ingénieux pour le plaisir.
Résultats
- +15 % de taux de conversion, rapporté par le client
- −20 % de temps de cycle d’analyse pour l’équipe métier
- Recommandations explicables, reprises et maintenues en interne après la fin de la mission
Ce que je referais autrement
Poser la mesure avant la construction. Le +15 % a été rapporté ; un protocole d’A/B test défini au premier jour aurait produit un chiffre défendable plutôt qu’un chiffre crédible. C’est aujourd’hui la première chose que je cadre : comment saura-t-on que ça a marché, et qui accepte ce chiffre ?
Traiter le démarrage à froid comme une stratégie, pas comme un cas dégradé. Sur un site grand public, les visiteurs nouveaux sont une part énorme du trafic. En faire un repli du chemin nominal, c’est mal servir la majorité des gens.