01 — Model selection
Un benchmark par tâche évite de choisir un encodeur sur sa réputation.
Deux protocoles reproductibles ont séparé la recherche textuelle et la similarité image. Sur des catalogues publics, FashionCLIP améliorait le NDCG@10 visuel de 7,9 % sur Amazon Berkeley Objects et de 4,6 % sur H&M par rapport à CLIP. Pour la recherche sémantique, un encodeur textuel dédié restait supérieur.
La décision a consisté à conserver plusieurs espaces spécialisés tant qu’un benchmark hybride ne démontrait pas l’intérêt de les fusionner. Les catégories n’étant qu’un proxy de pertinence, les résultats ont été interprétés avec leurs limites et complétés par des inspections qualitatives.
02 — Pipeline
Le calcul incrémental sépare l’inférence coûteuse de la stratégie produit.
Chaque champ produit — nom, description, image — possède une empreinte et une représentation versionnée. Seuls les contenus nouveaux ou modifiés sont réencodés. Les produits retirés sont supprimés selon une règle explicite, tandis que les erreurs d’image et les champs optionnels suivent des stratégies de repli observables.
Les embeddings sont combinés avec des poids configurables puis normalisés. Une modification de la stratégie de fusion peut ainsi être appliquée sans recalculer l’ensemble du catalogue. La séparation par modèle et par champ permet également de faire coexister plusieurs versions pendant une migration.
03 — Serving & scale
L’architecture rend les compromis de retrieval mesurables.
ClickHouse, les index HNSW et les stratégies en mémoire ont été comparés en pertinence, latence et comportement sous charge. FastAPI expose les opérations nécessaires, tandis que l’orchestration, la conteneurisation et les tests de charge rendent le chemin reproductible.
Un service d’embeddings sur GPU a aussi été évalué jusqu’à saturation afin de distinguer le gain matériel des limites de batching et d’orchestration. Ces mesures ont alimenté le capacity planning plutôt qu’une simple préférence technologique.
04 — Production
Tests de résultat et monitoring prolongent le benchmark après le déploiement.
Le pipeline multimodal est aujourd’hui en production. 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’apportaient pas assez de valeur. La segmentation automatique, par exemple, ajoutait des échecs et un coût sans amélioration suffisamment robuste pour la première version. Cette décision réduit la complexité tout en laissant un protocole d’ablation disponible pour de futurs catalogues.