Diagnostiquer un problème

Il existe plusieurs raisons possibles à la 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 ex. hnsw_ef élevé, filtres complexes sans index de payload)
Processus d'arrière-plan en concurrence (par ex. optimizer encore en cours après un chargement en masse)
Problème avec le cluster (par ex. problèmes réseau, dégradation matérielle)

Requête unique trop lente (latence)

À utiliser quand : les requêtes individuelles prennent trop longtemps 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 de payload est le goulot d'étranglement
Si la requête utilise des filtres, essayer de les supprimer un à 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 quantization en mémoire : Scalar quantization
Réduire la dimensionalité des vecteurs avec les modèles Matryoshka : Matryoshka Models
Utiliser sursampling + rescore pour les vecteurs haute dimension Search with quantization
Activer io_uring pour les workloads lourds en 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 batch search au lieu de requêtes individuelles Batch search
Activer la quantization pour réduire le coût CPU Scalar quantization
Ajouter des replicas pour distribuer la charge de lecture Replication

À utiliser quand : la recherche filtrée est nettement plus lente que la recherche non filtrée. Réclamation 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 pourrait 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 une réindexation pour créer les liens de sous-graphe filtrables

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

Réduire optimizer_cpu_budget pour réserver plus de CPU pour les requêtes
Utiliser prevent_unoptimized=true pour empêcher la création de segments contenant une grande quantité de données non indexées pour les recherches. À la place, une fois qu'un segment atteint le seuil appelé indexing_threshold, tous les points supplémentaires seront ajoutés en « état différé ».

En savoir plus ici

Mettre always_ram=false sur la quantization (thrashing disque à chaque recherche)
Placer HNSW sur disque pour une production sensible à la latence (réservé au stockage froid)
Augmenter le nombre de segments pour le débit (à l'opposé : moins = mieux)
Créer des index de payload sur tous les champs (gaspille la mémoire)
Blâmer Qdrant avant de vérifier l'état de l'optimizer