Comment évaluer efficacement les systèmes de génération augmentée par la recherche d’information (RAG)

À retenir

• Expliquons les principales métriques et méthodes d’évaluation que nous avons trouvées utiles en développant des systèmes RAG chez Towards AI.
• Par exemple, si vous construisez un outil de recherche juridique avec du RAG, il devra être approprié au contexte et à jour.
• Nous avons besoin de méthodes et de métriques plus rigoureuses pour nous assurer que les applications de LLMs fonctionnent de façon optimale.

Vous implémentez probablement des systèmes RAG tout en passant à côté d’améliorations faciles. La plupart n’ont même pas de pipeline d’évaluation. Comment savoir si leur système est optimal ou si chaque changement l’améliore? Il faut l’évaluer, ce qui diffère de l’évaluation des LLMs eux-mêmes. Examinons les principales métriques et méthodes d’évaluation que nous avons trouvées utiles en développant des systèmes RAG chez Towards AI.

Le RAG combine des mécanismes de recherche (comme la recherche Google) avec des modèles génératifs (par exemple GPT-4) pour améliorer la qualité et la pertinence des réponses.

Petit rappel de ce qu’est le RAG… Le RAG consiste simplement à ajouter des connaissances à un LLM existant dans le prompt d’input. Il est surtout utile pour des données privées ou des sujets avancés que le LLM n’a peut-être pas vus pendant son entraînement. Dans sa configuration la plus simple, on « injecte » de l’information supplémentaire avec le prompt afin qu’elle serve à formuler une meilleure réponse.

Alors, pourquoi l’évaluation est-elle importante? Évaluer et optimiser efficacement les systèmes fondés sur des LLMs peut faire la différence entre une jolie démo et un outil ou produit LLM très utile et digne de confiance. Que vous développiez un bot de service à la clientèle ou un outil de recherche, une bonne évaluation vous aidera à créer des solutions d’IA plus fiables et efficaces qui peuvent réellement être déployées en production.

Par exemple, si vous construisez un outil de recherche juridique avec du RAG, il devra être approprié au contexte et à jour. Vous ne pouvez pas simplement présumer qu’il fonctionnera bien. Une évaluation rigoureuse doit assurer une bonne interprétation du jargon juridique et de l’information pertinente.

Vous vous dites peut-être : « J’ai testé l’application et les réponses semblent bonnes! »

Tester vous-même l’application est très important. Vous devez l’essayer, ce qu’on appelle le « vibe checking », mais ça ne dit pas tout. Nous avons besoin de méthodes et de métriques plus rigoureuses pour nous assurer que les applications de LLMs fonctionnent de façon optimale.

Comme nous l’avons dit, les systèmes RAG comportent deux composants distincts à évaluer : le composant de recherche et le composant de génération de réponses.

Voyons comment évaluer les deux, en commençant par les métriques les plus pertinentes… Nous parlerons dans quelques minutes du pipeline global, y compris du dataset nécessaire.

Les métriques de recherche mesurent la capacité du système à récupérer de l’information pertinente dans sa base de connaissances. Vous avez donc votre dataset et voulez savoir si le système trouve l’information la plus utile pour répondre à la question d’un utilisateur. Vous pourriez utiliser quatre métriques pour le vérifier :

1. La première est la précision. Elle mesure la proportion de documents pertinents parmi ceux qui ont été récupérés. Elle est particulièrement utile lorsqu’on veut s’assurer que l’information récupérée par le système est très pertinente, par exemple dans un outil de diagnostic médical où les faux positifs pourraient être dangereux.
2. Vient ensuite le rappel. Il mesure la proportion de documents pertinents récupérés avec succès. Il est essentiel dans les scénarios où rater une information importante pourrait coûter cher, comme en recherche juridique, où négliger un précédent pertinent pourrait influencer l’issue d’une affaire.
3. Nous avons ensuite le Hit Rate (taux de succès). Il mesure la proportion de requêtes pour lesquelles au moins un document pertinent figure parmi les premiers résultats. Il reflète la capacité du système de recherche à trouver tout simplement des documents pertinents.
4. L’une des métriques les plus utilisées est le Mean Reciprocal Rank (MRR). Elle évalue à quelle hauteur le premier document pertinent apparaît dans les résultats de recherche. Elle est utile pour les systèmes où les utilisateurs se concentrent généralement sur les premiers résultats, comme un moteur de recherche Web.
5. Enfin, nous pouvons utiliser le Normalized Discounted Cumulative Gain (NDCG). Cette métrique tient compte à la fois de la pertinence et du classement des documents récupérés. Elle est particulièrement utile pour les systèmes de recommandation ou toute application où l’ordre des résultats compte.

