Évaluation en temps réel des systèmes de recherche d'informations (IR)

Nov 29 2022

par Malvina Matlis & Marcos Calvo Lance Les systèmes de recherche d'informations (IR) sont omniprésents dans notre quotidien. Peut-être qu'il s'agit de régler des paris en recherchant la réponse en ligne, en localisant vos produits préférés sur Amazon, en trouvant n'importe quel e-mail dans Outlook, ou peut-être avez-vous simplement faim et souhaitez-vous cuisiner une délicieuse paella authentique.

de Malvina Matlis & Marcos Calvo Lance

Est-il difficile de trouver une recette authentique de Valence ?

Les systèmes de recherche d'informations (RI) sont omniprésents dans notre quotidien. Peut-être qu'il s'agit de régler des paris en recherchant la réponse en ligne, en localisant vos produits préférés sur Amazon, en trouvant n'importe quel e-mail dans Outlook, ou peut-être avez-vous simplement faim et souhaitez-vous cuisiner une délicieuse paella authentique. Notre vie ne serait probablement pas aussi facile (et moins amusante) sans toutes ces boîtes de recherche qui nous permettent de trouver toutes sortes de documents et d'informations, qu'elles soient écrites, audio, photos, vidéos ou autre. Cependant, pour qu'un utilisateur trouve un système IR utile, le système doit fournir une réponse pertinente en temps opportun. Par conséquent, comment s'assurer qu'un moteur de recherche fournit aux utilisateurs un contenu pertinent en fonction de leurs requêtes lorsque nous avons un scénario de "démarrage à froid", c'est-à-dire pas d'historique de requêtes ? Et comment évaluer les performances en direct d'un système IR lorsqu'il est déjà en production ?

Dans cet article de blog, nous montrerons comment nous avons choisi d'évaluer un tel système à l'aide de la surveillance en ligne et de l'analyse des journaux avec Kusto , un outil d'interrogation de Microsoft, mais ces concepts peuvent également être appliqués à d'autres langages et piles technologiques.

Évaluation des systèmes IR

L'évaluation des systèmes IR a été largement étudiée et documentée, ce qui signifie que quelques mesures standard ont été définies, un bon aperçu peut être trouvé à Evaluation Metrics For Information Retrieval .
Par exemple, certaines de ces mesures standard sont :

