LIKYLY vs. construire sa propre solution

Construire un moteur de recommandations en interne est tout à fait faisable - la question n’est pas « est-ce possible » mais « qu’est-ce que ça coûte à maintenir, une fois que ça marche ». Voici où se situe réellement l’effort.

Ce qui est rapide à prototyper

Un premier « produits similaires » basé sur une similarité de texte (TF-IDF, cosine similarity) se code en un après-midi avec scikit-learn. Le filtrage collaboratif (ALS, matrix factorization) a des implémentations open-source matures (implicit, lightfm). Rien de tout ça n’est le problème.

Ce qui coûte cher dans la durée

• Le multi-tenant : isoler proprement le catalogue, les événements et les modèles de plusieurs clients (ou plusieurs catégories) sans qu’ils se mélangent - facile à rater, coûteux à corriger a posteriori.
• Le versioning de modèle : ré-entraîner un modèle sans jamais risquer de dégrader la production - ce qui suppose de comparer les performances avant promotion, garder l’historique, pouvoir revenir en arrière.
• La diversité des résultats : un score de similarité pur produit régulièrement des correspondances aberrantes (un titre qui matche par coïncidence textuelle plutôt que par pertinence réelle) - un vrai travail de réglage, pas un simple tri par score.
• L’infrastructure : base vectorielle, ré-entraînement planifié, monitoring - à faire tourner et surveiller, en continu.

Où LIKYLY se situe

LIKYLY encapsule ces quatre points (multi-tenant, versioning avec gate de promotion, diversification des résultats, infrastructure gérée) derrière une API HTTP et des SDK typés - pour se concentrer sur l’intégration dans votre produit plutôt que sur l’exploitation d’un moteur de ML.