2026-10-12

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

本文講清 rag 是什麼 ai，解析企業知識庫問答的適用場景、資料治理、權限控制、檢索最佳化、引用拒答與上線驗收方法。

一、RAG 是什麼 AI：不是新模型，而是企業知識的「開卷問答層」

從業務視角看，RAG（檢索增強生成）是一條問答工作流：使用者提出問題後，系統先到企業知識源中查詢相關內容，再把檢索結果交給大語言模型組織答案。它不是一種獨立的大模型，也不會替代模型本身；模型負責理解與表達，RAG 負責在生成之前提供可用的企業證據。

這一區分很重要。僅使用大語言模型時，回答主要依賴訓練階段形成的參數知識。模型可能熟悉通用概念，卻不知道企業內部的制度版本、專案資料、產品手冊或流程檔案。RAG 在模型與企業內容之間增加了一層檢索連接，使回答可以參考未進入模型訓練集的私有資料。

因此，RAG 的企業價值不能簡單概括為「減少幻覺」。它更直接地解決三個工程問題：讓模型能夠使用內部知識；讓知識變化主要通過更新資料而非重新訓練模型來處理；讓回答能夠關聯到原始材料，便於使用者核對依據。這裡的「依據」不是模型聲稱自己參考了某份檔案，而是系統實際檢索到、傳入生成上下文並可回到原文檢視的內容。

「開卷」是理解 RAG 的一個合適類比，但開卷不等於一定答對。資料是否完整、檢索結果是否相關、模型拿到的上下文是否包含關鍵條件，都會影響最終輸出。RAG 可以為模型提供證據，卻不能自動保證檔案本身正確，也不能把低品質資料變成可靠結論。它降低的是模型脫離企業資料自由作答的機率，而不是從機制上消除錯誤。

企業實施 RAG 時，建議始終檢查三條鏈路是否同時成立：

• 文件接得進來：業務資料能夠被持續採集、解析和更新，檢索時拿到的不是殘缺正文或長期未同步的舊內容。
• 權限管得住：檢索範圍與使用者身份、資料可見範圍保持一致，不能因為接入大模型而繞過既有的資訊邊界。
• 答案驗得出來：使用者可以看到回答依據，並能返回原始內容核對；系統也應區分「檢索到材料」和「材料足以支援結論」。

這三條鏈路決定了企業 RAG 的實際可用性。只有文件接入而沒有權限約束，知識庫會帶來資訊暴露風險；只有檢索結果而缺少可核驗依據，使用者難以判斷回答是否可靠；只關注模型表達而忽略資料品質，則容易得到措辭流暢但依據薄弱的答案。後續的需求判斷、資料治理、檢索最佳化和上線驗收，都應圍繞這三條鏈路展開，而不是把選模型或選向量資料庫當成建設起點。

二、先判斷需求：什麼問題適合做 RAG，什麼問題不能只靠 RAG

判斷一個需求是否適合 RAG，先不要討論模型參數或向量資料庫，而要確認答案從哪裡產生。RAG 更適合處理「答案已經寫在資料裡，但使用者難以快速找到」的問題。通常可從三個條件判斷：相關內容能夠納入管理；知識會更新，或屬於模型原本不瞭解的內部資訊；回答需要附帶可核驗的來源。

例如，制度條款、產品手冊、技術規範和內部操作說明，主要工作是從文件中定位相關段落，再讓模型結合上下文組織答案。這類需求的知識載體相對明確，RAG 可以在不重新訓練基礎模型的情況下，把組織內部資料加入回答過程。此時專案重點不是讓模型「記住」文件，而是確保它能找到正確版本，並說明結論依據。

另一類問題表面上也是問答，答案卻不完整存在於文件中。以員工詢問可用休假為例，制度資料只能解釋計算規則；要得到針對當前員工的結果，還需要讀取與本人相關的業務記錄。同樣，訂單進展之類的問題也依賴持續變化的業務資料。對這些需求，文件檢索只能承擔解釋規則、補充口徑的部分，當前狀態應由業務資料來源提供。

還要區分「回答問題」和「完成動作」。如果使用者的真實目標是提交審批、更新記錄或完成交易，那麼系統不僅要理解知識，還要處理身份、參數、流程結果和異常情況。RAG 可以解釋辦理條件、定位操作依據，卻不應被當作完整的業務自動化方案。架構上應把知識查詢與業務執行拆開，分別定義輸入、權限和失敗處理。

立項前建議形成一份答案邊界清單，而不是先建設一個覆蓋全部資料的知識庫。至少明確以下事項：

