Pour ce faire, nous utilisons le logiciel SigLIP-2 de Google pour générer des encastrements vectoriels pour les images et le texte, et les stocker dans la base de données vectorielles Elasticsearch. Au moment de la requête, nous convertissons l'entrée de la recherche, texte ou image, en encastrements et exécutons des recherches vectorielles kNN rapides pour extraire les résultats. Cette configuration permet une recherche efficace de texte à image et d'image à image. Une interface utilisateur Streamlit donne vie à ce projet en nous fournissant un frontend qui nous permet non seulement d'effectuer une recherche textuelle pour trouver et afficher les photos correspondantes de l'album, mais aussi d'identifier le sommet de la montagne à partir de l'image téléchargée et d'afficher d'autres photos de cette montagne dans l'album photo. Nous présentons également les mesures que nous avons prises pour améliorer la précision des recherches, ainsi que des conseils et astuces pratiques. Pour une exploration plus approfondie, nous fournissons un dépôt GitHub et un carnet de notes Colab.

Comment cela a commencé

Ce billet a été inspiré par un enfant de 10 ans qui m'a demandé de lui montrer toutes les photos du mont Ama Dablam prises lors de mon trek au camp de base de l'Everest. En parcourant l'album photo, on m'a également demandé d'identifier plusieurs autres pics montagneux, dont certains que je n'arrivais pas à nommer.

Cela m'a donné l'idée d'un projet amusant de vision par ordinateur. Ce que nous voulions réaliser :

• trouver des images d'un sommet de montagne par son nom

• deviner le nom du sommet d'une montagne à partir d'une image et trouver des sommets similaires dans l'album photo

• faire fonctionner les requêtes conceptuelles(personne, rivière, drapeaux de prière, etc.)

Assembler l'équipe de rêve : SigLIP-2, Elasticsearch & Streamlit

Il est rapidement apparu que pour que cela fonctionne, nous devions transformer à la fois le texte ("Ama Dablam") et les images (photos de mon album) en vecteurs pouvant être comparés de manière significative, c'est-à-dire dans le même espace vectoriel. Une fois cette étape franchie, la recherche se résume à "trouver les voisins les plus proches".

Pour générer des enregistrements d'images, nous utilisons un encodeur multilingue vision-langage, de sorte qu'une photo d'une montagne et une phrase comme "Ama Dablam" se retrouvent dans le même espace vectoriel.

SigLIP-2, récemment publié par Google, s'inscrit parfaitement dans ce cadre. Il peut générer des enchâssements sans formation spécifique à une tâche (un réglage zéro) et fonctionne bien pour notre cas d'utilisation : des photos non étiquetées et des pics avec des noms et des langues différents. Parce qu'il est formé à la correspondance texte ↔ image, une photo de montagne prise lors d'une randonnée et un court texte d'incitation se retrouvent proches en tant qu'ancrages, même lorsque la langue ou l'orthographe de la requête varient.

SigLIP-2 offre un excellent rapport qualité-vitesse, prend en charge plusieurs résolutions d'entrée et fonctionne à la fois avec le CPU et le GPU. SigLIP-2 est conçu pour être plus résistant aux photos prises en extérieur que les modèles précédents tels que le CLIP original. Lors de nos tests, SigLIP-2 a toujours produit des résultats fiables. Il est également très bien supporté, ce qui en fait un choix évident pour ce projet.

Ensuite, nous avons besoin d'une base de données vectorielle pour stocker les encastrements et effectuer des recherches puissantes. Il devrait permettre non seulement la recherche par cosinus kNN sur des images intégrées, mais aussi l'application de filtres de géographie et de texte en une seule requête. Elasticsearch convient bien ici : il gère très bien les vecteurs (HNSW kNN sur les champs dense_vector), prend en charge la recherche hybride qui combine le texte, les vecteurs et les requêtes géographiques, et propose d'emblée le filtrage et le tri. Il est également évolutif horizontalement, ce qui permet de passer facilement d'une poignée de photos à des milliers. Le client officiel Elasticsearch Python simplifie la plomberie et s'intègre parfaitement au projet. Enfin, nous avons besoin d'un frontal léger où nous pouvons saisir des requêtes de recherche et afficher les résultats. Pour une démonstration rapide, basée sur Python, Streamlit est une solution idéale. Il fournit les primitives dont nous avons besoin - le téléchargement de fichiers, une grille d'images réactive et des menus déroulants pour le tri et la géolocalisation. Il est facile de le cloner et de l'exécuter localement, et il fonctionne également dans un cahier Colab.

Implémentation

Conception et stratégie d'indexation Elasticsearch

Nous utiliserons deux indices pour ce projet : peaks_catalog et photos.

Index du catalogue des pics

Cet index constitue un catalogue compact des principaux sommets visibles pendant le trek du camp de base de l'Everest. Chaque document de cet index correspond à un sommet de montagne, comme le mont Everest. Pour chaque document relatif à un pic montagneux, nous stockons les noms/alias, les coordonnées facultatives de latitude et de longitude, ainsi qu'un vecteur prototype unique construit en mélangeant les messages-guides SigLIP-2 (+ images de référence facultatives).

Mappage de l'index :

Champ d'application

Type

Exemple

Objectif/Notes

Vecteur/Indexation

id

mot-clé

ama-dablam

Slug/id stable

-

noms

texte + sous-champ mot-clé

["Ama Dablam","Amadablam"]

Alias / noms multilingues ; names.raw pour les filtres exacts

-

latlon

geo_point

{"lat":27.8617,"lon":86.8614}

Coordonnées GPS du pic sous la forme d'une combinaison latitude/longitude (facultatif)

-

elev_m

entier

6812

Élévation (facultatif)

-

texte_embed

dense_vector

768

Prototype mixte (invites et éventuellement 1 à 3 images de référence) pour ce pic

index:true, similarité :"cosine", index_options :{type:"hnsw", m:16, ef_construction:128}

Cet index est principalement utilisé pour des recherches d'image à image, telles que l'identification de sommets de montagne à partir d'images. Nous utilisons également cet index pour améliorer les résultats de recherche texte-image.

En résumé, le site peaks_catalog transforme la question "Quelle est cette montagne ?" en un problème ciblé de plus proche voisin, séparant efficacement la compréhension conceptuelle des complexités des données d'image.

Stratégie d'indexation pour l'index peaks_catalog : Nous commençons par créer une liste des sommets les plus importants visibles lors de la randonnée EBC. Pour chaque pic, nous stockons sa position géographique, son nom, ses synonymes et son altitude dans un fichier yaml. L'étape suivante consiste à générer l'intégration pour chaque pic et à la stocker dans le champ text_embed. Afin de générer des encastrements robustes, nous utilisons la technique suivante :

• Créer un prototype de texte en utilisant :

  • noms des sommets

  • l'ensemble des invites (utilisation de plusieurs invites différentes pour tenter de répondre à la même question), par exemple :

    • "photo naturelle du sommet de la montagne {name} dans l'Himalaya, Népal".

    • "{name} sommet emblématique de la région du Khumbu, paysage alpin"

    • "{name} sommet montagneux, neige, ligne de crête rocheuse"

  • anti-concept optionnel (indiquant à SigLIP-2 ce qu'il ne faut pas faire) : soustraire un petit vecteur pour "peinture, illustration, affiche, carte, logo" afin de privilégier les photos réelles.

• Créer éventuellement un prototype d'image si des images de référence du pic sont fournies.

Nous fusionnons ensuite les prototypes de texte et d'image pour générer l'intégration finale. Enfin, le document est indexé avec tous les champs obligatoires :

Exemple de document provenant de l'index peaks_catalog:

Index des photos

Cet index primaire contient des informations détaillées sur toutes les photos de l'album. Chaque document représente une seule photo, contenant les informations suivantes :

• Chemin d'accès relatif à la photo dans l'album photo. Cette option permet de visualiser l'image correspondante ou de charger l'image dans l'interface de recherche.

• Informations sur le GPS et l'heure de la photo.

• Vecteur dense pour le codage d'images généré par SigLIP-2.

• predicted_peaks qui nous permet de filtrer par nom de pic. Cartographie de l'index

Champ d'application

Type

Exemple

Objectif/Notes

Vecteur / Indexation

chemin

mot-clé

data/images/IMG_1234.HEIC

Comment l'interface utilisateur ouvre la vignette/l'image complète

-

clip_image

dense_vector

768

Intégration d'images SigLIP-2

index:true, similarité :"cosine", index_options :{type:"hnsw", m:16, ef_construction:128}

pics_prédits

mot-clé

["ama-dablam","pumori"]

Les suppositions Top-K au moment de l'indexation (filtre / facette UX bon marché)

-

GPS

geo_point

{"lat":27.96,"lon":86.83}

permet d'utiliser des filtres géographiques

-

heure de la prise de vue

date

2023-10-18T09:41:00Z

temps de capture : tri/filtre

-

Stratégie d'indexation pour l'index des photos : Pour chaque photo de l'album, nous procédons comme suit : Extraire les informations sur les images shot_time et gps à partir des métadonnées de l'image.

• Intégration d'images SigLIP-2: passage de l'image dans le modèle et normalisation L2 du vecteur. Stocker l'intégration dans le champ clip_image.

• Prédire les pics et les stocker dans le champ predicted_peaks. Pour ce faire, nous prenons d'abord le vecteur image de la photo généré à l'étape précédente, puis nous effectuons une recherche rapide par kNN sur le champ text_embed de l'index peaks_catalog. Nous conservons les 3-4 premiers sommets et ignorons les autres.

• Nous calculons le champ _id en effectuant un hachage du nom de l'image et du chemin d'accès. Cela permet de s'assurer qu'il n'y a pas de doublons après plusieurs exécutions.

Une fois que nous avons déterminé tous les champs de la photo, les documents photo sont indexés par lots à l'aide de l'indexation en bloc :

Exemple de document de l'index des photos :

En résumé, l'index des photos est le magasin rapide, filtrable et prêt pour le kNN de toutes les photos de l'album. Sa cartographie est volontairement minimale - juste assez de structure pour permettre une recherche rapide, un affichage propre et une répartition des résultats dans l'espace et dans le temps. Cet index sert aux deux types de recherche. Le script Python permettant de créer les deux indices est disponible ici.

La visualisation des cartes Kibana ci-dessous affiche les documents de l'album photo sous forme de points verts et les pics montagneux de l'index peaks_catalog sous forme de triangles rouges, les points verts correspondant bien au sentier de randonnée du camp de base de l'Everest.

Cas d'utilisation de la recherche

Recherche par nom (texte-image) : Cette fonction permet aux utilisateurs de localiser des photos de sommets de montagne (et même des concepts abstraits comme les "drapeaux de prière") à l'aide de requêtes textuelles. Pour ce faire, l'entrée texte est convertie en un vecteur texte à l'aide de SigLIP-2. Pour la génération de vecteurs de texte robustes, nous utilisons la même stratégie que pour la création d'enchâssements de texte dans l'index peaks_catalog: combinaison de l' entrée texte avec un petit ensemble d'invites, soustraction d'un vecteur anti-concept mineur et application de la normalisation L2 pour produire le vecteur d'interrogation final. Une requête kNN est ensuite exécutée sur le champ photos.clip_image pour récupérer les pics les plus proches, sur la base de la similarité cosinusoïdale pour trouver les images les plus proches. Il est possible de rendre les résultats de la recherche plus pertinents en appliquant des filtres géographiques et de date, et/ou un filtre de terme photos.predicted_peaks dans le cadre de la requête (voir les exemples de requêtes ci-dessous). Cela permet d'exclure les sommets qui ressemblent à d'autres et qui ne sont pas visibles lors de la randonnée.

Requête Elasticsearch avec filtre géographique :

Recherche par image (image à image) : Cette fonction permet d'identifier une montagne sur une photo et de trouver d'autres images de cette même montagne dans l'album photo. Lorsqu'une image est téléchargée, elle est traitée par l'encodeur d'images SigLIP-2 pour générer un vecteur d'image. Une recherche kNN est ensuite effectuée sur le champ peaks_catalog.text_embed pour identifier les noms de pics qui correspondent le mieux. Ensuite, un vecteur de texte est généré à partir des noms de pics correspondants, et une autre recherche kNN est effectuée sur l'index des photos pour localiser les images correspondantes.

Requête Elasticsearch :

Étape 1 : Trouver les noms de pics correspondants

Étape 2 : Effectuer une recherche dans l'index photos pour trouver les images correspondantes (même requête que dans le cas d'utilisation de la recherche texte-image) :

