前幾天已經把 RAG 的流程整理完整：

Chunking
→ Embedding
→ Vector Database
→ Retrieval
→ Reranking
→ Grounded Generation

但系統做完之後，還有一個很重要的問題：

我們怎麼知道 RAG 真的有正常運作？

不能只因為 AI 有回答，就認為結果一定正確。

所以今天要整理的是：

RAG Evaluation。

⸻

RAG 要測的不只是一個地方

RAG 的結果主要可以分成兩個部分來看：

Retrieval 有沒有找對資料

以及：

Generation 有沒有根據資料回答。

也就是說，如果最後回答錯了，問題不一定出在 AI。

有可能是一開始就找錯 Chunk。

所以測試時需要把這兩個階段分開看。

⸻

第一個要測：Retrieval 找得準不準

假設使用者問：

VoCare 的語音功能怎麼開啟？

那 Retrieval 找到的內容，應該要包含語音操作方式。

如果搜尋結果反而是：

• 聊天功能介紹
• AI 模型說明
• 問卷操作方式

那代表 Retrieval 本身就有問題。

所以可以先準備一組固定問題，再檢查：

正確答案需要的資料，有沒有出現在 Top-K 裡。

這可以幫助我們判斷 Chunking、Embedding、Metadata 或 Retrieval 設定是不是需要調整。

⸻

第二個要測：AI 有沒有真的使用資料

就算 Retrieval 找到正確 Chunk，也不能代表最後回答一定正確。

例如資料裡明明只寫：

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

但 AI 最後卻自己補充：

長按三秒後即可開始錄音。

如果原始資料根本沒有這件事，就代表 AI 加入了額外資訊。

所以 Generation 需要確認：

回答內容是不是能在 Retrieved Context 裡找到依據。

這也是昨天提到 Grounded Generation 的核心。

⸻

可以先建立一組測試問題

最基本的做法，是先準備一組固定的 Question Set。

例如：

• VoCare 的語音功能怎麼使用？
• 問卷一天會出現幾題？
• Memory 和 Context 有什麼差別？
• 系統找不到資料時應該怎麼回答？

每次修改：

• Chunk Size
• Embedding
• Top-K
• Reranking
• Prompt

之後，就重新跑同一組問題。

這樣才能比較：

修改前和修改後到底有沒有變好。

⸻

不只測「答對」，也要測「不知道」

還有一種很重要的測試：

故意問知識庫裡沒有的問題。

例如資料庫裡沒有某個功能，卻故意詢問：

VoCare 有沒有自動叫救護車的功能？

如果知識庫沒有這項功能，系統就不應該自己回答「有」。

而是應該表達：

目前資料中沒有足夠資訊可以確認。

所以一套好的 RAG，不只是會回答有答案的問題。

也要知道：

什麼時候不應該回答。

⸻

RAG Evaluation 可以看哪些結果？

目前可以先從幾個比較基本的方向檢查：

Retrieval Relevance
搜尋出來的內容和問題有沒有關係。

Answer Relevance
最後回答有沒有真正回答使用者的問題。

Groundedness
回答內容能不能在 Retrieved Context 中找到依據。

Completeness
重要資訊有沒有漏掉。

這些指標不一定一開始就全部自動化，但至少可以先人工檢查。