Fine-tuning d’embeddings : le guide complet pour améliorer votre RAG

Quand et pourquoi fine-tuner ses embeddings ?

Les modèles d’embeddings génériques excellent sur des corpus vastes et variés, mais ils montrent leurs limites dès que votre domaine introduit un vocabulaire spécialisé. Sur des données financières, juridiques ou techniques, ces modèles échouent souvent à capturer les nuances sémantiques spécifiques : deux documents parlant de « charge » (facturation ou responsabilité) se retrouvent incorrectement rapprochés ou éloignés. Le fine-tuning consiste à ré-entraîner le modèle sur vos données métier pour qu’il apprenne ces distinctions fines.

• Échec des modèles génériques : vocabulaire spécialisé mal interprété, synonymes de domaine ignorés.
• Précision de retrieval insuffisante : les résultats pertinents sortent hors du top 10, le contexte récupéré est bruité.
• Amélioration du RAG : un fine-tuning ciblé améliore la précision de la recherche vectorielle, donc la qualité des réponses finales.
• Vérifier la cause du problème : analysez d’abord vos échecs de retrieval avant de lancer un entraînement.
• Éviter le fine-tuning si le keyword match suffit : si vos requêtes contiennent des termes exacts présents dans les documents, une simple recherche lexicale peut résoudre le problème.

Le fine-tuning ne doit pas être votre première action. Posez un pipeline d’évaluation dès le départ, mesurez le recall de votre modèle de base, avant d’envisager d’entraîner GPT-4o mini sur vos données, et n’envisagez l’entraînement que si les résultats ne satisfont pas vos exigences, un choix qui dépend de la fraîcheur de vos données et de votre budget, comme le montre la comparaison entre RAG ou fine-tuning. Un cas concret : sur 3 datasets métier testés, le fine-tuning a amélioré la précision de retrieval sur 2 d’entre eux. Sur le troisième, le modèle de base performait déjà suffisamment bien pour que l’entraînement n’apporte aucun gain mesurable.

Lorsque le fine-tuning est justifié, les gains sont significatifs : le modèle fine-tuné peut surpasser des API commerciales comme text-embedding-3-large sur des domaines spécifiques, tout en restant auto-hébergé et gratuit à l’inférence. La clé est de savoir quand s’arrêter : si votre problème de retrieval vient d’un mauvais chunking, c’est-à-dire un découpage du texte inadapté, d’un manque de métadonnées ou d’une requête mal formulée, le fine-tuning ne résoudra rien.

Améliorer la performance RAG grâce au fine-tuning des embeddings

Le fine-tuning des embeddings agit directement sur la qualité du retrieval, le maillon le plus critique de tout pipeline RAG. Un modèle ajusté sur vos données de domaine surpasse souvent un modèle généraliste: sur FinanceBench et ManufactQA, un modèle fine-tuné a amélioré le recall au point de dépasser text-embedding-3-large d’OpenAI sur 2 datasets sur 3.

Attention au cas limite : si votre retrieval est déjà performant (comme sur le dataset Databricks DocsQA), le fine-tuning n’apporte rien. Testez d’abord votre pipeline avec un reranker, qui effectue un réordonnancement de résultats plus précis (par exemple voyageai/rerank-1 avec un top-k réduit de 30 à 10) pour isoler la vraie source du problème avant d’investir dans un entraînement, une étape qui affine les candidats du retriever pour améliorer la recherche.

La corrélation est nette : une meilleure récupération vectorielle améliore directement la réponse finale de GPT-4o. Améliorer ses embeddings, c’est donc améliorer toute la chaîne RAG, y compris pour des usages de RAG temps réel où la latence est critique, sans toucher au reste de l’infrastructure.

Pour déployer ces améliorations en toute sécurité, l’activation progressive via des feature flags permet de tester les nouveaux embeddings sur une partie du trafic avant généralisation.

Préparer et structurer son jeu de données pour le fine-tuning

La qualité de votre jeu de données est le facteur n°1 qui détermine la performance du modèle final. Un modèle entraîné sur des données bruitées ou mal structurées produira des embeddings médiocres, même avec une configuration d’entraînement parfaite. Avant de lancer un entraînement, il faut donc définir une stratégie claire pour obtenir des paires question-réponse pertinentes. Heureusement, vous n’êtes pas obligé de tout annoter à la main : il existe trois approches éprouvées, utilisées notamment par Databricks pour leurs pipelines de fine-tuning sur des domaines financiers et techniques.

Les trois méthodes pour construire son dataset d’entraînement

