pgvector vs Qdrant : rappel et latence de la recherche filtrée par ACL

Pourquoi

C'est le test qui tranche Q-004. pgvector documente que « With approximate indexes, filtering is applied after the index is scanned. If a condition matches 10% of rows, with HNSW and the default hnsw.ef_search of 40, only 4 rows will match on average », et propose depuis 0.8.0 les « iterative index scans » ¹. Qdrant intègre le filtre payload à HNSW et regroupe les points par tenant avec is_tenant ³. Le filtre ACL est précisément ce cas : un avocat voit une fraction des dossiers.

Protocole

1. Générer 1 million de chunks synthétiques (texte aléatoire vectorisé par le modèle retenu, ou vecteurs synthétiques) sur 200 dossiers de tailles inégales.
2. Calculer la vérité terrain par recherche exacte (scan complet) pour 100 requêtes et 3 portées (10 %, 30 %, 100 % des dossiers).
3. pgvector : HNSW m=16, ef_construction=64 ; ef_search 40 puis 100 ; hnsw.iterative_scan = off | relaxed_order | strict_order ; index B-tree sur dossier_id ; variante index partiels ; variante RLS active avec rôle non superuser et SET LOCAL app.user_id ² ; lire le plan d'exécution pour vérifier l'ordre filtre / distance.
4. pgvectorscale : même jeu avec StreamingDiskANN et filtre par labels ⁵.
5. Qdrant : collection unique, payload dossier_id indexé is_tenant: true ; variante payload_m: 16, m: 0 ; variante JWT avec claim payload ⁴.
6. Mesurer recall@20 et latence p95, mémoire résidente, temps de construction de l'index.
7. Barrière seule : requêtes sans filtre applicatif, avec RLS ou JWT seulement : zéro point hors portée attendu.

Critères

Rappel filtré à 10 % supérieur ou égal à 90 % du rappel non filtré ; latence p95 inférieure à 200 ms ; zéro point hors portée avec la barrière moteur seule. Si pgvector satisfait les trois, il est retenu (une seule base à exploiter) ; sinon Qdrant.

Résultat

À venir.