Changer de modèle d'embedding RAG : migrer un chatbot IA sans lacune de connaissances

Un modèle d'embedding fonctionne généralement de manière invisible en arrière-plan d'un chatbot RAG. Il traduit les questions et les fragments de connaissances en vecteurs numériques afin d'identifier les contenus sémantiquement pertinents. C'est précisément parce que cette brique apparaît rarement sur une interface utilisateur qu'un changement de modèle peut sembler être une simple modification de configuration. Techniquement, cela crée pourtant un nouvel espace de recherche. Les vecteurs de documents existants, les vecteurs des nouvelles questions et la définition de l'index doivent à nouveau correspondre parfaitement.

Si vous souhaitez changer les embeddings RAG, vous ne devez pas simplement remplacer le nom du modèle dans le pipeline de requêtes. Une migration sécurisée traite le nouvel index comme une version à part entière : construite de manière reproductible, testée avec les mêmes questions de validation, exploitée en parallèle dans un premier temps et activée seulement après une décision de validation explicite. Le chatbot du site web reste ainsi disponible tandis que l'équipe conserve le contrôle sur la qualité, la latence, les coûts et la stratégie de repli.

Pourquoi les embeddings ne sont pas interchangeables à volonté

Un vecteur n'a de sens que dans l'espace où il a été généré. La documentation officielle d'Azure AI Search sur la création d'un index vectoriel décrit l'index comme un espace d'embeddings composé de vecteurs issus du même modèle. Elle indique également que la dimension de chaque vecteur doit correspondre à la définition du champ. Un nouveau modèle peut avoir une dimension différente, des forces linguistiques distinctes ou une répartition différente des distances sémantiques.

Le côté requête est tout aussi crucial. Selon la documentation Microsoft sur la configuration des vectoriseurs, l'indexation et la requête doivent utiliser le même modèle d'embedding. Si une équipe mélange d'anciens vecteurs de documents avec des questions générées par un nouveau modèle, les scores de similarité ne sont plus interprétables de manière fiable. Même si la dimension est accidentellement identique, cela ne prouve en aucun cas une compatibilité sémantique.

Définir un objectif mesurable avant le changement

« Plus récent » n'est pas un critère de recette suffisant. Avant la première réindexation, l'équipe a besoin d'un motif concret pour la migration. Souhaitez-vous améliorer la qualité des résultats dans un jargon technique spécifique ? Des langues supplémentaires sont-elles nécessaires ? Le modèle actuel est-il obsolète, trop lent ou trop coûteux ? Ou une dimension vectorielle plus petite doit-elle économiser de la mémoire ? C'est à partir de cet objectif que découlent les métriques de comparaison.

• Qualité : sources pertinentes dans le Top-k, proportion de questions auxquelles le système peut répondre et qualité de la réponse finale.
• Exploitation : latence de recherche (retrieval), taux d'erreur, durée d'indexation et comportement en cas d'erreurs partielles.
• Coûts : vectorisation de l'ensemble de la base, modifications quotidiennes, stockage et requêtes.
• Couverture : documents, langues, versions de produits et périmètres d'autorisations dans le nouvel index.

Les valeurs initiales doivent figurer dans le même rapport de validation que les résultats du modèle candidat. Si vous entretenez déjà un Golden Set pour cela, vous pouvez utiliser le guide existant sur la mesure de la qualité des réponses d'un chatbot IA comme base de travail. L'important est de ne pas comparer seulement un score moyen : les questions de support critiques, les termes techniques rares et les cas sans résultat méritent leurs propres évaluations.

Deux index plutôt qu'une modification sur le système en production

La norme éprouvée consiste à créer un index parallèle. L'ancien index reste inchangé et sert le trafic en direct. À côté, une nouvelle collection ou un nouvel index est créé avec ses propres identifiants de modèle, dimension, métrique de distance et numéro de version. Les deux sont construits à partir de la même version source validée. Cela permet d'attribuer les différences au modèle ou à la configuration de l'index, plutôt que de comparer des contenus qui évoluent simultanément.

Le tutoriel officiel Weaviate sur le changement de vectoriseur illustre cette approche avec des collections séparées et un alias comme point de basculement réversible. Le produit spécifique est interchangeable ; le principe reste précieux : isoler proprement les anciens et nouveaux embeddings, diriger l'accès via un routeur contrôlé ou un alias, et conserver l'ancien état pendant une période de rétrogradation limitée.

Des identités stables pour chaque fragment de connaissance