• Données réelles annotées manuellement : la méthode la plus fiable, mais la plus coûteuse en temps.
• Données synthétiques générées par LLM : idéale pour les domaines spécifiques, sans labeling manuel.
• GPL (Génération de Paires par LLM) : technique de distillation pour créer des paires à partir de vos documents.

La méthode synthétique, plébiscitée par Databricks, consiste à générer des questions à partir de vos propres documents, en s’appuyant sur des prompts structurés pour garantir des requêtes exploitables. Par exemple, ils ont utilisé un LLM pour créer des requêtes à partir de 2 400 documents SEC 10-K, ce qui a permis de constituer un superset de 360 filings pour le benchmark FinanceBench. Cette approche présente un double avantage : elle ne nécessite aucun labeling manuel, et elle garantit un chevauchement nul entre les requêtes d’entraînement et celles d’évaluation.

Structurer ses paires et triplets d’entraînement

Une fois vos données collectées, il faut les structurer. La méthode la plus efficace repose sur l’apprentissage contrastif : vous formez le modèle à rapprocher les paires de textes similaires et à éloigner les paires dissemblables. Pour ce faire, on utilise généralement des triplets : une requête « ancre », un document « positif » (le bon résultat), et un ou plusieurs documents « négatifs » (des résultats incorrects mais plausibles).

C’est ici qu’intervient la notion de hard negatives : des documents qui ressemblent fortement à la requête mais qui ne répondent pas à la question. Les inclure force le modèle à apprendre des nuances fines plutôt que des correspondances superficielles. Lors de vos entraînements, vous pourrez ajuster le nombre de négatifs dans le batch, la température de l’apprentissage contrastif, et le pooling. L’objectif est de trouver la combinaison idéale qui réduit au maximum la distance entre les textes sémantiquement proches, comme le montre l’accélération de 1.8 à 3.3x observée avec des librairies optimisées comme Unsloth.

La structure de vos données détermine aussi vos choix techniques : pour un triplet classique, vous utiliserez une perte contrastive comme MultipleNegativesRankingLoss, tandis que des paires simples nécessiteront des fonctions de perte dédiées. Prenez le temps de définir cette structure avant de lancer votre premier sweep d’hyperparamètres sur 1 à 3 époques.

Processus de fine-tuning d’embeddings pas à pas

Choisir son modèle de base et configurer l’entraînement

La sélection du modèle de base détermine la qualité finale de vos embeddings. Pour un choix éclairé, appuyez-vous sur le classement MTEB, qui évalue la performance des modèles sur une centaine de tâches de retrieval et de similarité. Celui-ci vous aidera à identifier un modèle générique robuste, avant de l’adapter à votre domaine.

• MTEB : Référence pour comparer les modèles d’embeddings
• 1 à 3 époques : Suffisant lors des premiers tests
• 3GB VRAM : Compatible avec le fine-tuning QLoRA
• 6GB VRAM : Requis pour la méthode LoRA standard
• EmbeddingGemma-300M : Supporte LoRA et QLoRA

Avec le workflow Unsloth, la configuration est simplifiée. Son API FastSentenceTransformer conserve la même interface que la bibliothèque classique, ce qui évite toute réécriture de votre pipeline de traitement. Il suffit d’adapter les hyperparamètres learning rate, batch size, température pour débuter l’entraînement sur un modèle comme EmbeddingGemma-300M, qui se contente de 3GB de VRAM en QLoRA pour un fine-tuning accessible, ou de 6GB de VRAM en LoRA.

Lancer le fine-tuning et sauvegarder son modèle

L’entraînement s’effectue sur vos paires ou triplets préparés. Grâce à l’optimisation d’Unsloth, le fine-tuning est accéléré de 1.8 à 3.3 fois par rapport à une approche classique avec SentenceTransformers, tout en maintenant la même qualité de résultats. Lors des phases de test, limitez-vous à 1 à 3 époques pour éviter le sur-apprentissage et évaluer rapidement la progression.

Une fois l’entraînement terminé, la sauvegarde s’effectue via les méthodes save_pretrained() pour conserver le modèle en local, save_pretrained_merged() pour fusionner les poids LoRA dans le modèle de base, ou push_to_hub() pour le partager. Votre modèle fine-tuné s’intègre alors directement dans des outils comme Weaviate, LangChain ou TEI, sans modification supplémentaire de votre infrastructure.

Fonctions de perte et techniques d’apprentissage contrastif

L’apprentissage contrastif est la pierre angulaire du fine-tuning d’embeddings. Son principe est simple : rapprocher dans l’espace vectoriel les paires question-réponse pertinentes, tout en éloignant les textes sans rapport. Cette méthode fonctionne sans données supervisées classiques : vos données d’entraînement se composent de paires positives et de négatives, sans étiquetage manuel.

