2026-09-22

RAG 是什麼技術：企業知識庫問答怎麼實現

RAG 是什麼技術？本文從文件處理、索引召回、查詢重排序、答案生成、效果評估與權限治理出發，系統講解企業知識庫問答如何實現及生產化落地。

一、企業是否應該採用 RAG：先判斷問題，而不是先選向量資料庫

判斷是否需要 RAG，首先要看知識如何變化、答案能否追溯，以及不同使用者可見的內容是否一致。向量資料庫、嵌入模型和重排序器只是實現元件，不能替代場景判斷。若問題本身不需要外部知識檢索，提前搭建複雜索引只會增加維護環節。

RAG 更適合承載「持續變化且必須有依據」的事實知識。典型場景包括內部制度諮詢、產品故障支援、工程文件查詢、合同與合規條款核驗。這些內容往往沒有進入通用模型的訓練資料，或者在模型訓練完成後仍頻繁修訂。此時，系統應在每次請求發生時讀取當前有效資料，並保留答案與原文之間的對應關係，而不是試圖讓模型永久記住企業事實。

長上下文與 RAG 並非替代關係。對於幾份固定材料的總結、比較或審閱，將全文直接交給模型通常更簡單。但隨著資料規模擴大，完整塞入上下文會帶來更多 token 消耗，也可能使關鍵資訊被大量無關內容稀釋。若還要按部門、專案或密級過濾資料，檢索層就成為必要的控制點。常見做法是先召回少量高相關證據，再讓模型在較長上下文中完成綜合分析。

微調也不應被當作企業知識更新通道。制度版本、價格規則或產品參數一旦變化，重新準備樣本並訓練模型既慢，也難以確認舊事實是否被徹底覆蓋。微調更適合統一措辭、輸出欄位、拒答方式和任務流程。較穩妥的分工是：RAG 負責提供可更新、可引用的事實，微調或提示工程負責約束模型如何使用這些事實。

GraphRAG 則適用於另一類難題：答案並不直接存在於某個段落中，而要把分散文件裡的人員、組織、裝置、事件等關係串聯起來。Microsoft Research 的相關工作展示了以實體關係圖支援跨資料推理的路徑。但圖譜抽取需要處理實體消歧、關係校驗和增量維護，查詢鏈路也更長。因此，除非評測已經證明向量檢索在多跳問題上存在穩定缺口，否則不應把 GraphRAG 作為預設架構。

立項前可以用四個問題做快速篩選：知識是否經常更新，回答是否必須附帶來源，資料是否需要按使用者權限隔離，單次問題是否只涉及文件中的局部內容。多數答案為「是」時，RAG 通常值得投入；若只是偶發地處理少量固定文本，先採用長上下文往往更經濟。架構選擇應從答案責任和知識生命週期出發，而不是從資料庫型別出發。

二、文件處理：多數 RAG 問題在檢索前就已經產生

RAG 的離線處理不能被簡化為「抽取文字、切成幾段、計算向量」。檢索系統只能使用已經進入索引的資訊：標題關係被破壞、表格欄位錯位、舊制度未下線，後續即使更換檢索演算法或大模型，也只能在失真的語料上尋找答案。工程上應先建立統一的資料接入流水線，再討論索引參數。

第一步是將不同來源轉換成統一但不失結構的中間格式。PDF、Word、網頁、郵件、工單與資料庫記錄的儲存形式不同，解析後至少要區分正文、標題、列表、表格、附件和分頁位置。掃描版檔案需要先執行 OCR，並保留頁碼或區域座標，便於定位原文。表格不能簡單按視覺順序拼成一串文本，否則模型可能無法判斷某個數值對應哪一列；更穩妥的做法是讓表名、列頭、行標識與單元格內容形成可獨立理解的記錄。

