Évaluation de la pertinence des recherches, partie 1 - Le benchmark BEIR

Ce document est le premier d'une série d'articles de blog traitant de la manière d'évaluer vos propres systèmes de recherche dans le cadre d'une meilleure compréhension du benchmark BEIR. Nous vous présenterons des conseils et des techniques spécifiques pour améliorer vos processus d'évaluation des recherches dans le contexte d'une meilleure compréhension du BEIR. Nous aborderons également les pièges courants qui affectent la fiabilité de l'évaluation. Enfin, nous soulignerons l'importance des LLM comme nouvel outil puissant pour les ingénieurs en recherche et illustrerons par des exemples leur utilisation pour faciliter l'évaluation.

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.

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.

{
  "_id": "test-economy-epiasghbf-pro02b",
  "title": "economic policy international africa society gender house believes feminisation",
  "text": "Again employment needs to be contextualised with …",
  "metadata": {}
}
{
  "_id": "test-society-epiasghbf-pro02b",
  "title": "economic policy international africa society gender house believes feminisation",
  "text": "Again employment needs to be contextualised with …",
  "metadata": {}
}

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

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$\dag$ :

• 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 :

{
  "query":
    {
        "_id": 155234,
        "text": "do bigger tires affect gas mileage"
    },
  "positive_doc":
    {
        "_id": 502713,
        "text": "Tire Width versus Gas Mileage. Tire width is one of the only tire size factors that can influence gas mileage in a positive way. For example, a narrow tire will have less wind resistance, rolling resistance, and weight; thus increasing gas mileage.",
    },
    "negative_doc":
    {
        "_id": 7073658,
        "text": "Tire Size and Width Influences Gas Mileage. There are two things to consider when thinking about tires and their effect on gas mileage; one is wind resistance, and the other is rolling resistance. When a car is driving at higher speeds, it experiences higher wind resistance; this means lower fuel economy."
    }
}

2{^>e <^}exemple :

{
  "query":
    {
        "_id": 300674,
        "text": "how many years did william bradford serve as governor of plymouth colony?"
    },
  "positive_doc":
    {
        "_id": 7067032,
        "text": "http://en.wikipedia.org/wiki/William_Bradford_(Plymouth_Colony_governor) William Bradford (c.1590 \u00e2\u0080\u0093 1657) was an English Separatist leader in Leiden, Holland and in Plymouth Colony was a signatory to the Mayflower Compact. He served as Plymouth Colony Governor five times covering about thirty years between 1621 and 1657."
    },
    "negative_doc":
    {
        "_id": 2495763,
        "text": "William Bradford was the governor of Plymouth Colony for 30 years. The colony was founded by people called Puritans. They were some of the first people from England to settle in what is now the United States. Bradford helped make Plymouth the first lasting colony in New England."
    }
}

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.

$\dag$ 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.