Day 24 整理了 RAG Evaluation，也就是怎麼判斷搜尋結果和最後回答到底準不準。

但實際測試之後，更常遇到的問題其實是：

如果回答不對，到底是哪裡出了問題？

因為 RAG 並不是只有 AI 回答這一個步驟。

完整流程包含：

文件
→ Chunking
→ Embedding
→ Vector Database
→ Retrieval
→ Reranking
→ Prompt
→ AI Response

任何一個環節出問題，最後的回答都可能不正確。

所以今天要整理的是：

RAG Debugging。

第一種情況：根本沒有找到正確資料

假設使用者問：

VoCare 的語音功能怎麼使用？

但 Retrieval 找到的卻是：

• 問卷操作方式
• Memory 功能介紹
• 家屬端使用說明

這種情況其實還沒有進到 AI 回答階段，問題就已經發生了。

可能原因包含：

• Chunk 切得不好
• Embedding 搜尋效果不佳
• Top-K 太小
• Metadata 設定錯誤
• Query 本身不夠清楚

所以第一個要檢查的不是 AI，而是：

Retrieval 到底找出了什麼。

第二種情況：資料找到了，但排名不對

另一種情況是：

正確資料其實有被搜尋出來，但排得太後面。

例如 Top-10 裡第 8 筆才是真正需要的內容，而最後只取前 3 筆交給 AI。

這時候就可以檢查：

Similarity Score、Top-K 或 Reranking。

也就是前面提過的：

找得到，不代表排得對。

第三種情況：資料正確，但 AI 還是回答錯

如果 Retrieval 已經找到正確資料，但最後 AI 還是加入不存在的資訊，那問題可能就出在 Generation。

例如資料寫：

點擊麥克風按鈕即可開始語音輸入。

但 AI 回答：

長按麥克風三秒即可開始錄音。

「長按三秒」根本不存在於原始資料。

這時候就需要檢查 Prompt，例如是否有明確要求：

• 根據提供資料回答
• 不自行補充不存在的內容
• 資料不足時直接表示無法確認

所以這種情況要調整的不是 Retrieval，而是 Prompt 與 Generation。

Debugging 最好一層一層看

RAG 出問題時，如果只看最後答案，其實很難知道要改哪裡。

比較好的方式是依序檢查：

1. Query 是什麼？

↓

2. Retrieval 找到哪些 Chunk？

↓

3. Reranking 後留下哪些資料？

↓

4. 最後送進 Prompt 的 Context 是什麼？

↓

5. AI 根據這些資料產生了什麼回答？

這樣才能知道問題真正發生在哪一層。

不要一看到回答錯，就直接換模型

這也是做 RAG 時很容易遇到的情況。

只要 AI 回答不好，就直接認為：

模型不夠強。

但很多時候真正的問題其實是：

前面根本沒有提供正確資料。

如果 Retrieval 找錯內容，就算換成更強的模型，也很難得到正確答案。

所以在 RAG 裡，Debugging 的重點是：

先確認資料對不對，再確認模型回答得好不好。