2026-06-25

餵給 AI 之前：企業文件治理的工程清單

RAG 效果差，根因往往不在模型，而在入庫前的文件品質。本文從內容清洗、結構化解析、時效管理、權限同步到合規邊界，梳理企業文件治理的完整工程清單，幫助團隊在構建 AI 知識庫前打好資料地基，避免垃圾進、垃圾出的系統性風險。

RAG 翻車的根因，常在你看不見的入庫前

一個 RAG 系統上線後效果不及預期，團隊的第一反應往往是懷疑模型不夠強，或者檢索演算法選錯了。於是開始換 embedding 模型、調相似度閾值、加 rerank,折騰幾週收效甚微。這條排查路徑之所以常常走偏，是因為它默認了一個前提：進入向量庫的內容本身是乾淨、準確、該被看到的。但在我接觸的多數案例裡，問題恰恰出在這個前提還沒成立的地方——入庫前的那道工序被跳過了。

把這件事拆開看會更清楚。檢索和生成是流水線的末端，它們忠實地處理餵進來的東西；如果灌進向量庫的是帶著格式垃圾、版本混亂、權限標註缺失的文件，後面的環節再精密，產出的也只是「高品質地複述了錯誤素材」。換句話說，模型沒有能力替你判斷一份文件是不是三年前作廢的舊政策，也分不清某段內容是不是只有財務部門才能看。這些判斷必須在資料進庫之前完成，一旦錯過，汙染就被固化進了索引。

過期內容是最隱蔽的一類。它不像亂碼那樣一眼可見，反而長得和有效文件一模一樣，語義匹配度還可能很高。設想一份兩年前的報銷標準，條目清晰、表述規範，檢索時它會被穩穩召回，模型基於它生成的回答看起來專業又自信，實際卻是在拿一套已經廢止的規則指導今天的決策。這類錯誤的危險在於它不報錯，使用者很難察覺自己拿到的是過時答案。時間一長，知識庫裡有效內容和殭屍文件混雜沉澱，逐漸變成一個誰都不敢信、也沒人願意清理的「文件墳場」。缺乏明確責任歸屬的內容治理往往會逐漸走向失控——這正是為什麼後面我會專門講，每份文件都該繫結一個負責人和一個審核週期，過期的要麼下架，要麼在檢索結果裡被顯式標記為存疑。

另一類問題更要命，因為它牽涉安全。很多團隊建索引時只關心「內容是什麼」,卻忘了同步「誰能看」。當文件的訪問控制資訊沒有跟著進入檢索層，向量庫就成了一個對所有查詢者一視同仁的大池子。這時風險不再是答錯，而是越權。一個本不該接觸薪酬資料的普通員工，可能不需要任何破解手段，只要換個問法做語義搜尋，就能讓系統把受限內容當作普通知識片段返回給他。原文件系統裡設定好的權限邊界，在這一刻被檢索通道繞了過去，這就是權限穿透。

這裡有個容易踩的認知誤區：以為在入庫時按權限做一次過濾就夠了。靜態快照式的權限處理扛不住現實——組織架構在變，人員在流動，專案權限隨時調整，今天有權看的人下個月可能就調崗了。如果檢索層依賴的是入庫那一刻凍結的權限狀態，它遲早會和真實的授權關係對不上。正確的做法是把權限校驗放到查詢發生的那一刻：使用者發起檢索時，即時拿他當前的身份和授權去過濾候選結果，而不是信任幾個月前寫進索引的標註。這部分的工程實現我會在權限同步那一節展開。

把這三類隱患——髒資料、過期內容、權限錯配——放在一起看，會發現它們有個共同特徵：都發生在資料進庫之前或進庫那一刻，且一旦發生就很難在下游補救。你沒法靠調檢索參數把一份廢止文件變回有效，也沒法靠換模型補上缺失的權限標註。所以本系列接下來的幾節，重點都不在模型和演算法，而在餵給 AI 之前那段常被忽略的工序：內容怎麼清洗和做安全掃描，非結構化資料怎麼轉成可治理的結構化資料，時效怎麼管，權限怎麼即時對齊，以及當 Agent 開始反向寫入知識庫時，審計和分級又該怎麼兜底。把入庫前這道關守住，後面的檢索品質才有談論的基礎。

