Dans cet article, vous apprendrez comment utiliser le paramètre de score minimum pour augmenter la précision de vos résultats de recherche sémantique. Si vous souhaitez tester les exemples fournis dans cet article de blog, accédez au notebook Jupyter associé.

Contexte : précision et rappel

En matière de pertinence de recherche, la précision et le rappel sont des concepts clés. Nous encourageons vivement les lecteurs qui ne les connaissent pas encore à se familiariser avec ces concepts. Voici un résumé.

• Précision : la fraction des résultats de recherche renvoyés qui sont pertinents pour l'utilisateur.

• Rappel : la fraction de tous les documents pertinents du corpus inclus dans l'ensemble des résultats de recherche.

En d'autres termes, la précision consiste à ne renvoyer que les résultats pertinents, tandis que le rappel consiste à renvoyer tous les résultats pertinents. Comme vous pouvez l'imaginer, ces deux exigences sont souvent contradictoires. La recherche sémantique a généralement un rappel très élevé, mais peut être à la peine en termes de précision. Poursuivez votre lecture pour découvrir comment contourner ce problème.

Présentation du paramètre de score minimum

Le paramètre "min_score" nous permet d'améliorer la précision en fixant un score minimum, ce qui tronquera le résultat en supprimant toutes les correspondances dont le score est inférieur au seuil défini. Voici un exemple simple :

Normalisation du score

Définir un score minimum est une bonne chose ; cependant, tous les modèles sémantiques ne renvoient pas un score adapté à un seuil statique. ELSER, par exemple, renvoie un score qui n'est pas limité. Certains scores de modèles denses sont fortement regroupés et n'ont de sens que dans le contexte de la requête spécifique.

Pour la plupart des cas de recherche sémantique, nous recommandons d'utiliser une approche de normalisation avant d'appliquer le "min_score". La normalisation garantit que le score du document se situe dans un intervalle défini. Les extracteurs Elasticsearch proposent deux normalisateurs de ce type, "l2_norm" et "minmax". Le plus couramment utilisé est "minmax", car il est facile à comprendre et fonctionne bien dans de nombreux scénarios. Voici les principales propriétés de "minmax" :

• Les scores des documents sont distribués entre 0 et 1.

• Le document ayant le score le plus élevé est toujours noté 1.

• Le document ayant obtenu le score le plus bas est toujours noté 0.

  • Cela peut le rendre moins adapté à la recherche par mots-clés. Voir la section "Recherche hybride" pour plus de détails.

Voici un exemple de requête sémantique normalisée avec min_score. La taille de la fenêtre de classement a été augmentée à 500 pour nous permettre de renvoyer une liste plus longue de résultats de recherche, en commençant à 100.

La taille a été définie sur une valeur plus élevée que celle habituellement observée en production. Cela nous permet de contrôler la qualité des résultats de recherche et de les optimiser.

Recherche hybride utilisant l'extracteur linéaire

Pour la recherche hybride, l'approche la plus simple consiste à normaliser tous les scores, à leur attribuer des pondérations et à appliquer un score minimal. Notez qu'en choisissant des pondérations dont la somme est égale à 1, le score total reste compris entre 0 et 1. Cela facilite l'interprétation des scores finaux et l'ajustement de min_score. Voici un exemple :

Recherche hybride à l'aide de la RRF

Avec le BM25, nous contrôlons souvent la précision par d'autres moyens, par exemple en utilisant l'opérateur AND ou minimum_should_match. De plus, les requêtes composées de termes uniques, précis et rares entraîneront naturellement des résultats de recherche peu nombreux, souvent tous très pertinents. Cela peut causer les problèmes suivants :

• Les résultats situés plus loin dans le classement reçoivent un score normalisé faible dans l'extracteur BM25, même si le score BM25 absolu est proche des meilleurs résultats.

• Si l'on ajoute un score BM25 très faible au score sémantique, le total peut être considéré comme le score sémantique.

• L'absence de contribution au score BM25 peut entraîner la suppression du document par le min_score threshold.

Comme solution, nous pouvons plutôt utiliser la fusion des rangs réciproques (RRF) pour combiner les résultats BM25 et sémantiques. RRF contourne la difficulté de comparer les scores de différents algorithmes de recherche en se concentrant plutôt sur la position dans chaque ensemble de résultats. Dans ce scénario, le min_score est uniquement appliqué à l'extracteur sémantique.

Conclusion

En utilisant min_score, nous avons montré comment réduire le nombre de faux positifs dans nos ensembles de résultats causés par le fort rappel des algorithmes de recherche sémantique. Pour en savoir plus sur les extracteurs, veuillez consulter cet article de blog et la documentation d'Elasticsearch.

Mais en corrigeant ce cas précis, vous risquez de détériorer d’autres requêtes, faute de pouvoir tester chaque cas manuellement. Mais comment vérifier, vous ou votre équipe QA, si une modification d’une requête a un effet en cascade sur les autres ? Et surtout, comment s’assurer que les modifications apportées ont réellement amélioré une requête ?

Vers une évaluation systématique

C’est là que les listes de jugement prennent tout leur sens. Plutôt que de recourir à des tests manuels et subjectifs à chaque changement, vous pouvez définir un ensemble fixe de requêtes pertinentes pour votre cas d’usage, avec leurs résultats attendus.

Cet ensemble vous sert de référence. À chaque modification, vous l’utilisez pour déterminer si votre recherche s’est effectivement améliorée ou non.

Ce qui rend cette approche si précieuse :

• Élimine l’incertitude : plus besoin de vous demander si vos changements impactent d’autres requêtes – les données vous le diront.

• Met fin aux tests manuels : une fois les ensembles de jugement enregistrés, le test devient automatique.

• Accompagne les changements : vous pouvez mettre en évidence des métriques claires qui confirment les bénéfices d’une modification.

Comment constituer votre liste de jugement

L’une des façons les plus simples de commencer consiste à choisir une requête représentative et à sélectionner manuellement les documents pertinents. Deux approches sont possibles pour construire cette liste :

• Jugements binaires : Chaque document associé à une requête reçoit une étiquette simple : pertinent (1) ou non pertinent (0).

• Jugements gradués : chaque document reçoit ici un score selon différents niveaux. Exemple : une échelle de 0 à 4, semblable à une échelle de Likert, où 0 signifie « pas du tout pertinent » et 4 « totalement pertinent », avec des nuances comme « pertinent », « plus ou moins pertinent », etc.

Les jugements binaires sont adaptés lorsque l’intention de recherche est bien définie : ce document doit-il apparaître dans les résultats ou non ?

Les jugements gradués sont utiles lorsque la frontière est plus floue : certains résultats sont meilleurs que d’autres. On peut ainsi distinguer des résultats « très pertinents », « pertinents » ou « inutiles », et utiliser des métriques qui prennent en compte l’ordre des résultats ainsi que les retours des utilisateurs. Mais les échelles graduées présentent aussi des inconvénients : les évaluateurs peuvent interpréter différemment les niveaux de notation, ce qui nuit à la cohérence des jugements. De plus, comme les métriques graduées accordent plus de poids aux notes élevées, une légère variation (par exemple, noter 3 au lieu de 4) peut entraîner un changement bien plus important dans la métrique que ce que l’évaluateur avait anticipé. Cette part de subjectivité rend les jugements gradués plus bruyants et plus difficiles à gérer dans le temps.

Dois-je classer les documents moi-même ?

Pas forcément, car il existe plusieurs façons de créer votre liste de jugement, chacune avec ses avantages et ses inconvénients :

• Jugements explicites : des experts métier examinent chaque couple requête/document et évaluent manuellement le niveau de pertinence. Cela garantit qualité et contrôle, mais c’est moins scalable.

• Jugements implicites : cette méthode déduit les documents pertinents à partir du comportement réel des utilisateurs : clics, taux de rebond, achats, etc. Elle permet de collecter automatiquement des données, mais celles-ci peuvent être biaisées. Par exemple, les utilisateurs ont tendance à cliquer plus souvent sur les premiers résultats, même s’ils ne sont pas pertinents.

• Jugements générés par l’IA : cette dernière option utilise des modèles (comme les LLM) pour évaluer automatiquement les requêtes et les documents – on parle souvent de jurys LLM. C’est rapide et facilement scalable, mais la qualité des données dépend du modèle utilisé et de la pertinence de ses données d’entraînement vis-à-vis de vos objectifs métier. Comme pour les évaluations humaines, les jurys LLM peuvent introduire leurs propres biais ou incohérences. Il est donc essentiel de valider leurs résultats à l’aide d’un ensemble restreint de jugements de confiance. Les modèles LLM sont de nature probabiliste, il n’est donc pas rare de voir un modèle LLM attribuer des scores différents à un même résultat, même avec un paramètre de température réglé sur 0.

Voici quelques recommandations pour choisir la méthode la plus adaptée à la création de votre ensemble de jugement :

• Décidez des fonctionnalités critiques pour lesquelles seuls les utilisateurs peuvent vraiment juger (prix, marque, langue, style, détails du produit, etc.). Si ces éléments sont critiques, vous avez besoin de jugements explicites – au moins pour une partie de votre liste de jugement.

• Utilisez des jugements implicites lorsque votre moteur de recherche génère déjà suffisamment de trafic pour que vous puissiez exploiter les clics, conversions et temps passés comme métriques de tendance. Il reste essentiel d’interpréter ces résultats avec prudence, en les comparant à des jugements explicites afin d’éviter tout biais (ex. : les utilisateurs ont tendance à cliquer sur les premiers résultats, même si des documents plus pertinents apparaissent plus bas).

Pour y remédier, des techniques de réduction des biais de position permettent d’ajuster ou de repondérer les données de clics afin de mieux refléter l’intérêt réel des utilisateurs. Parmi les approches possibles :

• Changement d’ordre des résultats : permet de modifier l’ordre des résultats de recherche pour un sous-ensemble d’utilisateurs afin d’évaluer l’effet de la position sur les clics.

• Les modèles de clic incluent : Dynamic Bayesian Network (DBN), User Browsing Model (UBM), etc. Ces modèles statistiques estiment la probabilité qu’un clic reflète un véritable intérêt et non simplement une position dans la page, en prenant en compte des facteurs comme le défilement, la durée du clic, la séquence de navigation, et le retour aux résultats.

Exemple : application de notation de films

Produits requis

Pour exécuter cet exemple, vous avez besoin d'un cluster Elasticsearch 8.x en cours d'exécution, en local ou sur Elastic Cloud Hosted (hébergé ou sans serveur), ainsi que d'un accès à l'API REST ou à Kibana.

Imaginez une application dans laquelle les utilisateurs peuvent publier leurs avis sur des films et aussi rechercher des films à regarder. Comme ces textes sont rédigés par les utilisateurs eux-mêmes, ils peuvent contenir des fautes de frappe ou de nombreuses variations dans la façon de s’exprimer. Il est donc essentiel que le moteur de recherche puisse interpréter cette diversité et fournir des résultats utiles aux utilisateurs.

Afin de pouvoir tester différentes requêtes sans impacter le comportement global de la recherche, l’équipe métier de votre entreprise a créé l’ensemble de jugement binaire suivant, basé sur les recherches les plus fréquentes :

Requête

DocID

Texte

Performance de DiCaprio

doc1

La performance de DiCaprio dans The Revenant était époustouflante.

Performance de DiCaprio

doc2

Inception montre Leonardo DiCaprio dans l’un de ses rôles les plus emblématiques.

Performance de DiCaprio

doc3

Brad Pitt offre une performance solide dans ce thriller criminel.

Performance de DiCaprio

doc4

Une aventure riche en action avec des effets visuels impressionnants.

films tristes qui vous font pleurer

doc5

Une histoire bouleversante d’amour et de perte qui m’a fait pleurer pendant des heures.

films tristes qui vous font pleurer

doc6

Un des films les plus tristes jamais réalisés — apportez des mouchoirs !

films tristes qui vous font pleurer

doc7

Une comédie légère qui vous fera rire

films tristes qui vous font pleurer

doc8

Une épopée de science-fiction pleine d’action et de rebondissements.

Création de l'index :

Requête BULK :

Voici la requête Elasticsearch utilisée par l’application :

Du jugement aux métriques

À elles seules, les listes de jugement fournissent peu d’informations : elles ne font qu’exprimer une attente vis-à-vis des résultats de nos requêtes. Elles révèlent tout leur intérêt lorsqu’elles servent à calculer des métriques objectives pour évaluer les performances de la recherche.

Aujourd’hui, la plupart des métriques les plus courantes incluent

• Précision : mesure la proportion de résultats réellement pertinents parmi tous les résultats de recherche.

• Rappel : mesure la proportion de documents pertinents que le moteur de recherche a trouvés parmi tous les résultats.

• Gain Cumulé Actualisé (DCG) : mesure la qualité du classement des résultats, en tenant compte du fait que les documents les plus pertinents devraient apparaître en haut de la liste.

• Rang réciproque moyen (MRR) : mesure la position du premier résultat pertinent. Plus un document est haut dans la liste, plus son score est élevé.

En reprenant l’exemple de l’application de notation de films, nous allons calculer la métrique de rappel pour vérifier si des informations sont ignorées par nos requêtes.

