Évaluation d'un RAG : comment faire ?

Pour garantir l'efficacité d’un système RAG, il est primordial de disposer de méthodes d’évaluation robustes et adaptées. Ces évaluations permettent non seulement d’identifier les faiblesses des différent composants du système (notamment du retriever et du générateur), mais aussi d’optimiser ses performances globales.

L'évaluation d'un RAG est primordiale pour deux raisons : tout d'abord, elle permet de s'assurer que le système qui sera déployé en production, répond à des exigences minimales en termes de performances et de fiabilité des résultats. D'autre part, elle aide également les développeurs à suivre l'évolution de la performance du RAG entre deux versions successives.

Ce dernier point est important, car un système RAG n'est pas un seul bloc monolithe, mais une sucession d'étapes et de composants (processing, chunking, embedding, retriever, génération), dont chacun disposent de paramètres qu'il faut adapter.

Dans ce contexte, des librairies logicielles comme RAGAS offrent des outils d’évaluation spécialement conçus pour les applications basées sur les LLMs y compris les systèmes RAG, fournissant des métriques précises pour analyser et améliorer leurs performances.

Dans cet article, nous allons utiliser plusieurs métriques et la librairie RAGAS pour analyser les performances de récupération et de génération de notre système RAG.

Comment évaluer un RAG ?

L’évaluation des systèmes RAG constitue un défi complexe et multifacette, contrairement aux systèmes traditionnels de Machine Learning, où des métriques bien définies (comme la précision ou la matrice de confusion) suffisent souvent.

Les systèmes RAG produisent des réponses sous forme de texte non structuré, nécessitant une analyse à plusieurs niveaux. Cette analyse doit intégrer à la fois la qualité de la récupération des documents (retriever) et celle des réponses générées (generator), car un défaut dans l’un des composants peut entraîner une dégradation de la performance globale.

Prenons un exemple concret : imaginons un assistant juridique basé sur un système RAG. Lorsqu’un utilisateur demande Quels articles du Code civil régissent les contrats de travail ?, le retriever doit non seulement localiser les sections pertinentes du Code civil, mais ces résultats doivent également servir de base pour que le générateur formule une réponse cohérente, fidèle et directement exploitable. Si le retriever échoue à fournir les bons articles, le générateur pourrait produire une réponse incorrecte ou hors contexte, même s’il est performant.

Ainsi, l’évaluation des systèmes RAG repose sur deux axes principaux.

Évaluation de la récupération d’informations : Le retriever joue un rôle fondamental en filtrant l’ensemble des données disponibles pour extraire les documents pertinents. Son efficacité se mesure à sa capacité à identifier les informations clés nécessaires à la génération d'une réponse précise et complète.
Évaluation des réponses générées : Une fois les documents récupérés, le générateur doit produire des réponses exploitables et vérifiables. Cela nécessite de mesurer deux aspects principaux.
- Fidélité (ou ancrage) : Les réponses doivent être basées sur les documents fournis, sans inventer d'informations.
- Pertinence : Une bonne réponse doit non seulement être factuelle, mais aussi répondre directement à la requête.

Le framework TRIAD pour l'évaluation d'un RAG

L’évaluation des systèmes RAG peut être structurée autour du framework TRIAD, qui organise les analyses en trois dimensions complémentaires. Ce cadre aide à examiner à la fois les performances du retriever et du générateur tout en considérant leur interdépendance dans le processus global.

Pertinence du contexte (côté retriever) : Cette dimension évalue la capacité du retriever à fournir des documents précis et pertinents. Il ne s’agit pas seulement de retrouver des documents liés à la requête, mais aussi de s’assurer que ces documents apportent une valeur ajoutée au processus de génération. Par exemple, dans un système de support technique, si un utilisateur cherche à résoudre un problème avec une imprimante, le retriever doit extraire des guides ou des articles correspondant précisément au modèle de l’appareil en question.
Fidélité ou ancrage (côté générateur) : Cette dimension concerne la véracité des réponses générées. Une réponse est fidèle si elle s’appuie strictement sur les informations contenues dans les documents récupérés, sans inventer ni distordre les faits. Par exemple, un assistant médical basé sur un système RAG doit fournir des recommandations issues des recherches médicales citées et éviter des réponses qui ne peuvent être tracées à une source spécifique.
Pertinence de la réponse (générateur) : Enfin, cette dimension évalue dans quelle mesure la réponse produite est utile et alignée avec la question initiale. Par exemple, si un utilisateur demande "Quels sont les avantages des panneaux solaires ?", une réponse pertinente devrait se concentrer sur les bénéfices énergétiques et environnementaux, sans s’éloigner sur des aspects techniques sans rapport direct avec la question.