Chaque chunk (fragment) nécessite un identifiant métier stable qui ne dépend pas du vecteur. Une combinaison judicieuse comprend l'ID source, la version source, la section et la version du chunk. De plus, chaque enregistrement doit porter le nom du modèle, sa version, sa dimension, la date de création et le hash du texte vectorisé. De cette façon, le pipeline peut identifier précisément ce qui a déjà été traité, ce qui doit être à nouveau vectorisé et les erreurs encore ouvertes.

Spécifier le nouveau pipeline de manière reproductible

Avant la grande phase de réindexation globale (backfill), un petit échantillon représentatif doit passer par le nouveau pipeline. L'extraction, le nettoyage et le découpage RAG (chunking) restent inchangés dans un premier temps. Si l'équipe modifie simultanément le modèle, les limites des chunks, les métadonnées et le classement, toute différence de qualité ultérieure sera presque impossible à expliquer.

La configuration doit figurer sous forme de manifeste versionné associé à l'exécution : modèle et fournisseur, dimension, normalisation, métrique de distance, taille des lots (batch), règles de réessai, version du découpeur, langues autorisées et métadonnées requises. Les identifiants d'accès doivent en être strictement exclus. Seuls les ID, compteurs, statuts et un code d'erreur sécurisé sont enregistrés pour chaque lot. Cela permet de reprendre un traitement interrompu sans réitérer inutilement des vectorisations réussies.

Ré-vectoriser de manière contrôlée et prouver l'exhaustivité

Une réindexation n'est complète que lorsque le contenu cible et le contenu réel correspondent. Un nombre élevé de documents ne suffit pas à lui seul. Le pipeline doit vérifier pour chaque source si tous les chunks attendus sont présents, si leurs hashs de texte correspondent à la version source validée et si toutes les métadonnées obligatoires ont été intégrées. Les enregistrements ayant échoué rejoignent une file de réitération limitée ; les erreurs permanentes restent visibles avec leur ID et ne doivent pas être masquées par un statut global au vert.

1. Geler ou marquer clairement la base source et la date de référence.
2. Créer la nouvelle structure d'index avec la dimension et la métrique appropriées.
3. Vectoriser et écrire les chunks par lots idempotents et limités.
4. Comparer les nombres de documents, chunks et métadonnées avec la base cible.
5. Contrôler un échantillon en vous appuyant sur le hash du texte, l'ID source et le contenu récupéré.

Comparer la recherche (retrieval) avec des questions identiques

Désormais, les mêmes questions de test sont exécutées sur les deux index. En plus du taux de réussite et de la position dans le classement, l'équipe doit comparer les sources effectivement retournées. Le nouvel index a-t-il placé en tête des sections sémantiquement proches mais factuellement incorrectes ? Perd-il des codes produits exacts ? Les termes composés ou les questions multilingues sont-ils mieux trouvés ? Un concept de recherche hybride et de reranking existant doit être configuré de manière identique pour les deux candidats afin d'assurer une comparaison équitable.

La documentation Azure sur la pertinence vectorielle et le classement mentionne la recherche exacte par plus proches voisins (k-nearest-neighbor) comme un moyen de construire un ensemble de référence (Ground Truth) pour évaluer le rappel (recall) d'un processus approximatif (ANN). Il ne s'agit pas d'un seuil universel, mais d'un test de contrôle utile : d'abord la référence exacte, puis la recherche de production plus rapide. Pour le chatbot, ce qui compte également est de savoir si les sources trouvées permettent une réponse correcte et étayée.

Vérifier la réponse finale et pas seulement les résultats bruts

Un meilleur rang de recherche ne garantit pas à lui seul une meilleure réponse du chatbot. C'est pourquoi la comparaison doit également couvrir le lien avec les sources, l'exhaustivité, l'incertitude autorisée et l'arrêt sécurisé en cas de preuves insuffisantes. Le modèle de réponse, l'instruction système et la température restent autant que possible constants. Sinon, le test mesurerait plusieurs changements en même temps.

Lectures fantômes (Shadow Reads) avant le vrai basculement

Après les tests hors ligne, une petite partie des requêtes réelles (traitées dans le respect de la sobriété des données) peut être exécutée en parallèle sur le nouvel index, sans afficher ses résultats aux utilisateurs. Cette lecture fantôme (Shadow Read) mesure le langage réel, la latence et le comportement face aux absences de résultats. Les contenus privés, les données personnelles et les historiques de conversation complets n'ont pas leur place dans les journaux de comparaison sans vérification préalable. Des classes de requêtes pseudonymisées, des ID de résultats et des métriques techniques suffisent souvent.