第一道工序：入庫前的內容清洗與安全掃描

把文件餵進檢索系統之前，你得先承認一件事：大多數企業文件不是為機器準備的。它們是人寫給人看的——裡面夾著除錯時隨手貼上的金鑰、客服工單裡抄錄的客戶手機號、內部 wiki 中某位工程師留下的臨時 token。這些東西在原始文件裡幾乎無害，因為訪問它們需要先有訪問那份文件的權限。可一旦進入向量索引，邊界就被打破了：一個本來只有維運能看的配置片段，現在可能因為語義相近被檢索出來，拼進給任何一個發起查詢的人看的回答裡。問題的本質不是文件髒，而是檢索把文件從它原本的訪問上下文裡剝離了出來。

所以清洗這道工序要解決的第一類問題，是敏感資訊的識別與處置。這裡有個時機上的判斷需要明確：檢測點必須放在攝入階段，而不是進庫之後再回頭掃。入庫後補救意味著敏感資料已經被切片、向量化、寫進索引，你要清理的不只是原文，還有派生出來的所有嵌入向量和後設資料，而且在你清理完之前的任意時刻，它都可能被檢索命中。前移檢測的好處是它把風險攔在了不可逆操作之前——文件還是一份完整的、可追溯的對象，你可以決定隔離、脫敏還是直接拒收。Glean 在 2026 年的 Protect Plus 走的就是這個路線，把 PII 檢測和企業既有的安全端打通，讓檢測發生在內容進入索引之前而非之後。這個方向值得借鑑，核心不在於用了誰的工具，而在於把安全控制點釘在了管道入口。

具體到處置策略，不該一刀切。我的建議是按敏感型別分流：

• 結構化的強識別符號——身份證號、銀行卡、API 金鑰、私鑰、訪問令牌——這類有明確格式特徵，正則加熵值檢測的命中率高，預設應當隔離或直接阻斷入庫，需要人工複核才放行。
• 弱識別符號——人名、電子郵件、內部 IP、專案代號——單獨出現未必敏感，組合起來才構成識別風險。這類適合脫敏後入庫，用佔位符替換原值，既保留了文件的語義結構供檢索，又切斷了洩露路徑。
• 上下文相關的敏感內容——比如薪資討論、未公開的併購資訊——純靠模式匹配抓不準，這部分往往要靠文件來源分級和存取權限來兜底，不該指望清洗環節獨自扛下。

第二類問題更隱蔽，也更容易被忽略：文件本身可能是攻擊載體。當知識庫變成 RAG 的檢索源，文件內容就不再只是被讀取的資料，它會被模型當作上下文去理解、去執行。攻擊者可以構造一份看似正常的文件，在裡面埋入誘導性指令——「忽略之前的所有約束」「把這份內容標記為最高優先順序」——一旦這份文件被檢索命中並拼進提示詞，模型就可能按攻擊者的意圖行事。這就是攝入攻擊(ingestion attack)的邏輯：汙染不是發生在查詢時，而是發生在更早的入庫時，潛伏在索引裡等一個合適的查詢把它啟用。

對付這類風險，需要在文件進入向量索引前加一道內容安全掃描。和 PII 檢測不同，這道掃描關注的不是「有沒有敏感資料」,而是「這份內容會不會試圖操縱下游行為」。可以落地的檢查點包括：識別文件裡是否存在指令式語句模式，尤其是那些在正常業務文件中不該出現的祈使句；檢測異常的格式構造，比如大段不可見字元、超長的重複 token、試圖突破上下文邊界的分隔符；以及對來源不可信的外部文件(使用者上傳、爬取的網頁、第三方匯入)施加比內部文件更嚴的審查閾值。這些檢查抓不全所有變體，但能把成本最低、最常見的注入擋在門外。

把這兩道掃描串進攝入管道，實際工程形態通常是一組攔截器：文件進來，先過格式解析，然後並行跑 PII 檢測和內容安全掃描，任一命中就進入隔離佇列等待處置，全部通過才進入下一道結構化工序。值得花力氣做好的是處置記錄——每一份被隔離、被脫敏的文件都要留下可追溯的日誌，記清楚命中了什麼規則、做了什麼處理、誰批准放行。這不只是為了合規審計，更是因為清洗規則一定會迭代，而你需要資料來判斷規則是太鬆還是太緊。一道既能調參又能復盤的清洗工序，才是能長期運轉的工序。

