{"notes":[{"id":"retrieval-augmented-generation/rag-failure-points","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Seven Failure Points","subtitle":"Les sept péchés capitaux","author":"Z. Yuan","paperDate":"2024-01-11","publishedOn":"2026-05-28","paperTitle":"Seven Failure Points When Engineering a Retrieval Augmented Generation System","paperUrl":"https://arxiv.org/abs/2401.05856","bibliography":{"title":"Seven Failure Points When Engineering a Retrieval Augmented Generation System","authors":["Scott Barnett","Stefanus Kurniawan","Srikanth Thudumu","Zach Brannelly","Mohamed Abdelrazek"],"url":"https://arxiv.org/abs/2401.05856","pdfUrl":"https://arxiv.org/pdf/2401.05856v1","codeUrl":null,"preprint":{"id":"2401.05856","submittedOn":"2024-01-11","url":"https://arxiv.org/abs/2401.05856"},"publication":null,"citation":"@misc{retrievalaugmentedgenerationragfailurepoints2024,\n  title = {{Seven Failure Points When Engineering a Retrieval Augmented Generation System}},\n  author = {Scott Barnett and Stefanus Kurniawan and Srikanth Thudumu and Zach Brannelly and Mohamed Abdelrazek},\n  year = {2024},\n  eprint = {2401.05856},\n  archivePrefix = {arXiv},\n  url = {https://arxiv.org/abs/2401.05856}\n}\n","citationPath":"/content/papers/citations/retrieval-augmented-generation/rag-failure-points.40ca0c32c91e.bib"},"thumbnail":{"src":"/content/papers/assets/bd756f315ebe65964e8195f5120c63e86e709d677c39b319fecacd74ea197d71.png","width":1422,"height":578},"locale":"fr","path":"/content/papers/fr/retrieval-augmented-generation/rag-failure-points.f1b323faa871.md","headings":[{"id":"définir-le-problème","text":"Définir le problème","depth":2},{"id":"résoudre-le-problème","text":"Résoudre le problème","depth":2},{"id":"trois-cas","text":"Trois cas","depth":3},{"id":"les-deux-processus-du-rag","text":"Les deux processus du RAG","depth":3},{"id":"une-question-sept-occasions-de-se-tromper","text":"Une question, sept occasions de se tromper","depth":3},{"id":"discussion","text":"Discussion","depth":2},{"id":"leçons-tirées-des-trois-cas","text":"Leçons tirées des trois cas","depth":3},{"id":"pistes-de-recherche-proposées","text":"Pistes de recherche proposées","depth":3},{"id":"ce-quil-faut-garder-en-tête","text":"Ce qu'il faut garder en tête","depth":3},{"id":"conclusion","text":"Conclusion","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"En 2023, monter une démonstration de RAG était assez facile.\n\nOn découpait les documents, calculait leurs embeddings et les plaçait dans une base vectorielle. À l'arrivée d'une question, on retrouvait les passages les plus proches et on les envoyait à ChatGPT avec la question. Un après-midi suffisait pour montrer au patron que « l'IA comprend nos documents ».\n\nLes difficultés venaient ensuite.\n\nCet article vient de l'Institut d'intelligence artificielle appliquée de l'université Deakin, en Australie. Il a été présenté à CAIN 2024, une conférence consacrée au génie logiciel des systèmes d'IA. Aucun nouveau modèle, aucun record : les auteurs livrent un **retour d'expérience**. Ils ont construit trois systèmes RAG et regroupé les échecs rencontrés en sept catégories.\n\n## Définir le problème\n\nLes auteurs rappellent d'abord les trois objectifs du RAG :\n\n1. **Réduire les hallucinations** : faire répondre le modèle à partir des documents plutôt que le laisser improviser.\n2. **Citer les sources** : indiquer à l'utilisateur de quel document provient la réponse.\n3. **Éviter l'annotation** : utiliser directement la recherche sémantique, sans ajouter manuellement des métadonnées à chaque document.\n\nMais le RAG hérite aussi des faiblesses des deux côtés : la recherche d'information peut manquer des documents ou retrouver les mauvais ; le grand modèle de langage peut mal les lire ou répondre de travers.\n\nLes auteurs posent donc deux questions :\n\n- **Où un système RAG peut-il échouer pendant sa mise au point ?**\n- **À quoi les ingénieurs doivent-ils faire attention ?**\n\n## Résoudre le problème\n\n### Trois cas\n\nLe matériau vient de trois systèmes :\n\n| Cas | Domaine | Documents | Taille | Exemple de question |\n| --- | --- | --- | --- | --- |\n| Cognitive Reviewer | Recherche | PDF | Sans limite | Quels sont les points essentiels de cet article ? |\n| AI Tutor | Enseignement | Vidéos, HTML, PDF | 38 documents | Quels sujets ont été abordés en sixième semaine ? |\n| BioASQ | Biomédecine | Articles scientifiques en PDF | 4 017 documents | Qu'est-ce qu'une pseudotumeur cérébrale, et comment la traiter ? |\n\n*Synthèse du tableau 1 de l'article.*\n\n**Cognitive Reviewer** aide les chercheurs à lire la littérature. L'utilisateur formule une question de recherche et importe des articles ; le système les classe selon l'objectif et permet d'interroger toute la collection. Les documents arrivent à l'exécution, ce qui empêche les développeurs d'en contrôler la qualité à l'avance.\n\n**AI Tutor** joue le rôle d'assistant pédagogique : il répond aux étudiants à partir des supports du cours et cite ses sources. Les vidéos sont transcrites avec Whisper avant le découpage. Un reformulateur s'appuie sur l'historique de conversation pour transformer une demande vague, comme « Explique encore ce concept », en requête complète. Le système a été développé d'août à novembre 2023, puis expérimenté à partir du 30 octobre dans un cours d'environ 200 étudiants.\n\nLes deux premiers systèmes ont réellement servi à l'université Deakin. Pour des raisons de confidentialité, seul le troisième cas publie ses données et son code.\n\n**BioASQ** a été construit pour tester une collection plus grande. Les auteurs ont téléchargé 4 017 articles en libre accès issus du jeu de questions-réponses biomédical BioASQ, fait répondre GPT-4 à 1 000 questions, puis évalué automatiquement les réponses avec l'outil evals d'OpenAI. Ils ont vérifié à la main les réponses jugées fausses et une partie de celles jugées correctes.\n\nDans ce domaine, l'évaluation automatique s'est révélée plus sévère que l'évaluation humaine. Les auteurs signalent toutefois une limite de validité : les vérificateurs n'étaient pas des spécialistes de biomédecine, et le modèle pouvait en savoir davantage qu'eux.\n\n\n> [!NOTE]\n> \n> L'introduction et la conclusion mentionnent 15 000 documents ; la section §4.3 et le tableau 1 en donnent 4 017. Cette note retient le second chiffre.\n\n\n### Les deux processus du RAG\n\nAvant les échecs, regardons le schéma des auteurs. Les cadres rouges indiquent les sept points de défaillance.\n\n[![Processus d'indexation et de requête d'un système RAG ; les cadres rouges repèrent les sept points de défaillance](/content/papers/assets/bd756f315ebe65964e8195f5120c63e86e709d677c39b319fecacd74ea197d71.png)](/content/papers/assets/bd756f315ebe65964e8195f5120c63e86e709d677c39b319fecacd74ea197d71.png)\n\n*Figure 1 de l'article, extraite de la [**page 3 du PDF v1**](https://arxiv.org/pdf/2401.05856v1#page=3), CC BY 4.0. En haut : indexation ; en bas : requête. Les cadres rouges signalent les points de défaillance.*\n\nEn haut, le **processus d'indexation** (Index Process) se déroule généralement pendant le développement : le Chunker découpe les documents, chaque fragment devient un embedding, puis les embeddings sont stockés dans la base.\n\nLes choix sont déjà délicats. Des fragments trop petits empêchent de répondre à certaines questions ; trop grands, ils apportent du bruit. Changer de modèle d'embedding oblige à réindexer tous les documents.\n\nEn bas, le **processus de requête** (Query Process) intervient à l'exécution, en cinq étapes :\n\n1. **Rewriter** : un modèle de langage reformule la question en requête généralisée, éventuellement avec l'historique de conversation.\n2. **Retriever** : l'embedding de la requête permet de retrouver les $K$ fragments les plus similaires.\n3. **Reranker** : les fragments sont reclassés pour placer ceux qui contiennent la réponse le plus haut possible.\n4. **Consolidator** : le contenu destiné au prompt est assemblé. Les API de l'époque imposaient des limites de tokens et de débit ; tous les fragments ne tenaient pas, d'où la nécessité de sélectionner, fusionner ou enchaîner plusieurs prompts.\n5. **Reader** : le modèle écarte le bruit du prompt, respecte le format demandé et produit la réponse finale.\n\n### Une question, sept occasions de se tromper\n\nReprenons la question d'AI Tutor : « Quels sujets ont été abordés en sixième semaine ? » Suivons son parcours pour situer les sept échecs.\n\n\n> [!TIP]\n> \n> Les situations ci-dessous ont été conçues pour expliquer le sujet. L'article ne retrace pas les échecs successifs de cette question ; les définitions des points de défaillance viennent de sa section §5.\n\n\n**FP1 : contenu absent (Missing Content).** Les supports de la sixième semaine n'ont jamais été importés. Le système devrait répondre « Désolé, je ne sais pas ». Mais si la question ressemble au contenu disponible, il peut se laisser tromper et inventer une réponse.\n\n**FP2 : document absent des premiers résultats (Missed the Top Ranked Documents).** Les diapositives sont dans la base, mais arrivent en huitième position alors que le système ne prend que les cinq premières. En théorie, tous les documents sont classables ; en pratique, seuls les $K$ premiers sont transmis.\n\n**FP3 : document absent du contexte (Not in Context).** Les diapositives ont été retrouvées, mais le Consolidator les écarte pour respecter la limite de tokens.\n\n**FP4 : réponse non extraite (Not Extracted).** Les diapositives figurent bien dans le prompt, mais le modèle n'en extrait pas la réponse. Selon les auteurs, cela arrive souvent avec un contexte trop bruité ou contradictoire, par exemple lorsque les supports de l'ancien et du nouveau semestre sont retrouvés ensemble.\n\n**FP5 : mauvais format (Wrong Format).** L'étudiant demande une liste, mais le modèle écrit un paragraphe et ignore la consigne de format.\n\n**FP6 : mauvais degré de précision (Incorrect Specificity).** La réponse est présente, mais le propos est trop général ou trop détaillé. Dans l'exemple pédagogique des auteurs, l'enseignant souhaite que la réponse soit accompagnée des supports pertinents. Le problème survient aussi quand l'utilisateur ne sait pas bien formuler sa demande et pose une question trop large.\n\n**FP7 : réponse incomplète (Incomplete).** Trois sujets ont été abordés, mais le modèle n'en cite que deux, alors que le troisième figure dans le contexte. Les auteurs conseillent de séparer les questions du type « Quels sont les points essentiels des documents A, B et C ? ».\n\nLes trois premiers échecs surviennent **avant que l'information nécessaire atteigne le modèle** : elle manque, n'est pas retrouvée ou n'est pas incluse. Les quatre suivants surviennent **après sa réception** : extraction manquée, mauvais format, mauvais niveau de détail ou élément oublié.\n\n## Discussion\n\n### Leçons tirées des trois cas\n\nLes auteurs résument leur expérience dans le tableau 2 et relient chaque leçon aux défaillances concernées :\n\n1. **Un contexte plus grand améliore les résultats.** AI Tutor répondait plus précisément avec 8K qu'avec 4K. Les auteurs précisent que cela contredit des travaux antérieurs sur GPT-3.5. (FP4)\n2. **Un cache sémantique réduit coûts et latence.** Avec plusieurs utilisateurs, limites de débit et frais deviennent préoccupants ; les questions fréquentes peuvent être mises en cache. (FP1)\n3. **Les attaques de jailbreak peuvent contourner le RAG.** Des travaux indiquent que le fine-tuning peut affaiblir l'entraînement de sécurité ; les modèles affinés employés dans le RAG doivent donc être testés. (FP5–7)\n4. **Les métadonnées aident la recherche.** Ajouter noms de fichiers et numéros de fragments au contenu retrouvé aide le Reader à extraire l'information utile. (FP2, FP4)\n5. **Sur les textes courts, les modèles d'embedding open source peuvent égaler les modèles commerciaux.** (FP2, FP4–7)\n6. **Un système RAG exige un calibrage continu.** Des entrées inattendues arrivent à l'exécution ; il faut surveiller le système en permanence. (FP2–7)\n7. **La chaîne RAG doit être configurable.** Taille des fragments, embeddings, découpage, recherche, consolidation, taille du contexte et prompts doivent tous pouvoir être ajustés. (FP1, FP2)\n8. **Assembler une chaîne pièce par pièce n'est pas optimal.** Les auteurs citent des travaux où l'entraînement de bout en bout améliore l'adaptation au domaine. (FP2, FP4)\n9. **Les performances se mesurent à l'exécution.** Des méthodes d'évaluation hors ligne comme G-Eval sont prometteuses, mais supposent de disposer de questions-réponses annotées. (FP2–7)\n\nLe dernier point rejoint les deux conclusions du résumé :\n\n- **Un système RAG ne peut être validé qu'en fonctionnement.**\n- **Sa robustesse se construit progressivement ; elle ne se conçoit pas entièrement dès le départ.**\n\nLa raison est concrète. Le RAG traite des documents encore peu structurés, et les développeurs disposent rarement de jeux de questions-réponses prêts à l'emploi. Les vraies questions apparaissent lorsque de vrais utilisateurs commencent à les poser.\n\n### Pistes de recherche proposées\n\n1. **Découpage et embeddings** : faut-il suivre la ponctuation et les paragraphes, ou les frontières sémantiques ? Une comparaison systématique doit déterminer ce qui aide la recherche. Produire des embeddings pour les tableaux, images et formules reste également une question ouverte.\n2. **RAG et fine-tuning** : le fine-tuning inscrit les données dans le modèle et doit gérer les droits d'accès. Le RAG permet d'ajouter des documents à tout moment et de contrôler les fragments visibles par chaque utilisateur. Il faut comparer systématiquement leurs compromis en précision, latence, coût et robustesse.\n3. **Tests et surveillance** : produire des questions-réponses représentatives d'un domaine réel reste difficile ; chaque nouvelle version du modèle peut aussi modifier sa latence et ses performances.\n\n### Ce qu'il faut garder en tête\n\nIl s'agit d'un retour d'expérience. Les sept défaillances sont des catégories dégagées de trois cas. L'article **ne mesure pas leur fréquence** et ne compare pas la réduction des échecs obtenue avec différents choix de conception. Les données des deux systèmes en service restent confidentielles ; seul BioASQ peut être examiné.\n\nCes expériences datent aussi du début de 2024, à l'époque de GPT-4. Le Consolidator associé à FP3 servait surtout à respecter la limite de tokens ; l'allongement ultérieur des contextes a changé la contrainte pesant sur cette étape. C'est une évolution postérieure aux conclusions de l'article, mais sa date mérite d'être gardée à l'esprit.\n\n## Conclusion\n\nCet article propose une carte, sans nouvelle méthode.\n\nIl sépare le RAG en deux processus, indexation et requête, puis repère sept échecs possibles : contenu absent, document mal classé, omission du contexte, extraction manquée, mauvais format, mauvais niveau de détail et réponse incomplète. Les trois premiers concernent l'acheminement des données au modèle ; les quatre derniers, leur mauvaise exploitation une fois reçues.\n\nCette carte permet, face à une mauvaise réponse, d'interroger chaque étape : les données existent-elles ? Ont-elles été retrouvées ? Incluses ? Le modèle en a-t-il extrait la réponse ?\n\nUn meilleur modèle d'embedding ne règle que certains de ces problèmes.\n\nPour les autres, il faudra probablement attendre la mise en service et les rencontrer un par un.\n","imageSizes":{"/content/papers/assets/bd756f315ebe65964e8195f5120c63e86e709d677c39b319fecacd74ea197d71.png":{"width":1422,"height":578}}}