2026-09-21

RAG 是什麼：企業知識庫問答怎麼做

RAG 是什麼？本文從適用場景、資料治理、文件切塊、混合檢索、重排序到效果評估，系統講解企業知識庫問答如何落地。

一、先判斷是否該用 RAG：它解決的是知識供給，不是所有智慧化問題

企業評估 RAG 時，首先要確認問題是否真的出在「模型拿不到正確資料」。RAG 的核心作用，是在回答前從外部知識源選取相關內容，再讓模型基於這些內容組織結論。它適合補充企業內部知識和時效性資訊，但不能替代計算系統、業務流程或資料治理。

一個場景是否適合採用 RAG，可以先檢查三個條件。第一，答案依賴企業私有資訊，或者所需知識會頻繁變化，例如制度檔案、產品手冊、專案記錄和內部案例。第二，問題存在可供查證的資料依據，而不是只能依靠主觀判斷。第三，業務要求說明結論來自哪裡，使用者需要檢視原文、版本或發布日期。三個條件大體成立時，把知識保留在外部資料庫中並按需檢索，通常比將知識固化進模型參數更容易更新，也更便於追溯。

反過來，如果答案來源不明確，企業長期沒有沉澱相關材料，或者不同文件之間本身相互矛盾，引入 RAG 只會更快地暴露知識缺口。向量索引能夠幫助尋找內容，卻不能創造不存在的事實，也不能自動判斷哪一份衝突檔案具有最終效力。此時應先補齊資料、確定責任部門和版本規則，而不是直接建設檢索鏈路。

這些方案並不互斥。例如，客服助手可以用 RAG 查詢售後政策，用訂單介面讀取當前狀態，再通過工作流發起申請。關鍵是把「知識問答」和「確定性操作」分開：模型可以解釋規則，但金額計算、權限校驗和交易提交應由可測試的程式完成。只把所有能力都接到向量資料庫上，容易產生看似完整、實際不可執行的回答。

超長上下文同樣不能消除檢索的必要性。將大量檔案整體放入提示詞，看似減少了檢索環節，實際會擴大輸入成本，並把無關章節、重複版本和衝突表述一併交給模型。長文本中的關鍵資訊還可能因位置和噪聲而未被充分利用。對企業系統而言，更穩妥的組合是先縮小資料範圍，再使用較長上下文完成跨段落比較、摘要和推理。

是否採用 RAG，最終可以歸結為一個工程問題：答案能否在受控資料中找到，並且是否值得為這些資料建立更新、權限、引用和評估機制。如果問題沒有可驗證的標準答案，應設計人工判斷或專家審核；如果流程必須嚴格執行，應呼叫規則引擎、資料庫和介面；如果知識源殘缺，則先治理內容。只有當主要瓶頸確實是「正確資料沒有在正確時間進入模型上下文」時，RAG 才是對症方案。

二、資料治理先於向量化：知識庫品質決定答案上限

向量模型只能判斷文本是否相近，不能替企業裁決哪份檔案有效。若知識庫同時儲存現行制度、歷史版本和未經審核的經驗記錄，檢索越充分，衝突內容反而越容易一起進入上下文。上線前應先解決知識來源、適用範圍和生命週期問題，再討論嵌入模型與向量庫。

先給知識源排優先順序

第一步不是匯入檔案，而是建立知識源清單。每類來源都要明確責任部門、更新方式、審核狀態和衝突處理規則。權威等級不宜簡單按檔案格式劃分，而應依據業務場景確定。例如，正式制度通常高於個人筆記；產品規格應以已發布版本為準；FAQ 可以解釋標準文件，但不應覆蓋其中的約束條件；工單適合補充案例，不應自動成為通用結論。

後設資料不是裝飾，而是檢索邊界

欄位值應使用受控列舉，避免同一部門或產品出現多種寫法。這些資訊一方面用於檢索前過濾，另一方面支撐引用展示、訪問授權和過期治理。

否則，一份文字高度相似但適用於其他市場的規定，很可能排在正確答案之前。

入庫要保留文件結構與證據位置

企業文件不能直接抽取成連續純文本。可靠的入庫流水線通常需要處理以下環節：

• 識別正文區域，清除重複頁首、頁尾、水印和目錄噪聲；
• 保留章節標題及父子層級，使片段仍能解釋自身所處語境；
• 解析表格的行列關係，關聯正文中的附件、圖示和腳註；
• 檢測跨檔案或跨頁面的重複內容，避免同一結論擠佔召回結果；
• 記錄檔案標識、頁碼、段落路徑和字元區間，便於回到原文核驗。

解析品質應通過抽樣驗收，而不是只看任務是否成功。重點檢查表格是否錯位、標題是否丟失、附件是否斷鏈，以及否定條件、例外條款是否被切散。只保留語義文本卻丟失原始位置，會讓引用看似存在，實際無法審計。