• 知識範圍：系統回答哪些主題，哪些問題明確不處理；
• 服務對象：不同崗位或組織可訪問哪些內容；
• 來源約束：回答必須依據哪些正式資料，普通參考材料能否作為證據；
• 時效要求：哪些問題可以使用定期同步的文件，哪些必須讀取當前業務資料；
• 回答策略：找不到充分依據時，是拒絕作答、提示補充條件，還是轉入其他處理通路；
• 動作邊界：系統只給出說明，還是需要銜接後續業務流程。

一個直接的判斷方法是追問：「去掉語言模型後，這個問題的可靠答案應當從哪裡取得？」如果答案是某份受控資料，優先考慮 RAG；如果答案來自業務系統中的當前記錄，就需要資料查詢能力；如果目標是改變系統狀態，則還需要獨立的執行鏈路。先完成這一步分類，可以避免把所有企業 AI 需求都包裝成知識庫問答。

三、從文件到知識庫：先解決資料治理，再討論向量庫

企業 RAG 的首要問題通常不是選擇哪一種向量資料庫，而是確定哪些資料可以作為答案依據。若源文件重複、過期或責任不明，檢索系統只會更快地暴露這些問題。向量化不會自動判斷制度是否仍然有效，也無法替企業決定 Wiki、正式通知與歷史工單之間誰更權威。

第一步應盤點知識來源，並給每類資料定義治理規則。網盤和 Wiki 往往覆蓋面廣，但版本狀態未必清楚；產品手冊適合解釋功能與操作；工單可以補充真實問題，卻可能包含臨時處置和個別結論；合同的適用範圍取決於具體主體與版本；業務系統中的記錄則持續變化。盤點時不要只登記存放位置，還要明確維護責任、更新節奏、有效區間以及發生衝突時的採用順序。

資料準備也不等於批次上傳檔案。工程流程至少要處理正文和表格解析、重複內容清理、標題結構恢復以及語義分塊。掃描件、複雜表格和跨頁條款若解析錯誤，後續使用更強的嵌入模型或重排模型也難以補救。處理後的內容還應保留必要的檢索屬性，例如原始出處、版本狀態、歸屬範圍、時間資訊與訪問限制。欄位不必追求數量，而要能支援過濾、追溯和維運。

分塊策略應服從文件結構，而不是讓所有資料套用同一個字元長度。制度條款需要儘量保留適用條件、例外和處理結論；FAQ 可以按問答單元組織；技術文件則應維持章節、步驟和前置條件之間的關係。固定長度切分雖然實現簡單，卻可能把條件留在前一塊、把結論放到後一塊。即使需要控制塊大小，也應儲存塊所屬標題、相鄰內容和原文位置，便於檢索後補齊上下文。

知識庫還要具備持續更新能力。源文件新增後應進入增量處理；版本替換時要讓舊內容退出有效檢索範圍；資料失效或被刪除後，相關文本、向量及快取也應同步處理。僅完成首次匯入，只能得到一次性快照。RAG 可以通過更新索引吸收新資料，但這一優勢能否落地，取決於索引變化是否跟隨源系統，而不是取決於模型參數是否更新。

因此，在討論向量庫容量、索引演算法或嵌入模型之前，可以先做一次更直接的檢查：資料是否有明確來源，衝突時是否能夠判斷優先順序，舊版本是否可以下線，刪除是否會傳播到檢索端。若這些問題沒有答案，專案當前缺少的通常不是檢索技術，而是可執行的知識治理機制。

四、權限不是登入校驗：RAG 如何避免搜到不該看的文件

使用者能夠登入知識庫，只能證明身份已被識別，不能說明他有權檢視庫內全部內容。企業 RAG 的授權對象不是一個頁面，而是每次檢索涉及的文件、段落、引用和衍生內容。權限設計應從「誰可以檢索哪些資料」出發，而不是在答案生成後再判斷是否展示。

較穩妥的做法是儘量沿用源系統的授權關係。文件同步進入索引時，將源系統中的人員、群組、組織歸屬、文件訪問控制列表和保密級別轉換成檢索服務可執行的權限欄位。RAG 不應另建一套長期獨立維護的權限名單，否則源系統已經撤權，知識庫仍可能保留舊授權。