Le framework TRIAD offre ainsi une approche claire et cohérente pour analyser chaque étape du pipeline RAG, en s’assurant que le retriever fournit un contexte approprié et que le générateur produit des réponses factuelles et utiles. Ce cadre permet également d’identifier les points faibles du système, qu’il s’agisse d’un manque de précision dans la récupération des informations ou d’un problème de cohérence dans la génération des réponses.

Évaluation du retriever

Pour évaluer la qualité du retriever dans un système RAG, il est essentiel d'utiliser des métriques spécifiques qui tiennent compte du fonctionnement des retrievers sur des extraits ou des contextes extraits d'une base de données. Ces métriques, comme la Context Precision et la Context Recall, permettent d'évaluer non seulement la pertinence des documents récupérés, mais aussi leur couverture par rapport aux informations nécessaires.

Context Precision

La Context Precision@K mesure la proportion de contextes pertinents parmi les résultats récupérés dans les $k$ premiers rangs, en pondérant chaque résultat par sa précision à ce rang.

Dans le contexte des systèmes RAG, "rang" (ou rank en anglais) fait référence à la position d'un élément dans une liste ordonnée de résultats récupérés par le retriever. Lorsqu'un retriever effectue une recherche, il renvoie une liste de documents ou de contextes triés selon leur pertinence estimée par rapport à la requête. Le rang représente l'ordre dans lequel ces documents apparaissent dans la liste, en commençant par le plus pertinent.

Cette métrique est utile pour comprendre la qualité des résultats les plus prioritaires. La formule est donnée par :

$$ \text{Context Precision@K} = \frac{\displaystyle \sum_{k=1}^{K} \left( \text{Precision@k} \times v_k \right)}{\text{Total number of relevant items in the top } K \text{ results}} $$

Où :

Precision@K est la précision au rang k.
vk est une pondération qui indique si l’élément au rang k est pertinent vk = 1 ou non vk = 0.

Supposons que pour une requête donnée, le retriever retourne les 5 premiers contextes suivants :

Les résultats 1, 2 et 4 sont pertinents v1 = v2 = v4 = 1.
Les résultats 3 et 5 ne sont pas pertinents v3 = v5 = 0.

Si les valeurs de précision pour ces rangs sont respectivement 1.0, 0.75, 0.67, 0.5, 0.4, alors la Context Precision@5 est :

$$ \text{Context Precision@5} = \displaystyle \frac{(1.0 \times 1) + (0.75 \times 1) + (0.67 \times 0) + (0.5 \times 1) + (0.4 \times 0)}{\text{Total number of relevant items in top 5 results}} = \frac{2.25}{3} = 0.75 $$

Une haute Context Precision indique que le système produit des résultats prioritaires pertinents. Un tel niveau de précision est crucial, notamment dans des domaines comme le domaine médical, où l'inclusion de documents non pertinents pourrait induire des erreurs graves.

En pratique, on prendra souvent pour valeur de K entre 3 et 7.

Context Recall

Le Context Recall mesure la proportion de contextes pertinents présents dans les résultats récupérés, par rapport à l’ensemble des contextes pertinents disponibles. Elle met en évidence la capacité du retriever à ne manquer aucun élément important. La formule est donnée par :

$$ \text{Context Recall} = \frac{|\text{Nombre de contextes pertinents récupérés}|}{|\text{Nombre total de contextes pertinents de référence}|} $$

Imaginons qu'une base contienne 20 contextes pertinents pour une requête donnée, mais que le retriever en identifie seulement 15. La Context Recall serait alors :

$$ \text{Context Recall} = \frac{15}{20} = 0.75 $$

Une Context Recall élevée garantit que les résultats contiennent tous les éléments pertinents, ce qui est essentiel dans des scénarios où manquer une information critique pourrait compromettre les performances globales du système.

Il existe deux méthodes pour calculer le rappel dans l'évaluation d'un RAG.

Évaluation de la génération

Après avoir évalué l’efficacité du retriever, nous passons maintenant à l’évaluation de la génération. Cette étape est cruciale pour vérifier que les réponses générées par le modèle RAG répondent aux requêtes utilisateur avec précision et pertinence.

L'évaluation de la génération fait intervenir des métriques de LLM, qui sont par ailleurs utilisés de manière générale pour évaluer les performances d'un LLM, en dehors du contexte d'un RAG.

Dans cette partie, nous explorerons plusieurs métriques basiques avant de nous concentrer sur la notion de faithfulness avec le package RAGAS.

BLEU (Bilingual Evaluation Understudy)

