{"notes":[{"id":"retrieval-augmented-generation/rag-failure-points","category":"retrieval-augmented-generation","legacyPath":"","legacySlug":"","legacyPaths":[],"title":"Seven Failure Points","subtitle":"七宗罪","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":"zh-hans","path":"/content/papers/zh-hans/retrieval-augmented-generation/rag-failure-points.face71c6cea2.md","headings":[{"id":"定义问题","text":"定义问题","depth":2},{"id":"解决问题","text":"解决问题","depth":2},{"id":"三个案例","text":"三个案例","depth":3},{"id":"rag-的两条流程","text":"RAG 的两条流程","depth":3},{"id":"一个问题七个地方可能出错","text":"一个问题，七个地方可能出错","depth":3},{"id":"讨论","text":"讨论","depth":2},{"id":"从三个案例学到的事","text":"从三个案例学到的事","depth":3},{"id":"作者提出的研究方向","text":"作者提出的研究方向","depth":3},{"id":"读这篇时要知道的事","text":"读这篇时要知道的事","depth":3},{"id":"结论","text":"结论","depth":2}],"anchorAliases":{},"guide":null,"relatedReading":[]}],"text":"2023 年，做一个 RAG 演示并不难。\n\n把文档切块、算 embedding、存进向量数据库，问题进来时找出最像的几块，连同问题一起交给 ChatGPT。一个下午就能让老板看到「AI 读懂了我们的文档」。\n\n难的是之后。\n\n这篇论文来自澳洲迪肯大学（Deakin University）的应用人工智能研究所，发表于 CAIN 2024，一个讨论 AI 系统软件工程的会议。它没有提出新模型，也没有刷新任何分数；作者做的是一份**经验报告**：他们实际做了三个 RAG 系统，把途中遇到的失败整理成七个类别。\n\n## 定义问题\n\n作者先说明，RAG 想解决三件事：\n\n1. **减少幻觉**：让模型依据文档回答，而不是自由发挥。\n2. **附上出处**：让用户知道答案来自哪份文档。\n3. **省掉标注**：不必替文档逐一加上元数据（metadata），直接用语义搜索。\n\n但 RAG 同时继承了两边的弱点：信息检索系统会找错、找漏；大型语言模型会误读、乱答。\n\n所以作者想回答两个问题：\n\n- **做 RAG 系统时，会在哪些地方失败？**\n- **工程上该注意什么？**\n\n## 解决问题\n\n### 三个案例\n\n作者的材料来自三个系统：\n\n| 案例 | 领域 | 文档 | 规模 | 示例问题 |\n| --- | --- | --- | --- | --- |\n| Cognitive Reviewer | 研究 | PDF | 不限 | 这篇论文的重点是什么？ |\n| AI Tutor | 教育 | 视频、HTML、PDF | 38 份 | 第六周教了哪些主题？ |\n| BioASQ | 生物医学 | 科学论文 PDF | 4,017 份 | 什么是假性脑瘤？怎么治疗？ |\n\n*整理自原论文 Table 1。*\n\n**Cognitive Reviewer** 帮研究人员读文献：用户写下研究问题、上传一批论文，系统依研究目标排序，也能直接对所有文档提问。文档是用户运行时才上传的，开发时无法先替它们做质量控制。\n\n**AI Tutor** 是课程助教：学生提问，答案来自该门课的教材，并附上出处。视频先用 Whisper 转成文本再切块。它还有一个改写器（rewriter），会参考之前的对话，把「这个概念再解释一下」这种含糊的问题改写成完整查询。系统在 2023 年 8 月到 11 月开发，10 月 30 日起在一门约 200 名学生的课程试行。\n\n前两个系统都在迪肯大学实际使用，但因保密考量，只有第三个案例公开了数据与程序。\n\n**BioASQ** 是作者为了测试较大规模而建的系统。他们从 BioASQ 生物医学问答数据集下载 4,017 份开放取用的论文，用 GPT-4 回答 1,000 个问题，再用 OpenAI 的 evals 工具自动评分，人工检查被判错的案例与一部分判对的案例。\n\n作者发现，在这个领域，自动评分比人工评分更严格。不过他们也指出一个效度上的问题：做人工检查的不是生物医学专家，语言模型懂的可能比检查者还多。\n\n\n> [!NOTE]\n> \n> 论文的前言和结论写的是 15,000 份文档，§4.3 与 Table 1 则是 4,017 份。这篇笔记采用后者。\n\n\n### RAG 的两条流程\n\n在看失败之前，先认识作者画的流程图。红色方框就是七个失败点的位置。\n\n[![RAG 系统的索引流程与查询流程，红色方框标出七个失败点的位置](/content/papers/assets/bd756f315ebe65964e8195f5120c63e86e709d677c39b319fecacd74ea197d71.png)](/content/papers/assets/bd756f315ebe65964e8195f5120c63e86e709d677c39b319fecacd74ea197d71.png)\n\n*原论文 Figure 1，取自 [**v1 PDF 第 3 页**](https://arxiv.org/pdf/2401.05856v1#page=3)，CC BY 4.0。上半为索引流程，下半为查询流程；红色方框为失败点。*\n\n上半部的**索引流程**（Index Process）通常在开发时进行：文档经过 Chunker 切成小块，每块转成 embedding，存进数据库。\n\n这里已经有几个不容易的决定。块切得太小，有些问题答不了；切得太大，答案里混进噪声。换一个 embedding 模型，所有文档都得重新建索引。\n\n下半部的**查询流程**（Query Process）在运行时进行，经过五个关卡：\n\n1. **Rewriter**：用语言模型把问题改写成一般化的查询，可以带入对话历史。\n2. **Retriever**：用查询的 embedding 找出最相似的前 $K$ 块。\n3. **Reranker**：重新排序，让含答案的块尽量排在前面。\n4. **Consolidator**：整理要放进提示词的内容。这一关存在，是因为当时的 API 有 token 上限和速率限制，放不下所有片段，只好挑选、合并，或串接多次提示。\n5. **Reader**：从提示词里过滤噪声、遵守格式要求，产生最后的回答。\n\n### 一个问题，七个地方可能出错\n\n我们拿 AI Tutor 的示例问题「第六周教了哪些主题？」，沿着流程走一遍，看七个失败点分别落在哪里。\n\n\n> [!TIP]\n> \n> 下面的情境是本文为了说明而设计的，论文没有逐步记录这一题的失败经过；各失败点的定义则依照原论文 §5。\n\n\n**FP1：内容不存在（Missing Content）**。第六周的教材根本没上传。理想情况下，系统应该回答「抱歉，我不知道」；但如果问题和现有内容很接近，系统可能被骗，硬是编出一个答案。\n\n**FP2：没排进前几名（Missed the Top Ranked Documents）**。第六周的幻灯片在数据库里，但相似度排在第 8 名，而系统只取前 5 名。理论上所有文档都会被排序，实务上只有前 $K$ 名会往下传。\n\n**FP3：没放进上下文（Not in Context）**。幻灯片被检索到了，但 Consolidator 为了塞进 token 上限，挑掉了它。\n\n**FP4：没有取出答案（Not Extracted）**。幻灯片确实在提示词里，模型却没有读出答案。作者说这通常发生在上下文噪声太多，或信息互相矛盾的时候，例如旧学期和新学期的教材同时被找到。\n\n**FP5：格式错误（Wrong Format）**。学生要的是分条列出的清单，模型却写成一段话，忽略了格式指示。\n\n**FP6：具体程度不对（Incorrect Specificity）**。回答虽然包含答案，但太笼统或太细。作者举的例子是教学情境：老师希望系统除了给答案，也附上相关的教材内容。用户自己不确定该怎么问、问得太广时，也会发生。\n\n**FP7：回答不完整（Incomplete）**。第六周有三个主题，模型只列了两个，虽然第三个就在上下文里。作者的建议是，像「文档 A、B、C 的重点是什么」这种问题，分开问会比较好。\n\n七个失败点里，前三个发生在答案**进入模型之前**：没有数据、没捞到、没放进去。后四个发生在**模型读到之后**：没读出来、格式不对、程度不对、少一块。\n\n## 讨论\n\n### 从三个案例学到的事\n\n作者把经验整理成一张表（原论文 Table 2），每一项都对应到相关的失败点：\n\n1. **上下文大一点，结果比较好**。AI Tutor 用 8K 比 4K 的上下文回答得更准确。作者特别注明，这和先前在 GPT-3.5 上的研究结果相反。（FP4）\n2. **语义缓存能降成本与延迟**。多人同时使用时，速率限制和费用都是问题；可以先把常见问题放进语义缓存。（FP1）\n3. **越狱攻击会绕过 RAG**。有研究指出微调会削弱模型的安全训练，所以用在 RAG 里的微调模型都要测。（FP5–7）\n4. **加上元数据有助检索**。在检索内容里加入文件名和块编号，能帮助 Reader 取出需要的信息。（FP2、FP4）\n5. **短文本上，开源 embedding 模型不输商用模型。**（FP2、FP4–7）\n6. **RAG 系统需要持续校准**。运行时会收到各种没预料到的输入，必须一直监控。（FP2–7）\n7. **把 RAG 做成可设置的流水线**。块大小、embedding、切块策略、检索策略、整理策略、上下文大小、提示词，全都需要调整。（FP1、FP2）\n8. **东拼西凑的流水线不是最佳解**。作者引用研究指出，端到端训练能提升领域适应能力。（FP2、FP4）\n9. **性能只有在运行时才测得出来**。像 G-Eval 这类离线评估方法看起来不错，但前提是手上有标注好的问答数据。（FP2–7）\n\n最后一点直接呼应了摘要的两个结论：\n\n- **RAG 系统只能在运作中验证。**\n- **RAG 系统的鲁棒性是逐步长出来的，不是一开始就能设计好的。**\n\n原因很实际。RAG 处理的是还没整理过的文档，开发时通常没有现成的问答数据可以测。问题长什么样子，要等真正的用户来问了才知道。\n\n### 作者提出的研究方向\n\n1. **切块与 embedding**：依标点与段落切，还是依语义切？哪种对检索比较好，需要系统性的比较。表格、图片、公式这类多模态内容怎么做 embedding，也还是开放问题。\n2. **RAG 与微调**：微调要把数据训练进模型，还得处理谁能访问什么；RAG 可以随时加入新文档，也能控制用户看得到哪些片段。两者在准确度、延迟、成本与鲁棒性上的取舍，需要系统性比较。\n3. **测试与监控**：如何产生贴近真实领域的测试问答，仍是开放问题；模型每次改版，延迟与性能特性也会跟着变。\n\n### 读这篇时要知道的事\n\n这是一份经验报告。七个失败点是从三个案例里归纳出来的类别，论文**没有统计每种失败发生的频率**，也没有比较不同设计能减少多少失败。两个在用的系统因保密没有公开数据，只有 BioASQ 案例可以检验。\n\n另外，这是 2024 年初、GPT-4 时代的经验。像 FP3 的 Consolidator，存在的主要理由是 token 上限；之后上下文长度大幅增加，这一关的压力也跟着改变。这是后来的发展，不是论文本身的结论，但读的时候可以把时间点放在心上。\n\n## 结论\n\n这篇论文没有新方法，给的是一张地图。\n\n它把一个 RAG 系统拆成索引与查询两条流程，标出七个会失败的位置：内容不存在、没排进前几名、没放进上下文、没有取出、格式错误、具体程度不对、回答不完整。前三个是「数据没送到模型面前」，后四个是「送到了，模型没用好」。\n\n这张地图的实用之处在于，当你的 RAG 答错时，可以沿着流程一关一关问：数据在不在？捞到了没？放进去了没？模型读到了没？\n\n换一个更好的 embedding 模型，只解决得了其中几个。\n\n剩下的，大概只能等上线以后，一个一个遇到了。\n","imageSizes":{"/content/papers/assets/bd756f315ebe65964e8195f5120c63e86e709d677c39b319fecacd74ea197d71.png":{"width":1422,"height":578}}}