Un ingénieur logiciel doit toujours fournir à ses clients des preuves concrètes de la qualité des livrables. Un ingénieur en recherche se spécialise dans un domaine de cette qualité logicielle générique, appelé qualité de recherche.
Qu’est-ce que la qualité de recherche ? Et pourquoi est-ce si important dans une infrastructure de recherche ? Après tout, la “qualité du logiciel” devrait être omniprésente, elle devrait toujours inclure tout (et en fait, elle l’est), mais lorsqu’on traite des systèmes de recherche, la qualité est un terme très abstrait, difficile à définir à l’avance.
La correctitude fonctionnelle d’une infrastructure de recherche (en supposant que la correction soit le seul facteur influençant la qualité du système – ce qui n’est pas le cas) est naturellement associée à des jugements humains, à des opinions, et malheureusement, nous savons que les opinions peuvent être différentes d’une personne à l’autre.
Les parties prenantes commerciales, qui tireront une valeur d’un système de recherche, peuvent appartenir à différentes catégories, avoir des attentes différentes et avoir en tête une idée différente de la correctitude attendue du système.
Dans ce scénario, un ingénieur en recherche est confronté à de nombreux défis en termes de choix, et à la fin, il doit fournir des preuves concrètes concernant la couverture fonctionnelle de ces choix.
C’est dans ce contexte que nous avons développé le Rated Ranking Evaluator (ci-après RRE).
Qu'est-ce que c'est ?
Le Rated Ranking Evaluator (RRE) est un outil d’évaluation de la qualité de recherche qui évalue la qualité des résultats provenant d’une infrastructure de recherche.
Il aide un ingénieur en recherche dans son travail quotidien. Êtes-vous un ingénieur en recherche ? Êtes-vous en train de configurer, de mettre en place, de modifier une infrastructure de recherche ? Voulez-vous quelque chose qui vous donne des preuves sur les améliorations entre différentes versions ? RRE peut vous aider.
RRE formalise la manière dont un système de recherche satisfait les besoins d’information de l’utilisateur, à un niveau technique, en combinant un modèle de domaine riche en arbre avec plusieurs mesures d’évaluation, mais aussi à un niveau fonctionnel, en fournissant des sorties lisibles par l’homme qui peuvent cibler les parties prenantes commerciales.
Il encourage une approche incrémentale/itérative/immuable pendant le développement et l’évolution d’un système de recherche : en supposant que nous commençons notre système à partir de la version x.y, lorsque vient le moment d’appliquer un changement important à sa configuration, il est préférable de cloner cette version et d’appliquer les changements à la nouvelle version fraîche.
De cette manière, RRE exécutera le processus d’évaluation sur toutes les versions disponibles, fournira le delta/la tendance entre les versions successives, afin que vous puissiez immédiatement obtenir un aperçu détaillé de l’évolution du système, en termes de pertinence.
Cet article est un simple résumé du RRE. Vous pouvez trouver plus d’informations détaillées dans le Wiki du projet.
En quelques mots, que puis-je obtenir de RRE ?
Vous pouvez configurer RRE comme une partie intégrante de votre cycle de construction de projet. Cela signifie qu’à chaque fois qu’une construction est déclenchée, un processus d’évaluation sera exécuté.
RRE n’est pas lié à une plateforme de recherche spécifique : il fournit un mini-framework pour intégrer différentes plateformes de recherche. Actuellement, nous avons deux bindings disponibles : Apache Solr et Elasticsearch (voir ici pour les versions supportées).
Les données d’évaluation seront disponibles :
- sous forme de fichier JSON : pour des traitements ultérieurs
- sous forme de feuille de calcul : pour livrer les résultats de l’évaluation à quelqu’un d’autre (par exemple, un stakeholder)
- dans une Console Web où les métriques et leurs valeurs sont actualisées en temps réel (après chaque construction)
Comment cela fonctionne
RRE fournit un modèle de domaine riche, composite, en forme d’arbre, où le concept d’évaluation peut être observé à différents niveaux.
L’évaluation au niveau supérieur est simplement un conteneur des entités imbriquées. Notez que toutes les relations entre les entités sont 1 à plusieurs. Dans ce contexte, un Corpus est défini comme un ensemble de données de test. RRE l’utilisera pour exécuter le processus d’évaluation ; dans un seul processus d’évaluation, vous pouvez avoir plusieurs ensembles de données.
Un Topic représente un besoin en information : il définit une exigence fonctionnelle du point de vue de l’utilisateur final. À l’intérieur d’un topic, nous pouvons avoir plusieurs requêtes, qui expriment le même besoin mais à un niveau plus technique. RRE fournit une abstraction supplémentaire au milieu : les groupes de requêtes. Un groupe de requêtes est un groupe de requêtes censé produire les mêmes résultats (et donc associé au même ensemble de jugements).
Les requêtes, qui sont les éléments techniques du modèle de domaine de RRE, sont encore décomposées sous plusieurs perspectives, une pour chaque version disponible de notre système. Une requête est bien sûr une entité unique, mais pendant une session d’évaluation, son exécution concrète se produit plusieurs fois, une pour chaque version disponible. C’est pourquoi RRE doit mesurer les résultats de recherche (c’est-à-dire les exécutions de requêtes) par rapport à toutes les versions.
Pour chaque version, nous aurons finalement une ou plusieurs métriques, selon la configuration. Enfin, bien que les métriques soient calculées au niveau de la requête/ version, RRE agrégera ces valeurs aux niveaux supérieurs (voir les lignes verticales pointillées dans le diagramme) de sorte que chaque entité/niveau dans le modèle de domaine offrira une perspective agrégée de toutes les métriques disponibles (par exemple, je pourrais être intéressé par le NDCG pour une requête donnée, ou je pourrais m’arrêter à un niveau de topic).
Entrée
Pour exécuter un processus d’évaluation, RRE a besoin des éléments suivants :
- Un ou plusieurs corpus / ensemble de test : ce sont les ensembles de données représentatifs d’un domaine spécifique, qui seront utilisés pour peupler et interroger une plateforme de recherche cible.
- Un ou plusieurs ensembles de configuration : bien qu’il n’y ait rien contre l’utilisation d’une seule configuration, un minimum de deux versions est requis pour fournir une comparaison entre les mesures d’évaluation.
- Un ou plusieurs ensembles de jugements : c’est ici que les jugements sont définis, en termes de documents pertinents pour chaque groupe de requêtes.
Sortie
La sortie concrète de RRE dépend du conteneur d’exécution dans lequel il fonctionne. Le cœur de RRE est simplement une bibliothèque, donc lorsqu’il est utilisé de manière programmatique dans un projet, il génère un ensemble d’objets correspondant au modèle de domaine décrit ci-dessus.
Lorsqu’il est utilisé en tant que plugin Maven, il génère principalement la même structure au format JSON. Ces données sont ensuite utilisées pour produire d’autres sorties, comme une feuille de calcul. La même charge utile peut être envoyée à un autre module appelé RRE Server, qui offre une console Web basée sur AngularJS qui se met à jour automatiquement.
La console RRE est très utile lorsque nous effectuons des itérations internes / essais autour d’un problème, ce qui nécessite généralement des cycles de modification et vérification immédiate. Imaginez si vous pouvez avoir deux moniteurs sur votre bureau : sur le premier, il y a votre IDE préféré, où vous modifiez les choses, exécutez des builds. Sur le deuxième, il y a la console RRE (voir ci-dessous). Après chaque build, jetez simplement un coup d’œil sur la console pour obtenir un retour immédiat sur vos changements.
Travaux futurs
- Intégration avec un outil pour construire les jugements de pertinence. Cela pourrait être une interface utilisateur ou un collecteur d’interactions plus sophistiqué (qui générera automatiquement les ensembles de jugements à partir de métriques en ligne calculées comme le taux de clics, le taux de vente)
- Plugin Jenkins : pour une meilleure intégration de RRE dans l’outil CI populaire
- Plugin Gradle
- API Apache Solr Rank Eval : en utilisant le cœur de RRE, nous pourrions implémenter un point d’API Rank Eval dans Solr, similaire à l’API Rank Eval fournie dans Elasticsearch
- ??? Autres ? Toute suggestion est la bienvenue !
Liens
- Le dépôt du projet
- Le Wiki du projet
- Les diapositives de notre intervention au meetup Apache Solr/Lucene à Londres
- Le résumé excellent du meetup de Londres par Flax
