Architecture de base vectorielle : structure, contraintes, performances

Un vecteur stocké dans une base n’est qu’une liste de nombres. Sa valeur dépend de ce qui l’entoure : l’index qui le retrouve en millisecondes, le modèle qui l’a généré, la stratégie de recherche qui le sélectionne, l’architecture qui sert des milliers de requêtes simultanées sans dégrader la qualité. Concevoir une base vectorielle, c’est orchestrer ces couches pour qu’elles tiennent ensemble sous contrainte réelle.

Une base vectorielle ne se résume pas à stocker des embeddings

Une base vectorielle est avant tout un système de recherche. Elle reçoit un vecteur (la représentation numérique d’un texte, d’une image ou d’un son) et doit retrouver, parmi des millions ou des milliards d’autres, ceux qui sont les plus proches au sens d’une métrique de similarité (cosinus, distance euclidienne, produit scalaire). Ce qui la distingue d’une base relationnelle classique, c’est que la requête n’est pas une égalité exacte sur une colonne, mais une recherche de proximité dans un espace à haute dimension.

Cette spécificité entraîne des contraintes architecturales propres, résumées dans la comparaison de LLMOps ^[1] :

Dimension	Ce qu’elle couvre	Métriques clés
Scalabilité	Volume de données, charge de requêtes, montée en charge horizontale	Débit (requêtes/seconde), latence, capacité de stockage, stratégie de sharding
Tolérance aux pannes	Maintien du service en cas de défaillance	Taux de disponibilité (uptime), temps de récupération (MTTR), réplication des données, haute disponibilité
Indexation	Méthodes de recherche efficace dans des espaces vectoriels à haute dimension	Précision de recherche, vitesse de recherche, choix entre arbres métriques, hachage, index inversé

Chaque ligne correspond à un choix d’architecture qui conditionne les performances et les coûts du système en production. Les sections suivantes décortiquent ces choix un par un.

L’indexation sera votre premier arbitrage architectural

L’indexation détermine comment la base retrouve les vecteurs les plus proches d’une requête. Une recherche exhaustive (comparer la requête à chaque vecteur stocké) est exacte mais trop lente au-delà de quelques dizaines de milliers de vecteurs. Les algorithmes d’approximate nearest neighbor, ou ANN (recherche approchée des plus proches voisins), sacrifient un peu de précision pour un gain de vitesse considérable.

Quatre grandes familles coexistent, synthétisées à partir de la comparaison de LLMOps ^[1], de l’analyse de Kulkarni et al. ^[2], et des implémentations documentées dans le RAG Cookbook ^[3] :

Technique	Principe	Points forts	Limites
HNSW (Hierarchical Navigable Small World)	Graphe multi-couches où chaque couche est un sous-ensemble du précédent. La recherche navigue du haut vers le bas, de proche en proche.	Bonne précision, latence faible, adapté à des données modérées à volumineuses	Gourmand en mémoire (chaque vecteur stocke des liens vers ses voisins)
IVF (Inverted File Index)	Partitionnement de l’espace en clusters (via k-means). La requête ne cherche que dans les clusters les plus proches.	Efficace pour les gros volumes, compatible avec les filtres sur métadonnées	Précision dépend du nombre de clusters et de leur qualité ; nécessite un entraînement préalable
LSH (Locality-Sensitive Hashing)	Hachage de similarité : des vecteurs proches ont de fortes probabilités de recevoir le même hash.	Très rapide pour une recherche approximative	Précision inférieure aux autres méthodes, surtout en haute dimension
ScaNN (Scalable Nearest Neighbors)	Quantisation analytique développée par Google Research. Décompose l’espace vectoriel en sous-espaces pour réduire le coût de calcul.	Optimisé pour la basse latence, utilisé par BigQuery, AlloyDB et Vertex AI Vector Search [4]	Moins flexible hors de l’écosystème Google

Un point essentiel : les méthodes ANN souffrent de limitations en termes de rappel (la capacité à retrouver tous les résultats pertinents), ce qui peut justifier de compléter la recherche vectorielle par d’autres approches ^[2].

Ce que supportent concrètement les plateformes

Les bases et bibliothèques ne supportent pas toutes les mêmes méthodes. D’après les implémentations documentées dans le RAG Cookbook ^[3] et la documentation Google ^[4] :

Plateforme	HNSW	IVF	PQ (Quantisation produit)
pgvector (PostgreSQL)	Oui	Oui (IVFFlat)	Non
Milvus	Oui	Oui	Oui
FAISS	Oui	Oui	Oui