權限判斷應進入檢索條件。系統先解析當前使用者身份和授權範圍，再在召回文件片段時應用過濾。不要先從全庫取回內容，再依靠提示詞要求模型「不要洩露」。一旦敏感片段進入模型上下文，它就已經越過了資料訪問邊界；即使最終答案沒有直接複述，該內容仍可能出現在除錯資訊、呼叫鏈路或中間結果中。提示詞可以約束回答風格，但不應承擔授權控制。

工程上還要明確異常策略。身份無法確認、權限關係缺失或授權服務不可用時，不應自動放寬為全庫檢索。系統可以停止本次查詢，或僅訪問明確允許公開的資料，並向用戶說明當前無法完成權限校驗。這裡需要顯式設計失敗路徑，避免元件異常意外擴大可見範圍。

檢索過濾只是第一道邊界。答案引用可能帶出原文標題和連結，快取可能儲存已撤權的結果，歷史會話可能繼續展示舊片段，執行日誌也可能記錄問題、上下文與完整回答。下載、複製和匯出功能還會把內容帶離原有系統。因此，這些衍生載體應採用與原檢索結果一致的授權與脫敏規則。

• 展示引用前重新確認當前使用者對來源文件仍有訪問權。
• 快取鍵納入使用者或權限範圍，避免不同授權主體共用結果。
• 會話恢復時重新檢查歷史引用，不把舊授權視為永久有效。
• 日誌按用途控制欄位，對正文、身份資訊和查詢內容分別脫敏。
• 匯出內容保留來源與權限標記，並受獨立的匯出授權約束。

權限還存在時效問題。員工離職、組織調整、文件撤權或密級變化後，需要檢查索引中的權限欄位是否更新，同時處理快取、會話和已生成引用中的舊內容。只更新源系統頁面而不處理這些副本，不能視為撤權完成。同步鏈路應保留變更時間、處理狀態和失敗原因，便於追蹤某次授權變化是否已經傳遞到各個環節。

上線驗收時，不要只用有權限的正常帳號測試。應覆蓋無權限訪問、跨部門查詢、調崗後訪問、離職帳號、文件臨時撤權、共享連結和歷史會話恢復等路徑，並檢查檢索結果、引用、快取、日誌與匯出是否執行相同邊界。企業 RAG 的權限合格標準，不是模型承諾不說，而是未授權內容沒有進入本次問答的資料鏈路。

五、問答效果怎麼提升：把問題拆成召回、排序與上下文組織

RAG 回答不準時，先不要調整提示詞或更換大模型。生成結果取決於上游提供了什麼材料：相關內容未進入候選集，屬於召回問題；正確片段已經出現，卻被無關內容擠掉，屬於排序問題；證據都在，但被切碎、重複或缺少前後文，則應檢查上下文組織。三類問題需要分別定位。

只使用向量檢索，往往覆蓋不了企業查詢的全部形態。向量方法擅長匹配含義相近、措辭不同的表達，例如使用者口語與制度文本之間的差異；BM25 一類關鍵詞方法則更容易保留精確字元匹配，對故障程式碼、裝置型號、縮寫和領域詞彙更有價值。因此，檢索方案應通過業務問題集比較語義檢索、關鍵詞檢索及兩者組合，而不是預設向量方案一定更優。

混合檢索不是把兩份結果簡單拼接。兩條檢索通道的分數尺度可能不同，需要使用統一的融合規則，例如按名次合併的 RRF，再處理重複片段和權限過濾。驗收時應分別觀察不同問題型別：自然語言提問是否能找到同義材料，精確識別符號是否命中對應文件。若只看總體平均值，局部失效容易被掩蓋。

召回階段的目標是避免漏掉證據，而不是立刻得到最終上下文。工程上可以先取得範圍較寬的候選集，再由重排序模型重新判斷問題與片段的關聯程度，將真正有用的內容送入生成環節。語料規模較大時，可採用分級流程：低成本檢索負責縮小範圍，輕量排序繼續篩選，計算開銷較高的 Cross-Encoder 只處理剩餘候選。每增加一層，都應驗證它是否改善結果，並記錄新增延遲與資源消耗。

查詢本身也可能限制召回。一個問題同時包含多個意圖時，單次檢索容易只覆蓋其中一部分；表達過短或指代不明時，檢索詞也不足以定位資料。此時可以改寫查詢，或生成若干側重點不同的檢索表達，再合併候選結果。但改寫屬於額外推理步驟，會增加模型呼叫、響應時間與費用，還可能改變原問題含義。因此需要保留原始查詢，並檢查改寫結果是否遺漏限定條件。

