Quantized RAG : compresser embeddings et index en prod

Pourquoi “quantizer” un RAG ? (indice : parce que la RAM n'est pas extensible à l’infini)

Un RAG “vanilla” fonctionne très bien… jusqu’au jour où vous mettez des vrais volumes.

Et là, vous découvrez une vérité physique :

Stocker et chercher dans des millions (ou milliards) de vecteurs coûte cher.

Chaque embedding est un vecteur de dimension 384/768/1536 (selon modèle), souvent stocké en float. À grande échelle, la mémoire explose, les caches souffrent, et la latence devient un sport.

Le Quantized RAG vise trois objectifs concrets :

1. Réduire la mémoire (donc le coût),
2. Accélérer la recherche (donc la latence),
3. Garder une qualité de retrieval suffisante (sinon : vous économisez… en répondant faux).

Si vous voulez une remise à niveau sur “embeddings” et “vector DB”, voir glossaire : Embedding et Vector Database.

Ce que vous pouvez quantizer (et ce que vous ne devriez pas quantizer en premier)

Quand on dit “Quantized RAG”, on parle de compression. Mais où, exactement ?

1) Les embeddings stockés (dataset vectors)

C’est la cible principale : les vecteurs des chunks/documents.

La logique est simple : votre corpus est énorme, vos requêtes sont nombreuses, vous voulez que la recherche soit rapide et cache-friendly.

2) L’index ANN (structure de recherche)

L’index peut être plus gros que les vecteurs eux-mêmes. Certains index favorisent la vitesse (graphes), d’autres la compacité (inverted lists + quantization).

3) Le modèle d’embeddings (en amont)

Vous pouvez réduire la dimension, choisir un modèle plus petit, ou quantizer le modèle d’embeddings. C’est parfois utile, mais c’est souvent une optimisation secondaire : le gros coût, en prod, c’est le stockage + la recherche.

4) Le LLM (en aval)

Quantizer le LLM aide sur le coût de génération. Mais ce n’est pas “Quantized RAG” à proprement parler : c’est de l’optimisation de serving. (Utile, mais autre sujet.)

Les techniques qui reviennent partout (PQ, IVF, HNSW… et les autres acronymes de votre futur)

On va faire simple, mais pas simpliste : trois grandes familles dominent en pratique.

A) Product Quantization (PQ) : compresser un vecteur sans l’oublier totalement

La product quantization découpe un vecteur en sous-vecteurs, puis approxime chaque sous-partie par un code (un “centroïde” appris). L’idée : stocker des codes compacts et calculer des distances approximatives très vite.

Le papier de référence “Product quantization for nearest neighbor search” formalise cette approche.¹

Ce que PQ vous donne :

• un gros gain mémoire,
• une distance approximative rapide,
• un trade-off contrôlable entre compression et qualité.

Ce que PQ ne vous donne pas :

• la vérité absolue. C’est approximatif. Donc vous devez mesurer.

B) IVF-PQ : d’abord on réduit le champ, ensuite on quantize

IVF (inverted file) = on partitionne l’espace en “cellules” (coarse quantizer). À la requête, on explore seulement quelques cellules proches.

Puis PQ compresse à l’intérieur de ces cellules.

C’est le pattern “pruning + compression” qu’on retrouve dans des bibliothèques industrielles comme FAISS.²

C) Graph-based ANN (HNSW) : très rapide, mais plus gourmand

HNSW (Hierarchical Navigable Small World) est un index basé sur un graphe navigable. Il est très populaire pour obtenir une excellente latence/recall en mémoire.

Le papier “Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs” (arXiv) décrit l’approche.³

En pratique :

• HNSW = souvent très bon pour la qualité,
• mais peut coûter cher en mémoire à grande échelle.

Bonus : DiskANN (Vamana) et la recherche “à l’échelle du disque”

DiskANN (NeurIPS 2019) est une approche conçue pour du billion-scale avec SSD, en s’attaquant au problème “graph + I/O”. Le papier “DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node” en détaille le cadre.⁴

Et si vous avez des contraintes “web scale” ou “dataset énorme”, DiskANN est un nom à connaître (au minimum pour la culture).

Bonus : ScaNN et la quantization anisotrope (Google)

ScaNN (ICML 2020) vise une recherche vectorielle efficace à grande échelle et met en avant des techniques de compression pour accélérer les calculs (anisotropic vector quantization). L’arXiv 1908.10396 est référencé dans la doc du projet.⁵