Les services managés de Google (BigQuery, AlloyDB, Vertex AI Vector Search) s’appuient sur ScaNN, avec des SLA de disponibilité allant jusqu’à 99,999 % ^[4].

Voici un exemple concret de création d’une table vectorielle avec pgvector, adapté du RAG Cookbook ^[3] :

import psycopg2

conn = psycopg2.connect(
    dbname="rag_cookbook",
    user="rag_cookbook_user",
    password="rag_cookbook_user_pw",
    host="localhost",
    port="5432",
)

cur = conn.cursor()
cur.execute("""CREATE EXTENSION IF NOT EXISTS vector""")
cur.execute("""
    CREATE TABLE IF NOT EXISTS job_description_table(
        id integer PRIMARY KEY,
        text_chunk TEXT,
        embedding vector(1536)
    )
""")
conn.commit()

Le champ embedding vector(1536) stocke un vecteur de 1536 dimensions (la dimension standard des modèles d’embedding d’OpenAI). La suite consiste à créer un index HNSW ou IVFFlat sur cette colonne pour accélérer la recherche par similarité cosinus. HNSW offre généralement une meilleure précision à latence égale, tandis qu’IVFFlat est plus simple à paramétrer et se combine mieux avec des filtres sur les métadonnées.

L’erreur la plus courante est de choisir l’indexation sur papier, sans tester sur ses propres données. Les performances varient fortement selon la dimensionnalité des vecteurs, la distribution des données et le ratio entre précision requise et latence acceptable.

Le modèle d’embedding, un choix qui pèse sur toute la chaîne

Le modèle d’embedding transforme un texte en vecteur numérique. C’est lui qui détermine ce que « similaire » signifie pour votre système. Et c’est un choix d’architecture à part entière, car la qualité de l’embedding et sa dimensionnalité ont un impact direct sur le stockage, la latence et le coût.

La tension qualité/coût des hautes dimensions

Les meilleurs modèles d’embedding sur le classement MTEB (Massive Text Embedding Benchmark) sont aussi les plus lourds. NV-Embed-v2 et bge-en-icl, deux modèles de référence, comptent chacun 7 milliards de paramètres et produisent des vecteurs de 4096 dimensions ^[5]. Les modèles de type LLM utilisés comme embedders ont des états cachés (hidden states, les représentations internes calculées à chaque couche du réseau) dont de très haute dimension, souvent plusieurs milliers ^[6].

Le problème : chaque dimension supplémentaire augmente la taille de l’index et le temps de calcul des similarités. L’étude de Zhenghao Liu et al. sur la réduction de dimension pour le dense retrieval montre explicitement que les embeddings haute dimension engendrent un stockage d’index plus volumineux et une latence de recherche plus élevée ^[7]. La relation entre dimension et performance n’est pas linéaire : au-delà d’un certain seuil, ajouter des dimensions n’améliore plus significativement la qualité des résultats, comme le montrent les mesures de « suffisance informationnelle » pour des modèles comme UAE-Large-V1, e5-small ou udever-bloom-560m ^[8].

Trois réponses architecturales à cette tension

La distillation. Entraîner un modèle léger à reproduire le comportement d’un modèle lourd. Le modèle Jasper, par exemple, est issu d’un processus de distillation appliqué aux embeddings de modèles de grande taille, avec un jeu de données de distillation textuelle dédié ^[5]. La méthode de distillation par paires (pointwise et pairwise distillation losses) améliore systématiquement les performances par rapport à un modèle DPR (Dense Passage Retrieval) vanilla, en combinant les deux types de perte ^[9]. Le résultat : des vecteurs de dimension réduite qui conservent l’essentiel de la qualité de recherche.

La représentation Matryoshka (MRL). Cette technique entraîne le modèle de sorte que les informations les plus critiques soient concentrées dans les premières dimensions du vecteur ^[6]. On peut alors tronquer le vecteur (par exemple de 4096 à 1024 dimensions) pour la recherche rapide, tout en gardant le vecteur complet pour des opérations plus fines. C’est une solution élégante car elle permet de choisir la dimension d’embedding au moment de la requête, pas au moment de l’entraînement.

La réduction de dimension par autoencodeur. L’approche de Zhenghao Liu et al. utilise un autoencodeur conditionnel pour projeter les vecteurs haute dimension dans un espace réduit, en préservant au maximum les signaux d’entraînement ^[7].