Le MRR est utile pour évaluer les systèmes où le rang du premier document pertinent compte le plus, comme les moteurs de recherche, par exemple les 1 à 3 premiers résultats Google. Le NDCG fournit une mesure plus globale de la qualité du classement en tenant compte de la pertinence et de l’ordre de tous les documents. Il convient donc parfaitement aux applications comme les systèmes de recommandation, où toute la liste compte, par exemple un top 10.

Vous pouvez ensuite utiliser ces cinq métriques pour mesurer la capacité de votre système RAG à trouver l’information pertinente à joindre au prompt envoyé au LLM. La deuxième étape consiste à évaluer la réponse du LLM avec des métriques de génération. Nous en avons trois principales :

1. Fidélité : la fidélité mesure l’intégrité de la réponse par rapport aux contextes récupérés. Elle garantit que la réponse générée reflète précisément l’information des documents récupérés sans introduire d’information fausse ou sans rapport.
2. Pertinence de la réponse : elle évalue la pertinence de la réponse générée par rapport à la requête initiale. Elle aide à vérifier que le système ne récupère pas seulement des documents pertinents, mais utilise aussi cette information pour générer des réponses appropriées.
3. Exactitude de la réponse : l’exactitude évalue si la réponse générée correspond à la réponse de référence pour une requête donnée. Elle est particulièrement utile lorsqu’on dispose d’un ensemble de réponses ground truth pour la comparaison.

D’accord, tout cela est bien beau. Nous avons des métriques pour évaluer notre LLM, mais il nous faut ensuite un dataset sur lequel les exécuter. On peut créer un dataset d’évaluation en faisant appel à des experts du domaine, en utilisant ses propres connaissances lorsqu’on possède l’expertise nécessaire, ou même en demandant à un LLM puissant de générer des questions complexes et riches en contexte à partir des données indexées. N’oubliez pas de réviser et d’améliorer ces questions pour qu’elles reflètent des cas d’utilisation réels. L’objectif est essentiellement de générer des questions artificielles, ou idéalement réelles, dont la réponse se trouve dans vos données. Vous pouvez ensuite vérifier, à l’aide des métriques abordées, si la réponse fournie exploite les bonnes données et correspond au résultat attendu.

Maintenant, qu’en est-il des réponses? En supposant que nous avons récupéré la bonne information pour répondre à la question, comment juger si la génération est bonne? L’une des nouvelles approches intéressantes consiste à utiliser un autre LLM comme juge, guidé par les métriques de génération. Cette approche peut être très efficace, mais il est important de suivre quelques bonnes pratiques :

1. Premièrement, lorsqu’un LLM évalue des outputs, il est souvent plus efficace de lui faire comparer deux réponses que d’en évaluer une seule de façon isolée. Cela lui donne une sorte de baseline pour déterminer si la deuxième réponse est meilleure. Cette méthode s’appelle la comparaison par paires et fournit généralement un benchmark de qualité plus clair.
2. Lorsque vous présentez des paires de réponses au LLM juge, vous devez toutefois randomiser leur ordre. Les LLMs sont sensibles à un biais d’ordre, par exemple en favorisant toujours la première option.
3. Vous devez aussi permettre les égalités. Deux réponses peuvent être aussi bonnes l’une que l’autre. Donnez au LLM juge la possibilité de les déclarer de qualité égale. Vous obtiendrez ainsi des évaluations plus nuancées.
4. Le meilleur conseil consiste à utiliser une approche Chain-of-Thought et à demander au LLM d’expliquer son raisonnement avant de prendre une décision finale. Cela peut produire des évaluations plus fiables et interprétables. Puisque les LLMs génèrent un seul token ou mot à la fois, ils ne pensent pas comme nous. Ils n’ont pas une sorte de carte mentale de ce qu’ils diront ni de la structure de leur réponse. Ils construisent le tout à la volée. Leur demander de procéder étape par étape, ou même d’écrire d’abord un plan d’action, place ce plan dans leur contexte. Celui-ci agit comme une sorte de réflexion artificielle avant la génération de la réponse finale et améliore beaucoup les résultats et l’évaluation.
5. Notre dernier conseil est de tenter de comparer des réponses de longueur semblable. La comparaison est ainsi plus équitable, puisque la longueur peut parfois influencer injustement la qualité perçue.