Google a aussi communiqué sur ScaNN et ses améliorations (SOAR, etc.) via ses blogs de recherche.⁶

Quantization en pratique : int8, scalar, PQ, binaire… quel impact ?

Le mot “quantization” est un parapluie. Sous ce parapluie, il y a des compromis très différents.

La question à se poser n’est pas “quelle technique est la meilleure ?”, mais :

“Quel type d’erreur suis-je prêt à accepter pour gagner en coût/latence ?”

Le pattern “prod” qui marche : coarse → recall → rerank

Dans un Quantized RAG sérieux, vous ne faites pas “une recherche et basta”.

Vous faites une chaîne en 3 temps :

1. coarse retrieval (rapide, compressé) → récupérer des candidats,
2. recall stage (un peu plus cher) → affiner,
3. reranking (cher mais précis) → trier finement ce que vous injectez au LLM.

Pourquoi ? Parce qu’injecter du bruit dans un prompt, c’est comme mettre du sable dans un moteur.

Architecture “quantized” réaliste : deux étages (et un filet de sécurité)

Le pattern que je vois le plus souvent en entreprise, c’est une architecture à deux étages :

1. Un index compressé qui sert à remonter vite des candidats (coarse/top‑N).
2. Un étage précision qui re-score finement (reranker, ou distance plus fidèle).

Et parfois un filet de sécurité :

3. Une voie “fallback” quand l’incertitude est haute (HITL, “je ne sais pas”, ou recherche alternative).

Pourquoi ce design marche ? Parce que vous acceptez une approximation tôt (quand ça coûte cher) et vous redevenez strict tard (quand ça compte).

Variante A : garder des vecteurs full-precision (pour le reranking de distance)

Une variante très pragmatique :

• on stocke des codes PQ pour la recherche rapide,
• et on garde les vecteurs full-precision pour recalculer une distance plus précise sur les top‑N.

Vous payez un peu plus en stockage (ou en cold storage), mais vous récupérez de la qualité.

Variante B : reranker “texte” (cross-encoder) plutôt que distance vectorielle

Quand vos erreurs viennent du sens (pas de la distance), un reranker texte est souvent plus efficace : il lit réellement question + chunk et tranche.

Ça coûte du compute… mais ça peut vous permettre de compresser plus tôt sans perdre en pertinence finale.

Variante C : hybrid search + quantization (keyword + vecteurs compressés)

Sur du B2B, le retrieval “pur embedding” n’est pas toujours le plus stable.

Quand vous avez des codes, des références, des noms propres, un étage keyword (BM25) peut sauver des cas que le dense retrieval compresse trop.

La morale : quantization ne remplace pas le design du retrieval. Elle s’y ajoute.

Comment décider : un arbre de choix simple (et cruel)

Cas 1 — “On a 200k chunks, ça rame un peu”

Avant de quantizer, regardez :

• votre chunking (trop fin = trop de vecteurs),
• vos filtres (métadonnées),
• votre cache,
• et votre reranking.

Beaucoup de problèmes “performance” sont des problèmes de design.

Cas 2 — “On a des millions de chunks, et on veut du low-latency”

Vous allez probablement vers :

• un index ANN solide (HNSW/IVF, selon contraintes),
• de la quantization PQ/IVF-PQ,
• et un reranker.

Cas 3 — “On vise du billion-scale (ou du dataset qui grossit sans fin)”

Là, vous entrez dans le monde DiskANN/ScaNN/approches hybrides, et la question devient : où est votre data (RAM, SSD, cluster), et quel SLO vous promettez.

Playbook d’implémentation (sans tomber dans l’usine à gaz)

Vous pouvez implémenter un Quantized RAG en itérant, sans tout casser.

1

Stabiliser la baseline (avant de compresser)

Fixez votre chunking, vos filtres, vos logs, et votre évaluation. Sinon, vous ne saurez pas si la régression vient de la quantization ou d’un autre changement.

2

Mesurer recall/latence sur un dataset réel

Construisez un petit benchmark interne (questions réelles + sources attendues). Mesurez retrieval et groundedness, pas seulement la vitesse.

3

Ajouter un étage coarse (IVF/PQ ou autre) en mode “shadow”

Servez le nouveau retrieval en parallèle, comparez les passages récupérés, et logguez les divergences.

4

Ajouter un reranker (ou une étape précision) pour compenser