讓索引狀態跟隨源系統變化

RAG 可以在不調整模型參數的情況下更新外部知識，但「可更新」不等於「自然一致」。入庫流程必須覆蓋新增、修訂、失效、撤回和刪除，併為每次變更儲存來源標識、處理時間與索引狀態。

工程上還應設定同步延遲、解析失敗、版本並存和孤立片段等監控項，並定期從源系統反查索引。判斷資料治理是否合格，可以用一個直接標準：任何答案片段都能說明來自哪裡、適用於誰、何時有效，並能在源文件撤回後按約定時限停止被召回。

三、切塊與索引設計：不要用一個固定參數處理所有文件

切塊不是把長文本裁成模型能接收的長度，而是為檢索構造可獨立判斷、可準確引用的知識單元。真正需要最佳化的問題是：使用者提出一個具體問題時，系統能否召回包含完整條件、結論與適用範圍的片段。若只按固定字數截斷，條款中的例外說明、操作步驟的前置條件、表格中的欄位含義都可能被拆開。

塊太大時，檢索結果可能命中主題，卻把大量無關段落一併送入模型，相關證據反而被稀釋；塊太小時，召回內容看似精確，卻缺少條件、例外或結論，模型只能自行補足缺口。相鄰塊重疊可以減少句子恰好落在邊界上的問題，但無法修復錯誤的文件結構。例如，一條制度的正文與但書被分到兩個片段，即使設定重疊，也未必能保證兩者同時進入候選集。

工程實踐中常從數百 token 量級設定多組候選塊長，並配置一定的相鄰重疊，再用真實問題集比較效果。這些參數只能作為實驗入口，不是跨文件通用的最佳配置。更穩妥的實現是先識別標題層級、列表、條款、問答對和表格，再對過長的語義單元做二次切分；過短片段則可與父級摘要或標題路徑組合後參與檢索。

索引也不應等同於「文本加向量」。每個知識片段至少應儲存以下資訊：

• 可供生成模型閱讀的正文，以及經過規範化的檢索文本；
• 文件標題、章節層級和父子片段關係；
• 穩定的文件標識、片段標識與原文頁碼或段落位置；
• 發布時間、更新時間、有效狀態和業務版本；
• 部門、角色、密級等權限標籤；
• 關鍵詞、實體或其他可用於過濾和關鍵詞檢索的欄位。

向量適合發現語義近似內容，但對精確編號、產品型號、縮寫、日期和專有名詞未必穩定。因此，正文倒排索引、結構化過濾條件與向量欄位應並存。標題路徑還能在生成階段補足語境，例如同樣名為「審批條件」的片段，位於採購制度和費用制度時含義並不相同。

最後，索引必須具備重建和回滾能力。每次發布應記錄原始文件批次、解析器版本、切塊規則、文本清洗邏輯、Embedding 模型及索引配置，並保留片段到原文的對映。模型升級後若召回率下降，團隊才能判斷問題來自文件解析、塊邊界變化、向量表示變化，還是索引過濾配置。沒有版本記錄的知識庫一旦效果波動，通常只能全量重做，難以完成可驗證的修復。

四、從使用者問題到有效召回：用混合檢索解決「搜不到」和「搜不準」

企業 RAG 的線上鏈路不應從向量查詢直接開始。使用者輸入往往不是一個合格的檢索式：它可能省略產品名稱，把錯誤現象寫成口語，沿用上一輪對話中的指代，或者混入版本、地區、崗位等隱含條件。若原問題未經處理就送入索引，後續即使增加召回數量，也只會得到更多表面相似、實際不適用的文本。

第一步應把對話輸入整理成可獨立理解的問題。查詢處理模組需要提取使用者真正要完成的任務，並補齊對象範圍、適用版本、時間條件和使用者身份。例如，「這個報錯怎麼處理」應結合會話歷史還原為具體產品、版本和錯誤碼。縮寫、內部別名和口語稱呼可以對映到知識庫中的標準術語，但原始詞也應保留，避免改寫時丟失精確線索。

複雜問題不宜強行壓成一個檢索式。若問題同時要求查規則、找資料並比較差異，可拆成若干子查詢分別召回，再在生成階段合併證據。拆分的價值不是讓問題變短，而是避免多個檢索目標互相干擾。實施時應保留子查詢與原問題的對應關係，否則模型可能只回答其中一部分。

因此，企業知識庫通常應並行執行向量檢索和 BM25，再用排名融合彙總候選，而不是只選其中一種。包含錯誤碼、型號或條款編號時，可提高關鍵詞結果的影響；故障描述、流程諮詢等自然語言問題，則可適當偏向語義召回。還要做候選去重，避免同一文件的相鄰切塊佔滿上下文。