第二步是清洗，但清洗目標不是讓文本「看起來整齊」，而是消除會誤導檢索的內容。頁首、頁尾、版權模板、導航選單和郵件簽名可能在每頁重複出現，容易因高頻而佔據召回結果；亂碼和解析殘片會降低關鍵詞與向量表示的品質；重複檔案、過期頁面及失效條款則可能讓系統給出已經不適用的結論。刪除前應保留原始檔案及處理記錄，以便出現爭議時復現資料鏈路。

每個文件和文本塊還應攜帶可用於判斷適用範圍的後設資料，例如來源地址、檔案標識、版本號、發布與生效日期、歸屬部門、保密等級、適用產品及解析時間。後設資料不是附加說明，而是後續檢索過濾、答案引用、增量更新和訪問控制的基礎。若只儲存正文，系統很難區分「內容相似」與「當前使用者可以使用且仍然有效」。

第三步是按內容結構分塊。固定字元長度可以作為兜底策略，但不應成為所有文件的統一規則。制度檔案宜沿章節、條款和例外條件切分，避免把約束條件留在上一塊；操作手冊應將動作步驟、前置要求、風險提示和結果判斷儘量放在同一語義單元內；工單可圍繞問題、排查過程與解決方案組織；表格則需要把列定義與對應資料一起保留。切塊尺寸還要適配嵌入模型和生成模型的上下文限制，而不是直接複製某個通用參數。

文本塊過短時，檢索可能命中一句結論，卻遺漏適用對象、否定條件或時間範圍；塊過長時，大量無關段落會稀釋主題，並增加生成階段的上下文佔用。判斷切分是否合理，可以抽樣檢查：任意文本塊脫離原文後，是否仍能回答「它在說明什麼、適用於誰、條件是什麼」；若不能，就需要合併上下文或補充結構資訊。

生產環境中可同時儲存細粒度子塊與較完整的父級內容。檢索階段使用較小單元提高定位能力，命中後再回取所屬章節、相鄰步驟或完整條款交給模型。這樣既避免整章參與向量匹配造成主題模糊，也減少模型依據孤立句子作答的風險。父子關係、段落順序和原文位置應在入庫時建立，而不是等生成答案時臨時猜測。

文件處理完成的標準，不是「檔案已經匯入」，而是能夠穩定回答四個問題：內容是否被正確解析，文本是否仍然有效，適用邊界是否可過濾，命中片段是否能還原到完整證據。任何一項缺失，都會在後續表現為「明明檢索到了，答案卻不可靠」。

三、索引與召回：不要把語義相似度當成唯一答案

索引層的任務不是替模型「理解全部知識」，而是以可接受的延遲，把可能包含證據的文本塊送入後續環節。Embedding 模型將查詢與文件塊對映到同一向量空間，向量索引再通過近似最近鄰演算法尋找距離較近的候選。這裡得到的是「語義上可能相關」，並不等於「能夠回答問題」。

Embedding 選擇要在企業語料上驗證

通用評測排名只能用於縮小候選範圍。企業真正需要測試的是模型能否區分內部術語、相似產品名稱、否定表達以及帶條件的制度條款。選型時至少檢查以下因素：

• 中文與行業表達：使用真實問題驗證縮寫、別名、專業詞彙和中英文混寫，不要只測公開問答資料。
• 輸入長度：模型可接收的長度應與文本塊策略匹配。直接截斷長塊，可能把結論、適用條件或例外條款留在編碼範圍之外。
• 部署約束：結合資料出域要求、推理吞吐、延遲和硬體資源判斷採用本地還是外部服務。
• 版本穩定性：查詢與文件必須使用相容的編碼模型。模型更換後通常需要重新生成文件向量，不能只升級查詢側。

企業檢索通常需要兩條召回路徑

向量檢索擅長處理措辭變化。例如，使用者詢問「差旅票據怎麼算」，系統仍可能召回標題為「費用報銷核算規則」的內容。但企業知識中還存在大量不能模糊匹配的字串，如 ERROR_CODE_4012、合同編號、藥品通用名和裝置型號。此類查詢中，一個字元的差異就可能指向完全不同的對象，BM25 等關鍵詞檢索往往更可靠。