Dans Elasticsearch, nous pouvons utiliser les listes de jugement pour calculer ces métriques via l’API Ranking Evaluation. Cette API prend en entrée la liste de jugement, la requête et la métrique à évaluer, puis retourne une valeur qui correspond à une comparaison du résultat de la requête avec la liste de jugement.

Lançons la liste de jugement pour les deux requêtes dont nous disposons :

Nous allons utiliser deux requêtes avec rank_eval : une pour la requête sur DiCaprio et une autre pour les films tristes. Chaque requête est accompagnée de sa propre liste de jugement (notations). Il n’est pas nécessaire d’évaluer tous les documents : ceux qui ne figurent pas dans la liste de notation sont simplement considérés comme non jugés. Pour effectuer les calculs, la métrique de rappel ne prend en compte que l’« ensemble pertinent », c’est-à-dire les documents jugés pertinents dans l’évaluation.

Dans ce cas, la requête sur DiCaprio obtient un rappel de 1, tandis que celle sur les films tristes obtient 0. Autrement dit, nous avons récupéré tous les résultats pertinents pour la première requête, et aucun pour la seconde. Le rappel moyen est donc de 0,5.

Peut-être que nous sommes trop stricts avec le paramètre minimum_should_match : en exigeant que 100 % des mots de la requête soient présents dans les documents, nous risquons d’écarter des résultats pertinents. Supprimons le paramètre minimum_should_match, afin qu’un document soit considéré comme pertinent dès qu’un seul mot de la requête est présent.

Comme vous pouvez le constater, en supprimant le paramètre minimum_should_match dans l'une des deux requêtes, nous obtenons maintenant un rappel moyen de 1 dans les deux cas.

En résumé, supprimer la clause minimum_should_match : 100 % permet d’obtenir un rappel parfait pour les deux requêtes.

Nous l'avons fait ! N'est-ce pas ?

Pas si vite !

En augmentant le rappel, on élargit la gamme des résultats possibles. Cependant, chaque ajustement implique un compromis. D’où l’importance de définir des cas de test complets, en utilisant plusieurs métriques pour évaluer les changements.

Les listes de jugement et les métriques vous évitent d’avancer à l’aveugle lorsque vous apportez des modifications, car vous disposez désormais de données pour les justifier. La validation n’est plus manuelle ni répétitive, et vous pouvez tester vos changements sur plusieurs cas d’usage, et non plus un seul. Les tests A/B vous permettent également de tester en conditions réelles la configuration qui convient le mieux à vos utilisateurs et à votre cas d’utilisation, bouclant ainsi la boucle entre métriques techniques et résultats concrets.

Recommandations finales pour l’utilisation des listes de jugement

Travailler avec des listes de jugement ne consiste pas seulement à mesurer : c’est aussi construire un cadre vous permettant d’itérer en toute confiance. Pour y parvenir, voici quelques recommandations :

1. Démarrez petit, mais démarrez. Il n’est pas nécessaire d’avoir 10 000 requêtes avec 50 listes de jugement chacune. Vous devez seulement identifier les 5 à 10 requêtes les plus critiques pour votre cas d’utilisation, et définir les documents que vous attendez en haut des résultats. Cela vous donne déjà une base de travail. En général, on commence par les principales requêtes et celles qui ne renvoient aucun résultat. Vous pouvez aussi tester en partant d’une métrique simple comme la précision, puis monter en complexité.

2. Validez avec les utilisateurs. Complétez les résultats chiffrés par des tests A/B en production. De cette façon, vous saurez si les modifications prometteuses dans les métriques ont aussi un véritable impact.

3. Gardez la liste vivante. Votre cas d’utilisation évoluera, tout comme vos requêtes critiques. Mettez régulièrement à jour votre liste de jugement pour refléter les nouveaux besoins.

4. Intégrez-la à vos workflows. Intégrez les listes de jugement dans vos pipelines de développement. Assurez-vous que chaque modification de configuration, de synonymes ou d’analyse de texte soit automatiquement validée à partir de votre liste de référence.

5. Connectez les savoir-faire techniques à la stratégie. Ne vous limitez pas à des métriques techniques comme la précision ou le rappel. Utilisez les résultats d’évaluation pour éclairer vos décisions métier.

Le problème de l'étendue des scores

Pour préparer le terrain, examinons l'une des principales raisons pour lesquelles la recherche hybride peut s'avérer difficile : la variation des fourchettes de scores. Notre vieil ami BM25 produit des scores non bornés. En d'autres termes, BM25 peut générer des scores allant de près de 0 à (théoriquement) l'infini. En revanche, les requêtes portant sur les champs dense_vector produiront des scores limités entre 0 et 1. Pour aggraver ce problème, semantic_text obscurcit le type de champ utilisé pour indexer les embeddings, de sorte qu'à moins d'avoir une connaissance détaillée de la configuration de votre index et de votre point de terminaison d'inférence, il peut être difficile de savoir quelle sera la plage de scores de votre requête. Cela pose un problème lorsqu'on essaie d'intercaler des résultats de recherche lexicaux et sémantiques, car les résultats lexicaux peuvent prendre le pas sur les résultats sémantiques, même si ces derniers sont plus pertinents. La solution généralement acceptée pour ce problème est de normaliser les scores avant d'entrelacer les résultats. Elasticsearch dispose de deux outils pour cela, les extracteurs linéaires et RRF.

Le récupérateur RRF applique l'algorithme RRF, en utilisant le rang du document comme mesure de la pertinence et en écartant le score. Étant donné que le score n'est pas pris en compte, les écarts de score ne posent pas de problème.

L'extracteur linéaire utilise une combinaison linéaire pour déterminer le score final d'un document. Il s'agit de prendre le score de chaque composante de la requête pour le document, de le normaliser et de l'additionner pour obtenir le score total. Mathématiquement, l'opération peut être exprimée comme suit :

Où N est la fonction de normalisation et SX est le score de la requête X. La fonction de normalisation est essentielle ici, car elle transforme le score de chaque requête pour utiliser le même intervalle. Pour en savoir plus sur le retriever linéaire , cliquez ici.

La décomposition

Les utilisateurs peuvent mettre en œuvre une recherche hybride efficace à l'aide de ces outils, mais cela nécessite une certaine connaissance de votre index. Prenons un exemple avec l'extracteur linéaire, où nous allons interroger un index avec deux champs :

1. semantic_text_field est un champ semantic_text qui utilise E5, un modèle d'intégration de texte.

2. text_field est un champ standard text

1. Nous utilisons une requête match sur notre champ semantic_text, dont la prise en charge a été ajoutée dans Elasticsearch 8.18/9.0.

Lors de la construction de la requête, nous devons garder à l'esprit que semantic_text_field utilise un modèle d'intégration de texte, de sorte que toute requête sur ce site générera un score entre 0 et 1. Nous devons également savoir que text_field est un champ standard de text et que les requêtes sur ce champ génèreront donc un score non borné. Pour créer un ensemble de résultats pertinents, nous devons utiliser un extracteur qui normalisera les résultats des requêtes avant de les combiner. Dans cet exemple, nous utilisons l'extracteur linéaire avec la normalisation minmax, qui normalise le score de chaque requête à une valeur comprise entre 0 et 1.

La construction de la requête dans cet exemple est assez simple car seuls deux champs sont concernés. Toutefois, la situation peut se compliquer très rapidement à mesure que l'on ajoute d'autres champs, de types différents. Cela démontre que la rédaction d'une requête de recherche hybride efficace nécessite souvent une connaissance plus approfondie de l'index interrogé, afin que les scores des composantes de la requête soient correctement normalisés avant d'être combinés. Cela constitue un obstacle à l'adoption plus large de la recherche hybride.

Regroupement de requêtes

Étendons l'exemple : Et si nous voulions interroger un champ text et deux champs semantic_text? Nous pourrions construire une requête comme celle-ci :

Cela semble être une bonne chose à première vue, mais il y a un problème potentiel. Désormais, les matchs sur le terrain semantic_text représentent ⅔ du score total :

Ce n'est probablement pas ce que vous souhaitez, car cela crée un score déséquilibré. Les effets ne sont peut-être pas très visibles dans un exemple comme celui-ci, qui ne comporte que trois champs, mais ils deviennent problématiques lorsqu'un plus grand nombre de champs sont interrogés. Par exemple, la plupart des index contiennent beaucoup plus de champs lexicaux que de champs sémantiques (c.-à-d. dense_vector, sparse_vector, ou semantic_text). Que se passerait-il si nous interrogions un index comportant 9 champs lexicaux et 1 champ sémantique en utilisant le modèle ci-dessus ? Les correspondances lexicales représenteraient 90% du score, ce qui réduirait l'efficacité de la recherche sémantique.

Une solution courante consiste à regrouper les requêtes en catégories lexicales et sémantiques et à pondérer les deux de manière égale. Cela permet d'éviter que l'une ou l'autre catégorie ne domine le score total.

Mettons cela en pratique. À quoi ressemblerait cette approche de requêtes groupées pour cet exemple en utilisant l'outil de recherche linéaire ?

Wow, ça devient verbeux ! Vous avez peut-être même dû faire défiler l'écran de haut en bas plusieurs fois pour examiner l'ensemble de la requête ! Ici, nous utilisons deux niveaux de normalisation pour créer les groupes de requêtes. Mathématiquement, elle peut être exprimée comme suit :

Ce deuxième niveau de normalisation garantit que les requêtes portant sur les champs semantic_text et text sont pondérées de manière égale. Notez que nous omettons la normalisation de second niveau pour text_field dans cet exemple puisqu'il n'y a qu'un seul champ lexical, ce qui vous évite encore plus de verbosité.

Cette structure d'interrogation est déjà lourde, et nous n'interrogeons que trois champs. Il devient de plus en plus difficile à gérer, même pour les praticiens chevronnés de la recherche, au fur et à mesure que l'on interroge davantage de champs.

Le format d'interrogation à champs multiples

Nous avons ajouté le format de requête multi-champs pour les extracteurs linéaires et RRF dans Elasticsearch 8.19, 9.1 et serverless pour simplifier tout cela. Vous pouvez maintenant effectuer la même requête que ci-dessus avec just :

Ce qui réduit la requête de 55 lignes à seulement 9 ! Elasticsearch utilise automatiquement les mappages d'index pour :

• Déterminer le type de chaque champ interrogé

• Regrouper chaque champ dans une catégorie lexicale ou sémantique

• Pondérer chaque catégorie de manière égale dans la note finale

Cela permet à n'importe qui d'exécuter une requête de recherche hybride efficace sans avoir besoin de connaître les détails de l'index ou les points de terminaison d'inférence utilisés.

Lorsque vous utilisez la méthode RRF, vous pouvez omettre le site normalizer, car le rang est utilisé comme indicateur de la pertinence :

Renforcement par champ

Lors de l'utilisation de l'extracteur linéaire, vous pouvez appliquer un boost par champ pour ajuster l'importance des correspondances dans certains champs. Par exemple, disons que vous interrogez quatre champs : deux champs semantic_text et deux champs text:

Par défaut, chaque champ est pondéré de manière égale dans son groupe (lexical ou sémantique). La répartition des points est la suivante :

En d'autres termes, chaque champ représente 25% du score total.

Nous pouvons utiliser la syntaxe field^boost pour ajouter un boost par champ à n'importe quel champ. Appliquons un boost de 2 à semantic_text_field_1 et text_field_1:

La répartition des points est maintenant la suivante :

Chaque groupe de requêtes est toujours pondéré de manière égale, mais la pondération des champs à l'intérieur des groupes a changé :

• semantic_text_field_1 est 66% du score du groupe de requêtes sémantiques, 33% du score total

• text_field_1 est 66% du score du groupe de requêtes lexicales, 33% du score total

ℹ️ Notez que la fourchette de score total ne changera pas lorsqu'une majoration par champ est appliquée. Il s'agit d'un effet secondaire voulu de la normalisation des scores, qui garantit que les scores des requêtes lexicales et sémantiques restent directement comparables entre eux.

ℹ️ Le boosting par champ peut également être utilisé avec le récupérateur RRF dans Elasticsearch 9.2+.

Résolution sur les caractères génériques

Vous pouvez utiliser le caractère générique * dans le paramètre fields pour faire correspondre plusieurs champs. Si l'on reprend l'exemple ci-dessus, cette requête est fonctionnellement équivalente à l'interrogation explicite des sitesemantic_text_field_1, semantic_text_field_2 et text_field_1:

Il est intéressant de noter que le modèle *_field_1 correspond à la fois à text_field_1 et à semantic_text_field_1. La requête sera exécutée comme si chacun des champs avait été explicitement interrogé. Le fait que le site semantic_text_field_1 corresponde aux deux modèles ne pose pas de problème ; tous les noms de champ correspondant sont dédupliqués avant l'exécution de la requête.

Vous pouvez utiliser les caractères génériques de différentes manières :

• Correspondance des préfixes (ex : *_text_field)

• Correspondance en ligne (ex : semantic_*_field)

• Correspondance des suffixes (ex : semantic_text_field_*)

Vous pouvez également utiliser plusieurs caractères génériques pour appliquer une combinaison des éléments ci-dessus, par exemple *_text_field_*.

Champs de requête par défaut

