Pourquoi ce sujet est important
Un embedding transforme un texte, une image ou un autre objet en vecteur numérique. Des contenus proches dans l’espace vectoriel sont supposés partager un sens utile. Cette représentation alimente recherche sémantique, clustering, recommandations et détection de doublons, mais sa qualité dépend du modèle et de la tâche.
Comprendre la similarité
Le modèle produit un vecteur de dimension fixe. La similarité cosinus, le produit scalaire ou la distance euclidienne permettent de classer les voisins. La valeur brute n’a pas de signification universelle : un seuil doit être calibré sur vos données et avec la métrique recommandée par le modèle.
Choisir selon la tâche
Un modèle performant sur la recherche générale peut être moins bon pour du code, des textes juridiques ou des requêtes très courtes. Vérifiez les langues, la longueur maximale, les instructions de requête et de document, ainsi que les benchmarks correspondant à retrieval, classification ou similarité.
Tester le français et le multilingue
Construisez des requêtes françaises avec documents attendus, paraphrases, acronymes et noms propres. Si les utilisateurs interrogent en français des documents anglais, testez explicitement le cross-lingue. Une mention “multilingual” ne garantit pas une qualité homogène.
Dimension, stockage et latence
Plus de dimensions augmentent mémoire, transfert et coût d’indexation. Certains modèles permettent de tronquer les vecteurs, mais la perte doit être mesurée. Calculez taille du corpus, nombre de copies, index et cache. Le coût de l’API d’embedding n’est qu’une partie du coût total.
Évaluer avec un jeu de pertinence
Pour chaque requête, marquez les documents pertinents. Mesurez recall@k, MRR ou nDCG, puis la qualité de la réponse RAG. Comparez également latence, débit et coût. Analysez les échecs par type : termes exacts, langue, longueur et ambiguïté.
Migrer sans mélanger les espaces
Deux versions de modèle produisent des espaces incompatibles. Créez un nouvel index ou un vecteur nommé, réencodez les documents et comparez en parallèle. Épinglez l’identifiant du modèle et conservez version, dimension et normalisation avec chaque collection.
Combiner lexical et vectoriel
Les embeddings excellent sur les paraphrases mais peuvent manquer références exactes, codes et noms rares. Une recherche hybride BM25 + vecteur, éventuellement suivie d’un reranker, offre souvent un meilleur compromis.
Exemple concret
Une base de documentation française contient des codes d’erreur et des explications. L’équipe compare trois modèles sur 300 requêtes. Le modèle le plus grand gagne sur les paraphrases, mais une solution plus compacte combinée à BM25 obtient le meilleur rappel global et réduit stockage et latence.
Les erreurs fréquentes
- choisir sur un benchmark anglais uniquement
- utiliser un seuil copié d’un autre modèle
- mélanger des vecteurs de versions différentes
- ignorer noms propres et références exactes
- mesurer seulement la recherche sans réponse finale
- réencoder la production sans stratégie de retour arrière
Checklist
- [ ] Tâche et langues définies
- [ ] Jeu de pertinence versionné
- [ ] Métrique conforme au modèle
- [ ] Recall, latence et coût mesurés
- [ ] Recherche hybride comparée
- [ ] Version et dimension stockées
- [ ] Migration parallèle préparée
FAQ
Quelle dimension choisir ?
Celle du modèle ou une réduction officiellement supportée et validée. Plus grand n’est pas automatiquement meilleur.
Faut-il normaliser les vecteurs ?
Suivez la documentation du modèle et la métrique de la base. Une normalisation incohérente fausse les scores.
Peut-on réutiliser un embedding pour toutes les tâches ?
Pas toujours. Recherche, clustering et similarité peuvent favoriser des modèles ou modes différents.
Comment choisir un seuil ?
À partir de positifs et négatifs représentatifs, en arbitrant faux positifs et faux négatifs selon le risque.