Le chatbot retrouve moins bien les procédures depuis le changement de modèle, mais aucune requête ne produit d’erreur. Les vecteurs ont toujours la dimension attendue et l’index contient le même nombre de documents. L’équipe ajuste le prompt, puis le nombre de résultats, sans retrouver la qualité précédente. Elle n’a pas encore vérifié si les questions et les documents sont représentés dans le même espace.
Le risque est de croire qu’une migration d’embeddings se résume à remplacer un nom de modèle dans la configuration. La dimension valide seulement une forme de données ; elle ne prouve pas leur compatibilité sémantique. Le changement doit porter sur un ensemble cohérent : transformation des documents, transformation des questions, index interrogé et règles qui rendent chaque passage admissible.
Nous allons construire une migration avec deux collections séparées, suivre les modifications intervenues pendant le recalcul et décider quand basculer ou revenir en arrière. Le laboratoire associé calcule des cosinus sur des vecteurs manuscrits et contrôle un journal documentaire fictif. Aucun modèle d’embedding, moteur distribué ou LLM n’est exécuté ; ces résultats ne constituent donc pas un classement de fournisseurs ni un benchmark de pertinence.
Notre accompagnement en IA et automatisation métier relie cette évolution technique à la fiabilité du service rendu. Pour un RAG connecté aux documents de l’entreprise, la recette doit montrer quelles preuves restent accessibles, actuelles et utiles après la migration. Une meilleure réponse de démonstration ne suffit pas à accepter le changement sur tout le corpus.
Pour qui : une recherche déjà utilisée qui doit changer de représentation
Partir d’une raison de migration mesurable
Une équipe peut vouloir améliorer la récupération multilingue, réduire un coût de traitement ou remplacer un modèle qui ne convient plus à ses contraintes d’exploitation. Ces motifs ne demandent pas la même preuve. Pour une base de maintenance bilingue, le critère peut être la récupération d’une procédure française à partir d’une question anglaise ; pour un corpus de références, il peut concerner des codes proches.
Écrivez cette attente avant le recalcul. Si la difficulté vient d’un document absent ou mal extrait, changer l’embedding risque seulement de reproduire le défaut avec une facture supplémentaire. Le diagnostic de recherche hybride et de reclassement RAG aide à localiser cette perte. Une migration doit répondre à une cause ou à une contrainte identifiée, pas au seul intérêt d’un nouveau modèle.
Maintenir la distinction entre moteur de recherche et réponse générée
Le modèle qui représente les documents peut changer sans que le modèle chargé de rédiger la réponse change. Inversement, améliorer la génération ne répare pas automatiquement les passages récupérés. Dans le dossier de migration, nommez ces composants séparément. Cette séparation évite de découvrir trop tard qu’une expérimentation a modifié simultanément la recherche, le prompt et le format de réponse.
Si vous changez aussi le découpage ou l’OCR, traitez l’ensemble comme une nouvelle chaîne documentaire. Vous pourrez comparer sa qualité globale, mais vous ne pourrez pas attribuer chaque variation à l’embedding seul. Pour isoler ce facteur, conservez d’abord les mêmes passages et les mêmes questions de contrôle. Le bénéfice métier doit rester compréhensible au-delà du nom commercial du modèle.
Ce que les sources imposent à la compatibilité des vecteurs
Dans sa publication du 22 octobre 2026 sur les embeddings dans Agent Framework pour Go, Microsoft recommande de régénérer les représentations stockées lors d’un changement de modèle, même lorsque les dimensions restent identiques. Le framework présenté y est encore en préversion publique. Ce conseil de compatibilité ne constitue pas une validation de migration de votre corpus.
La documentation Azure AI Search sur la génération des embeddings rappelle également d’utiliser le même modèle pour indexer et interroger. Selon le fournisseur, les traitements des questions et des documents peuvent utiliser des paramètres adaptés à leurs rôles. Il faut qualifier la paire prévue, sans déduire que deux sorties de taille identique sont interchangeables.
Les exemples de Google Cloud pour les embeddings textuels exposent notamment le type de tâche, la dimension demandée et des statistiques de troncature. Ces paramètres montrent pourquoi un nom de modèle seul ne décrit pas tout le calcul. Conservez les valeurs réellement utilisées et les limites d’entrée applicables au modèle retenu, plutôt que des valeurs copiées d’un autre déploiement.
Définir le profil de recherche avant de toucher aux collections
Relier version du modèle, préparation et index physique
Nous proposons un profil immuable par version de recherche. Il indique modèle ou déploiement effectivement résolu, dimensions, préparation des passages, préparation des questions, métrique de distance et collection cible. Le profil documentaire et le profil de requête peuvent avoir des paramètres distincts, mais leur association doit être qualifiée. Un changement de préfixe d’entrée ou de normalisation demande lui aussi une vérification.
Ajoutez la version de découpage et l’empreinte des passages utilisés au recalcul. Le dossier sur la comparaison des découpages documentaires précise les conditions à conserver. Un index produit à partir de fragments différents ne peut pas être présenté comme une simple substitution de vecteurs. L’équipe doit retrouver la relation entre une source, sa révision et les fragments réellement inscrits.
Refuser les assemblages inconnus à la frontière de recherche
Le service reçoit en entrée une question autorisée et une version de recherche choisie. Il résout cette version une fois, puis utilise le profil de requête et l’index associés pendant toute l’exécution. Sa sortie conserve la version servie avec les identifiants des passages. Cette traçabilité permet d’expliquer une réponse pendant une période où plusieurs versions fonctionnent simultanément.
Un contrôle d’intégration doit refuser une paire non déclarée avant la recherche vectorielle. La responsabilité du mapping appartient au service, pas au texte de la question ni à une décision improvisée du LLM. Vérifiez également le contrat des tâches différées : une tâche créée sous la version A ne doit pas résoudre silencieusement la configuration B au milieu de son traitement.
Exemple concret : mêmes dimensions, premier résultat inversé
Le premier scénario utilise deux documents et deux représentations inventées à deux dimensions. D01 est la procédure attendue ; D02 représente une autre procédure. Les coordonnées sont choisies à la main pour isoler l’effet d’un mélange. Elles ne sont pas produites par un modèle et ne mesurent pas la proximité linguistique réelle des textes.
| Élément | Espace A | Espace B |
|---|---|---|
| D01 attendu | (1 ; 0) | (0 ; 1) |
| D02 différent | (0 ; 1) | (−1 ; 0) |
| Question correspondante | (1 ; 0) | (0 ; 1) |
Avec la question A dans l’index A, le cosinus de D01 vaut 1 et celui de D02 vaut 0. Avec la question B dans l’index B, le résultat reste D01. En revanche, la question B confrontée aux anciens vecteurs A place D02 en tête. Le calcul fonctionne parfaitement ; c’est son interprétation qui devient incorrecte parce que les représentations ont été mélangées.
Le programme local de migration des embeddings reproduit cette inversion, puis vérifie qu’un contrôle de profil refuse la combinaison B/A. Il vérifie aussi un écart de dimensions. Ces deux refus protègent des contrats différents : le premier vise une incompatibilité déclarée de représentation, le second une incompatibilité de forme. Aucun des deux ne démontre encore la qualité sémantique d’un candidat réel.
Quatre documents ne prouvent pas que le nouveau corpus est à jour
Le second scénario commence avec quatre documents fictifs D01 à D04, au point 40 d’un journal local. Pendant la reconstruction, D03 est retiré, D04 reçoit un nouveau tarif, D05 est ajouté et D02 devient réservé à la finance. Le nombre de documents actifs reste égal à quatre, mais leur identité, leur révision et leur portée d’accès ont changé.
| N° | Changement fictif | Preuve attendue dans le candidat |
|---|---|---|
| 41 | Retrait de D03 | D03 n’est plus proposé à la recherche. |
| 42 | D04 passe du tarif 100 au tarif 120 | La révision 2 remplace la révision 1. |
| 43 | Ajout de D05 | La nouvelle procédure figure dans l’inventaire. |
| 44 | D02 réservé à la finance | Alice ne peut plus recevoir ce document. |
Avant rattrapage, le candidat contient D01, D02, D03 et D04 dans leurs états initiaux. Après rattrapage, il contient D01, D02, D04 et D05 avec les nouvelles métadonnées. Alice peut consulter D01, D04 et D05 ; la finance peut également consulter D02. Un contrôle limité au compteur global donnerait le même résultat avant et après, malgré ces différences décisives.
Le laboratoire rapproche des métadonnées locales, sans calculer d’embeddings pour ce corpus de quatre documents. Il teste la conservation des identités, révisions, contenus et lecteurs. En production, il faut ajouter la preuve que les vecteurs correspondent réellement aux bons passages et au bon profil. Inscrire « modèle B » dans une colonne ne prouve pas que le calcul a utilisé ce modèle.
Construire le candidat sans perdre les changements en cours
Choisir un point de départ et une méthode de rattrapage explicites
Une stratégie consiste à produire le candidat à partir d’un état source identifié, puis à appliquer les changements ultérieurs. Elle suppose de disposer d’un journal fiable ou d’un moyen équivalent de rapprochement. Le scénario numéroté de 40 à 44 est une simplification pédagogique ; votre GED ou votre stockage documentaire peut proposer un autre mécanisme, voire aucun historique suffisant.
Si la source ne fournit pas de journal exploitable, prévoyez une comparaison d’inventaires, une fenêtre de gel autorisée ou une autre procédure dont la couverture peut être démontrée. Ne promettez pas une migration sans interruption par défaut. Le choix dépend du volume, de la fréquence des modifications et de la capacité à identifier ce qui a été retiré depuis le début du recalcul.
Empêcher une ancienne tâche de réintroduire un état dépassé
Une tâche lente peut terminer l’indexation de D04 révision 1 après le traitement de sa révision 2. Le consommateur doit comparer la version source avant d’accepter cette écriture. Dans le laboratoire, l’ordre est porté par une séquence locale ; une tentative plus ancienne est refusée. La file conserve ainsi un traitement explicable plutôt qu’une règle « dernière réponse réseau gagnante ».
Le même contrôle s’applique au retrait de D03. Conserver un marqueur de suppression permet de rejeter une ancienne tâche qui tente de remettre le document en circulation. Cette méthode proposée exige une durée de conservation et une politique adaptées au système réel. Le dossier sur le retrait d’un document RAG et de ses dérivés complète les contrôles de cache, d’historique et de réingestion.
Transporter les droits sans transformer la reconstruction en ouverture d’accès
Le nouveau pipeline peut extraire correctement les textes tout en perdant leurs métadonnées d’autorisation. Une recherche qui retrouve davantage de passages peut alors sembler meilleure parce qu’elle voit des documents interdits. Gardez la même règle d’admissibilité lors de la comparaison A/B et vérifiez les résultats pour plusieurs profils de lecteurs. Le rappel seul ne qualifie pas le service.
Dans notre exemple, D02 reste présent pour la finance après le point 44, mais disparaît pour Alice. Sa suppression globale serait donc une mauvaise correction. Le système doit conserver le document et appliquer sa nouvelle portée. Les contrôles d’accès sur passages, citations et réponses conservées doivent être rejoués sur la version candidate, y compris après une révocation récente.
Traitez les résultats de recherche, le contexte envoyé au modèle et les caches comme des sorties distinctes. Une réponse déjà préparée sous une ancienne autorisation peut rester dangereuse après la bascule. La politique de cache doit inclure les identités et versions pertinentes, puis revérifier l’accès au moment approprié. Changer le nom de collection n’applique pas à lui seul une nouvelle politique de confidentialité.
Évaluer la récupération avant d’interpréter une meilleure moyenne
Comparer les mêmes besoins sur des corpus rapprochés
Conservez un jeu de questions dont les sources attendues sont annotées : référence exacte, paraphrase, question multilingue, condition répartie entre plusieurs passages et demande sans réponse autorisée. Fixez la profondeur de récupération et les règles de filtre pour la comparaison. Si le candidat reçoit davantage de documents que la référence, qualifiez cette différence avant d’attribuer un gain au modèle.
Mesurez d’abord la présence des preuves nécessaires, puis leur rang et leur conservation dans le contexte final. Le dossier sur les évaluations de régression entre versions IA explique comment conserver les pertes critiques derrière une moyenne. Les résultats de notre laboratoire géométrique ne remplacent pas cette évaluation sur des questions métier et des embeddings réellement calculés.
Établir les seuils qui bloquent une bascule
Définissez avec le responsable métier un seuil minimal par famille de questions et des erreurs qui interdisent l’ouverture. Une fuite documentaire ou la récupération d’un tarif retiré peut constituer un veto même si le rappel global progresse. La latence et le coût doivent également rester compatibles avec l’usage. Ces seuils appartiennent au projet ; aucun pourcentage universel ne garantit qu’un RAG soit prêt.
Réévaluez les éventuels seuils de similarité utilisés pour l’abstention. Une valeur de cosinus acceptable avec l’ancienne représentation ne conserve pas automatiquement sa signification avec la nouvelle. Garder le même seuil sans contrôle peut multiplier les réponses sans preuve ou les refus injustifiés. Examinez les distributions et les cas limites du jeu, puis faites accepter la règle qui transforme le score en décision.
Basculer un ensemble cohérent plutôt qu’un alias isolé
Microsoft recommande, dans sa documentation de mise à jour et reconstruction d’un index Azure AI Search, de préparer et tester un nouvel index à côté de l’ancien pour les changements de schéma en production. Un alias peut faciliter le changement de cible. Il ne décrit cependant pas à lui seul le modèle utilisé pour transformer la question dans votre application.
Notre architecture proposée versionne donc un ensemble comprenant profil de requête, collection physique, règles de recherche et politique de cache. Une requête déjà commencée termine avec l’ensemble qu’elle a résolu ; une nouvelle requête reçoit la version retenue pour son périmètre. Le déploiement doit vérifier ce comportement dans les travailleurs, les API et les tâches asynchrones, sans supposer une mise à jour instantanée de tous les processus.
La supervision distingue le trafic A du trafic B et rattache chaque résultat à sa version. Elle suit les refus de profil, les pièces attendues absentes et les erreurs d’indexation. Pour une ouverture progressive, choisissez un périmètre que le support sait identifier. Le pourcentage de trafic routé ne remplace pas une observation de l’usage réel ni l’examen des questions qui régressent.
Le retour arrière n’est sûr que si l’ancien index reste admissible
Conserver les changements nécessaires pendant la période de comparaison
Garder l’index A en stockage ne suffit pas à préparer un rollback. Si A est resté au point 40 alors que les sources ont atteint 44, le retour réintroduirait D03 et l’accès d’Alice à D02. Dans le laboratoire, cette cible est refusée. Il faut soit maintenir A à jour avec son propre profil, soit le rapprocher avant de l’utiliser à nouveau.
Le runbook de repli indique la responsabilité de cette synchronisation, les dépendances nécessaires et la preuve de sortie attendue. Si l’ancien modèle n’est plus disponible ou si l’index ne peut plus recevoir les changements, le repli prévu peut être impossible. Le service doit alors choisir une autre option autorisée : recherche documentaire limitée, suspension de génération ou traitement humain selon la criticité.
Limiter la coexistence au temps nécessaire à une décision
Deux index maintenus en parallèle entraînent stockage, calcul de nouveaux vecteurs, contrôles supplémentaires et support de deux configurations. Ce coût caché peut dépasser le coût du recalcul initial si personne ne décide de fermer la période de migration. Fixez une date de revue et des conditions de retrait de l’ancienne version, sans confondre retrait du trafic et suppression définitive des preuves utiles.
Avant de retirer A, confirmez que les tâches différées, les caches et les intégrations n’y font plus référence. Préservez ce qui permet de comprendre les résultats de la recette, selon les contraintes documentaires applicables. Une fois le repli abandonné, mettez à jour le dossier d’exploitation : le support ne doit pas suivre une procédure qui renvoie vers une collection devenue indisponible.
Erreurs fréquentes : trois raccourcis qui rendent la migration trompeuse
Considérer le chargement terminé comme une preuve de recherche
Un lot d’écriture accepté ne démontre pas que chaque document est immédiatement interrogeable ni que chaque résultat correspond à la révision attendue. Contrôlez les erreurs par élément et vérifiez les lectures après ingestion. Un indicateur de fin de tâche doit conduire à une recette de disponibilité, pas directement à la bascule du trafic utilisateur.
Un signal faible est une augmentation des passages sans version ou sans empreinte après le recalcul. Un autre est un résultat qui change selon le serveur applicatif alors que la question et les droits sont identiques. Ces anomalies peuvent révéler une configuration partiellement déployée ou un cache commun à plusieurs profils. Les masquer par un nouveau prompt laisserait la cause intacte.
Confondre nombre de vecteurs, nombre de sources et couverture métier
Le découpage peut produire plusieurs fragments par source. Un volume de vecteurs supérieur ne signifie donc ni davantage de documents utiles ni une meilleure couverture. Rapprochez les identifiants de source et de fragment avec les révisions attendues. Les suppressions partielles ou les fragments orphelins doivent apparaître dans ce bilan, sans être noyés dans le total du nouvel index.
La métrique « coût par million de tokens » ne décrit pas non plus le coût complet de migration. Ajoutez extraction, reprise des échecs, indexation, comparaison, coexistence et intervention métier. Le budget doit permettre de suspendre une reconstruction qui rejoue inutilement des passages inchangés. Une économie sur le modèle peut être absorbée par un pipeline qui perd la trace de ce qu’il a déjà traité.
Plan d’action : décider sur compatibilité, fraîcheur et qualité
Préparer une migration dont le périmètre peut être reçu
Choisissez une collection et une population de lecteurs que l’équipe documentaire peut suivre. Relevez la configuration A, les sources attendues et les défauts qui motivent B. L’équipe d’intégration décrit les transformations, les points de reprise et le mécanisme de collecte des modifications. Le propriétaire métier fournit les questions et les documents qui rendront la comparaison utile, y compris des cas de refus.
Le premier livrable est un contrat de migration : profil A, profil B, inventaire initial, stratégie de rattrapage et conditions de repli. Il doit permettre de rejeter une combinaison inconnue et de retrouver la provenance d’un passage. Exécutez le laboratoire local pour comprendre les contrôles, puis adaptez les essais aux capacités réelles de votre stockage et de votre fournisseur d’embeddings.
Recevoir les données avant d’accepter la nouvelle recherche
Construisez B sans lui envoyer immédiatement les utilisateurs. Rapprochez les identités, les révisions et les droits au point de contrôle choisi. Vérifiez ensuite la recherche sur le jeu annoté, puis la génération et ses citations. Conservez les traces des questions dégradées avec la cause identifiée ou la limite restante. Un résultat manquant ne doit pas disparaître de l’évaluation parce que son diagnostic demande davantage de travail.
- À faire : refuser le mélange de profils, rapprocher les changements et contrôler les lecteurs avant la bascule.
- À différer : étendre le trafic tant que la fraîcheur du candidat ou la portée des régressions reste inconnue.
- À refuser : conserver un ancien droit, un document retiré ou une combinaison incompatible pour améliorer une métrique de rappel.
La décision documente séparément compatibilité, couverture du corpus, admissibilité des passages et qualité de récupération. Le responsable produit peut ainsi accepter un progrès limité à une population ou demander une correction précise. Il ne signe pas un « meilleur RAG » abstrait, mais une version définie, évaluée sur un périmètre et accompagnée de conditions d’arrêt compréhensibles.
Ouvrir, observer et fermer la période de coexistence
Déployez le routage de version avec une instrumentation qui distingue A et B. L’exploitation vérifie les traces de requête, les erreurs d’ingestion et les retards du journal. Le support reçoit une procédure pour reproduire un problème avec la version réellement servie, sans exporter inutilement les documents sensibles. Un incident critique déclenche le repli qualifié ou la suspension prévue, selon l’état disponible.
À la revue de migration, comparez les résultats métier, le coût complet et les incidents observés. Décidez de poursuivre B, de corriger son profil ou de revenir à une configuration admissible. Lorsque la décision devient stable, retirez les dépendances devenues inutiles et actualisez le dossier d’exploitation. La migration est terminée lorsque le service sait fonctionner et être repris avec la version retenue, pas au dernier vecteur calculé.
Contenus liés : diagnostiquer ce qui reste dégradé après migration
Lorsque le candidat est compatible et à jour mais que le passage attendu reste absent, examinez la récupération par recherche hybride et reranking. Le point à observer devient la liste des candidats, sa profondeur et la sélection remise à la génération. Une bascule correctement exécutée peut conserver un problème de récupération que l’ancien système possédait déjà.
Lorsque les passages sont présents mais que certaines réponses régressent, utilisez la comparaison des versions IA à données constantes pour isoler les cas concernés. Les preuves de migration décrivent le contenu servi ; les preuves d’évaluation décrivent son utilité pour les questions retenues. Garder ces deux dossiers permet de corriger une faiblesse sans reconstruire inutilement un index déjà cohérent.
Conclusion : migrer une chaîne de preuve, pas seulement des vecteurs
Changer d’embeddings modifie la manière dont le système rapproche une question des documents. La bonne dimension permet un calcul, mais seule une association qualifiée entre représentation de requête et index rend ce calcul interprétable. L’exemple manuscrit montre comment un résultat peut s’inverser sans erreur technique ; il ne remplace pas la mesure de pertinence sur votre corpus réel.
La migration doit aussi conserver ce qui a changé pendant le recalcul. Dans le scénario documentaire, quatre entrées avant et après masquent un retrait, une nouvelle procédure, un tarif modifié et un accès restreint. Ces différences doivent rester explicables lors de la bascule comme lors du repli. Un index ancien est une solution de secours seulement si son contenu et ses droits restent admissibles.
Pour préparer cette évolution, notre offre de RAG documentaire pour l’entreprise associe inventaire des sources, profils de recherche, évaluation et reprise. Le travail commence par les passages utiles au métier et les limites du système existant, puis établit les preuves nécessaires pour accepter une nouvelle version sans ouvrir de droits ni perdre des documents silencieusement.
Dawap vous accompagne dans la conception et l’industrialisation de vos systèmes IA avec des critères de décision vérifiables. Nous relions la qualité de réponse aux documents, aux accès et aux composants effectivement servis. Cette chaîne permet à vos équipes de choisir une évolution, d’en expliquer les limites et de revenir à un fonctionnement maîtrisé lorsqu’un résultat se dégrade.
