RAG 知識庫怎麼建——文件整理到上線的五關完整拆解

你把公司五年累積的 PDF、SOP、產品手冊全餵給 ChatGPT，問它「我們的退換貨規則是什麼」，它卻給你一個語氣篤定、看起來很專業、但其實早就作廢的舊版本。你知道哪裡怪，卻說不出問題出在哪——因為模型沒看過你的文件，它只是在用訓練資料裡的常識幫你「腦補」一個聽起來合理的答案。

這就是為什麼有依據的內部問答，幾乎都得靠 RAG 才做得到。RAG（Retrieval-Augmented Generation，檢索增強生成）就是一套讓 AI 先去你的資料庫翻到相關片段、再根據那些片段回答的架構，目的只有一個，就是讓它講話有所本，而不是自由發揮。做對了，員工能在幾秒內查到散落各系統的內部知識；做歪了，AI 會拿著錯資料回答得更理直氣壯。

好消息是，蓋一座堪用的知識庫，現在不需要自架 GPU、也不需要先養一個 AI 團隊。手上有幾百份文件、會串 API，就能從 PDF 一路走到能回答問題的系統。接下來就照「文件處理 → 切分 → 進向量庫 → 串接 LLM → 測試驗收」這條線，一關一關拆給你看，每一關都告訴你做什麼、怎麼做、容易在哪裡卡住。

RAG 知識庫在做什麼？先看懂這條資料流

一句話：RAG 把「找資料」和「寫答案」拆成兩件事，讓擅長找的歸找、擅長寫的歸寫。

傳統上你直接問 LLM，它只能靠訓練時記下來的東西回答，碰到你公司專屬的政策、規格、流程，它沒看過，就只能猜。RAG 在它回答之前插進一個檢索步驟，先把你的問題拿去一個存了公司文件的資料庫裡比對，撈出最相關的幾個段落，再連同問題一起塞給 LLM，等於是「開書考試」——它不必背，照著翻到的那幾頁回答就好。

整條流程其實分成兩半。一半是離線先做好的「蓋知識庫」：把文件清乾淨、切成小塊、轉成向量、存進向量資料庫。另一半是使用者每次提問時才即時跑的「查詢」：問題也轉成向量、去庫裡找最近的幾塊、組進提示詞交給 LLM 生成答案。前半段決定了答案的天花板，後半段決定了體驗順不順。

這也解釋了一個很多人一開始想不通的問題——為什麼不乾脆把所有文件一次塞進 LLM 的對話視窗就好？因為即使是支援長上下文的模型，幾百份 PDF 全塞進去既慢又貴，每問一次就要重算一次所有文件的成本，而且沒有權限控管——你沒辦法讓某個員工查不到他無權看的資料。RAG 的精神是「只把相關的那幾塊」丟給模型，成本、速度、精準度都會贏過整份硬塞。

理解了這條資料流，後面每一關要解決什麼問題就清楚了。先從最前面、也最容易被輕忽的文件處理開始。

文件進來之前，先把資料清乾淨

垃圾進、垃圾出，這句話在 RAG 的世界裡會被放大好幾倍。一份排版混亂、夾雜頁首頁尾雜訊、表格被打散的文件，切完之後語意支離破碎，後面用再強的模型也救不回來。所以第一步不是急著切，而是先盤點和清理。

盤點要回答三個問題：哪些文件要進來、它們是什麼格式、多久更新一次。把 PDF、Word、Excel、網頁分門別類，標清楚哪些是現行版、哪些是過期該排除的舊檔。這一步看起來像雜務，卻是整個專案最該由懂業務的人來把關的環節——技術能告訴你「做得到」，但「哪份文件可信、哪份該丟」是業務判斷，不能丟給工程自己猜。

真正的技術難點在 PDF。內部文件裡最常見、也最難處理的就是 PDF，因為它可能夾著掃描影像、複雜表格、雙欄排版。直接用陽春的文字抽取工具，常會把表格的欄列順序拆亂、把雙欄內容交錯讀成一團。處理方式視文件複雜度而定：

1. 純文字、單欄的 PDF：用一般的文字抽取就夠，成本最低。
2. 含表格的 PDF：需要能辨識版面結構的解析工具，把表格轉成 Markdown 或保留欄列關係的格式，否則「品名對應價格」這種資訊一拆就亂。
3. 掃描件 / 圖片型 PDF：得先過 OCR 把圖變成文字，再進後面的流程。

清理的同時，別忘了替每一塊內容帶上溯源資訊（metadata）：這段來自哪份文件、哪個章節、版本日期是哪個季度、屬於哪個部門、權限等級是公開還內部。這些標籤在後面做引用標註、做權限過濾時都會用到，現在不帶，之後要回頭補會非常痛。