Le format d'interrogation à champs multiples vous permet également d'interroger un index dont vous ignorez tout. Si vous omettez le paramètre fields, il interrogera tous les champs spécifiés par le paramètre d'indexation index.query.default_field:

Par défaut, index.query.default_field est défini comme *. Ce caractère générique permet de résoudre tous les types de champs de l'index qui prennent en charge les requêtes de termes, ce qui est le cas de la plupart d'entre eux. Les exceptions sont les suivantes :

• dense_vector champs

• rank_vector champs

• Champs de géométrie : geo_point, shape

Cette fonctionnalité est particulièrement utile lorsque vous souhaitez effectuer une recherche hybride sur un index fourni par un tiers. Le format d'interrogation à champs multiples vous permet d'exécuter une requête appropriée de manière simple. Il suffit d'exclure le paramètre fields pour que tous les champs applicables soient interrogés.

Conclusion

Le problème de la plage de scores peut faire de la recherche hybride efficace un casse-tête à mettre en œuvre, en particulier lorsque l'on ne dispose que de peu d'informations sur l'index interrogé ou sur les points de terminaison d'inférence utilisés. Le format d'interrogation à champs multiples pour les extracteurs linéaires et RRF atténue cette difficulté en intégrant une approche de recherche hybride automatisée, basée sur le regroupement de requêtes, dans une API simple et facile d'accès. Des fonctionnalités supplémentaires, telles que le renforcement par champ, la résolution des caractères génériques et les champs de requête par défaut, permettent d'étendre les fonctionnalités à de nombreux cas d'utilisation.

Essayez le format d'interrogation à champs multiples dès aujourd'hui

Vous pouvez tester les extracteurs linéaires et RRF avec le format de requête multi-champs dans des projets Elasticsearch Serverless entièrement gérés avec un essai gratuit. Il est également disponible en version stack à partir de 8.19 & 9.1.

Démarrez en quelques minutes sur votre environnement local à l'aide d'une simple commande :

Comme beaucoup d'entre nous, je suis à la fois heureux et étonné du rythme auquel les capacités de l'IA évoluent. Les grands modèles de langage (LLM) et la recherche vectorielle nous ont d'abord lancés dans la révolution sémantique, où nous ne cherchions plus à trouver des choses à l'aide de mots-clés. Ensuite, les LLM nous ont montré de nouvelles façons d'interagir avec nos données, en utilisant des interfaces de chat pour transformer les demandes en langage naturel en réponses qui distillent de vastes bases de connaissances en résumés facilement consommables. Nous avons maintenant (déjà !) ont les prémices d'une logique automatisée pilotée par le LLM sous la forme de flux de travail "d'IA agentique" qui peuvent comprendre sémantiquement une demande entrante, raisonner sur les étapes à suivre, puis choisir parmi les outils disponibles pour exécuter itérativement des actions afin d'atteindre ces objectifs.

La promesse de l'IA agentique nous oblige à évoluer et à ne plus utiliser principalement l'"ingénierie de l'invite" pour façonner nos interactions génératives avec l'IA, mais à nous concentrer sur la manière dont nous pouvons aider les outils agentiques à obtenir les informations supplémentaires les plus pertinentes et les plus efficaces que le LLM doit prendre en compte lorsqu'il génère ses réponses - l'"ingénierie du contexte" est la prochaine frontière. La recherche hybride est de loin le moyen le plus puissant et le plus souple de faire apparaître un contexte pertinent, et la plateforme Search AI d'Elastic ouvre une toute nouvelle voie pour exploiter les données au service de l'ingénierie contextuelle. Dans cet article, nous allons examiner comment les LLM ont changé le monde de la recherche d'informations sous deux angles, puis comment ils peuvent travailler ensemble pour obtenir de meilleurs résultats. Il y a beaucoup de chemin à parcourir...

Partie I : Comment les LLM ont changé la recherche

Commençons par la façon dont les LLM ont changé la façon dont nous accédons à l'information et dont nous la recherchons.

Notre héritage lexical

Nous vivons tous depuis longtemps dans le monde quelque peu limité de la recherche lexicale (plutôt bien, du mieux que nous pouvons). La recherche est le premier outil que nous utilisons lorsque nous faisons des recherches ou que nous commençons un nouveau projet. Jusqu'à récemment, il nous incombait de formuler nos requêtes de manière à ce qu'elles soient comprises par un moteur de recherche lexical. La recherche lexicale repose sur la mise en correspondance d'une certaine forme de termes d'interrogation avec des mots-clés trouvés dans un corpus de documents, que le contenu soit structuré ou non. Pour qu'une recherche lexicale aboutisse à un document, celui-ci doit correspondre à ce mot-clé (ou disposer d'un vocabulaire contrôlé tel qu'une liste de synonymes ou un dictionnaire pour établir le lien conceptuel).

Exemple de requêtelexicale multi-correspondance

Au moins, les moteurs de recherche ont la possibilité de renvoyer les résultats avec un score de pertinence. Les moteurs de recherche offrent une multitude d'options syntaxiques pour cibler efficacement les données indexées et des algorithmes de pertinence intégrés qui évaluent les résultats en fonction de l'intention de la syntaxe de la requête de l'utilisateur. Les moteurs de recherche bénéficient de décennies de progrès dans les algorithmes de classement par pertinence, ce qui en fait une plate-forme efficace de recherche de données capable de fournir des résultats notés et triés en fonction de leur pertinence par rapport à la requête. Les bases de données et autres systèmes qui utilisent SQL comme principale méthode de recherche de données sont ici désavantagés : il n'y a pas de concept de pertinence dans une requête de base de données ; le mieux qu'ils puissent faire est de trier les résultats par ordre alphabétique ou numérique. La bonne nouvelle, c'est que vous obtiendrez tous les résultats (rappel) avec ces mots-clés, mais qu'ils ne seront pas nécessairement dans un ordre utile par rapport à la raison pour laquelle vous les avez demandés (précision). C'est un point important, comme nous le verrons bientôt...

Entrez dans le dragon (sémantique)

Le potentiel des représentations vectorielles de l'information en tant qu'alternative à la recherche par mot-clé fait l'objet de recherches depuis longtemps. Les vecteurs sont très prometteurs parce qu'ils nous permettent de sortir du mode de correspondance par mot-clé uniquement - parce qu'ils sont des représentations numériques des termes et des poids, les vecteurs permettent de rapprocher mathématiquement les concepts sur la base de la compréhension par un modèle linguistique de la manière dont les termes sont liés les uns aux autres dans le domaine d'apprentissage. Le retard pris par la recherche vectorielle générale s'explique par le fait que les modèles étaient essentiellement limités à des domaines spécifiques et qu'ils n'étaient tout simplement pas assez vastes pour comprendre suffisamment les nombreux concepts différents qu'un terme peut représenter dans des contextes différents.

