Base vectorielle : pgvector, Qdrant et alternatives

L'essentiel

• Deux finalistes : pgvector (extension PostgreSQL, licence PostgreSQL) et Qdrant (serveur dédié en Rust, Apache 2.0). Les deux savent filtrer et imposer un filtre côté moteur (RLS pour l'un, JWT payload pour l'autre).
• Critère qui départage : le comportement du filtre ACL avec l'index HNSW. pgvector documente une perte de rappel en post-filtrage, corrigée par iterative_scan (0.8.0) ; Qdrant intègre le filtre à la traversée du graphe.
• Critère qui rapproche : PostgreSQL est déjà nécessaire (interface, métadonnées, journal). Une seule base à sauvegarder, à surveiller et à chiffrer est un argument fort pour une Box maintenue à distance.
• Écartés pour la Box : Chroma (défaut d'Open WebUI, pas de production multi-utilisateur stricte), Milvus (surdimensionné, dépend de MinIO archivé en distribué), Elasticsearch (DLS payante), Weaviate et OpenSearch (viables mais plus lourds), LanceDB (embarqué, pas de barrière moteur).
• Recommandation provisoire Hypothèse : pgvector pour le POC, avec Qdrant en plan B immédiat si le test de filtrage ACL échoue. Décision dans Q-004.

Ce qu'on demande à la base

1. Stocker vecteurs, texte et métadonnées de chaque chunk.
2. Filtrer par dossier_id dans la recherche, sans perte de rappel, et imposer ce filtre indépendamment du code applicatif (permissions).
3. Recherche hybride (vecteurs + BM25) avec fusion RRF (recherche).
4. Suppression fiable par document, mise à jour des métadonnées en masse (resynchronisation des ACL).
5. Sauvegarde, restauration, chiffrement au repos, exploitation par une seule personne.
6. Licence compatible avec une Box commercialisée.
7. Empreinte raisonnable sur une machine qui réserve sa mémoire au LLM.

Comparatif

Focus pgvector

• Index : IVFFlat (rapide à construire, rappel moindre) ou HNSW (meilleur rappel, construction plus lente, maintenance_work_mem à dimensionner). L'index doit tenir en mémoire ¹.
• Filtrage : « filtering is applied after the index is scanned » ; avec 10 % de lignes éligibles et ef_search 40, environ 4 résultats au lieu de 40. Trois remèdes : index B-tree sur dossier_id, index HNSW partiels (WHERE dossier_id = …, viable pour quelques dizaines de dossiers, ingérable pour des centaines), et hnsw.iterative_scan = relaxed_order avec hnsw.max_scan_tuples (défaut 20 000) ¹.
• Barrière moteur : Row-Level Security avec un rôle applicatif non superuser, FORCE ROW LEVEL SECURITY, politique sur dossier_id, SET LOCAL app.user_id par transaction. Avertissements officiels : fonctions non LEAKPROOF évaluables avant la politique, conditions de course, contraintes d'intégrité qui contournent RLS, row_security = off pour les sauvegardes ³.
• Hybride : tsvector avec la configuration french, requête BM25-like via ts_rank_cd (ce n'est pas exactement BM25 : estimation) ou extension ParadeDB (non vérifiée) ; RRF en une CTE.
• pgvectorscale : à essayer si HNSW + filtre déçoit ; index DiskANN avec recherche filtrée par labels et quantification SBQ ; benchmark éditeur seulement ² Constructeur.
• Exploitation : une base pour tout (utilisateurs de l'interface, dossiers, ACL, journal d'accès, vecteurs) ; sauvegardes PostgreSQL standard ; chiffrement du volume ; réplication possible vers un second disque (sauvegardes).

Focus Qdrant

• Modèle : collections de points (vecteur dense, vecteurs sparse, payload JSON). Filtrage payload intégré au parcours HNSW ; index payload avec is_tenant: true pour regrouper les points d'un même dossier ; option payload_m: 16, m: 0 pour ne pas construire de graphe global quand toutes les requêtes sont filtrées par tenant ⁵.
• Barrière moteur : JWT signé par l'application avec claims access (r), collections et payload (filtre imposé sur dossier_id) ; clé API lecture seule pour les consommateurs ; TLS ⁶.
• Hybride : vecteurs sparse (BM25 ou bge-m3 sparse) et fusion RRF dans une requête query ; pas d'analyseur français intégré pour BM25 : la tokenisation se fait côté application (estimation).
• Mémoire : quantification scalaire, binaire ou produit, stockage on-disk ; claim éditeur « up to 97% » de réduction ⁴ Constructeur.
• Exploitation : un conteneur supplémentaire, ses snapshots (API), sa surveillance, ses mises à jour. Open WebUI le supporte nativement (VECTOR_DB=qdrant, ENABLE_QDRANT_MULTITENANCY_MODE=True par défaut) ¹³.

Grille de critères pondérée

Pondérations et notes sont des estimations d'architecture, pas des mesures ; elles seront remplacées par les résultats de l'expérimentation de filtrage ACL. Notes de 1 (faible) à 5 (fort).

Lecture : pgvector et Qdrant sont à égalité pratique ; l'écart tient au rappel filtré, que seul un test tranchera. OpenSearch est techniquement complet mais trop lourd ; Weaviate demande de vérifier le filtrage post-fusion ; Chroma reste un outil de démonstration.

Recommandation provisoire

Dans les deux cas, la base n'est joignable que depuis le service RAG (réseau Docker interne), le compte applicatif n'a que les droits nécessaires, et le journal d'accès est écrit par l'application (permissions).

Questions ouvertes

• Q-004pgvector ou Qdrant pour la base vectorielle ?HauteOuverte

Ce qu'il reste à tester

• pgvector vs Qdrant : rappel et latence de la recherche filtrée par ACLAvec hnsw.iterative_scan activé, pgvector conserve au moins 90 % du rappel non filtré pour un utilisateur ayant accès à 10 % des dossiers, à une latence inférieure à 200 ms ; Qdrant y parvient sans réglage grâce au filtrage intégré à HNSW. Dans les deux cas, la barrière moteur (RLS, JWT payload) ne renvoie aucun point hors portée.À tester