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

Les vecteurs de différents modèles sont incompatibles. Vous ne pouvez pas mélanger les anciens et les 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 ré-embedder ?

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

Vous DEVEZ ré-embedder 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 vous ajoutez des vecteurs creux à une collection dense uniquement.

Vous POUVEZ éviter de ré-embedder si : vous utilisez des modèles Matryoshka (utilisez le paramètre dimensions pour sortir des embeddings de dimensions inférieures, apprenez la transformation linéaire à partir de données d'échantillon, une certaine perte de rappel, bon pour les ensembles de données de 100 M+ points). Ou en changeant la quantification (binaire vers scalaire) : Qdrant re-quantifie automatiquement. Quantization

Besoin de zéro temps d'arrêt (Alias Swap)

À 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
Ré-embedez 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 direct
É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 téléchargés à nouveau séparément.

Besoin que les deux modèles soient actifs (Côte à côte)

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

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 anciens et nouveaux vecteurs nommés tous deux définis Collection with multiple vectors
Migrez les données de l'ancienne collection, en préservant les vecteurs existants dans l'ancien champ nommé
Complétez les embeddings du nouveau modèle de manière progressive en utilisant UpdateVectors Update vectors
Comparez la qualité en interrogeant avec using: "old_model" par rapport à using: "new_model"
Échangez l'alias vers la nouvelle collection une fois satisfait

La co-localisation de grands multi-vecteurs (notamment ColBERT) avec des vecteurs denses dégrade TOUTES les requêtes, même celles utilisant uniquement des vecteurs denses. À des millions de points, les utilisateurs signalent une latence de 13 secondes tombant à 2 secondes après suppression de ColBERT. Placez les grands vecteurs sur disque lors d'une migration côte à côte.

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

Migration de la recherche dense vers la recherche hybride

À utiliser quand : vous ajoutez des vecteurs creux/BM25 à une collection dense uniquement existante. Motif de migration le plus courant.

Vous ne pouvez pas ajouter de vecteurs creux à une collection dense uniquement existante. Vous devez la recréer :

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

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

Re-embedding est trop lent

À utiliser quand : l'ensemble de données est volumineux et le ré-embedding est le goulot d'étranglement.

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

Pour les ensembles de données de 400 Go+, prévoyez des jours. Pour les petits ensembles de données (<25 Mo), la ré-indexation à partir de la source est plus rapide que l'utilisation de l'outil de migration.

Ce qu'il NE FAUT PAS faire

Supposer que vous pouvez ajouter des vecteurs nommés à une collection existante (ils 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 le code de votre application
Sauter la migration des payloads lors de l'utilisation d'un alias swap (les alias redirigent les requêtes, ils ne copient pas les données)
Conserver les vecteurs ColBERT co-localisés avec les vecteurs denses lors d'une longue migration (le coût d'E/S dégrade toutes les requêtes)
Migrer vers la recherche hybride sans tester la qualité BM25 au niveau du fragment