Plusieurs modèles d’embedding peuvent-ils coexister dans un même système de recherche privé ?

Oui. Un même système de recherche privé peut stocker et interroger simultanément les plongements issus de plusieurs modèles. L’approche sûre consiste à traiter chaque modèle de plongement comme son propre espace vectoriel, avec des dimensions, une métrique de distance, une version et une configuration d’index explicites. Ne mélangez pas des vecteurs incompatibles dans une colonne anonyme en supposant qu’ils sont comparables.

Plusieurs modèles sont utiles pour les migrations, la recherche multilingue, la récupération combinant images et texte, les plongements spécialisés par domaine ou les tests A/B. La complexité apparaît lorsque vous devez combiner les résultats issus de ces espaces.

Pourquoi conserveriez-vous plusieurs modèles de plongement ?

Une base de connaissances privée évolue. Lier définitivement chaque document au premier modèle de plongement choisi rend les mises à niveau inutilement perturbatrices.

Des modèles différents produisent des espaces vectoriels différents

Deux modèles peuvent tous deux produire des vecteurs de 768 dimensions tout en restant incompatibles. Les coordonnées n’ont de sens que par rapport au modèle qui les a produites.

Document A
  |
  +-- Modèle v1 -> vector_v1 [768]
  |
  +-- Modèle v2 -> vector_v2 [1024]
  |
  +-- modèle d’image -> vector_image [512]

Une requête générée avec le modèle v2 doit interroger l’espace v2. La comparer directement aux vecteurs du modèle v1 n’a aucun sens, même si une API accepte les dimensions.

La documentation actuelle de Qdrant sur les vecteurs nommés prend explicitement en charge plusieurs vecteurs de tailles et de types différents au sein d’un même point, chacun dans un espace vectoriel nommé distinct.

Utilisez un registre de modèles, pas seulement un nom de vecteur

Enregistrez suffisamment de métadonnées pour reproduire chaque plongement :

embedding_space: text_v2
model_id:        example/model-name
model_revision:  sha-or-version
vector_dim:      1024
metric:          cosine
normalized:      true
chunking_policy: semantic-v3
created_at:      2026-09-03

Le découpage en segments doit également figurer dans le registre. Si vous modifiez à la fois le modèle d’embeddings et la manière dont les documents sont segmentés, la recherche évolue pour deux raisons. Expliciter la version du pipeline permet les comparaisons et les restaurations.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Une collection avec des vecteurs nommés ou des collections distinctes ?

Les deux conceptions peuvent être correctes.

La documentation des collections de Weaviate prend également en charge plusieurs espaces vectoriels nommés par objet, chacun avec son propre vectoriseur et sa propre configuration d’index.

Si les autorisations diffèrent — par exemple entre des documents familiaux et professionnels — des collections distinctes peuvent rester plus claires que de placer toutes les représentations dans un seul objet.

pgvector peut-il stocker différentes dimensions ?

Oui. La documentation de pgvector montre une colonne vector générique avec un model_id, puis utilise des index d’expression et des index partiels pour les lignes ayant une dimension donnée.

Le principe est le même : conservez l’identité du modèle dans le modèle de données et créez l’index ANN uniquement sur les lignes compatibles.

Ne comparez pas les scores bruts de similarité entre les modèles

Il s’agit de l’échec le plus subtil. Une similarité cosinus de 0,78 avec le modèle A ne signifie pas nécessairement la même qualité qu’une valeur de 0,78 avec le modèle B. Les distributions des scores dépendent de l’entraînement du modèle, de la normalisation, de la métrique, du domaine et du comportement de l’index.

Si vous voulez obtenir une seule liste de résultats à partir de deux modèles d’embeddings, commencez par effectuer des recherches séparément :

Requête
  |
  +-- Modèle A -> 20 premiers résultats + rangs
  |
  +-- Modèle B -> 20 premiers résultats + rangs
                      |
                      v
               fusion / reranker
                      |
                      v
                  10 premiers résultats finaux

Les méthodes de combinaison les plus sûres incluent la fusion de rangs, la normalisation des scores propre au modèle et étalonnée sur vos données, ou un cross-encoder/reranker qui évalue le texte des candidats après la recherche.

La documentation de Weaviate sur la recherche multi-cibles présente des stratégies de combinaison, notamment les combinaisons normalisées et pondérées, ce qui montre pourquoi la fusion entre espaces nécessite une stratégie explicite plutôt qu’un simple tri naïf des scores bruts.

Comment migrer vers un nouveau modèle d’intégration sans interruption de service ?

Ne supprimez pas d’abord les anciennes intégrations. Effectuez une migration parallèle :

1. enregistrez le nouveau modèle et l’espace vectoriel ;
2. générez de nouvelles intégrations pour les documents nouvellement ingérés ;
3. complétez les anciens documents par lots ;
4. effectuez des recherches en parallèle dans les deux espaces ;
5. comparez le rappel et la réussite des tâches sur des questions réelles ;
6. basculez vers l’espace de requête par défaut ;
7. conservez les anciens vecteurs pendant une période de restauration ;
8. ne les supprimez qu’une fois votre confiance suffisamment établie.