使用者所屬組織、訪問級別、業務地區、產品版本以及文件有效期，都應成為索引後設資料。檢索時先限定可用範圍，再在範圍內計算相關性。否則，系統可能召回內容正確但使用者無權檢視的檔案，或引用已經廢止、尚未生效、僅適用於其他地區的規定。僅在提示詞中要求模型「不要洩露」不能替代訪問控制。

• 檢查「搜不到」：目標證據是否進入索引，查詢是否被錯誤改寫，關鍵詞與語義通道是否至少有一路命中。
• 檢查「搜不準」：高排名結果是否滿足產品、版本、地區、時效和權限條件，而不只看文本相似度。
• 記錄召回軌跡：儲存原問題、改寫結果、子查詢、過濾條件及各通道排名，便於復現失敗案例。

對於需要沿多個實體關係查詢證據，或要求從大量文件歸納整體主題的問題，可以評估 GraphRAG。它通過實體與關係組織知識，更適合跨文件關係鏈和全域性分析，但代價包括實體消歧、關係更新、圖查詢維護以及更長的響應鏈路。工程上應先用問題集驗證普通 RAG 的缺口：如果失敗主要來自查詢改寫、過濾條件或混合檢索配置，建設圖結構不會解決根因。只有當核心問題確實依賴多跳關係或全域性結構時，額外複雜度才可能值得承擔。

五、重排序與答案生成：避免「召回了資料，仍然答非所問」

檢索命中並不等於證據可用。第一階段檢索更像「擴大排查範圍」：寧可帶回少量噪聲，也不要過早漏掉關鍵材料。真正決定哪些內容進入模型上下文的，應是後續重排序。Reranker 會聯合讀取使用者問題與候選文件塊，重新判斷兩者是否語義匹配，而不是繼續依賴向量距離。

企業語料規模較大時，不宜讓計算成本較高的精排模型掃描全部內容。更可控的做法是級聯處理：先用關鍵詞檢索、向量檢索等方式快速取得較寬的候選集合，再由輕量模型排除明顯無關項，最後通過 Cross-Encoder 一類模型做精細排序。每一層都應記錄候選數量、耗時與淘汰原因，便於判斷品質損失發生在哪個環節。

重排序不能只看「主題相近」。例如使用者詢問某項制度的生效條件，一段介紹制度背景的文字可能語義高度相關，卻無法回答條件是什麼。評分時應額外考慮以下因素：

• 內容能否直接支援問題所要求的結論，而非僅僅出現相同主題；
• 資料是否處於有效期內，版本、地區和適用對象是否一致；
• 來源層級是否可靠，例如正式制度檔案應優先於會議紀要或個人筆記；
• 文件塊是否包含完整條件、例外條款和限定範圍，避免只取到半句結論。

進入生成階段前，還需要一次上下文編排。按相關性分數機械拼接，常會造成同一段內容重複出現、條款與標題分離，或把解釋文字放在規則正文之前。工程上應先消除重複片段，將連續且屬於同一章節的塊合併，再補入標題、文件版本、發布時間以及理解當前段落所必需的前文。若令牌預算不足，應優先保留能夠直接作答、來源明確且時效正確的材料，而不是平均壓縮所有候選。

生成提示應被當作一份可測試的回答協議，而不是一句「請根據資料回答」。對影響審批、合規或業務執行的結論，還應附帶原文片段及文件位置，使使用者可以回到來源複查。

引用本身也需要校驗。模型生成的引文編號必須對應實際進入上下文的材料，引用片段應確實支援相鄰結論，不能只證明相關背景。

出現錯誤答案時，先定位故障層級，再決定改哪裡。把所有問題歸因於「大模型不夠強」，通常會導致無效調參。

因此，這一階段的驗收不應只看最終回答「像不像對的」。還要分別檢查正確證據是否進入候選集、精排是否把它提升到可見位置、上下文是否保留完整語義，以及結論能否逐項追溯到證據。只有把這條鏈路拆開觀測，答非所問才會從偶發體驗問題變成可以定位和修復的工程問題。

六、答案評估與營運閉環：分別測檢索、生成和業務結果

RAG 評估不能從模型自擬的問題開始。每條樣本除參考答案外，還要標註作答所需的證據、答案適用的產品或時間範圍、存取權限，以及是否應當拒答。否則，系統可能給出內容正確但版本不對、越權或缺少前提的回答，綜合得分卻看不出問題。

樣本覆蓋面比樣本數量更重要。至少要納入簡稱與別稱、輸入錯誤、上下文省略、多輪追問、新舊制度衝突、不同角色權限、需要合併多份材料才能回答的問題。還應專門建設不可回答集，例如知識庫尚未收錄、問題條件不足、證據相互矛盾或使用者無權檢視的內容。拒答不是異常分支，而是企業問答的基本能力。

