Qdrant : la base vectorielle d'un RAG local

#À quoi sert une base vectorielle

Un modèle d'embedding convertit un texte en une liste de nombres — un vecteur — telle que deux textes de sens proche donnent deux vecteurs proches. Retrouver les passages pertinents pour une question revient alors à chercher les vecteurs les plus proches de celui de la question. Sur mille passages, un simple calcul sur l'ensemble suffit. Sur un million, il faut une structure d'index, et c'est le métier d'une base vectorielle : construire et maintenir cette structure, répondre en quelques millisecondes plutôt qu'en comparant chaque vecteur un par un, et rester correcte pendant que le corpus continue de recevoir de nouveaux documents.

Cette étape conditionne tout le reste : un modèle excellent qui reçoit les mauvais passages répond mal, et aucune consigne de prompt ne rattrape une récupération défaillante. C'est pour cette raison que le choix de la base vectorielle, longtemps traité comme un détail d'infrastructure interchangeable, mérite le même soin que le choix du modèle de langage lui-même.

#Ce que Qdrant apporte

Le projet se décrit lui-même comme un moteur de recherche et une base de données vectorielles « haute performance, à grande échelle », taillé pour un filtrage étendu — ce qui le distingue des bibliothèques qui se contentent de chercher le plus proche voisin sans condition. Il est écrit en Rust, ce que ses auteurs présentent comme la raison de sa rapidité et de sa fiabilité sous charge élevée. Au chapitre de la robustesse opérationnelle, le projet documente aussi une journalisation en écriture anticipée (write-ahead logging) qui garantit la persistance des données avec confirmation de mise à jour, même en cas de coupure d'alimentation, ainsi que des métriques, de la télémétrie et des journaux d'audit pour surveiller et déboguer un déploiement en production.

Un serveur autonome

Un conteneur, une API HTTP et gRPC, des clients officiels en Python, Go, Rust, JavaScript/TypeScript, .NET et Java. Il vit indépendamment de votre application, qui peut redémarrer sans jamais perdre l'index construit.

Le filtrage par payload

Chaque vecteur porte des métadonnées — auteur, date, service, type de document — sur lesquelles on filtre pendant la recherche avec des clauses should, must et must_not, pas après. C'est la différence entre une recherche utilisable en entreprise et une démonstration.

La quantification des vecteurs

Compresser les vecteurs pour diviser l'empreinte mémoire par un facteur important (4× en scalaire, jusqu'à 32× en binaire), au prix d'une perte de précision contrôlée et rattrapable.

Les vecteurs creux et multi-vecteurs

Au-delà des vecteurs denses classiques, Qdrant prend en charge les vecteurs creux pour la recherche plein texte et les objets à plusieurs embeddings, utiles pour des modèles à interaction tardive comme ColBERT.

La recherche hybride

Combiner plusieurs vecteurs dans une même requête pour profiter à la fois de la compréhension sémantique et de la précision par mot-clé, avec un résultat fusionné par des stratégies configurables comme la fusion de rangs réciproques (RRF) ou la fusion de scores par distribution (DBSF).

Instantanés et reprise

Sauvegarder une collection et la restaurer ailleurs, ce qui compte le jour où réindexer coûterait des heures de GPU.

Le déploiement distribué

Répartir une collection sur plusieurs nœuds par sharding et réplication, avec redimensionnement sans interruption de service — pertinent au-delà d'un usage strictement local, mais bon à savoir si le projet grandit sans tout reconstruire depuis zéro le jour où une seule machine ne suffit plus.

#Démarrer en local

Le chemin le plus court est le conteneur officiel, avec un volume pour que les données survivent au redémarrage. Une interface web intégrée, décrite par le projet comme « un moyen visuel d'interagir avec vos données et de surveiller la santé de votre déploiement », permet ensuite d'explorer les collections, de gérer les données et d'interroger l'API REST sans écrire une ligne de code — c'est le meilleur outil de diagnostic quand une réponse est mauvaise : on regarde ce qui a réellement été retrouvé, plutôt que de deviner en relisant le code de récupération.

docker run -p 6333:6333 -p 6334:6334 \
  -v "$(pwd)/qdrant_storage:/qdrant/storage" \
  qdrant/qdrant

Le client Python sait aussi fonctionner sans serveur du tout : QdrantClient(":memory:") pour un test jetable, ou QdrantClient(path="chemin/vers/db") pour un stockage local persistant. C'est précieux pour un prototype ou des tests automatisés, le même code passant ensuite au serveur en changeant une ligne de connexion. Le projet documente depuis 2026 une seconde voie d'intégration, Qdrant Edge : une version allégée conçue pour les appareils en ressources limitées, qui s'exécute directement dans le processus de l'application plutôt qu'en architecture client-serveur, avec une synchronisation possible vers un serveur Qdrant complet.

