Différentes Recherches dans Une Requête API

Chaque prefetch exécute exactement une recherche par requête.

Déterminez si l'utilisateur souhaite exécuter plusieurs recherches parallèles sur:

1. Les mêmes représentations vectorielles mais avec des requêtes ou filtres différents.
2. Différentes représentations vectorielles mais la même requête brute.

Si c'est le premier cas, aidez l'utilisateur à concevoir la logique de construction de la requête et/ou des filtres côté application, puis consultez Combining Searches. N'oubliez pas de créer des indices sur les champs de payload filtrables, immédiatement après la création de la collection, avant de construire le HNSW, afin que le HNSW filtrable puisse être construit.

Si c'est le second cas, utilisez les vecteurs nommés, qui permettent de stocker plusieurs types de vecteurs par point dans une seule collection. Attention, les vecteurs nommés ne peuvent actuellement être configurés qu'à la création de la collection. Pour choisir les vecteurs, consultez les recommandations suivantes.

Correspondances de Mots-Clés Manquées

À utiliser quand: la recherche vectorielle pure rate les correspondances exactes de termes ou de mots-clés et vous avez besoin d'une récupération lexicale aux côtés de la recherche sémantique.

Il est très probable que vous ayez besoin d'un vecteur creux pour une recherche textuelle exacte aux côtés du vecteur dense. Qdrant utilise les vecteurs creux pour les recherches lexicales, car le filtrage de payload ne fournit aucun score de classement.

Choisir un Vecteur Creux pour le Texte

• BM25 représentations statistiques, intégrées dans le noyau de Qdrant (calculées côté serveur). Bon point de départ, fonctionne hors du domaine, généralement pour les textes longs. Peut être utilisé pour du contenu non-anglais, mais nécessite une configuration par langue (tokenization, stemming, stopwords, etc) au moment de l'indexation et de la récupération. Plus d'informations dans Text Search Guide
• BM42 vecteur creux appris, basé sur BM25, mais meilleur pour les petits fragments de texte et avec une compréhension du sens. Fonctionne uniquement en anglais. Nécessite un fine-tuning pour la récupération spécifique au domaine. Nécessite FastEmbed (Python/REST uniquement, non disponible dans tous les SDK). Non maintenu.
• miniCOIL vecteur creux appris, BM25 avec une compréhension supplémentaire du sens des mots en contexte. Fonctionne uniquement en anglais. Nécessite un fine-tuning pour la récupération spécifique au domaine. Nécessite FastEmbed. L'utilisation est montrée dans FastEmbed miniCOIL documentation.
• SPLADE++ vecteur creux appris avec expansion de termes. Utilisation plus lourde de l'inférence et des ressources, mais meilleure performance grâce à l'expansion de termes. Nécessite un fine-tuning pour la récupération spécifique au domaine. Fourni dans Qdrant Cloud Inference et les versions FastEmbed fonctionnent uniquement en anglais. Pour utiliser avec FastEmbed, consultez FastEmbed SPLADE documentation.
• Plongements creux appris externes, par exemple BAAI/bge-m3.

À retenir lors de l'utilisation de vecteurs creux pour la recherche lexicale:

• la tokenization et le stemming affectent les correspondances exactes, particulièrement sur les codes personnalisés, les termes, etc.

À retenir lors de l'utilisation de Qdrant BM25 et miniCOIL (basés sur BM25):

• avg_len dans la formule n'est pas calculé côté serveur, c'est la responsabilité de l'utilisateur et il est passé comme paramètre
• BM25 peut ne pas être adapté aux petits fragments de texte, car l'algorithme BM25 a été initialement créé pour la recherche sur de longs documents; envisagez d'ajuster les statistiques des documents dans les vecteurs creux (TF & IDF, k, b).
• Les vecteurs BM25 de Qdrant sont configurés par langue, donc envisagez de personnaliser les stopwords, le stemming et la tokenization quand les documents des utilisateurs mélangent plusieurs langues ou configurez soigneusement les vecteurs par point quand ils sont monolingues.

Plus d'informations sur Sparse Vectors for Text Search

Besoin de Combiner Plusieurs Représentations du Même Élément

À utiliser quand: le même élément est imbriqué de plusieurs façons (par ex. différents modèles, langues, ou modalités) et vous voulez effectuer une recherche sur différentes représentations en une seule requête (ce n'est pas nécessaire que ce soit toutes, ça peut être même une seule).

Utilisez plusieurs prefetch de vecteurs nommés, chaque prefetch couvre une représentation.

• Si vous avez des groupes et sous-groupes de représentations (document -> chunk, image -> patch), vous pourriez utiliser searching in groups. Pour ne pas stocker les mêmes payloads plusieurs fois, consultez Lookup in Groups

Vous pouvez également effectuer une recherche directement sur multivectors, une matrice de vecteurs denses, dans un prefetch.

Cependant, cela s'accompagne de plusieurs considérations, car les multivectors ont été conçus pour supporter les modèles d'interaction tardive utilisant la métrique max similarity, il est donc impossible de récupérer la liste des scores max similarity individuels pour chaque vecteur de requête.

De plus, les multivectors sont rarement un bon choix pour prefetch:

• la métrique max similarity n'est pas symétrique, donc l'utilisation de l'index HNSW avec elle pourrait être problématique
• les représentations multivectors sont très lourdes, car le processus de recherche sur elles.

Il existe des moyens de rendre la récupération multivector moins coûteuse (MUVERA, pooling), vous pouvez en savoir plus dans "Evaluating Tradeoffs of Multi-stage Multi-vector Search"

Ce Qu'il NE FAUT PAS Faire

• Choisir n'importe quelle méthode de recherche (par exemple, BM25) sans évaluation de sa qualité et des ressources utilisées.
• Utiliser n'importe quelle méthode de recherche (par exemple, BM25) sans faire attention aux spécificités de leur configuration et à leur applicabilité au cas d'utilisation.