Précision
Elle quantifie la proportion des résultats renvoyés par le système qui sont pertinents pour la requête (c'est-à-dire le terme de recherche). Par exemple, dans l'image ci-dessus, nous avons recherché la recette d'une paella authentique. Le moteur de recherche a récupéré 330 millions de documents. Si nous avions une référence indiquant que 200 millions de ces documents sont pertinents pour la recherche de recettes, la précision de la requête serait de 200/330 = 60,6 %.

Rappel
Il mesure la proportion de résultats pertinents renvoyés par le système à partir de l'ensemble de tous les résultats pertinents. Revenons à notre exemple, et si le moteur de recherche manquait 20 millions de documents pertinents ? Alors le rappel sera 200/(200+20) = 90.9%

Classement réciproque (RR)
Il mesure où dans la liste des résultats renvoyés se trouve le premier document pertinent. Puisqu'il est pratique d'avoir des métriques avec des valeurs comprises entre 0 et 1, 1 représentant un meilleur score que 0, le classement réciproque est défini comme 1 sur l'index le plus élevé d'un document pertinent pour la requête. Pour le mesurer sur un ensemble de requêtes, nous faisons simplement la moyenne du classement réciproque sur l'ensemble de requêtes, obtenant ainsi le classement réciproque moyen (MRR), ou sous une forme d'équation :

où rang(i) est la position de rang (en partant de 1) du premier document pertinent pour la ième requête.

Puisque nous avons encore faim et que nous n'allons pas dépasser les 330 millions de recettes, le RR examinera le premier document que nous avons marqué comme pertinent. Disons que c'était la 5ème recette, alors le RR pour la requête sera de 1/5.

Plus facile à dire qu'à faire

Comme pour la plupart des problèmes d'apprentissage automatique, les métriques d'évaluation sont généralement calculées sur un ensemble de données d'évaluation prédéfini, annoté et organisé hors ligne, qui, espérons-le, est suffisamment représentatif du comportement du système dans la nature . Cependant, que se passe-t-il s'il n'existe pas d'ensemble de données suffisamment représentatif des besoins des utilisateurs ? Ou que se passe-t-il si ces besoins sont inconnus ?

Mesures en ligne — recueillons des commentaires
Une alternative à l'utilisation d'un ensemble de données d'évaluation prédéfini pour évaluer la qualité du système consiste à tirer parti des informations sur l'utilisation du système. En collectant des informations sur le parcours de l'utilisateur dans le système IR, nous sommes en mesure d'évaluer et de surveiller les résultats renvoyés. A titre d'exemple, considérons le flux utilisateur suivant dans une application :

Présentation générale d'un parcours de recherche. À n'importe quelle étape, les utilisateurs peuvent revenir aux étapes précédentes. La progression peut être surveillée par l'horodatage de l'événement. Image créée par les auteurs.

Requête d'entrée : l'utilisateur saisit une requête ("recette de paella authentique" dans notre exemple) dans l'application, qui est transmise au moteur de recherche.
Parcours de documents : Le système renvoie une liste de documents, et l'application les affiche triés par pertinence.
Inspection de documents : l'utilisateur parcourt les documents retournés dans l'ordre et en sélectionne un pour l'inspecter plus avant.
Succès : si l'utilisateur est satisfait du document inspecté, il peut informer l'application que la recherche est terminée. Une option consiste à évaluer le résultat positivement. Une autre consiste à utiliser des méthodes proxy pour déduire que la recherche a réussi, comme mesurer le temps que l'utilisateur a passé à inspecter le document.
Si l'utilisateur n'est pas satisfait du document inspecté, il retourne parcourir les résultats (point 4) et peut sélectionner un nouveau document à inspecter.

Kusto à la rescousse

Les mécanismes d'observabilité tels que la journalisation génèrent une énorme quantité de données, ce qui pose le défi supplémentaire de les interroger.

Les journaux peuvent être inspectés dans le portail Azure AppInsights à l'aide d' Azure Data Explorer et, plus précisément, de son langage de requête Kusto . Si vous êtes familier avec SQL, vous reconnaîtrez pas mal de points communs à ce langage. Cependant, il existe une différence significative entre Kusto et SQL - dans Kusto, les instructions sont exécutées dans l'ordre, ce qui rend les requêtes plus courtes et plus lisibles que les requêtes SQL.

Métriques d'évaluation à l'aide de la journalisation des événements utilisateur

Traditionnellement, la journalisation a été largement utilisée à des fins de surveillance et d'ingénierie. Quelques exemples incluent le nombre de requêtes par unité de temps que le système doit traiter, le nombre d'utilisateurs qui interrogent le système ou le temps qu'un utilisateur passe en moyenne à inspecter un document. Cependant, les Data Scientists peuvent également bénéficier d'une journalisation appropriée pour calculer les indicateurs de performance clés (KPI) et évaluer en ligne les performances du système de manière continue.

Rang réciproque moyen (MRR)

À partir des mesures d'évaluation IR mentionnées ci-dessus, le classement réciproque (RR) ne nécessite que le rang du premier résultat pertinent dans la liste de documents réajustée, que nous pouvons définir par l'interaction de l'utilisateur final. Par conséquent, il peut être calculé sur le trafic réel une fois que la journalisation appropriée est en place. Dans notre exemple, lorsqu'un événement OnSuccess est déclenché, cela signifie que l'utilisateur a considéré un résultat comme pertinent. Du point de vue de l'expérience utilisateur, le RR pour une requête donnée nous informe de la rapidité avec laquelle l'utilisateur pourrait trouver un premier document pertinent pour ses besoins.

Le MRR peut ensuite être calculé en faisant la moyenne du RR sur une période de temps significative, par exemple un jour, sur une population d'utilisateurs statistiquement significative afin que différentes requêtes et profils d'utilisateurs soient agrégés et représentés dans la métrique. De cette façon, nous pouvons comparer que, par exemple, les utilisateurs d'Espagne trouvent la 1ère recette pertinente sur le 15e document en moyenne et les utilisateurs d'Israël la trouvent sur le 3e document en moyenne.

La requête Kusto suivante calcule exactement cela.

Rang réciproque moyen quotidien

Une feuille de triche rapide de Kusto à SQL (et rappelez-vous, Kusto s'exécute dans l'ordre):

[Kusto] -> [SQL]
où -> où
projet -> sélectionner
résume -> une sélection avec n'importe quelle fonction d'agrégation comme sum, avg ou min, ainsi que le groupe par colonnes
make-series -> une fonctionnalité non disponible dans SQL qui transforme l'ensemble de données en un tracé de série chronologique
rendu -> une autre fonctionnalité non disponible en SQL qui trace les données

Étant donné une requête "recette de paella authentique" et 10 documents qui ont été renvoyés par le moteur de recherche, nous ordonnons les documents de sorte que le document le plus similaire à la requête soit au rang 1 et le moins similaire au rang 10. Pour les besoins de l'exemple , supposons que les documents 3, 6 et 8 ont été jugés pertinents par nos utilisateurs.

Les documents en vert sont marqués par l'utilisateur comme pertinents.

arg_max (ExprToMaximize, * | ExprToReturn [, ...])

Métriques de l'entonnoir

La métrique de classement réciproque nous offre une vue limitée sur la façon dont l'utilisateur interagit avec le système, car elle ne regarde que le premier document pertinent. Par exemple, nous pouvons compléter cette métrique en calculant le nombre de documents qu'un utilisateur doit inspecter en moyenne pour trouver tous les documents dont il pourrait avoir besoin. Dans un scénario idéal, nous voudrions que l'utilisateur n'ouvre que les documents qui sont effectivement pertinents, car nous économiserions beaucoup de temps aux utilisateurs en parcourant des documents non pertinents.

En utilisant la journalisation introduite dans ce système, nous pouvons reformuler cette question sous forme de métrique : à partir de ces interactions provoquant un événement onNavigate , quelle est la proportion qui a également déclenché un événement onSuccess ? Ou, plus simplement, avec quel pourcentage des documents lus par l'utilisateur a-t-il interagi ? Nous pouvons l'écrire en utilisant Kusto comme suit :

Vous pouvez consulter la feuille de triche Kusto to SQL complète pour l'interprétation de la requête.

Tout mettre ensemble — le tableau de bord

Pour suivre ces mesures et d'autres, il est pratique de créer un tableau de bord. Dans notre exemple, nous surveillons les métriques à l'aide de la fonctionnalité de tableau de bord AppInsights. Nous suivons les métriques de surveillance ainsi que les métriques de performance IR dans une seule vue, car toutes les informations peuvent être facilement obtenues à partir des journaux système. Tout le code est inclus dans le référentiel azure-samples suivant

Tableau de bord AppInsights surveillant l'utilisation et les performances d'un index de recherche

Ce tableau de bord nous permet de suivre simultanément les mesures du système et des performances. Cependant, cela ne nous permet pas nécessairement de diagnostiquer pourquoi la performance de nos métriques se détériore. Par exemple, si le "RR quotidien" diminue avec le temps, est-ce parce que :

Les besoins des utilisateurs ont changé ?
De nouveaux documents ont été indexés et le nouveau contenu ne correspond pas à l'ancien ?
Notre bibliothèque de documents est obsolète et doit être mise à jour avec de nouveaux documents ?
La définition du succès de l'utilisateur a changé ?
Les changements UX affectent-ils la façon dont les utilisateurs interagissent avec les résultats ? Par exemple, un widget de rubrique apparaît sur la page de résultats et affiche des informations, éliminant ainsi le besoin d'interagir avec un document spécifique.
Saisonnalité ?
Autre?

Conclusion

Nous avons été motivés pour écrire cet article parce que nous avons rencontré un scénario où les données d'évaluation annotées préexistantes pour le moteur de recherche n'étaient pas disponibles. Nous avons constaté que le suivi des interactions des utilisateurs avec le système au fil du temps fournit des indices sur les endroits où des ajustements supplémentaires sont nécessaires. Le classement réciproque visualise jusqu'où l'utilisateur doit faire défiler pour trouver le premier document pertinent, tandis que le rapport entre les documents pertinents et ouverts met en lumière les performances globales du moteur de recherche et la pertinence des documents renvoyés.

La conception d'une journalisation et d'une analyse appropriées des applications permet un suivi en temps réel de la qualité du système à partir de la minute où le système fonctionne en production. Cela n'est pas seulement utile dans les cas où les ressources d'évaluation ne sont pas disponibles, mais nous permet également de repérer les écarts dans la qualité du système au fil du temps, et donc d'améliorer l'expérience utilisateur. Et maintenant, on va faire une paella.