Ce n'est que lorsque les grands modèles de langage (LLM) sont apparus il y a quelques années, avec leur capacité à s'entraîner sur des quantités de données beaucoup plus importantes (en utilisant des transformateurs et de l'attention), que la recherche vectorielle est devenue pratique - la taille et la profondeur des LLM ont finalement permis aux vecteurs de stocker suffisamment de nuances pour qu'ils puissent réellement capturer le sens sémantique. Cette augmentation soudaine de la profondeur de compréhension a permis aux LLM de remplir un grand nombre de fonctions de traitement du langage naturel (NLP) qui étaient auparavant verrouillées, la plus importante étant peut-être la capacité à déduire le terme suivant le plus probable dans une séquence, compte tenu du contexte de ce qui se trouve dans la séquence jusqu'à présent. L'inférence est le processus qui donne à l'IA générative sa capacité quasi humaine à produire du texte. Le texte généré par l'IA s'appuie sur la compréhension qu'a le LLM de la manière dont les termes sont liés dans ses données d'apprentissage et utilise également la formulation de la demande pour désambiguïser les différents contextes dans lesquels les termes peuvent apparaître.

Aussi magique que soit l'IA générative, les LLM présentent des limites qui entraînent des erreurs de qualité et de précision, communément appelées hallucinations. Les hallucinations se produisent lorsque le LLM n'a pas accès aux informations (ou n'est pas guidé vers le bon contexte) pour fonder sa réponse sur la vérité et que, pour être utile, il génère une réponse confiante et plausible qui a été inventée. Cela s'explique en partie par le fait que les LLM apprennent l'usage de la langue dans de vastes domaines d'informations diverses, mais qu'ils doivent cesser leur formation à un moment donné, de sorte que leur compréhension est soumise à un facteur temporel, ce qui signifie que le modèle ne peut savoir que ce qui était exact jusqu'au moment où il a cessé de se former. Un autre facteur d'hallucinations est que le modèle ne connaît généralement pas les données privées (données non disponibles sur l'internet public), ce qui est particulièrement important lorsque ces données contiennent des termes et une nomenclature spécifiques.

Bases de données vectorielles

Les LLM vectorisent le contenu dans l'espace de leur modèle à l'aide d'une technique appelée "text embedding", qui consiste à intégrer ou à cartographier la signification sémantique du contenu dans la vision du monde du modèle sur la base de la formation qu'il a reçue. Quelques étapes sont nécessaires pour préparer et traiter le contenu à intégrer, notamment le découpage en morceaux et la tokenisation (et la tokenisation des sous-mots). Le résultat est généralement un ensemble de vecteurs denses représentant la compréhension par le modèle de la signification de ce morceau de contenu dans son espace vectoriel. Le découpage est un processus inexact qui vise à adapter le contenu aux limites des contraintes de traitement d'un modèle pour générer des encastrements, tout en essayant de regrouper le texte apparenté dans un morceau à l'aide de constructions sémantiques telles que les indicateurs de phrase et de paragraphe.

La nécessité d'un découpage en morceaux peut entraîner une certaine perte sémantique dans un document incorporé, car les morceaux individuels ne sont pas entièrement associés à d'autres morceaux du même document. L'opacité inhérente aux réseaux neuronaux peut aggraver cette perte - un LLM est véritablement une "boîte noire" dans laquelle les connexions entre les termes et les concepts établies au cours de la formation sont non déterministes et ne peuvent être interprétées par les humains. Cela pose des problèmes d'explicabilité, de reproductibilité, de partialité inconsciente et, potentiellement, de perte de confiance et d'exactitude. Néanmoins, la possibilité de relier sémantiquement des idées, de ne pas être lié à des mots-clés spécifiques lors de la recherche, est extrêmement puissante :

Un exemple de requête sémantique

Les bases de données vectorielles ne sont pas des moteurs de recherche, mais des bases de données ! Lorsqu'une recherche de similarité vectorielle est effectuée, les termes de la requête sont encodés pour trouver un ensemble de coordonnées (d'intégration) dans l'espace vectoriel du modèle. Ces coordonnées sont ensuite utilisées comme œil-de-bœuf pour trouver les documents qui sont les "plus proches voisins" de l'œil-de-bœuf - ce qui signifie que le rang d'un document (ou sa place dans les résultats) est déterminé par la distance de similarité calculée entre les coordonnées de ce document et les coordonnées de la requête. Dans quel sens le classement doit-il primer, lequel des contextes possibles est le plus proche de l'intention de l'utilisateur ? L'image à laquelle je me réfère est une scène du film Stargate, où nous avons les six points de coordonnées qui se croisent pour nous indiquer la destination (l'œil-de-bœuf), mais nous ne pouvons pas nous y rendre sans connaître le "7e symbole" - les coordonnées du point de départ représentant l'intention subjective de l'utilisateur. Ainsi, au lieu que le classement relatif des vecteurs soit basé sur une sphère de similarité toujours plus étendue et indifférenciée, en tenant compte de l'intention subjective de la requête par le biais d'une syntaxe expressive et d'une notation de la pertinence, nous pouvons obtenir quelque chose qui ressemble à un cylindre de pertinence subjective graduée.

Les capacités d'inférence d'un LLM peuvent aider à identifier le contexte le plus probable pour la requête, mais le problème est que sans aide, les coordonnées de la requête entrante ne peuvent être déterminées que par la façon dont le modèle a été formé à l'origine.

D'une certaine manière, on pourrait dire que la similarité vectorielle va à l'extrême opposé d'une correspondance stricte par mot-clé - sa force réside dans sa capacité à surmonter les problèmes d'inadéquation des termes, mais presque jusqu'à la faute: Les LLM tendent à unifier des concepts apparentés plutôt qu'à les différencier. La similarité vectorielle améliore notre capacité à faire correspondre le contenu sur le plan sémantique, mais ne garantit pas la précision car elle peut négliger des mots-clés exacts et des détails spécifiques qui ne sont pas suffisamment désambiguïsés par le modèle. La recherche de similarités vectorielles est puissante en soi, mais nous avons besoin de moyens pour corréler les résultats que nous extrayons d'une base de données vectorielle avec les résultats d'autres méthodes d'extraction.

Techniques de repositionnement

C'est le moment de mentionner une technique générale appelée "reranking", qui consiste à réévaluer ou à normaliser les ensembles de résultats en fonction d'un ordre de classement unifié. Le besoin de reclassement peut être dû au fait que les résultats provenant de sources multiples ou de méthodes de recherche ont des mécanismes de classement/évaluation différents (ou aucun, SQL !), ou le reclassement peut être utilisé pour aligner sémantiquement les résultats provenant de sources non sémantiques sur la requête de l'utilisateur. Le reclassement est une opération de deuxième étape, c'est-à-dire un ensemble de résultats qui ont été collectés par une méthode de recherche initiale (c'est-à-dire le SQL, recherche lexicale, recherche vectorielle) sont ensuite réordonnées avec une méthode de notation différente.

Plusieurs approches sont disponibles, notamment Learning-To-Rank (LTR) et Reciprocal Rank Fusion (RRF) - LTR est utile pour capturer les caractéristiques des résultats de recherche (likes, évaluations, clics, etc.) et les utiliser pour noter et améliorer ou biaiser les résultats. RRF est parfait pour fusionner les résultats obtenus à partir de différentes modalités d'interrogation (par ex. les recherches dans les bases de données lexicales et vectorielles) en une seule liste de résultats. Elastic offre également la possibilité d'ajuster les scores à l'aide de méthodes de reclassement linéaire.

L'une des techniques de reclassement les plus efficaces est cependant le reclassement sémantique, qui utilise la compréhension sémantique d'un LLM pour analyser les vecteurs d'intégration de la requête et des résultats, puis appliquer la notation de la pertinence/le reclassement pour déterminer l'ordre final. Le reranking sémantique nécessite une connexion à un modèle de reranking, bien sûr, et Elasticsearch fournit une API d'inférence qui vous permet de créer des points d'extrémité de rerank qui exploitent des modèles intégrés(Elastic Rerank), des modèles tiers importés ou des services hébergés en externe tels que Cohere ou Google Vertex AI. Vous pouvez ensuite effectuer un reclassement grâce à la syntaxe d'abstraction de la requête du récupérateur:

Exemple d'opération de remise en ordre d'un récupérateur en plusieurs étapes

Ça a l'air bien, non ? Nous pouvons effectuer un reclassement sur des résultats provenant de sources disparates et nous rapprocher d'une compréhension sémantique de tous les types de contenu... Le reclassement sémantique peut être coûteux tant sur le plan du calcul que du temps de traitement nécessaire, et pour cette raison, le reclassement sémantique ne peut être effectué que sur un nombre limité de résultats, ce qui signifie que la manière dont ces résultats initiaux sont récupérés est importante.

La méthode de recherche contextuelle est importante

L'intention subjective est un facteur important dans la détermination de l'exactitude d'un résultat, dans l'évaluation de sa pertinence. Sans la possibilité de prendre en compte l'intention de l'utilisateur lors de l'exécution de la requête (telle qu'elle est exprimée par une syntaxe flexible ou par un reclassement de deuxième niveau), nous ne pouvons que sélectionner les contextes existants déjà encodés dans l'espace de modélisation. La façon dont nous abordons généralement ce manque de contexte est par le biais de techniques telles que Retrieval Augment Generation (RAG). La méthode RAG consiste à déplacer les coordonnées de la requête en incluant des termes connexes supplémentaires issus d'une pré-requête de données contextuelles pertinentes. Le moteur qui fournit ce contexte supplémentaire et sa méthode initiale de recherche sont donc d'autant plus importants pour la précision du contexte !

Passons en revue les différentes méthodes de recherche contextuelle et la manière dont elles peuvent aider ou nuire à une opération RAG :

• La recherche hybride sans moteur de recherche manque encore de pertinence subjective. Si la plateforme qui fournit le RAG est principalement basée sur SQL (ce qui inclut la plupart des plateformes de "lac de données"), elle ne dispose pas d'un système de notation de la pertinence au stade de la recherche initiale. De nombreuses plateformes de lac de données proposent leur propre version de la recherche hybride (et non de la recherche), combinant généralement des techniques de reranking telles que le reranking sémantique et le RRF sur leur recherche basée sur SQL et les résultats de la base de données vectorielles. Un simple tri est manifestement insuffisant pour un classement subjectif, mais même lorsqu'il est utilisé comme base pour une opération de reclassement sémantique à la deuxième étape, SQL comme la recherche à la première étape devient un problème lorsque le reclassement sémantique n'est effectué que sur les "k premiers" résultats - sans un moyen de noter les résultats à la recherche, quelle garantie avons-nous que les meilleurs résultats se trouvent effectivement dans les premiers résultats ?

• La similarité vectorielle n'est pas suffisante pour le RAG. Il s'agit en fait d'un ensemble de problèmes combinés - la perte de l'intégration, les méthodes naïves de regroupement, le mode de calcul de la similarité et la composante manquante cruciale de l'intention subjective. L'un des principaux objectifs de RAG est de fonder les interactions génératives de l'IA sur la vérité objective, à la fois pour éviter les hallucinations et pour informer le LLM des informations privées dont il n'a pas eu connaissance au cours de la formation. Nous pouvons utiliser le contexte supplémentaire fourni par le RAG pour contraindre et orienter les MFR à prendre en compte les liens et les détails que nous savons être les plus importants pour répondre à la question posée. Pour ce faire, nous devons utiliser des approches sémantiques et lexicales.

• RAG (grep/regex) basé sur des fichiers. Certains secteurs de l'univers de l'IA agentique préconisent l'utilisation de fenêtres contextuelles considérablement agrandies qui accèdent aux fichiers locaux via grep et regex pour RAG plutôt que des plates-formes de recherche externes. L'idée est qu'en disposant d'une fenêtre contextuelle beaucoup plus large, les LLM seront en mesure d'établir des connexions conceptuelles au sein de leur propre espace de réflexion plutôt que de s'appuyer sur des éléments fragmentés et de multiples méthodes/plateformes de recherche pour collecter des informations pertinentes. S'il est vrai en théorie que le fait de disposer d'un document entier donne une image plus complète que des segments de document, cela ne peut fonctionner que dans des domaines de données restreints (ou, par exemple, lors de la fourniture de fichiers pour le vibecodage), et même dans ce cas, la méthode de recherche initiale est un balayage de tous les documents avec une correspondance par mot-clé uniquement.

La recherche, c'est plus que l'extraction

Les moteurs de recherche sont conçus pour rendre les requêtes aussi rapides et flexibles que possible. En interne, ils utilisent des structures de données spécialisées pour stocker et récupérer différents types de données de manière adaptée à ces types de données. Elasticsearch permet d'optimiser le stockage et l'interrogation de pratiquement tous les types de données, y compris la recherche lexicale non structurée/texte intégral (correspondance, phrase, proximité, correspondance multiple), la correspondance et le filtrage rapides par mot-clé (correspondance exacte), les plages numériques, les dates, les adresses IP, et est très flexible dans la manière dont il stocke les structures de documents (par ex. les documents imbriqués ou aplatis). Elasticsearch est également une base de données vectorielle native capable de stocker et d'interroger des types de vecteurs épars et denses, et nous continuons à explorer des moyens innovants (par exemple, Better Binary Quantization (BBQ) & DiskBBQ) pour maintenir la fidélité de la recherche tout en améliorant la vitesse, l'évolutivité et les coûts associés au contenu vectorisé. La plateforme Elasticsearch offre également une résilience des données et une haute disponibilité intégrées, ainsi que des fonctionnalités de gestion du cycle de vie des données, telles que les instantanés consult ables, qui vous permettent de conserver les données rarement consultées ou les données conservées à long terme sur un stockage objet rentable, tout en conservant une capacité de recherche totale.

La recherche hybride, c'est le meilleur des mondes

Recherche hybride (et pas seulement recherche hybride !) combine les forces de la recherche lexicale traditionnelle avec la compréhension sémantique des LLM et la recherche par similarité vectorielle. Cette synergie permet de cibler des résultats très pertinents au stade de la recherche grâce à l'une des options syntaxiques souples proposées par un moteur de recherche : options syntaxiques axées sur l'intention et évaluation de la pertinence, recherche de données multimodales, filtrage, agrégations et biais. Avec une syntaxe de recherche telle que ES|QL et des extracteurs à plusieurs niveaux, nous pouvons combiner de manière flexible la recherche traditionnelle avec la recherche sémantique, les filtres et plusieurs techniques de reclassement en une seule requête.

L'un des principaux avantages de la recherche hybride est que vos requêtes peuvent utiliser une syntaxe spécialisée pour plusieurs types de données simultanément. Ces différentes syntaxes d'interrogation peuvent être utilisées non seulement pour trouver des résultats, mais aussi comme filtres ou agrégations sur les résultats. Par exemple, l'analyse géospatiale est l'un des types d'interrogation les plus courants qui est fréquemment combiné à d'autres syntaxes. Vous pouvez par exemple demander des résultats dont les coordonnées géographiques se situent à une distance donnée d'un point, ou demander des agrégations de vos résultats par région, ou encore des agrégations pour suivre et alerter sur les mouvements à l'intérieur ou à l'extérieur d'une zone. Avec la recherche hybride, vous avez la possibilité de combiner des syntaxes pour cibler les résultats de la manière la plus précise possible, afin de retrouver le contenu le plus proche de votre contexte.

Intermède

Cette première partie raconte comment la recherche vectorielle a changé la façon dont nous pouvons récupérer des données et prépare le terrain pour les changements que les LLM ont apportés aux mécanismes d'interrogation que nous utilisons pour interagir avec les données. Nous allons faire comme si nous avions dû diviser ce texte en plusieurs parties pour que les LLM puissent le comprendre sans perdre le contexte... ;-) Nous en apprendrons plus sur les raisons de cette importance dans la Partie II : L'IA agentique et le besoin d'ingénierie contextuelle, et dans la Partie III, nous reviendrons à notre discussion sur la recherche hybride.

Rencontrez le retriever linéaire !

Dans ce billet, nous vous présentons le linear retriever, notre dernier ajout pour soutenir la recherche hybride ! Contrairement à rrf, le récupérateur linear calcule une somme pondérée de toutes les requêtes correspondant à un document. Cette approche préserve l'importance relative de chaque document dans un ensemble de résultats tout en permettant un contrôle précis de l'influence de chaque requête sur le score final. Il s'agit donc d'un moyen plus intuitif et plus souple d'affiner la recherche hybride.

Définition d'un récupérateur linéaire où le score final sera calculé comme suit :

C'est aussi simple que cela :

Vous avez remarqué à quel point c'est simple et intuitif ? (et très similaire à rrf!) Cette configuration vous permet de contrôler précisément la contribution de chaque type de requête au classement final, contrairement à rrf, qui s'appuie uniquement sur les classements relatifs.

Une mise en garde subsiste : les scores knn peuvent être strictement limités, en fonction de la métrique de similarité utilisée. Par exemple, avec la similarité en cosinus ou le produit de points de vecteurs normalisés en unités, les scores se situeront toujours dans l'intervalle [0, 1]. En revanche, les scores sur bm25 sont moins prévisibles et n'ont pas de limites clairement définies.

Mise à l'échelle des scores : kNN vs BM25

L'une des difficultés de la recherche hybride réside dans le fait que les différents outils de recherche produisent des résultats sur des échelles différentes. Prenons par exemple le scénario suivant :

La requête A obtient un score :

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

Les résultats de la requête B :

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

0.63

0.01

0.3

0.4

Vous pouvez voir la disparité ci-dessus : les scores de kNN se situent entre 0 et 1, tandis que les scores de bm25 peuvent varier considérablement. Cette différence rend difficile l'établissement de poids statiques optimaux pour la combinaison des résultats.

La normalisation à la rescousse : le normalisateur MinMax

Pour y remédier, nous avons introduit un normalisateur minmax facultatif qui adapte les scores, indépendamment pour chaque requête, à la plage [0, 1] en utilisant la formule suivante :

Cela permet de préserver l'importance relative de chaque document dans l'ensemble des résultats d'une requête, ce qui facilite la combinaison des scores obtenus par différents extracteurs. Avec la normalisation, les scores deviennent :

La requête A obtient un score :

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1.00

0.01

0.005

0.000

Les résultats de la requête B :

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1.00

0.000

0.465

0.645

Tous les scores se situent désormais dans la fourchette [0, 1] et l'optimisation de la somme pondérée est beaucoup plus simple car nous capturons désormais l'importance (relative à la requête) d'un résultat au lieu de son score absolu et nous maintenons la cohérence entre les requêtes.

Exemple de récupérateur linéaire

Prenons maintenant un exemple pour illustrer ce qui précède et la façon dont le récupérateur linear comble certaines lacunes de rrf. RRF se base uniquement sur les rangs relatifs et ne prend pas en compte les différences de score réelles. Par exemple, compte tenu de ces scores :

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

100

1.5

1

0.5

score du rrf

0.03226

0.03252

0.03200

0.03125

rrf classerait les documents comme suit :

Cependant, doc1 a un score bm25 nettement plus élevé que les autres, ce que rrf ne parvient pas à capturer car il ne tient compte que des rangs relatifs. L'outil linear retriever, combiné à la normalisation, prend correctement en compte les scores et leurs différences, ce qui permet d'obtenir un classement plus significatif :

doc1

doc2

doc3

doc4

knn

0.347

0.35

0.348

0.346

bm25

1

0.01

0.005

0

Comme nous pouvons le voir ci-dessus, l'excellent classement de doc1 et score pour bm25 est correctement pris en compte et reflété dans les notes finales. En outre, tous les scores se situent désormais dans la fourchette [0, 1], ce qui nous permet de les comparer et de les combiner de manière beaucoup plus intuitive (et même de mettre en place des processus d'optimisation hors ligne).

