Diagnostiquer un problème

Il y a plusieurs raisons possibles à une dégradation des performances de recherche. Les plus courantes sont :

Pression mémoire : si l'ensemble de travail dépasse la RAM disponible
Requêtes complexes (par exemple, hnsw_ef élevé, filtres complexes sans index de payload)
Processus en arrière-plan concurrents (par exemple, l'optimiseur encore en cours d'exécution après un chargement en masse)
Problème avec le cluster (par exemple, problèmes réseau, dégradation du matériel)

Requête unique trop lente (latence)

À utiliser quand : les requêtes individuelles prennent trop de temps indépendamment de la charge.

Vérifier si la deuxième exécution de la même requête est nettement plus rapide (indique une pression mémoire)
Essayer la même requête avec with_payload: false et with_vectors: false pour voir si la récupération du payload est le goulot d'étranglement
Si la requête utilise des filtres, essayer de les supprimer un par un pour identifier si une condition de filtre spécifique est le goulot d'étranglement

Affiner les paramètres HNSW : Fine-tuning search
Activer la quantification en mémoire : Scalar quantization
Réduire la dimensionnalité des vecteurs avec les modèles Matryoshka : Matryoshka Models
Utiliser le suréchantillonnage + rescore pour les vecteurs haute dimensionnalité Search with quantization
Activer io_uring pour les charges de travail intensives disque sur Linux io_uring

À utiliser quand : le système ne peut pas servir assez de requêtes par seconde sous charge.

Réduire le nombre de segments (default_segment_number à 2) Maximizing throughput
Utiliser l'API de recherche par lot au lieu de requêtes individuelles Batch search
Activer la quantification pour réduire le coût CPU Scalar quantization
Ajouter des répliques pour distribuer la charge de lecture Replication

À utiliser quand : la recherche filtrée est nettement plus lente que non filtrée. Plainte SA la plus courante après la mémoire.

Créer un index de payload sur le champ filtré Payload index
Utiliser is_tenant=true pour la condition de filtrage primaire : Tenant index
Essayer l'algorithme ACORN pour les filtres complexes : ACORN
Éviter d'utiliser les conditions de filtrage nested comme filtre primaire. Cela peut forcer qdrant à lire les valeurs de payload brutes au lieu d'utiliser l'index.
Si l'index de payload a été ajouté après la construction HNSW, déclencher la réindexation pour créer les liens de sous-graphe filtrables

Essayer de lancer la même requête avec le paramètre indexed_only=true, si la requête est nettement plus rapide, cela signifie que l'optimiseur est encore en cours d'exécution et n'a pas encore indexé tous les segments.
Si l'utilisation du CPU ou des entrées/sorties est élevée même sans requêtes, cela indique également que l'optimiseur est encore en cours d'exécution.

réduire optimizer_cpu_budget pour réserver plus de CPU aux requêtes
Utiliser prevent_unoptimized=true pour éviter de créer des segments avec une grande quantité de données non indexées pour les recherches. À la place, une fois qu'un segment atteint le seuil d'indexation, tous les points supplémentaires seront ajoutés dans l'« état différé ».

En savoir plus ici

Définir always_ram=false sur la quantification (thrashing disque à chaque recherche)
Mettre HNSW sur disque pour la production sensible à la latence (seulement pour l'archivage froid)
Augmenter le nombre de segments pour le débit (inverse : moins = mieux)
Créer des index de payload sur chaque champ (gaspille de la mémoire)
Blâmer Qdrant avant de vérifier l'état de l'optimiseur