Que faire lors du changement de modèles d'embedding

Les vecteurs provenant de modèles différents sont incompatibles. Vous ne pouvez pas mélanger les anciens et nouveaux embeddings dans le même espace vectoriel. Vous ne pouvez pas non plus ajouter de nouveaux champs de vecteurs nommés à une collection existante. Tous les vecteurs nommés doivent être définis au moment de la création de la collection. Les deux stratégies de migration ci-dessous nécessitent de créer une nouvelle collection.

• Comprenez les alias de collection avant de choisir une stratégie Collection aliases

Puis-je éviter de re-embed ?

À utiliser quand : vous cherchez des raccourcis avant de vous engager dans une migration complète.

Vous DEVEZ re-embed si : vous changez de fournisseur de modèle (OpenAI vers Cohere), vous changez d'architecture (CLIP vers BGE), incompatibilité du nombre de dimensions entre différents modèles, ou ajout de vecteurs creux à une collection dense uniquement.

Vous POUVEZ éviter de re-embed si : vous utilisez des modèles Matryoshka (utilisez le paramètre dimensions pour produire des embeddings de dimension inférieure, apprenez une transformation linéaire à partir de données d'exemple, une certaine perte de rappel, adapté pour les datasets de 100M+ points). Ou changement de quantification (binaire vers scalaire) : Qdrant re-quantifie automatiquement. Quantization

Besoin de zéro temps d'arrêt (échange d'alias)

À utiliser quand : la production doit rester disponible. Recommandé pour le remplacement de modèle à grande échelle.

• Créez une nouvelle collection avec les dimensions et la métrique de distance du nouveau modèle
• Re-embeddez toutes les données dans la nouvelle collection en arrière-plan
• Pointez votre application vers un alias de collection au lieu d'un nom de collection directe
• Échangez atomiquement l'alias vers la nouvelle collection Switch collection
• Vérifiez la qualité de la recherche, puis supprimez l'ancienne collection

Attention, l'échange d'alias redirige uniquement les requêtes. Les payloads doivent être re-uploadés séparément.

Besoin des deux modèles en direct (côte à côte)

À utiliser quand : test A/B de modèles, multi-modal (dense + creux), ou évaluation d'un nouveau modèle avant engagement.

Vous ne pouvez pas ajouter un vecteur nommé à une collection existante. Créez une nouvelle collection avec les deux champs de vecteurs définis à l'avance :

• Créez une nouvelle collection avec les deux vecteurs nommés anciens et nouveaux définis Collection with multiple vectors
• Migrez les données de l'ancienne collection, préservant les vecteurs existants dans l'ancien champ nommé
• Remplissez les embeddings du nouveau modèle progressivement avec UpdateVectors Update vectors
• Comparez la qualité en interrogeant avec using: "old_model" vs using: "new_model"
• Échangez l'alias vers la nouvelle collection une fois satisfait

La colocalisation de gros multi-vecteurs (surtout ColBERT) avec des vecteurs denses dégrade TOUTES les requêtes, même celles utilisant uniquement le dense. À des millions de points, les utilisateurs signalent une latence de 13s tombant à 2s après suppression de ColBERT. Placez les gros vecteurs sur disque pendant la migration côte à côte.

Si vous anticipez des migrations de modèle futures, définissez les deux champs de vecteurs à l'avance au moment de la création de la collection.

Migration de recherche dense vers hybride

À utiliser quand : ajout de vecteurs creux/BM25 à une collection dense uniquement existante. Schéma de migration le plus courant.

Vous ne pouvez pas ajouter de vecteurs creux à une collection dense uniquement existante. Doit être recréée :

• Créez une nouvelle collection avec les configurations de vecteurs dense et creux définis
• Re-embeddez toutes les données avec les deux modèles dense et creux
• Migrez les payloads, échangez l'alias

Les vecteurs creux au niveau des chunks ont des caractéristiques TF-IDF différentes du niveau document. Testez la qualité de la récupération après migration, surtout pour les textes non-anglais sans suppression de stop-words.

La re-embedding est trop lente

À utiliser quand : le dataset est volumineux et la re-embedding est le goulot d'étranglement.

• Utilisez update_mode: insert (v1.17+) pour une migration idempotente sûre Update mode
• Parcourez l'ancienne collection avec with_vectors=False, re-embeddez par lots, upsertez dans la nouvelle collection
• Uploadez par lots parallèles (64-256 points par requête, 2-4 flux parallèles) Bulk upload
• Désactivez HNSW lors du chargement massif (définissez indexing_threshold_kb très haut, restaurez après)
• Pour l'inference Qdrant Cloud, changer de modèle est un changement de configuration, pas un changement de pipeline Inference docs

Pour les datasets de 400GB+, attendez-vous à plusieurs jours. Pour les petits datasets (<25MB), la réindexation depuis la source est plus rapide que l'utilisation de l'outil de migration.

À NE PAS faire

• Supposer que vous pouvez ajouter des vecteurs nommés à une collection existante (doivent être définis au moment de la création)
• Supprimer l'ancienne collection avant de vérifier la nouvelle
• Oublier de mettre à jour le modèle d'embedding de requête dans votre code d'application
• Ignorer la migration des payloads lors de l'utilisation d'un échange d'alias (les alias redirigent les requêtes, ils ne copient pas les données)
• Conserver les vecteurs ColBERT colocalisés avec les vecteurs denses pendant une longue migration (le coût I/O dégrade toutes les requêtes)
• Migrer vers une recherche hybride sans tester la qualité BM25 au niveau des chunks