Streamlit UI

Pour réunir le tout, nous avons créé une interface utilisateur Streamlit simple qui nous permet de réaliser les deux cas d'utilisation de la recherche. La barre de gauche affiche une liste déroulante de pics (agrégés à partir de photos.predicted_peaks) avec des cases à cocher et un filtre mini-carte/géo. En haut, il y a un champ de recherche par nom et un bouton d'identification à partir du téléchargement d'une photo. Le volet central présente une grille de vignettes réactive indiquant les scores kNN, les badges de pic prédit et les heures de capture. Chaque image comporte un bouton " Voir l'image" qui permet d'obtenir un aperçu en pleine résolution.

Recherchez en téléchargeant une image : Nous prédisons le pic et trouvons les pics correspondants dans l'album photo.

Recherche par texte: Trouver les sommets correspondants dans l'album à partir d'un texte.

Conclusion

Tout a commencé par la possibilité de voir les photos del'Ama Dablam. s'est transformé en un petit système de recherche multimodale fonctionnel. Nous avons pris des photos brutes de trek, les avons transformées en encastrements SigLIP-2 et avons utilisé Elasticsearch pour effectuer un kNN rapide sur les vecteurs, ainsi que des filtres géo/temporels simples pour faire remonter à la surface les bonnes images en fonction de leur signification. En cours de route, nous avons séparé les préoccupations en deux indices : un minuscule peaks_catalog de prototypes mélangés (pour l'identification) et un index évolutif photos de vecteurs d'images et d'EXIF (pour la recherche). Il est pratique, reproductible et facile à étendre.

Si vous souhaitez l'accorder, vous pouvez jouer avec quelques paramètres :

• Paramètres de temps de recherche : k (nombre de voisins à récupérer) et num_candidates (étendue de la recherche avant la notation finale). Ces paramètres sont abordés dans le blog ici.

• Paramètres de temps d'indexation : m (connectivité du graphique) et ef_construction (précision du temps de construction par rapport à la mémoire). Pour les requêtes, expérimentez avec ef_search également - une valeur plus élevée signifie généralement un meilleur rappel avec un certain compromis en termes de latence. Consultez ce blog pour plus de détails sur ces paramètres.

A l'avenir, des modèles natifs/rerankers pour la recherche multimodale et multilingue seront bientôt intégrés à l'écosystème Elastic, ce qui devrait rendre la recherche d'images/de textes et le classement hybride encore plus performants. ir.elastic.co+1

Si vous souhaitez essayer vous-même :

• GitHub repo : https://github.com/navneet83/multimodal-mountain-peak-search

• Colab quickstart : https://github.com/navneet83/multimodal-mountain-peak-search/blob/main/notebooks/multimodal_mountain_peak_search.ipynb

Notre voyage s'achève donc et il est temps de prendre l'avion du retour. J'espère que cela vous a été utile et si vous le cassez (ou l'améliorez), j'aimerais savoir ce que vous avez changé.

Et si nous pouvions utiliser les interactions réelles des utilisateurs avec notre application de recherche pour créer ces données d'entraînement ? L'utilisation des données UBI nous permet justement de le faire. Créer un système automatique capable de capturer et d'utiliser nos recherches, nos clics et autres interactions pour générer une liste de jugement. Ce processus peut être mis à l'échelle et répété beaucoup plus facilement qu'une interaction manuelle et tendrait à donner de meilleurs résultats. Dans ce blog, nous allons explorer comment nous pouvons interroger les données UBI stockées dans Elasticsearch pour calculer des signaux significatifs afin de générer un ensemble de données d'entraînement pour un modèle LTR.

L'expérience complète est disponible ici.

Pourquoi les données UBI peuvent-elles être utiles pour entraîner votre modèle LTR ?

Les données UBI offrent plusieurs avantages par rapport à une annotation manuelle :

• Le volume : Étant donné que les données UBI proviennent d'interactions réelles, nous pouvons collecter beaucoup plus de données que nous ne pouvons en générer manuellement. Cela suppose que nous ayons suffisamment de trafic pour générer ces données, bien entendu.

• L'intention de l'utilisateur réel : Traditionnellement, une liste de jugement manuel provient d'une évaluation experte des données disponibles. D'autre part, les données UBI reflètent le comportement réel des utilisateurs. Cela signifie que nous pouvons générer de meilleures données de formation qui amélioreront la précision de notre système de recherche, car elles sont basées sur la façon dont les utilisateurs interagissent réellement avec votre contenu et y trouvent de la valeur, plutôt que sur des hypothèses théoriques sur ce qui devrait être pertinent.

• Mises à jour permanentes : Les listes de jugement doivent être actualisées au fil du temps. Si nous les créons à partir des données de l'UBI, nous pouvons disposer de données actualisées qui se traduisent par des listes de jugement mises à jour.

• Rentabilité : Sans les frais généraux liés à la création manuelle d'une liste de jugement, le processus peut être répété efficacement un nombre illimité de fois.

• Distribution naturelle des requêtes: Les données UBI représentent les requêtes réelles des utilisateurs, ce qui peut entraîner des changements plus profonds. Par exemple, nos utilisateurs utilisent-ils le langage naturel pour effectuer des recherches dans notre système ? Si c'est le cas, nous pourrions vouloir mettre en œuvre une recherche sémantique ou une approche de recherche hybride.

Elle s'accompagne toutefois de quelques mises en garde :

• Amplification des biais : Un contenu populaire est plus susceptible de recevoir des clics, simplement parce qu'il est plus exposé. Cela pourrait donc avoir pour effet d'amplifier les articles les plus populaires et d'étouffer les meilleures options.

• Couverture incomplète : Le nouveau contenu n'a pas d'interactions, il peut donc être difficile pour lui de figurer en bonne place dans les résultats. Les requêtes rares peuvent également ne pas comporter suffisamment de points de données pour créer des données de formation significatives.

• Variations saisonnières : Si vous vous attendez à ce que le comportement de l'utilisateur change radicalement au fil du temps, les données historiques risquent de ne pas vous donner beaucoup d'indications sur ce qui constitue un bon résultat.

• Ambiguïté de la tâche : Un clic ne garantit pas toujours que l'utilisateur a trouvé ce qu'il cherchait.

Calcul des notes

Grades pour la formation LTR

Pour former les modèles LTR, nous devons fournir une représentation numérique de la pertinence d'un document par rapport à une requête. Dans notre application, ce nombre est un score continu allant de 0,0 à 5,0+, les scores les plus élevés indiquant une plus grande pertinence.

Pour illustrer le fonctionnement de ce système de classement, prenons l'exemple suivant, créé manuellement :

Requête

Contenu du document

Grade

Explication

"meilleure recette de pizza"

"Recette de pâte à pizza italienne authentique avec photos étape par étape"

4.0

Très pertinent, exactement ce que l'utilisateur recherche

"meilleure recette de pizza"

"Histoire de la pizza en Italie"

1.0

Un peu dans le sujet, il s'agit de pizza mais ce n'est pas une recette.

"meilleure recette de pizza"

"Recette de pizza en 15 minutes pour les débutants"

3.0

C'est un bon résultat, mais il ne s'agit peut-être pas de la "meilleure" recette.

"meilleure recette de pizza"

"Guide d'entretien des voitures"

0.0

Pas du tout pertinent, sans aucun rapport avec la requête

Comme nous pouvons le voir ici, la note est une représentation numérique de la pertinence d'un document par rapport à notre exemple de requête "meilleure recette de pizza". Grâce à ces scores, notre modèle LTR peut apprendre quels documents devraient être présentés plus haut dans les résultats.

La manière de calculer les notes est au cœur de notre ensemble de données de formation. Il existe plusieurs approches pour y parvenir, chacune ayant ses propres forces et faiblesses. Par exemple, nous pourrions attribuer un score binaire de 1 pour pertinent, 0 pour non pertinent, ou nous pourrions simplement compter le nombre de clics dans un document résultant pour chaque requête.

Dans cet article de blog, nous utiliserons une approche différente, en prenant en compte le comportement de l'utilisateur en tant qu'entrée et en calculant un nombre de notes en tant que sortie. Nous corrigerons également le biais qui pourrait résulter du fait que les résultats les plus élevés ont tendance à être davantage cliqués, quelle que soit la pertinence du document.

Calcul des notes - algorithme COEC

L'algorithme COEC(Clicks over Expected Clicks) est une méthodologie permettant de calculer les notes de jugement à partir des clics des utilisateurs. Comme nous l'avons indiqué précédemment, les utilisateurs ont tendance à cliquer sur les résultats les mieux positionnés, même si le document n'est pas le plus pertinent par rapport à la requête ; c'est ce que l'on appelle le biais de position. L'idée centrale de l'utilisation de l'algorithme COEC est que tous les clics n'ont pas la même importance ; un clic sur un document en position 10 indique que ce document est beaucoup plus pertinent pour la requête qu'un clic sur un document en position 1. Pour citer le document de recherche sur l'algorithme COEC (lien ci-dessus) :

