Vous changez de modèle d’embeddings RAG ? Planifiez la migration de l’index avant de basculer

Considérez le changement d’embeddings comme une migration de données

Un système RAG génère généralement des embeddings du contenu source pour les stocker, ainsi que des embeddings des requêtes pour effectuer la recherche. Changer de modèle ou de dimensions peut donc nécessiter de réingérer les documents. La documentation de NVIDIA indique que les documents doivent être réingérés après ingestion si le modèle d’embeddings ou les dimensions changent, afin d’obtenir une recherche précise ([documentation NVIDIA](https://docs.nvidia.com/rag/latest/change-model.html)).

Ne traitez pas le changement comme une simple modification de paramètre : planifiez aussi le nouvel index et la configuration des requêtes qui l’utiliseront. Qdrant décrit une migration qui copie les données dans une nouvelle collection et ré-encode les vecteurs avec le nouveau modèle, tout en permettant de poursuivre les recherches pendant la migration ([documentation Qdrant](https://qdrant.tech/documentation/tutorials-operations/embedding-model-migration/)).

• Identifiez le modèle et la configuration ayant produit les vecteurs existants.
• Prévoyez comment créer le nouvel index et adapter le parcours des requêtes.
• Conservez l’index existant pendant la préparation et la validation du remplacement.

Inventoriez le parcours de recherche avant la reconstruction

Consignez le cheminement des données, du contenu source jusqu’aux passages récupérés. Un appel réussi au modèle d’embeddings ne suffit pas à vérifier que le nouvel index couvre bien les documents prévus ou que les métadonnées nécessaires à la recherche ont été conservées.

Rassemblez les paramètres actuels et ceux envisagés : modèles, dimensions attendues, extraction du texte, segmentation en blocs, métadonnées, filtres et paramètres de recherche. Notez aussi comment les documents sont identifiés, mis à jour et supprimés.

Si vous modifiez le prétraitement en même temps que le modèle, consignez ces changements séparément. Cela facilitera l’examen des différences observées pendant la validation.

• Corpus : sources, identifiants des documents, périmètre et exclusions.
• Embeddings : modèle actuel et modèle cible, configuration et dimensions attendues.
• Traitement : extraction, segmentation, transformations du texte et gestion des mises à jour.
• Recherche : métadonnées, filtres et paramètres utilisés par l’application.
• Opérations : tâche de reconstruction, accès requis et méthode d’examen des échecs.

Choisissez une méthode de migration adaptée à votre déploiement

La méthode dépend de la capacité de votre système à héberger plusieurs index, du rythme de mise à jour du corpus et de l’interruption acceptable. Les options ci-dessous sont des approches à évaluer pour votre configuration, pas des choix universellement adaptés.

Une reconstruction planifiée peut convenir si une période de maintenance est possible et que l’index précédent peut être conservé jusqu’à la vérification du nouveau. Des index parallèles permettent de préparer et d’examiner le nouvel index sans supprimer immédiatement le parcours existant. Un projet pilote sur un sous-ensemble peut éprouver le processus, mais ne valide pas à lui seul la migration complète.

• Évaluez une reconstruction planifiée si une interruption est acceptable.
• Envisagez des index parallèles si vous devez conserver l’accès au parcours existant pendant la préparation.
• Utilisez un projet pilote pour éprouver le processus, puis vérifiez séparément la reconstruction complète.
• Avant de commencer, vérifiez la capacité disponible et la façon dont les changements du corpus seront traités.

Ré-encodez et suivez la couverture du nouvel index

Construisez le nouvel index avec la configuration cible, puis vérifiez que le parcours des requêtes utilise la configuration prévue pour cet index. Contrôlez notamment que les dimensions des vecteurs correspondent à celles attendues par la destination.

Tenez un registre des éléments traités et des échecs. Lorsque c’est possible, comparez les enregistrements reconstruits au corpus prévu à l’aide d’identifiants stables. Examinez les éléments manquants, les doublons, les enregistrements ignorés et les documents modifiés pendant la tâche.

Si le contenu source peut changer pendant la reconstruction, définissez comment ces changements seront pris en compte dans le nouvel index. Par exemple, vous pouvez prévoir de suspendre les écritures ou de répercuter les mises à jour selon les possibilités de votre système.

• Utilisez la configuration cible d’embeddings pour les vecteurs du nouvel index.
• Vérifiez les dimensions attendues par l’index.
• Suivez les enregistrements traités, en échec, ignorés, modifiés et en double.
• Vérifiez comment les changements du corpus survenus pendant la reconstruction sont pris en compte.

Validez la recherche avant la bascule

Préparez des requêtes représentatives et identifiez les documents ou passages attendus avant de reconstruire l’index. Incluez des cas courants et des recherches qui utilisent des filtres de métadonnées importants pour votre application.

Testez le parcours réel d’encodage des requêtes et de recherche. Examinez les passages récupérés et leurs métadonnées, pas seulement la réponse finale. Définissez les critères d’acceptation adaptés à votre cas d’usage et consignez les différences à examiner.

Vérifiez aussi la couverture du corpus : des résultats satisfaisants sur quelques requêtes ne suffisent pas à établir que tous les documents prévus ont été indexés.

• Confirmez que des documents représentatifs sont présents dans le nouvel index.
• Examinez les passages récupérés pour des requêtes représentatives.
• Testez les filtres et les comportements de recherche importants pour l’application.
• Consignez les critères d’acceptation et les exceptions à résoudre.

Basculez de manière contrôlée et prévoyez le retour arrière

Consignez l’index et la configuration d’embeddings utilisés par l’application. Lors de la bascule, vérifiez que le parcours des requêtes et l’index cible sont configurés ensemble.

Convenez à l’avance de la durée d’observation, des critères pouvant justifier un retour arrière et des étapes pour rétablir le parcours précédent. Si le corpus continue à changer, prévoyez comment ces changements seront pris en compte en cas de retour à l’ancien index.

Ne nettoyez pas l’index précédent avant d’avoir accepté le nouveau parcours et vérifié les exigences de conservation applicables.

• Appliquez la bascule dans le cadre d’un changement contrôlé et vérifiez quelques requêtes connues.
• Conservez l’index précédent jusqu’à l’acceptation du nouveau parcours.
• Documentez les conditions, le responsable et les étapes du retour arrière.
• Vérifiez les exigences de conservation avant de planifier le nettoyage.

Conservez les décisions et les résultats de la migration

Désignez les personnes responsables de la configuration des embeddings et des opérations sur l’index. Conservez un dossier indiquant le périmètre du corpus, le modèle et les dimensions, les choix de prétraitement, les nombres d’éléments traités ou en échec, les résultats des tests et les instructions de retour arrière.

L’hébergement et la gestion de l’infrastructure ne déterminent pas quels documents doivent figurer dans l’index, qui peut les retrouver ni si la recherche est acceptable. Airbip gère le déploiement des applications de son catalogue sous forme de charges de travail Docker et propose des sauvegardes configurables ; les équipes doivent néanmoins planifier la migration des données RAG, les choix d’accès et la validation de leur propre configuration.

• Désignez les responsables de la configuration des embeddings et des opérations sur l’index.
• Conservez les paramètres et les résultats des tests associés à chaque index.
• Examinez séparément les choix d’accès, de conservation et de sauvegarde.