Différentes recherches dans une seule 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 différentes requêtes ou filtres.
2. Différentes représentations vectorielles mais la même requête brute.

Si 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 HNSW, pour que HNSW filtrable puisse être construit.

Si le deuxième cas, utilisez named vectors, qui permettent de stocker plusieurs types de vecteurs par point dans une même collection. Attention : les named vectors 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 manque des correspondances exactes ou des mots-clés et vous avez besoin d'une récupération lexicale aux côtés de la recherche sémantique.

Vous avez probablement besoin d'un vecteur sparse pour la recherche textuelle exacte aux côtés du vecteur dense. Qdrant utilise les vecteurs sparse pour les recherches lexicales, car le filtrage de payload ne fournit aucun score de classement.

Choisir un vecteur sparse pour le texte

• BM25 représentations statistiques, intégrées au cœur de Qdrant (calculées côté serveur). Bonne base de référence, fonctionne hors domaine, généralement pour les longs textes. 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 le Text Search Guide
• BM42 sparse appris, basé sur BM25, mais meilleur pour les petits morceaux de texte et avec 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 SDKs). Non maintenu.
• miniCOIL sparse appris, BM25 avec 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. Utilisation montrée dans la documentation FastEmbed miniCOIL.
• SPLADE++ sparse appris avec expansion de termes. Inference et utilisation de ressources plus lourdes 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 la documentation FastEmbed SPLADE.
• Embeddings sparse appris externes, par exemple BAAI/bge-m3.

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

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

À retenir lors de l'utilisation de BM25 et miniCOIL de Qdrant (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é en tant que paramètre
• BM25 pourrait ne pas être bon pour les petits morceaux de texte, car l'algorithme BM25 a été initialement créé pour la recherche sur de longs documents ; envisagez d'ajuster les statistiques de document dans les vecteurs sparse (TF & IDF, k, b).
• Les vecteurs BM25 de Qdrant sont configurés par langue, donc envisagez de personnaliser les stop words, le stemming et la tokenization quand les documents des utilisateurs mélangent plusieurs langues, ou configurez soigneusement les vecteurs par point s'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 encodé de plusieurs façons (par ex. différents modèles, langues ou modalités) et vous voulez rechercher sur différentes représentations dans une seule requête (ne doivent pas toutes être présentes, peut être même une seule).

Utilisez plusieurs prefetches de named vectors, chaque prefetch couvrant une représentation.

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

Vous pouvez aussi rechercher directement sur les 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 de similarité maximale, il est donc impossible de récupérer la liste des scores de similarité maximale individuels pour chaque vecteur de requête.

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

• la métrique de similarité maximale n'est pas symétrique, donc l'utilisation d'un index HNSW avec elle pourrait être problématique
• les représentations multivectors sont très lourdes, car le processus de recherche sur celles-ci.

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

Ce qu'il ne faut PAS faire

• Choisir une méthode de recherche quelconque (par exemple BM25) sans évaluation de sa qualité et des ressources utilisées.
• Utiliser une méthode de recherche quelconque (par exemple BM25) sans prêter attention aux spécificités de leur configuration et de leur applicabilité au cas d'usage.