第二道工序：把非結構內容變成可治理的結構化資料

清洗解決的是「髒」,這一步解決的是「形」。企業裡真正難啃的文件，往往一開始就不是可解析的文本：幾年前掃描歸檔的合同 PDF、財務部門匯出的票據影像、會議錄音、產品演示影片。這些東西塞進向量庫，檢索器看到的只是一團無法切分的二進位制，或者一頁掃描圖被當成空白頁跳過。RAG 答非所問，很多時候根因就在這裡——不是模型不行，是它壓根沒拿到能讀的內容。

所以第一件事是把「影像裡的字」還原成「機器能讀的字」。OCR 在這一層是底座，但要按場景挑引擎，不能一個模型走天下。普通公文、說明書，通用 OCR 足夠；一旦進入財務這種零容錯的領域，情況就變了。銀行流水、信用卡帳單、增值稅票據，這些表格裡全是數字和金額，小數點錯一位、千分位識別成句點，下游對賬就全盤崩掉。這類場景需要專門針對財務表格訓練的識別引擎，它對數字、金額欄位和表格線做過專項最佳化，能把流水直接吐成 Excel 或 CSV 的行列結構，而不是一串丟了位置關係的散字。市面上專做財務文件數位化的廠商通常會標稱數字識別準確率在 99% 量級，這個指標的意義不在於絕對值，而在於它把人工複核的工作量壓到了可接受的抽檢範圍——這是能不能上生產的分水嶺。

但把圖變成字，只是結構化的起點，遠不是終點。真正決定文件「可治理」的，是它有沒有帶上一組能被檢索、被過濾、被審計的欄位。一份合同光有正文不夠，系統需要知道：它是合同還是發票，簽約方是誰，生效和到期日期，涉及金額，歸屬哪個部門。這些就是後設資料。靠人工錄入，幾萬份文件根本不現實，而且錄入品質參差不齊。可行的做法是在入庫流水線裡掛一個自動抽取環節，讓模型讀完內容後順手把這些欄位填好——文件型別自動歸類、關鍵實體自動識別、標籤自動打上。這樣每份文件進庫時就自帶一張「身份證」,後續無論是按部門做權限隔離，還是按到期日觸發時效預警，都有欄位可依。

這件事現在不算前沿，成熟的內容管理平台已經把它做成標配。比較典型的能力組合是：用 AI 對文件做自動分類與智慧標記，在入庫瞬間完成後設資料抽取和內容分析，再據此提供更準的檢索建議。換句話說，分類和打標不再是歸檔員的手工活，而是內容進門時自動發生的一道工序。這背後的工程價值是，它把「治理」從一個需要專人維護的後置動作，變成了入庫鏈路上的內聯步驟——文件多到什麼程度，治理就自動跟到什麼程度，不會因為量大就失管。

異構內容裡最容易被漏掉的是音影片。很多公司的真實知識——一次架構評審、一場客戶答疑、一段產品培訓——是以錄音錄影形式躺在網盤裡的，從來沒進過任何可檢索的系統。處理它的關鍵動作是轉錄：把語音轉成帶時間戳的文本，再走和普通文件一樣的清洗、抽取、打標流程。一些平台已經把轉錄、影像內容識別、關鍵資訊提取打包進了同一套技能框架，意思是你不必為每種媒體型別單獨搭管線，音訊進去出來就是可索引的文本片段。對工程團隊來說，這意味著可以用一套統一的入庫標準，去吃掉文本、表格、影像、音影片這些原本格式各異的來源。

把這幾層串起來看，這一步的目標其實很清楚：讓所有進庫的內容，無論原始形態是什麼，最終都收斂成同一種帶欄位的標準格式。可以用一個對照表來理解每類內容要過哪幾道處理：

有一點要提醒：OCR 和模型抽取都不是百分百可靠，財務、法務這類高風險欄位不能讓自動結果直接進生產。務實的做法是給抽取結果配一個置信度，低於閾值的進人工複核佇列，高於閾值的自動放行，並且把複核記錄留痕。這樣既享受了自動化的吞吐，又在關鍵欄位上保住了人能兜底的那條線。結構化做到這個程度，後面的權限隔離和時效管理才有抓手——下一節會接著講，文件進庫之後，怎麼給它配責任人和保鮮期。