Le basculement (cutover) lui-même est une modification mineure et clairement observable : l'alias, la cible du routeur ou le feature flag passe de l'index A à l'index B. Durant la première phase, des seuils d'alerte plus stricts s'appliquent pour les sources manquantes, les erreurs de recherche, la latence et le taux de transfert vers un agent humain. Un basculement progressif est pertinent si l'architecture le supporte sans mélanger les états de session.

Tester le rollback dans la pratique avant de basculer

Un plan de rollback n'est fiable que si l'ancien index reste suffisamment à jour et si la procédure de retour arrière a été testée. Durant la phase parallèle, les sources nouvelles ou modifiées doivent donc alimenter de manière contrôlée les deux pipelines. Alternativement, l'équipe documente un court gel des modifications suivi d'une synchronisation claire. Le guide existant sur la réponse aux incidents et le rollback aide à déterminer les déclencheurs et les responsabilités.

Les signaux typiques de retour arrière ne sont pas seulement des erreurs techniques. Une chute nette des résultats pertinents dans le Top-k, de nouvelles lacunes linguistiques, un nombre anormalement élevé de questions sans réponse ou des filtres d'accès mal appliqués justifient également un retour en arrière. L'ancien index ne sera supprimé qu'une fois la période d'observation terminée, la validation de suppression documentée et aucune différence de qualité non expliquée ne restant ouverte.

Erreurs fréquentes lors de la migration d'embeddings

• Changer uniquement le côté requête : les nouveaux vecteurs de questions sont comparés avec un ancien espace documentaire.
• Confondre dimension identique et compatibilité : la longueur du vecteur et l'espace sémantique sont deux choses distinctes.
• Modifier plusieurs variables à la fois : modèle, chunking et classement changent en même temps ; la cause d'un effet devient impossible à isoler.
• Ne regarder que les moyennes : les questions rares, critiques pour l'entreprise ou multilingues sont noyées dans la moyenne.
• Nettoyer trop tôt : l'ancien index est supprimé avant que la charge réelle et les données de qualité ne confirment la stabilité.
• Oublier les filtres : la langue, la version et l'accès ne s'appliquent pas exactement dans le nouvel index comme dans l'ancien.

Checklist pratique pour les équipes web

• L'objectif, la référence, les critères de recette, le responsable de la validation et le signal de rollback sont documentés.
• L'ancien et le nouvel index restent séparés ; le modèle, la dimension et la métrique sont clairement versionnés.
• Les deux index proviennent de la même version source et de découpage validée.
• La réindexation est idempotente, peut être reprise et a été contrôlée par rapport à la base cible.
• Le Golden Set, les questions critiques, les langues, les cas sans résultat et les filtres d'accès réussissent la comparaison.
• Les Shadow Reads enregistrent uniquement les données techniques nécessaires.
• Le basculement et le retour arrière sont simples, observables et testés en pratique.
• L'ancienne base n'est supprimée qu'après la période d'observation et une validation documentée.

Conclusion : le nouvel espace vectoriel nécessite son propre processus de déploiement

Changer les embeddings RAG est une migration de données et de qualité, pas un simple interrupteur de modèle. Construire le nouvel espace de recherche séparément, ré-vectoriser l'intégralité du contenu, comparer à l'aide de questions identiques et activer via un point de basculement réversible réduit considérablement les risques de panne et de dégradation de la qualité. Pour les équipes web, la mise en place d'un processus réutilisable est très rentable : sécuriser la baseline, construire l'index parallèle, vérifier le retrieval et les réponses, observer les données fantômes, basculer de manière contrôlée et maintenir la voie de retour ouverte.

Si votre chatbot IA utilise déjà une base de connaissances RAG, ne commencez pas par la migration, mais par le jeu de données de test. Dix à vingt classes de questions particulièrement importantes, complétées par des cas complexes de langues, de produits ou d'autorisations, font toute la différence entre un changement de modèle incertain et un déploiement prouvé sécurisé.

Sources

• Microsoft Learn : Créer un index vectoriel dans Azure AI Search
• Microsoft Learn : Configurer un vectoriseur dans Azure AI Search
• Microsoft Learn : Pertinence dans la recherche vectorielle
• Documentation Weaviate : Changer de vectoriseur