混合檢索不應理解為把兩種分數直接相加。更穩妥的做法是分別生成排名，再用 RRF 依據候選在各列表中的名次合併結果。若業務對特定欄位有強約束，也可以增加規則加權，但應通過評測集確定，而不是憑經驗固定權重。

後設資料過濾應發生在候選進入上下文之前

文件塊除了正文，還應攜帶部門、產品線、發布日期、有效狀態、文件版本和存取權限等後設資料。檢索時先按使用者身份與問題範圍過濾，再執行向量或關鍵詞召回，可以避免已廢止制度、其他區域版本或無權檢視的內容進入候選集。權限過濾尤其不能只在答案展示階段處理，因為受限文本一旦進入模型上下文，就已經形成資料洩露風險。

過濾條件也不能無限收緊。使用者問題中的部門或時間可能缺失，錯誤推斷會直接導致零召回。工程上應區分硬條件與軟條件：存取權限、租戶邊界屬於硬過濾；產品偏好、時間傾向可以作為排序特徵，併為無結果情況設計逐級放寬策略。

Top-k 應由評測結果決定

候選數量過小，可能漏掉分散在多個文本塊中的定義、條件與例外；數量過大，則會把內容相近但適用範圍不同的片段送給模型，增加錯誤引用和上下文競爭。合理範圍取決於問題型別、切塊粒度、索引品質以及後續是否配置重排序器。

調參時應同時觀察「證據是否進入候選集」和「正確證據最終排在什麼位置」。先逐步擴大召回規模測量召回率，再結合重排序後的準確率、推理延遲和上下文佔用確定閾值。若擴大 Top-k 仍找不到證據，問題通常不在候選數量，而在文本切塊、欄位過濾、編碼模型或關鍵詞索引。用更大的候選集掩蓋索引缺陷，只會讓「能搜到一些相關內容，卻無法穩定答對」的問題更難定位。

四、查詢處理與重排序：解決「搜到了相關內容，卻沒排到前面」

企業問答中的檢索失敗，不一定是知識庫缺少資料。更常見的情況是：相關片段已經進入候選集，卻因為查詢表達不完整、排序訊號單一或上下文拼裝不當，沒有被送到模型面前。排查這類問題時，應分別檢視候選集合、排序結果和最終上下文，不能只根據答案對錯判斷檢索品質。

先處理查詢，但不要覆蓋使用者原話

使用者很少按照制度檔案的書面語言提問。直接用原句檢索，容易找到詞面接近但約束條件不一致的內容。

檢索前可以增加查詢處理層，常用操作包括：

• 結合會話歷史補全被省略的對象、部門或業務場景；
• 將內部簡稱對映為正式名稱，同時保留簡稱參與匹配；
• 識別「今年」「上一版本」「合同生效後」等時間條件，並轉換為可檢索的範圍；
• 把包含多個判斷條件的問題拆成若干可獨立驗證的子問題；
• 生成更接近制度、合同或技術文件措辭的檢索表達。

改寫結果只能作為新增檢索入口，不能替換原始問題。工程上應同時儲存原句、標準化版本、擴展詞和拆分結果，並記錄每條候選內容由哪一種查詢召回。否則，一旦改寫模型誤判了主體或時間，後續排序再準確，也只是在錯誤方向上挑選材料。

用級聯排序分配算力

單靠向量相似度排序，容易高估「主題相近」的內容；只用關鍵詞檢索，又可能漏掉同義表達。更穩妥的方案是讓不同檢索與排序機制分工，而不是要求一個模型完成全部判斷。

這種級聯結構的價值在於把高成本判斷留給較小的候選集合。線上參數應根據候選規模、響應時限和誤答成本聯合調整，不能只追求離線排序分數。