第三道工序：時效治理，給每份文件配責任人和保鮮期

前兩道工序解決的是「髒」的問題，這一道解決的是「舊」的問題。一份格式乾淨、結構完整的文件，如果內容已經過期，它對檢索系統的破壞性比一段亂碼更大——亂碼會被向量模型當作噪聲大機率邊緣化，而過期文件往往寫得規範、表述自信、語義清晰，恰恰最容易被召回到答案的前列。使用者問「報銷審批走哪個流程」,系統檢索出一份措辭嚴謹的舊制度，模型據此生成了一段看起來完全可信的回答，沒有人會懷疑。問題在這裡悄悄發生：模型沒有時間觀念，它不知道這份文件是去年作廢的版本。

所以時效治理的第一件事，是給每份入庫文件繫結兩個不能為空的欄位：責任人和複核週期。責任人決定了當這份內容需要更新時，系統知道該提醒誰；複核週期決定了文件在什麼時間點會被強制重新確認有效性。這兩個欄位聽上去是管理動作，落到工程上其實是後設資料約束——文件進入知識庫時，如果這兩項缺失，入庫流程就應該攔下來，而不是放行後指望事後補。一旦放行，你會發現半年後沒人記得這份文件歸誰管，它就成了無主件，既不會被更新也不會被刪除，靜靜躺在索引裡等著誤導下一個提問的人。這就是所謂「文件墳場」的成因：不是文件太多，是沒有人對單份文件的有效性負責。

第二件事，是讓「過期」這個狀態在檢索結果裡可見。很多團隊的做法是到期就刪，這其實過於粗暴。一份政策可能整體作廢，也可能只是某條細則調整，直接刪除會連帶丟失上下文和歷史依據。更穩妥的做法是給文件打上時效標記，檢索命中過期內容時，在結果中顯式標註警告，而不是悄悄返回。這個警告既要傳給終端使用者看，也要傳進送給模型的上下文裡——你可以在拼接 prompt 時把「此文件已於某日期失效」作為一段元資訊注入，讓模型在生成時有機會規避或主動提示。檢索層有時效感知，模型才不會拿著廢稿一本正經地回答。

第三件事，是版本的保留與回溯。企業文件很少是寫一次就定稿的，一份制度可能改過十幾個版本，而檢索系統真正需要命中的，只能是當前生效的那一版。這要求知識庫在底層把「歷史版本可查」和「當前版本唯一」這兩件事同時做到：既要能回溯任意一個歷史版本看它當時寫了什麼，又要保證向量索引和檢索通道裡暴露給模型的始終是生效版。這兩個目標容易被做成對立面——為了能回溯就把所有版本一股腦塞進索引，結果同一個問題召回三個互相矛盾的版本；或者為了乾淨只留最新版，出了糾紛卻查不到當初的依據。正確的拆法是把儲存和檢索分開：歷史全量保留在文件庫，檢索索引只掛當前生效版，版本切換時同步更新索引指向。

把這三件事串起來，會發現時效治理本質上是給靜態文件加上了一條生命週期：建立時繫結責任人，執行中按週期複核，過期後打標而非靜默，更新時切換生效版並保留舊版。這條線一旦缺了任何一環，知識庫的可信度都會隨時間衰減——這也是為什麼很多 RAG 系統剛上線時效果不錯，跑半年開始頻繁出錯，內容沒人維護，索引裡舊文件的比例越來越高，檢索品質自然滑坡。

還有一點必須講清楚：時效治理沒有一套放之四海的模式，它的複雜度直接隨組織規模變化。一個五人團隊，內容生命週期可能根本不需要系統化——誰寫的誰記得，過期了口頭說一聲就改，複核週期寫在腦子裡都夠用。但到了兩千人規模的企業，情況完全不同：文件跨部門、跨業務線，作者可能早已離職，一份制度的失效會牽連多個下游流程，這時候責任人、複核週期、版本生效狀態就必須是系統強約束的欄位，靠人記是記不住的。所以不要照搬大廠的治理框架往小團隊套，也不要拿小團隊的隨意心態管大規模知識庫。先看清自己處在哪個量級，再決定時效治理要做到多重——這件事上，過度工程和治理缺失同樣會出問題。