文件清乾淨、metadata 帶齊了，才輪到整個 RAG 最關鍵的單一變因登場——切分。

切分（chunking）切壞了，後面再強都白搭

把長文件切成一塊塊餵進向量庫，這個動作叫 chunking，它對檢索精度的影響大到不成比例。一份切得好的文件，每一塊都是一個完整語意單元；切壞了，相關內容被打散到不同塊，檢索時就怎麼也湊不齊。

最常見的失誤，是直接拿通用工具的預設值切完就交差。那種固定字數硬切的做法，會把句子攔腰斬斷、把「條件」和「結果」拆到兩塊去，對中文又特別不友善——中文不像英文有空格分詞，硬照 token 數切常常切出半個詞。比較穩的起手式是遞迴式切分：先照段落、再照句子、再照標點，一層一層退而求其次，盡量在語意邊界斷開。

切塊大小怎麼抓？業界普遍的安全範圍落在 300 到 800 個 token、重疊（overlap）設 10% 到 20%。重疊的作用是避免一個完整概念剛好被切在兩塊交界處而兩邊都不完整，留一段共用的緩衝，概念至少會完整出現在其中一塊裡。值得注意的是，針對中文文本，因為資訊密度比英文高，塊切太大或太小檢索效果都會變差，800 token 上下、重疊抓在這個區間的高端，通常是個相對穩定的起點。中文用太大的塊，反而容易讓檢索找到一堆模糊的匹配。

不同文件其實適合不同切法，不必全庫統一：

一個實用的小原則：像 SOP、操作教學這類有步驟的內容，以「一組步驟」當一塊，會比把整份 SOP 塞進同一塊好用得多。切分沒有唯一正解，但有一條鐵律——切完一定要回頭抽幾塊出來讀讀看，確認每塊單獨拿出來都還讀得懂。

切好的文字塊，接下來要變成機器能比對的形式。這就進到向量化與向量資料庫。

把文字變成向量，存進向量資料庫

向量化（embedding）就是把一段文字轉成一串數字，讓「意思相近」變成「數字相近」。打個比方，假設我們只用三個數字描述一個詞，「貓」是 [0.8, 0.2, 0.9]、「狗」可能是 [0.7, 0.3, 0.85]，兩者在數字空間裡很靠近，因為意思相關；「報表」就會離得很遠。真實的 embedding 不是三個數字，而是上千維，但原理一樣——一旦每段文字都變成向量，系統就能用同一套規則去計算誰跟誰最接近，這正是檢索的基礎。

這一步用 API 就能完成，不必自己訓練模型。市面上的 embedding 服務直接接受文字、回傳向量，你要做的是把每一塊文字送過去、把回來的向量連同 metadata 一起存好。選 embedding 模型時，真正該看的不是排行榜上的分數，而是兩件事：對中文的支援度夠不夠好、需不需要私有部署。如果資料完全不能外流，就選能自架的開源模型；如果可以用雲端 API，主流的多語言 embedding 服務對繁體中文已經堪用。

向量算好了，得有地方存。向量資料庫就是專門儲存向量、並能快速找出「最相近的前幾個」的系統。選型不必妖魔化，照規模和現況挑就好：

對多數剛起步、文件量還在幾百到幾萬份的團隊，從 pgvector 起手通常最省事——尤其你的業務資料本來就在 PostgreSQL，向量查詢能直接和業務表關聯，省掉一整層同步。等到規模真的長大了，再考慮搬家也不遲。在還搞不清楚自己有多少向量、查詢多頻繁之前，先上最貴的全託管方案，多半是把錢花在你還用不到的容量上。

知識庫蓋到這裡，離線的部分就完成了。接下來把它接上 LLM，讓它真的能回答問題。

串接 LLM，怎麼讓它老實照著資料講

檢索到正確的段落，不代表 LLM 就會乖乖根據那些段落回答——這一步沒做好，前面所有功夫都會在最後一關漏氣。

即時查詢的流程是這樣，使用者問了一句話，系統先把這句話也轉成向量，拿去向量庫找出最相近的幾塊（通常取前 3 到 5 塊），再把這幾塊連同原始問題、一段指令，組成一份提示詞交給 LLM，最後由它整理成一段通順的答案。整套同樣是用 API 串起來的，embedding 一個 API、生成一個 API，中間夾著向量庫的查詢，沒有哪一步需要你自己跑模型。

真正的成敗點在那段指令怎麼寫。很多團隊把提示詞寫成「請參考以下資料回答」，問題就出在「參考」這兩個字——模型會把它解讀成「可以加上自己的看法」，於是又開始腦補。要把規則寫死、寫狠，重點不是寫得漂亮，而是把「禁止做什麼」講清楚：

