Changer de modèle d’embedding dans un RAG ne revient pas à remplacer le modèle qui rédige les réponses. Le premier transforme les textes en vecteurs pour la recherche ; le second formule une réponse à partir des passages retrouvés. Modifier seulement le premier nom dans les réglages peut donc laisser un système apparemment fonctionnel, mais incohérent avec son ancien index.
Ce guide documentaire propose une migration contrôlée, sans commande destructive ni promesse de meilleur classement. Sources officielles consultées le 27 octobre 2026 ; aucun corpus privé migré, aucun benchmark réalisé pour cet article. Les critères de validation ci-dessous sont une méthode proposée, pas un résultat de test.
Changer de modèle d’embedding : séparer recherche et rédaction
La documentation officielle d’Ollama sur les embeddings recommande le même modèle pour l’indexation et les requêtes. La documentation de Sentence Transformers décrit aussi une recherche où les documents et la question sont représentés dans le même espace vectoriel. Ces deux points fixent la première question : avec quel modèle les vecteurs déjà stockés ont-ils été calculés ?
On en déduit une précaution : ne présumez pas que deux modèles deviennent compatibles parce qu’ils produisent des vecteurs de même longueur. Cette longueur décrit un format, pas une preuve que les coordonnées portent le même sens. Conservez un index homogène et documenté plutôt que de mélanger les sorties au hasard.
Établir un état de départ qui permet de revenir en arrière
Avant tout changement, relevez le modèle actuel, sa révision si elle est identifiable, l’application, les règles de découpage et les paramètres de recherche. Notez également comment les documents et les questions sont préparés. Un nom raccourci dans une interface ne suffit pas toujours à reconstruire l’environnement.
Préservez les documents sources, leurs repères et une copie exploitable de la configuration. Le guide sauvegarder une IA locale et son index RAG traite cette étape. Ici, le but n’est pas de remplir un disque de copies : il est de garder une version identifiable à laquelle revenir si le nouvel index ne convient pas.
Construire un nouvel index à côté de l’ancien
La méthode prudente consiste à créer une collection distincte, puis à recalculer les représentations des passages avec le nouveau modèle. Ne modifiez pas d’abord la recherche utilisée au quotidien en espérant reconstruire les documents plus tard. Préparez la nouvelle chaîne avant de basculer son usage.
Pour comprendre l’effet du modèle, gardez d’abord le même corpus et les mêmes frontières de passages. Si vous changez simultanément l’OCR, le découpage, les filtres et le modèle, un progrès ou une régression devient difficile à expliquer. Un fichier récemment ajouté ne doit pas non plus être comparé à un ancien index qui ne le connaissait pas.
Respecter les rôles document et requête
Sentence Transformers distingue les recherches symétriques et asymétriques. Une courte question qui cherche un long passage n’a pas nécessairement le même traitement que deux phrases de longueur comparable. Sa documentation recommande les méthodes adaptées aux requêtes et aux documents dans les cas asymétriques ; les détails dépendent du modèle et de ses consignes.
En pratique, ne recopiez pas un préfixe trouvé pour un autre modèle. Lisez la documentation de celui que vous avez choisi, puis consignez le traitement de chaque côté. Un test utile vérifie la chaîne complète : le texte préparé, le calcul des vecteurs, la collection interrogée et les passages effectivement renvoyés.
Comparer des passages retrouvés, pas seulement des nombres
Reprenez un jeu de questions représentatives dont vous connaissez les sources utiles. Incluez des références exactes, des formulations différentes et quelques questions sans réponse dans le corpus. Notre guide du RAG local et de sa méthode de test explique pourquoi il faut séparer recherche et génération.
Pour chaque question, notez le passage attendu, sa présence parmi les premiers résultats et les passages inutiles qui le précèdent. Comparez les deux versions avec la même règle. Un score brut plus élevé dans le nouvel index n’établit pas à lui seul une amélioration : privilégiez la présence de la bonne source et la qualité de son classement.
| Contrôle | Preuve à conserver |
|---|---|
| Modèle et préparation | Identifiant, révision disponible, traitement des documents et requêtes |
| Corpus comparable | Liste des sources et règles de découpage utilisées pour chaque version |
| Recherche utile | Questions de référence, passages attendus et classement observé |
| Accès respectés | Essais avec les profils autorisés et refus attendus |
| Retour arrière | Version précédente identifiable et procédure de restauration vérifiable |
Basculer sans abandonner les autres contrôles
Avant d’utiliser le nouvel index, vérifiez les métadonnées, les versions de documents et les droits d’accès. Un bon passage retrouvé ne doit pas provenir d’un fichier que le lecteur n’est pas autorisé à consulter. Contrôlez aussi une suppression ou une mise à jour pour vous assurer que la nouvelle chaîne suit réellement votre corpus.
Conservez la version précédente le temps nécessaire à une validation organisée, selon vos règles de conservation et de confidentialité. Une copie d’index contenant des données sensibles reste une copie à protéger. Enfin, testez séparément les réponses du modèle rédacteur : une recherche améliorée ne garantit pas une citation fidèle ou une conclusion correcte.
Changer de modèle d’embedding est donc une migration de recherche, pas un simple changement d’étiquette. Identifiez l’ancien état, reconstruisez à part, comparez des sources retrouvées et basculez seulement avec des preuves. La meilleure version est celle qui répond à votre besoin documentaire, pas celle dont le nom paraît le plus récent.
