企業知識庫文件怎麼整理?版本、權限與中繼資料清單
企業知識庫效果不好,常不是模型不夠強,而是系統不知道哪一份才是正本、文件何時失效,以及誰有權看到。匯入 RAG 前先建立文件清冊,比一開始調整向量資料庫參數更重要。
每份文件至少要有的欄位
- 唯一文件 ID,避免改檔名後失去追蹤。
- 標題、部門、文件 owner 與聯絡方式。
- 版本、發布日、最後審查日與失效日。
- 正本位置與允許引用的深層連結。
- 機密等級、可見群組與禁止使用範圍。
- 語言、文件類型、產品或地區等搜尋欄位。
- 取代哪一份舊文件,以及是否已完成下架。
先定義正本
同一政策散落在 PDF、簡報、Email 與聊天室時,模型可能同時找出互相矛盾的版本。每個主題要指定一個權威來源,其他副本標為參考或不納入索引。更新流程也要確保新版本上線時,舊片段從索引移除。
文件品質檢查
掃描 PDF 先確認 OCR 是否正確;表格要保留欄位關係;頁首頁尾與目錄不要重複進每個片段;圖片中的關鍵資訊需要可讀文字。切塊前清除無意義重複內容,但不要把法條編號、版本與例外條款一起刪掉。
Google Cloud 的 RAG 流程包含資料轉換與切塊,這一步不只是技術參數。切塊邊界要符合文件語意,例如把問題和答案、條文和例外、產品和規格留在同一個可理解範圍。
權限不能等回答後才過濾
使用者發問時,檢索層就應套用身分與文件權限,不能先把機密片段送進模型,再期待輸出階段不顯示。OWASP 對向量與 embedding 弱點的建議也包含細緻權限與資料邏輯隔離。
建立更新與下架流程
文件 owner 應在到期前收到審查提醒。更新時保存版本差異、重新索引受影響片段並重跑相關測試題;撤銷權限或刪除文件時,確認原檔、快取、索引與備份依公司政策同步處理。
匯入前驗收
- 抽查每個部門十份文件,正本與版本欄位完整。
- 搜尋過期標題,不應出現在可用結果。
- 用不同角色查同一問題,結果符合各自權限。
- 每個片段可回到原始文件與具體位置。
- 文件更新後,舊答案不再被引用。
完成資料清理後,可接著做RAG 測試題與引用驗收及知識庫權限設計,或查看企業 AI 知識庫服務。