Évaluer la génération augmentée par récupération (RAG) : tout ce que vous devez savoir
Introduction
La génération augmentée par récupération (RAG) est devenue une approche largement adoptée pour mettre en œuvre des applications d’IA générative alimentées par des grands modèles de langage (LLMs). En intégrant des sources de connaissances externes, la RAG améliore la capacité du modèle à fournir des réponses plus précises et contextuellement pertinentes à des requêtes spécifiques. Malgré son potentiel, les réponses générées par la RAG ne sont pas toujours entièrement exactes ni cohérentes avec les connaissances récupérées.
Lors d’un récent webinaire, Stefan Webb, Developer Advocate chez Zilliz, a exploré les stratégies d’évaluation des applications RAG, en se concentrant sur les méthodes permettant d’évaluer les performances des LLM et en abordant les défis et limites actuels dans ce domaine.
Dans ce blog, nous récapitulerons les principaux enseignements de Stefan, notamment un aperçu des différentes architectures de pipelines RAG, des cadres de récupération et d’évaluation, ainsi que des exemples de biais et d’échecs dans les LLM.
Architecture RAG
Stefan a commencé son intervention en présentant le concept fondamental de recherche sémantique, un composant essentiel des applications RAG. La recherche sémantique s’appuie sur des bases de données vectorielles, telles que Milvus ou Zilliz, comme systèmes de stockage de bases de connaissances pour les plongements vectoriels. Ces bases de données permettent une recherche efficace dans des données non structurées afin de récupérer des contextes sémantiquement similaires pertinents par rapport à la requête d’un utilisateur. Cette capacité constitue l’épine dorsale des systèmes RAG, garantissant que les connaissances récupérées correspondent étroitement à la question saisie, améliorant ainsi la qualité des réponses générées.
La Figure 1 ci-dessous illustre une architecture RAG de base, naïve. Dans cette configuration, le système récupère les documents les plus pertinents en fonction de leur similarité sémantique avec la question de l’utilisateur. Les informations récupérées sont ensuite mises en forme dans une invite structurée, accompagnée d’instructions, puis transmises au LLM. Le modèle utilise ce contexte pour générer une réponse bien informée.
Figure 1 : RAG naïve
Figure 1 : RAG naïve
Bien que le pipeline RAG de base puisse récupérer des documents pertinents et générer des réponses, ses performances ne sont pas toujours optimales. Certaines sorties peuvent manquer d’exactitude ou de pertinence. Pour relever ces défis, une approche modulaire de la construction du pipeline RAG permet des améliorations incrémentales à chaque étape.
Ci-dessous (comme illustré dans la Figure 2) figurent les techniques clés qui peuvent améliorer l’efficacité du pipeline.
Figure 2 : Architecture modulaire RAG
Figure 2 : Architecture modulaire RAG (Source)
Traduction des requêtes
Cette étape vise à garantir que la requête de l’utilisateur est correctement comprise par le système. Elle traduit les requêtes dans un format ou une représentation qui s’aligne sur le mécanisme de récupération sous-jacent.
Multi-query : Divise la requête principale en plusieurs sous-requêtes ciblées afin de récupérer des informations diverses mais pertinentes.
Step-back : Revient sur les étapes précédentes du pipeline lorsque les résultats trouvés sont insuffisants, en affinant la requête pour une meilleure récupération.
RAG Fusion : Fusionne les résultats de plusieurs requêtes afin de fournir un contexte cohérent et complet au LLM.
Documents hypothétiques (HyDE) : Consiste à générer des documents synthétiques ou des contextes hypothétiques pouvant aider à récupérer des documents sémantiquement similaires depuis la base de connaissances, améliorant la récupération pour les requêtes abstraites ou mal formulées.
Routage des requêtes
L’approche de routage des requêtes dirige la requête vers le mécanisme de récupération ou la source de connaissances le plus approprié.
Routage logique : Achemine les requêtes selon des règles prédéfinies ou des opérateurs logiques, comme le filtrage par métadonnées ou par domaine.
Routage sémantique : Dirige les requêtes selon leurs caractéristiques sémantiques vers la base de données ou le système le plus adapté pour les traiter.
Construction des requêtes
La construction des requêtes affine la manière dont les requêtes sont formulées afin de correspondre à la structure des bases de données sous-jacentes.
Base de données relationnelle : Construit des requêtes de type SQL pour les bases de données relationnelles traditionnelles.
Base de données graphe : Utilise des requêtes Cypher de parcours de graphe pour explorer les nœuds et les relations dans les bases de données graphes.
Base de données vectorielle : Exploite les embeddings pour créer des requêtes vectorisées destinées aux recherches de similarité sémantique.
Indexation
L’indexation améliore l’organisation et l’accessibilité de la base de connaissances.
Optimisation des chunks : Divise les documents en chunks significatifs et récupérables tout en préservant le contexte.
Indexation multi-représentations : Crée plusieurs représentations (par exemple, sémantique, syntaxique) des données pour répondre à divers besoins de récupération.
Embeddings spécialisés : Utilise des embeddings propres à un domaine pour améliorer la récupération d’informations hautement spécialisées ou techniques.
Indexation hiérarchique : Structure l’index de manière hiérarchique pour des recherches plus rapides et plus précises.
Récupération
Récupère les documents ou contextes les plus pertinents pour une requête donnée à l’aide de techniques avancées.
Classement : Attribue un score aux documents récupérés en fonction de leur pertinence, en veillant à prioriser les meilleures correspondances.
RAG correctif : Ajuste le classement en fonction des retours ou de critères supplémentaires afin d’améliorer les résultats de manière dynamique.
Nouvelle récupération : Récupère itérativement des documents si les résultats initiaux ne répondent pas aux attentes de qualité, en affinant le processus jusqu’à ce qu’un résultat acceptable soit trouvé.
Cette approche modulaire de la création d’un pipeline RAG affine chaque composant indépendamment. En répondant aux défis spécifiques à chaque étape, le pipeline devient plus robuste, précis et adaptable, améliorant au final la qualité des sorties générées.
Évaluation des modèles de fondation
Qu’une approche RAG naïve ou avancée soit utilisée, l’évaluation des performances de chaque application RAG est essentielle. Cette évaluation aide à identifier les forces et les faiblesses, garantissant la fiabilité et la pertinence du système. Tous les LLM, quel que soit leur niveau de sophistication, nécessitent une évaluation rigoureuse des performances afin de traiter les limitations, biais et inexactitudes potentiels.
Évaluation des performances
Mais comment mesurer et évaluer les performances du modèle ? Mesurer les performances d’une application RAG nécessite une approche nuancée, car différents aspects du pipeline doivent être évalués. Voici les principales considérations et méthodes pour une mesure efficace des performances :
Évaluation sur une tâche vs évaluation intrinsèque
Évaluation des tâches : Mesure les performances du modèle sur un ensemble prédéfini de tâches, qui incluent souvent des scénarios multi-tours (par exemple, MT-Bench) ou multitâches (par exemple, MMLU). Chaque tâche est associée à des questions de vérité terrain spécifiques et à des réponses de référence.
Auto-évaluation : Se concentre sur les métriques de performance internes, telles que l’efficacité avec laquelle le modèle récupère et traite les informations sans nécessairement les relier à un cas d’utilisation pratique. Cela est utile pour diagnostiquer les performances du pipeline.
Comparer les réponses à la vérité terrain vs. au contexte
Comparaison à la vérité terrain : Évalue dans quelle mesure la réponse générée correspond à une réponse prédéfinie et exacte (vérité terrain). Cette approche fonctionne bien pour les tâches objectives comme les requêtes fondées sur des faits.
Comparaison contextuelle : Examine dans quelle mesure la réponse s’aligne sur le contexte fourni par les documents récupérés. Cela est particulièrement important pour les tâches où la vérité terrain est indisponible ou subjective, en mettant l’accent sur la cohérence et la pertinence.
Évaluer la récupération vs. évaluer la sortie du LLM
Évaluation de la récupération : Se concentre sur la qualité des documents récupérés par le pipeline. Les métriques peuvent inclure le rappel et la précision entre les documents récupérés et la requête.
Évaluation de la sortie du LLM : Examine la qualité de la sortie finale générée par le modèle de langage, en tenant compte de facteurs tels que la cohérence factuelle et la pertinence par rapport à la requête et au contexte récupéré.
L’évaluation humaine comme « référence absolue »
- L’évaluation humaine reste la méthode la plus fiable pour évaluer les performances, en particulier pour les tâches subjectives ou complexes. Les humains peuvent évaluer des aspects nuancés tels que la cohérence logique, le ton et la créativité. Cependant, cette approche passe mal à l’échelle en raison de ses exigences en temps et en ressources.
Utiliser des LLMs pour évaluer des LLMs (LLM-as-a-Judge)
- Des LLMs plus avancés et efficaces (LLM-as-a-Judge) peuvent être employés pour évaluer les sorties d’autres LLMs, en particulier lorsque la vérité terrain est indisponible. Ces modèles peuvent noter les réponses selon des critères prédéfinis comme la pertinence et l’exactitude, offrant une alternative évolutive à l’évaluation humaine. Toutefois, il faut veiller à éviter d’introduire des biais provenant du modèle évaluateur lui-même.
Stefan a poursuivi la discussion en abordant deux approches de l’évaluation : l’évaluation basée sur les tâches et l’auto-évaluation. L’évaluation basée sur les tâches s’appuie généralement sur des benchmarks publiquement disponibles, tandis que l’auto-évaluation se concentre davantage sur des mesures internes ou l’introspection, comme l’examen de la qualité des réponses générées et de la pertinence des informations récupérées.
Évaluation basée sur les tâches : l’approche par benchmark
L’évaluation basée sur les tâches repose sur l’utilisation de benchmarks standards, publiquement disponibles, qui évaluent les performances du modèle sur une variété de tâches. Ces benchmarks couvrent souvent différents domaines de connaissances, les capacités de question-réponse et les compétences conversationnelles. Voici quelques exemples :
Benchmarks basés sur les connaissances : Ces benchmarks se concentrent sur les connaissances générales et la réponse à des questions fondées sur des faits.
MMLU : Un benchmark diversifié qui teste les modèles de langage dans plusieurs domaines, notamment les mathématiques, les sciences et l’histoire.
HellaSwag : Un benchmark conçu pour mesurer le raisonnement de sens commun.
ARC : Un benchmark axé sur la réponse aux questions avec des capacités de raisonnement.
Benchmarks de suivi d’instructions : Ces benchmarks évaluent la capacité du modèle à suivre des instructions et à générer des réponses pertinentes.
Flan : Une série de tâches qui évaluent les capacités de suivi d’instructions dans les LLMs.
Self-instruct : Évalue la capacité du modèle à générer et à suivre des instructions auto-générées.
NaturalInstructions : Un benchmark à grande échelle axé sur la capacité du modèle à suivre des instructions en langage naturel.
Benchmarks conversationnels : Ces benchmarks évaluent la capacité du modèle à participer à un dialogue cohérent et pertinent.
CoQA : Un jeu de données de question-réponse conversationnelle qui teste les modèles sur des dialogues à plusieurs tours.
MMDialog : Un benchmark conversationnel qui se concentre sur la qualité du dialogue dans divers scénarios.
OpenAssistant : un benchmark d’IA conversationnelle qui évalue la capacité du modèle à tenir des conversations naturelles.
Bien que les benchmarks fournissent des critères d’évaluation standardisés, ils ne parviennent souvent pas à saisir les nuances de l’interaction humaine, telles que l’intelligence émotionnelle, la fluidité conversationnelle et la sensibilité au contexte. Par exemple, une réponse peut être factuellement correcte selon un benchmark, mais néanmoins insuffisante en termes de naturel ou d’empathie, des éléments clés que les humains valorisent dans les conversations réelles. En outre, les benchmarks peuvent ne pas toujours refléter la complexité des préférences humaines, qui peuvent varier selon le contexte, l’intention de l’utilisateur et le ton émotionnel. C’est pourquoi l’évaluation humaine reste une « référence absolue » pour évaluer l’IA conversationnelle, car elle prend en compte les préférences humaines que les benchmarks négligent souvent. Cependant, en raison du coût et de la forte consommation de ressources qu’implique l’évaluation humaine, des méthodes alternatives, telles que l’évaluation fondée sur l’introspection, peuvent être envisagées comme des options plus évolutives.
Évaluation fondée sur l’introspection
L’évaluation fondée sur l’introspection se concentre sur l’évaluation de la qualité des réponses générées par le modèle et de leur alignement avec le contexte, dans le but de mesurer dans quelle mesure les sorties du modèle respectent les attentes définies par l’entrée. Ce type d’évaluation peut être divisé en deux grandes catégories : Évaluation fondée sur la génération et Évaluation fondée sur la récupération. Voici quelques exemples de métriques pertinentes :
Évaluation fondée sur la génération
Fidélité (Ancrage factuel) : Cette métrique mesure la cohérence factuelle de la réponse générée par rapport au contexte donné. Si le modèle génère des affirmations qui ne peuvent pas être étayées par le contexte récupéré, ces affirmations sont pénalisées. La fidélité garantit que la sortie du modèle est à la fois cohérente et ancrée dans les informations fournies.
Pertinence de la réponse : Cette métrique évalue dans quelle mesure la réponse répond directement à la question de l’utilisateur ou au contexte donné. Une réponse très pertinente sera à la fois exacte et appropriée au contexte, fournissant la réponse la plus utile à la requête.
Évaluation fondée sur la récupération
Pertinence du contexte : Mesure dans quelle mesure les documents ou contextes récupérés sont pertinents pour la requête. Idéalement, le contexte récupéré ne devrait contenir que les informations nécessaires pour répondre à la question. Les informations non pertinentes ou superflues peuvent réduire la qualité de la réponse générée.
Rappel du contexte : Cette métrique évalue dans quelle mesure le contexte récupéré s’aligne avec la vérité terrain, souvent en utilisant des réponses annotées comme référence. Elle aide à évaluer si les documents pertinents ont bien été récupérés en premier lieu, garantissant que le modèle dispose de suffisamment d’informations pour générer une réponse significative.
Pour les métriques de Fidélité, de Pertinence de la réponse et de Pertinence du contexte, l’absence de vérité terrain représente un défi pour l’évaluation directe. Cependant, en l’absence de vérité terrain, une méthode alternative consiste à utiliser un LLM-as-a-Judge. Un LLM performant peut être utilisé pour noter ces aspects en analysant la cohérence, la pertinence et l’ancrage factuel de la réponse. En comparant les réponses générées à sa propre compréhension du contexte et de la pertinence, le modèle peut fournir une évaluation automatisée.
Défis et limites de LLM-as-a-Judge
Bien que l’utilisation d’un LLM-as-a-Judge puisse constituer une alternative utile pour évaluer des métriques lorsque la vérité terrain n’est pas disponible, cette approche introduit certains défis et limites qui doivent être traités. Le modèle évaluateur lui-même peut introduire des biais, susceptibles d’affecter la qualité et l’équité de l’évaluation. Voici quelques biais et défis courants qui doivent être pris en compte.
Biais de position
Le biais de position désigne la tendance du modèle évaluateur à favoriser les réponses en fonction de leur position dans le classement ou de l’ordre dans lequel elles apparaissent. Dans de nombreux cas, le modèle peut supposer que la première réponse ou celle qui est la mieux classée est plus pertinente ou plus exacte, quelle que soit sa qualité réelle. Cela peut conduire à des évaluations inexactes, en particulier dans les cas où la bonne réponse est classée plus bas en raison du biais du modèle en faveur des premières positions du classement.
Figure 3 : Biais de position
Figure 3 : Biais de position (Source)
Biais de verbosité
Le biais de verbosité se produit lorsque le modèle évaluateur tend à favoriser les réponses plus longues et plus détaillées, même si celles-ci ne sont pas nécessairement plus exactes ou pertinentes. Dans certains cas, le modèle peut assimiler à tort la verbosité à la qualité, en attribuant des scores plus élevés aux réponses plus longues contenant des informations inutiles. Cela peut fausser le processus d’évaluation, en particulier dans les contextes où des réponses concises et claires sont plus souhaitables.
Figure 4 : Biais de verbosité
Figure 4 : Biais de verbosité (Source)
Jugement erroné
Une autre limite est la possibilité de jugements erronés. Un LLM-as-a-Judge, comme tout modèle, peut commettre des erreurs lorsqu’il évalue la qualité ou la pertinence d’une réponse. Par exemple, il peut mal interpréter le contexte, négliger des détails subtils ou ne pas reconnaître les nuances de la réponse, ce qui entraîne des résultats d’évaluation incorrects ou trompeurs
Figure 5 : Jugement erroné
Figure 5 : Jugement erroné (Source)
Jugement erroné avec Chain-of-Thought
Le raisonnement Chain-of-Thought (CoT) dans l’évaluation fondée sur les LLM introduit des mécanismes complexes de propagation des erreurs qui peuvent compromettre considérablement la précision de l’évaluation. Chaque étape intermédiaire du raisonnement agit comme un point de défaillance potentiel, où même une mauvaise interprétation mineure ou une incohérence logique peut se transformer en erreurs de plus en plus importantes dans le jugement final. Par exemple, si une étape précoce de la chaîne de raisonnement comprend mal une nuance contextuelle clé ou pondère incorrectement un aspect particulier de la réponse, les étapes de raisonnement suivantes s’appuieront sur cette base défectueuse, amplifiant exponentiellement l’erreur initiale.
Figure 6 : Jugement erroné avec Chain-of-thought
Figure 6 : Jugement erroné avec Chain-of-thought (Source)
Ces biais soulignent l’importance d’adopter des stratégies d’évaluation qui tiennent compte des limites des approches LLM-as-a-Judge. Une solution consiste à utiliser des modèles LLM spécialement affinés à des fins d’évaluation, tels que GroundedAI, ou Flow-Judge-v0.1. Une autre stratégie consiste à combiner les évaluations LLM-as-a-Judge avec des évaluations humaines lorsque cela est possible. Les évaluateurs humains apportent une compréhension nuancée et une conscience contextuelle qui peuvent faire défaut aux modèles automatisés. Des audits réguliers et des améliorations itératives des modèles évaluateurs sont également essentiels pour minimiser les biais et renforcer la fiabilité.
Cadres d’évaluation open source
En plus des techniques LLM-as-a-Judge, plusieurs cadres d’évaluation open source sont largement utilisés sur le marché pour évaluer les applications RAG. Ces cadres fournissent des méthodologies structurées et des outils permettant d’évaluer efficacement les performances de récupération et de génération :
RAGAS : Un cadre pour évaluer les systèmes RAG avec des métriques adaptées aux applications RAG.
DeepEval : un outil flexible et robuste pour évaluer les systèmes RAG ou de fine-tuning selon plusieurs métriques d’évaluation.
ARES : conçu pour l’évaluation des modèles RAG, en mettant l’accent sur la pertinence du contexte, la fidélité de la réponse et la pertinence de la réponse.
HuggingFace Lighteval : fournit des outils légers et extensibles pour évaluer les applications RAG sur plusieurs backends (p. ex., transformers, tgi, vllm ou nanotron).
Ces frameworks simplifient le processus d’évaluation et aident à standardiser les métriques de performance entre différents systèmes, favorisant la comparabilité et l’amélioration.
Conclusion
La génération augmentée par récupération (RAG) est une approche transformatrice pour renforcer les capacités des grands modèles de langage (LLM). Cependant, son succès repose sur une évaluation robuste et un affinage continu. Comme Stefan l’a souligné dans le webinaire, le pipeline RAG est complexe, englobant plusieurs étapes allant de la traduction des requêtes à la génération de la réponse finale. Les défis sont considérables — allant de l’atténuation des biais dans les évaluations LLM-as-a-Judge à la garantie d’une récupération précise et à la génération de réponses qui répondent aux attentes des utilisateurs.
Le principal enseignement est qu’il n’existe pas de solution universelle pour l’évaluation de RAG. Réussir nécessite une approche nuancée et multidimensionnelle qui combine diverses techniques d’évaluation : benchmarks basés sur les tâches, métriques introspectives, frameworks d’évaluation open source et — lorsque cela est faisable — évaluation humaine. Des outils comme RAGAS, DeepEval et ARES offrent un soutien précieux, mais ils ne constituent pas des réponses définitives. Ils représentent plutôt des outils en évolution dans le paysage en constante progression de l’IA générative.
À l’avenir, l’avenir de RAG réside dans son adaptabilité et son affinage continu. À mesure que les systèmes d’IA deviennent plus sophistiqués, la capacité à évaluer et à améliorer leurs performances sera essentielle pour libérer tout leur potentiel. En s’attaquant aux limites actuelles et en adoptant des méthodes d’évaluation innovantes, les applications RAG peuvent fournir de manière constante des informations exactes, contextuellement pertinentes et fiables, stimulant ainsi les progrès dans le domaine de l’IA.
Lectures complémentaires
Techniques RAG avancées : faire le lien entre texte et visuels
Qu’est-ce que GraphRAG ? Améliorer RAG avec les graphes de connaissances
ColPali : récupération efficace de documents avec des modèles vision-langage
Le paysage de l’écosystème GenAI : au-delà des LLM et des bases de données vectorielles
Modèles d’IA les plus performants pour vos applications GenAI | Zilliz
Créez des applications d’IA avec Milvus : tutoriels et notebooks
Continuer à lire
What Is a Vector Lakebase?
A Vector Lakebase is a unified, lake-native data architecture for AI that combines vector-database-grade serving with open lake storage, reusable lake-level indexes, and a shared semantic layer.
Announcing the General Availability of Zilliz Cloud BYOC on Google Cloud Platform
Zilliz Cloud BYOC on GCP offers enterprise vector search with full data sovereignty and seamless integration.
Demystifying the Milvus Sizing Tool
Explore how to use the Sizing Tool to select the optimal configuration for your Milvus deployment.