#Le minimum en Python

1. 01
   Se connecter

   from qdrant_client import QdrantClient puis client = QdrantClient(url="http://localhost:6333") pointe vers le conteneur lancé plus haut.
2. 02
   Créer une collection

   client.create_collection(collection_name="docs", vectors_config=VectorParams(size=1024, distance=Distance.COSINE)) — la taille doit correspondre exactement à la dimension de votre modèle d'embedding.
3. 03
   Insérer des points

   client.upsert(collection_name="docs", points=[PointStruct(id=1, vector=[...], payload={"service": "support"})]) associe à chaque vecteur un identifiant et des métadonnées filtrables.
4. 04
   Interroger

   client.query_points(collection_name="docs", query=vecteur_question, limit=5).points renvoie les cinq passages les plus proches, avec leur score et leur payload.

#Le filtrage par métadonnées, la fonction qu'on regrette d'avoir négligée

En situation réelle, une question n'est presque jamais posée sur la totalité du corpus. On cherche dans les documents d'un service, postérieurs à une date, d'un type donné, ou accessibles à l'utilisateur qui pose la question. Qdrant applique ces conditions pendant la recherche vectorielle, avec un vocabulaire de filtre riche — correspondance de mot-clé, recherche plein texte, plages numériques, géolocalisation — combiné par des clauses logiques should, must et must_not, ce qui donne toujours le bon nombre de résultats pertinents là où un filtrage effectué après coup peut ne rien laisser.

Le contrôle d'accès mérite une mention à part : si plusieurs personnes interrogent le même index, le filtre sur les droits est ce qui empêche un modèle de citer à quelqu'un un document qu'il n'a pas le droit de lire. Aucune consigne de prompt ne remplace ce filtre, et l'écrire au niveau de la base plutôt que dans le code applicatif évite qu'un nouveau point d'accès à la même collection oublie de le réappliquer.

#Tenir en mémoire : la quantification des vecteurs

La pratique documentée consiste à chercher sur les vecteurs compressés, puis à réordonner (rescoring) les meilleurs candidats avec les vecteurs d'origine — Qdrant expose un paramètre de suréchantillonnage (oversampling) pour ajuster ce compromis : à 2,4 avec une limite de 100 résultats, 240 candidats sont présélectionnés sur l'index quantifié avant le réordonnancement final. On garde l'essentiel de la précision en divisant la mémoire par quatre ou plus, ce qui sur une machine qui héberge aussi un modèle n'est pas un luxe. La documentation officielle avance par ailleurs jusqu'à 40 fois d'accélération avec la quantification binaire par rapport aux vecteurs d'origine, un chiffre à vérifier sur son propre jeu de données plutôt qu'à prendre pour acquis. Le projet résume l'ensemble de ces options de compression, combinées au stockage sur disque, en annonçant une réduction de l'usage mémoire pouvant aller jusqu'à 97 % — un ordre de grandeur qui explique pourquoi la quantification est présentée comme une fonctionnalité centrale plutôt qu'un réglage marginal.

#Qdrant ou une autre

La question à se poser n'est pas « quelle est la meilleure base vectorielle » mais « qu'est-ce que mon projet exige aujourd'hui ». Un script de test n'a besoin de rien de plus qu'une bibliothèque en mémoire. Une application métier qui interroge déjà PostgreSQL gagne à y ajouter une extension vectorielle plutôt qu'un service de plus. Qdrant devient le bon choix précisément quand plusieurs de ces besoins se cumulent à la fois : un service partagé par plusieurs applications, un filtrage fin sur les métadonnées, un corpus qui continue de grandir, et l'envie de ne pas réécrire soi-même la persistance ou les instantanés. Revenir régulièrement sur ce choix, plutôt que de le figer au premier prototype, évite aussi bien de sur-architecturer un projet modeste que de sous-dimensionner un projet qui a fini par grandir.

• Un RAG local complet, de l'ingestion à la réponse
• Choisir un modèle d'embedding pour le français
• Ajouter un reranker pour améliorer la pertinence
• pgvector : quand PostgreSQL suffit
• Le kit RAG local QuelLLM
• Source : dépôt officiel Qdrant sur GitHub
• Source : documentation officielle de la quantification
• Source : démarrage rapide Qdrant en Python

#FAQ