Le choix de la fonction de perte dépend de votre objectif. La perte contrastive et la Multiple Negatives Ranking Loss sont les plus courantes pour le RAG. L’ajout de hard negatives des exemples négatifs très similaires aux positifs force le modèle à affiner ses distinctions. Les hyperparamètres comme le learning rate, la température ou le pooling influencent directement la qualité finale. Si vous manquez de données réelles, les données synthétiques générées par LLM sont une alternative viable pour enrichir vos triplets.

Évaluer son modèle fine-tuné et comparer à la baseline

Le tableau ci-dessus synthétise l’expérience menée par Databricks sur 3 datasets : FinanceBench, ManufactQA et DocsQA. La baseline gte-large-en-v1.5 est comparée au même modèle après fine-tuning sur des données de domaine. Les métriques utilisées sont le Recall@10 et le Recall@30, mesurés avec un top-k initial de 30 avant reranking, puis réduit à k=10 après réordonnancement.

Les résultats montrent que le fine-tuning améliore la précision sur 2 datasets sur 3. Sur FinanceBench, le recall progresse nettement, passant de 0,72 à 0,81 pour le Recall@10. ManufactQA suit la même tendance avec un gain de près de 10 points sur le Recall@30. En revanche, DocsQA affiche une quasi-stabilité (0,88 à 0,89) : le modèle généraliste était déjà performant sur ce domaine, et le fine-tuning n’apporte qu’un gain marginal.

Ce constat illustre un principe clé : le fine-tuning n’est utile que lorsque le modèle de base échoue sur les nuances spécifiques de votre domaine. Si la baseline atteint déjà un recall satisfaisant, l’effort d’entraînement peut s’avérer superflu. À l’inverse, sur des données de niche comme les filings SEC 10-K (2 400 documents utilisés pour générer les requêtes synthétiques), le gain est substantiel.

Pour comparer correctement votre propre modèle, mettez en place un pipeline d’évaluation standardisé avant de lancer l’entraînement. Utilisez un jeu de requêtes distinct de celui d’entraînement, comme Databricks avec ses 360 documents SEC 10-K réservés au retrieval. Attention : tout changement de modèle impose un re-embedding et une ré-indexation complète de vos données avant de pouvoir mesurer l’impact réel sur votre pipeline RAG.

Générer des données synthétiques avec un LLM pour enrichir son dataset

Lorsque votre domaine est trop spécifique ou que vous manquez de données réelles, un LLM peut générer un dataset d’entraînement sur mesure. Cette approche, utilisée par Databricks pour ses benchmarks, élimine le labeling manuel et accélère considérablement la préparation.

Principes de la génération de données synthétiques

La méthode repose sur un principe simple : le LLM rédige des requêtes à partir de vos documents métier. Concrètement, on fournit un extrait de texte au modèle, qui imagine la question qu’un utilisateur poserait pour trouver cette information. Les paires (requête, document) ainsi créées deviennent vos données d’entraînement.

Génération par document : le LLM crée des questions ciblées depuis chaque passage, produisant des paires question-réponse pertinentes.
Domaines sans données : les secteurs pointus (juridique, médical, technique) profitent d’un dataset immédiatement exploitable.
Volume insuffisant : synthétiser des milliers de requêtes compense le manque de données réelles et diversifie les formulations.
Superset de 360 filings SEC 10-K : Databricks a constitué un vaste corpus source pour générer un volume conséquent de requêtes FinanceBench.

Un point crucial : les requêtes synthétiques ne doivent jamais être utilisées pour l’évaluation finale. L’évaluation s’effectue avec un jeu de test distinct, excluant tout chevauchement avec les données d’entraînement générées.

Bonnes pratiques et limites des données synthétiques

La qualité du LLM générateur conditionne directement la pertinence de vos données. Un modèle puissant produira des requêtes variées et réalistes, tandis qu’un modèle faible générera des formulations artificielles qui nuiront au fine-tuning.

Cette technique brille particulièrement pour les domaines où les requêtes réelles sont rares (documents internes, jargon spécifique). Elle enrichit substantiellement le dataset, permettant au modèle d’apprendre des correspondances sémantiques fines. Privilégiez la diversité des formulations pour éviter que le modèle ne sature sur des patterns trop similaires.

Enfin, surveillez la longueur des séquences. Des documents comme les 10-K peuvent dépasser 512 tokens : adaptez la taille des passages fournis au LLM pour rester dans la fenêtre de contexte et obtenir des requêtes exploitables.