多數團隊導入 AI 問答系統時，心力幾乎都花在挑哪個大型語言模型最強，GPT、Claude、Gemini 輪流測過一輪，最後買下當下評分最高的那個。結果員工問一句「我們現在的退換貨規則是什麼」，AI 依然講得篤定又專業，答案卻是三個版本前就已經作廢的舊規則。問題從來不在模型不夠聰明，而是它根本沒看過你真正在用的那份文件。
RAG（Retrieval-Augmented Generation，檢索增強生成）就是一套讓 AI 先去你的知識庫翻到相關片段、再依這些片段回答的架構，目的只有一個，讓它講話有所本，不是憑訓練資料裡的常識自由發揮。做對了，員工能在幾秒內查到散落在各系統裡的內部知識；做歪了，AI 只會拿著錯的資料回答得更理直氣壯。
好消息是，蓋一座堪用的 RAG 知識庫，現在不用自架 GPU，也不用先養一個 AI 團隊，手上有幾百份文件、會串 API，就能一路走到能回答問題的系統。接下來就照這條資料流，從文件整理一路講到檢索架構怎麼補強、上線前怎麼驗收。
RAG 怎麼運作？搜尋和生成分成兩條線
RAG 做的事，一句話就能講完，就是把「找資料」和「寫答案」拆成兩個獨立的步驟，讓擅長檢索的歸檢索、擅長生成的歸生成。傳統上直接問 LLM，它只能靠訓練時記下來的東西回答；碰到公司專屬的政策、規格、流程，它沒看過，就只能用常識腦補。RAG 在它動筆之前插進一個檢索步驟，先把問題拿去一個存了公司文件的資料庫裡比對，撈出最相關的幾個段落，再連同問題一起交給 LLM。像是把閉卷考試換成開卷考試，模型不必死記硬背，只要照著翻到的那幾頁老實作答就好。
整條流程其實分成兩半。一半是離線先做好的建庫工作，把文件清乾淨、切成小塊、轉成向量、存進向量資料庫。另一半是使用者每次提問時才即時跑的查詢，問題也轉成向量，去資料庫裡找最接近的幾塊，組進提示詞交給 LLM 生成答案。前半段決定了答案的天花板，後半段決定了體驗順不順，這也是為什麼接下來每一關都值得拆得這麼細。
即使現在主流模型的上下文視窗都已經衝上百萬 token 級別，直接把幾百份文件整批塞進對話視窗依然不是解方。每問一次就要重新處理一次全部文件，成本壓不下來，而且沒辦法做權限分流，沒辦法讓某個員工只看到他有權限看的那份資料。RAG 的精神是只把相關的那幾塊丟給模型，速度、成本、精準度都會贏過整份硬塞。先從最容易被輕忽、也是離線第一步的地方開始，把文件整理乾淨。
文件進向量庫之前，先把資料整理乾淨
垃圾進、垃圾出，這句話套進 RAG 的世界會被放大好幾倍。一份排版混亂、夾雜頁首頁尾雜訊、表格被打散的文件，切完之後語意支離破碎，後面用再強的模型也救不回來。所以動手切分之前，第一步永遠是盤點與清理，不是急著開始切。
盤點要回答三個問題，哪些文件要進來、它們是什麼格式、多久更新一次。把 PDF、Word、Excel、網頁分門別類，標清楚哪一份是現行版、哪一份是早該淘汰的舊檔。這一步看起來像雜務，卻是整個專案最該由懂業務的人把關的環節，技術能告訴你「做得到」，但「哪份文件可信、哪份該丟」是業務判斷，不能丟給工程自己猜。
PDF 是最大地雷，依複雜度挑對解析方式
內部文件裡最常見、也最難處理的就是 PDF，因為它可能夾著掃描影像、複雜表格、雙欄排版。直接用陽春的文字抽取工具，常會把表格的欄列順序拆亂、把雙欄內容交錯讀成一團。處理方式要依文件複雜度分級：
- 純文字、單欄排版的 PDF，文字抽取工具直接處理就夠，成本最低，不必額外投入解析工具。
- 含表格的 PDF，要用看得懂版面結構的解析工具，把表格轉成 Markdown 或保留欄列對應的格式，不然「品項」和「金額」對不上，資料就整組報廢。
- 掃描件或圖片型 PDF，文字根本不是文字而是圖，得先跑一輪 OCR 辨識出來，才能接進後面的清理與切分流程。
清理的同時，別忘了替每一塊內容帶上溯源資訊，這段來自哪份文件、哪個章節、版本是哪一季、屬於哪個部門、權限等級是公開還是內部。這些標籤在後面做引用標註、做權限過濾時都會用到，現在不帶，之後要回頭補會非常痛。文件整理好、metadata 也貼齊了，下一步就要面對整個 RAG 流程裡影響最大的一個環節，切分。
切分策略決定了檢索的天花板
把長文件切成一塊塊餵進向量庫，這個動作叫 chunking，它對檢索精度的影響大到不成比例。一份切得好的文件，每一塊都是一個完整語意單元；切壞了，相關內容被打散到不同塊，檢索時就怎麼也湊不齊。
最常見的失誤，是直接拿通用工具的預設值切完就交差。那種固定字數硬切的做法，會把句子攔腰斬斷、把「條件」和「結果」拆到兩塊去。比較穩的起手式是遞迴式切分，作法是一層一層退讓，先照段落切，切不下去再退到句子，句子還嫌長才退到標點符號，盡量選在語意完整的邊界斷開。
塊大小怎麼抓？業界常見的安全範圍落在 300 到 800 個 token，重疊設在 10% 到 20%。重疊的作用是避免一個完整概念剛好被切在兩塊交界處而兩邊都不完整，留一段共用的緩衝，概念至少會完整出現在其中一塊裡。NVIDIA 針對金融文件做過一次測試，在 FinanceBench 這個資料集、區塊大小抓 1024 個 token 的條件下，重疊比例落在 15% 表現最好。同一組參數沒有標準答案，得依文件性質微調，但落在上面這個區間通常是穩定的起點。
不同文件其實適合不同切法，不必全庫統一：
| 文件類型 | 建議切法 | 為什麼適合 |
|---|---|---|
| 客服對話、系統 log | 固定字數切分 | 每則訊息長度接近，切齊了速度快也好預測 |
| SOP、操作手冊、合約條款 | 遞迴式切分 | 每一條款、每個步驟本身就是天然的語意邊界 |
| 研究報告、長篇論述 | 語意切片 | 保留完整的論證脈絡，代價是運算成本較高 |
一個實用的小原則，像 SOP、操作教學這類有步驟的內容，以「一組步驟」當一塊，會比把整份 SOP 塞進同一塊好用得多。切分沒有唯一正解，但有一條鐵律，切完一定要回頭抽幾塊出來讀讀看，確認每塊單獨拿出來都還讀得懂。切好的文字塊，接下來要變成機器能比對的形式，這就進到向量化與向量資料庫的選型。
向量化之後，要挑一個撐得住的向量資料庫
向量化（embedding）就是把一段文字轉成一串數字，讓「意思相近」變成「數字相近」。假設只用三個數字簡化描述一個詞，「咖啡」是〔0.9、0.1、0.4〕、「拿鐵」可能是〔0.85、0.15、0.42〕，兩者在數字空間裡靠得很近，因為意思相關；換成「颱風」，位置就會差得很遠。真實的 embedding 不會只有三個數字，而是上千維，但原理一樣，一旦每段文字都變成向量，系統就能用同一套規則計算誰跟誰最接近，這正是檢索的基礎。
這一步用 API 就能完成，不必自己訓練模型，把每一塊文字送過去，把回來的向量連同 metadata 一起存好即可。選 embedding 模型時，真正該看的不是排行榜上的分數，而是兩件事，對中文的支援度夠不夠好、需不需要私有部署。資料完全不能外流，就選能自架的開源模型；可以用雲端 API，主流的多語言 embedding 服務對繁體中文已經堪用。
向量算好了，得有地方存。向量資料庫是專門儲存向量、並能快速找出「最相近的前幾個」的系統，選型不必妖魔化，照規模和現況挑就好：
| 向量資料庫 | 適合誰 | 特性 |
|---|---|---|
| pgvector | 已經在用 PostgreSQL 的中小團隊 | 向量查詢可直接和業務資料表關聯，省一層維運 |
| Qdrant | 要顧到精準過濾、規模持續成長的團隊 | 開源自架或雲端都成熟，metadata 過濾效能好 |
| Pinecone | 沒有基礎設施團隊、想零維運 | 全託管，量小時方便，量大時成本會明顯墊高 |
規模拿捏可以參考公開數據。Timescale 團隊做過一次 pgvectorscale 與 Qdrant 的公開效能測試，在 5000 萬筆向量、99% 召回率的設定下，Postgres 搭配 pgvectorscale 每秒能處理約 471 次查詢，Qdrant 約 41 次；但反過來看，Qdrant 建立索引只花約 3.3 小時，pgvectorscale 卻要 11 小時以上，尾端延遲的波動也更小。沒有絕對贏家，只有適合的取捨，查詢吞吐量優先就偏 pgvector，索引更新頻繁、要穩定的尾端延遲就偏 Qdrant。對多數剛起步、文件量還在幾百到幾萬份的團隊，資料本來就在 PostgreSQL 的話，從 pgvector 起手通常最省事，等到規模真的長大了，再考慮搬家也不遲。
做到這裡，整個離線建庫的工作已經告一段落。但光是找得到相關段落還不夠準，這就要靠下一關補上。
只找得到還不夠，混合檢索和重新排序怎麼補上精準度？
單靠向量相似度搜尋，其實有個天花板。使用者搜尋帶著明確關鍵字或料號、縮寫時，例如「B2302 型號的保固期限」，向量檢索容易找出一堆語意相關、卻沒真正命中那個關鍵字的模糊內容。原因是向量比對抓的是「意思」，不是「字面」，遇到專有名詞或精確代碼，反而是老牌的關鍵字比對更可靠。
解法是混合檢索（hybrid search），讓向量搜尋和關鍵字比對同時跑，向量那路負責理解語意與問句背後的概念，關鍵字那路負責咬住專有名詞與代碼，兩邊找出來的候選段落合併起來，通常會比單靠一種方式更完整。但候選變多了，也需要一道工序把真正相關的挑出來，這就是重新排序模型（reranker）的工作，把兩路找出來的候選清單重新打分，用比向量比對更精細的方式判斷每一段跟問題的相關度，篩出真正該送進生成階段的前幾筆。
Qdrant 官方的一份 RAG 評測指南，把檢索層的評估拆成兩個指標，Recall（該找到的相關段落，找回來了幾成）和 Precision（找回來的段落裡，真正相關的佔幾成）。混合檢索加重新排序，本質上就是同時想拉高這兩個指標，單靠向量搜尋常常是 Recall 過得去、Precision 卡住，找到一堆看似相關其實答非所問的內容；補上關鍵字比對和重新排序，就是在補 Precision 這一塊。這一步做不做，往往是知識庫「堪用」和「好用」之間最明顯的分水嶺。串起來的整個檢索管線還沒完，資料裡混雜著不同部門、不同機密等級的文件，找得再準，也不能讓不該看到的人看到。
權限控管要顧在檢索那一關，不是回答之後
多數團隊到系統快上線才想起權限問題，這時候補救往往已經來不及。核心原則是，存取控管必須發生在向量資料庫查詢的當下，而不是等生成完答案之後才過濾。模型一旦讀到了不該讀的內容，傷害就已經造成，事後在應用層攔截容易被繞過，也擋不住模型已經把內容組進答案裡的事實。
做法要從資料進來的那一刻就開始，每份文件進入知識庫時，就帶上權限相關的 metadata，包含誰可以看、屬於哪個部門、機密等級是公開還是內部。文件被切分成一塊塊之後，每個區塊都要繼承來源文件的權限標籤，這也呼應前面提過的溯源資訊，權限等級本來就該是那批標籤的一部分。查詢時，向量資料庫要能同步用這些 metadata 做過濾，確保回傳的候選段落一開始就不包含使用者無權查看的文件，而不是撈出來之後再靠應用程式手動篩掉。
還有一個容易被忽略的維運挑戰，使用者的部門或職務一旦異動，知識庫的存取權也要跟著同步更新，不管是即時串接身分系統，還是定期跑一次同步排程，都要確保這個時間差不會拉得太長，否則離職員工或轉調的同事，還是能透過知識庫查到不該看的內容。權限顧好了，資料才能放心送進下一步，交給 LLM 生成答案。
串接 LLM 之後，怎麼讓它老實照著資料講？
檢索到正確的段落，不代表 LLM 就會乖乖根據那些段落回答，這一步沒做好，前面所有功夫都會在最後一關漏氣。
即時查詢的流程是這樣，使用者問了一句話，系統先把這句話轉成向量，拿去向量庫和關鍵字索引裡找出最相近的幾塊，通常取前 3 到 5 塊，再把這幾塊連同原始問題、一段指令，組成一份提示詞交給 LLM，由它整理成一段通順的答案。
真正的成敗點在那段指令怎麼寫。很多團隊把提示詞寫成「請參考以下資料回答」，問題就出在「參考」這兩個字，模型會把它解讀成「可以加上自己的看法」，於是又開始腦補。要把規則寫死、寫狠，重點不是寫得漂亮，而是把「禁止做什麼」講清楚：
- 鎖住回答依據：直接寫明「只能根據以下提供的內容作答，不能使用你自己的訓練知識或憑經驗猜測」。
- 留一個誠實出口：告訴模型「如果資料裡沒有答案，就照實說目前查不到，不要硬掰一個聽起來合理的答案」。
- 逼它交代出處：要求每個關鍵事實後面附上對應的來源或段落編號，方便使用者回頭核對。
- 教它處理矛盾：如果撈到的幾段內容彼此衝突，要模型明講這裡出現不一致，並列出各自的來源，而不是自己選一個當標準答案。
把這幾條寫進提示詞，幻覺的情況通常會明顯收斂。這也是 RAG 比直接微調模型更靈活的地方，同一套架構，換一份知識庫、換一段指令，就能服務完全不同的場景，文件更新了也只要重新切分入庫，不必重練模型。這套向量檢索加提示詞的組合，已經能應付多數企業內部問答，但遇到需要跨文件串連推理的問題，還有一層更進階的架構可以補上。
要不要加一層知識圖譜？GraphRAG 和向量檢索怎麼分工？
向量檢索再加混合搜尋，多數情境已經夠用，但有一種問題型態它天生答不好，需要串起多份文件才能拼出答案的多跳推理，例如「這個供應商同時也供應哪些會影響到另一個專案交期的原料」。這種問題沒有單一段落能直接命中，向量相似度搜尋比對的是「這段話跟問題像不像」，不是「這些實體之間有什麼關係」，遇到需要跨文件串連的推理，就容易漏接。
知識圖譜補的正是這一塊，把實體與實體之間的關係，明確建成節點與邊的資料結構，能沿著「供應商到原料到專案」這樣的關係鏈路查詢，而不是只靠語意相似度瞎猜。這種把知識圖譜整合進 RAG 架構的做法，業界近來稱為 GraphRAG，也是目前 RAG 架構一個明顯的走向，不少團隊開始把知識圖譜和向量檢索合併使用，向量負責廣度，圖譜負責深度，兩者互補而不是二選一。
但知識圖譜不是免費的升級。建置一套堪用的知識圖譜，需要投入本體設計的時間成本，也就是定義哪些是實體、實體之間有哪些關係類型，往往是以週甚至以月計算，遠高於架一套向量檢索管線只需要幾天的工夫。判斷自己需不需要，最實際的做法是先盤點真實的提問分布，多跳推理與跨文件比對的問題如果只佔一小部分，向量檢索加重新排序已經綽綽有餘；只有這類問題確實佔了相當比重，才值得投入知識圖譜這筆額外的建置成本。架構決定了知識庫能做到什麼程度，但做到了不代表做對了，上線前還有一關驗收要走。
上線前的測試與驗收，怎麼知道它答得準不準？
一般軟體測試有明確的對錯，輸入 A 就該輸出 B；RAG 不一樣，同一個問題，知識庫差一點點，答案可能天差地遠，而且「看起來回答了」常常不等於「回答正確」。所以上線前一定要有一套系統性的驗收，不能靠隨手問兩句覺得「好像可以」就拍板。
先準備一組測試題，不要只靠團隊自己想，更好的來源有三個，從客服紀錄、搜尋 log 撈真實提問；把知識庫文件讀一遍、反推使用者讀完會想問什麼；再補一批邊界案例，像是文件裡根本沒答案的、問法含糊的、一次問兩件事的。題型要涵蓋簡單的事實查詢、需要理解後才能回答的問題、要結合多塊資訊才能推理出來的問題，以及沒有標準答案的開放或邊界問題，四種都要有，不要全部都是最簡單那種。PoC 階段只用幾十題拿到漂亮分數很容易，但真實使用者千奇百怪的問法上線後才會冒出來，測試題務必涵蓋同義詞、跨文件、時間敏感這些刁鑽角落。
評估要分三層看，因為不同的錯要用不同的指標抓：
- 檢索層，有沒有找到對的段落，看 Recall 和 Precision，這層錯了，後面再強都是蓋在沙灘上。
- 生成層，找到的資料有沒有好好回答，看答案有沒有真的引用到正確的段落、有沒有答非所問。
- 幻覺層，有沒有自己掰，系統可能語氣篤定地給出一個文件裡根本沒有的數字，使用者完全分辨不出來。
幻覺怎麼測？有個樸素但誠實的做法，對每個答案抽出一兩個具體聲明，回去文件裡查證有沒有這條資訊，沒有的就是幻覺，累積三五十筆就能算出大致的幻覺率。一個實用的安全閥，是設個門檻，把忠實度偏低的答案一律先送進人工審核，不直接回給使用者。
Barnett 等人 2024 年一篇專門研究 RAG 系統失敗模式的論文，拿三個不同領域，研究、教育、生醫的實際案例做分析，歸納出七個常見的失敗點，其中兩個結論特別值得記住，一是 RAG 系統的驗證只有在系統真正上線運作後才做得到，光靠上線前的測試永遠不夠完整；二是系統的穩健度是隨時間演進出來的，不是一開始設計時就能一次到位。這也是為什麼測試不是做一次就結束，固定每週用同一組題、同一個評審跑一次，盯著分數的走向，Recall 從 0.6 進步到 0.7，比任何單次測試都更有意義。沒有這套迴圈，知識庫上線後品質會慢慢流失，而你不會察覺。
走完這幾關，知識庫已經能動了，但「能動」和「真正可靠」之間還隔著一段距離。回到最前面那個反例，換上再強的模型，答案準不準終究是由文件整理得夠不夠乾淨、切分切得夠不夠好、檢索架構能不能兼顧精準與權限決定的。模型可以換，向量資料庫也可以搬家，但文件沒整理乾淨、切分沒切對、測試沒做足，再貴的架構也撐不起一個讓人敢信任的答案。與其急著挑下一個更強的模型，不如先把手上這幾百份文件整理好，那才是真正決定這座知識庫好不好用的起點。