1. 鎖定依據：明確要求「只能根據以下提供的資料回答，禁止使用你自己的訓練知識或推測」。
2. 給逃生口：規定「如果資料裡找不到答案，就直接說『目前知識庫裡查不到這個問題的答案』，不要硬掰」。
3. 要求標引用：每個重要事實後面附上來源編號，讓使用者能回頭核對，也方便你日後查錯。
4. 處理衝突：如果撈到的幾塊內容互相矛盾，要它明白指出衝突、並列出各自來源，而不是擅自選一個。

把「只能根據以下資料」「禁止使用訓練知識」「查不到就說查不到」這幾句寫進去，幻覺率通常會直接降一截。這也是 RAG 比直接微調模型更靈活的地方——同一套架構，換一份知識庫、換一段指令，就能服務完全不同的場景，文件更新了也只要重新切分入庫，不必重練模型。

系統能回答了，但「能回答」不等於「答得對」。最後一關，也是最多人省略的一關，是測試。

測試與驗收，怎麼知道它答得準不準

一般軟體測試有明確的對錯，輸入 A 就該輸出 B；RAG 不一樣，同一個問題，知識庫差個 1% 答案可能天差地遠，而且「看起來回答了」常常不等於「回答正確」。所以上線前一定要有一套系統性的驗收，不能靠隨手問兩句覺得「好像可以」就拍板。

先準備一組測試題。不要只靠團隊自己想，更好的來源有三個：從客服紀錄、搜尋 log 撈真實提問；把知識庫文件讀一遍、反推使用者讀完會想問什麼；再補一批邊界案例（文件裡根本沒答案的、含糊的、一次問兩件事的）。題量別太少，至少 50 題，而且分佈要均勻：約兩成是簡單事實查詢、四成需要理解後回答、兩成要結合多塊資訊推理、兩成是沒有標準答案的開放或邊界問題。特別提醒，PoC 階段只用幾十題拿到漂亮分數很容易，但上線遇到真實使用者千奇百怪的問法，準確率常會明顯掉下來，所以測試題務必涵蓋同義詞、跨文件、時間敏感這些刁鑽角落。

評估要分三層看，因為不同的錯要用不同的指標抓：

1. 檢索層——有沒有找到對的段落：看 Recall（該找到的相關段落，找回來了幾成）和 Precision（找回來的段落裡，真正相關的佔幾成）。這層錯了，後面再強都是蓋在沙灘上。
2. 生成層——找到的資料有沒有好好回答：看答案有沒有真的引用到正確的段落、有沒有答非所問。
3. 幻覺層——有沒有自己掰：這是最危險、也最容易被忽略的一層。系統可能語氣篤定地給出一個文件裡根本沒有的數字，使用者完全分辨不出來。

幻覺怎麼測？有個樸素但誠實的做法——對每個答案抽出一兩個具體聲明，回去文件裡查證有沒有這條資訊，沒有的就是幻覺。累積三五十筆，就能算出大致的幻覺率。如果系統在「文件裡沒有答案」的問題上經常自信地長篇大論，那個比例就是你最該優先處理的數字。一個實用的安全閥是設個門檻，把忠實度偏低的答案一律先送進人工審核，不直接回給使用者。

測試最大的價值不在某一次的分數，而在趨勢。固定每週用同一組題、同一個評審跑一次，盯著分數的走向——Recall 從 0.6 進步到 0.7，比任何單次測試都更有意義。沒有這套迴圈，知識庫上線後會慢慢腐爛，而你不會察覺。

上線前，用這五項自評表替知識庫打分

走完五關，知識庫已經能動了。但「能動」和「能上線」之間還隔著一段距離。下面這張表把前面每一關最容易翻車的點濃縮成五道自評題，上線前逐項對著看，沒把握的就回頭補，不要急著開給真實使用者用。

這五項不是一次過關就一勞永逸，而是要週期性回頭跑的健檢。文件會變、使用者的問法會變，知識庫的品質也會隨之漂移。把這張表變成每季一次的例行檢查，比你糾結該選哪一套向量資料庫重要得多。

一座會回答有依據的知識庫，八成的功夫在資料、兩成在技術。模型可以換、向量庫可以搬，但只要文件沒整理乾淨、切分沒切對、測試沒做足，再貴的架構也撐不起一個讓人敢信任的答案。回到開頭那個語氣篤定卻早就作廢的退換貨答案——它之所以出錯，從來不是模型不夠強，而是它根本沒看過你的文件。把這五關一關一關走扎實，從手上那幾百份 PDF 開始，你要的「有所本」自然就長出來了。