Un RAG qui rate des passages évidents, ce n'est presque jamais un problème de LLM. C'est un problème d'embeddings — et plus précisément un problème de décalage entre le vocabulaire de votre corpus et ce que le modèle a appris à encoder. Fine-tuner un modèle d'embeddings sur votre domaine métier via apprentissage contrastif corrige ce problème à la source. On a mesuré des gains de 10 à 25 points de Recall@10 sur des corpus à jargon spécialisé en faisant exactement ça.
Cet article explique comment entraîner des embeddings sur votre corpus : constitution des paires d'entraînement, génération de hard negatives, perte contrastive, outillage avec sentence-transformers / SBERT, choix du modèle de base (e5, BGE, GTE), et évaluation réelle sur Recall@k. Pour comprendre d'abord ce que sont les embeddings et comment ils fonctionnent, commencez par notre guide technique sur les embeddings et la recherche sémantique. Ici, on passe à l'étape suivante : les entraîner.
Pourquoi un modèle d'embeddings générique rate votre jargon
Les modèles d'embeddings populaires — intfloat/e5-large, BAAI/bge-m3, Alibaba-NLP/gte-multilingual — ont été entraînés sur des corpus massifs : Wikipedia, Common Crawl, des paires questions-réponses du web public. Ils sont excellents sur du texte généraliste.
Le problème survient dès que votre corpus contient un vocabulaire que ces modèles n'ont jamais vu dans un contexte utile. Une nomenclature produit interne ("réf. KP-2247-B"), un jargon réglementaire très spécialisé, des abréviations sectorielles propres à votre filière. Pour le modèle générique, ces tokens existent, mais n'ont aucune représentation sémantique calibrée — ils sont traités comme du bruit, pas comme des concepts à relier.
Conséquence directe : quand un utilisateur pose une question avec votre jargon, le modèle encode cette requête dans une zone de l'espace vectoriel éloignée des passages pertinents. Le retriever rate, le LLM reçoit de mauvais contextes et hallucine — ou répond "je ne sais pas" alors que l'information est là, dans votre base.
Ce décalage s'observe surtout dans trois situations :
- Jargon propriétaire dense : codes affaire internes, nomenclatures techniques, références produit, abréviations maison.
- Domaine sous-représenté dans les corpus publics : droit français très spécifique, documentation industrielle sectorielle, réglementation peu numérisée.
- Asymétrie question / document : les utilisateurs posent des questions en langage naturel et vos documents répondent en termes techniques formels, ou l'inverse.
Soyons honnêtes : si votre RAG porte sur du français professionnel courant bien représenté dans les corpus publics, un bon modèle générique suffit. Le fine-tuning d'embeddings n'est pas la première chose à faire. Mais si votre Recall@5 stagne en dessous de 65-70 % sur un set de test représentatif, regardez les embeddings.
L'apprentissage contrastif : ce qui se passe pendant l'entraînement
Le fine-tuning d'embeddings repose sur l'apprentissage contrastif. L'idée : pendant l'entraînement, on montre au modèle des paires (question, passage pertinent) et on le force à les rapprocher dans l'espace vectoriel — tout en éloignant les passages non pertinents.
La perte la plus efficace pour cette tâche est la MultipleNegativesRankingLoss (MNRL), implémentée nativement dans sentence-transformers. Son principe : dans un batch de N paires, pour chaque question, le passage positif doit avoir un score de similarité cosinus plus élevé que tous les autres passages du batch (qui servent de négatifs implicites). Computationnellement efficace, pas besoin de négatifs explicitement labellisés.
Constitution des données : paires et triplets
Chaque exemple d'entraînement est une paire ou un triplet :
- Paire positive : (question, passage qui y répond) — la base de tout fine-tuning contrastif.
- Triplet : (question, passage positif, passage négatif) — plus informatif, force des distinctions plus fines.
Avec la MNRL, des paires positives seules suffisent pour un premier entraînement. L'étape suivante : ajouter des hard negatives.
Les hard negatives : le vrai levier de performance
Un négatif aléatoire, c'est un passage hors sujet total. Le modèle les écarte facilement, même sans fine-tuning. Ce n'est pas là que le gain se fait.
Un hard negative, c'est un passage qui ressemble à la bonne réponse — même vocabulaire, même thème — mais qui n'y répond pas réellement. Exemple concret sur un catalogue de pièces industrielles : la question porte sur le "joint torique pour compresseur modèle GA-11" et le hard negative est la fiche du joint pour le modèle GA-7. En surface, très proches. En fond, différents. Forcer le modèle à les distinguer l'oblige à créer des représentations sémantiques bien plus fines.
La méthode standard pour miner les hard negatives : utiliser BM25 sur toutes vos questions, récupérer le top 20-50, et exclure les passages réellement pertinents. Les passages restants — bien classés par BM25 mais faux — sont vos meilleurs hard negatives. FlagEmbedding (l'écosystème de BGE) intègre ce pipeline de mining automatiquement.
Générer des paires synthétiques : la méthode GPL
Vous n'avez pas de dataset de questions-réponses prêt ? C'est le cas de la grande majorité des projets. La solution : générer des paires synthétiques depuis vos documents avec un LLM.
C'est la méthode GPL (Generative Pseudo-Labeling). Le principe : pour chaque passage du corpus, demander à un LLM (GPT-4o, Mistral Large) de générer 3 à 5 questions auxquelles ce passage répond directement. On obtient des milliers de paires (question générée, passage source) sans annotation manuelle initiale.
Sur un corpus de 1 000 passages, on peut générer 3 000 à 5 000 paires en quelques heures. C'est suffisant pour un premier fine-tuning utile. Mais — et c'est important — valider un échantillon de 100 à 200 paires manuellement avant de lancer l'entraînement. Si le taux de "bonne paire" est inférieur à 75-80 %, revoir le prompt de génération.
Embedding générique vs fine-tuné : ce que les chiffres donnent
| Critère | Modèle générique (e5 / BGE / GTE) | Modèle fine-tuné sur le domaine |
|---|---|---|
| Recall@5 sur corpus généraliste (français courant) | 70–85 % | 72–87 % (+2 à +5 pts) |
| Recall@5 sur corpus à jargon très spécialisé | 40–60 % | 60–80 % (+10 à +25 pts) |
| MRR sur nomenclatures internes | Faible | Fort (×1,5 à ×2) |
| Coût d'inférence | Identique | Identique (même architecture) |
| Temps de mise en place | Nul (prêt à l'emploi) | 1 à 3 semaines (données + entraînement) |
| Maintenance si le corpus évolue fortement | Aucune | Réentraînement périodique nécessaire |
| Cas recommandé | Français professionnel courant, vocabulaire standard | Jargon propriétaire, nomenclatures, domaine sous-représenté |
Ces ordres de grandeur sont cohérents avec les résultats publiés sur le MTEB Leaderboard (Massive Text Embedding Benchmark), la référence publique pour comparer les modèles d'embeddings sur des tâches de retrieval standardisées. Un modèle spécialisé de taille intermédiaire fine-tuné sur son domaine cible peut surpasser un modèle générique bien plus grand — mais uniquement sur ce domaine. Hors domaine, les positions s'inversent souvent.
Pour une vue complète des leviers d'amélioration d'un RAG au-delà des embeddings (reranking, retrieval hybride, chunking adaptatif), notre article optimiser un système RAG couvre ces étapes complémentaires.
Outils et modèles de base : ce qu'on utilise en pratique
sentence-transformers : la librairie de référence
sentence-transformers (SBERT) est incontournable pour le fine-tuning contrastif de bi-encodeurs. Elle implémente toutes les pertes utiles (MNRL, TripletLoss, CoSENTLoss), intègre des évaluateurs de retrieval (InformationRetrievalEvaluator), et se branche sur n'importe quel modèle HuggingFace. Un entraînement sur 5 000 paires avec hard negatives prend 30 à 90 minutes sur GPU A100 — environ 3 à 8 € en cloud à la demande.
Quel modèle de base choisir ?
Trois familles dominent pour les projets en français :
- e5 (Microsoft) —
intfloat/multilingual-e5-large: excellent support multilingue dont le français, bien classé sur MTEB. Notre point de départ recommandé pour du français professionnel. La varianteintfloat/e5-mistral-7b-instructest plus lourde (7B paramètres) mais donne d'excellentes performances sur des corpus longs et complexes. - BGE (BAAI) —
BAAI/bge-m3: un des meilleurs modèles multilingues disponibles à ce jour, avec des performances de pointe sur les tâches de retrieval. L'écosystème FlagEmbedding propose un pipeline de fine-tuning complet avec mining de hard negatives intégré. Recommandé si vous prévoyez un processus rigoureux sur un corpus important. - GTE (Alibaba) —
Alibaba-NLP/gte-multilingual-base: léger, rapide, très bon rapport performance/coût d'inférence. Idéal pour les déploiements à scale où la latence compte.
Matryoshka Representation Learning : une option à connaître
Matryoshka (MRL) est une technique d'entraînement qui produit des embeddings tronçables : un même modèle génère des vecteurs de 1 024 dimensions utilisables à 64, 128, 256 ou 512 dimensions sans réentraînement. L'intérêt est pratique — selon vos contraintes de latence ou de coût de stockage dans la base vectorielle, vous choisissez la dimension adaptée. Plusieurs variantes e5 et BGE supportent déjà MRL. À intégrer si vous anticipez des contraintes d'infrastructure sur l'index.
Quand le fine-tuning d'embeddings vaut le coup (et quand non)
La question centrale : est-ce que le retrieval est vraiment le maillon faible de votre RAG ? Si votre Recall@5 est déjà supérieur à 80 % sur un set de test représentatif, regardez d'abord le chunking, le reranking, ou la génération. Le fine-tuning d'embeddings n'est pas la première optimisation à faire.
Signaux qui indiquent que ça vaut le coup :
- Votre corpus contient un jargon dense absent des données d'entraînement publiques.
- Vous observez des ratés évidents : des passages clairement pertinents que le retriever ne remonte pas dans le top 10.
- Votre Recall@5 sur un set de test domaine est inférieur à 65-70 %.
- Vous avez suffisamment de documents pour générer 1 000 paires minimum.
- Votre corpus est relativement stable sur 6 à 12 mois.
Signaux qui indiquent de ne pas le faire maintenant :
- Votre corpus change fortement tous les trimestres — le modèle fine-tuné se périme et un réentraînement régulier coûte cher.
- Vous n'avez pas 500 paires minimum de qualité validée — le résultat sera instable.
- Votre Recall@k est déjà bon — le problème vient d'ailleurs (génération, prompt, chunking).
- Vous n'avez pas encore établi de baseline et mesuré le Recall@k de votre système actuel.
Sur ce dernier point : on voit encore régulièrement des équipes qui lancent un fine-tuning d'embeddings sans avoir mesuré le Recall de base. C'est du tâtonnement coûteux. Commencez toujours par constituer un petit set de test (100 paires), mesurer les métriques du modèle générique, puis décider.
Les pièges à éviter : ce qui fait rater un fine-tuning d'embeddings
Piège 1 : trop peu de paires ou de mauvaise qualité
80 paires générées automatiquement sans validation, c'est le moyen le plus rapide d'obtenir un modèle instable. Le modèle apprend les artefacts de génération du LLM, pas les relations sémantiques utiles. En dessous de 300 paires de qualité vérifiée, mesurez impérativement sur votre set de test avant de conclure que ça a marché. La règle : 20 minutes de validation manuelle sur un échantillon de 50 paires avant de lancer l'entraînement complet.
Piège 2 : des négatifs trop faciles
Si tous vos négatifs sont des passages d'un domaine totalement différent, le modèle n'apprend rien de difficile. Il reste incapable de distinguer deux passages proches dans votre domaine — exactement là où votre problème de retrieval se concentre. Investissez dans les hard negatives. C'est là que se fait la différence entre un modèle "passable" et un modèle vraiment utile en production.
Piège 3 : sur-spécialisation (catastrophic forgetting)
Un learning rate trop élevé ou trop d'époques font oublier au modèle ses connaissances générales. Le Recall@5 progresse sur votre domaine cible mais chute sur des requêtes légèrement hors domaine. Résultat en production : 90 % des requêtes bien traitées, 10 % qui donnent des résultats absurdes. Pour l'éviter : learning rate ≤ 2e-5, 3 à 5 époques maximum, arrêt dès que la métrique de validation plafonne sur le set de test.
Piège 4 : oublier le set de test indépendant
Le classique. On mesure sur les données d'entraînement (ou sur un split aléatoire contaminé), le Recall@5 monte à 92 %, on déploie — et les utilisateurs remontent immédiatement des résultats dégradés. La règle absolue : le set de test ne doit jamais avoir été vu pendant l'entraînement, et au moins 80 % des paires doivent être validées manuellement par un expert métier. C'est lui qui dit si le fine-tuning a vraiment généralisé — pas la loss curve d'entraînement.
Piège 5 : ne pas comparer au modèle de base
Sans baseline, impossible de savoir si le fine-tuning a aidé. Mesurez systématiquement les métriques du modèle générique sur votre set de test avant tout entraînement. Si le gain est inférieur à 3 à 4 points de Recall@5 après fine-tuning, le problème n'est probablement pas dans les embeddings — regardez le chunking, le reranking, ou la formulation des requêtes.
Pour aller plus loin
- Guide technique : embeddings et recherche sémantique — comprendre les embeddings avant de les entraîner.
- Optimiser un système RAG de bout en bout — chunking, reranking, retrieval hybride, tous les leviers d'amélioration.
- Guide complet RAG — architecture, cas d'usage et décisions d'implémentation.
- Préparer un dataset de fine-tuning — méthodes d'annotation, génération synthétique et validation qualité.
- Comparatif des librairies de fine-tuning — sentence-transformers, PEFT, TRL, Unsloth : tradeoffs et cas d'usage.
- Comparatif des bases de données vectorielles pour le RAG — Qdrant, Weaviate, Chroma, pgvector.
- Notre service expert en fine-tuning embeddings et LLM — constitution des datasets, entraînement, déploiement en production.
- Documentation sentence-transformers — Training Overview : référence technique complète sur les pertes contrastives et les pipelines d'entraînement.
- MTEB Leaderboard (HuggingFace) : comparer les modèles d'embeddings sur des benchmarks de retrieval standardisés.
Vous hésitez encore ?
Votre RAG rate des passages évidents ? 30 minutes pour diagnostiquer si le fine-tuning de vos embeddings est la bonne réponse.
En résumé : fine-tuner les embeddings, oui — mais mesurer d'abord
Quand un RAG rate des passages évidents, l'erreur est presque toujours dans le retrieval, pas dans la génération. Et le retrieval, c'est les embeddings.
Le fine-tuning contrastif avec sentence-transformers sur vos paires domaine + hard negatives est l'intervention la plus chirurgicale pour corriger ce problème. Elle ne touche pas au LLM, ne modifie pas la base documentaire, ne change pas le pipeline — elle ajuste uniquement l'espace vectoriel pour que votre jargon soit correctement représenté.
Les gains sont réels et mesurables sur le Recall@k. Les prérequis sont raisonnables : 1 000 paires minimum, un set de test séparé, des hard negatives correctement minés. Les pièges sont évitables dès lors qu'on évalue sur des données que le modèle n'a pas vues. Mesurez la baseline d'abord. Entraînez ensuite. Validez avant de déployer. Le retrieval d'abord, toujours.