精排結束不等於上下文已經可用

排名靠前的片段仍需經過上下文組裝。首先應合併內容高度重複的塊，避免同一段制度因不同檔案副本反覆出現。其次，對依賴前後文才能理解的條款，可補入標題、定義段或相鄰段落。再次，應按原章節順序排列同一來源的材料，避免將「例外情形」放在「適用條件」之前。

還要限制單一來源佔用的上下文比例。若前排結果都是同一檔案的近似片段，它們會擠佔模型視窗，使另一份真正決定結論的合同附件或最新通知無法進入。可按來源、文件版本和章節進行配額控制；發生衝突時，則優先保留時效明確、適用範圍匹配且能直接支援結論的證據。

多條件問題要檢查證據覆蓋，而不是只看最高分

「外地員工試用期內離職，差旅費是否報銷，需要哪些審批」包含人員範圍、任職階段、費用規則和審批流程。即使某個片段與「差旅費報銷」高度相關，也不能說明證據已經完整。系統應為每個子問題維護覆蓋狀態：哪些已有直接依據，哪些只有間接資訊，哪些仍未找到材料。

當一次檢索無法覆蓋全部條件時，可以分別檢索各子問題，再按主體、時間、版本和規則依賴關係合併證據。只有證據覆蓋達到預設要求，才進入答案生成；否則應繼續檢索、要求使用者補充條件，或明確提示現有資料不足。判斷排序鏈路是否有效，最終不是看第一條結果「像不像答案」，而是看送入模型的證據能否完整支撐使用者提出的全部約束。

五、答案生成：把模型從「自由回答」約束為「基於證據回答」

檢索完成後，生成層的任務不是讓模型「結合常識回答」，而是把檢索結果轉換成可核驗的結論。兩者的差別在於：前者把資料視為參考，模型仍可自行補全；後者把資料視為證據邊界，任何關鍵結論都必須能回指到具體文本。

Prompt 應定義清楚回答契約：只能使用當前提供的資料；資料未覆蓋的內容不得用模型記憶補齊；直接記載的事實與基於事實形成的推斷必須分開表達；每項重要結論需要附帶文件標題、章節、頁碼或其他可定位資訊。僅在答案末尾列出幾份「參考文件」並不足夠，因為使用者無法判斷某句話究竟由哪段材料支援。

更穩妥的做法，是在進入模型前為每個文本塊分配穩定標識，並保留文件版本、頁碼、標題層級和更新時間。生成時要求引用繫結到具體文本塊，輸出後再由程式檢查：引用標識是否存在，引用片段是否真的包含相關事實，金額、日期等關鍵值是否與原文一致。引用應證明答案，而不是充當裝飾。

拒答能力是生成品質的一部分。系統若要求模型無論如何都給出確定答案，模型就會傾向於用語言連貫性填補證據空缺。工程上應把「無法回答」設計成正常狀態，並區分未檢索到材料、材料本身缺項、使用者問題含義不清和權限不足等原因，方便後續採取補充文件、改寫查詢或轉交人工等動作。

在制度解釋、法律諮詢、醫療資訊和財務核對等高風險場景中，不宜直接讓模型從長段資料生成最終答覆。可先執行證據抽取，把適用對象、條件、金額、日期、比例、型號及例外條款整理為結構化欄位，再基於這些欄位生成自然語言。對於格式穩定的關鍵事實，還應使用規則、資料庫記錄或計算邏輯進行二次校驗。模型負責表達，不應承擔所有事實驗證工作。

上下文編排同樣會改變答案。檢索結果正確，只說明證據進入了候選集合，不代表模型一定會採用正確證據。生成前需要去除重複片段和低相關內容，將直接回答問題的材料放在更顯著的位置，並按文件版本、主題或時間組織上下文。若新舊制度同時出現，應顯式標註生效狀態，而不是交給模型自行猜測。

