Vecteurs et bases de vecteurs en prod

La recherche sémantique, au cœur des systèmes RAG (Retrieval-Augmented Generation), repose sur une brique fondamentale : la base de données vectorielle. C’est elle qui permet de trouver des “concepts” similaires plutôt que des mots-clés exacts. Mettre une base de vecteurs en production n’est pas juste une affaire de choix technologique ; c’est un ensemble de compromis entre le volume de données, la fraîcheur, le coût et la latence.

le principe de la recherche vectorielle

Le processus est simple en théorie : on transforme le texte en vecteurs (embeddings), puis on cherche les vecteurs les plus proches dans un index.

critères de choix

Le “meilleur” outil n’existe pas. Le bon choix dépend de vos contraintes.

indexer proprement

La qualité de vos résultats dépend directement de la qualité de votre index.

Normaliser le texte: Avant de créer les embeddings, nettoyez le texte (casse, espaces superflus).
Stocker des métadonnées riches: Chaque vecteur doit être associé à des métadonnées (id source, date, propriétaire, droits d’accès). C’est crucial pour le filtrage.
Choisir la bonne distance: La métrique de similarité (Cosinus, Produit Scalaire, L2) doit correspondre à celle pour laquelle votre modèle d’embedding a été entraîné.

# Exemple de normalisation de texte simple avant l'embedding
def normalize_text(text: str) -> str:
    # Met en minuscule et supprime les espaces multiples
    return " ".join(text.lower().split())

exploiter en RAG

Un RAG efficace ne se contente pas de faire une recherche vectorielle brute.

Pré-filtrer: Utilisez les métadonnées pour réduire l’espace de recherche avant de lancer la recherche vectorielle. C’est plus rapide et plus précis.
Re-classer (Reranking): La recherche vectorielle peut remonter des chunks sémantiquement similaires mais redondants. Un petit modèle de re-classement peut améliorer la pertinence des résultats finaux.
Versionner les embeddings: Si vous changez de modèle d’embedding, vous devez ré-indexer tout votre corpus. Versionnez vos index pour éviter les incohérences.

opérations au quotidien

Maintenance de l’index: Selon la technologie, il peut être nécessaire de compacter ou de rééquilibrer l’index périodiquement pour maintenir les performances.
Sauvegardes: Comme toute base de données, mettez en place des sauvegardes régulières et testez votre processus de restauration.
Gestion des coûts: Surveillez les coûts de mémoire (pour les index in-memory comme HNSW) et de calcul.

tests et mesures

Precision@k: Sur un jeu de questions/réponses de référence, est-ce que le bon document se trouve dans les ‘k’ premiers résultats ? C’est la métrique reine.
Latence p95: Quel est le temps de réponse pour 95% de vos requêtes ?
Coût par requête: Suivez le coût moyen pour servir une recherche.

pièges et parades

Symptôme: Les résultats de recherche sont incohérents.
- Cause: Des embeddings générés avec des modèles différents sont mélangés dans l’index.
- Correctif: Mettre en place un versioning strict. Chaque index est associé à une seule version du modèle d’embedding.
Symptôme: L’API retourne des documents auxquels l’utilisateur ne devrait pas avoir accès.
- Cause: Le filtrage des droits est fait après la recherche vectorielle.
- Correctif: Le filtrage de sécurité doit toujours se faire avant la recherche (pré-filtrage).
Symptôme: On perd tout l’index à cause d’une mauvaise manipulation.
- Cause: Pas de plan de sauvegarde.
- Correctif: Mettre en place un runbook de sauvegarde et de restauration, et le tester tous les trimestres.

faq

Ai-je besoin d’une base de données vectorielle dédiée ? Pas toujours. Pour démarrer avec quelques millions de vecteurs, des extensions comme pgvector pour PostgreSQL sont une excellente option, car elles s’intègrent à votre stack existante. Les solutions managées (Pinecone, Weaviate Cloud) deviennent pertinentes lorsque vous passez à l’échelle et que la performance à faible latence sur de grands volumes devient critique.
Qu’est-ce qu’un index ANN ? ANN signifie “Approximate Nearest Neighbor”. Contrairement à une recherche exacte (kNN) qui est trop lente sur de grands volumes, les index ANN (comme HNSW) font un compromis : ils sont ultra-rapides en échange d’une très légère perte de précision, ce qui est tout à fait acceptable pour la plupart des cas d’usage.

Menu