上下文並非越長越好。片段進入提示詞前，應去除重複內容，補齊必要的標題、條款歸屬和相鄰段落，並儘量讓同一主題的證據保持連續。若切分邊界破壞了表格、步驟或定義，即使檢索命中，模型也可能無法還原完整含義。此類問題應回到文件切分與上下文拼裝處理，而不是依靠生成模型猜測缺失部分。

RAG 與長上下文可以配合使用：檢索先從資料集中縮小證據範圍，長上下文再承載這些高相關且結構完整的內容，供模型綜合分析。相比直接放入大量文件，這種方式更容易控制輸入範圍、成本和證據來源。最終調優也應按鏈路逐段驗收：先確認能否找到，再確認排序是否合理，最後檢查模型看到的上下文是否足以支援回答。

六、答案可信不等於模型會說：設計引用、拒答與衝突處理

企業 RAG 的可信度不應按語言是否流暢判斷，而要看結論能否由檢索證據支撐。模型可以負責組織表達，但不應自行補全制度條件、適用範圍或例外條款。RAG 能把回答約束在指定知識來源附近，從而降低虛構內容、誤用舊資訊和混淆內部術語的風險，但不能保證完全消除幻覺。

首先要定義「有證據回答」的輸出契約。對影響業務判斷的結論，答案應關聯到原文標題、具體章節或段落，並在條件允許時提供可訪問連結。引用不能只指向知識庫首頁，也不能列出與結論關係不明的一組文件。使用者應當能夠從答案直接返回對應原文，核驗上下文、適用對象與版本。

• 結論與引用一一對應，避免在一個引用下混入多個未經支援的判斷。
• 引用保留文件標題、定位資訊和版本標識，便於複核。
• 生成內容不得擴大原文含義；證據只覆蓋部分條件時，應限定回答範圍。
• 引用片段與最終答案一起記錄，方便後續排查和迴歸測試。

其次要把拒答作為正常路徑，而不是系統異常。檢索結果為空、片段與問題關聯較弱，或者資料沒有覆蓋關鍵條件時，系統應明確說明「現有資料無法確認」。可以同時指出缺少哪類資訊或建議核驗哪個責任部門，但不應呼叫模型常識把空白補成確定結論。提示詞中的「僅依據資料回答」只能形成行為約束，不能替代證據檢查；應用層仍需根據相關性、引用覆蓋情況和資料狀態決定是否允許生成。

多份檔案互相衝突時，也不能把不同表述自動拼接成一個看似完整的答案。工程上應先建立衝突裁決規則：優先比較檔案效力與責任主體，再判斷適用組織、人員或業務範圍，最後結合生效時間、發布日期和版本狀態確定候選依據。較新的檔案不一定覆蓋範圍更窄的專項規定，因此排序結果仍需保留適用條件。系統無法確定優先順序時，應並列展示衝突點、對應來源及待確認事項，而不是替使用者作出無依據的裁決。

答案出錯後，不要直接歸因於「大模型不夠好」。應沿處理鏈路定位故障，否則更換模型或反覆修改提示詞通常無法解決根因。

因此，可信問答的驗收對象不是單獨一段答案，而是「結論、證據、適用條件和不確定性」組成的完整記錄。只有這條鏈路可核驗、可拒絕、可追責，RAG 才能從演示型問答進入企業業務環境。

七、從 PoC 到上線：用可復現的驗收替代演示效果

RAG PoC 的目標不是做出一場順暢演示，而是確認某個知識域能否形成可執行、可評估、可追責的問答閉環。首個範圍宜選擇責任主體明確、資料版本可確認、實際查詢頻繁的領域。不要在試點階段同時接入多個部門的全部檔案，否則錯誤究竟來自原始資料、權限規則還是檢索鏈路，很難定位。

測試問題應取自真實業務場景，並在脫敏後沉澱為固定迴歸集。樣本需要覆蓋日常表述、同一意圖的不同說法、多條件組合問題，以及資料中不存在答案的提問。對於已失效檔案，可將其作為專門樣本，用來檢查系統是否錯誤引用舊版本。每條樣本應保留預期答案要點、允許引用的資料範圍、適用身份和是否應當拒答，後續調整才能進行前後對比。

權限測試應與內容測試分開執行。可為同一個問題配置不同部門、崗位或專案身份，比較可檢索範圍和最終輸出；還要覆蓋權限被收回後的再次查詢，以及文件正文、標題、摘要和引用中可能暴露敏感內容的情況。驗收記錄不能只儲存最終答案，還應保留檢索條件、候選片段、排序結果與身份上下文，便於判斷問題發生在哪一層。