La mise en place de l'ensemble

Pour tirer pleinement parti de l'outil de recherche linear et de la normalisation, la demande de recherche devrait ressembler à ce qui suit :

Cette approche combine le meilleur des deux mondes : elle conserve la flexibilité et la notation intuitive du linear retriever, tout en garantissant une mise à l'échelle cohérente des scores grâce à la normalisation MinMax.

Comme tous nos retrievers, le retriever linear peut être intégré à n'importe quel niveau d'un arbre hiérarchique de retrievers, avec une prise en charge de l'explicabilité, de la mise en évidence des correspondances, du regroupement des champs, etc.

Quand choisir le retriever linéaire et pourquoi cela fait une différence

Le linear retriever :

• Préserve l'importance relative en s'appuyant sur les scores réels, et pas seulement sur les rangs.

• Permet un réglage fin avec des contributions pondérées de différentes requêtes.

• Améliore la cohérence grâce à la normalisation, ce qui rend la recherche hybride plus robuste et plus prévisible.

Conclusion

Le récupérateur linear est déjà disponible sur Elasticsearch Serverless, et les versions 8.18 et 9.0 ! D'autres exemples et paramètres de configuration sont également disponibles dans notre documentation. Essayez-le et voyez comment il peut améliorer votre expérience de la recherche hybride - nous attendons vos commentaires. Bonne recherche !

Quepid soutient les équipes de recherche dans le processus d'évaluation de la qualité de la recherche :

• Construire des ensembles de requêtes

• Créer des listes de jugement

• Calculer les indicateurs de qualité de la recherche

• Comparer différents algorithmes de recherche/rankers sur la base de paramètres de qualité de recherche calculés

Pour notre blog, supposons que nous gérons un magasin de location de films et que notre objectif est d'améliorer la qualité de nos résultats de recherche.

Produits requis

Ce blog utilise les données et les correspondances du référentiel es-tmdb. Les données proviennent de The Movie Database. Pour continuer, créez un index appelé tmdb avec les mappings et indexez les données. Peu importe que vous mettiez en place une instance locale ou que vous utilisiez un déploiement Elastic Cloud pour cela - l'un ou l'autre fonctionne parfaitement. Pour ce blog, nous supposons un déploiement d'Elastic Cloud. Vous pouvez trouver des informations sur la manière d'indexer les données dans le README du dépôt es-tmdb.

Effectuez une simple recherche de correspondance dans le champ du titre pour rocky afin de confirmer que vous disposez des données nécessaires à la recherche :

Vous devriez voir 8 résultats.

Se connecter à Quepid

Quepid est un outil qui permet aux utilisateurs de mesurer la qualité des résultats de recherche et de mener des expériences hors ligne pour l'améliorer.

Vous pouvez utiliser Quepid de deux manières : soit vous utilisez la version gratuite et publiquement disponible à l'adresse https://app.quepid.com, ou installez Quepid sur une machine à laquelle vous avez accès. Cet article suppose que vous utilisez la version hébergée gratuite. Si vous souhaitez mettre en place une instance de Quepid dans votre environnement, suivez le Guide d'installation.

Quelle que soit la configuration choisie, vous devrez créer un compte si vous n'en avez pas déjà un.

Comment configurer un cas Quepid

Quepid est organisé autour des cas "." Un cas stocke les requêtes avec les paramètres de réglage de la pertinence et la façon d'établir une connexion avec votre moteur de recherche.

• Pour les nouveaux utilisateurs, sélectionnez Créer votre premier cas de pertinence.

• Les utilisateurs qui reviennent peuvent sélectionner Cas de pertinence dans le menu de haut niveau et cliquer sur + Créer un cas.

Donnez un nom descriptif à votre cas, par exemple "Movie Search Baseline,", car nous voulons commencer à mesurer et à améliorer notre recherche de base.

Confirmez le nom en sélectionnant Continuer.

Ensuite, nous établissons une connexion entre Quepid et le moteur de recherche. Quepid peut se connecter à une variété de moteurs de recherche, y compris Elasticsearch.

La configuration diffère en fonction de la configuration d'Elasticsearch et de Quepid. Pour connecter Quepid à un déploiement Elastic Cloud, nous devons activer et configurer CORS pour notre déploiement Elastic Cloud et avoir une clé API prête. Les instructions détaillées se trouvent dans le guide pratique correspondant dans la documentation de Quepid.

