企業知識庫架構設計：權限、審計、版本控管

企業級 RAG 不是「文件 → AI → 回答」那麼簡單。權限、審計、版本、多模態、多語言——這些是把 RAG 從 Demo 變生產系統的關鍵。

企業級 RAG 的 7 個維度

1. 權限控制（誰能查什麼）
2. 審計日誌（誰問了什麼、AI 回了什麼）
3. 版本管理（文件更新時的 rollback）
4. 多語言（中、英、日的混合處理）
5. 多模態（圖、影、音文件）
6. 來源優先（公司內 > 公開資料）
7. 更新機制（文件變動時的 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）
• 查詢時同時用原文與翻譯版搜尋
• 輸出時統一翻成用戶語言

多模態文件

真實企業文件常含表格、圖片、圖表。處理方式：

1. 用 Gemini Vision / Unstructured 抽取結構
2. 表格保留 markdown 格式
3. 圖片用 Vision 生成 alt-text 一起存
4. 圖表數據手動或 AI 抽取為結構化資料

來源優先策略

當問題涉及通用知識（不在公司文件內）：

1. 先檢索公司知識庫（最權威）
2. 命中分數低時，回退到公開資料（Wikipedia、Google Search API）
3. 明確標示來源等級（公司內部 / 公開資料）

更新機制

文件何時 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