Tard dans la nuit, un policier trouve un homme ivre qui rampe à quatre pattes sous un réverbère. L'homme ivre dit à l'agent qu'il cherche son portefeuille. Lorsque l'agent lui demande s'il est sûr d'avoir perdu son portefeuille à cet endroit, l'homme répond qu'il pense l'avoir plutôt perdu de l'autre côté de la rue. Alors pourquoi cherchez-vous ici ? demande l'agent déconcerté. Parce que la lumière est meilleure ici, explique l'homme ivre.
David H. Friedman, Why Scientific Studies Are So Often Wrong: The Streetlight Effect, Discover magazine, déc. 2010
Les benchmarks sont une composante essentielle des pratiques modernes d'apprentissage automatique depuis un certain temps, mais ils présentent un problème très sérieux : nous ne pouvons pas dire si nos benchmarks mesurent quelque chose d'utile.
C'est un problème majeur, et cet article présentera une partie de la solution : l'AIR-Bench. Ce projet conjoint avec la Beijing Academy of Artificial Intelligence est une approche novatrice des métriques d'IA conçue pour améliorer la qualité et l'utilité de nos benchmarks.
tagL'effet Réverbère
La recherche scientifique et opérationnelle met beaucoup l'accent sur les mesures, mais les mesures ne sont pas simples. Dans une étude de santé, vous pourriez vouloir savoir si un médicament ou un traitement a rendu les patients plus sains, a prolongé leur vie ou a amélioré leur condition d'une manière ou d'une autre. Mais la santé et l'amélioration de la qualité de vie sont des choses difficiles à mesurer directement, et il peut falloir des décennies pour savoir si un traitement a prolongé la vie de quelqu'un.
Les chercheurs utilisent donc des indicateurs indirects. Dans une étude de santé, il peut s'agir de la force physique, de la réduction de la douleur, de la baisse de la pression artérielle ou d'une autre variable facilement mesurable. L'un des problèmes de la recherche en santé est que l'indicateur indirect peut ne pas être vraiment représentatif du meilleur résultat de santé que vous souhaitez obtenir avec un médicament ou un traitement.
Une mesure est un indicateur indirect de quelque chose d'utile qui compte pour vous. Vous ne pouvez peut-être pas mesurer cette chose, alors vous mesurez autre chose, quelque chose que vous pouvez mesurer, et que vous avez des raisons de croire corrélée avec la chose utile qui vous importe vraiment.
L'accent mis sur la mesure a été un développement majeur de la recherche opérationnelle du 20e siècle et a eu des effets profonds et positifs. Le Total Quality Management, un ensemble de doctrines crédité de la montée du Japon à la domination économique dans les années 1980, concerne presque entièrement la mesure constante de variables indirectes et l'optimisation des pratiques sur cette base.
Mais l'accent mis sur la mesure pose certains problèmes connus et importants :
- Une mesure peut cesser d'être un bon indicateur indirect lorsque vous prenez des décisions basées sur elle.
- Il existe souvent des moyens de gonfler une mesure qui n'améliorent rien, ce qui peut mener à la tricherie ou à croire que l'on progresse en faisant des choses qui n'aident pas.
Certains pensent que la plupart des recherches médicales pourraient être tout simplement erronées en partie à cause de ce problème. La déconnexion entre les choses que vous pouvez mesurer et les objectifs réels est l'une des raisons citées pour la catastrophe de la guerre américaine au Vietnam.
On appelle parfois cela "l'effet Réverbère", d'après les histoires, comme celle en haut de cette page, de l'ivrogne qui cherche quelque chose non pas là où il l'a perdu, mais là où la lumière est meilleure. Une mesure indirecte, c'est comme regarder là où il y a de la lumière parce qu'il n'y a pas de lumière sur la chose que nous voulons voir.
Dans la littérature plus technique, "l'effet Réverbère" est généralement lié à la Loi de Goodhart, attribuée aux critiques de l'économiste britannique Charles Goodhart envers le gouvernement Thatcher, qui avait mis beaucoup l'accent sur les mesures indirectes de la prospérité. La Loi de Goodhart a plusieurs formulations, mais celle ci-dessous est la plus citée :
Toute mesure qui devient un objectif devient une mauvaise mesure [...]
Keith Hoskins, 1996 The 'awful idea of accountability': inscribing people into the measurement of objects.
Dans l'IA, un exemple célèbre est la métrique BLEU utilisée dans la recherche en traduction automatique. Développé en 2001 chez IBM, BLEU est un moyen d'automatiser l'évaluation des systèmes de traduction automatique, et ce fut un facteur déterminant dans l'essor de la traduction automatique des années 2000. Une fois qu'il était facile de donner un score à votre système, vous pouviez travailler à l'améliorer. Et les scores BLEU se sont constamment améliorés. Vers 2010, il était presque impossible de faire publier un article de recherche sur la traduction automatique dans une revue ou une conférence s'il ne battait pas le score BLEU de l'état de l'art, peu importe à quel point l'article était innovant ou à quel point il pouvait gérer un problème spécifique que d'autres systèmes géraient mal.
Le moyen le plus facile d'être accepté dans une conférence était de trouver une façon mineure de modifier les paramètres de votre modèle, d'obtenir un score BLEU légèrement supérieur à celui de Google Translate, puis de soumettre. Ces résultats étaient essentiellement inutiles. Il suffisait de prendre quelques nouveaux textes à traduire pour montrer qu'ils étaient rarement meilleurs et souvent pires que l'état de l'art.
Au lieu d'utiliser BLEU pour évaluer les progrès en traduction automatique, obtenir un meilleur score BLEU est devenu l'objectif. Dès que cela s'est produit, il a cessé d'être un moyen utile d'évaluer les progrès.
tagNos benchmarks d'IA sont-ils de bons indicateurs indirects ?
Le benchmark le plus utilisé pour les modèles d'embedding est l'ensemble de tests MTEB, qui comprend 56 tests spécifiques. Ceux-ci sont moyennés par catégorie et tous ensemble pour produire une collection de scores spécifiques aux classes. Au moment de la rédaction, le haut du classement MTEB ressemble à ceci :
Le modèle d'embedding le mieux classé a un score moyen global de 68,28, le suivant est à 67,56. Il est très difficile, en regardant ce tableau, de savoir si c'est une grande différence ou non. Si c'est une petite différence, alors d'autres facteurs peuvent être plus importants que le modèle ayant le score le plus élevé :
- Taille du modèle : Les modèles ont différentes tailles, reflétant différentes demandes en ressources de calcul. Les petits modèles s'exécutent plus rapidement, utilisent moins de mémoire et nécessitent du matériel moins coûteux. Nous voyons, dans ce top 10, des modèles allant de 434 millions à plus de 46 milliards de paramètres — une différence de 100 fois !
- Taille de l'embedding : Les dimensions d'embedding varient. Une dimensionnalité plus petite fait que les vecteurs d'embedding utilisent moins de mémoire et de stockage et rend les comparaisons de vecteurs (l'utilisation principale des embeddings) beaucoup plus rapides. Dans cette liste, nous voyons des dimensions d'embedding de 768 à 4096 — seulement une différence de cinq fois mais toujours significative lors de la construction d'applications commerciales.
- Taille de la fenêtre de contexte d'entrée : Les fenêtres de contexte varient en taille et en qualité, de 2048 tokens à 32768. De plus, différents modèles utilisent différentes approches pour l'encodage positionnel et la gestion des entrées, ce qui peut créer des biais en faveur de parties spécifiques de l'entrée.
En bref, la moyenne globale est une manière très incomplète de déterminer quel modèle d'embedding est le meilleur.
Même si nous regardons les scores spécifiques aux tâches, comme ceux ci-dessous pour la recherche, nous faisons face aux mêmes problèmes encore et encore. Quel que soit le score d'un modèle sur cet ensemble de tests, il n'y a aucun moyen de savoir quels modèles fonctionneront le mieux pour votre cas d'utilisation unique particulier.
Mais ce n'est pas la fin des problèmes avec ce type de benchmarks. L'idée principale de la Loi de Goodhart est qu'une métrique peut toujours être détournée, souvent sans intention. Par exemple, les benchmarks MTEB contiennent des données provenant de sources publiques qui sont probablement présentes dans vos données d'entraînement. À moins de travailler spécifiquement pour retirer les données de benchmark de votre entraînement, vos scores de benchmark seront statistiquement peu fiables. Il n'existe pas de solution simple et complète. Un benchmark est un indicateur indirect et nous ne pouvons jamais être certains qu'il reflète ce que nous voulons savoir mais ne pouvons pas mesurer directement. Cependant, nous identifions trois problèmes fondamentaux avec les benchmarks d'IA que nous pouvons atténuer : 1. Les benchmarks sont fixes par nature : les mêmes tâches, utilisant les mêmes textes. 2. Les benchmarks sont génériques : ils ne sont pas très informatifs sur des scénarios réels. 3. Les benchmarks sont rigides : ils ne peuvent pas s'adapter à des cas d'utilisation divers. L'IA crée ce type de problèmes, mais elle crée parfois aussi des solutions. Nous pensons pouvoir utiliser les modèles d'IA pour résoudre ces problèmes, du moins en ce qui concerne les benchmarks d'IA. ## Utiliser l'IA pour évaluer l'IA : AIR-Bench AIR-Bench est open source et disponible sous la [Licence MIT](https://opensource.org/license/mit?ref=jina-ai-gmbh.ghost.io). Vous pouvez consulter ou télécharger le code depuis son [dépôt sur GitHub](https://github.com/AIR-Bench/AIR-Bench/?ref=jina-ai-gmbh.ghost.io). ### Que fait-il ? AIR-Bench apporte des fonctionnalités importantes aux benchmarks d'IA : * **Spécialisation pour les Applications de Recherche et RAG** Ce benchmark est orienté vers des applications réalistes de recherche d'information et des pipelines de génération augmentée par recherche. * **Flexibilité de Domaine et de Langue** AIR facilite grandement la création de benchmarks à partir de données spécifiques à un domaine ou pour une autre langue, ou même à partir de vos propres données spécifiques à une tâche. * **Génération Automatisée de Données** AIR-Bench génère des données de test et le jeu de données reçoit des mises à jour régulières, réduisant le risque de fuite de données. ## Classement AIR-Bench sur HuggingFace ⚠️ Explorez la version bêta publique du Classement AIR-Bench dans [l'espace HuggingFace d'AIR-Bench](https://huggingface.co/spaces/AIR-Bench/leaderboard?ref=jina-ai-gmbh.ghost.io). Nous gérons un [classement](https://huggingface.co/spaces/AIR-Bench/leaderboard?ref=jina-ai-gmbh.ghost.io), similaire à celui de [MTEB](https://huggingface.co/spaces/mteb/leaderboard?ref=jina-ai-gmbh.ghost.io), pour la version actuelle des tâches générées par AIR-Bench. Nous régénérerons régulièrement les benchmarks, en ajouterons de nouveaux et étendrons la couverture à davantage de modèles d'IA. ### Comment fonctionne-t-il ? L'idée centrale de l'approche AIR est que nous pouvons utiliser les grands modèles de langage (LLM) pour *générer* de nouveaux textes et de nouvelles tâches qui ne peuvent pas être dans un ensemble d'entraînement. AIR-Bench tire parti des capacités créatives des LLM en leur demandant de jouer un scénario. L'utilisateur choisit une collection de documents — une collection réelle qui peut faire partie des données d'entraînement de certains modèles — puis imagine un utilisateur avec un rôle défini, et une situation dans laquelle il aurait besoin d'utiliser ce corpus de documents. Ensuite, l'utilisateur sélectionne un document du corpus et le transmet au LLM avec le profil utilisateur et la description de la situation. Le LLM est invité à créer des requêtes appropriées à cet utilisateur et à cette situation et qui devraient permettre de trouver ce document. Le pipeline AIR-Bench sollicite ensuite le LLM avec le document et la requête et crée des documents synthétiques qui sont *similaires* à celui fourni mais qui *ne devraient pas* correspondre à la requête. Nous avons maintenant : * Une collection de requêtes * Un document réel correspondant pour chaque requête * Une petite collection de documents synthétiques non correspondants attendus AIR-Bench fusionne les documents synthétiques avec la collection de documents réels puis utilise un ou plusieurs modèles d'embedding et de reranking pour vérifier que les requêtes *devraient* pouvoir retrouver les documents correspondants. Il utilise également le LLM pour vérifier que chaque requête est pertinente pour les documents qu'elle devrait retrouver. Pour plus de détails sur ce processus de génération et de contrôle qualité centré sur l'IA, consultez la [documentation sur la Génération de Données](https://github.com/AIR-Bench/AIR-Bench/blob/main/docs/data_generation.md?ref=jina-ai-gmbh.ghost.io) dans le [dépôt AIR-Bench sur GitHub](https://github.com/AIR-Bench/AIR-Bench/?ref=jina-ai-gmbh.ghost.io).
AIR-BenchLe résultat est un ensemble de paires requête-correspondance de haute qualité et un jeu de données semi-synthétique pour les tester. Même si la collection de documents réels d'origine fait partie de son entraînement, les documents synthétiques ajoutés et les requêtes elles-mêmes sont des données nouvelles et jamais vues auparavant qu'il n'aurait pas pu apprendre précédemment.
tagBenchmarks spécifiques au domaine et tests basés sur la réalité
La synthèse des requêtes et des documents empêche les données de benchmark de fuiter dans l'entraînement, mais elle contribue également largement à résoudre le problème des benchmarks génériques.
En fournissant aux LLMs des données choisies, un profil utilisateur et un scénario, AIR-Bench facilite grandement la construction de benchmarks pour des cas d'utilisation particuliers. De plus, en construisant des requêtes pour un type d'utilisateur et un scénario d'utilisation spécifiques, AIR-Bench peut produire des requêtes de test plus fidèles à l'utilisation réelle que les benchmarks traditionnels. La créativité et l'imagination limitées d'un LLM peuvent ne pas correspondre entièrement à un scénario réel, mais c'est une meilleure correspondance qu'un jeu de données de test statique constitué de données disponibles pour les chercheurs.
En tant que sous-produit de cette flexibilité, AIR-Bench prend en charge toutes les langues supportées par GPT-4.
De plus, AIR-Bench se concentre spécifiquement sur la recherche d'informations réaliste basée sur l'IA, de loin l'application la plus répandue des modèles d'embedding. Il ne fournit pas de scores pour d'autres types de tâches comme le clustering ou la classification.
tagLa distribution AIR-Bench
AIR-Bench est disponible en téléchargement, utilisation et modification via son dépôt GitHub.
AIR-BenchAIR-Bench prend en charge deux types de benchmarks :
- Une tâche de recherche d'informations basée sur l'évaluation de la récupération correcte des documents pertinents pour des requêtes spécifiques.
- Une tâche "document long" qui imite la partie recherche d'informations d'un pipeline de génération augmentée par récupération.
Nous avons également pré-généré un ensemble de benchmarks, en anglais et en chinois, ainsi que les scripts pour les générer comme exemples concrets d'utilisation d'AIR-Bench. Ils utilisent des ensembles de données facilement disponibles.
Par exemple, pour une sélection de 6 738 498 pages Wikipédia en anglais, nous avons généré 1 727 requêtes correspondant à 4 260 documents et 7 882 documents synthétiques supplémentaires non correspondants mais similaires. Nous proposons des benchmarks de recherche d'informations conventionnels pour huit jeux de données en anglais et six en chinois. Pour les tâches "document long", nous fournissons quinze benchmarks, tous en anglais.
Pour voir la liste complète et plus de détails, visitez la page des tâches disponibles dans le dépôt AIR-Bench sur GitHub.
AIR-BenchtagParticipez
L'AIR-Benchmark a été conçu comme un outil pour la communauté Search Foundations afin que les utilisateurs engagés puissent créer des benchmarks mieux adaptés à leurs besoins. Lorsque vos tests sont informatifs sur vos cas d'utilisation, ils nous informent également, nous permettant ainsi de construire des produits qui répondent mieux à vos besoins.
