需求背景：从「全量索引」到「权限感知」的转型

某金融 SaaS 企业原有基于关键词匹配的 FAQ 系统，在接入 DeepSeek-V4 做智能问答升级时，暴露出两个核心矛盾： 1. 业务部门要求答案必须遵守文档权限（如合同仅法务组可见） 2. 技术团队实测发现纯向量检索在 20w+ 文档规模下，TOP-3 召回率不足 60%

阶段一：混合检索管线的三次迭代

第一次尝试：向量+关键词的简单拼接

• 技术组合：DeepSeek-V4 Embedding + BM25
• 问题：权限过滤后结果集过小，业务反馈「经常返回空」
• 关键指标：P@5（Precision at 5）仅 0.38
• 深度分析：向量检索受限于权限过滤后的候选集过小，而 BM25 在专业术语上表现不佳

第二次调整：引入重排层

• 新增 cross-encoder 模型（DeepSeek-Reranker）
• 改进点：先做无权限检索引擎级召回，再用业务规则过滤后重排
• 新问题：财务部投诉「看到其他部门文档标题」
• 技术细节：重排模型需在 200ms 内完成 50 个候选文档的排序
• 性能优化：采用量化后的 INT8 模型，推理速度提升 2.1 倍

最终方案：离线分权限建索引

1. 预处理阶段：
2. 按 RBAC 规则生成 N 个文档子集
3. 每个子集独立构建 Milvus 集合 + Elasticsearch 索引
4. 索引构建耗时：从单索引 4 小时增至多索引 11 小时
5. 查询阶段：
6. 网关层校验 JWT 提取用户权限标签
7. 路由到对应权限等级的检索管线
8. 新增 35ms 权限校验开销
9. 成本代价：索引存储开销增加 3.2 倍
10. 权衡点：选择牺牲存储成本换取查询性能和权限安全性

阶段二：权限继承的暗坑

预期逻辑

flowchart LR
    A[用户提问] --> B{权限校验}
    B -->|通过| C[检索对应集合]
    B -->|拒绝| D[返回空]

实际故障场景

• 场景1：市场部上传的 PDF 内含有敏感数据表截图
• 根因：OCR 文本未被继承原文件权限标签
• 影响范围：3 个业务部门涉及 42 份文档
• 场景2：跨部门协作文档的嵌套权限
• 现象：子文档继承父文档权限导致过度曝光
• 解决方案：实现动态权限合并计算

技术解决方案

1. 预处理流水线改造：
2. 增加权限标签注入步骤
3. 对非结构化文本强制打上源文件 ACL
4. 对嵌套文档实现权限合并计算
5. 实时校验层：
6. 在 RAG 召回阶段二次校验片段级权限
7. 采用布隆过滤器降低校验开销

阶段三：上线后观测与调优

核心指标对比（上线 30 天）

资源开销与性能

• DeepSeek-V4 32K 上下文窗口占用率：
• 峰值 78%（混合检索场景）
• 均值 52%（简单问答场景）
• GPU 内存占用：
• 纯向量检索：12GB
• 混合检索：19GB
• 引入重排后：23GB
• 冷启动优化：
• 采用 vLLM 实现连续批处理
• P99 延迟从 1.2s 降至 680ms

关键教训与工程启示

1. 权限系统的动态性：
2. 文档转移部门需触发索引重建
3. 实现权限变更的实时事件通知机制
4. 混合检索的代价：
5. 召回率提升可能让位于安全合规
6. 需建立业务价值与技术成本的量化评估模型
7. 非结构化数据处理：
8. OCR 是权限黑洞，所有衍生文本必须继承源 ACL
9. 对图片、表格等特殊内容建立专项处理流程
10. 性能与安全的平衡：
11. 权限校验不能完全依赖预处理
12. 需在查询链路实施多层校验

待解决问题与技术路线

1. 多级权限下的索引管理：
2. 探索基于属性的访问控制（ABAC）模型
3. 测试分层索引结构的可行性
4. 实时性要求与索引更新的矛盾：
5. 评估增量索引构建方案
6. 测试 DeepSeek-V4 的上下文学习能力替代部分检索
7. 成本优化方向：
8. 测试 GPTQ 量化对重排模型的影响
9. 探索混合精度推理的可能性

实施检查清单（部分关键项）

• [ ] 文档预处理阶段注入权限标签
• [ ] 实现嵌套文档权限合并计算
• [ ] 建立索引更新的事件驱动机制
• [ ] 在查询链路部署二次权限校验
• [ ] 对 OCR 内容实施专项权限继承