La dérive des embeddings survient lorsque la géométrie vectorielle ou les données représentées changent suffisamment pour que les vecteurs de documents stockés ne correspondent plus de manière fiable au comportement actuel des requêtes.
Un index privé peut continuer à renvoyer des voisins après un changement de modèle d'embedding, de pipeline OCR, de segmenteur ou de vocabulaire domestique, sans qu'aucune erreur évidente ne signale l'incompatibilité. Certains changements créent des espaces vectoriels incompatibles et nécessitent une reconstruction complète ; d'autres ne modifient qu'une partie du corpus ou de la distribution des requêtes et appellent un ré-embedding ciblé, une évaluation ou un recalibrage des seuils. La distinction dépend de la provenance et de la qualité mesurée de la récupération.
La dérive du modèle peut rendre les anciens et les nouveaux vecteurs incomparables
Un modèle d'embedding projette le texte dans un système de coordonnées appris à partir de ses paramètres et de son objectif d'entraînement. Un nouveau modèle, un fine-tuning, une méthode de pooling, une dimension ou une règle de normalisation peut faire pivoter et remodeler cet espace, même lorsque les deux sorties ont la même longueur.
Les travaux sur les représentations rétrocompatibles considèrent la compatibilité des embeddings comme un objectif d'entraînement explicite, car des embeddings appris indépendamment ne sont pas automatiquement interopérables. Sans cette garantie, les nouveaux vecteurs de requête ne devraient pas interroger un ancien index de documents. Cette distinction reste visible lors des tests domestiques ultérieurs.
Une incompatibilité de dimension échoue visiblement, mais des dimensions identiques peuvent échouer silencieusement. L'index accepte le vecteur et calcule un score de similarité précis dans un espace mixte dépourvu d'interprétation sémantique fiable. Le résultat intermédiaire doit rester inspectable avant toute automatisation.
La dérive du pipeline et des données modifie le sens sans changer le modèle
Les packs de langues OCR, la normalisation Unicode, les limites des segments, l'extraction des tableaux, les légendes et les préfixes de métadonnées modifient le texte présenté à un encodeur inchangé. De nouveaux termes domestiques ou types de documents peuvent également éloigner les distributions des requêtes et du corpus de l'ensemble d'évaluation.
MTEB montre une grande variation entre les tâches d'embedding selon la récupération, le clustering, la classification, les langues et les domaines. Un modèle qui reste techniquement identique peut donc devenir moins adapté à mesure que la collection privée évolue. Cette limite doit être mesurée séparément dans des conditions d'utilisation réalistes.
Un ré-embedding ciblé peut suffire lorsque seuls des documents identifiés ont changé dans le cadre d'un pipeline versionné. La dérive des requêtes peut au contraire nécessiter des tests mis à jour, une récupération hybride ou un autre encodeur, plutôt qu'une reconstruction aveugle de vecteurs identiques. La conséquence pratique apparaît lorsque plusieurs sources se disputent un contexte limité.
La reconstruction est une migration de version, pas une compaction de routine
Une reconstruction complète retraite chaque source active avec une configuration d'extraction, de segmentation et d'embedding figée, crée une génération d'index distincte, valide la récupération et modifie atomiquement la cible des requêtes. Mélanger les générations pendant la reconstruction annule son objectif.
Les études sur la compensation de la dérive des requêtes examinent des méthodes de projection des requêtes entre versions qui orientent les nouvelles requêtes vers d'anciens espaces de tâches, ce qui montre qu'éviter une reconstruction nécessite une méthode de compatibilité explicite plutôt que l'espoir que des versions proches du modèle s'alignent. Cette dépendance doit rester explicite dans l'interface finale.
La limite critique est un changement non versionné du modèle ou du prétraitement. Lorsque la provenance ne permet pas de prouver quel pipeline a créé chaque vecteur, une réparation sélective est risquée ; reconstruisez à partir des sources faisant autorité et conservez l'ancienne génération jusqu'à la fin de l'évaluation et du retour arrière.
Utilisez la provenance et les tests de récupération pour choisir l'étendue de la reconstruction
Répertoriez pour chaque vecteur la version de l'encodeur, la dimension, le pooling, la normalisation, l'analyseur, l'OCR, le segmenteur, le modèle de métadonnées, la version de la source et la génération de l'index. Refusez les écritures mixtes lorsque la clé de compatibilité change. Le résultat doit donc être vérifié par rapport aux éléments de preuve d'origine.
Comparez les résultats classés avec le comportement après une reconstruction complète de l'index. Exécutez un ensemble de requêtes reproductible pour mesurer le rappel, la précision, l'appui des citations, les distributions de scores, la langue et le type de document sur les index ancien, miroir et candidat. Cette distinction reste visible lors des tests domestiques ultérieurs.
Effectuez une reconstruction complète après un changement de modèle incompatible ou de provenance inconnue ; ré-encodez les sources affectées après un changement versionné du pipeline ; ne recalibrez que lorsque les vecteurs restent identiques, mais que les seuils ou le mélange de requêtes ont changé. Ne basculez qu'après avoir mesuré une amélioration.
Centre Tech & IA
Plus à lire

Qu’est-ce que la compatibilité des tokeniseurs et pourquoi peut-elle perturber le changement de modèle ?
Décodez l’identité du vocabulaire, la sémantique des tokens spéciaux, les modèles de chat, les tokens mis en cache, les adaptateurs et les vérifications de...

Qu’est-ce que la résidence d’un modèle et quand un service d’IA local doit-il conserver les poids chargés ?
Comprendre la persistance des poids, les niveaux de cache, les démarrages à froid, l’éviction, le multiplexage, la pression mémoire et les situations où un...

Qu’est-ce que le taux d’acceptation du décodage spéculatif, et pourquoi est-il important ?
Décodez la métrique d'acceptation, rédigez la vérification, le comportement en cas de rejet, les limites d'accélération, la variation de la charge de travail et...