Saisissez les informations relatives à votre point de terminaison Elasticsearch (https://YOUR_ES_HOST:PORT/tmdb/_search) et toute autre information nécessaire à la connexion (la clé API dans le cas d'un déploiement Elastic Cloud dans les options de configuration avancées ), testez la connexion en cliquant sur ping it et sélectionnez Continue pour passer à l'étape suivante.

Nous définissons maintenant les champs que nous voulons voir apparaître dans le dossier. Sélectionner tout ce qui aide nos évaluateurs humains à évaluer ultérieurement la pertinence d'un document pour une requête donnée.

Définissez title comme champ de titre, laissez _id comme champ d'identification et ajoutez overview, tagline, cast, vote_average, thumb:poster_path comme champs d'affichage supplémentaires. La dernière entrée affiche de petites vignettes pour les films de nos résultats afin de nous guider visuellement, ainsi que les évaluateurs humains.

Confirmez les paramètres d'affichage en sélectionnant le bouton Continuer.

La dernière étape consiste à ajouter des requêtes de recherche au dossier. Ajoutez les trois requêtes star wars, harrison ford, et meilleur film d'action une par une dans le champ de saisie et continuez.

Idéalement, un cas contient des requêtes qui représentent des requêtes réelles d'utilisateurs et illustrent différents types de requêtes. Pour l'instant, nous pouvons imaginer que Star Wars est une requête représentant toutes les demandes de titres de films, que Harrison Ford est une requête représentant toutes les demandes de noms d'acteurs, et que le meilleur film d'action est une requête représentant toutes les demandes de films d'un genre spécifique. C'est ce que l'on appelle généralement un ensemble de requêtes.

Dans un scénario de production, nous échantillonnerions les requêtes à partir des données de suivi des événements en appliquant des techniques statistiques telles que l'échantillonnage proportionnel à la taille et importerions ces requêtes échantillonnées dans Quepid pour inclure les requêtes de la tête (requêtes fréquentes) et de la queue (requêtes peu fréquentes) par rapport à leur fréquence, ce qui signifie que nous privilégions les requêtes les plus fréquentes sans exclure les requêtes rares.

Enfin, sélectionnez Terminer et vous serez redirigé vers l'interface du cas où vous verrez les trois requêtes définies.

Requêtes et besoins d'information

Pour parvenir à l'objectif global d'une liste de jugement, les évaluateurs humains devront juger un résultat de recherche (généralement un document) pour une requête donnée. C'est ce qu'on appelle une paire requête/document.

Parfois, il semble facile de savoir ce que l'utilisateur voulait en regardant la requête. L'objectif de la requête harrison ford est de trouver des films mettant en scène l'acteur Harrison Ford. Qu'en est-il de la requête action? Je sais que je serais tenté de dire que l'intention de l'utilisateur est de trouver des films appartenant au genre action. Mais lesquels ? Les plus récents, les plus populaires, les meilleurs d'après les évaluations des utilisateurs ? Ou bien l'utilisateur souhaite-t-il trouver tous les films intitulés "Action" ? Il y a au moins 12 ( !) films appelés "Action" dans The Movie Database et leurs noms diffèrent principalement par le nombre de points d'exclamation dans le titre.

Deux évaluateurs humains peuvent interpréter différemment une requête dont l'intention n'est pas claire. Le besoin d'information : Un besoin d'information est un désir conscient ou inconscient d'obtenir des informations. La définition d'un besoin d'information aide les évaluateurs humains à juger les documents pour une requête, et joue donc un rôle important dans le processus d'élaboration des listes de jugement. Les utilisateurs experts ou les experts en la matière sont de bons candidats pour spécifier les besoins d'information. Une bonne pratique consiste à définir les besoins d'information du point de vue de l'utilisateur, car c'est à ses besoins que les résultats de la recherche doivent répondre.

Besoins en informations pour les requêtes de notre cas "Recherche de films de référence" :

1. la guerre des étoiles: L'utilisateur souhaite trouver des films ou des émissions de la franchise Star Wars. Les documentaires sur la Guerre des étoiles sont potentiellement pertinents.

2. harrison ford: L'utilisateur souhaite trouver des films mettant en scène l'acteur Harrison Ford. Les films dans lesquels Harrison Ford joue un rôle différent, comme celui de narrateur, sont potentiellement pertinents.

3. meilleur film d'action: L'utilisateur souhaite trouver des films d'action, de préférence ceux dont la moyenne des votes des utilisateurs est élevée.

Comment définir les besoins en information dans Quepid

Pour définir un besoin d'information dans Quepid, accédez à l'interface du cas :

1. Ouvrez une requête (par exemplestar wars) et sélectionnez Toggle Notes.

2. Inscrivez le besoin d'information dans le premier champ et toute note supplémentaire dans le deuxième champ :

3. Cliquez sur Enregistrer.

Pour une poignée de requêtes, ce processus est satisfaisant. Cependant, lorsque vous passez de trois à 100 requêtes (les cas Quepid sont souvent compris entre 50 et 100 requêtes), vous pouvez définir les besoins d'information en dehors de Quepid (par exemple, dans une feuille de calcul), puis les télécharger via Import et sélectionner Besoins d'information.

Créez une équipe dans Quepid et partagez votre cas

Les jugements collaboratifs améliorent la qualité des évaluations de la pertinence. Mettre en place une équipe :

1. Naviguez jusqu'à Équipes dans le menu de haut niveau.

2. Cliquez sur + Ajouter nouveau, saisissez un nom d'équipe (par exemple, "Search Relevance Raters"), puis cliquez sur Créer.

3. Ajoutez des membres en saisissant leur adresse électronique et en cliquant sur Ajouter un utilisateur.

4. Dans l'interface du dossier, sélectionnez Partager le dossier.

5. Choisissez l'équipe appropriée et confirmez.

Créer un livre de jugements dans Quepid

Un livre dans Quepid permet à plusieurs évaluateurs d'évaluer systématiquement les paires requête/document. Pour en créer un :

1. Dans l'interface du dossier, allez dans Jugements et cliquez sur + Créer un livre.

2. Configurez le livre avec un nom descriptif, assignez-le à votre équipe, sélectionnez une méthode de notation (par exemple, DCG@10) et définissez la stratégie de sélection (un ou plusieurs évaluateurs). Utilisez les paramètres suivants pour le livre :

• Nom: "Recherche de films échelle 0-3"

• Équipes avec lesquelles partager ce livre: Cochez la case de l'équipe que vous avez créée.

• Marqueur: DCG@10

3. Cliquez sur Créer un livre.

Le nom est descriptif et contient des informations sur l'objet de la recherche ("Films") ainsi que l'échelle des jugements ("0-3"). Le scoreur DCG@10 sélectionné définit la manière dont la métrique de recherche sera calculée. "DCG" est l'abréviation de Discounted Cumulative Gain (gain cumulatif actualisé ) et "@10" est le nombre de résultats à partir du sommet pris en considération lors du calcul de la mesure.

Dans ce cas, nous utilisons un indicateur qui mesure le gain d'information et le combine avec la pondération positionnelle. D'autres mesures de recherche peuvent être plus adaptées à votre cas d'utilisation et le choix de la bonne mesure est un défi en soi.

Remplir le book avec des paires requête/document

Afin d'ajouter des paires requête/document pour l'évaluation de la pertinence, suivez les étapes suivantes :

1. Dans l'interface du cas, naviguez vers "Judgements."

2. Sélectionnez le livre que vous avez créé.

3. Cliquez sur "Populate Book" et confirmez en sélectionnant "Refresh Query/Doc Pairs for Book."

Cette action génère des paires basées sur les meilleurs résultats de recherche pour chaque requête, prêtes à être évaluées par votre équipe.

Laissez votre équipe d’évaluateurs humains juger

Jusqu'à présent, les étapes franchies étaient plutôt techniques et administratives. Maintenant que cette préparation nécessaire est faite, nous pouvons laisser notre équipe de juges faire son travail. En substance, le travail du juge consiste à évaluer la pertinence d'un document particulier pour une requête donnée. Le résultat de ce processus est la liste de jugement qui contient tous les labels de pertinence pour les paires de documents de la requête jugés. Ensuite, ce processus et son interface sont expliqués plus en détail.

Aperçu de l'interface Human Rating

L'interface Human Rating de Quepid est conçue pour des évaluations efficaces :

• Requête : Affiche le terme de la recherche.

• Besoin d'information : Indique l'intention de l'utilisateur.

• Lignes directrices pour la notation : Fournit des instructions pour des évaluations cohérentes.

• Métadonnées du document : Présente des détails pertinents sur le document.

• Boutons d'évaluation : Permet aux évaluateurs d'attribuer des jugements à l'aide des raccourcis clavier correspondants.

Utilisation de l'interface Human Rating

En tant qu'évaluateur humain, j'accède à l'interface via l'aperçu du livre :

1. Accédez à l'interface du dossier et cliquez sur Jugements.

2. Cliquez sur Plus de jugements sont nécessaires !

Le système présentera une paire requête/document qui n'a pas encore été évaluée et qui nécessite des jugements supplémentaires. Elle est déterminée par la stratégie de sélection du Livre :

• Un seul évaluateur: Un seul jugement par paire requête/document.

• Plusieurs évaluateurs: Jusqu'à trois évaluations par paire requête/document.

Évaluation des paires requête/document

Voyons quelques exemples. Lorsque vous suivrez ce guide, vous serez probablement confronté à différents films. Cependant, les principes de notation restent les mêmes.

Notre premier exemple est le film "Heroes" pour la requête harrison ford:

Nous examinons d'abord la requête, puis le besoin d'information et jugeons ensuite le film sur la base des métadonnées fournies.

Ce film est un résultat pertinent pour notre requête, puisque Harridson Ford en fait partie. Nous pouvons considérer subjectivement que les films plus récents sont plus pertinents, mais cela ne fait pas partie de notre besoin d'information. Nous attribuons donc à ce document la note "parfait", qui correspond à un 3 dans notre échelle de notation.

Notre prochain exemple est le film "Ford contre Ferrari" pour la requête harrison ford:

Selon la même pratique, nous évaluons cette requête/document en examinant la requête, le besoin d'information et la correspondance entre les métadonnées du document et le besoin d'information.

C'est un mauvais résultat. Ce résultat est probablement dû au fait que l'un des termes de notre requête, "ford", figure dans le titre. Mais Harrison Ford ne joue aucun rôle dans ce film, ni dans aucun autre. Nous attribuons donc à ce document la note "médiocre", ce qui correspond à un 0 dans notre échelle de notation.

Notre troisième exemple est le film "Action Jackson" pour la requête meilleur film d'action :

Cela ressemble à un film d'action, donc le besoin d'information est au moins partiellement satisfait. Cependant, la moyenne des votes est de 5,4 sur 10. Ce qui fait que ce film n'est probablement pas le meilleur film d'action de notre collection. Cela m'amènerait, en tant que juge, à attribuer à ce document la note "Passable", qui correspond à la note 1 dans notre échelle de notation.

Ces exemples illustrent le processus d'évaluation des paires requête/document avec Quepid en particulier, à un niveau élevé et aussi en général.

Bonnes pratiques pour les évaluateurs humains

Les exemples présentés peuvent donner l'impression qu'il est facile de parvenir à des jugements explicites. Mais la mise en place d'un programme d'évaluation humaine fiable n'est pas une mince affaire. C'est un processus plein de défis qui peut facilement compromettre la qualité de vos données :

• Les évaluateurs humains peuvent être fatigués par des tâches répétitives.

• Les préférences personnelles peuvent fausser les jugements.

• Les niveaux d'expertise varient d'un juge à l'autre.

• Les évaluateurs jonglent souvent avec de multiples responsabilités.

• La pertinence perçue d'un document peut ne pas correspondre à sa pertinence réelle par rapport à une requête.

Ces facteurs peuvent entraîner des jugements incohérents et de faible qualité. Mais ne vous inquiétez pas - il existe des bonnes pratiques éprouvées qui peuvent vous aider à minimiser ces problèmes et à mettre en place un processus d'évaluation plus solide et plus fiable :

• Évaluation cohérente : Examiner la requête, le besoin d'information et les métadonnées du document dans l'ordre.

• Se référer aux lignes directrices : Utiliser les lignes directrices pour la notation afin de maintenir la cohérence. Les lignes directrices en matière de notation peuvent contenir des exemples illustrant le processus de jugement et indiquant quand appliquer telle ou telle note. La vérification des évaluateurs humains après le premier lot de jugements s'est avérée être une bonne pratique pour connaître les cas limites difficiles et les domaines dans lesquels une aide supplémentaire est nécessaire.

• Utilisez les options : En cas d'incertitude, utilisez "I Will Judge Later" ou "I Can't Tell," en fournissant des explications si nécessaire.

• Faire des pauses : Des pauses régulières permettent de maintenir la qualité du jugement. Quepid facilite les pauses régulières en lançant des confettis chaque fois qu'un évaluateur humain termine un lot de jugements.

En suivant ces étapes, vous établissez une approche structurée et collaborative pour créer des listes d'arrêts dans Quepid, améliorant ainsi l'efficacité de vos efforts d'optimisation de la pertinence des recherches.

Étapes suivantes

Que faire maintenant ? Les listes de jugement ne sont qu'une étape fondamentale vers l'amélioration de la qualité des résultats de recherche. Voici les prochaines étapes :

Calculer les indicateurs et commencer à expérimenter

Une fois que les listes de jugements sont disponibles, l'exploitation des jugements et le calcul des mesures de la qualité de la recherche constituent une progression naturelle. Quepid calcule automatiquement la mesure configurée pour l'affaire en cours lorsque les jugements sont disponibles. Les mesures sont implémentées en tant que "Scorers" et vous pouvez fournir les vôtres lorsque les mesures supportées n'incluent pas vos préférées !

Accédez à l'interface du cas, naviguez jusqu'à Sélectionner un évaluateur, choisissez DCG@10 et confirmez en cliquant sur Sélectionner un évaluateur. Quepid va maintenant calculer le DCG@10 par requête ainsi que la moyenne des requêtes globales afin de quantifier la qualité des résultats de recherche pour votre cas.

Maintenant que la qualité de vos résultats de recherche est quantifiée, vous pouvez lancer les premières expériences. L'expérimentation commence par la formulation d'hypothèses. En examinant les trois requêtes de la capture d'écran après avoir effectué un classement, il est évident que les trois requêtes ont des performances très différentes en termes de qualité de recherche : la guerre des étoiles est assez performante, harrison ford semble correct mais le plus grand potentiel réside dans le meilleur film d'action.

En développant cette requête, nous voyons ses résultats et pouvons nous plonger dans les détails les plus infimes et explorer les raisons pour lesquelles les documents correspondent et ce qui influence leurs scores :

En cliquant sur "Explain Query" et en entrant dans l'onglet "Parsing", nous voyons que la requête est une DisjunctionMaxxQuery qui recherche trois champs : cast, overview et title:

En général, en tant qu'ingénieurs de recherche, nous connaissons certaines spécificités de notre plateforme de recherche. Dans ce cas, nous pouvons savoir que nous avons un champ de genre. Ajoutons-le à la requête et voyons si la qualité de la recherche est améliorée.

Nous utilisons l'Environnement de recherche qui s'ouvre lorsque l'on sélectionne Accorder la pertinence dans l'interface du cas. Allez-y et explorez cette possibilité en ajoutant le champ des genres dans lequel vous effectuez votre recherche :

Cliquez sur Réexécuter mes recherches ! Et consultez les résultats. Ont-ils changé ? Malheureusement, ce n'est pas le cas. Nous avons maintenant beaucoup d'options à explorer, essentiellement toutes les options de requête offertes par Elasticsearch :

• Nous pourrions augmenter le poids du champ sur le champ des genres.

• Nous pourrions ajouter une fonction qui augmente les documents en fonction de leur moyenne de votes.

• Nous pourrions créer une requête plus complexe qui n'augmenterait les documents en fonction de leur moyenne de vote que s'il existe une forte correspondance des genres.

• …

L'avantage d'avoir toutes ces options et de les explorer dans Quepid est que nous avons un moyen de quantifier les effets non seulement sur la requête que nous essayons d'améliorer, mais aussi sur toutes les requêtes que nous avons dans notre cas. Cela nous évite d'améliorer une requête peu performante en sacrifiant la qualité des résultats de recherche pour les autres. Nous pouvons itérer rapidement et à peu de frais et valider la valeur de notre hypothèse sans aucun risque, ce qui fait de l'expérimentation hors ligne une capacité fondamentale pour toutes les équipes de recherche.

Mesurer la fiabilité inter-évaluateurs

Même avec des descriptions de tâches, des besoins d'information et une interface d'évaluation humaine comme celle fournie par Quepid, les évaluateurs humains peuvent ne pas être d'accord.

Le désaccord en soi n'est pas une mauvaise chose, bien au contraire : mesurer le désaccord peut mettre en lumière des questions que vous pourriez vouloir aborder. La pertinence peut être subjective, les requêtes peuvent être ambiguës et les données peuvent être incomplètes ou incorrectes. Le Kappa de Fleiss est une mesure statistique de l'accord entre les évaluateurs et il existe un cahier d'exemples dans Quepid que vous pouvez utiliser. Pour le trouver, sélectionnez Notebooks dans la navigation de haut niveau et sélectionnez le carnet Fleiss Kappa.ipynb dans le dossier examples.

Conclusion

Quepid vous permet de relever les défis les plus complexes en matière de pertinence des recherches et continue d'évoluer : à partir de la version 8, Quepid prend en charge les jugements générés par l'IA, ce qui est particulièrement utile pour les équipes qui souhaitent faire évoluer leur processus de génération de jugements.

Les flux de travail de Quepid vous permettent de créer efficacement des listes d'arrêts évolutives, ce qui se traduit par des résultats de recherche qui répondent réellement aux besoins des utilisateurs. Une fois les listes de jugement établies, vous disposez d'une base solide pour mesurer la pertinence des recherches, procéder à des améliorations itératives et améliorer l'expérience des utilisateurs.

N'oubliez pas que l'optimisation de la pertinence est un processus continu. Les listes de jugement vous permettent d'évaluer systématiquement vos progrès, mais elles sont plus efficaces lorsqu'elles sont associées à l'expérimentation, à l'analyse des mesures et aux améliorations itératives.

Lecture complémentaire

• Docs Quepid :

  • La pertinence est un sport d'équipe

  • Quepid pour les évaluateurs humains

  • Comment connecter Quepid à Elastic Cloud ?

• Dépôt Github de Quepid

• Meet Pete, une série de blogs sur l'amélioration de la recherche dans le domaine du commerce électronique

• Relevance Slack: rejoignez le canal #quepid

Associez-vous à Open Source Connections pour transformer vos capacités de recherche et d'IA et donner à votre équipe les moyens de les faire évoluer en permanence. Nous avons fait nos preuves dans le monde entier et nos clients ont constamment amélioré la qualité de leurs recherches, les capacités de leurs équipes et les performances de leurs entreprises. Contactez-nous dès aujourd'hui pour en savoir plus.

Filtres vs facettes

Avant de commencer, définissons ce que sont les filtres et les facettes. Les filtres sont des attributs prédéfinis utilisés pour restreindre un ensemble de résultats. Sur une place de marché, par exemple, des filtres sont disponibles avant même qu'une recherche ne soit effectuée. L'utilisateur peut sélectionner une catégorie, telle que "Jeux vidéo", avant de rechercher "PS5", ce qui permet d'affiner la recherche à un sous-ensemble plus spécifique plutôt qu'à l'ensemble de la base de données. Cela augmente considérablement les chances d'obtenir des résultats plus pertinents.

Les facettes fonctionnent de la même manière que les filtres, mais elles ne sont disponibles qu'une fois la recherche effectuée. En d'autres termes, la recherche renvoie des résultats et, sur la base de ceux-ci, une nouvelle liste d'options d'affinage est générée. Par exemple, lors de la recherche d'une console PS5, des aspects tels que la capacité de stockage, les frais d'expédition et la couleur peuvent être affichés pour aider les utilisateurs à choisir le produit idéal.

Maintenant que nous avons défini les filtres et les facettes, examinons l'impact de l'approche classique et de l'approche basée sur l'apprentissage automatique sur leur mise en œuvre et leur utilisation. Chaque méthode présente des avantages et des inconvénients qui influencent l'efficacité de la recherche.

Approche classique des filtres et des facettes

Dans cette approche, les filtres et les facettes sont définis manuellement sur la base de règles prédéfinies. Cela signifie que les attributs disponibles pour affiner la recherche sont fixés et planifiés à l'avance, en tenant compte de la structure du catalogue et des besoins de l'utilisateur.

Par exemple, sur une place de marché, les catégories telles que "Électronique" ou "Mode" peuvent avoir des filtres spécifiques tels que la marque, le format et la fourchette de prix. Ces règles sont créées de manière statique, ce qui garantit la cohérence de l'expérience de recherche, mais nécessite des ajustements manuels lorsque de nouveaux produits ou de nouvelles catégories apparaissent.

Bien que cette approche permette de prévoir et de contrôler les filtres et les facettes affichés, elle peut s'avérer limitée lorsque de nouvelles tendances apparaissent et exigent un affinement dynamique.

Pour :

• Prévisibilité et contrôle : Les filtres et les facettes étant définis manuellement, la gestion devient plus facile.

• Faible complexité : Il n'est pas nécessaire de former des modèles.

• Facilité de maintenance : Les règles étant prédéfinies, les ajustements et les corrections peuvent être effectués rapidement.

Cons :

• Réindexation nécessaire pour les nouveaux filtres : Chaque fois qu'un nouvel attribut doit être utilisé comme filtre, l'ensemble du jeu de données doit être réindexé pour s'assurer que les documents contiennent cette information.

• Absence d'adaptation dynamique : Les filtres sont statiques et ne s'adaptent pas automatiquement aux changements de comportement des utilisateurs.

Mise en œuvre des filtres/facettes - Approche classique

Dans Dev Tools, Kibana, nous allons créer une démonstration de filtres/facettes en utilisant l'approche classique.

Tout d'abord, nous définissons la correspondance pour structurer l'index :

Les champs marque et stockage sont définis comme des mots-clés, ce qui permet de les utiliser directement dans les agrégations(facettes). Le champ prix est de type flottant, ce qui permet de créer des fourchettes de prix.

L'étape suivante consiste à indexer les données relatives aux produits :

Retrouvons maintenant des facettes classiques en regroupant les résultats par marque, rangement et gamme de prix. Dans la requête, la taille:0 a été définie. Dans ce scénario, l'objectif est de récupérer uniquement les résultats de l'agrégation sans inclure les documents correspondant à la requête.

La réponse comprendra des comptes pour la marque, le stockage et le prix, ce qui permettra de créer des filtres et des facettes.

Approche basée sur le Machine Learning et l’IA pour les filtres et les facettes

Dans cette approche, les modèles d'apprentissage automatique (ML), y compris les techniques d'intelligence artificielle (IA), analysent les attributs des données pour générer des filtres et des facettes pertinents. Au lieu de s'appuyer sur des règles prédéfinies, la ML/AI exploite les caractéristiques des données indexées. Cela permet la découverte dynamique de nouvelles facettes et de nouveaux filtres.

Pour :

• Mises à jour automatiques : Les nouveaux filtres et facettes sont générés automatiquement, sans qu'il soit nécessaire de procéder à des ajustements manuels.

• Découverte de nouveaux attributs : Il peut identifier des caractéristiques de données précédemment non prises en compte en tant que filtres, enrichissant ainsi l'expérience de recherche.

• Réduction des efforts manuels : L'équipe n'a pas besoin de définir et de mettre à jour en permanence les règles de filtrage, car l'IA apprend à partir des données disponibles.

Cons :

• Complexité de la maintenance : L'utilisation de modèles peut nécessiter une prévalidation pour garantir la cohérence des filtres générés.

• Nécessite une expertise en ML et en IA : La solution exige des professionnels qualifiés pour affiner et surveiller les performances du modèle.

• Risque de filtres non pertinents : Si le modèle n'est pas bien calibré, il peut générer des facettes qui ne sont pas utiles aux utilisateurs.

• Coût : L'utilisation de la ML et de l'IA peut nécessiter des services tiers, ce qui augmente les coûts opérationnels.

Il convient de noter que même avec un modèle bien calibré et une invite bien rédigée, les facettes générées doivent toujours passer par une étape de révision. Cette validation peut être manuelle ou basée sur des règles de modération, garantissant que le contenu est approprié et sûr. Bien qu'il ne s'agisse pas nécessairement d'un inconvénient, il est important de s'assurer de la qualité et de l'adéquation des facettes avant de les mettre à la disposition des utilisateurs.

Mise en œuvre de filtres/façades - Approche IA

Dans cette démonstration, nous utiliserons un modèle d'intelligence artificielle pour analyser automatiquement les caractéristiques des produits et suggérer des attributs pertinents. Avec une invite bien structurée, nous extrayons des informations du catalogue et les transformons en filtres et facettes. Nous présentons ci-dessous chaque étape du processus.

Dans un premier temps, nous utiliserons l'API Inference pour enregistrer un point de terminaison en vue d'une intégration avec un service de ML. Vous trouverez ci-dessous un exemple d'intégration avec le service OpenAI.

Nous définissons maintenant le pipeline permettant d'exécuter l'invite et d'obtenir les nouveaux filtres générés par le modèle.

Lancer une simulation de ce pipeline pour le produit "PlayStation 5", avec la description suivante :

Des jeux époustouflants : Admirez des graphismes époustouflants et découvrez les fonctionnalités de la nouvelle PS5.

Une immersion à couper le souffle : Découvrez une expérience de jeu plus profonde grâce à la prise en charge du retour haptique, des déclencheurs adaptatifs et de la technologie audio 3D.

Un design élancé : Avec la PS5 Digital Edition, les joueurs bénéficient d'une technologie de jeu puissante dans un design élégant et compact.

1 To de stockage : Vos jeux préférés sont prêts à être joués grâce à 1 To de stockage SSD intégré.

Rétrocompatibilité et boost de jeux : La console PS5 peut lire plus de 4 000 jeux PS4. Avec Game Boost, vous pouvez même profiter de taux de rafraîchissement plus rapides et plus fluides dans certains des meilleurs jeux de la console PS4.

Observons la sortie rapide générée par cette simulation.

Un nouveau champ, dynamic_facets, sera ajouté au nouvel index pour stocker les facettes générées par l'IA.

En utilisant l'API Reindex, nous allons réindexer l'index videogames en videogames_1, en appliquant le pipeline generate_filter_ai pendant le processus. Ce pipeline génère automatiquement des facettes dynamiques lors de l'indexation.

Nous allons maintenant lancer une recherche et obtenir les nouveaux filtres :

Résultats :

Pour illustrer la mise en œuvre des facettes, nous présentons ci-dessous une interface simple :

Le code de l'interface utilisateur présenté est ici.

Conclusion

Les deux approches de la création de filtres et de facettes ont leurs avantages et leurs inconvénients. L'approche classique, basée sur des règles manuelles, permet de contrôler et de réduire les coûts, mais elle nécessite des mises à jour constantes et ne s'adapte pas de manière dynamique aux nouveaux produits ou aux nouvelles fonctionnalités.

D'autre part, l'approche basée sur l'IA et l'apprentissage automatique automatise l'extraction des facettes, ce qui rend la recherche plus flexible et permet de découvrir de nouveaux attributs sans intervention manuelle. Toutefois, cette approche peut être plus complexe à mettre en œuvre et à maintenir, et nécessite un étalonnage pour garantir des résultats cohérents.

Le choix entre l'approche classique et l'approche basée sur l'IA dépend des besoins et de la complexité de l'entreprise. Pour les scénarios plus simples, où les attributs des données sont stables et prévisibles, l'approche classique peut être plus efficace et plus facile à maintenir, en évitant les coûts inutiles liés à l'infrastructure et aux modèles d'IA. D'autre part, l'utilisation de la ML/AI pour extraire les facettes peut apporter une valeur ajoutée significative, en améliorant l'expérience de recherche et en rendant le filtrage plus intelligent.

L'important est d'évaluer si l'automatisation justifie l'investissement ou si une solution plus traditionnelle répond déjà efficacement aux besoins de l'entreprise.

Ce blog explore la manière dont les grands modèles de langage (LLM) peuvent être utilisés pour identifier et générer automatiquement des synonymes, ce qui permet de charger ces termes de manière programmatique dans l'API de synonymes d'Elasticsearch.

Quand utiliser des synonymes ?

L'utilisation de synonymes peut être une solution plus rapide et plus rentable que la recherche vectorielle. Sa mise en œuvre est plus simple car elle ne nécessite pas de connaissances approfondies en matière d'encastrements ni de processus complexe d'ingestion de vecteurs.

En outre, la consommation de ressources est plus faible, car la recherche vectorielle nécessite une plus grande capacité de stockage et de mémoire pour l'indexation de l'incorporation et la recherche.

Un autre aspect important est la régionalisation de la recherche. Grâce aux synonymes, il est possible d'adapter les termes à la langue et aux coutumes locales. Ceci est utile dans les situations où les embeddings peuvent ne pas correspondre à des expressions régionales ou à des termes spécifiques à un pays. Par exemple, certains mots ou acronymes peuvent avoir des significations différentes selon la région, mais sont naturellement traités comme des synonymes par les utilisateurs locaux. Au Brésil, cette situation est assez courante. "Abacaxi" et "ananás" sont le même fruit (ananas), mais le second terme est plus couramment utilisé dans certaines régions du nord-est. "De même, le pão francês", bien connu dans le Sud-Est, peut être appelé "pão careca" dans le Nord-Est.

Comment utiliser les LLM pour générer des synonymes ?

Pour obtenir automatiquement des synonymes, on peut utiliser des LLM, qui analysent le contexte d'un terme et suggèrent des variations appropriées. Cette approche permet d'étendre dynamiquement les synonymes, ce qui garantit une recherche plus large et plus précise sans dépendre d'un dictionnaire fixe.

Dans cette démonstration, nous utiliserons un LLM pour générer des synonymes pour des produits de commerce électronique. De nombreuses recherches ne donnent que peu ou pas de résultats en raison de variations dans les termes recherchés. Les synonymes permettent de résoudre ce problème. Par exemple, une recherche sur "smartphone" peut englober différents modèles de téléphones mobiles, ce qui permet aux utilisateurs de trouver les produits qu'ils recherchent.

Produits requis

Avant de commencer, nous devons configurer l'environnement et définir les dépendances nécessaires. Nous utiliserons la solution fournie par Elastic pour exécuter Elasticsearch et Kibana localement dans Docker. Le code sera écrit en Python, v3.9.6, avec les dépendances suivantes :

Création de l'index des produits

Dans un premier temps, nous créerons un index des produits sans support de synonymes. Cela nous permettra de valider les requêtes et de les comparer à un index comprenant des synonymes.

Pour créer l'index, nous chargeons en masse un jeu de données de produits à l'aide de la commande suivante dans Kibana DevTools :

Générer des synonymes avec LLM

Dans cette étape, nous utiliserons un LLM pour générer dynamiquement des synonymes. Pour ce faire, nous intégrerons l'API OpenAI, en définissant un modèle et une invite appropriés. Le LLM recevra la catégorie et le nom du produit, en veillant à ce que les synonymes soient pertinents du point de vue contextuel.

À partir de l'index des produits créé, nous récupérerons tous les articles de la catégorie "Electronics" et enverrons leurs noms au LLM. Le résultat attendu sera quelque chose comme :

Avec les synonymes générés, nous pouvons les enregistrer dans Elasticsearch à l'aide de l'API Synonyms.

Gestion des synonymes avec l'API Synonyms

L'API Synonymes offre un moyen efficace de gérer les ensembles de synonymes directement dans le système. Chaque ensemble de synonymes se compose de règles de synonymie, selon lesquelles un groupe de mots est traité comme équivalent dans les recherches.

Exemple de création d'un jeu de synonymes

Cela crée un ensemble appelé "my-synonyms-set," où "hello" et "hi" sont traités comme des équivalents, ainsi que "bye" et "goodbye."

Mise en œuvre de la création de synonymes pour le catalogue de produits

Vous trouverez ci-dessous la méthode permettant de construire un ensemble de synonymes et de l'insérer dans Elasticsearch. Les règles de synonymie sont générées sur la base du mappage des synonymes suggérés par le LLM. Chaque règle possède un identifiant, correspondant au nom du produit au format "slug", et la liste des synonymes calculée par le LLM.

Vous trouverez ci-dessous la demande de création d'un ensemble de synonymes :

Une fois l'ensemble de synonymes créé dans le cluster, nous pouvons passer à l'étape suivante, qui consiste à créer un nouvel index avec prise en charge des synonymes à l'aide de l'ensemble défini.

Le code Python complet avec les synonymes générés par LLM et la création d'ensembles de synonymes définie par l'API Synonyms est ci-dessous :

Création d'un index avec prise en charge des synonymes

Un nouvel index sera créé dans lequel toutes les données de l'index products seront réindexées. Cet index utilisera le synonyms_filter, qui applique le products-synonyms-set créé précédemment.

Vous trouverez ci-dessous le mappage de l'index configuré pour utiliser les synonymes :

Réindexation de l'index products

Nous allons maintenant utiliser l'API Reindex pour migrer les données de l'index products vers le nouvel index products_02, qui prend en charge les synonymes. Le code suivant a été exécuté dans Kibana DevTools :

Après la migration, l'index products_02 sera alimenté et prêt à valider les recherches à l'aide du jeu de synonymes configuré.

Valider la recherche avec des synonymes

Comparons les résultats de recherche entre les deux index. Nous allons exécuter la même requête sur les deux index et vérifier si les synonymes sont utilisés pour récupérer les résultats.

Recherche dans l'index products (sans synonymes)

Nous utiliserons Kibana pour effectuer des recherches et analyser les résultats. Dans le menu Analytics > Discovery, nous allons créer une vue de données pour visualiser les données des index que nous avons créés.

Dans Discovery, cliquez sur Data View et définissez un nom et un modèle d'index. Pour l'index "products", nous utiliserons le modèle "products". Ensuite, nous répéterons le processus pour créer une nouvelle vue de données pour l'index "products_02", en utilisant le modèle "products_02".

Une fois les vues de données configurées, nous pouvons retourner sur Analytics > Discovery et commencer les validations.

Ici, après avoir sélectionné les produits DataView et effectué une recherche pour le terme "tablet", nous n'obtenons aucun résultat, même si nous savons qu'il existe des produits tels que "Kindle Paperwhite" et "Apple iPad Air".

Recherche dans l'index products_02 (support des synonymes)

Lors de l'exécution de la même requête sur la vue de données "products_synonyms", qui prend en charge les synonymes, les produits ont été récupérés avec succès. Cela prouve que le jeu de synonymes configuré fonctionne correctement, en garantissant que les différentes variations des termes recherchés renvoient les résultats escomptés.

Nous pouvons obtenir le même résultat en exécutant la même requête directement dans Kibana DevTools. Il suffit d'effectuer une recherche dans l'index products_02 à l'aide de l'API de recherche Elasticsearch :

Conclusion

La mise en œuvre de synonymes dans Elasticsearch a permis d'améliorer la précision et la couverture des recherches dans les catalogues de produits. Le principal facteur de différenciation était l'utilisation d'un LLM, qui générait des synonymes automatiquement et en fonction du contexte, éliminant ainsi le besoin de listes prédéfinies. Le modèle a analysé les noms et les catégories de produits, en veillant à ce que les synonymes soient pertinents pour le commerce électronique.

En outre, l'API Synonymes a simplifié la gestion des dictionnaires, en permettant de modifier dynamiquement les ensembles de synonymes. Grâce à cette approche, la recherche est devenue plus souple et plus adaptable aux différents types de requêtes des utilisateurs.

Ce processus peut être continuellement amélioré grâce à de nouvelles données et à des ajustements de modèles, ce qui garantit une expérience de recherche de plus en plus efficace.

Références

Exécuter Elasticsearch localement

https://www.elastic.co/guide/en/elasticsearch/reference/current/run-elasticsearch-locally.html

Synonymes API

https://www.elastic.co/guide/en/elasticsearch/reference/current/synonyms-apis.html

S’appuyant sur les exemples de la première partie, ce blog explore comment utiliser différentes techniques et la puissante boîte à outils de recherche vectorielle d’Elasticsearch afin de préparer les vecteurs d’interaction tardive pour des charges de production à grande échelle.

Les exemples complets de code sont disponibles sur GitHub.

Défis des modèles d’interaction tardive

ColPali crée plus de 1000 vecteurs par page pour les documents dans notre index.

Travailler avec des vecteurs d'interaction tardive présente alors deux défis :

1. Espace disque : l’enregistrement de tous ces vecteurs sur disque entraînera une consommation de stockage considérable, ce qui s’avérera coûteux à grande échelle..

2. Calcul : Lors du classement de nos documents avec la comparaison maxSimDotProduct() , nous devons comparer tous ces vecteurs pour chacun de nos documents avec les N vecteurs de notre requête.

Examinons quelques techniques pour remédier à ces problèmes.

Techniques pour optimiser les modèles d'interactions tardives

Vecteurs de bits

Afin de réduire l'espace disque, nous pouvons compresser les images en vecteurs binaires. Nous pouvons utiliser une simple fonction Python pour transformer nos multi-vecteurs en vecteurs de bits :

Le concept de noyau de la fonction est simple : les valeurs supérieures à 0 deviennent 1, et les valeurs inférieures à 0. Cela aboutit à un tableau de 0 et de 1, que nous transformons ensuite en une chaîne hexadécimale représentant notre vecteur de bits.

Pour le mapping de notre index, nous avons défini le paramètre element_type sur bit:

Après avoir écrit tous nos nouveaux vecteurs de bits dans notre index, nous pouvons classer nos vecteurs de bits en utilisant le code suivant :

En échange d'un peu de précision, cela nous permet d'utiliser la distance de hamming (maxSimInvHamming(...)), qui est capable de tirer parti d'optimisations telles que les masques de bits, SIMD, etc. Pour en savoir plus sur les vecteurs binaires et la distance de hamming, consultez notre blog.

Sinon, nous ne pouvons pas convertir notre vecteur de requête en vecteurs de bits et rechercher à l'aide du vecteur d'interaction tardive en pleine fidélité :

Cela comparera nos vecteurs en utilisant une fonction de similarité asymétrique.

Considérons une distance de Hamming standard entre deux vecteurs de bits.. Supposons que nous ayons un vecteur de document D :

Et un vecteur de requête Q :

La quantification binaire simple transformera les vecteurs D en 10101101 et Q en 11111011. Pour trouver la distance de Hamming, il faut des calculs directs en bits — c’est extrêmement rapide. Dans ce cas, la distance de hamming est 01010110, qui a un nombre de bits de 4. La notation devient donc l'inverse de cette distance de hamming. Rappelez-vous : plus les vecteurs sont similaires, plus la distance de Hamming est petite. L'inverser permet aux vecteurs les plus similaires d'être mieux notés. Plus précisément ici, le score serait 1/4 = 0.25.

Cependant, remarquez comment nous perdons l'ampleur de chaque dimension. Un 1 est un 1. Ainsi, pour Q, la différence entre 0.01 et 0.79 disparaît. Puisque nous quantifions simplement selon >0, nous pouvons faire une petite astuce où le vecteur Q n'est pas quantifié. Cela ne permet pas des calculs bit à bit extrêmement rapides, mais cela maintient le coût de stockage bas car D est toujours quantifié.

En résumé, cette méthode conserve les informations fournies dans Q, ce qui permet d’améliorer la qualité de l’estimation de la distance tout en limitant la consommation de stockage.

L'utilisation de vecteurs de bits nous permet d'économiser de manière significative de l'espace disque et de la charge de calcul au moment de la requête. Mais nous pouvons faire davantage.

Vecteurs moyens

Pour scaler notre recherche sur des centaines de milliers de documents, même les avantages de performance que nous apportent les vecteurs de bits ne seront pas suffisants. Afin de scaler à ces types de charges de travail, nous voudrons exploiter la structure d'index HNSW d'Elasticsearch pour la recherche vectorielle.

ColPali génère environ un millier de vecteurs par document, ce qui est trop pour les ajouter à notre graphe HNSW. Nous devons donc réduire le nombre de vecteurs. Pour cela, nous pouvons créer une représentation unique de la signification du document en prenant la moyenne de tous les vecteurs de documents produits par ColPali lors de l’intégration de notre image.

Pour l’instant, cela n’est pas possible au sein d’Elastic. Nous devrons donc prétraiter les vecteurs avant de les ingérer dans Elasticsearch.

Nous pouvons le faire avec Logstash ou des pipelines d'ingestion, mais ici nous utiliserons une simple fonction Python :

Nous normalisons également le vecteur afin de pouvoir utiliser la similarité par produit scalaire.

Après avoir transformé tous nos vecteurs ColPali en vecteurs moyens, nous pouvons les indexer dans notre champ dense_vector :

Il faut considérer que cela accroîtra l’utilisation globale du disque, car nous sauvegardons des données supplémentaires parallèlement à nos vecteurs d'interaction tardive. En outre, nous utiliserons de la RAM supplémentaire pour contenir le graphe HNSW, ce qui nous permettra de scaler la recherche à des milliards de vecteurs. Pour réduire l’utilisation de la RAM, nous pouvons utiliser notre fonctionnalité BBQ populaire. À notre tour, nous obtenons des résultats de recherche rapides sur d'énormes ensembles de données qui ne seraient autrement pas possibles.

À présent, nous recherchons simplement à l'aide de la requête knn pour trouver nos documents les plus pertinents.

Le meilleur résultat précédent a malheureusement été relégué au troisième rang.

Pour résoudre ce problème, nous pouvons effectuer une récupération en plusieurs étapes. Dans notre première étape, nous utilisons la requête knn pour rechercher les meilleurs candidats pour notre requête parmi des millions de documents. Dans la deuxième étape, nous ne classons que les k premiers (ici : 10) avec la plus grande fidélité des vecteurs d'interaction tardive de ColPali. 

Ici, nous utilisons l'outil rescore retriever introduit en 8.18 pour reclasser nos résultats. Après un nouveau calcul des scores, nous constatons que notre meilleur match se retrouve à nouveau en première position.

Remarque : Dans une application de production, nous pouvons utiliser un k bien supérieur à 10 car la fonction Max Sim est toujours relativement performante.

Regroupement de jetons

Le pooling de tokens réduit la longueur de séquence des plongements multi-vectoriels en regroupant les informations redondantes, comme les zones de fond blanc. Cette technique réduit le nombre de plongements tout en préservant la majeure partie du signal de la page.

Le pooling de jetons fonctionne en regroupant des embeddings de jetons similaires au sein d'un document en clusters à l'aide d'un algorithme de clustering. Ensuite, la moyenne des vecteurs dans chaque groupe est calculée pour créer une représentation unique et agrégée. Ce vecteur agrégé remplace les tokens originaux dans le groupe, réduisant ainsi le nombre total de vecteurs sans perte significative du signal du document.

Le document ColPali propose une valeur initiale de facteur de pool de 3 pour la plupart des ensembles de données, ce qui assure la maintenance de 97,8 % des performances originales tout en réduisant le nombre total de vecteurs de 66,7 %. 

Mais attention : l’ensemble de données « Shift », qui contient des documents très denses et riches en texte avec peu d’espace blanc, voit ses performances se dégrader rapidement à mesure que les facteurs de regroupement augmentent.

Pour créer les vecteurs regroupés, nous pouvons utiliser la bibliothèque colpali_engine :

Nous avons maintenant un vecteur dont les dimensions ont été réduites d’environ 66,7 %. Nous l'indexons comme d'habitude et nous pouvons rechercher dessus avec notre fonction maxSimDotProduct().

Nous pouvons obtenir de bons résultats de recherche au détriment d’une légère précision dans les résultats.

Conseil : avec un pool_factor plus élevé (100-200), vous pouvez également obtenir un juste milieu entre la solution vectorielle moyenne et celle dont nous avons discuté ici. Avec environ 5 à 10 vecteurs par document, il devient possible de les indexer dans un champ imbriqué pour tirer parti de l'index HNSW.

Encodeur Coss vs. encodeur à interaction tardive vs. bi-encodeur

Compte tenu de ces éléments, quelle est la place des modèles d'interaction tardive (comme ColPali ou ColBERT) vis-à-vis des autres méthodes de récupération de données par IA ?

Bien que la fonction de simulation maximale soit moins chère que les encodeurs croisés, elle nécessite néanmoins beaucoup plus de comparaisons et de calculs que la recherche vectorielle avec des bi-encodeurs, où nous comparons simplement deux vecteurs pour chaque paire requête-document.

Pour cette raison, nous recommandons d'utiliser les modèles d'interaction tardive uniquement pour le reclassement des k premiers résultats de recherche. Nous le reflétons également dans le nom du type de champ : rank_vectors.

Mais qu'en est-il de l'encodeur croisé ? Les modèles d'interaction tardive sont-ils meilleurs parce qu'ils sont moins chers à exécuter au moment de la requête ? Comme c'est souvent le cas, la réponse est : cela dépend. Les encodeurs croisés produisent généralement des résultats de meilleure qualité, mais ils nécessitent beaucoup de calcul car les paires de documents de requête doivent effectuer un passage complet à travers le modèle transformateur. Ils bénéficient également du fait qu'ils ne nécessitent aucune indexation de vecteurs et peuvent fonctionner de manière apatride. Résultats obtenus :

• Moins d'espace disque utilisé

• Un système plus simple

• Qualité supérieure des résultats de recherche

• Latence plus élevée, et donc impossible à repositionner aussi profondément

D'autre part, les modèles d'interaction tardive peuvent décharger une partie de ce calcul sur l'index, ce qui rend la requête moins coûteuse. Le prix à payer est la nécessité d’indexer les vecteurs, ce qui complexifie nos pipelines d’ingestion et nécessite davantage d’espace disque pour sauvegarder ces données.

Dans le cas particulier de ColPali, l'analyse des informations contenues dans les images est très coûteuse car elles contiennent beaucoup de données. Dans ce cas, le compromis penche en faveur de l'utilisation d'un modèle d'interaction tardive tel que ColPali, car évaluer ces informations au moment de la requête serait trop gourmand en ressources/lent.

Pour un modèle d’interaction tardif comme ColBERT, qui fonctionne sur des données textuelles comme la plupart des encodeurs croisés (par exemple, elastic-rerank-v1), la décision pourrait plutôt pencher vers l’utilisation du codeur croisé pour bénéficier des économies et de la simplicité du disque.

Nous vous encourageons à peser le pour et le contre en fonction de votre cas d'utilisation et à expérimenter les différents outils qu'Elasticsearch met à votre disposition pour créer les meilleures applications de recherche.

Conclusion

Dans ce blog, nous avons exploré diverses techniques pour optimiser les modèles d'interaction tardive comme ColPali pour la recherche vectorielle à grande échelle dans Elasticsearch. Bien que les modèles d'interaction tardive offrent un bon équilibre entre l'efficacité de la récupération et la qualité du classement, ils présentent également des défis liés au stockage et au calcul.

Pour relever ces défis, nous avons examiné :

• Des vecteurs de bits pour réduire de manière significative l'espace disque tout en tirant parti de calculs de similarité efficaces, tels que la distance de Hamming ou la similarité maximale asymétrique.

• Des vecteurs moyens pour compresser plusieurs intégrations en une seule représentation dense, permettant ainsi une récupération efficace grâce à l'indexation HNSW.

• Le pooling de jetons permet de fusionner intelligemment les embeddings redondants tout en assurant la maintenance de l’intégrité sémantique, réduisant ainsi la surcharge de calcul au moment de la requête.

Elasticsearch offre une boîte à outils puissante pour personnaliser et optimiser les applications de recherche selon vos besoins. Que vous privilégiez la vitesse de récupération, la qualité de classement ou l'efficacité de stockage, ces outils et techniques vous permettent d'équilibrer les performances et la qualité selon vos besoins pour vos applications du monde réel.