{"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-hant","path":"/content/papers/zh-hant/retrieval-augmented-generation/rag-failure-points.227d58b40b34.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}}}