Comment évaluer un système RAG

Pourquoi évaluer un système RAG ?

L’efficience financière et les performances sont également importantes. Par ailleurs, une entreprise doit s’assurer que son système est robuste et résistant aux injections de prompts, volontaires ou non. L’équipe derrière un tel projet doit, par ailleurs, vérifier que l’utilisateur ait bien le droit d’accès à l’information produite.

Dans sa documentation, Databricks explique qu’il faut donc mesurer la qualité de la recherche, la qualité des réponses et les performances du système. Un bon point de départ pour expliquer comment évaluer un système RAG.

Qualité de la recherche

Dans un système RAG, la qualité de la recherche est fonction de deux métriques principales : la précision et le rappel (recall, en VO).

Ces deux mesures sont très utilisées dans la classification automatique, la reconnaissance de forme et la recherche d’information.

•  La précision correspond dans le cas présent à la proportion des extraits ou des documents pertinents parmi l’ensemble des documents sélectionné dans le processus de recherche. Cela revient à répondre à la question : parmi les documents trouvés par le système RAG combien sont réellement utiles à la réponse ?
• Le rappel renvoie au nombre de documents pertinents par rapport à l’ensemble des éléments pertinents présents dans la base de données. Ici, il s’agit de répondre à la question : « combien de documents pertinents sont-ils récupérés ? », évoque Pinecone, l’éditeur d’une base de données vectorielle.

Et à Pinecone d’indiquer qu’il faut bien distinguer le rappel dans le système de recherche de celui d’un LLM. « Le rappel LLM fait référence à la capacité d’un LLM à trouver des informations à partir du texte placé dans sa fenêtre contextuelle », explique-t-il.

Ces deux métriques sont généralement exprimées par un score à virgule compris entre 0 et 1. Une note de 1 impliquerait que les résultats de recherche sont bons.

Le score F1, lui, « correspond à la moyenne harmonique (une sorte de moyenne) de la précision et du rappel », explique Google. « Cette métrique équilibre l’importance de la précision et du rappel, et est préférable à la précision pour les jeux de données déséquilibrés ». Un score faible signifie que les bons documents ne sont pas retrouvés ou qu’il y a une dérive entre la requête et les informations retrouvées.

En soi, les résultats de ces trois indicateurs ne suffisent pas. Ils ne permettent pas de déterminer précisément ce qui peut affecter la qualité de la recherche.

Les problèmes de précision et de rappel peuvent être provoqués par la qualité des documents indexés, les performances des algorithmes de récupération (HNSW, embeddings, BM25), le nombre limite de documents sélectionnés lors de la recherche (top_k cutoff), un souci lié au modèle de reranking ou encore le LLM (taille de la fenêtre de contexte, performance) et sa configuration (prompting, filtrage).

Comme l’indique Weaviate, la précision et le rappel ne sont pas des mesures pour évaluer le classement des documents.  

Pour cela, il faut se tourner vers des métriques plus spécifiques. Les voici :

- Mean Reciprocal Rank (MRR) : le rang moyen réciproque est une mesure statistique du nombre de documents pertinents en haut du classement envoyé au LLM. « Cette métrique ne tient compte que de l’ordre des premiers résultats pertinents, mais pas du nombre ou de l’ordre des autres résultats pertinents », indique Weaviate.

- Mean Average Precision (MAP) : ici, il s’agit d’évaluer la qualité globale du classement des documents. En clair, il s’agit de prendre en compte à la fois le nombre de documents pertinents et leur position dans le classement. Le score MAP est la métrique principale pour évaluer la performance d’un modèle de reranking.

- Normalized Discounted Cumulative Gain (NDCG) : cette métrique sert à évaluer la capacité du système à classer les documents selon leur pertinence. Il s’agit d’une mesure effectuée entre un classement idéal par rapport à la réalité. « Pour le RAG, cela permet de déterminer si le classement du retriever [produit par le système de recherche, N.D.L.R.] correspond aux informations dont le générateur [le LLM, N.D.L.R.] a besoin pour produire des résultats de haute qualité », relate Ziliz, un autre éditeur d’une base de données vectorielle.

Ces métriques sont fonction de formules statistiques incluses dans certaines librairies Python. Elles sont déjà largement répandues dans les systèmes de recherche et de recommandations.

Qualité des réponses

Une fois que la recherche a été effectuée, c’est au LLM d’interpréter les documents les plus pertinents. Les opérateurs de système RAG doivent donc s’intéresser à trois aspects en particulier :

• l’ancrage (groundedness)
• l’exactitude (correctness)
• et la sûreté (safety).

Ici, il ne s’agit pas de métriques spécifiques de types d’indicateurs clés à suivre.

L’ancrage établit si la réponse effectuée s’appuie sur le contexte fourni, c’est-à-dire les extraits ou les documents complets présents dans la base de données vectorielle.