Objectif : sécuriser la qualité finale. Vous voulez compresser tôt, mais rester strict tard.

5

Déployer progressivement et surveiller les régressions

Canari, feature flag, rollback. La recherche est une infra : quand elle casse, tout le produit casse.

Évaluer un Quantized RAG : ne mesurez pas seulement la latence

Le piège classique : “On a gagné 40% de latence, donc c’est mieux.”

Sauf si votre retrieval a perdu en qualité. Dans ce cas, vous avez gagné du temps… pour répondre à côté.

Une évaluation minimale doit mesurer :

• Recall@k du retrieval (est-ce qu’on récupère les bonnes sources ?),
• latence (p95/p99, pas seulement la moyenne),
• coût (compute + stockage),
• et l’impact sur la réponse (groundedness, citations, taux “je ne sais pas”).

Pour la partie RAG (groundedness/pertinence), des approches comme RAGAS peuvent aider à structurer l’évaluation.⁷

Open source vs commercial : où se fait la différence

Open source

• FAISS est un standard de facto pour la recherche de similarité et inclut des techniques de compression (IVF/PQ).²
• ScaNN est disponible en open source et documenté avec un lien arXiv.⁵
• DiskANN est disponible en open source (repo Microsoft).⁸

Commercial / managed

Les vector DB managées et services “vector search” vendent surtout :

• l’ops (scaling, monitoring),
• la persistance,
• les backups,
• l’intégration.

Vous payez moins de complexité, mais vous devez vérifier :

• ce qui est configurable (quantization, index),
• ce qui est observable (logs, explain),
• ce qui est portable (lock-in).

Les pièges (aka “comment perdre de la qualité sans s’en rendre compte”)

1) Quantizer sur un dataset pas représentatif

Si votre corpus change, vos clusters/coarse quantizers changent. Votre recall aussi.

2) Sur-compression

À un moment, votre index devient “rapide” parce qu’il renvoie du bruit.

3) Oublier le reranking

La quantization est une approximation. Le reranking compense. Sans lui, vous transférez l’erreur au LLM.

4) Confondre “vector similarity” et “relevance”

La similarité vectorielle n’est pas toujours la pertinence métier. Le meilleur remède reste : filtres + reranking + évaluation sur questions réelles.

5) Ne pas prévoir le “rebuild” (et découvrir le drift en prod)

Un index compressé n’est pas éternel.

Quand vos sources changent (nouvelles gammes produits, nouvelles clauses, nouveaux tickets), votre espace vectoriel change.

La question n’est pas “est-ce qu’il faut rebuild ?”. C’est : quand et comment :

• rebuild complet périodique,
• rebuild incrémental,
• ou stratégies hybrides (hot index + cold index).

Sans stratégie, votre Quantized RAG se dégrade lentement… puis tout le monde accuse “l’IA”.

FAQ

Questions frequentes

Quantized RAG = réponses moins bonnes ?+

Pas forcément. Si vous compressez intelligemment (coarse + PQ) et que vous gardez un reranking, vous pouvez souvent améliorer la latence et le coût tout en gardant une qualité stable. La condition : mesurer le recall et la groundedness, pas seulement la vitesse.

HNSW ou IVF-PQ ?+

Ça dépend de vos contraintes. HNSW est souvent excellent pour la qualité en mémoire. IVF-PQ est souvent plus compact et peut être très efficace à grande échelle. Le meilleur choix est empirique : benchmark sur vos embeddings et vos requêtes.

Est-ce que DiskANN est obligatoire ?+

Non. DiskANN est utile quand votre dataset devient énorme et/ou quand vous voulez des performances avec SSD. Beaucoup d’équipes n’en ont pas besoin. Mais connaître le pattern vous évite de réinventer la roue quand vous grandissez.

Sources et references

1. [1]Jégou et al., “Product Quantization for Nearest Neighbor Search”.
2. [2]Johnson et al., “Billion-scale similarity search with GPUs” (FAISS).
3. [3]Malkov & Yashunin, “Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs”.
4. [4]Subramanya et al., “DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node” (NeurIPS 2019).
5. [5]ScaNN (PyPI) — référence l’arXiv 1908.10396.
6. [6]Google Research Blog, “Announcing ScaNN: Efficient Vector Similarity Search”.
7. [7]RAGAS, documentation / repo.
8. [8]Microsoft, DiskANN (GitHub repo).