• 限制上下文中的無關材料，避免有效證據被噪聲淹沒。
• 優先保留原文邊界完整、來源明確且版本有效的文本塊。
• 對衝突內容增加版本標籤，並在輸出中暴露衝突。
• 生成後檢查引用覆蓋率、關鍵欄位一致性和無依據陳述。

因此，答案生成並非在檢索結果後追加一次模型呼叫，而是一條包含證據編排、回答約束、引用驗證、事實校驗和拒答處理的鏈路。只有把「答案是否有證據」落實為可檢查的系統規則，才能真正緩解「資料已經搜到，答案仍然不準」的問題。

六、效果評估：分開測檢索、生成和端到端業務價值

RAG 不能只用「最終回答看起來是否合理」來驗收。一個錯誤答案可能來自文件解析失敗，也可能是候選片段排序不當，或者模型忽略了已經提供的證據。若不分層測量，團隊通常只能反覆調整提示詞，實際問題卻留在上游。

第一步是建立可迴歸的評測集。樣本不能只取常見問法，還應覆蓋低頻業務問題、需要組合多份材料才能回答的問題、知識庫中沒有結論的問題、受存取權限約束的問題，以及答案會隨版本或日期變化的問題。評測集應儘量來自真實搜尋日誌、客服記錄和業務人員訪談，而不是全部由實施團隊自行編寫。

每個問題至少需要標註以下內容：

• 可接受的標準答案，以及不能出現的錯誤結論；
• 回答所必需的證據片段，區分核心證據與補充材料；
• 允許引用的文件、版本和生效時間；
• 使用者身份及其可訪問範圍，用於驗證越權檢索；
• 知識不足時應直接拒答，還是可以給出有限結論。

對於表達方式不同但含義一致的答案，不宜採用簡單字串匹配。更穩妥的做法是先把關鍵事實、條件、數值和適用範圍拆成檢查項，再結合人工複核判斷。

檢索評測的核心，是確認必要證據能否穩定進入候選集。僅看這些排名指標仍不夠，還要檢查回答所需事實是否被完整覆蓋，以及候選上下文中混入了多少主題相近但結論無關的片段。

如果標準證據沒有被召回，不應先修改生成提示。應沿資料鏈路反查：原文是否被正確解析，表格和標題關係是否丟失，切塊是否把條件與結論拆開，索引是否納入關鍵欄位，查詢改寫是否改變原意，以及關鍵詞、語義和後設資料過濾能否互補。尤其要單獨檢查權限過濾與版本過濾，避免通過提高召回率把過期內容或無權存取的材料帶入上下文。

生成評測要在「證據已給定」的條件下進行。可將標準證據直接放入上下文，隔離檢索變數，再檢查答案是否與材料一致、引用是否真正支援對應結論、關鍵條件是否遺漏，以及面對證據不足時能否拒絕作答。若材料已經齊全而輸出仍然錯誤，問題通常落在上下文排序、重複資訊干擾、新舊版本衝突、提示規則不清或模型能力不足。

引用準確性需要逐條核對，不能只檢查答案末尾是否存在來源連結。常見失敗包括引用了相關但不能證明結論的段落、結論與引用來自不同版本，以及模型拼接多份材料後產生原文中不存在的推斷。

離線分數最終要接受業務結果校驗。指標改善可能只是讓答案更像標準答案，並不一定減少使用者處理時間。上線前應保留現有方案作為基線，開展隱藏方案資訊的人工盲測，再通過小流量 A/B 測試觀察真實使用效果。除正確率外，還要持續記錄尾部延遲、每次問答成本、轉人工比例、問題是否真正閉環，以及使用者是否採用答案繼續辦理業務。

評測集應納入發布流程：文件解析、切塊規則、嵌入模型、重排序器、提示詞或生成模型發生變化時，都運行同一組迴歸測試。新增錯誤樣本經過脫敏和標註後繼續沉澱。這樣才能判斷一次最佳化究竟改善了哪一層，又是否以權限安全、時效性、成本或延遲為代價。

