RAG（Retrieval-Augmented Generation）系統效果不好，很多時候不是模型的問題，而是「檢索到的內容根本不對」。這篇筆記聚焦在檢索前置作業：怎麼切文件、怎麼知道切得好不好。

為什麼 Chunking 這麼關鍵

檢索是拿使用者的問題去找「最相關的片段」，如果切分方式破壞了語意完整性（例如把一個表格從中間切斷、把一段論述切成兩個不相干的片段），就算 embedding 模型再強，也檢索不到正確答案所在的完整脈絡。

常見 Chunking 策略

固定長度切分 最簡單，按字數／token 數切，通常搭配 overlap（如 200 token 一段、50 token 重疊）避免邊界切斷語意。缺點是完全不理解文件結構，容易切壞表格、程式碼區塊。

遞迴式切分（Recursive Character Splitting） 依照優先順序嘗試分隔符（先用段落、再用句子、再用字），盡量在自然邊界切開，同時控制長度上限。是目前多數 RAG 框架的預設做法，泛用性最好。

結構化切分（Markdown / HTML aware） 依照標題階層（#、##）或 HTML 標籤切，確保每個 chunk 至少對應到一個完整的章節單位，適合技術文件、規格書這類結構清楚的內容。

語意切分（Semantic Chunking） 用 embedding 計算相鄰句子的語意相似度，在相似度明顯下降的地方切開，讓每個 chunk 的主題盡量單一。效果通常最好，但需要額外的 embedding 運算成本。

怎麼知道檢索品質好不好

生成結果看起來「怪怪的」時，很難判斷是檢索錯還是生成錯，所以要把檢索階段獨立評估：

  • Recall@K：正確答案所在的 chunk，有沒有出現在前 K 個檢索結果裡
  • MRR（Mean Reciprocal Rank）：正確 chunk 排名越前面分數越高，比 Recall@K 更能反映排序品質
  • 上下文精確率：檢索回來的 K 個 chunk 裡，有多少比例是真的相關（避免塞一堆無關內容稀釋 LLM 的注意力）

實務上建議先準備一組「問題 → 應該命中的 chunk」的標註資料（哪怕只有 30–50 筆），每次調整 chunking 策略或 embedding 模型後都重新跑一次，才不會憑感覺調參。

小結

RAG 的除錯順序應該是：先確認檢索有沒有找對東西，再看生成有沒有忠實引用檢索結果，最後才去調 prompt。反過來先狂調 prompt，通常只是在掩蓋檢索階段的根本問題。