判斷標準其實很樸素：開啟你的知識庫，隨機抽十份文件，看看有多少能立刻說清楚歸誰管、上次複核是什麼時候、現在掛在索引裡的是不是生效版。答得上來，說明時效治理在跑；答不上來，你餵給 AI 的就不是知識，是一堆沒人擔保的舊檔案。

權限同步：檢索必須在查詢那一刻校驗，而不是入庫時

很多團隊把權限當成入庫階段的一次性動作：文件進庫時打上標籤，以為後續檢索自然就受控了。這是個危險的誤解。向量庫本質上是一張語義相似度的索引表，它記住的是「哪段內容和這個問題最接近」,不記得「誰有權看這段內容」。如果你不在查詢時再做一次權限判斷，語義檢索就成了繞開原有訪問控制的後門——一個沒有 HR 權限的工程師，完全可能通過一句「公司去年的調薪幅度是多少」把鎖在 HR 目錄裡的內容撈出來。文件列表裡他看不到那份檔案，但 RAG 會把裡面的句子拼進答案。這種「權限穿透」不是配置失誤，是架構層面少做了一步。

所以正確的順序是反過來想：先確定「這次提問的人是誰、他能看什麼」,再決定「哪些向量片段允許參與召回」。權限過濾必須發生在召回階段而非生成階段。如果等模型已經把無權內容讀進上下文、再靠提示詞讓它「假裝沒看見」,那等於把控制點交給了一個機率系統——它有機率失守，而合規審計不接受機率。工程上可行的做法是給每個向量片段攜帶訪問控制後設資料(歸屬目錄、密級、可見角色/群組),檢索時把當前使用者的有效權限作為硬過濾條件下推到向量庫查詢裡，先篩掉無權片段，再做相似度排序。這樣無權內容根本進不了候選集，模型也就無從洩露。

要讓這套即時校驗跑得動，身份得是可信且統一的。這意味著檢索服務不能自己維護一套使用者表，而要接到企業既有的身份源上——通過 SSO 拿到登入態，通過目錄服務(LDAP/AD 或 IdP)解析出使用者當下所屬的群組和角色。關鍵詞是「當下」:人員調崗、專案結束、權限回收，這些變化必須在下一次查詢時立刻生效，而不是等向量索引重建才同步。把權限快照烤進靜態索引，等於給離職或調崗的人留了一段時間的越權視窗。讓查詢去問即時的身份系統，雖然每次多一跳延遲，但這是合規的底線成本。

底座是文件本身得先有清晰的歸屬和分級。如果所有材料平鋪在一個大池子裡，沒有分類、沒有讀寫邊界，那查詢時也沒有可供過濾的維度。合理的組織方式是按業務域或團隊建立分類樹，在分類和文件兩個層級上分別配置讀、寫權限，讓「誰能檢索到」「誰能寫入修訂」成為可宣告、可繼承、可審計的屬性。一些文件管理平台已經把這件事和 AI 能力結合起來：自動識別文件型別、掃描出其中的敏感資訊(身份證號、合同金額、客戶名單),據此給出密級建議甚至自動收緊權限。這類自動檢測不能替代人工定級，但能把「哪些文件可能定錯級」這個大海撈針的問題，壓縮到一個可複核的候選清單，顯著降低人工治理的盲區。

最後是審計。權限感知檢索一旦上線，你需要回答的不再只是「系統安全嗎」,而是「上週二下午三點，某某查了什麼、命中了哪幾份文件、其中有沒有觸碰高密級內容」。每一次查詢的發起人、命中片段、應用的過濾規則都應落到審計日誌裡，且日誌本身要防篡改、可追溯。這既是出事後定責的依據，也是平時發現異常訪問模式(比如某帳號短時間內反覆試探敏感目錄)的訊號源。

