Pour un RAG ou une recherche sémantique, l'embedding est souvent la première brique externalisée : on envoie le texte à une API hébergée, on récupère un vecteur et on le confie à une base vectorielle. La mise en route est rapide, mais quand les volumes augmentent, que la conformité se durcit ou que la facture devient imprévisible, les équipes cherchent des alternatives.

Trois routes sont courantes : l'API Embedding hébergée, le déploiement autonome d'un modèle à poids ouverts, et la vectorisation intégrée à une base vectorielle. Aucune n'est absolument supérieure ; les différences se concentrent sur cinq points : dimensions et langues, latence, confidentialité, coût et exploitation.

Cet article les examine selon ces cinq axes, avec un tableau de choix par scénario et une liste de migration. Les modèles, dimensions et prix exacts sont ceux de la documentation de chaque éditeur et de la page Tarifs des modèles.

Remarque : OpenAI, Azure, Cohere, Pinecone, Qdrant, Milvus, Weaviate, BAAI, Qwen et les autres noms cités sont des marques de leurs détenteurs respectifs. Cet article compare des approches techniques et n'implique aucun partenariat ni autorisation ; les spécifications et limites d'interface peuvent changer selon les versions, faites foi sur la documentation des éditeurs.

1. Distinguer les trois routes

API Embedding hébergée. Elle englobe l'accès direct à un éditeur de modèles, les services de modèles des plateformes cloud et les passerelles compatibles OpenAI. Avantages : pas d'exploitation, facturation à l'usage, changement rapide ; inconvénient : les textes quittent votre réseau et le coût croît avec le volume d'appels.

Modèle à poids ouverts. Par exemple BGE-M3, Qwen3-Embedding, EmbeddingGemma, multilingual-e5 ou la série jina. Les poids sont téléchargeables et déployés sur votre serveur ou votre cloud privé. Avantage : les données ne sortent pas du réseau interne ; inconvénient : il faut préparer les ressources d'inférence et gérer soi-même version, montée en charge et supervision.

Vectorisation intégrée à la base vectorielle. L'integrated embedding de Pinecone, le vectorizer de Weaviate, FastEmbed de Qdrant ou l'embedding function de Milvus en relèvent. À l'écriture, on transmet directement le texte et la base, ou le modèle qu'elle appelle, produit le vecteur, ce qui évite une couche de code de liaison. Mais la vectorisation intégrée ne signifie pas nécessairement une inférence locale : beaucoup d'implémentations appellent encore un service de modèle externe. pgvector ne fait que stocker et rechercher, sans générer de vecteurs.

2. Dimensions : plus haut n'est pas toujours mieux

La dimension détermine la capacité d'expression, mais aussi directement le stockage et le coût de recherche. Exemples courants : text-embedding-3-small d'OpenAI en 1536 dimensions par défaut, 3-large en 3072 ; BGE-M3 en 1024 ; Qwen3-Embedding en 1024, 2560 et 4096 pour les tailles 0,6B, 4B et 8B ; EmbeddingGemma en 768 par défaut, réductible à 512, 256 ou 128. Ces valeurs sont indicatives ; faites foi sur la documentation des éditeurs.

Le stockage s'estime grossièrement ainsi : nombre de vecteurs × dimension × octets par nombre flottant. Un million de vecteurs en 1024 dimensions float32 représente environ 4 Go de données brutes ; en 3072 dimensions, environ 12 Go, sans compter index, réplicas et métadonnées.

# Estimation de l'occupation brute des vecteurs, hors index, réplicas et métadonnées
chunks = 1_000_000
for dim in (768, 1024, 1536, 3072):
    gb = chunks * dim * 4 / 1024**3
    print(f"{dim} dimensions : {gb:.1f} Go")

Point essentiel : dimension et modèle sont liés. Les vecteurs produits par des modèles différents ou des paramètres dimensions différents ne peuvent pas cohabiter dans le même index ; après un changement de modèle, il faut tout recalculer, sans compléter par des zéros ni tronquer pour atteindre la bonne longueur.

3. Couverture linguistique : tester le chinois à part

Beaucoup de modèles annoncent la prise en charge de dizaines de langues, mais « pris en charge » ne signifie pas « performant sur votre corpus ». Le chinois, les textes mixtes chinois-anglais, le russe, les références produit, les abréviations et les fautes de frappe influencent le rappel.

