Comment construire un RAG fiable : une plongée approfondie dans 7 points de défaillance et des cadres d’évaluation

La génération augmentée par récupération (RAG) est critique pour les architectures d’IA modernes, 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 des obstacles importants dans la récupération de données, la consolidation du contexte et la synthèse de réponses.

Cet article propose une plongée approfondie 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 (FP)

Selon les chercheurs Barnett et al., les systèmes de génération augmentée par récupération (RAG) 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 point de défaillance, 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 car les informations pertinentes ne sont pas présentes dans le magasin de vecteurs disponible en premier lieu.

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

FP2. Classement manqué

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 de haut rang transmis à un LLM comme contexte.

En conséquence, les informations correctes n’atteignent jamais le 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 lors du processus de consolidation.

Cela se produit lorsque trop de documents sont renvoyés et que le système doit les filtrer pour les faire entrer 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 échoue à 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 et consolidées avec succès.

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

FP5. Format incorrect

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

FP6. Spécificité incorrecte

La sortie du LLM est technique, mais soit trop générale ou trop complexe par rapport aux besoins de l’utilisateur.

Par exemple, un LLM génère des réponses simples à une question d’un 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?”, le LLM n’aborde qu’une ou deux des sources.

Comment les FP compromettent les performances du pipeline RAG

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

Échecs d’intégrité des données et de confiance

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

• FP1 (Contenu manquant): La réponse n’est pas dans le document en premier lieu.
• FP4 (Non extrait): Le LLM décide d’ignorer la bonne réponse dans le document.
• FP7 (Incomplet): Le 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 lors des étapes de récupération et de consolidation. Les principaux FP incluent:

• FP2 (Classement manqué): Le modèle d’incrustation échoue à sélectionner les incrustations de haut rang.
• FP3 (Stratégie de consolidation): Le script pour rogner les documents pour les faire entrer dans les limites du LLM supprime les parties les plus importantes.

Erreurs d’expérience utilisateur et de formatage

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

• FP5 (Format incorrect): Le LLM échoue à suivre le format de sortie spécifique comme JSON.
• FP6 (Spécificité incorrecte): Le LLM génère une réponse longue pour une question oui/non simple, ou vice versa (trop brève pour une question complexe).

La pile d’évaluation: cadres pour atténuer les FP

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

Cette section explore les principales métriques d’évaluation avec des exemples de code 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-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 étapes 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 analyser l’entrée et la sortie du LLM.
4. Calculer 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 question de l’utilisateur (Vous pensez juste qu’il fonctionne…).
• Solution: Intégrer une fonction PyTest dans un ensemble 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 tombe en dessous du seuil (0,85), PyTest lève une AssertionError – échouant immédiatement à la construction CI, empêchant la régression silencieuse d’atteindre la production.

Remarque 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 devrait 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 de l’aiguille dans la botte de foin

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 ne savez pas si le problème est dans la recherche (Récupérateur) ou la lecture (Générateur).
• Problème: Aucune idée sur le top-k optimal (nombre de blocs récupérés).
• 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 la précision du contexte et le rappel du contexte:
• Résultat attendu: En fonction des 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 basé sur le LLM qui reflète à quel point la réponse satisfait l’intention de la requête, en utilisant une échelle de Likert à 4 points (0-3), ce qui le rend 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 validée.
• Problème: Le conseil ajouté peut être utile, mais n’est pas fondé.
• Solution: Utilisez TruLens pour mettre en œuvre une fonction de rétroaction de fondement avec un seuil comme score > 0,8.

• Résultats attendus: Lorsque le LLM génère une réponse qui contient des informations non présentes dans les blocs 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 de LLM, y compris les systèmes RAG complexes.

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

Dans le contexte de l’évaluation de RAG, Phoenix excelle dans <strong{l'analyse d'incrustation, en utilisant l’approximation de la variété uniforme et de la projection (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 blocs de documents.
• Résultats attendus: Visualisez un regroupement de requêtes utilisateur atterrissant dans la zone sombre où aucun document n’existe, indiquant que certains documents ont été oubliés lors du téléchargement dans la base 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 de modèles croisés.

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 pourrait 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 seul mot dans l’invite:

• Résultat attendu: Un rapport de différence montrant exactement quels cas se sont améliorés ou détériorés pour chacun des ensembles de données dorés (N = 50).

Conclusion

Lorsqu’il est géré avec les cadres d’évaluation appropriés, RAG peut être un outil compétitif pour fournir un contexte LLM le plus pertinent pour la requête de l’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 point de défaillance 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, facilitant la visualisation de la perte du document lors de la consolidation (FP3).

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