En pratique, le choix de la dimension est un arbitrage que chaque organisation doit calibrer. Un vecteur de 768 dimensions (taille BERT-base) suffit pour de nombreux cas d’usage courants. Les 4096 dimensions des modèles de pointe ne se justifient que lorsque la précision de recherche doit être maximale et que le budget de stockage et de calcul le permet. La distillation et Matryoshka offrent un chemin intermédiaire : tester d’abord avec le modèle de base, mesurer la qualité de recherche, puis compresser si les métriques le permettent.

Recherche hybride : pourquoi le vectoriel pur ne suffit plus

La recherche vectorielle pure a des angles morts que la production révèle rapidement.

Les deux écueils classiques

Requête trop vague. Un utilisateur demande : « Quels sont les impacts du changement climatique sur l’environnement ? » La recherche vectorielle retourne des chunks mentionnant « climat » et « environnement » de façon générique, mais rate les paragraphes détaillés sur le blanchiment des coraux ou l’érosion des sols. La requête est trop large pour que la similarité sémantique suffise ^[10].

Requête trop spécifique. Un autre demande : « Quels mécanismes moléculaires permettent à CRISPR-Cas9 d’atteindre l’édition ciblée de gènes dans les cellules eucaryotes ? » La recherche vectorielle peine à trouver des chunks correspondant à toutes les facettes de cette question technique. Aucun vecteur unique ne la couvre intégralement ^[10].

L’architecture de secours : hybride et reranking

La réponse consiste à combiner plusieurs stratégies de recherche dans un pipeline unique, comme le montre le modèle hybride développé dans les travaux sur la recherche sémantique hybride ^[11] :

Transformation de requête. La requête brute est reformulée en amont pour être plus exploitable. Trois opérations sont possibles : le rewriting (réécrire la requête pour la rendre plus précise), le broadening (l’élargir pour couvrir plus de variantes sémantiques), et la decomposition (la scinder en sous-questions) ^[10]. Le modèle hybride de la recherche sémantique intègre une structuration de requête par LLM en amont, qui transforme la requête brute avant de la passer aux deux branches de recherche ^[11].

Recherche lexicale (BM25). La recherche par mots-clés reste redoutablement efficace. Elle exploite la correspondance exacte des termes et bénéficie d’optimisations bien maîtrisées. Fait notable : réordonner les résultats d’une recherche lexicale avec un modèle de reranking compétitif reste une baseline très solide, parfois à la hauteur des approches purement vectorielles ^[2].

Recherche vectorielle (ANN). Capture la similarité sémantique que les mots-clés ne voient pas : synonymes, paraphrases, concepts apparentés.

Fusion des scores. Les résultats des deux recherches sont combinés, par exemple par une moyenne pondérée des scores de similarité et de pertinence lexicale.

Reranking. Un modèle de reranking (souvent un cross-encoder, plus coûteux mais plus précis que le modèle d’embedding d’origine) réordonne les candidats fusionnés pour produire le classement final. Le modèle hybride démontre que ce pipeline complet, malgré les étapes de calcul supplémentaires, apporte des gains de précision qui dépassent largement le surcoût ^[11].

En pratique, implémenter cette architecture dans PostgreSQL avec pgvector consiste à combiner une recherche par similarité sur la colonne embedding avec une recherche en texte intégral (via les index tsvector de PostgreSQL), puis à fusionner les scores. Le RAG Cookbook détaille cette combinaison recherche par mots-clés et recherche vectorielle avec pgvector ^[3].

Du prototype au production-grade

Le passage du prototype (POC) au système de production est un saut qualitatif, pas quantitatif. Les KPIs concrets qui changent de statut entre les deux phases sont documentés dans la comparaison POC vs Production établie par des praticiens du RAG ^[12] :

KPI	Définition	POC	Production
Latence de requête	Temps de réponse moyen/médian (50 requêtes)	Moyenne : 7,5 s / Médiane : 8,5 s	Moyenne : 4,5 s / Médiane : 4 s
Disponibilité	% de temps opérationnel	Non mesuré	≥ 99,99 %
Qualité de réponse	Context precision, context recall, taux d’hallucination, answer relevance, score UMBRELA	Non mesuré	CP ≥ 0,9 ; CR ≥ 0,8 ; Hallucination ≤ 5 % ; AR ≥ 0,9 ; UMBRELA > 2,5
Ingestion de données	Sources, types de fichiers, fréquence de rafraîchissement	PDF locaux uniquement	PDF, DOCX, PPTX, HTML, web, S3, Snowflake, Notion ; rafraîchissement quotidien
Pipeline de retrieval	Techniques supportées	Vectorielle uniquement	Vectorielle + hybride + reranking de pertinence + reranking de diversité

Ce tableau sert de checklist : si un KPI est encore au niveau « POC » alors que vous visez la production, c’est un point de blocage à traiter.

