Comment construire un RAG fiable : Une plongée en profondeur dans 7 points de défaillance et les cadres d’évaluation

Retrieval-Augmented Generation (RAG) est critique pour l’architecture moderne de l’IA, servant de cadre essentiel pour la construction d’agents conscients du contexte.

Mais passer d’un prototype de base à un système prêt pour la production implique de naviguer dans d’importants obstacles en matière de récupération de données, de consolidation de contexte et de synthèse de réponses.

Cet article propose une plongée en profondeur dans sept points de défaillance typiques de RAG et les métriques d’évaluation avec des exemples de code pratiques.

L’anatomie de la rupture de RAG – 7 points de défaillance (FPs)

Selon les chercheurs Barnett et al., Retrieval Augmented Generation (RAG) systems rencontrent sept points de défaillance spécifiques tout au long du pipeline.

Le diagramme ci-dessous illustre ces étapes :

Figure A. Indexing and Query processes required for creating a RAG system. The indexing process is done at development time and queries at runtime. Failure points identified in this study are shown in red boxes (source)

Explorons chaque FP, classés selon la séquence du pipeline, en suivant la progression de haut en bas gauche à droite montrée dans Figure A.

FP1. Contenu manquant

Le contenu manquant se produit lorsque le système est invité à répondre à une question qui ne peut pas être répondue parce que les informations pertinentes ne sont pas présentes dans le magasin de vecteurs disponible en premier lieu.

La défaillance se produit lorsque l’LLM fournit une réponse plausible mais incorrecte au lieu de dire qu’il ne sait pas.

FP2. Classement des documents manqués

Il s’agit d’une situation où un document correct existe dans le magasin de vecteurs, mais le récupérateur ne parvient pas à le classer suffisamment haut pour le inclure dans les documents top-k alimentés à un LLM en tant que contexte.

En conséquence, les informations correctes n’atteignent jamais l’LLM.

FP3. Non dans le contexte (limites de la stratégie de consolidation)

Il s’agit d’une situation où un document correct existe et est récupéré à partir du magasin de vecteurs, mais est exclu pendant le processus de consolidation.

Cela se produit lorsque trop de documents sont renvoyés et que le système doit les filtrer pour les faire rentrer dans la fenêtre de contexte d’un LLM, les limites de jetons ou les limites de taux.

FP4. Non extrait

Il s’agit d’une situation où un LLM ne parvient pas à identifier les informations correctes dans le contexte, même si les informations correctes étaient dans le magasin de vecteurs et ont été récupérées/consolidées avec succès.

Cela se produit lorsque le contexte est trop bruyant ou contient des informations contradictoires qui confondent l’LLM.

FP5. Mauvais format

Il s’agit d’une situation où le stockage, la récupération, la consolidation et l’interprétation de l’LLM sont gérés avec succès, mais l’LLM ne parvient pas à suivre les instructions de formatage spécifiques fournies dans l’invite, telles qu’un tableau, une liste à puces ou un schéma JSON.

FP6. Spécificité incorrecte

La sortie d’un LLM est technique et présente, mais soit trop générale, soit trop complexe par rapport aux besoins de l’utilisateur.

Par exemple, un LLM génère des réponses simples à une requête utilisateur avec un objectif professionnel complexe.

FP7. Réponses incomplètes

Il s’agit d’une situation où un LLM génère une sortie qui n’est pas nécessairement incorrecte, mais manque des pièces clés d’informations qui étaient disponibles dans le contexte.

Par exemple, lorsque l’utilisateur pose une question complexe comme “Quels sont les points clés des documents A, B et C?”, l’LLM n’aborde qu’une ou deux des sources.

Comment les FPs compromettent les performances du pipeline RAG

Chacun de ces FPs a un impact sur les performances des pipelines RAG :

Intégrité et confiance des données

Lorsque des informations manquantes ou incorrectes sont présentes, le système n’est plus une source d’information fiable. Les FPs principaux incluent :

• FP1 (Contenu manquant) : La réponse n’est pas dans le doc en premier lieu.
• FP4 (Non extrait) : L’LLM décide d’ignorer la bonne réponse dans le doc.
• FP7 (Incomplet) : L’LLM fournit des demi-vérités, manquant des pièces importantes.

Goulots d’étranglement de récupération et d’efficacité

Le pipeline RAG peut être inefficace lorsqu’il manque des informations clés dans les étapes de récupération et de consolidation. Les FPs principaux incluent :

