AI 知識庫的品質上限由資料決定，不是模型。本文用公開評測數據拆解髒資料如何毀掉 RAG，並給出盤點去重、切塊策略、OCR 品質、權限分級與定期回測的工程判斷準則。
先搞懂 RAG 怎麼運作，才知道髒資料錯在哪
RAG 的全名是「檢索增強生成」，運作邏輯拆開來其實只有兩段：先從你的文件庫裡「檢索」出幾段最相關的內容，再把這幾段連同問題一起丟給模型去「生成」答案。關鍵就在這裡——模型講出來的話，是被它撈到的那幾段內容綁住的。如果檢索撈到的是三個月前作廢的舊版報價、或是兩份互相打架的請假辦法，那模型再聰明，也只能照著錯的段落往下講，而且講得理直氣壯。
更麻煩的是檢索這一段的底層機制。向量檢索靠的是「語意相似度」，它比對的是你的問題跟文件段落在意義上像不像，而不是判斷哪一份「才是對的、現行有效的」。也就是說，只要舊版和新版講的是同一件事，它們的語意就很接近，檢索器會把它們一視同仁地一起撈上來。當撈進模型的幾段內容彼此矛盾，模型有時候還會很「貼心」地綜合出一個兩邊都不對的折衷答案——這正是企業 RAG 幻覺最常見的來源之一。
資料清洗的四個動作，每一個都有機制在後面
整理文件聽起來像庶務，但每個動作背後都對應著檢索系統的一個弱點。我把它拆成四塊來講，順便把「為什麼要這樣做」的道理一起說清楚。
一、盤點與去重：先逼出「單一事實來源」
第一步是把散在共用磁碟、郵件附件、個人電腦、通訊軟體裡的文件全部集中起來，找出重複與過期的版本，並且明確標記出哪一份是「現行有效」。重點是——別再靠檔名的「最新版」「final」「final2」來判斷，那是災難的開始。正確做法是給每份文件掛上結構化的中繼資料（metadata）：版本號、生效日期、狀態（生效／作廢）、負責單位。
為什麼去重這麼要緊？因為檢索一次只會撈回固定的前幾名（top-k）。如果你庫裡躺著五份幾乎一樣的近似文件，它們會互相稀釋、把有限的檢索名額佔滿，真正該被撈到的那份關鍵段落反而擠不進來。去重不只是清爽，它是在替真正有用的內容騰出檢索名額。
二、去舊與版本治理：作廢的要下架，不是留著
去蕪存菁這一步，很多人捨不得做。作廢的辦法、過季的價目、換了三輪的組織圖，留在庫裡不刪，遲早會被檢索到、被拿去回答客戶。正確的動作是把它們從向量庫裡移出去，而不是塞進一個「舊資料」資料夾繼續躺著。
三、切塊策略：不是切越小越精準
不同模型、資料集、提示、判分方式與正式流量，結果可能差很多。公開 benchmark 只能用來理解方法，不能直接當成專案承諾；驗收應使用公司自己的題庫，分別記錄正確率、引用支持率、拒答、延遲、成本與人工覆核量。
實務上還有兩個細節別忽略：切塊之間留一點重疊（overlap），避免把一句完整的規則從中間砍斷；長文件務必補上清楚的標題層次，讓每一塊都帶著它的脈絡。一句話收尾——別用一套切塊參數硬套所有文件。短的 FAQ、長的合約、密密麻麻的報表，本來就該用不同的切法。
四、OCR 與版面解析：那道看不見的天花板
這裡有一個對採購特別有用的結論：把 OCR 的品質做好，對 RAG 準確率帶來的提升，常常大過你去換一顆更貴的模型、或換一個更大的 embedding。錢花在把文件讀乾淨，比花在算力上更划算。另外，表格是重災區——把 OCR 出來的表格內容轉成結構化的欄位格式，就算不動 OCR 本身的準確率，也能明顯拉高 RAG 表現。至於手寫的、表格密密麻麻的、印刷模糊的文件，辨識結果一定要抽樣人工複檢，別把機器的輸出照單全收。
五、權限分級：檢索層就要擋下，不是事後補
最後這一塊最容易被工程進度犧牲，卻是資安的紅線。資料進庫之前就要標好「誰能看」，財務、人事、法務這類敏感內容，必須在「檢索層」就被過濾掉（業界叫 security trimming），而不是等模型生成完答案再想辦法遮。
機制上，正確的做法是把權限資訊（類似 POSIX 的存取控制清單 ACL）跟著中繼資料一起寫進索引，讓檢索從「只看相似度」升級成「受權限政策約束」的操作——同一個問題，不同身分的人問，能被撈到的文件範圍就不一樣。這也要求你的向量庫本身要支援逐筆（item-level）的權限過濾。為什麼一定要在檢索層擋、不能事後補？因為只要機密段落被撈進了模型的上下文，它就已經進到 prompt 裡了，後面不管是被提示注入（prompt injection）套話、還是日誌外洩，都補不回來。安全這種事，只有「一開始就沒讓它進來」才算數。
幾個最常見、也最傷的誤區
把上面的機制反過來看，就是實務上最常見的幾個坑，這裡幫你列成一張清單：
- 以為換更強的模型能救髒資料。不會。約七成三的失敗卡在檢索階段，模型再強也救不了被撈錯的段落。
- 以為切塊越小越精準。切太碎會把上下文砍斷，模型拿到零碎片段組不出答案；檢索召回率漂亮，不代表答得對。
- 以為 OCR 有出字就夠了。82.9% 的辨識準確率可能只換來 53% 的 RAG 正確率，讀不乾淨的文件是一切下游錯誤的源頭。
- 以為清一次就一勞永逸。知識庫維護失靈才是第一年陣亡的頭號死因，它是持續工程，不是專案結案。
- 把權限留到最後補。敏感資料一旦進了上下文就收不回來，權限一定要在檢索層就生效。
把整理變成習慣：落地節奏與驗收準則
既然資料清洗是持續工程，就得把它變成一套有節奏的制度，而不是靠某個熱心同事偶爾整理。我通常會建議客戶做到三件事。
第一，指定明確的負責人與更新節奏。文件誰維護、多久盤點一次、作廢流程怎麼走，寫成規矩，別靠默契。第二，建一批「真實問題」當黃金題庫，定期拿它回測。每次知識庫更新後，用這批題目量測檢索命中率與答案正確率，設定一條可接受的門檻，低於門檻就代表資料退化了、該檢查了。第三，要求每一個答案都能追回它的支撐文件（也就是引用來源、grounding）。如果一個答案講得頭頭是道，卻找不到任何一份文件在背後撐它，那就是最明顯的紅旗，代表模型在自由發揮。
廷皓科技位在高雄，長期協助南台灣的企業，從文件盤點、清洗、結構化、切塊策略到知識庫建置做一條龍的規劃，也能依照你的資安需求，採雲端或地端部署。如果你也正卡在「資料很多、但很亂」，那通常正是最該先動手、投報率也最高的地方，歡迎找我們坐下來聊聊。