Scalabilité horizontale et tolérance aux pannes

Sharding. Quand l’index ne tient plus en mémoire sur un seul GPU, on le répartit (shard) sur S GPU différents. Chaque shard reçoit une fraction des vecteurs et traite l’ensemble des requêtes, puis les résultats partiels sont fusionnés. Le sharding apporte un gain de performance, mais moins net que la réplication, en raison des surcoûts fixes et de l’étape de sélection des k-meilleurs résultats sur les résultats partiels ^[13].

Réplication. Chaque réplica contient une copie complète de l’index. Pour R réplicas, la charge de requêtes est divisée par R. Le speedup est quasi linéaire, sauf pour un nombre de requêtes faible où les surcoûts fixes dominent ^[13]. Sharding et réplication se combinent : S shards, chacun avec R réplicas, soit S × R GPU au total. Le même principe s’applique pour distribuer un index sur plusieurs machines ^[13].

Haute disponibilité. En déploiement managé, les SLA vont de 99,90 % à 99,999 % de disponibilité selon les services ^[4]. En self-hosted, la réplication est le mécanisme principal pour atteindre ces niveaux. Le choix dépend du budget, de l’expertise interne et des contraintes de compliance.

Patterns d’architecture pour les systèmes RAG

Les architectures RAG en production suivent plusieurs patterns, comparés dans les travaux sur les systèmes RAG scalables ^[14] : architecture monolithique (simple mais difficile à faire évoluer), architecture modulaire (composants indépendants et remplaçables), architecture micro-services (chaque composant est un service déployé indépendamment). Le choix dépend de la taille de l’équipe, de la vélocité de développement souhaitée et de la complexité opérationnelle acceptable. Les systèmes modulaires offrent le meilleur compromis pour la plupart des équipes : chaque composant (chunking, embedding, indexation, retrieval, reranking, génération) peut être optimisé, remplacé ou mis à l’échelle indépendamment.

Au-delà du RAG : l’architecture vectorielle au service d’autres cas d’usage

L’investissement dans une base vectorielle ne se limite pas au RAG. Les mêmes briques d’indexation et de recherche de similarité s’appliquent à des scénarios métier très différents.

Unlearning (désapprentissage de modèles)

Le framework RASLIK (Randomized Antipodal Search on Linearized Influence Kernel) utilise la recherche vectorielle pour identifier les données d’entraînement à retirer d’un modèle. Le principe : calculer le noyau d’influence entre les données d’entraînement et une génération cible, mesuré par la similarité cosinus entre les gradients du modèle sur ces données et sur la cible, puis utiliser la recherche de plus proches voisins pour sélectionner les candidats au « forget set » (les vecteurs dont le gradient est aligné avec celui de la cible) et au « retain set » (les vecteurs dont le gradient est opposé, formant des « sketches antipodaux ») ^[15]. C’est une application de la recherche vectorielle à la gouvernance des modèles, loin du RAG.

Requêtes au-delà du top-k

La base AlayaDB introduit un type de requête novateur, la « dynamic inner product range query » (DIPR), qui surmonte les limitations du traditionnel top-k (retourner les k vecteurs les plus proches). Les requêtes DIPR permettent de chercher des vecteurs dont le produit scalaire avec la requête tombe dans un intervalle dynamique, ce qui est plus pertinent pour les cas d’usage où la notion de « assez proche » prime sur « les k plus proches ». AlayaDB intègre aussi un optimiseur de requêtes natif qui sélectionne le meilleur plan d’exécution pour la recherche vectorielle ^[16].

Recherche dans des domaines spécialisés

Dans le projet d’analyse coranique, un jeu de données riche en contexte thématique, historique et théologique est vectorisé et stocké dans une base vectorielle pour permettre des recherches sémantiques. Le format vectorisé dépasse la traduction littérale et permet l’intégration avec des pipelines modernes de recherche et de génération ^[17]. Ce type de déploiement illustre que la base vectorielle est un investissement transverse : le même système sert la recherche documentaire, la recommandation, la détection d’anomalies ou la recherche de similarité non textuelle (images, audio).

Des bases qui s’améliorent avec l’usage

Une architecture vectorielle mature ne reste pas figée. Elle s’adapte aux retours d’usage pour améliorer continuellement ses performances.

Optimisation dynamique par apprentissage par renforcement

