9.3 进阶案例：企业级知识库

9.1 的本地 RAG 是个好的起点，但企业级场景需要考虑更多：​多用户隔离、权限控制、数据增量更新、检索效果优化、高可用部署​。这篇文章给出一个从 Demo 到 Production 的完整升级路线。

📑 目录

• 从 Demo 到 Production 的差距
• 架构设计：企业级 RAG 系统全貌
• 多租户与权限控制

增量更新机制

效果评估体系

部署与运维

从 Demo 到 Production 的差距

9.1 的 Demo 版本：
├── 单用户
├── 静态文档（一次性导入）
├── 简单向量检索（Top-K）
├── 无权限管理
├── 无监控
└── 单机运行

企业级版本需要：
├── 多部门/多角色/多租户        ← 隔离
├── 文档持续入库 + 自动处理流水线    ← 增量
├── 混合检索 + Rerank 重排         ← 精度
├── RBAC 权限 + 操作审计           ← 安全
├── 全链路监控 + 告警             ← 可观测
├── 高可用部署 (K8s + 多副本)     ← 稳定
└── 效果评估 → 反馈优化闭环       ← 质量

架构设计：企业级 RAG 系统全貌

┌─────────────────────────────────────────────────────┐
│                  企业级知识库系统                    │
│                                                     │
│  ┌──────────┐   ┌──────────┐   ┌──────────────────┐ │
│  │ Web前端   │   │ API网关  │   │ 管理后台         │ │
│  │ (问答界面)│   │ (鉴权/限流)│   │(文档管理/用户/统计)│ │
│  └─────┬────┘   └────┬────┘   └────────┬─────────┘ │
│        └──────────────┼──────────────────┘          │
│                       ↓                             │
│  ┌──────────────────────────────────────────────┐ │
│  │              核心服务层                       │ │
│  │                                              │ │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────────┐ │ │
│  │  │ RAG 服务  │  │ 文档服务  │  │ 用户/权限    │ │ │
│  │  │ (问答)    │  │ (CRUD)   │  │ (RBAC)      │ │ │
│  │  └────┬─────┘  └────┬─────┘  └──────┬───────┘ │ │
│  │       └──────────────┼───────────────┘        │ │
│  │                      ↓                        │ │
│  │  ┌──────────────────────────────────────┐   │ │
│  │  │         数据层                        │   │ │
│  │  │  Milvus(向量) + PG(元数据) + Redis(缓存)│  │ │
│  │  └──────────────────────────────────────┘   │ │
│  └──────────────────────────────────────────────┘ │
│                                                     │
│  ┌──────────────────────────────────────────────┐ │
│  │              文档处理流水线                   │ │
│  │  上传→解析→分块→Embedding→存储→索引         │ │
│  │  支持触发方式: 手动 / 定时 / Webhook / API     │ │
│  └──────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘

多租户与权限控制

# 企业级 RAG 的多租户检索实现
class TenantAwareRetriever:
    """带租户隔离的检索器"""
    
    def retrieve(self, query: str, tenant_id: str,
                 user_id: str, top_k: int = 5):
        # 1. 向量检索时带上租户过滤
        vector_results = self.milvus.search(
            embed(query),
            filter={"tenant_id": tenant_id},  # 只查本租户的文档
            limit=top_k * 2,  # 多取一些用于后续过滤
        )
        
        # 2. 二次过滤：基于文档级别的权限
        authorized_results = []
        for doc in vector_results:
            if self.rbac.check_read_permission(
                user_id, doc.metadata["doc_id"]
            ):
                authorized_results.append(doc)
            if len(authorized_results) >= top_k:
                break
        
        return authorized_results

# 权限模型
class DocumentPermission:
    doc_id: str
    owner_dept: str      # 所属部门
    visibility: str       # public / dept_only / private
    allowed_users: list[str]  # private 时白名单
    allowed_roles: list[str]   # 角色级权限

增量更新机制

文档更新策略：

方案 A：定时全量重建（适合 < 1万文档）
每天凌晨全量重新 Embedding
→ 简单粗暴，小规模够用

方案 B：增量更新（推荐）
监听文档变化 → 只处理新增/修改的文档
→ 删除旧的向量 → 写入新的向量

方案 C：事件驱动（最适合）
文档上传/修改时通过 Webhook 触发处理流水线
→ 实时性最好，架构稍复杂

增量更新的关键步骤：
1. 检测变更（文件 hash 对比 / DB timestamp / Webhook）
2. 提取变更的文档 ID 列表
3. 删除旧向量：vectorstore.delete(ids=old_doc_ids)
4. 处理新文档：parse → chunk → embed
5. 写入新向量：vectorstore.add(new_vectors)
6. 更新元数据索引

效果评估体系

❌ 常见误区

• ❌ 直接把 Demo 版上线加个登录就是「企业版」 — 安全和稳定性需要系统性设计
• ❌ 忽略权限到行级别 — 同一个知识库不同人能看到的范围可能完全不同