正確證據未進入候選集，通常應檢查查詢改寫、索引或召回策略；證據已召回卻沒有進入最終上下文，問題更可能出在重排序或上下文拼裝；上下文完整但答案錯誤，則應繼續檢查提示約束、引用機制和模型生成。只有分層記錄，失敗才能被歸因，而不是被籠統歸為「模型效果不好」。

引用也要單獨核驗。回答附帶來源，並不等於來源支援結論。評估時應檢查引用片段是否真的包含對應事實、是否指向當前有效版本，以及一條引用是否被錯誤地用於支撐多個結論。能夠定位到具體知識片段的價值，不只是方便使用者核查，也讓團隊可以反向找到過期、衝突或表述含糊的原始材料。

離線評測用於比較方案，例如調整切塊邊界、替換檢索方法或修改排序規則後，觀察各類問題的變化；線上資料則用於判斷系統有沒有產生業務收益。兩者不能互相替代：離線命中改善，不代表使用者更快解決問題；人工轉接減少，也可能只是使用者放棄繼續提問。因此應結合會話完成情況、後續追問和負面回饋分析。

營運閉環的核心是建立可歸因的失敗佇列。知識缺失或衝突迴流到內容治理，問法未被理解進入查詢改寫，語義被截斷進入切塊最佳化，目標材料未出現進入召回調整，相關材料排序靠後進入重排序處理，有證據仍答偏則進入上下文組織與提示策略最佳化。每個案例應保留問題、權限、知識版本、召回結果、最終上下文和模型輸出，避免只儲存一段錯誤答案。

任何變更上線前都應執行固定迴歸集，並按問題型別檢視差異。局部參數可能修復某類問法，卻讓舊版本識別、權限隔離或多文件回答退化。成熟的 RAG 營運不是不斷調高一個分數，而是讓每次失敗都有歸屬、每次修改都能驗證、每次上線都知道改善了什麼，又可能影響什麼。

七、FAQ：企業建設 RAG 時的常見問題

有了超長上下文，還需要 RAG 嗎？

需要，但兩者不是替代關係。上下文視窗變長，解決的是模型單次能夠接收多少材料；RAG 解決的是從企業知識中挑出哪些材料值得送入模型。若把大量文件直接塞進提示詞，工程上可能增加處理負擔，並影響權限管理和證據利用。長文本中部的資訊也可能較難被模型穩定利用，即常說的「中間資訊丟失」。

更穩妥的做法是先通過 RAG 縮小證據範圍，再讓長上下文承擔跨章節閱讀、多文件比較和複雜歸納。只有在資料集合較小、內容相對固定、單次任務確實需要通讀全文時，直接使用長上下文才可能更簡單。例如分析範圍明確的合同材料，可以整體輸入；從大規模合同庫中回答條款問題，則應先檢索。

RAG、微調和企業搜尋應該怎樣選擇？

先區分要改變的是知識、行為，還是資訊獲取方式：

實際專案常組合使用：搜尋負責發現與導航，RAG 基於證據生成解釋，微調約束模型的任務行為。不要因為「回答不準」就直接微調；如果根因是資料缺失或檢索失敗，訓練無法補回正確證據。

向量檢索命中了相似內容，為什麼答案仍然不對？

「語義相似」不等於「可用於作答」。命中的片段可能主題一致，卻在產品版本、適用地區、客戶等級或生效時間上不符合問題；也可能只召回結論，遺漏定義、例外條件和上下文。另一類問題發生在生成階段：證據已經存在，但排序靠後，被無關片段干擾，或者模型把多個來源錯誤拼接。

排查時應分層檢視鏈路，而不是只讀最終答案：

• 先確認正確文件是否進入候選集；沒有進入，檢查切塊、查詢改寫、關鍵詞召回和後設資料過濾。
• 再確認正確片段是否排在模型實際可見的位置；排序不佳時，引入重排序並降低重複片段佔比。
• 最後檢查答案是否嚴格受證據約束；要求給出來源、區分事實與推斷，並在證據不足時明確拒答。

企業 RAG 上線前至少要評估哪些指標？

不能只用「回答看起來不錯」驗收。應建立來自真實業務問題的測試集，並把指標拆成三層：

• 檢索層：正確證據能否進入候選結果、排序是否靠前、權限與時間等過濾條件是否準確、召回內容是否存在大量重複。
• 生成層：答案是否得到證據支援、引用能否對應原文、是否完整覆蓋問題、證據不足時能否拒答，以及是否出現無依據補充。
• 業務層：任務完成率、人工轉接情況、使用者修正頻率、響應時延與單次呼叫成本。

上線後持續收集低評分、追問與人工改寫記錄，判斷問題究竟出在知識源、召回、排序還是提示與生成。只有能定位錯誤所在環節，RAG 才具備可營運性，而不是一次性的演示系統。