Le framework d’évolution des bases de connaissances piloté par feedback des Quality Engineers (QE) propose d’optimiser les mécanismes de retrieval de la base vectorielle via l’apprentissage par renforcement (RL). Le principe : ajuster dynamiquement les paramètres de recherche (seuils de similarité, modèles d’embedding, stratégies de retrieval) en fonction des patterns de feedback. L’agent RL prend des actions et reçoit une récompense composite mesurant l’efficacité perçue par l’utilisateur, l’alignement avec ses préférences de workflow et l’efficience d’exécution ^[18]. Ce paradigme transforme la base vectorielle d’un composant statique en un système qui apprend de ses requêtes.

Le processus RAG comme couche d’optimisation continue

Les dimensions du processus RAG identifiées dans la littérature distinguent cinq étapes, chacune étant un levier d’optimisation ^[19] :

• Pré-retrieval : chunking, vectorisation, indexation, optimisation de l’indexation, amélioration de la requête utilisateur.
• Retrieval : sélection des documents pertinents via la recherche vectorielle et/ou lexicale.
• Post-retrieval : filtrage, reranking de pertinence et de diversité.
• Génération : production de la réponse à partir des documents sélectionnés.
• Post-génération : validation de la réponse, bouclage du feedback utilisateur vers le système de retrieval.

L’architecture évolutive, c’est concevoir dès le départ ces points d’injection. Pas besoin de tout implémenter d’entrée, mais les interfaces doivent être là. Quand le moment viendra d’ajouter de l’optimisation RL, du reranking de diversité ou de nouvelles stratégies de chunking, le système sera prêt à les absorber sans réécriture. Le passage d’un RAG monolithique à un RAG modulaire, avec le LLM comme composant adaptable (entraînable ou bouclé en spécification du paradigme modulaire), est le cap architectural qui permet cette évolution ^[19].

Sources

• [1] LLMOps Managing Large Language Models in Production · livre · Amazon
• [2] Lexically-Accelerated Dense Retrieval · Hrishikesh Kulkarni et al. · 2023 · preprint · arXiv:2307.16779
• [3] RAG with Python Cookbook Practical Recipes from Data Preprocessing to LLM Agents · livre · Amazon
• [4] GenAI on Google Cloud Enterprise Generative AI Systems and Agents · livre · Amazon
• [5] Jasper and Stella: distillation of SOTA embedding models · Dun Zhang et al. · 2024 · preprint · arXiv:2412.19048
• [6] When Text Embedding Meets Large Language Model: A Comprehensive Survey · Zhijie Nie et al. · 2024 · preprint · arXiv:2412.09165
• [7] Dimension Reduction for Efficient Dense Retrieval via Conditional Autoencoder · Zhenghao Liu et al. · 2022 · preprint · arXiv:2205.03284
• [8] When is an Embedding Model More Promising than Another? · Maxime Darrin et al. · 2024 · preprint · arXiv:2406.07640
• [9] PairDistill: Pairwise Relevance Distillation for Dense Retrieval · Chao-Wei Huang et al. · 2024 · preprint · arXiv:2410.01383
• [10] RAG Made Simple: The Complete Visual Guide to Retrieval-Augmented Generation · Nir Diamant · livre · Amazon
• [11] Hybrid Semantic Search: Unveiling User Intent Beyond Keywords · Aman Ahluwalia et al. · 2024 · preprint · arXiv:2408.09236
• [12] Hands-On RAG for Production · Ofer Mendelevitch and Forrest Sheng Bao · livre · Amazon
• [13] Billion-scale similarity search with GPUs · Jeff Johnson et al. · 2017 · preprint · arXiv:1702.08734
• [14] Engineering the RAG Stack: A Comprehensive Review of the Architecture and Trust Frameworks for Retrieval-Augmented Generation Systems · Dean Wampler et al. · 2025 · preprint · arXiv:2601.05264
• [15] Randomized Antipodal Search Done Right for Data Pareto Improvement of LLM Unlearning · Ziwen Liu et al. · 2026 · preprint ·  arXiv:2604.16591
• [16] AlayaDB: The Data Foundation for Efficient and Effective Long-context LLM Inference · Yangshen Deng et al. · 2025 · preprint · arXiv:2504.10326
• [17] Investigating Retrieval-Augmented Generation in Quranic Studies: A Study of 13 Open-Source Large Language Models · Zahra Khalila et al. · 2025 · preprint · arXiv:2503.16581
• [18] Reinforcement Learning Integrated Agentic RAG for Software Test Cases Authoring · Mohanakrishnan Hariharan · 2025 · preprint · arXiv:2512.06060
• [19] Creating a Taxonomy for Retrieval Augmented Generation Applications · Irina Nikishina et al. · 2024 · preprint · arXiv:2408.02854