En combinant ces évaluations fondées sur les LLMs aux métriques de recherche traditionnelles, nous obtenons une vue plus complète des performances de notre système RAG qui couvre à la fois la recherche et la génération. Chaque modification, fonctionnalité ou prompt peut ensuite être associé à un changement quantitatif, accompagné d’une vérification qualitative indispensable pour toujours prendre le pouls du système.

Ces métriques et votre propre vibe checking ne suffisent toutefois pas. Nous devons tenir compte du contexte plus large dans lequel notre système RAG est utilisé. Cela nous amène à un point critique souvent négligé : l’importance de comprendre les véritables besoins de vos utilisateurs.

L’une des façons les plus efficaces d’y arriver consiste à journaliser et à analyser les requêtes des utilisateurs. En implémentant un système de journalisation, vous pouvez enregistrer chaque question posée à votre système RAG. Vous pouvez ensuite analyser ces questions avec des techniques comme le regroupement par sujets afin de repérer les thèmes et les patterns courants.

Par exemple, nous avons construit une application de LLM pour un client. Après avoir analysé les requêtes des utilisateurs, l’entreprise a finalement découvert que 80 % des questions portaient sur un sous-ensemble précis de sujets. Cette observation lui a permis de concentrer ses efforts d’optimisation là où ils auraient le plus d’impact. Vous pouvez adapter vos datasets d’évaluation à ces sujets fréquents afin que votre système fonctionne particulièrement bien sur les requêtes qui comptent le plus pour vos utilisateurs. Il devient aussi beaucoup plus facile d’en faire le vibe check que d’essayer de vérifier tout l’ensemble des questions possibles.

Vous avez maintenant votre raison d’évaluer, vos métriques et des façons d’automatiser le processus. Que reste-t-il? La prochaine étape consiste à l’implémenter.

Nous suggérons d’utiliser des librairies comme Ragas pour automatiser votre processus d’évaluation et le mettre à l’échelle. Ne codez pas tout vous-même! Ces outils peuvent vous aider à mesurer différents aspects des performances de votre système RAG, dont la qualité de la recherche et de la génération, ainsi que toutes les métriques mentionnées dans l’article.

Enfin, n’oubliez pas l’évaluation humaine. Les métriques automatisées et les évaluations fondées sur les LLMs sont précieuses et plus faciles à mettre à l’échelle, mais le jugement humain demeure la référence absolue, surtout pour évaluer la fluidité, le naturel des réponses et leur utilité globale dans des scénarios réels. Comme nous l’avons dit, vos utilisateurs sont les mieux placés pour le faire, au moyen de tests A/B ou en rémunérant des personnes pour cette tâche.

Vous possédez maintenant les outils nécessaires pour aller au-delà des métriques de base et vraiment comprendre les performances de votre système RAG dans des scénarios réels, en vous concentrant sur les sujets qui comptent le plus pour vos utilisateurs.

Je vous invite à consulter notre cours sur les architectures RAG avancées. Nous y abordons des techniques comme le reranking, l’expansion de requêtes et bien plus encore pour construire des systèmes RAG de pointe, de l’implémentation de base aux techniques d’optimisation avancées.

FAQ

Pourquoi évaluer la recherche séparément de la génération?

Une bonne réponse est impossible si le système de recherche rate les preuves, tandis que le modèle peut tout de même mal utiliser une recherche solide.

Que devrait contenir un dataset d’évaluation du RAG?

Utilisez des questions représentatives, les preuves attendues, des critères de réponse, des exemples négatifs difficiles et des cas où le système devrait s’abstenir.

Quelles qualités de la recherche devraient être mesurées?

Mesurez la présence des passages pertinents, leur rang, le bruit dans le contexte et la couverture des faits nécessaires.

Comment un LLM juge peut-il aider?

Un juge calibré peut noter des qualités sémantiques que les métriques de correspondance exacte des chaînes ratent, avec une vérification humaine sur un échantillon.

Pourquoi randomiser l’ordre des réponses dans un jugement par paires?

La randomisation réduit le biais de position, où le juge favorise la première ou la deuxième réponse sans égard à sa qualité.

Pourquoi un simple vibe check d’une application RAG ne suffit-il pas?

Quelques exemples manuels peuvent sembler bons tout en cachant des échecs systématiques de recherche ou de génération. Il faut donc un dataset représentatif et des métriques reproductibles.