Traditionnellement, l’ancrage est mesuré à l’aide des algorithmes BLEU (Bilingual Evaluation Understudy), ROUGE (Recall-Oriented Understudy for Gisting Evaluation) et METEOR (Metric for Evaluation of Translation with Explicit ORdering). Ces métriques sont d’abord utilisées pour évaluer la qualité d’un texte traduit ou résumé par une machine.

Dans le contexte des systèmes RAG, BLEU peut être utilisé pour mesurer la correspondance exacte des mots entre les sources documentaires et le contenu généré. ROUGE permet d’évaluer la fidélité du texte produit en comparant ses n-grammes avec ceux des sources. Comparable à BLEU, METEOR offre des fonctionnalités supplémentaires, notamment la prise en compte de la synonymie, ce qui lui permet de mieux évaluer la similarité sémantique.

D’autres méthodes ont vu le jour, spécifiques au système RAG, dont le framework RAGAS (Retrieval Augmented Generation Assessment). Les fournisseurs, par exemple Microsoft, Databricks ou Giskard, mettent au point leurs propres métriques d’évaluation.

Selon Ziliz, l’exactitude vise à évaluer si la réponse d’un système RAG est « factuellement exacte, logique, consistante » et « si elle correspond à la demande de l’utilisateur ».

Généralement, la mesure de l’exactitude s’appuie sur les éléments fournis par le système de recherche. En clair, exactitude et ancrage sont souvent liés, mais une évaluation constituée de paires de questions-réponses réalisées semi manuellement ou avec un LLM as a Judge peut mettre en lumière des biais ou des erreurs factuelles dans les documents d’origine. Un agent LLM doté d’un outil de recherche sur le Web peut parfaitement illustrer ce phénomène : il peut générer une réponse fidèle aux sources trouvée par le retriever, mais ces sources peuvent être incorrectes.

Exemple très concret. La presse française a relayé l’information selon laquelle la voix de Val Kilmer dans le film « Top Gun : Maverick » a été générée par une IA. Une information que ChatGPT produit en première instance et qui est fidèle aux sources françaises disponibles sur le Web.

Si le procédé de re-création de la voix de l’acteur a bien été mené, le réalisateur Joseph Kosinski a déclaré auprès d’USA Today qu’il n’a pas utilisé cette ressource. Bien que sa voix soit altérée par la maladie, Val Kilmer a bien prononcé la phrase qui lui a été confiée. La piste audio a été éditée pour davantage de clarté.  

Cette mesure de l’exactitude peut être en partie automatisée, il convient généralement de constituer des paires de questions-réponses spécifiques en s’appuyant sur la méthode QA Eval, par exemple.

Selon Microsoft, « l’exactitude reste la priorité ». Toutefois, cette mesure peut être liée aux sources, comme la métrique « factual correctness » du framework RAGAS qui compare cette exactitude aux références données en entrée, alors considérées comme la « vérité terrain ».

Enfin, la sûreté est tout simplement une mesure de la toxicité et de la dangerosité des réponses d’un système RAG.

Ici, il est possible d’utiliser une passerelle API qui appliquerait des règles, de se servir d’un jeu de données d’évaluation – des paires de questions-réponses vérifiées – ou encore d’un LLM as a judge pour identifier les biais. Cela n’est pas forcément parfait.

De même, des algorithmes et des outils peuvent aider à identifier, puis filtrer les données personnelles ou confidentielles dans les réponses. Les modèles garde-fous, comme Granite Guardian HAP-38m d’IBM permettent de filtrer les réponses haineuses, abusives et insultantes.

Une couche de sécurité capable de gérer les prompt injections est recommandée.

Les performances d’un système RAG

La multitude des pièces mouvantes d’une architecture RAG implique une vigilance en matière de latence. Cette latence peut être mesurée dans chaque composant : le temps d’indexation, de recherche, de classement, de génération de la réponse, de sa vérification, de son envoi à l’utilisateur. Il est aussi possible de traiter la chose comme une mesure de bout en bout en s’appuyant sur les traces applicatives. Il s’agit d’estimer le temps de réponse entre la validation d’une instruction par un utilisateur et la réception de la réponse.

Ici, des outils d’observabilité comme Datadog, Dynatrace, la suite ELK ou encore des frameworks comme MLFlow ou LlamaIndex sont utiles pour mesurer ces temps de réponse.

Quant à la mesure des coûts du système, elle dépend du nombre de contenus vectorisés et indexés (qui influencent l’espace de stockage occupé), des ressources RAM et CPU utilisées pour exécuter les différences opérations (y compris les évaluations), ainsi que des ressources GPU ou du nombre de tokens ingérés et générés par les LLM via API.

L’application de limites (à l’ingestion de documents, au nombre d’appels, etc.) est enfin un moyen de contrôler les dépenses.