Weaviate précise que l’ajout d’un nouveau vecteur nommé ne vectorise pas automatiquement les objets existants. Ce comportement est utile à garder à l’esprit, car « le schéma prend en charge le nouveau modèle » et « toutes les anciennes données disposent de nouveaux vecteurs » sont deux étapes distinctes.

Plusieurs intégrations augmentent le stockage plus rapidement que beaucoup d’utilisateurs ne le pensent

Chaque représentation vectorielle supplémentaire peut ajouter un autre tableau dense ainsi qu’un autre index ANN. Un deuxième modèle d’intégration peut donc multiplier approximativement la portion vecteur/index de la base de données, même si les documents originaux ne sont stockés qu’une seule fois.

Estimation :

octets vectoriels ~= 
  segments de documents
  x dimensions
  x octets par élément
  x nombre d’espaces d’intégration

+ surcharge de l’index ANN
+ index de métadonnées / de contenu

Les index quantifiés ou en demi-précision peuvent réduire l’empreinte, mais testez la qualité de la récupération avant d’appliquer la compression à chaque modèle.

Cela nous ramène à la question de l’architecture des bases de connaissances locales : les intégrations sont des données dérivées remplaçables, tandis que les documents sources et les métadonnées sont les actifs durables qui vous permettent de les reconstruire.

Utiliser des modèles différents pour différents itinéraires de requête

Vous n’avez pas besoin d’effectuer une recherche dans chaque espace vectoriel pour chaque question. Acheminez les requêtes selon le besoin :

Un petit classificateur de requêtes peut sélectionner l’espace approprié, tandis que les recherches ambiguës peuvent être diffusées sur deux représentations, puis fusionner les résultats.

Les autorisations doivent s’appliquer avant la fusion

Ne récupérez pas de candidats non autorisés dans chaque espace vectoriel en espérant que le réordonnanceur final les masque. Appliquez les autorisations de l’utilisateur et du document à chaque étape de récupération afin que les segments sensibles n’entrent pas dans l’ensemble de candidats, les journaux ou l’invite du réordonnanceur.

Pour la recherche sur un NAS privé, la même règle de contrôle d’accès doit être maintenue lors des migrations de modèles. Un nouvel index doit hériter des métadonnées d’autorisation du document au lieu de devenir une copie temporaire non protégée.

Le guide de l’assistant IA privé fournit le contexte général : la recherche vectorielle n’est utile que lorsqu’elle respecte les mêmes limites d’accès aux données privées que le stockage de fichiers.

Liste de contrôle d’assurance qualité multi-embeddings

• Attribuez à chaque espace d’embeddings un identifiant unique de modèle/version.
• Enregistrez les dimensions, la normalisation et la métrique de distance.
• Versionnez le découpage en segments et le prétraitement.
• N’interrogez jamais l’index d’un modèle avec le vecteur d’un autre modèle.
• Ne comparez pas directement les scores bruts entre les espaces sans étalonnage.
• Appliquez les autorisations dans chaque chemin de récupération.
• Générez les nouveaux vecteurs avant de modifier la valeur par défaut.
• Évaluez le système avec de vraies questions et des documents connus comme pertinents.
• Conservez l’index précédent pendant une fenêtre de retour en arrière.
• Incluez les vecteurs et index supplémentaires dans la planification de la capacité du disque et de la RAM.

FAQ

Deux modèles d’embeddings peuvent-ils utiliser des dimensions différentes dans une même base de données ?

Oui, si la base de données prend en charge des espaces vectoriels nommés, des collections ou des index distincts pour chaque dimension compatible. Qdrant, Weaviate et pgvector proposent tous des modèles adaptés.

Puis-je changer de modèle d’embeddings sans réencoder les anciens documents ?

Non, si vous voulez que les anciens documents restent interrogeables dans l’espace vectoriel du nouveau modèle. Un nouveau vecteur de requête n’est pas compatible avec les embeddings produits par un autre modèle.

Dois-je conserver indéfiniment les anciens embeddings ?

Non. Conservez-les pendant l’évaluation et la possibilité de retour en arrière. Une fois le nouveau modèle validé et la migration terminée, la suppression des vecteurs obsolètes peut récupérer une quantité importante d’espace de stockage et de mémoire d’index.

Verdict final

Plusieurs modèles d’embeddings peuvent coexister proprement dans un même système de recherche privé lorsque leurs espaces vectoriels restent explicites. Stockez les métadonnées du modèle et du pipeline, interrogez chaque espace avec l’encodeur correspondant, fusionnez délibérément les résultats et migrez en effectuant un réenrichissement en parallèle. La conception dangereuse n’est pas d’utiliser « plus d’un modèle ». C’est de perdre la trace du modèle ayant produit chaque vecteur et de prétendre que tous les scores de similarité ont la même signification.