把這幾層疊起來看，小團隊的協作網盤和企業級知識庫的差距就很清楚了：五個人共用一個空間，靠默契就能維持秩序；兩千人、幾十條業務線、外加合規審查，就必須把訪問控制、身份聯動、生命週期和審計做成系統能力。權限不是知識庫的附加功能，它決定了這套系統能不能進入真實的企業生產環境——做不到查詢時即時過濾，RAG 就只能停在演示階段。

資料主權與合規邊界：文件片段送出去之前要確認什麼

前面幾道工序解決的是「文件乾不乾淨」,這一節解決的是「文件去了哪裡」。一個容易被忽略的事實：當你把一份合同、病歷或員工檔案餵給 RAG 系統，它通常不會留在你的伺服器裡。檢索增強的第一步是把文本切塊、呼叫 embedding 介面算向量；問答的最後一步是把命中的片段拼進 prompt 發給大模型。這兩步裡，有相當一部分商用知識庫走的是第三方雲端 API。也就是說，你的原文片段，實際離開了你的邊界。

對大多數內部知識庫，這沒什麼大不了。但有幾類資料，出境這件事本身就是法律事件，而不是技術選型。受 GDPR 管轄的歐盟個人資料、需要走出境安全評估的特定資料、以及行業監管劃定的敏感資訊——這些資料片段一旦進了境外的 embedding 服務或 LLM 推理叢集，你就可能在不知情的情況下觸發了一次跨境傳輸。審計時它不會以「呼叫了一個 API」的形式出現，而是以「個人資料流向了不在合規清單上的處理方」的形式出現。

所以選型階段要問的不是「模型效果好不好」,而是三個更硬的問題：embedding 能不能自託管，推理能不能落在本地或指定區域，廠商對資料駐留區域給不給書面保證。這三條任意一條答不上來，對涉境資料就要直接劃掉。值得提醒的是，SSL 傳輸加密和儲存側的安全認證解決的是「傳輸和落盤安全」,和「資料在哪個法域被處理」是兩碼事——前者再齊全，也不替你回答出境問題。對資料主權要求高的場景，能私有化部署、把整條鏈路收在自己機房或自有 VPC 裡的方案，往往是唯一能通過合規評審的選項。

把判斷落成一張可執行的檢查表會更穩妥：

• 分類先行：哪些文件庫含個人資料、哪些含出境受限資料，在入庫前就打好標籤，而不是出事後再翻。
• 鏈路畫圖：把每一類資料從切塊、向量化到推理的完整流向畫出來，標清每一跳的處理方和物理位置。
• 區域約束：對受限資料強制走自託管 embedding 與本地/指定區域推理，在配置層而非靠人記。
• 合同兜底：對必須用外部服務的部分，確認資料處理協議、駐留承諾和留存刪除條款都白紙黑字寫下來。

合規的另一半是「說得清」。監管和審計越來越不滿足於「我們很安全」這種口頭表態，而是要看你能不能復盤整個系統是怎麼被訓練、監控和評估的。這正是 EU AI Act、NIST 風險管理框架(NIST RMF)和 ISO/IEC 42001 這幾套體系想要的東西——它們的共同訴求，是把 AI 系統的來龍去脈變成可追溯的記錄。落到文件治理上，意味著你得保留：每一類資料的處理位置和法律依據、模型呼叫的對象與版本、敏感資料的流向日誌。這些不是為了好看，而是審計人員坐下來翻賬時，你能逐項指給他看的證據。

一個務實的判斷：資料主權不是上線前補一份合規文件就能補回來的，它是架構決策。embedding 跑在哪、推理落在哪、片段經過誰的手，這些在你選平台、畫資料流的那一刻就基本定死了。把它當成入庫工序的一部分提前想清楚，遠比等法務找上門再返工要省得多。下一節會進入更動態的場景：當知識庫不再只讀，而是允許 Agent 寫入時，審計和可觀測要怎麼跟上。

當知識庫可被 Agent 寫入：審計、分級與可觀測

前面六道工序假設了一個隱含前提：知識庫是只讀的，人寫進去，機器讀出來。但這個前提正在崩塌。現在不少協作平台已經允許 Agent 直接往知識庫裡寫內容、改條目、生成新文件，知識庫從一個被動檢索的語料庫，變成了一個會自己長東西的系統。一旦寫入端開了口子，前面所有關於清洗、結構化、時效的努力都可能被悄悄稀釋——一個 Agent 半夜批次補全了三百條文件，沒人知道它依據的是哪版資料、哪個模型、用了什麼提示詞，而這些內容下一秒就成了別人檢索的「事實」。

