01 — Choix des modèles
Chaque tâche mérite son propre protocole de comparaison.
Deux évaluations reproductibles ont séparé la recherche par le texte de la similarité entre images. Sur des catalogues publics, FashionCLIP améliorait le NDCG@10 visuel de 7,9 % en relatif sur Amazon Berkeley Objects (0,6177 → 0,6662) et de 4,6 % en relatif sur H&M (0,8759 → 0,9160) par rapport à CLIP. Le NDCG@10 mesure la qualité de l’ordre des dix premiers résultats. Pour une requête textuelle, un modèle spécialisé dans le texte restait supérieur.
Les catégories de produits servaient d’indicateur approximatif de pertinence : deux produits de même catégorie ne sont pas toujours similaires. Les scores ont donc été complétés par une inspection des résultats. Cette limite a conduit à conserver plusieurs modèles spécialisés plutôt qu’à imposer trop tôt une représentation unique.
02 — Pipeline
Le calcul incrémental évite de retraiter tout le catalogue.
Le nom, la description et l’image de chaque produit possèdent une empreinte numérique. Lorsqu’aucun de ces contenus ne change, leurs embeddings sont réutilisés. Seuls les produits nouveaux ou modifiés sont à nouveau encodés. Des règles distinctes gèrent les suppressions, les images invalides et les champs manquants.
Les représentations compatibles d’un même espace peuvent être combinées avec des poids configurables et normalisées. Les espaces d’encodeurs distincts restent séparés : additionner directement des vecteurs OpenAI et CLIP n’est pas une fusion valide. L’équipe peut modifier cette pondération sans recalculer tous les embeddings. Le versionnement permet également de faire coexister l’ancien et le nouveau modèle pendant une migration.
03 — Service et montée en charge
L’architecture mesure le compromis entre qualité, vitesse et coût.
Plusieurs méthodes de recherche ont été comparées : requêtes dans ClickHouse, index HNSW — une structure conçue pour retrouver rapidement les vecteurs proches — et recherche en mémoire. Chaque option a été mesurée en pertinence, en temps de réponse et sous forte charge. FastAPI fournit les opérations nécessaires au produit.
Le service de calcul des embeddings sur processeur graphique a aussi été poussé jusqu’à saturation. L’objectif était de distinguer ce que le matériel accélérait réellement des limites liées au regroupement des requêtes et à l’orchestration. Ces mesures ont servi à dimensionner le système.
04 — Production
Le suivi en production prolonge l’évaluation initiale.
J’ai contribué à la mise en production du pipeline multimodal. Son exploitation suit la couverture des catalogues, les échecs d’encodage, la disponibilité des voisins, la latence et les versions de modèles. Les migrations et la cohérence des métadonnées font l’objet de contrôles fonctionnels, car une requête peut techniquement réussir tout en retournant un classement erroné.
Les briques expérimentales ont été conservées hors du chemin critique lorsqu’elles n’amélioraient pas assez les résultats. La segmentation automatique, par exemple, ajoutait des échecs et un coût sans améliorer suffisamment la pertinence des produits voisins pour la première version. Cette décision réduit la complexité tout en laissant un protocole d’ablation disponible pour de futurs catalogues.