Changer de modèle d'embedding : réindexer sans coupure

Changer de modèle d'embedding oblige, sauf exception documentée par l'éditeur, à recalculer tous les vecteurs et à reconstruire l'index. Chaque modèle range les textes dans son propre espace : un vecteur produit par l'un ne se compare pas à un vecteur produit par l'autre. La bonne nouvelle : la migration peut se faire en parallèle de l'ancienne recherche, puis basculer d'un coup.

Pourquoi on ne peut pas mélanger

La documentation d'Ollama le formule simplement : utilisez le même modèle de plongements pour l'indexation et pour l'interrogation. Une question encodée avec le modèle B, comparée à des passages encodés avec le modèle A, donne des scores sans signification. Pire, la recherche ne plante pas : elle renvoie des résultats, simplement mauvais. Quand les deux modèles ont la même dimension, rien ne vous alertera.

L'exception : une gamme compatible

Certains éditeurs conçoivent des gammes dont les vecteurs restent comparables. Voyage AI indique que tous les plongements de sa série 4 (voyage-4-large, voyage-4, voyage-4-lite, voyage-4-nano) sont compatibles entre eux. Sa documentation précise aussi que les vecteurs calculés avec ou sans le paramètre input_type sont compatibles. Sans mention explicite de ce genre dans la documentation, partez du principe qu'il faut tout recalculer.

Les bonnes raisons de changer

• un modèle nettement meilleur sur vos propres questions, mesuré, pas seulement mieux classé ;
• un modèle plus économe en dimensions ou en prix ;
• l'arrêt annoncé d'un modèle par son éditeur ;
• le passage d'un service en ligne à un modèle installé chez vous, ou l'inverse.

Le choix lui-même est traité dans Choisir un modèle d'embedding.

La migration pas à pas avec pgvector

Le principe : une nouvelle colonne, remplie en arrière-plan, indexée sans bloquer, comparée, puis la bascule.

1. Ajouter une colonne à la nouvelle dimension. Le dépôt pgvector montre l'ajout d'une colonne vecteur à une table existante :

ALTER TABLE passages ADD COLUMN embedding_v2 vector(1024);

2. Remplir par lots. Un script lit les passages dont embedding_v2 est vide, les encode par paquets avec le nouveau modèle, écrit les vecteurs. Prévoyez la reprise après erreur (le script repart des lignes encore vides) et respectez les limites de débit de l'interface de programmation (API) du fournisseur.

3. Indexer sans bloquer les écritures. La documentation conseille en production la création concurrente :

CREATE INDEX CONCURRENTLY ON passages USING hnsw (embedding_v2 vector_cosine_ops);

4. Comparer. Sur un jeu de questions réelles, lancez la recherche sur l'ancienne et la nouvelle colonne, chacune avec la question encodée par son modèle. Comparez la part de bonnes réponses dans les premiers résultats.

5. Basculer. L'application interroge embedding_v2 et encode les questions avec le nouveau modèle, en même temps : les deux changements partent ensemble.

6. Garder l'ancienne colonne quelque temps. Elle permet un retour arrière immédiat. Ne la supprimez qu'une fois la nouvelle version validée en production.

Pendant toute la migration, les nouveaux documents doivent être encodés avec les deux modèles, sinon l'une des colonnes aura des trous.

Estimer le coût de la réindexation

Le coût de calcul est simple : nombre de jetons du corpus × prix du nouveau modèle. Exemple illustratif : un corpus de 50 millions de jetons réencodé avec voyage-4 à 0,06 $ par million de jetons (prix affiché par MongoDB, relevé le 15/11/2026) coûterait 3 $, et entrerait dans les 200 millions de jetons offerts sur ce modèle. Le vrai coût est ailleurs : le temps du script, la construction de l'index, l'évaluation, et la place disque des deux colonnes pendant la transition. Voir Coût des embeddings.

Anticiper dès le premier jour

• Gardez le texte source de chaque passage dans la base, pas seulement son vecteur : sans lui, impossible de réencoder.
• Notez le modèle et sa version à côté des vecteurs (une colonne ou une table de configuration).
• Fixez la dimension en connaissance de cause : une réduction ultérieure est aussi une réindexation. OpenAI note par exemple qu'une dimension peut être choisie pour tenir dans la limite d'une base (documentation) ; mieux vaut le décider avant le premier chargement (voir Dimensions et Matryoshka).