RAG 知識庫為什麼答不準？
——企業文件的切塊、檢索與評測

企業導入知識問答，最常見的挫折是：明明文件裡寫得清清楚楚，AI 卻答錯或答「查無資料」。要理解為什麼，得先看清 RAG 的運作方式。Lewis 等人提出的檢索增強生成（Retrieval-Augmented Generation），是讓語言模型在生成答案前，先從外部知識庫檢索相關段落，再根據這些段落作答^[1]。關鍵在於：模型只能根據「檢索到的段落」回答。檢索環節若沒把對的段落撈出來，後面接的模型再強也回天乏術——它要嘛答錯，要嘛用參數裡的舊記憶硬掰，也就是幻覺^[4]。所以「答不準」的診斷，永遠要先問：對的段落，到底有沒有被檢索到？

切塊：資訊在這一步就可能被切斷

知識庫不是把整份文件丟進去，而是先切成一段一段（chunk）再建索引。切塊策略直接決定檢索品質，而它有兩個反方向的陷阱。切得太碎，一個完整的規定被拆到兩三個 chunk，檢索只撈到半句話，模型看不到完整條件；切得太整，一個 chunk 塞進整章內容，關鍵句被大量無關文字稀釋，語意向量被「平均掉」，反而檢索不到。資訊檢索的經典教科書早就把「索引單位（indexing unit）的粒度如何影響檢索效果」列為核心議題^[6]。實務上，好的切塊要順著文件的語意邊界（章節、條款、表格）走，並讓相鄰 chunk 有適度重疊，避免把一句話攔腰切斷。企業文件尤其棘手：表格、編號條款、跨頁段落，用通用的「每 N 字切一刀」幾乎必然出問題。

檢索：語意向量不是萬靈丹

現代 RAG 多用稠密檢索（dense retrieval）：把 chunk 與問題都編碼成向量，用語意相近度找段落。Karpukhin 等人的 DPR 證明了這種雙編碼器稠密檢索在開放域問答上勝過傳統關鍵字法^[2]，其編碼器多半建立在 Transformer 架構之上^[3]。但稠密檢索有個現場常見的盲點：它擅長「意思相近」，卻可能漏掉必須靠精確字串才找得到的東西——料號、型號、專有名詞、法規條號。使用者查「XR-200 的扭力規格」，語意向量可能撈回一堆「講扭力」但型號不對的段落。這正是關鍵字檢索的強項，其代表方法 BM25 至今仍是強而難以超越的基準^[5]。實務上最穩健的做法是混合檢索（hybrid）：稠密與關鍵字並用、再重排序，兼顧「意思對」與「字串對」。

評測：沒有它，你只是在盲改

這是最常被跳過、卻最致命的一步。很多團隊調 RAG 的方式是：換個切塊大小、改個提示詞，然後「試幾個問題看看」感覺有沒有變好。這不是工程，是碰運氣。資訊檢索領域幾十年前就把評測制度化了——用一組標好「哪個問題該檢索到哪些段落」的測試集，量化 precision 與 recall^[6]。RAG 的評測要分兩層：檢索層（對的段落有沒有被撈到、排在前面）與生成層（答案是否忠實於檢索到的段落、有沒有幻覺）。沒有這組評測集，你永遠不知道剛剛的調整是真的改善了系統，還是只是「這次那幾個例子剛好對」。建立評測集要花工，但它是 RAG 從 demo 走向可信賴生產系統的唯一路徑。

結論：先修資料與檢索，再談模型

把上面三件事連起來看，一個清楚的順序浮現：當 RAG 答不準，先別急著換更大的模型。先檢查切塊是否順著語意邊界、檢索是否兼顧語意與關鍵字、以及——最重要的——你有沒有一組評測集能告訴你問題到底出在檢索層還是生成層。多數「AI 回答不準」的案子，根源是資料工程與檢索工程，而非模型選型。工具鏈（如 Dify）已把 RAG 管線、混合檢索與評測節點做成可視化配置，讓非 AI 團隊也能落實這套紀律——我們的 Dify 實戰課程，教的正是這套「從切塊、檢索到評測」的完整方法，而不只是把文件丟進去按個按鈕。