Rapidité vs précision : mesurer le rappel de la recherche vectorielle quantifiée

Tout le monde souhaite une recherche vectorielle instantanée. Or, les vecteurs de grande dimension sont volumineux. Un seul vecteur de type float-32 à 1 024 dimensions occupe une quantité importante de mémoire, et sa comparaison avec des millions d'autres est très coûteuse en calcul.

Pour résoudre ce problème, les moteurs de recherche comme Elasticsearch utilisent deux stratégies d'optimisation principales :

1. Recherche approximative (hierarchical navigable small world [HNSW]) : au lieu de parcourir chaque document, nous construisons un graphe de navigation pour accéder rapidement au voisinage probable de la réponse.
2. Quantification : nous compressons les vecteurs (par exemple, de nombres flottants 32 bits à des entiers 8 bits ou même à des valeurs binaires 1 bit) afin de réduire l'utilisation de la mémoire et d'accélérer les calculs.

Mais l'optimisation s'accompagne souvent d'une taxe : la précision.

La crainte est légitime : "Si je compresse mes données et que je prends des raccourcis pendant la recherche, vais-je manquer les meilleurs résultats ?" "Cette optimisation dégrade-t-elle la pertinence de mon moteur de recherche ?"

Pour prouver que la quantification d'Elastic ne dégrade pas les résultats, nous avons construit un banc d'essai reproductible utilisant l'ensemble de données DBPedia-14 pour calculer exactement la précision (en particulier le rappel) que nous sacrifions pour la vitesse lorsque nous utilisons les optimisations par défaut dans Elasticsearch.

tldr : c'est probablement beaucoup moins cher que vous ne le pensez. Consultez le notebook ici, et essayez par vous-même.

Définitions (pour les non-experts)

Avant d'examiner le code, clarifions certains termes.

• Pertinence ou rappel : la pertinence est subjective (ai-je trouvé des choses intéressantes ?). Le rappel est mathématique. Si la base de données contient 10 documents qui correspondent parfaitement à votre requête sur le plan mathématique et que le moteur de recherche en trouve neuf, votre rappel est de 90 % (ou 0,9).
• Recherche exacte (à plat) : parfois appelée méthode "force brute". Le moteur de recherche analyse chaque document dans un index et calcule la distance.
  • Avantages : rappel parfait à 100 %.
  • Inconvénients : coût de calcul élevé et lenteur à grande échelle.
• Recherche approximative (HNSW) : la méthode "raccourci". Le moteur de recherche construit un graphe HNSW. Il parcourt le graphe pour trouver les voisins les plus proches.
  • Avantages : extrêmement rapide et scalable.
  • Inconvénients : vous risquez de manquer un voisin si le parcours du graphe s'arrête trop tôt.

L'expérience : exact versus approximatif

Pour tester le rappel, nous avons utilisé l'ensemble de données DBPedia-14, un grand ensemble de données de titres et de résumés répartis en 14 classes ontologiques, couramment utilisé pour l'entraînement et l'évaluation des modèles de catégorisation de texte. Plus précisément, nous nous concentrerons sur la catégorie "Film". Nous voulions comparer les paramètres de production optimisés à une vérité terrain mathématiquement parfaite.

Pour cette expérience, nous utilisons le modèle jina-embeddings-v5-text-small, un modèle multilingue de pointe qui fait référence dans le secteur de la représentation textuelle. Nous avons choisi ce modèle car il définit la norme actuelle pour les plongements lexicaux haute performance. En combinant l'excellente précision de Jina v5 avec la quantification native d'Elasticsearch, nous pouvons démontrer une architecture de recherche à la fois efficace en termes de calcul et garantissant une qualité de récupération optimale.

Nous avons configuré un index avec un double mapping. Nous avons ingéré le même texte dans deux champs différents simultanément :

1. content.raw avec le type : flat. Cela force Elasticsearch à effectuer une analyse exhaustive de l'ensemble des vecteurs Float32. Cette analyse renvoie des résultats de correspondance exacte qui serviront de référence.
2. content avec le type semantic_text. Paramètres par défaut utilisant HNSW + Better Binary Quantization (BBQ). Il s'agit du paramétrage standard optimisé pour la production, permettant une correspondance approximative.

Le test Recall@10

Pour notre métrique, nous avons utilisé Recall@10.

Nous avons choisi 50 films au hasard et lancé la même requête sur les deux champs.

• Si la recherche exacte (à plat) indique que les 10 premiers voisins sont les ID [1, 2, 3... 10].
• Et que la recherche approximative (HNSW) renvoie les identifiants [1, 2, 3… 9, 99].
• Nous avons trouvé neuf des 10 premiers correctement. Le score est 0,9.

Voici le mapping que nous avons utilisé :

Les résultats : la "ligne plate" du succès

Nous avons effectué un test d'échelle, en rechargeant l'ensemble de données complet et en le testant par rapport à des index de 1 000 à 40 000 documents.

Voici ce qui est arrivé au score de rappel :

Les résultats étaient incroyablement stables. Même en augmentant l'échelle, la recherche approximative correspondait à la recherche exacte par force brute >99 % du temps.

Pourquoi cela a-t-il si bien fonctionné ?

On pourrait s'attendre à ce que la compression des vecteurs en valeurs binaires nuise davantage à la précision. La raison en est liée à la façon dont Elasticsearch gère la récupération.

La plupart des modèles de plongement actuels génèrent des vecteurs Float32 en sortie, qui sont de grande taille. Pour optimiser la recherche, Elasticsearch utilise la quantification pour les vecteurs de grande dimension. Plus précisément, depuis la version 9.2, il utilise BBQ par défaut.

BBQ utilise un mécanisme de rescoring :

1. Parcours : le moteur de recherche utilise les vecteurs compressés (quantifiés) pour parcourir rapidement le graphe HNSW. Grâce à la petite taille des vecteurs, il peut effectuer un suréchantillonnage efficace, générant ainsi une liste plus longue de candidats (par exemple, les 100 documents les plus similaires) sans dégradation des performances.
2. Rescoring : une fois ces candidats identifiés, le système récupère les valeurs de pleine précision pour ces quelques documents uniquement afin de calculer le classement final et précis.

Vous obtenez le meilleur des deux mondes : la rapidité de la quantification pour les opérations les plus lourdes et la précision des nombres à virgule flottante pour le tri final.

Pouvons-nous faire mieux ?

Il est important de noter que les résultats présentés ici utilisent les paramètres par défaut et un échantillon aléatoire de données. Considérez-les comme un point de départ performant. Bien que Jina v5 soit extrêmement puissant, ces scores de rappel ne constituent pas une garantie universelle pour tous les ensembles de données. Chaque ensemble de données présente ses propres spécificités, et même s'il est possible d'optimiser davantage les paramètres pour obtenir des performances encore meilleures, il est toujours conseillé de réaliser des tests comparatifs avec vos propres données afin d'en déterminer les limites.

Conclusion

Il s'agit d'un test à très petite échelle. L'objectif de cet exercice n'est pas de mesurer le modèle d'intégration ou BBQ en particulier, mais de démontrer comment mesurer facilement le rappel de votre ensemble de données avec une configuration minimale.

Si vous souhaitez effectuer ce test sur vos propres données, vous pouvez consulter le notebook ici et essayer par vous-même.