企業級 RAG 知識庫要從 Demo 走到生產系統，必須補齊權限控制、審計日誌、版本管理、多語言、多模態、來源優先與更新機制 7 個維度：在向量庫 metadata 存 ACL 標籤並於查詢時過濾，每次對話記錄並保存 6 到 24 個月，文件更新採軟刪除加 active 標記，並以延遲低於 3 秒、命中率高於 85% 為監控目標。
發布 2026-06-05 · 最後更新 2026-09-27 · 作者 賴家榮 Andy Lai
企業級 RAG 不是「文件 → AI → 回答」那麼簡單。權限、審計、版本、多模態、多語言——這些是把 RAG 從 Demo 變生產系統的關鍵。
企業級 RAG 的 7 個維度
- 權限控制（誰能查什麼）
- 審計日誌（誰問了什麼、AI 回了什麼）
- 版本管理（文件更新時的 rollback）
- 多語言（中、英、日的混合處理）
- 多模態（圖、影、音文件）
- 來源優先（公司內 > 公開資料）
- 更新機制（文件變動時的 re-embed）
權限控制設計
三層權限：
- 文件層：哪些文件能被誰看（部門、角色、個人）
- 欄位層：同一文件中，敏感欄位（薪資、客戶 ID）只給特定人
- 查詢層：高敏感問題需主管二次核可
實作：向量庫的 metadata 存 ACL 標籤：
{
"text": "...",
"metadata": {
"doc_id": "policy_001",
"department": "HR",
"access_level": ["manager", "hr_specialist"],
"classification": "internal"
}
}
# 查詢時加過濾
filter = {"access_level": {"$in": user.roles}}
審計日誌
每次 RAG 對話要記錄：
- 使用者（user_id）
- 時間戳記
- 問題內容
- retrieved 的切片 ID
- AI 回應
- 用戶反饋（👍/👎）
儲存 6–24 個月，符合稽核要求。
版本管理
文件更新時的策略：
- 軟刪除舊版本（不要直接刪 vector）
- 新版本標記 active=true、舊的 active=false
- 查詢時預設只查 active
- 稽核時可指定查特定日期版本
多語言處理
有些企業文件中英混合：
- 用支援多語的 Embedding（如 BGE-M3、Cohere multilingual）
- 查詢時同時用原文與翻譯版搜尋
- 輸出時統一翻成用戶語言
多模態文件
真實企業文件常含表格、圖片、圖表。處理方式：
- 用 Gemini Vision / Unstructured 抽取結構
- 表格保留 markdown 格式
- 圖片用 Vision 生成 alt-text 一起存
- 圖表數據手動或 AI 抽取為結構化資料
來源優先策略
當問題涉及通用知識（不在公司文件內）：
- 先檢索公司知識庫（最權威）
- 命中分數低時，回退到公開資料（Wikipedia、Google Search API）
- 明確標示來源等級（公司內部 / 公開資料）
更新機制
文件何時 re-embed？
- 文件新增 / 修改 → 立即（背景任務）
- Embedding 模型升級 → 全量 re-embed（每年 1–2 次）
- 切片策略調整 → 全量 re-embed
建議用 message queue（如 Redis、SQS）非同步處理。
監控指標
- 每日查詢量
- 平均 latency（< 3s）
- 命中率（> 85%）
- 用戶滿意度（👍 比例 > 80%）
- 未命中問題 Top 20（找出文件缺口）
架構圖（典型企業 RAG）
使用者
↓ (Web / Slack / Line)
API Gateway (含驗證)
↓
RAG Orchestrator
├→ User ACL Service (查用戶權限)
├→ Vector DB (Qdrant cluster)
├→ Reranker (Cohere API)
├→ LLM (Gemini)
└→ Audit Logger → BigQuery
常見問題
企業級 RAG 跟一般 RAG Demo 差在哪裡？
差在 7 個生產環境必備的維度：權限控制（誰能查什麼）、審計日誌（誰問了什麼、AI 回了什麼）、版本管理（文件更新時可 rollback）、多語言混合處理、多模態文件（圖、影、音）、來源優先（公司內部資料優先於公開資料）以及文件變動時的 re-embed 更新機制。少了這些，RAG 只能停留在 Demo 階段。
企業 RAG 的權限控制要怎麼設計？
作者建議分三層：文件層決定哪些文件能被哪些部門、角色或個人看到；欄位層讓同一文件中的薪資、客戶 ID 等敏感欄位只開放給特定人；查詢層則要求高敏感問題需主管二次核可。實作上是在向量庫的 metadata 存 access_level 等 ACL 標籤，查詢時用使用者角色做 filter 過濾。
RAG 審計日誌要記錄哪些內容、保存多久？
每次 RAG 對話要記錄使用者 user_id、時間戳記、問題內容、被 retrieved 的切片 ID、AI 回應以及用戶的正負評回饋。文章建議儲存 6 到 24 個月以符合稽核要求，典型架構是由 Audit Logger 把紀錄寫入 BigQuery。
企業文件更新時，RAG 向量資料需要重新 embedding 嗎？
要，但時機分三種：文件新增或修改時應立即以背景任務 re-embed；Embedding 模型升級時要全量 re-embed，頻率約每年 1 到 2 次；切片策略調整時也要全量 re-embed。文章建議用 Redis 或 SQS 之類的 message queue 非同步處理，並且舊版本採軟刪除、以 active 標記區分新舊版本，稽核時仍可查特定日期的版本。
企業 RAG 上線後要監控哪些指標？
文章列出五項：每日查詢量、平均 latency 應低於 3 秒、命中率應高於 85%、用戶滿意度（正評比例）應高於 80%，以及未命中問題的 Top 20 清單，用來找出知識庫的文件缺口。這些指標搭配審計日誌，就能持續改善知識庫品質。