## Stocker et retrouver par similarité

Après l'embedding, chaque fragment de document devient un **vecteur** (une liste de nombres
qui encode son sens). La **base vectorielle** stocke ces vecteurs et retrouve les plus
proches d'une question (recherche par similarité, dite *ANN* — Approximate Nearest
Neighbors).

### Le paysage des solutions

- **pgvector** — Une extension de **PostgreSQL**. Avantage décisif pour une institution :
  **pas de nouveau composant** à exploiter, on reste sur une base déjà maîtrisée, sauvegardée
  et auditée. Parfait jusqu'à quelques millions de vecteurs.
- **Qdrant** — Base vectorielle dédiée, écrite en Rust, simple à déployer, **excellent
  filtrage par métadonnées**. Très bon choix souverain auto-hébergé.
- **Milvus** — Conçue pour le **très grand volume** (milliards de vecteurs), puissante mais
  plus complexe à opérer.
- **Weaviate** — Riche en fonctionnalités (modules, recherche hybride intégrée).

### Le critère souverain — et le rôle des métadonnées

Toutes s'auto-hébergent. Pour une administration qui dispose **déjà de PostgreSQL**,
**pgvector** minimise la surface à sécuriser et à sauvegarder. Le **filtrage par
métadonnées** est crucial : il permet de restreindre la recherche aux documents que
l'utilisateur a le **droit** de voir.

> **📌 Cas concret — cloisonner par direction**
> Dans un ministère, un agent de la direction A ne doit pas voir les notes internes de la
> direction B. Chaque fragment est stocké avec une métadonnée `direction` et `niveau`. À
> chaque requête, on **filtre** : `WHERE niveau <= habilitation_agent AND direction IN
> (directions_autorisées)` **avant** la recherche de similarité. Même base, mais chacun ne
> « voit » que son périmètre. Sans ce filtrage, le RAG deviendrait une fuite de données
> organisée.

> **À retenir** — Commencez avec **pgvector** si vous avez déjà PostgreSQL ; ne
> sur-architecturez pas (la base vectorielle se remplace facilement, l'ingestion non).
> Le **filtrage par métadonnées = contrôle d'accès** : à concevoir dès le départ.