所以這一節談的不是怎麼把內容餵進去，而是當機器也能往裡塞東西時，你拿什麼兜底。核心是三件配套：能追溯到每次寫入的操作審計、按角色切分的寫入權限分級、以及一個明確劃定的自主權邊界——哪些操作 Agent 可以獨立完成，哪些必須停下來等人確認。少了任何一件，品質下滑都會以一種沒有報錯、沒有告警的方式發生。

我們已經在調 chunk 大小和換 embedding 模型了，為什麼效果還是不穩定？

因為你在調的是檢索層，而不穩定的根子常在資料層。chunk 切多大、用哪個 embedding,決定的是「在一堆內容裡能不能找準」,但如果那堆內容本身有重複版本、過期條目、被 Agent 無聲改寫過的片段，你切得再精準，召回的也是髒的。一個典型訊號是：同一個問題，今天答得對，過兩週答錯了，中間沒人動過檢索配置——那大機率是底層文件被寫入或漂移了。建議先做一件事：給每次模型輸出掛上它實際引用的資料版本和模型版本，做成可追溯的審計記錄。這樣下次結果變差，你能直接定位是哪份資料在哪個時間點變了，而不是反覆在 chunk 和 embedding 之間試錯。檢索調參是有上限的，資料可觀測才是天花板。

權限過濾放在入庫時還是查詢時？

查詢時。入庫時按權限切分，意味著你要為每種訪問級別維護一套副本，文件一更新就得同步多份，遲早錯位。正確的做法是入庫只存一份帶權限標籤的內容，在檢索那一刻拿當前查詢使用者的真實權限去過濾候選片段——使用者看不到的，根本不進入送給模型的上下文。這在知識庫可寫入之後尤其關鍵：Agent 寫入的新內容也必須帶上權限後設資料並接受同一道過濾，否則一個本該受限的片段被 Agent 生成出來後，會繞過原有的訪問控制洩露出去。權限不是入庫時的一次性動作，是查詢時的即時判斷。

入庫前的清洗具體要做哪幾件事？

按優先順序排，大致是這麼幾層。第一層是去髒：去掉重複文件、合併矛盾版本、剝離格式噪聲(頁首頁尾、導航殘留、亂碼),讓一份事實只有一個權威表述。第二層是結構化：把 PDF、聊天記錄、工單這類非結構內容抽成帶欄位的可治理資料，標題、歸屬、時間、責任人都要落到後設資料上，後續的時效治理和權限過濾才有抓手。第三層是安全掃描：在內容進庫前過一遍敏感資訊和內容安全檢測，留下可複核的檢測結果示例，而不是等它被檢索出來才發現問題。等到了 Agent 可寫入階段，這三層都得對寫入端再做一遍——人工錄入和機器生成，適用同一套准入標準，不能因為是 Agent 寫的就免檢。

資料出境合規怎麼和 RAG 部署對齊？

關鍵是想清楚：送出去的不是整篇文件，而是被檢索命中的片段，合規判斷要落在片段這個粒度上。在片段離開你的邊界、進入外部模型之前，至少確認三點：網路層是否做了隔離，送出的內容是否經過脫敏與內容安全控制，以及是否保留了可追溯的審計日誌，能說清這條片段在什麼時間、因為誰的什麼查詢被送往了哪裡。還有一件容易漏的——刪除要能驗證。當某份文件因合規要求需要下線時，你得有一套經過測試的刪除流程，確認它不僅從原始儲存刪了，也從索引、快取和 Agent 可能寫入的衍生內容裡徹底清除，並能拿出刪除已生效的證據。

把這些串起來，治理就不再是一次性的入庫動作，而是一個閉環：用可觀測性工具持續追蹤模型在真實場景裡的表現，把每次涉及的提示詞、模型版本、測試結果、發現的問題和對應的改進措施都記下來。下一輪再最佳化時，你改的是有據可查的具體環節，而不是憑感覺重調參數。知識庫能被機器寫入之後，這套記錄就是你和品質漂移之間唯一可靠的緩衝帶。