品質指標之外，還要觀測執行成本與業務結果。工程側可記錄完整請求耗時和每次呼叫開銷；使用側可跟蹤使用者是否繼續追問、是否轉交人工，以及問題最終有沒有得到解決。指標口徑需提前定義。例如，追問可能表示答案不清楚，也可能是正常的連續諮詢，不能脫離會話原因直接判斷優劣。

上線宜先限制使用者範圍和知識域，並保留回饋入口、失敗會話回放及版本標記。每次變更資料、切塊策略、召回配置、重排邏輯或提示詞後，都應重新運行同一套迴歸樣本，同時檢查權限用例。這樣可以發現某項最佳化是否改善了目標問題，卻破壞了其他場景。

失敗樣本應按鏈路歸因，而不是統一歸咎於模型。找不到資料，先檢查資料接入與檢索；找到錯誤版本，檢查後設資料和過濾；證據正確但回答偏離，再處理上下文編排與生成約束。只有確認瓶頸確實位於生成環節時，更換模型才是合理選項。PoC 通過的標準也不應是「看起來能回答」，而應是範圍內的品質、權限、成本和營運流程都已有明確的驗收結果。

八、FAQ：企業做 RAG 最常見的四個決策問題

RAG 是否等於企業知識庫或向量資料庫？

不等於。企業知識庫是被管理的內容集合，可能包含制度檔案、技術手冊、專案資料和業務說明；向量資料庫是儲存向量並執行相似度檢索的基礎設施；RAG 則是一條問答工作流：收到問題後查詢外部資料，把相關內容交給大語言模型，再基於這些內容生成答案。

因此，僅把文件寫入向量資料庫，不代表知識庫問答已經可用。檢索結果是否相關、文件版本是否正確、模型獲得了哪些上下文，以及答案能否指向依據，都屬於 RAG 鏈路。反過來，RAG 也不必繫結某一種向量資料庫；只要外部資訊能夠被檢索並用於生成，就符合其基本範疇。

有長上下文模型後，企業還需要 RAG 嗎？

通常仍然需要，兩者解決的問題不同。長上下文擴大了模型單次能夠讀取的材料範圍，適合對已經選定的一組資料做綜合分析；RAG 負責先從更大的文件集合中篩出相關內容。把全部資料直接塞進提示詞，會持續消耗 token，而且材料變長後，關鍵資訊可能因位於上下文中部而未被充分利用，這通常被稱為「Lost in the Middle」。

工程上不必在兩者之間二選一。更穩妥的組合是先檢索，縮小候選資料範圍，再利用長上下文完成對照、歸納或推理。如果文件量很小、更新不頻繁，並且每次都需要通讀全部材料，直接使用長上下文也可能更簡單。

RAG 能否保證不產生幻覺並且不洩露資料？

不能保證。RAG 能讓回答受到外部資料約束，並支援展示資訊來源，但模型仍可能誤解片段、混合不同證據，或者生成資料中沒有的結論。它降低的是風險，不是把生成式模型變成確定性查詢系統。

資料安全也不能由 RAG 機制本身兜底。檢索增強只回答「查到什麼並交給模型」，並不天然解決「誰可以查什麼」。企業需要把訪問控制作為獨立的安全能力處理，並驗證不同身份下的檢索結果。上線驗收時，還應分別觀察檢索內容、最終答案和引用依據，不能只檢查文字是否流暢。

企業應該先做向量 RAG、混合檢索，還是 GraphRAG？

選擇標準應是問題結構，而不是技術名稱。若使用者表達與文件措辭經常不同，向量檢索適合先建立語義匹配基線；若資料中大量存在錯誤碼、產品編號或固定術語，可在向量檢索之外加入 BM25 關鍵詞檢索，再用 RRF 等方法合併排序。混合檢索兼顧語義近似與精確匹配，通常更適合術語密集的知識庫。

GraphRAG 面向另一類問題：答案分散在多份材料中，必須沿實體關係進行跨文件推理。它需要先從文件中抽取實體與關係並建立圖結構，因此構建複雜度和查詢延遲通常高於常規向量 RAG。

實際決策可以按最小複雜度推進：單文件或局部事實問答先驗證向量檢索；精確詞匹配不足時引入混合檢索；只有當真實問題持續表現為跨資料、多跳關係查詢，並且前兩種方案難以覆蓋時，再評估 GraphRAG。這樣更容易判斷效果提升究竟來自檢索設計，還是來自額外的圖譜工程。