• FP2 (Classement des documents manqués) : Le modèle d’incrustation échoue à sélectionner les incrustations top-k.
• FP3 (Stratégie de consolidation) : Le script pour élaguer les documents pour les faire rentrer dans les limites de l’LLM supprime les parties les plus importantes.

Erreurs de formatage et d’expérience utilisateur

Bien que correct, une sortie avec une lisibilité médiocre ou dans un mauvais format peut compromettre l’expérience utilisateur. Les FPs principaux incluent :

• FP5 (Mauvais format) : L’LLM échoue à suivre le format de sortie spécifique comme JSON.
• FP6 (Spécificité incorrecte) : L’LLM génère une sortie longue pour une question oui/non simple, ou vice versa (trop brève pour une question compliquée).

La pile d’évaluation : Cadres pour atténuer les FPs

Les métriques d’évaluation sont conçues pour atténuer systématiquement ces FPs.

Cette section explore les principales métriques d’évaluation avec des cas d’utilisation pratiques.

Principales métriques d’évaluation RAG :

• DeepEval
• RAGAS
• TruLens
• Arize Phoenix
• Braintrust

DeepEval – Le test unitaire avant le déploiement

DeepEval calcule un score pondéré en fonction des critères.

Un LLM en tant que juge (par exemple, GPT-4o) évalue chaque critère par rapport à la sortie d’un LLM :

DeepEval utilise G-eval, un cadre de chaîne de pensée (CoT) qui adopte une approche mult étape pour évaluer la sortie :

1. Définir un critère à mesurer (par exemple, “cohérence”, “fluidité” ou “pertinence”).
2. Générer des étapes d’évaluation (en utilisant un LLM évaluateur).
3. Suivre l’étape d’évaluation et analysez l’entrée et la sortie de l’LLM.
4. Calculez une somme pondérée attendue du score de chaque critère.

Scénario courant dans la pratique

• Situation : Un assistant de documentation technique (bot) pour un produit logiciel complexe semble fonctionner à chaque fois que l’équipe d’ingénieurs met à jour la base de code.
• Problème : Aucune preuve quantitative que le bot peut toujours répondre à la requête utilisateur (Vous pensez juste que cela fonctionne…).
• Solution : Intégrez une fonction PyTest en tant que suite de régression CI/CD dans Github Action où DeepEval exécute G-Eval et d’autres métriques sur un cas de test :

• Résultats attendus : Si l’un des scores des métriques est inférieur au seuil (0,85), PyTest renvoie AssertionError – échouant immédiatement à la construction CI, empêchant la régression silencieuse d’atteindre la production.

Note du développeur – Le cas de test pour DeepEval
Un ensemble d’objets LLMTestCase définit le cas de test que DeepEval exécute.

Dans la pratique, ce cas de test doit contenir la plupart des requêtes utilisateur importantes et des sorties étiquetées avec le contexte récupéré.

Ces éléments peuvent être récupérés à partir d’un fichier JSON ou CSV.

RAGAS – L’optimiseur d’aiguille dans une botte de foin

Retrieval Augmented Generation Assessment (Ragas) vise à évaluer RAG sans ensemble de données annotées par l’homme en générant des ensembles de test synthétiques.

Ensuite, il calcule les métriques phares :

Figure B. Le diagramme d’évaluation triadique RAGAS reliant Question, Contexte et Réponse via les métriques de précision, de rappel, de fidélité et de pertinence (Créé par Kuriko IWAI)

Les métriques phares sont classées en trois groupes :

• Pipeline de récupération (ligne noire, solide, Figure B) : Précision du contexte, rappel du contexte.
• Pipeline de génération (ligne noire, pointillée, Figure B) : Fidélité, pertinence de la réponse.
• Vérité terrain (boîte rouge, Figure B) : Similarité sémantique de la réponse, correction de la réponse.

Scénario courant dans la pratique

• Situation : Le système RAG pour les contrats juridiques manque des clauses clés. Vous êtes incertain si le problème est dans la Recherche (Récupérateur) ou la Lecture (Générateur).
• Problème : Aucune idée sur le nombre optimal de chunks récupérés (top-k).
• Solution : Utilisez RAGAS pour créer un ensemble de test synthétique avec 100 paires de questions et de preuves. Ensuite, exécutez le pipeline RAG sur l’ensemble de test pour calculer le rappel du contexte et la précision du contexte :
• Résultat attendu : Selon les résultats des métriques, le plan d’action peut être le suivant :

Tableau 1. Matrice de diagnostic RAGAS – Mappage des scores aux ajustements du système.

TruLens – Le spécialiste de la boucle de rétroaction

