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.

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.

#Ce que Qdrant apporte

Un serveur autonome

Un conteneur, une API HTTP et gRPC, des clients dans les langages courants. Il vit indépendamment de votre application, qui peut redémarrer sans perdre l'index.

Le filtrage par payload

Chaque vecteur porte des métadonnées — auteur, date, service, type de document — sur lesquelles on filtre pendant la recherche, 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, au prix d'une perte de précision contrôlée.

La recherche hybride

Combiner la similarité sémantique et la correspondance de mots exacts, ce qui rattrape les références, numéros de pièce et noms propres que le sémantique seul manque.

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.

#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 permet ensuite d'inspecter les collections 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é.

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, en écrivant dans un dossier local ou en mémoire. C'est précieux pour un prototype ou des tests automatisés : le même code passe ensuite au serveur en changeant une ligne de connexion.

#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, 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.

#Tenir en mémoire : la quantification des vecteurs

La pratique courante consiste à chercher sur les vecteurs compressés, puis à réordonner les quelques dizaines de meilleurs candidats avec les vecteurs d'origine. 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.

#Qdrant ou une autre

• 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

#FAQ