Qdrant en production : concevoir une recherche vectorielle performante

Pourquoi ce sujet est important

Une démonstration Qdrant peut fonctionner avec quelques milliers de vecteurs et devenir lente ou coûteuse après le passage à plusieurs millions. La performance dépend moins d’un réglage magique que de la cohérence entre modèle d’embedding, structure des collections, filtres, index et matériel.

Comprendre les composants

Une collection définit la taille des vecteurs et la métrique de distance. Chaque point associe un identifiant, un ou plusieurs vecteurs et un payload. L’index HNSW accélère la recherche approchée ; les index de payload accélèrent les filtres. La recherche dense peut être combinée à des vecteurs sparse, à une fusion hybride ou à un reranking.

Modéliser les collections

Séparez les données ayant des dimensions, politiques de rétention ou niveaux de service différents. Conservez tenant, source, droits, langue, date et version d’embedding dans le payload. Créez des index uniquement pour les champs réellement filtrés : chaque index consomme mémoire et temps d’écriture. Utilisez des identifiants stables pour rendre les upserts idempotents.

Dimensionner HNSW et mémoire

Le paramètre de construction influence temps d’indexation, mémoire et rappel. Le paramètre de recherche permet d’arbitrer latence et qualité par requête. Mesurez sur des données représentatives, filtres inclus. La quantification réduit la mémoire mais peut diminuer le rappel ; conservez un échantillon non quantifié pour comparer.

Préparer la production

Définissez réplication, shards et capacité selon le volume et le débit. Testez sauvegarde et restauration, pas seulement la création d’un snapshot. Activez authentification, TLS, limites réseau et supervision. Surveillez p50, p95, p99, mémoire, CPU, taille des segments, temps d’optimisation et erreurs.

Changer de modèle d’embedding

Deux modèles produisent des espaces incompatibles. Ne remplacez pas progressivement les vecteurs dans la même population sans stratégie. Créez une nouvelle collection ou un nouveau vecteur nommé, réindexez, comparez les résultats, puis basculez le trafic avec possibilité de retour arrière.

Tableau de décision

Exemple concret

Pour une base documentaire multi-tenant, chaque fragment reçoit tenant_id, document_id, droits et version_embedding. La requête applique obligatoirement tenant_id et les groupes autorisés avant le classement. Un jeu de 200 questions mesure rappel@10, précision finale et latence. Une nouvelle version d’embedding est chargée dans une collection parallèle avant migration.

Les erreurs fréquentes

• mélanger des embeddings provenant de modèles différents
• oublier d’indexer les champs utilisés dans tous les filtres
• mesurer la latence sans filtre ni concurrence
• considérer la similarité comme une autorisation
• activer la quantification sans mesurer la perte de rappel
• disposer de snapshots jamais restaurés

Checklist de mise en production

• [ ] Dimension et métrique validées
• [ ] Jeu d’évaluation versionné
• [ ] Filtres d’autorisation testés
• [ ] Capacité et concurrence benchmarkées
• [ ] TLS et authentification activés
• [ ] Sauvegarde restaurée dans un environnement isolé
• [ ] Procédure de migration d’embedding documentée

FAQ

Qdrant remplace-t-il une base relationnelle ?

Non. Il sert la recherche vectorielle ; les transactions et la vérité métier restent souvent dans une base relationnelle.

Combien de shards faut-il ?

Il n’existe pas de valeur universelle. Commencez simple et dimensionnez selon volume, débit, taille des vecteurs et stratégie de réplication.

Faut-il utiliser la recherche hybride ?

Oui lorsque mots exacts, références ou noms propres comptent. Validez la fusion sur un jeu de requêtes.

Comment vérifier la qualité ?

Avec des requêtes réelles, des documents attendus et des métriques comme rappel@k, complétées par la qualité de la réponse finale.