[Day 14] RAG Error Case: 從失敗案例找出真正的問題

前幾天我們已經完成：

• Retrieval 評估
• Reranking
• RAG Evaluation

但這時候會遇到一個更重要的問題：

分數不好，到底是哪裡出了問題

可能是：

• Chunk 切得不好
• Embedding 不適合
• Query 本身太模糊
• Top-K 太小
• Vector Search 沒找到正確文件

而如果 Retrieval 很好，但 Answer 卻很差

可能是：

• Prompt 不夠清楚
• Context 太長
• LLM 忽略了重要資訊
• 模型產生了文件沒有提供的內容

所以今天的重點是：

不要只看 Evaluation Score，而是建立一套方法，找出 RAG Pipeline 真正失敗的位置

RAG 不是只有「答對」與「答錯」

一個完整的 RAG Pipeline

任何一個階段都可能造成錯誤

因此 Answer 錯誤，不代表 LLM 一定有問題

可能真正的原因是 Retrieval 根本沒有找到正確資料

此時 LLM 即使能力再強，也沒有足夠的 Context 可以回答

所以第一個重要觀念是：

先確認 Retrieval，再分析 Generation

建立 RAG Error Case

今天先建立一套錯誤分類。

可以將 RAG Error 分成五大類：

• Dataset Error
• Chunking Error
• Retrieval Error
• Generation Error
• System Error

Dataset Error

第一種錯誤甚至不是 RAG 本身造成的

而是：

測試資料本身有問題

例如原始文件根本沒有提到 macOS

這時候並不能直接判定 RAG 錯誤

因此 Dataset 本身也需要驗證

Chunking Error

文件切割方式造成資訊遺失

Retrieval Error

這是 RAG 最常見也最重要的一類

意思是：

正確資訊存在，但 Retrieval 沒有找到

Query Error

使用者問題太短，很難找到正確 Context

Embedding Error

兩個語句實際意思相近，但 Embedding 相似度不夠高

如果語意表示沒有被很好捕捉，就可能影響 Retrieval

Ranking Error

正確文件有被找到，但順位排在後面

Generation Error

Prompt 不清楚

Context 太長

缺少真正重要的資訊
LLM 可能難以聚焦

Context Conflict

不同文件可能存在不同說法

即使 Retrieval 正確，也需要處理

System Error

不是模型問題，而是系統問題

從 Error 回推 RAG 參數

Error Case 最有價值的地方，是可以形成：

工程 Debug 工具

今天最重要的觀念：先定位/再優化

避免讓調整與優化：

盲目調參

正確流程應該是發現失敗案例、定位問題

這樣才能知道：

到底是哪個修改才能真正改善系統

今天學到什麼

今天最大的改變，不是增加一個新的 Metric

而是把：

「RAG 評估」

進一步轉換成：

「RAG 問題診斷」

如此一來，當系統回答錯誤時，我們就能開始回答真正重要的問題：

「到底是哪一個環節出了問題」

這就是一個真正可以持續迭代的 AI Assistant 開發流程

知道問題在哪裡之後，下一步就是：

如何系統性地改善它

因此下一篇將進一步進入：

Day 15：RAG Optimization 系統化改善，讓每次調參都有依據