Le score BleuScore est une métrique utilisée pour évaluer la qualité d'une réponse en la comparant à une référence. Il mesure la similarité entre la réponse et la référence en se basant sur deux éléments.

Précision des n-grammes : Cela mesure combien de séquences de mots (de taille n) présentes dans la réponse générée se retrouvent aussi dans la référence. Plus cette proportion est élevée, plus la réponse est proche de la référence.
Pénalité de longueur : Si la réponse générée est beaucoup plus courte que la référence, une pénalité est appliquée. Cela vise à éviter que le modèle ne produise des réponses courtes, mais incomplètes, pour améliorer artificiellement le score.

Initialement conçu pour évaluer les systèmes de traduction automatique, le score BLEU est également utilisé dans d'autres tâches de traitement du langage naturel. Ce score varie de 0 à 1, où 1 indique une correspondance parfaite entre la réponse et la référence. Il s'agit d'une métrique qui n'est pas basée sur les modèles LLM.

La formule de cette métrique est la suivante :

$$ \text{BLEU} = \text{BP} \cdot \exp\left(\sum_{n=1}^N w_n \log P_n\right) $$

avec

BP : Pénalité de brièveté (brevity penalty)
Pn : Précision des n-grammes.
wn : Poids attribué à chaque niveau de n-gramme.

Faithfulness

Les deux métriques BLEU et ROUGE présentés précédemment ne se basent pas sur un LLM pour vérifier la qualité de la génération : elle est donc très déterministe, et surtout très sémantique.

La métrique de fidélité (faithfulness) mesure la cohérence factuelle d'une réponse générée par rapport au contexte fourni. Elle évalue dans quelle mesure la réponse respecte les informations contenues dans le contexte.

Une réponse est considérée comme fidèle si toutes les affirmations faites dans la réponse peuvent être déduites du contexte donné. Autrement dit, la réponse ne doit pas introduire d'informations qui ne sont pas présentes ou qui contredisent le contexte.

Cette métrique est calculée de la manière suivante.

Identification des affirmations : les affirmations contenues dans la réponse générée sont extraites. Une affirmation est une déclaration ou une information spécifique présente dans la réponse.
Vérification par rapport au contexte : chaque affirmation est ensuite comparée au contexte fourni. L'objectif est de vérifier si cette affirmation peut être inférée à partir des informations contenues dans le contexte.
Calcul du score de fidélité : le score de fidélité est donné par la formule suivante :

$$ \text{Faithfulness Score} = \frac{\text{Nombre d'affirmations inférées du contexte}}{\text{Nombre total d'affirmations dans la réponse générée}} $$

Le score est normalisé dans une plage allant de 0 à 1.

0 : Aucune affirmation de la réponse ne peut être déduite du contexte (non fidèle).
1 : Toutes les affirmations de la réponse sont cohérentes avec le contexte (totalement fidèle).

Prenons un exemple.

Question : Quels sont les principaux risques du changement climatique selon le rapport de l'IPCC ?
Contexte : Selon le rapport IPCC, les principaux risques liés au changement climatique incluent l'élévation du niveau de la mer, l'augmentation de la fréquence et de l'intensité des phénomènes climatiques extrêmes (comme les vagues de chaleur et les tempêtes), ainsi que des impacts graves sur la biodiversité, les écosystèmes et les sociétés humaines. Il est aussi souligné que les populations les plus vulnérables seront les plus touchées.

Maintenant, voyons la différence entre deux réponses (une fidèle, et une autre non fidèle).

Réponse fidèle : Le changement climatique entraîne des phénomènes extrêmes plus fréquents, tels que des vagues de chaleur et des tempêtes, et affecte gravement les écosystèmes et les sociétés humaines.
Réponse non fidèle : Le changement climatique entraîne des vagues de chaleur et des tempêtes, mais n'a pas d'impact significatif sur la biodiversité ou les sociétés humaines.

Conclusion

Comme nous l'avons vu, l'évaluation d'un RAG n'est pas aussi évidente que dans les systèmes d'IA « plus classiques ». Il faut tout d'abord déterminer quels composants on souhaite évaluer dans le cas d'un RAG, et plus précisément lequel est le plus critique dans un projet.

Ensuite, il est nécessaire de choisir les bonnes métriques adaptées à ses besoins. En effet, chaque métrique utilise des postulats différents, certaines font intervenir un LLM (LLM-as-a-Judge) afin de déterminer si la réponse générée s'appuie correctement sur le contexte fourni.

Malgré tout, évaluer un RAG est primordial avant de mettre en production : cela donne l'assurance que les réponses seront suffisamment pertinentes et les plus sourcées possibles.