七、生產化治理：讓知識持續更新，並確保使用者只看到該看的內容

RAG 上線後的主要風險不是模型突然失效，而是知識版本、存取權限和索引內容逐漸脫節。生產系統需要把文件變更視為可追蹤的資料流水線，而不是定期執行一次全量向量化。

新增檔案進入系統後，應依次完成解析、切分、向量生成、後設資料寫入和索引發布；檔案被修改或撤回時，也要同步處理原文本、向量記錄、關鍵詞索引與快取。每個切片至少關聯文件版本、生效區間、來源位置和處理狀態。新版本確認可用後，再將舊版本標記為失效，避免兩套制度同時進入候選結果。解析失敗或索引未完成的文件不能靜默上線，應進入告警與重試佇列。

權限校驗必須發生在召回階段。先檢索全部內容、再讓模型隱藏敏感資訊並不可靠，因為受限文本已經進入模型上下文，也可能出現在日誌和快取中。檢索條件應組合使用者身份、組織歸屬、專案關係、文件級別及有效期限；權限變更後，還要及時重新整理過濾資料。將敏感資料保留在企業控制的知識環境中，有助於縮小資料暴露面，但這不能替代細粒度授權。

線上監控不能只看介面是否成功。至少應觀察無結果查詢佔比、弱相關召回佔比、拒答比例、引用訪問情況、端到端耗時和單次呼叫成本。使用者點踩、專家修訂及轉人工案例需要按「知識缺失、切分錯誤、排序錯誤、生成偏離、權限阻斷」等原因歸類，並沉澱為持續迴歸的評測樣本。

實施時宜先限定一個知識域和一類穩定問題，用基礎 RAG 建立可測基線。只有評測證明瓶頸位於召回、排序或多跳關係時，再分別引入關鍵詞與向量混合召回、重排序、查詢拆解或 GraphRAG。元件一次堆得過多，通常只能增加延遲和排障難度，無法判斷準確率提升來自哪裡。

RAG 和大模型微調有什麼區別，企業應該選哪個？

RAG 解決的是外部知識的查詢、更新和引用問題，適合制度、手冊、專案資料等頻繁變化的內容；微調更適合調整輸出格式、術語習慣、任務步驟或行為邊界。若問題是「模型不知道最新檔案」，優先採用 RAG；若模型已經拿到正確證據，卻長期不能按固定規範執行，可考慮微調。兩者可以組合，但微調不應承擔知識版本管理。

長上下文模型能否取代 RAG？

通常不能。長上下文擴大了單次可輸入的資訊量，卻沒有自動解決文件篩選、權限隔離、版本控制和來源追蹤。材料很少且範圍固定時，可以直接裝入上下文；當資料持續增長、不同使用者可見範圍不同，或需要穩定引用時，仍需檢索層先縮小證據集合。長上下文更適合作為召回後的閱讀空間，而不是完整的知識治理方案。

為什麼系統明明檢索到了正確文件，最終答案仍然不準確？

「命中文件」不等於「提供了足夠證據」。正確片段可能排序靠後、被上下文截斷，或缺少適用條件和例外條款；提示詞也可能允許模型脫離證據補全。排查時應分別檢查候選排名、實際注入內容、上下文長度、引用覆蓋和回答約束。生成階段應要求結論綁定出處，證據不足時明確拒答，而不是自由推斷。

建設企業 RAG 知識庫需要多少文件才能開始？

沒有通用的最低文件數量。能否開始取決於知識域是否清晰、問題是否重複出現、文件能否回答這些問題。結構穩定的制度檔案也可用於建立首個基線。與其追求規模，不如先準備一組真實問題、標準答案和對應證據；如果這組樣本無法定義，匯入更多文件只會擴大噪聲和治理成本。