TruLens se concentre sur les mécanismes internes du processus RAG plutôt que sur la seule sortie finale en utilisant des fonctions de rétroaction.

Il utilise également un score LLM basé sur la mesure dans laquelle la réponse satisfait l’intention de la requête, en utilisant une échelle de Likert à 4 points (0-3), ce qui en fait supérieur pour classer la qualité des différents résultats de recherche.

Scénario courant dans la pratique

• Situation : Un bot conseiller médical répond à une question de l’utilisateur de manière correcte mais ajoute un conseil qui n’est pas dans la base PDF vérifiée.
• Problème : Le conseil ajouté peut être utile, mais n’est pas fondé.
• Solution : Utilisez TruLens pour implémenter une fonction de rétroaction de fondement avec un seuil comme score > 0,8.

• Résultats attendus : Lorsque l’LLM génère une réponse qui contient des informations non présentes dans les chunks récupérés, TruLens signale l’enregistrement dans votre tableau de bord.

Arize Phoenix – La carte de défaillance silencieuse

Arize Phoenix est un outil d’observabilité et d’évaluation open source pour évaluer les sorties LLM, y compris les systèmes RAG complexes.

Construit sur OpenTelemetry par Arize AI, il se concentre sur l’observabilité en traitant l’évaluation LLM comme un sous-ensemble de MLOps.

Dans le contexte de l’évaluation RAG, Phoenix excelle dans <strong{l'analyse d'incrustation, en utilisant l’approximation et la projection de l’espace uniforme (UMAP) pour réduire les incrustations de vecteurs haute dimension en espace 2D/3D.

Cette analyse d’incrustation révèle mathématiquement si les requêtes échouées sont regroupées sémantiquement, indiquant un trou dans la base de vecteurs.

Scénario courant dans la pratique

• Situation : Un bot de support client fonctionne bien pour les remboursements, mais fournit des réponses sans sens pour les réclamations de garantie.
• Problème : Trou dans la base de vecteurs (Impossible de trouver dans les journaux).
• Solution : Utilisez Arize Phoenix pour générer une visualisation d’incrustation UMAP (UEV), une carte 3D pour la base de vecteurs – pour superposer les requêtes utilisateur sur les chunks de documents.
• Résultats attendus : Visualisez un cluster de requêtes utilisateur atterrissant dans la zone sombre où aucun document n’existe, indiquant que certains documents ont été oubliés lors de l’upload dans le magasin de vecteurs.

Braintrust – Le filet de sécurité de régression de l’invite

Braintrust est conçu pour les cycles d’itération à haute fréquence en utilisant la comparaison entre modèles.

Scénario courant dans la pratique

• Situation : Une équipe d’ingénieurs met à niveau l’invite de “Répondez à la question” (Cas A) à une instruction système plus complexe de 500 mots (Cas B).
• Problème : L’amélioration de l’invite pour le cas B peut accidentellement casser le cas A.
• Solution : Utilisez Braintrust pour créer un ensemble de données doré avec un ensemble de N exemples parfaits (par exemple, N = 50). Laissez Braintrust exécuter une comparaison côte à côte (SxS) chaque fois que l’équipe met à jour un mot dans l’invite :

• Résultats attendus : Un rapport de différence montrant exactement quels cas se sont améliorés/pire pour chacun de l’ensemble de données doré (N = 50).

Conclusion

Lorsqu’il est géré avec les cadres d’évaluation appropriés, RAG peut être un outil compétitif pour fournir à l’LLM le contexte le plus pertinent pour la requête utilisateur.

Stratégie de mise en œuvre : Mappage des métriques aux points de défaillance

Bien qu’il n’y ait pas de solution universelle, le Tableau 2 montre quelles métriques d’évaluation appliquer pour chaque FP que nous avons couvert dans cet article :

Tableau 2. La matrice de mitigation des points de défaillance – Quel outil résout quel FP ?

DeepEval et RAGAS peuvent utiliser leurs métriques de fidélité pour mesurer les défaillances d’intégrité des données (FP1, FP4, FP7).

TruLens utilise sa précision du contexte / rappel pour mesurer la pertinence du contexte par rapport à la sortie – évaluant efficacement FP2.

Arize Phoenix fournit une trace visuelle du processus de récupération, ce qui facilite la visualisation de la perte du document récupéré pendant la consolidation (FP3).

Pour les défaillances de l’expérience utilisateur, DeepEval crée des métriques personnalisées pour évaluer les défaillances de l’expérience utilisateur, tandis que Braintrust excelle dans la comparaison de l’ensemble de données de vérité terrain.