Ne vous fiez pas seulement aux classements : réalisez une petite évaluation avec de vraies questions d'utilisateurs, de vrais fragments de documents et des cas difficiles (reformulations synonymes, questions interlangues, clauses numérotées). Mesurez au minimum recall@k et MRR, puis vérifiez si l'ordre correspond à l'intuition. Ces modèles mettent tous en avant le multilinguisme, mais ce sont vos données qui doivent trancher.

Surveillez aussi l'efficacité du découpage. À limite égale de 8192 tokens, le nombre de caractères tenables diffère entre chinois, anglais et code. Il est plus sûr de garder une marge en tokens lors du découpage.

4. Latence et débit : regarder le p95, pas la moyenne

La latence d'une API hébergée combine aller-retour réseau, file d'attente et inférence. Les appels inter-régions, la gigue réseau et les files aux heures de pointe font monter le p95 au-dessus du p50. Les requêtes par lots amortissent le coût, mais allongent le temps de réponse : elles conviennent à l'indexation hors ligne.

La latence d'un déploiement autonome vient surtout de la file d'inférence et du traitement par lots. Un petit modèle tourne sur CPU, avec un débit limité ; un grand modèle exige un GPU, avec la mémoire vidéo, la concurrence et le démarrage à froid à considérer. Sans équipe d'exploitation, ce coût est souvent sous-estimé.

La vectorisation intégrée ajoute un maillon d'appel : écriture comme lecture attendent le retour du modèle. Elle économise de la complexité de code, pas nécessairement de la latence. Mesurez séparément le débit d'indexation et le p95 des requêtes.

5. Confidentialité et conformité : où vont les textes

Une API hébergée implique que les textes quittent votre réseau. Vérifiez si les données servent à l'entraînement, combien de temps elles sont conservées, dans quelle région elles résident et si un accord de traitement pour entreprise est disponible. Pour les données personnelles, les contrats et les informations financières, passez d'abord une évaluation de conformité.

Un déploiement open source garde les textes dans votre VPC, mais n'est pas conforme par nature : licence du modèle, journaux, sauvegardes et contrôle d'accès restent à votre charge. Avec la vectorisation intégrée, identifiez quel modèle est appelé en arrière-plan et vers quelle région partent les requêtes.

Les vecteurs eux-mêmes peuvent révéler des informations. L'embedding n'est pas du chiffrement : un attaquant peut faire de l'inférence par similarité. Étiquettes de permission, isolation des locataires et journaux d'accès doivent être traités aussi sérieusement que le texte source.

6. Structure de coût : le prix unitaire n'est qu'un poste

Pour comparer des solutions, ne comparez pas seulement le prix par million de tokens. Le coût complet comprend au moins :

  • les tokens d'indexation : vectorisation initiale et mises à jour incrémentales ;
  • les tokens de requête : chaque question doit être revectorisée ;
  • le recalcul et la migration : recalcul complet lors d'un changement de modèle ou de découpage, avec double écriture, bascule et retour arrière ;
  • le stockage et la mémoire : vecteurs, index, réplicas et métadonnées ;
  • l'inférence et l'exploitation : GPU, CPU, électricité, déploiement, mise à jour et supervision d'un déploiement autonome.

Le coût de recalcul est le plus souvent sous-estimé. Un recalcul complet peut durer des heures, voire des jours. Les prix unitaires de référence sont ceux de la page Tarifs des modèles ; ils évoluent selon les éditeurs et les versions, et aucun chiffre n'est figé ici.

7. Choisir une route par scénario

Scénario Route prioritaire Raison Points à vérifier
Petite équipe, validation rapide API hébergée Sans exploitation, paiement à l'usage Consigner modèle, dimension et version de découpage
Données ne pouvant pas sortir du réseau Déploiement open source Textes conservés dans votre VPC Évaluer GPU, licence et sauvegardes
Base vectorielle déjà en place, volume modéré Vectorisation intégrée Une couche de code en moins Vérifier le modèle sous-jacent et la région d'appel
Indexation hors ligne massive, coût sensible Open source ou API par lots Le traitement par lots amortit le coût Évaluer le rappel avant le volume complet
Service client multilingue, e-commerce transfrontalier Modèle hébergé multilingue ou famille BGE-M3 Large couverture linguistique Valider les langues rares avec un corpus réel
Requêtes en ligne sensibles à la latence API hébergée proche, ou petit modèle local Moins d'allers-retours réseau Regarder le p95, pas seulement la moyenne
Recherche hybride dense et creuse Modèle ouvert à sorties multiples Une inférence, plusieurs types de vecteurs Index et scoring plus complexes