"Il est bien connu que le taux de clics (CTR) des résultats de recherche ou des publicités diminue de manière significative en fonction de la position des résultats."

Pour en savoir plus sur les préjugés de position , cliquez ici.

Pour résoudre ce problème avec l'algorithme COEC, nous suivons les étapes suivantes :

1. Établir des valeurs de référence pour les positions : Nous calculons le taux de clics (CTR) pour chaque position de recherche de 1 à 10. Cela signifie que nous déterminons le pourcentage d'utilisateurs qui cliquent généralement sur la position 1, la position 2, etc. Cette étape permet de prendre en compte les préférences naturelles des utilisateurs en matière de position. Nous calculons le CTR en utilisant :

Où ?

p = Position. De 1 à 10 Cp = Nombre total de clics (sur n'importe quel document) à la position p sur l'ensemble des requêtes Ip = Nombre total d'impressions : Nombre de fois qu'un document est apparu à la position p sur l'ensemble des requêtes.

Dans ce cas, nous nous attendons à ce que les positions les plus élevées donnent lieu à davantage de clics.

2. Calculer les clics attendus (EC):

Cette mesure détermine le nombre de clics qu'un document "aurait dû" recevoir sur la base des positions dans lesquelles il est apparu et du CTR pour ces positions. Nous calculons la CE à l'aide de :

Où ?

Qd = Toutes les requêtes dans lesquelles le document d est apparu pos(d,q)= Position du document d dans les résultats de la requête q

3. Compter les clics réels : Nous comptons le nombre total de clics qu'un document a reçus pour toutes les requêtes où il est apparu, ci-après dénommé A(d).

4. Calculer le score COEC : Il s'agit du rapport entre les clics réels (A(d)) et les clics attendus (EC(d)) :

Cette métrique normalise le biais de position de la manière suivante :

• Un score de 1,0 signifie que le document s'est comporté exactement comme prévu compte tenu des positions dans lesquelles il est apparu.

• Un score supérieur à 1,0 signifie que le document a obtenu de meilleurs résultats que prévu en examinant ses positions. Ce document est donc plus pertinent pour la requête.

• Un score inférieur à 1,0 signifie que le document a obtenu de moins bons résultats que prévu, compte tenu de ses positions. Ce document est donc moins pertinent pour la requête.

Le résultat final est une note qui reflète ce que les utilisateurs recherchent, en tenant compte des attentes basées sur la position, extraites des interactions réelles avec notre système de recherche.

Mise en œuvre technique

Nous allons créer un script pour créer une liste de jugements afin d'entraîner un modèle LTR.

L'entrée de ce script est constituée des données UBI indexées dans Elastic (requêtes et événements).

Le résultat est une liste de jugements dans un fichier CSV généré à partir de ces documents UBI en utilisant l'algorithme COEC. Cette liste de jugements peut être utilisée avec Eland pour extraire les caractéristiques pertinentes et former un modèle LTR.

Démarrage rapide

Pour générer une liste de jugement à partir de l'échantillon de données présenté dans ce blog, vous pouvez suivre les étapes suivantes :

1. Clonez le référentiel :

2. Installer les bibliothèques nécessaires

Pour ce script, nous avons besoin des bibliothèques suivantes :

• pandas: pour sauvegarder la liste des jugements

• elasticsearch: Pour obtenir les données UBI à partir de notre déploiement Elastic

Nous avons également besoin de Python 3.11

3. Mettez à jour les variables d'environnement pour votre déploiement Elastic dans un fichier .env

• ES_HOST

• API_KEY

Pour ajouter les variables d'environnement, utilisez :

4. Créez les index ubi_queries et ubi_events, et téléchargez les échantillons de données. Exécutez le fichier setup.py :

5. Exécutez le script Python :

Si vous suivez ces étapes, vous devriez voir apparaître un nouveau fichier appelé judgment_list.csv qui ressemble à ceci :

Ce script calcule les notes en appliquant l'algorithme COEC évoqué précédemment à l'aide de la fonction calculate_relevance_grade() présentée ci-dessous.

Architecture des données

Requêtes Ubi

Notre index des requêtes UBI contient des informations sur les requêtes exécutées dans notre système de recherche. Il s'agit d'un document type :

Ici, nous pouvons voir les données de l'utilisateur (client_id), les résultats de la requête (query_response_object_ids) et la requête elle-même (timestamp, user_query).

Événements de clics Ubi

Notre index ubi_events contient des données à chaque fois qu'un utilisateur a cliqué sur un document dans les résultats. Il s'agit d'un document type :

Script de génération de listes d'arrêts

Aperçu général du script

Ce script automatise la génération de la liste de jugement en utilisant les données UBI des requêtes et des événements de clics stockés dans Elasticsearch. Il exécute ces tâches :

• Récupère et traite les données UBI dans Elasticsearch.

• Corréler les événements UBI avec ses requêtes.

• Calcule le CTR pour chaque position.

• Calcule le nombre de clics attendus (EC) pour chaque document.

• Compte les clics réels pour chaque document.

• Calcule le score COEC pour chaque paire requête-document.

• Génère une liste de jugements et l'écrit dans un fichier CSV.

Passons en revue chaque fonction :

connect_to_elasticsearch()

Cette fonction renvoie un objet client Elasticsearch en utilisant l'hôte et la clé api.

fetch_ubi_data()

Cette fonction est la couche d'extraction des données ; elle se connecte à Elasticsearch pour récupérer les requêtes UBI à l'aide d'une requête match_all et filtre les événements UBI pour obtenir uniquement les événements "CLICK_THROUGH".

process_ubi_data()

Cette fonction gère la génération de la liste des jugements. Il commence à traiter les données UBI en associant les événements UBI et les requêtes. Il appelle ensuite la fonction calculate_relevance_grade() pour chaque paire document-requête afin d'obtenir les entrées de la liste de jugement. Enfin, il renvoie la liste résultante sous la forme d'un cadre de données pandas.

calculer_la_relevance_de_la_grade()

Il s'agit de la fonction qui met en œuvre l'algorithme COEC. Il calcule le CTR pour chaque position, puis compare les clics réels pour une paire document-requête, et enfin calcule le score COEC réel pour chacun d'entre eux.

generate_judgment_statistics()

Il génère des statistiques utiles à partir de la liste de jugement, telles que le nombre total de requêtes, le nombre total de documents uniques ou la distribution des notes. Il s'agit d'une information purement informative qui ne modifie pas la liste de jugement qui en résulte.

Résultats et impact

Si vous suivez les instructions de la section Démarrage rapide, vous devriez obtenir un fichier CSV contenant une liste de jugements de 320 entrées (vous pouvez voir un exemple de sortie dans le répertoire). Avec ces champs :

• qid : identifiant unique de la requête

• docid : identifiant unique du document résultant

• note : la note calculée pour la paire requête-document

• requête : La requête de l'utilisateur

Examinons les résultats de la requête "recettes italiennes" :

qid

docid

grade

Requête

q1-italien-recettes

recette_pasta_basics

0.0

Recettes italiennes

q1-italien-recettes

recette_pizza_margherita

3.333333

Recettes italiennes

q1-italien-recettes

guide_recette_risotto_guide

10.0

Recettes italiennes

q1-italien-recettes

recette_french_croissant

0.0

Recettes italiennes

q1-italien-recettes

recette_paella_espagnole

0.0

Recettes italiennes

q1-italien-recettes

recette_greek_moussaka

1.875

Recettes italiennes

Nous pouvons voir dans les résultats que pour la requête "recettes italiennes" :

• La recette de risotto est sans aucun doute le meilleur résultat pour la requête, recevant 10 fois plus de clics que prévu

• La pizza Margherita est également un excellent résultat.

• La mousaka grecque (surprenante) est également un bon résultat et se comporte mieux que ne le laisse supposer sa position dans les résultats. Cela signifie que quelques utilisateurs recherchant des recettes italiennes ont été intéressés par cette recette à la place. Ces utilisateurs sont peut-être intéressés par les plats méditerranéens en général. En fin de compte, cela nous indique qu'il pourrait s'agir d'un bon résultat à présenter dans le cadre des deux autres "meilleurs" matches dont nous avons parlé plus haut.

Conclusion

L'utilisation des données UBI nous permet d'automatiser l'apprentissage des modèles LTR, en créant des listes de jugement de haute qualité à partir de nos propres utilisateurs. En utilisant l'algorithme COEC pour générer les notes, nous tenons compte des biais inhérents tout en reflétant ce qu'un utilisateur considère comme un meilleur résultat. La méthode décrite ici peut être appliquée à des cas d'utilisation réels afin d'offrir une meilleure expérience de recherche qui évolue en fonction des tendances d'utilisation réelles.

Elasticsearch 8.12 et 8.13 ont apporté une prise en charge de base des types géospatiaux à ES|QL. Cette fonction a été considérablement améliorée par l'ajout de capacités de recherche géospatiale dans la version 8.14. Plus important encore, ce support a été conçu pour se conformer étroitement à la norme Simple Feature Access de l'Open Geospatial Consortium (OGC) utilisée par d'autres bases de données spatiales comme PostGIS, ce qui le rend beaucoup plus facile à utiliser pour les experts SIG familiarisés avec ces normes.

Dans ce blog, nous vous montrerons comment utiliser ES|QL pour effectuer des recherches géospatiales, et comment il se compare aux équivalents SQL et Query DSL. Nous vous montrerons également comment utiliser ES|QL pour effectuer des jointures spatiales et comment visualiser les résultats dans Kibana Maps. Notez que toutes les fonctionnalités décrites ici figurent dans l'aperçu technique de "" , et nous serions ravis de recevoir vos commentaires sur la manière dont nous pouvons les améliorer.

Recherche de données géospatiales

Commençons par un exemple de requête :

Cette opération permet de rechercher tous les polygones de limite de ville qui recoupent un polygone de recherche rectangulaire autour de l'aéroport international de Sanya Phoenix (SYX).

Dans un échantillon de données d'aéroports, de villes et de limites de villes, cette recherche trouve le polygone d'intersection et renvoie les champs souhaités à partir du document correspondant :

abbrev

aéroport

région

ville

ville_location

SYX

Sanya Phoenix Int'l

天涯区

Sanya

POINT(109.5036 18.2533)

C'était facile ! Comparez maintenant cela au DSL Elasticsearch Query classique pour la même requête :

Les deux requêtes sont raisonnablement claires dans leur intention, mais la requête ES|QL ressemble beaucoup à SQL. La même requête dans PostGIS se présente comme suit :

Reprenez l'exemple de ES|QL. C'est un peu la même chose, non ?

Nous avons constaté que les utilisateurs existants de l'API Elasticsearch trouvent ES|QL beaucoup plus facile à utiliser. Nous pensons que les utilisateurs de SQL, en particulier ceux de Spatial SQL, trouveront que ES|QL est très proche de ce qu'ils ont l'habitude de voir.

Pourquoi pas SQL ?

Qu'en est-il d'Elasticsearch SQL ? Il existe depuis un certain temps et possède des fonctions géospatiales. Cependant, Elasticsearch SQL a été écrit comme une enveloppe au-dessus de l'API de requête originale, ce qui signifie que seules les requêtes qui pouvaient être transposées vers l'API originale étaient prises en charge. ES|QL n'a pas cette limitation. Le fait qu'il s'agisse d'une pile entièrement nouvelle permet de nombreuses optimisations qui n'étaient pas possibles avec SQL. Nos benchmarks montrent qu'ES|QL est très souvent plus rapide que l'API Query, en particulier avec les agrégations !

Différences avec SQL

Il ressort clairement de l'exemple précédent que ES|QL est quelque peu similaire à SQL, mais qu'il existe des différences importantes. Par exemple, ES|QL est un langage d'interrogation par pipeline, qui commence par une commande source telle que FROM et enchaîne toutes les commandes suivantes à l'aide du caractère de pipeline |. Il est ainsi très facile de comprendre comment chaque commande reçoit un tableau de données et effectue une action sur ce tableau, comme le filtrage avec WHERE, l'ajout de colonnes avec EVAL, ou l'exécution d'agrégations avec STATS. Plutôt que de commencer par SELECT pour définir les colonnes de sortie finales, il peut y avoir une ou plusieurs commandes KEEP, la dernière spécifiant les résultats de sortie finaux. Cette structure simplifie le raisonnement sur la requête.

Si l'on se concentre sur la commande WHERE dans l'exemple ci-dessus, on constate qu'elle ressemble beaucoup à l'exemple PostGIS :

ES|QL

PostGIS

Outre la différence entre les caractères de citation des chaînes, la plus grande différence réside dans la façon dont nous transformons la chaîne de caractères en un type spatial. Dans PostGIS, nous utilisons le suffixe ::geometry, tandis que dans ES|QL, nous utilisons le suffixe ::geo_shape. En effet, ES|QL fonctionne au sein d'Elasticsearch, et l'opérateur de conversion de type :: peut être utilisé pour convertir une chaîne en l'un des types ES|QL pris en charge, dans ce cas, un geo_shape. En outre, les types geo_shape et geo_point dans Elasticsearch impliquent le système de coordonnées spatiales connu sous le nom de WGS84, plus communément désigné par le numéro SRID 4326. Dans PostGIS, cela doit être explicite, d'où l'utilisation du préfixe SRID=4326; pour la chaîne WKT. Si ce préfixe est supprimé, le SRID sera fixé à 0, ce qui est plus proche des types Elasticsearch cartesian_point et cartesian_shape, qui ne sont pas liés à un système de coordonnées spécifique.

ES|QL et PostGIS fournissent également une syntaxe de fonction de conversion de type :

ES|QL

PostGIS

Fonctions de l'OGC

Elasticsearch 8.14 introduit les quatre fonctions de recherche spatiale de l'OGC suivantes :

ES|QL

PostGIS

Description

ST_INTERSECTS

ST_Intersects

Retourne true si deux géométries se croisent, et false dans le cas contraire.

ST_DISJOINT

ST_Disjoint

Retourne true si deux géométries ne se croisent pas, et false dans le cas contraire. L'inverse de ST_INTERSECTS.

ST_CONTAINS

ST_Contains

Retourne true si une géométrie en contient une autre, et false sinon.

ST_WITHIN

ST_Within

Retourne true si une géométrie est à l'intérieur d'une autre, et false dans le cas contraire. L'inverse de ST_CONTAINS.

Ces fonctions se comportent de manière similaire à leurs homologues PostGIS et sont utilisées de la même manière. Par exemple, ST_INTERSECTS renvoie un message vrai si deux géométries se croisent et un message faux dans le cas contraire. Si vous suivez les liens de documentation dans le tableau ci-dessus, vous remarquerez que tous les exemples ES|QL se trouvent dans une clause WHERE après une clause FROM, alors que tous les exemples PostGIS utilisent des géométries littérales. En fait, les deux plates-formes permettent d'utiliser les fonctions dans n'importe quelle partie de la requête où elles sont utiles.

Le premier exemple dans la documentation PostGIS pour ST_INTERSECTS est le suivant :

L'équivalent en ES|QL serait le suivant :

Notez que nous n'avons pas spécifié le SRID dans l'exemple de PostGIS. En effet, dans PostGIS, lorsque l'on utilise le type geometry, tous les calculs sont effectués sur un système de coordonnées planaires et, par conséquent, si les deux géométries ont le même SRID, le SRID n'a pas d'importance. Dans Elasticsearch, c'est également le cas pour la plupart des fonctions, mais il existe des exceptions où geo_shape et geo_point utilisent des calculs sphériques, comme nous le verrons dans le prochain blog sur la recherche de distance spatiale.

ES|QL polyvalence

Nous avons donc vu ci-dessus des exemples d'utilisation de fonctions spatiales dans les clauses WHERE et dans les commandes ROW. Où cela aurait-il un sens ? Un endroit très utile est la commande EVAL. Cette commande permet d'évaluer une expression et de renvoyer le résultat. Par exemple, déterminons si les centroïdes de tous les aéroports regroupés par nom de pays se trouvent à l'intérieur d'une frontière délimitant le pays :

Les résultats sont attendus, les centroïdes des aéroports britanniques sont situés à l'intérieur de la frontière britannique, mais pas à l'intérieur de la frontière islandaise, et vice versa :

centroïde

Compte

in_uk

en_pays

within_uk

à l'intérieur de la patrie

POINT (-21.946634463965893 64.13187285885215)

1

faux

vrai

faux

vrai

POINT (-2.597342072712148 54.33551226578214)

17

vrai

faux

vrai

faux

POINT (0.04453958108176276 23.74658354606057)

873

faux

faux

faux

faux

En fait, ces fonctions peuvent être utilisées dans n'importe quelle partie de la requête où leur signature a un sens. Ils prennent tous deux arguments, qui sont soit un objet spatial littéral, soit un champ d'un type spatial, et renvoient tous une valeur booléenne. Il est important de noter que le système de référence des coordonnées (CRS) des géométries doit correspondre, sinon une erreur sera renvoyée. Cela signifie que vous ne pouvez pas mélanger les types geo_shape et cartesian_shape dans le même appel de fonction. Vous pouvez toutefois mélanger les types geo_point et geo_shape, car le type geo_point est un cas particulier du type geo_shape, et tous deux partagent le même système de référence de coordonnées. La documentation relative à chacune des fonctions définies ci-dessus énumère les combinaisons de types prises en charge.

En outre, chaque argument peut être un littéral spatial ou un champ, dans l'un ou l'autre ordre. Vous pouvez même spécifier deux champs, deux littéraux, un champ et un littéral, ou un littéral et un champ. La seule condition est que les types soient compatibles. Par exemple, cette requête compare deux champs dans le même index :

La requête demande essentiellement si la ville est située à l'intérieur des limites de la ville, ce qui devrait généralement être le cas, mais il y a toujours des exceptions :

cardinalité

Compte

dans_la_ville

peu

29

faux

nombreux

740

vrai

Une question bien plus intéressante serait de savoir si l'emplacement de l'aéroport se trouve à l'intérieur des limites de la ville desservie par l'aéroport. Cependant, l'emplacement de l'aéroport se trouve dans un index différent de celui qui contient les limites de la ville. Il faut donc trouver une méthode pour interroger efficacement les données de ces deux index distincts et les mettre en corrélation.

Jointures spatiales

ES|QL ne prend pas JOIN en charge les commandes, mais vous pouvez réaliser un cas spécial de jointure à l'aide de la ENRICH commande, qui se comporte de la même manière qu'une "jointure gauche" en SQL. Cette commande s'apparente à une "jointure gauche" en SQL, vous permettant d'enrichir les résultats d'un index avec des données d'un autre index sur la base d'une relation spatiale entre les deux ensembles de données.

Par exemple, enrichissons les résultats d'un tableau d'aéroports avec des informations supplémentaires sur la ville qu'ils desservent en trouvant la limite de la ville qui contient l'emplacement de l'aéroport, puis effectuons quelques statistiques sur les résultats :

Cette méthode permet d'obtenir les 5 régions qui comptent le plus d'aéroports, ainsi que le centroïde de tous les aéroports qui ont des régions correspondantes et la longueur de la représentation WKT des limites des villes à l'intérieur de ces régions :

centroïde

Compte

min_wkt

max_wkt

région

POINT (-32.56093470960719 32.598117914802714)

90

207

207

nul

POINT (-73.94515332765877 40.70366442203522)

9

438

438

Ville de New York

POINT (-83.10398317873478 42.300230911932886)

9

473

473

Détroit

POINT (-156.3020245861262 20.176383580081165)

5

307

803

Hawaï

POINT (-73.88902732171118 45.57078813901171)

4

837

837

Montréal

Alors, que s'est-il vraiment passé ? Où s'est produite la supposée JOIN? L'essentiel de la question réside dans la commande ENRICH:

Cette commande demande à Elasticsearch d'enrichir les résultats extraits de l'index airports et d'effectuer une jointure intersects entre le champ city_location de l'index original et le champ city_boundary de l'index airport_city_boundaries, que nous avons utilisé dans quelques exemples plus tôt. Mais certaines de ces informations ne sont pas clairement visibles dans cette requête. Ce que nous voyons, c'est le nom d'une politique d'enrichissement city_boundaries, et l'information manquante est encapsulée dans cette définition de politique.

Ici, nous pouvons voir qu'il effectuera une requête geo_match (intersects est la valeur par défaut), que le champ à comparer est city_boundary et que les champs enrich_fields sont les champs que nous voulons ajouter au document d'origine. L'un de ces champs, le region, a été utilisé comme clé de regroupement pour la commande STATS, ce que nous n'aurions pas pu faire sans cette capacité de "jointure à gauche". Pour plus d'informations sur les politiques d'enrichissement, voir la documentation d'enrichissement. En lisant ces documents, vous remarquerez qu'ils décrivent l'utilisation des index d'enrichissement pour enrichir les données au moment de l'indexation, en configurant les pipelines d'ingestion. Cela n'est pas nécessaire pour ES|QL, car la commande ENRICH fonctionne au moment de la requête. Il suffit de préparer l'index d'enrichissement avec les données et la politique d'enrichissement nécessaires, puis d'utiliser la commande ENRICH dans vos requêtes ES|QL.

Vous pouvez également remarquer que la région la plus fréquemment trouvée est null. Qu'est-ce que cela peut signifier ? Rappelez-vous que j'ai comparé cette commande à une "jointure gauche" en SQL, ce qui signifie que si aucune limite de ville correspondante n'est trouvée pour un aéroport, l'aéroport est toujours renvoyé, mais avec les valeurs null pour les champs de l'index airport_city_boundaries. Il s'avère que 89 aéroports n'ont pas trouvé de correspondance avec city_boundary, et un aéroport avec une correspondance où le champ region était null. Cela a conduit à un décompte de 90 aéroports sans region dans les résultats. Un autre détail intéressant est la nécessité de la commande MV_EXPAND. Cela est nécessaire car la commande ENRICH peut renvoyer plusieurs résultats pour chaque ligne d'entrée, et MV_EXPAND permet de séparer ces résultats en plusieurs lignes, une pour chaque résultat. Cela explique également pourquoi "Hawaii" affiche des résultats différents de min_wkt et max_wkt: il y avait plusieurs régions portant le même nom mais ayant des limites différentes.

Cartes Kibana

Kibana a ajouté la prise en charge de Spatial ES|QL dans l'application Maps. Cela signifie que vous pouvez désormais utiliser ES|QL pour rechercher des données géospatiales dans Elasticsearch et visualiser les résultats sur une carte.

Il existe une nouvelle option de couche dans le menu d'ajout de couches, appelée "ES|QL". Comme toutes les fonctions géospatiales décrites jusqu'à présent, il s'agit d'un aperçu technique "" . Cette option permet d'ajouter une couche à la carte en fonction des résultats d'une requête ES|QL. Par exemple, vous pouvez ajouter une couche à la carte qui montre tous les aéroports du monde.

Vous pouvez également ajouter une couche qui montre les polygones de l'index airport_city_boundaries ou, mieux encore, la requête complexe ENRICH ci-dessus qui génère des statistiques sur le nombre d'aéroports dans chaque région.

Et ensuite ?

Vous avez peut-être remarqué que dans deux des exemples ci-dessus, nous avons inséré une autre fonction spatiale ST_CENTROID_AGG. Il s'agit d'une fonction d'agrégation utilisée dans la commande STATS et de la première des nombreuses fonctions d'analyse spatiale que nous prévoyons d'ajouter à ES|QL. Nous en parlerons sur notre blog lorsque nous en aurons plus à montrer !

Avant cela, nous souhaitons vous parler d'une fonctionnalité particulièrement intéressante sur laquelle nous avons travaillé : la possibilité d'effectuer des recherches spatiales par distance, l'une des fonctionnalités de recherche spatiale les plus utilisées d'Elasticsearch. Pouvez-vous imaginer à quoi pourrait ressembler la syntaxe des recherches à distance ? Peut-être similaire à une fonction de l'OGC ? Restez à l'écoute du prochain blog de cette série pour le découvrir !

Alerte au spoiler : Elasticsearch 8.15 vient d'être publié, et la recherche de distance spatiale avec ES|QL est incluse !

Comprendre le benchmark BEIR dans l'évaluation de la pertinence des recherches

Pour améliorer un système, il faut pouvoir en mesurer l'efficacité. Dans le contexte de la recherche, BEIR (ou, de manière équivalente, la section Récupération du classement MTEB) est considéré comme le "Saint Graal" de la communauté de recherche d'informations, et cela n'a rien d'étonnant. C'est un indice de référence très bien structuré avec des ensembles de données variés couvrant différentes tâches. Plus précisément, les domaines suivants sont abordés :

• Récupération d'arguments (ArguAna, Touche2020)

• QA en domaine ouvert (HotpotQA, Natural Questions, FiQA)

• Récupération par passes (MSMARCO)

• Récupération des questions en double (Quora, CQADupstack)

• Vérification des faits (FEVER, Climate-FEVER, Scifact)

• Récupération d’informations biomédicales (TREC-COVID, NFCorpus, BioASQ)

• Récupération d'entités (DBPedia)

• Prédiction de citation (SCIDOCS)

Cet benchmark fournit une statistique unique, nDCG@10, qui indique dans quelle mesure un système fait correspondre les documents les plus pertinents pour chaque exemple de tâche dans les premiers résultats qu'il renvoie. Pour un système de recherche avec lequel un humain interagit, la pertinence des résultats en haut de liste est essentielle. Cependant, l'évaluation d'une recherche comporte de nombreuses nuances qu'une simple statistique récapitulative ne permet pas de saisir.

Structure d'un ensemble de données BEIR

Chaque benchmark comporte trois artefacts :

• le corpus ou les documents à récupérer

• les requêtes

• les jugements de pertinence pour les requêtes (alias qrels).

Les jugements de pertinence sont fournis sous forme de score égal ou supérieur à zéro. Les scores non nuls indiquent que le document est partiellement pertinent par rapport à la requête.

Ensemble de données

Taille du corpus

Nb. de requêtes dans l'ensemble de test

#qrels étiquetés positivement

#qrels égal à zéro

#Doublons dans le corpus

Arguana

8 674

1 406

1 406

0

96

Climate-FEVER

5 416 593

1 535

4 681

0

0

DBPedia

4 635 922

400

15 286

28 229

0

FEVER

5 416 568

6 666

7 937

0

0

FiQA-2018

57 638

648

1 706

0

0

HotpotQA

5 233 329

7 405

14 810

0

0

Questions naturelles

2 681 468

3 452

4 021

0

16 781

NFCorpus

3 633

323

12 334

0

80

Quora

522 931

10 000

15 675

0

1 092

SCIDOCS

25 657

1 000

4 928

25 000

2

SciFact

5 183

300

339

0

0

Touche2020

382 545

49

932

1 982

5 357

TREC-COVID

171 332

50

24 763

41 663

0

MSMARCO

8 841 823

6 980

7 437

0

324

CQADupstack (somme)

457 199

13 145

23 703

0

0

Tableau 1 : Statistiques de l'ensemble de données. Les chiffres ont été calculés sur la partie test des ensembles de données (dev pour MSMARCO).

Le tableau 1 présente quelques statistiques issues des ensembles de données qui composent le benchmark BEIR, telles que le nombre de documents dans le corpus, le nombre de requêtes dans l'ensemble de données de test et le nombre de paires positives/négatives (requête, document) dans le fichier qrels. Un simple coup d'œil aux données nous permet de déduire immédiatement ce qui suit :

• La plupart des ensembles de données ne contiennent aucune relation négative dans le fichier qrels, c'est-à-dire des scores nuls, ce qui indiquerait explicitement que les documents ne sont pas pertinents pour la requête donnée.

• Le nombre moyen de relations entre documents par requête (#qrels / #queries) varie de 1,0 dans le cas de ArguAna à 493,5 (TREC-COVID), mais avec une valeur de <5 dans la majorité des cas.

• Certains ensembles de données comportent des documents en double dans le corpus, ce qui, dans certains cas, peut conduire à une évaluation incorrecte, c'est-à-dire lorsqu'un document est considéré comme pertinent par rapport à une requête, alors que son doublon ne l'est pas. Par exemple, dans ArguAna, nous avons identifié 96 cas de paires de documents en double, avec un seul document par paire marqué comme pertinent pour une requête. En agrandissant la liste initiale des qrels pour inclure également les doublons, nous avons observé une augmentation relative d'environ 1 % du score nDCG@10 en moyenne.

Exemple de paires dupliquées dans ArguAna. Dans le fichier qrels, seul la première semble pertinente (en tant que contre-argument) par rapport à la requête ("test-economy-epiasghbf-pro02a")

Lors de la comparaison des modèles sur le classement MTEB, il est tentant de se concentrer sur la qualité moyenne de la récupération. Il s'agit d'un bon indicateur de la qualité globale du modèle, mais cela ne prédit pas nécessairement ses performances dans votre cas d'utilisation. Comme les résultats sont présentés par ensemble de données, il est important de comprendre le degré de pertinence des différents ensembles de données par rapport à votre tâche de recherche et de réévaluer les modèles en ne retenant que les plus pertinents. Pour une analyse plus approfondie, vous pouvez également vérifier le chevauchement thématique entre les différents corpus. Répartir les mesures de qualité par thème permet une évaluation beaucoup plus fine de leurs forces et faiblesses particulières.

Une remarque importante ici est que lorsqu'un document n'est pas marqué dans le fichier qrels, considéré par défaut comme non pertinent pour la requête. Nous approfondissons un peu plus ce domaine et recueillons des éléments de preuve pour éclairer davantage la question suivante : "À quelle fréquence un évaluateur est-il confronté à des paires (requête, document) pour lesquelles il n'existe aucune information de référence ?" Ceci est important, car lorsque seul un balisage superficiel est disponible (et que tous les documents pertinents ne sont donc pas étiquetés comme tels), un système de recherche d'informations peut être considéré comme pire qu'un autre simplement parce qu'il "choisit" de faire apparaître différents documents pertinents (mais non marqués). Il s'agit d'un piège courant dans la création d'ensembles de données d'évaluation de haute qualité, en particulier pour les grands ensembles de données. Pour être réalisable, l'étiquetage manuel se concentre généralement sur les meilleurs résultats renvoyés par le système actuel, ce qui peut entraîner l'omission de documents pertinents situés dans ses angles morts. Il est donc généralement préférable de consacrer davantage de ressources à un balisage plus complet d'un nombre restreint de requêtes plutôt qu'à un balisage superficiel et général.

Utilisation du benchmark BEIR pour l'évaluation de la pertinence des recherches

Pour initier notre analyse, nous mettons en œuvre le scénario suivant (voir le notebook) :

1. Tout d'abord, nous chargeons le corpus de chaque ensemble de données dans un index Elasticsearch.

2. Pour chaque requête dans l'ensemble de test, nous récupérons les 100 meilleurs documents avec BM25.

3. Nous reclassons les documents récupérés à l'aide de divers modèles de reclassement SOTA.

4. Enfin, nous rapportons le "taux de jugement" pour les 10 meilleurs documents provenant des étapes 2 (après récupération) et 3 (après reclassement). En d'autres termes, nous calculons le pourcentage moyen des 10 meilleurs documents qui ont un score dans le fichier qrels.

Voici la liste des modèles de reclassement que nous avons utilisés :

• Cohere rerank-english-v2.0 et rerank-english-v3.0

• BGE-base

• mxbai-rerank-xsmall-v1

• MiniLM-L-6-v2

Récupération

Reranking

Ensemble de données

BM25 (%)

Cohere Rerank v2 (%)

Cohere Rerank v3 (%)

BGE-base (%)

mxbai-rerank-xsmall-v1 (%)

MiniLM-L-6-v2 (%)

Arguana

7,54

4,87

7,87

4,52

4,53

6,84

Climate-FEVER

5,75

6,24

8,15

9,36

7,79

7,58

DBPedia

61,18

60,78

64,15

63,9

63,5

67,62

FEVER

8,89

9,97

10,08

10,19

9,88

9,88

FiQa-2018

7,02

11,02

10,77

8,43

9,1

9,44

HotpotQA

12,59

14,5

14,76

15.1

14,02

14,42

Questions naturelles

5,94

8.84

8,71

8,37

8,14

8,34

NFCorpus

31,67

32,9

33,91

30,63

32,77

32,45

Quora

12,2

10,46

13,04

11,26

12,58

12,78

SCIDOCS

8,62

9,41

9,71

8,04

8,79

8,52

SciFact

9,07

9,57

9,77

9,3

9,1

9,17

Touche2020

38,78

30,41

32,24

33,06

37,96

33,67

TREC-COVID

92,4

98,4

98,2

93,8

99,6

97,4

MSMARCO

3,97

6,00

6,03

6,07

5,47

6,11

CQADupstack (moy.)

5,47

6,32

6,87

5,89

6,22

6,16

Tableau 2 : Taux de jugement par paires (ensemble de données, reranker) calculé sur les 10 premiers documents récupérés/reclassés

D'après le tableau 2, à l'exception de TREC-COVID (>90 % de couverture), DBPedia (~65 %), Touche2020 et nfcorpus (~35%), nous constatons que la majorité des ensembles de données ont un taux d'étiquetage compris entre 5 % et un peu plus de 10 % après l'extraction ou le reclassement. Cela ne veut pas dire que tous ces documents banalisés sont pertinents, mais il se peut qu'un sous-ensemble d'entre eux, en particulier ceux placés en tête de liste, soit positif.

L'avènement des modèles de langage réglés pour les instructions générales nous offre un nouvel outil puissant capable d'automatiser potentiellement l'évaluation de la pertinence. Ces méthodes sont généralement beaucoup trop gourmandes en ressources de calcul pour être utilisées en ligne dans le cadre de la recherche, mais nous nous intéressons ici à l'évaluation hors ligne. Nous utilisons ces méthodes dans ce qui suit pour examiner les indices montrant que certains ensembles de données BEIR souffrent d'un balisage superficiel.

Afin d'approfondir cette hypothèse, nous avons décidé de nous concentrer sur MSMARCO et de sélectionner un sous-ensemble de 100 requêtes, ainsi que les 5 documents les mieux reclassés (avec Cohere v2) qui ne sont actuellement pas marqués comme pertinents. Nous avons suivi deux voies d'évaluation différentes : premièrement, nous avons utilisé un prompt soigneusement ajusté (nous y reviendrons dans un article ultérieur) pour préparer le modèle Phi-3-mini-4k récemment publié afin de prédire la pertinence (ou non) d'un document par rapport à la requête. En parallèle, ces cas ont également été étiquetés manuellement afin d'évaluer également le taux d'accord entre la sortie du LLM et le jugement humain. Dans l'ensemble, nous pouvons tirer les deux conclusions suivantes :

• Le taux de concordance entre les réponses LLM et les jugements humains était proche de 80 %, ce qui semble suffisant comme point de départ dans cette direction.

• Dans 57,6 % des cas (sur la base du jugement humain), les documents renvoyés se sont avérés réellement pertinents par rapport à la requête. Autrement dit : pour 100 requêtes, 107 documents ont été jugés pertinents, mais au moins 0,576 × 5 × 100 = 288 documents supplémentaires sont réellement pertinents !

Voici quelques exemples issus de l'ensemble de données MSMARCO/dev qui contiennent la requête, le document positif annoté (de qrels) et un faux négatif dû à un balisage incomplet :

1{^>er <^}exemple :

2{^>e <^}exemple :

L'évaluation manuelle de requêtes spécifiques comme celle-ci est une technique généralement utile pour comprendre la qualité de la recherche qui complète les mesures quantitatives comme le nDCG@10. Si vous disposez d'un ensemble représentatif de requêtes que vous exécutez systématiquement lorsque vous modifiez la recherche, cela vous fournit des informations qualitatives importantes sur l'évolution des performances, informations invisibles dans les statistiques. Par exemple, cela vous donne beaucoup plus d'informations sur les faux résultats renvoyés par la recherche : cela peut vous aider à repérer les erreurs évidentes dans les résultats obtenus, les classes d'erreurs connexes, telles que la mauvaise interprétation de la terminologie spécifique au domaine, etc.

Notre résultat est en accord avec les recherches pertinentes concernant l'évaluation de MSMARCO. Par exemple, Arabzadeh et al. suivent une procédure similaire où ils emploient des travailleurs du crowdsourcing pour effectuer des jugements de préférences : entre autres, ils montrent que, dans de nombreux cas, les documents retournés par les modules de reclassement sont préférés à ceux du fichier MSMARCO qrels. Un autre élément de preuve est fourni par les auteurs de l'outil de reclassement RocketQA, qui indiquent que plus de 70 % des documents reclassés ont été jugés pertinents après inspection manuelle.

Mise à jour – 9 septembre : Après une réévaluation minutieuse de l'ensemble de données, nous avons identifié 15 autres cas de documents pertinents, portant leur nombre total de 273 à 288

Principaux points à retenir et prochaines étapes

• La quête d'une meilleure référence est sans fin, car elle est cruciale pour le benchmarking et la comparaison de modèles. Les LLM peuvent aider dans certains domaines d'évaluation s'ils sont utilisés avec prudence et réglés avec des instructions appropriées.

• Plus généralement, étant donné que les critères de référence ne seront jamais parfaits, il peut être préférable de passer d'une simple comparaison de scores à des techniques plus robustes permettant de saisir les différences statistiquement significatives. Les travaux de Arabzadeh et al. fournit un bon exemple de cette méthode où, d'après leurs résultats, ils construisent des intervalles de confiance à 95 % indiquant des différences significatives (ou non) entre les différentes exécutions. Dans le notebook joint, nous proposons une implémentation des intervalles de confiance en utilisant le bootstrapping.

• Du point de vue de l’utilisateur final, il est utile de réfléchir à l'alignement des tâches lors de la lecture des résultats de benchmark. Par exemple, pour un ingénieur en IA qui conçoit un pipeline RAG et sait que le cas d'utilisation le plus courant consiste à assembler de multiples informations provenant de différentes sources, il serait plus pertinent d'évaluer les performances de son modèle de recherche sur des ensembles de données QA multisauts comme HotpotQA plutôt que sur la moyenne globale du benchmark BEIR.

Dans l'article de blog suivant, nous approfondirons l'utilisation de Phi-3 en tant que juge LLM et le processus de réglage pour prédire la pertinence.

Il existe une distinction entre l'inspiration et la paraphrase. Il est possible de lire un contenu, de s'en inspirer, puis d'explorer l'idée avec ses propres mots, même si l'on arrive à une conclusion similaire.

Si le plagiat est un sujet de discussion depuis longtemps, l'accélération de la production et de la publication de contenus lui a donné toute sa pertinence et constitue un défi permanent.

Ce défi ne se limite pas aux livres, à la recherche universitaire ou aux documents judiciaires, pour lesquels des contrôles de plagiat sont fréquemment effectués. Elle peut également s'étendre aux journaux et même aux médias sociaux.

Avec l'abondance d'informations et l'accès facile à la publication, comment le plagiat peut-il être contrôlé de manière efficace et à grande échelle ?

Les universités, les organismes publics et les entreprises utilisent divers outils, mais si une simple recherche lexicale permet de détecter efficacement le plagiat direct, la principale difficulté réside dans l'identification du contenu paraphrasé.

Détection du plagiat avec l'IA générative

L'IA générative pose un nouveau défi. Le contenu généré par l'IA est-il considéré comme du plagiat lorsqu'il est copié ?

Les conditions d'utilisation de l'OpenAI, par exemple, précisent que l'OpenAI ne revendiquera pas de droits d'auteur sur le contenu généré par l'API pour les utilisateurs. Dans ce cas, les personnes utilisant leur IA générative peuvent utiliser le contenu généré comme elles le souhaitent, sans le citer.

Toutefois, l'acceptation de l'utilisation de l'IA générative pour améliorer l'efficacité reste un sujet de discussion.

Afin de contribuer à la détection du plagiat, OpenAI a développé un modèle de détection, mais a reconnu par la suite que sa précision n'était pas suffisamment élevée.

"Nous pensons que cette précision n'est pas suffisante pour une détection autonome et qu'elle doit être associée à des approches basées sur les métadonnées, au jugement humain et à l'éducation du public pour être plus efficace."

Le défi persiste ; cependant, grâce à la disponibilité d'outils supplémentaires, il existe désormais davantage d'options pour détecter le plagiat, même dans les cas de paraphrases et de contenu d'IA.

Détecter le plagiat avec Elasticsearch

C'est pourquoi, dans ce blog, nous explorons un autre cas d'utilisation des modèles de traitement du langage naturel (NLP) et de la recherche vectorielle, la détection du plagiat, au-delà de la recherche de métadonnées.

Nous le démontrons à l'aide d'exemples en Python, où nous utilisons un ensemble de données de SentenceTransformers contenant des articles liés au TAL. Nous vérifions que les résumés ne sont pas plagiés en effectuant une "similarité textuelle sémantique" en tenant compte de l'intégration des "résumés" générée à l'aide d'un modèle d'intégration de texte importé au préalable dans Elasticsearch. En outre, pour identifier le contenu généré par l'IA - le plagiat par l'IA, un modèle NLP développé par OpenAI a également été importé dans Elasticsearch.

L'image suivante illustre le flux de données :

Au cours du processus d 'ingestion avec un processeur d'inférence, le paragraphe "abstrait" est mis en correspondance avec un vecteur à 768 dimensions, le "vecteur_abstrait.valeur_prédite".

Cartographie :

La similarité entre les représentations vectorielles est mesurée à l'aide d'une métrique de similarité vectorielle, définie à l'aide du paramètre"similarité".

Cosinus est la métrique de similarité par défaut, calculée comme '(1 + cosinus(query, vector)) / 2'. À moins que vous ne deviez préserver les vecteurs originaux et que vous ne puissiez pas les normaliser à l'avance, la façon la plus efficace d'effectuer une similarité en cosinus est de normaliser tous les vecteurs à une longueur unitaire. Cela permet d'éviter d'effectuer des calculs supplémentaires sur la longueur du vecteur pendant la recherche, et d'utiliser plutôt 'dot_product'.

Dans ce même pipeline, un autre processeur d'inférence contenant le modèle de classification de texte détecte si le contenu est "vrai", probablement écrit par des humains, ou "faux", probablement écrit par une IA, en ajoutant la valeur "openai-detector.predicted_value" à chaque document.

Pipeline d'ingestion :

Au moment de la requête, le même modèle d'intégration de texte est également utilisé pour générer la représentation vectorielle de la requête "texte_modèle" dans un objet "query_vector_builder".

Une recherche par k-voisins les plus proches (kNN) permet de trouver les k vecteurs les plus proches du vecteur de la requête, mesurés par la métrique de similarité.

Le _score de chaque document est dérivé de la similarité, ce qui garantit qu'un score plus élevé correspond à un meilleur classement. Cela signifie que le document est plus similaire d'un point de vue sémantique. Par conséquent, nous imprimons trois possibilités : si le score > est de 0,9, nous considérons qu'il s'agit d'une "forte similarité" ; si < est de 0,7, il s'agit d'une "faible similarité" ; sinon, il s'agit d'une "similarité modérée". Vous avez la possibilité de définir différentes valeurs seuils pour déterminer quel niveau de _score est considéré comme du plagiat ou non, en fonction de votre cas d'utilisation.

En outre, une classification du texte est effectuée afin de vérifier si la requête contient des éléments générés par l'IA.

Requête :

Sortie :

Dans cet exemple, après avoir utilisé l'une des valeurs "abstract" de notre ensemble de données comme requête textuelle "model_text", le plagiat a été identifié. Le score de similarité est de 1,0, ce qui indique un niveau élevé de similarité - un plagiat direct. La requête et le document vectorisés n'ont pas été reconnus comme des contenus générés par l'IA, ce qui était attendu.

Requête :

Sortie :

En mettant à jour la requête "texte_modèle" avec un texte généré par l'IA qui transmet le même message tout en minimisant la répétition de mots similaires, la similarité détectée était toujours élevée, mais le score était de 0,9302529 au lieu de 1,0 - plagiat de paraphrase. On s'attendait également à ce que cette requête, générée par l'IA, soit détectée.

Enfin, si l'on considère la requête textuelle "model_text" comme un texte sur Elasticsearch, qui n'est pas un résumé de l'un de ces documents, la similarité détectée était de 0,68991005, ce qui indique une faible similarité selon les valeurs seuils considérées.

Requête :

Sortie :

Bien que le plagiat ait été correctement identifié dans la requête de texte générée par l'IA, ainsi que dans les cas de paraphrase et de contenu directement copié, la navigation dans le paysage de la détection du plagiat implique la reconnaissance de divers aspects.

Dans le contexte de la détection de contenu généré par l'IA, nous avons exploré un modèle qui apporte une contribution précieuse. Toutefois, il est essentiel de reconnaître les limites inhérentes à la détection autonome, ce qui nécessite l'incorporation d'autres méthodes pour améliorer la précision.

La variabilité introduite par le choix des modèles d'intégration de texte est un autre élément à prendre en considération. Différents modèles, formés avec des ensembles de données distincts, aboutissent à des niveaux de similarité variables, ce qui souligne l'importance des enchâssements de texte générés.

Enfin, dans ces exemples, nous avons utilisé le résumé du document. Cependant, la détection du plagiat porte souvent sur des documents volumineux, ce qui rend essentielle la prise en compte de la longueur du texte. Il est fréquent que le texte dépasse la limite de jetons d'un modèle, ce qui nécessite une segmentation en morceaux avant de construire des embeddings. Une approche pratique consiste à utiliser des structures imbriquées avec dense_vector.

Conclusion

Dans ce blog, nous avons abordé les défis liés à la détection du plagiat, en particulier dans les contenus paraphrasés et générés par l'IA, et comment la similarité textuelle sémantique et la classification des textes peuvent être utilisées à cette fin.

En combinant ces méthodes, nous avons fourni un exemple de détection du plagiat dans lequel nous avons réussi à identifier le contenu généré par l'IA, le plagiat direct et le plagiat paraphrastique.

L'objectif premier était d'établir un système de filtrage qui simplifie la détection, mais l'évaluation humaine reste essentielle pour la validation.

Si vous souhaitez en savoir plus sur la similarité textuelle sémantique et le NLP, nous vous encourageons à consulter les liens suivants :

• Qu'est-ce que la recherche sémantique ?

• Qu'est-ce que le traitement du langage naturel (NLP) ?

• Recherche lexicale et sémantique avec Elasticsearch

• Chunking Large Documents via Ingest pipelines plus nested vectors equals easy passage search (en anglais)

Compte tenu de cet objectif, dans cet article de blog, nous allons explorer différentes approches de la recherche d'informations à l'aide d'Elasticsearch, en nous concentrant plus particulièrement sur la recherche de texte : recherche lexicale et sémantique.

Produits requis

Pour ce faire, nous fournirons des exemples Python qui démontrent divers scénarios de recherche sur un ensemble de données généré pour simuler des informations sur des produits de commerce électronique.

Cet ensemble de données contient plus de 2 500 produits, chacun accompagné d'une description. Ces produits sont classés en 76 catégories de produits distinctes, chaque catégorie contenant un nombre variable de produits, comme indiqué ci-dessous :

Visualisation du treemap - les 22 premières valeurs de category.keyword (catégories de produits)

Pour l'installation, vous aurez besoin de

• Python 3.6 ou version ultérieure

• Le client Elastic Python

• Déploiement d'Elastic 8.8 ou d'une version ultérieure, avec un nœud d'apprentissage automatique de 8 Go de mémoire

• Le modèle Elastic Learned Sparse EncodeR qui est préchargé dans Elastic a été installé et démarré sur votre déploiement.

Nous utiliserons Elastic Cloud, une version d'essai gratuite est disponible.

Outre les requêtes de recherche présentées dans cet article de blog, un carnet Python vous guidera dans les processus suivants :

• Établir une connexion à notre déploiement Elastic en utilisant le client Python

• Charger un modèle d'intégration de texte dans le cluster Elasticsearch

• Créer un index avec des correspondances pour indexer les vecteurs de caractéristiques et les vecteurs denses.

• Créer un pipeline d'ingestion avec des processeurs d'inférence pour l'intégration et l'expansion du texte

Recherche lexicale - recherche éparse

La manière classique dont les documents sont classés en fonction de leur pertinence par Elasticsearch sur la base d'une requête textuelle utilise l'implémentation Lucene du modèle BM25, un modèle clairsemé pour la recherche lexicale. Cette méthode suit l'approche traditionnelle de la recherche de texte, en recherchant des correspondances de termes exacts.

Pour rendre cette recherche possible, Elasticsearch convertit les données des champs de texte en un format de recherche en effectuant une analyse de texte.

L'analyse de texte est effectuée par un analyseur, un ensemble de règles régissant le processus d'extraction des mots-clés pertinents pour la recherche. Un analyseur doit avoir exactement un tokenizer. Le tokenizer reçoit un flux de caractères et le décompose en tokens individuels (généralement des mots individuels), comme dans l'exemple ci-dessous :

Balisage des chaînes de caractères pour la recherche lexicale

Sortie

Dans cet exemple, nous utilisons l'analyseur par défaut, l'analyseur standard, qui fonctionne bien pour la plupart des cas d'utilisation car il fournit une tokenisation basée sur la grammaire anglaise. La tokenisation permet de faire correspondre des termes individuels, mais chaque token est toujours mis en correspondance de manière littérale.

Si vous souhaitez personnaliser votre expérience de recherche, vous pouvez choisir un autre analyseur intégré. Par exemple, en mettant à jour le code pour utiliser l'analyseur de mots v ides, il décomposera le texte en jetons à partir de tout caractère autre qu'une lettre, avec la possibilité de supprimer les mots vides.

Sortie

Lorsque les analyseurs intégrés ne répondent pas à vos besoins, vous pouvez créer un analyseur personnalisé, qui utilise la combinaison appropriée de zéro ou plusieurs filtres de caractères, un tokenizer et zéro ou plusieurs filtres de jetons.

Dans l'exemple ci-dessus, qui combine un tokenizer et des filtres de jetons, le texte sera mis en minuscules par le filtre de minuscules avant d'être traité par le filtre de jetons de synonymes.

Correspondance lexicale

BM25 mesurera la pertinence des documents par rapport à une requête de recherche donnée sur la base de la fréquence des termes et de leur importance.

Le code ci-dessous effectue une recherche de correspondance, recherchant jusqu'à deux documents en tenant compte des valeurs du champ "description" de l'index "ecommerce-search" et de la requête de recherche. "Meubles confortables pour un grand balcon".

L'affinement des critères pour qu'un document soit considéré comme correspondant à cette requête peut améliorer la précision. Cependant, les résultats plus spécifiques sont assortis d'une plus faible tolérance aux variations.

Sortie

En analysant le résultat, le résultat le plus pertinent est le produit "Barbie Dreamhouse", dans la catégorie "Toys", et sa description est très pertinente car elle inclut les termes "furniture", "large" et "balcony", c'est le seul produit avec 3 termes dans la description qui correspondent à la requête de recherche, le produit est également le seul avec le terme "balcony" dans la description.

Le deuxième produit le plus pertinent est un "Comfortable Rocking Chair" catégorisé en "Indoor Furniture" et sa description inclut les termes "comfortable" et "furniture". Seuls 3 produits dans l'ensemble de données correspondent à au moins 2 termes de cette requête de recherche, et ce produit est l'un d'entre eux.

"Comfortable" apparaît dans la description de 105 produits et "furniture" dans la description de 4 produits avec 4 catégories différentes : Jouets, Mobilier d'intérieur, Mobilier d'extérieur et 'Dog and Cat Supplies & Toys'.

Comme vous pouvez le constater, le produit le plus pertinent par rapport à la requête est un jouet et le deuxième produit le plus pertinent est un meuble d'intérieur. Si vous souhaitez obtenir des informations détaillées sur le calcul du score afin de savoir pourquoi ces documents correspondent, vous pouvez attribuer la valeur true au paramètre explain __query.

Bien que les deux résultats soient les plus pertinents, compte tenu à la fois du nombre de documents et de l'occurrence des termes dans cet ensemble de données, l'intention derrière la requête "Meubles confortables pour un grandbalcon" est de rechercher des meubles pour un grand balcon réel, à l'exclusion, entre autres, des jouets et des meubles d'intérieur.

La recherche lexicale est relativement simple et rapide, mais elle présente des limites car il n'est pas toujours possible de connaître tous les termes et synonymes possibles sans nécessairement connaître l'intention et les requêtes de l'utilisateur. Un phénomène courant dans l'utilisation du langage naturel est l'inadéquation du vocabulaire. % L es recherches montrent qu'en moyenne, dans80 % des cas, des personnes différentes (experts dans le même domaine) nomment la même chose différemment.

Ces limites nous incitent à rechercher d'autres modèles de notation qui intègrent des connaissances sémantiques. Les modèles basés sur des transformateurs, qui excellent dans le traitement de jetons d'entrée séquentiels tels que le langage naturel, capturent le sens sous-jacent de votre recherche en prenant en compte les représentations mathématiques des documents et des requêtes. Cela permet une représentation vectorielle dense et contextuelle du texte, qui alimente la recherche sémantique, un moyen raffiné de trouver du contenu pertinent.

Recherche sémantique - recherche dense

Dans ce contexte, après avoir converti vos données en valeurs vectorielles significatives, l'algorithme de recherche k-nearest neighbor (kNN ) est utilisé pour trouver les représentations vectorielles dans un ensemble de données qui sont les plus similaires à un vecteur d'interrogation. Elasticsearch prend en charge deux méthodes de recherche kNN, le kNN exact par force brute et le kNN approximatif, également connu sous le nom d'ANN.

Le kNN brutal garantit des résultats précis, mais ne s'adapte pas bien aux grands ensembles de données. Le kNN approximatif trouve efficacement les voisins les plus proches approximatifs en sacrifiant une partie de la précision pour améliorer les performances.

Grâce à la prise en charge par Lucene de la recherche kNN et des index vectoriels denses, Elasticsearch tire parti de l'algorithme Hierarchical Navigable Small World (HNSW), qui démontre d'excellentes performances de recherche sur une variété d'ensembles de données de référence. Une recherche kNN approximative peut être effectuée en Python à l'aide du code d'exemple ci-dessous.

Recherche sémantique avec kNN approximatif

Ce bloc de code utilise le kNN d'Elasticsearch pour renvoyer jusqu'à deux produits dont la description est similaire à la requête vectorisée (query_vector_build) de "Meubles confortables pour un grand balcon" en tenant compte de l'intégration du champ "description" dans l'ensemble de données sur les produits.

Les encastrements de produits ont été préalablement générés dans un pipeline d'ingestion avec un processeur d'inférence contenant le logiciel "all-mpnet-base-v2" pour déduire les données qui étaient ingérées dans le pipeline.

Ce modèle a été choisi sur la base de l'évaluation des modèles pré-entraînés à l'aide de "sentence_transformers.evaluation" où différentes classes sont utilisées pour évaluer un modèle pendant la formation. Le modèle "all-mpnet-base-v2" a démontré la meilleure performance moyenne selon le classement Sentence-Transformers et a également obtenu une position favorable sur le Massive Text Embedding Benchmark (MTEB) Leaderboard. Le modèle pré-entraîné microsoft/mpnet-base et affiné sur un ensemble de données de 1B paires de phrases, il cartographie les phrases dans un espace vectoriel dense de 768 dimensions.

Par ailleurs, il existe de nombreux autres modèles qui peuvent être utilisés, en particulier ceux qui sont adaptés aux données spécifiques à votre domaine.

Sortie

Le résultat peut varier en fonction du modèle choisi, des filtres et de la syntonisation approximative de kNN.

Les résultats de la recherche kNN se trouvent tous deux dans la catégorie "Outdoor Furniture", même si le mot "outdoor" n'a pas été explicitement mentionné dans la requête, ce qui souligne l'importance de la compréhension sémantique dans le contexte.

La recherche vectorielle dense offre plusieurs avantages :

• Permettre la recherche sémantique

• Évolutivité pour traiter de très grands ensembles de données

• Flexibilité pour traiter un large éventail de types de données

Cependant, la recherche vectorielle dense présente également ses propres difficultés :

• Choisir le bon modèle d'intégration pour votre cas d'utilisation

• Une fois le modèle choisi, il peut être nécessaire de l'affiner pour optimiser les performances sur un ensemble de données spécifiques au domaine, un processus qui nécessite la participation d'experts du domaine.

• En outre, l'indexation de vecteurs à haute dimension peut être très coûteuse sur le plan informatique

Recherche sémantique - récupération de données éparses apprises

Explorons une autre approche : la récupération éparse apprise, une autre façon d'effectuer une recherche sémantique.

En tant que modèle clairsemé, il utilise l'index inversé basé sur Lucene d'Elasticsearch, qui bénéficie de décennies d'optimisations. Toutefois, cette approche va au-delà du simple ajout de synonymes avec des fonctions de notation lexicale telles que BM25. Au lieu de cela, il incorpore des associations apprises en utilisant une connaissance plus approfondie de la langue pour optimiser la pertinence.

En élargissant les requêtes de recherche pour inclure des termes pertinents qui ne sont pas présents dans la requête originale, l' encodeur de vecteurs épar s Elastic Learned Sparse Encoder améliore les encastrements de vecteurs épars, comme vous pouvez le voir dans l'exemple ci-dessous.

Recherche de vecteurs épars à l'aide d'un codeur épars à apprentissage élastique

Sortie

Les résultats dans ce cas incluent la catégorie "Garden Furniture", qui offre des produits assez similaires à "Outdoor Furniture".

En analysant "ml.tokens", le champ "rank_features" contenant les tokens générés par Learned Sparse Retrieval, il devient évident que parmi les différents tokens générés, il y a des termes qui, bien que ne faisant pas partie de la requête de recherche, sont toujours pertinents dans leur signification, tels que "relax" (confortable), "sofa" (meuble) et "outdoor" (balcon).

L'image ci-dessous présente certains de ces termes en regard de la requête, avec et sans expansion des termes.

Comme nous l'avons observé, ce modèle permet une recherche contextuelle et contribue à atténuer le problème d'inadéquation du vocabulaire tout en fournissant des résultats plus faciles à interpréter. Il peut même être plus performant que les modèles à vecteurs denses lorsqu'aucun recyclage spécifique au domaine n'est appliqué.

Recherche hybride : résultats pertinents grâce à la combinaison de la recherche lexicale et sémantique

En matière de recherche, il n'existe pas de solution universelle. Chacune de ces méthodes de recherche a ses avantages, mais aussi ses inconvénients. En fonction du cas d'utilisation, la meilleure option peut changer. Souvent, les meilleurs résultats obtenus par les différentes méthodes de recherche peuvent être complémentaires. C'est pourquoi, pour améliorer la pertinence, nous chercherons à combiner les points forts de chaque méthode.

Il existe plusieurs façons de mettre en œuvre une recherche hybride, notamment la combinaison linéaire, en attribuant un poids à chaque score, et la fusion des rangs réciproques (RRF), où il n'est pas nécessaire de spécifier un poids.

Elasticsearch : le meilleur des deux mondes avec la recherche lexicale et sémantique

Dans ce code, nous avons effectué une recherche hybride avec deux requêtes ayant la valeur " Unetable à manger et des chaises confortables pour un grand balcon". Au lieu d'utiliser "furniture" comme terme de recherche, nous spécifions ce que nous recherchons, et les deux recherches prennent en compte les mêmes valeurs de champ, "description". Le classement est déterminé par une combinaison linéaire avec un poids égal pour les notes BM25 et ELSER.

Sortie

Dans le code ci-dessous, nous utiliserons la même valeur pour la requête, mais nous combinerons les scores de BM25 (paramètre de requête) et de kNN (paramètre knn) en utilisant la méthode de fusion par rang réciproque pour combiner et classer les documents.

La fonctionnalité RRF est en avant-première technique. La syntaxe sera probablement modifiée avant l'AG.

Sortie

Ici, nous pourrions également utiliser différents champs et valeurs ; certains de ces exemples sont disponibles dans le Python notebook.

Comme vous pouvez le constater, Elasticsearch vous offre le meilleur des deux mondes : la recherche lexicale traditionnelle et la recherche vectorielle, qu'elle soit éparse ou dense, pour atteindre votre objectif et trouver la meilleure réponse possible à votre question.

Si vous souhaitez continuer à vous familiariser avec les approches mentionnées ici, ces blogs peuvent vous être utiles :

• Améliorer la recherche d'informations dans la pile élastique : Recherche hybride

• Recherche vectorielle dans Elasticsearch : La raison d'être de la conception

• Comment obtenir le meilleur de la recherche lexicale et de la recherche alimentée par l'IA avec la base de données vectorielle d'Elastic ?

• Présentation d'Elastic Learned Sparse Encoder : Le modèle d'IA d'Elastic pour la recherche sémantique

• Améliorer la recherche d'information dans la pile Elastic : Présentation d'Elastic Learned Sparse Encoder, notre nouveau modèle de recherche d'information

Elasticsearch fournit une base de données vectorielle, ainsi que tous les outils dont vous avez besoin pour construire une recherche vectorielle :

• Base de données vectorielleElasticsearch

• Cas d'utilisation de la recherche vectorielle avec Elastic

Conclusion

Dans ce billet de blog, nous avons exploré différentes approches de la recherche d'informations à l'aide d'Elasticsearch, en nous concentrant plus particulièrement sur la recherche textuelle, lexicale et sémantique. Pour le démontrer, nous avons fourni des exemples Python illustrant différents scénarios de recherche à l'aide d'un ensemble de données contenant des informations sur des produits de commerce électronique.

Nous avons passé en revue la recherche lexicale classique avec BM25 et discuté de ses avantages et de ses défis, tels que l'inadéquation du vocabulaire. Nous avons souligné l'importance d'intégrer des connaissances sémantiques pour résoudre ce problème. En outre, nous avons abordé la recherche vectorielle dense, qui permet une recherche sémantique, et les défis associés à cette méthode de recherche, notamment le coût de calcul lors de l'indexation de vecteurs à haute dimension.

D'autre part, nous avons mentionné que les vecteurs épars se compriment exceptionnellement bien. Ainsi, nous avons discuté de l'encodeur Learned Sparse Encoder d'Elastic, qui étend les requêtes de recherche pour inclure des termes pertinents qui ne sont pas présents dans la requête originale.

Il n'existe pas de solution unique en matière de recherche. Chaque méthode de recherche a ses avantages et ses inconvénients. C'est pourquoi nous avons également abordé le concept de recherche hybride.

Comme vous pouvez le constater, avec Elasticsearch, vous pouvez bénéficier du meilleur des deux mondes : la recherche lexicale traditionnelle et la recherche vectorielle !

Prêt à commencer ? Consultez le cahier Python disponible et commencez un essai gratuit d'Elastic Cloud.