Ce tableau n'est qu'un point de départ. Le choix réel dépend de l'infrastructure existante : si vous êtes déjà chez un cloud, examinez d'abord son service de modèles ; avec un cluster GPU, le coût marginal de l'auto-hébergement baisse ; avec une base vectorielle déjà utilisée, la vectorisation intégrée peut faire gagner du temps d'ingénierie.

8. Liste de migration

  1. Inventoriez l'existant : nom du modèle, dimension, mesure de distance, règles de découpage, paramètres d'index et volume quotidien.
  2. Construisez un jeu d'évaluation : quelques centaines de vraies questions et les documents corrects, pour une régression fixe.
  3. Choisissez deux ou trois candidats, sans changer trop de variables à la fois.
  4. Double écriture à faible volume : anciens et nouveaux vecteurs écrits en parallèle, requêtes sur le nouvel index, en notant les écarts de rappel.
  5. Vérifiez dimensions, normalisation et mesure de distance ; assurez la cohérence entre cosine, dot product et la configuration de l'index.
  6. Créez une nouvelle collection pour le recalcul complet ; ne mélangez pas des dimensions différentes dans l'ancien index.
  7. Basculez le trafic par pourcentage, en conservant l'ancien index et un interrupteur de retour arrière pendant au moins un cycle métier.
  8. Archivez version du modèle, dimension, version de découpage et date de recalcul dans le dictionnaire de données.

L'échec le plus fréquent d'une migration n'est pas une mauvaise qualité, mais une incohérence de dimension, de normalisation ou de mesure de distance. Alignez d'abord les détails d'ingénierie, puis parlez de qualité.

Questions fréquentes

Peut-on remplacer entièrement une API Embedding par un modèle open source ?

Dans la plupart des cas, oui, surtout pour les équipes aux données sensibles ou au volume stable. Il faut toutefois maintenir le service d'inférence, évaluer les modèles et assumer les montées de version. En phase de validation rapide, une API hébergée est plus simple.

Quelle différence entre la vectorisation intégrée à une base et l'appel direct d'une API ?

La vectorisation intégrée ramène la génération des vecteurs dans le flux d'écriture de la base, avec moins de code, mais elle appelle souvent un service de modèle externe en arrière-plan. Elle ne règle pas automatiquement confidentialité et coût : avant de signer, vérifiez l'origine du modèle, la région et la facturation.

Faut-il tout recalculer après un changement de modèle d'embedding ?

Oui. Les espaces vectoriels de modèles différents sont incompatibles ; les mélanger rend la recherche peu fiable. Une dimension identique ne suffit pas. Réalisez une évaluation à petite échelle avant le recalcul complet.

Une dimension plus élevée améliore-t-elle toujours les résultats ?

Pas nécessairement. Une dimension plus élevée renforce la capacité d'expression mais augmente stockage et coût de recherche. Beaucoup de modèles acceptent la troncature Matryoshka, qui permet d'arbitrer entre qualité et coût, mais impose une nouvelle évaluation après troncature.

Quel GPU faut-il pour auto-héberger un Embedding ?

Cela dépend de la taille du modèle, des lots, de l'objectif de latence et de la concurrence. Un petit modèle peut servir des scénarios à faible QPS sur CPU ; un grand modèle exige généralement un GPU et du traitement par lots. Testez d'abord avec le trafic réel, puis dimensionnez.

Pour aller plus loin

Si vous souhaitez d'abord valider les résultats avec une solution hébergée, créez une clé de test sur ZSQH AI Gateway, exécutez l'indexation et les requêtes via une interface compatible OpenAI, puis décidez si un déploiement autonome se justifie. La disponibilité des modèles et les prix sont sur la page Tarifs des modèles.

Pour aller plus loin :