跳转至

风险驱动验证计划

为什么要改方向

Context Router Demo 只能证明一个直观事实：上下文库变多后，先路由再检索通常会更快、更省、更少噪音。

这个结论本身价值不大。真正需要验证的是：当我们逐步实现 ES、embedding、MCP、Zenoh、企微主动询问和权限视图后，会遇到哪些工程问题、产品问题和组织问题，哪些问题会让方案无法落地。

所以后续 Demo 应从“证明路由有用”改成“主动制造失败并定位风险”。

最高风险判断

风险 为什么危险 失败信号
入库清洗失真 Agent 后续只会看到被清洗后的结构化上下文，原始语义丢失后很难恢复 搜索命中但证据不完整；摘要替代事实；原文追溯困难
检索质量不可解释 BM25、向量、RRF、rerank 混合后，结果好坏可能难以调试 分数高但内容无关；同一问题多次结果漂移；无法解释为什么命中
权限泄漏 私域知识系统最怕把“存在性、片段、字段、owner”泄露给无权限用户 用户看到不该看的客户、合同、财务或项目线索
MCP 工具边界不硬 如果工具只靠 prompt 约束，Agent 可以误调用、越权调用或被注入诱导 非预期工具调用；敏感输入外发；错误结果进入模型上下文
Zenoh 过早引入复杂度 总线、发现、ACL、拓扑都会增加运维面，早上可能比 JSON registry 更脆弱 服务发现不稳定；ACL 变更需重启；拓扑问题难排查
主动询问打扰人 如果 ask router 问错人、问太频繁、问得不清楚，组织会失去信任 群发、重复问、没人回、回复无法沉淀
成本和延迟失控 多库检索、embedding、rerank、LLM 读证据会叠加成本 单问题调用链过长；token 增长快于知识规模收益
Review 流程堵塞 补充信息如果都需要人工 review，知识卡片会堆积 inbox 积压；过期卡片被继续引用；没人负责提升

风险 1：入库清洗失真

问题

数据进入 ES 前要经历 normalize、classify、chunk、metadata、embedding。每一步都可能损失语义：

  • 聊天上下文被拆碎后，谁在回应谁丢失。
  • 会议纪要被摘要后，假设和事实混在一起。
  • JSON / 表格字段被扁平化后，字段关系丢失。
  • chunk 过短导致证据断裂，chunk 过长导致召回噪音。

下一步实验

做一个 ingestion_quality_demo：

  1. 准备 10 条混合输入：群聊、会议纪要、Markdown、JSON、表格。
  2. 生成清洗后的 context_document。
  3. 对每条输入保留 raw_source_id 和可回溯片段。
  4. 评测三件事：
  5. 能否从清洗结果回到原文。
  6. 关键事实是否丢失。
  7. 权限字段是否保留。

通过标准

  • 每个 context_document 都能追溯到原始来源。
  • 关键事实召回率达到人工标注的 90% 以上。
  • 没有把 task-only 材料提升为 team/public。

第一轮结果

已实现 ingestion_quality_demo。当前样例包含 8 条混合输入、42 个预期事实：

  • naive summary 事实召回率为 19%。
  • structured ingestion 事实召回率为 100%。
  • 结构化入库额外保留 34 个事实。
  • 原文追溯、权限字段保留和 review 状态保留均为 100%。

这个结果不是为了证明结构化一定完美，而是暴露一个明确坑：摘要字段可以存在，但不能成为唯一入库内容。后续 ES / vector / MCP evidence 必须保留原文追溯、chunk、权限字段和 review 状态。

详见：Ingestion Quality Demo：入库清洗质量分析。

风险 2：混合检索难调试

问题

ES hybrid search 不是“接上 embedding 就行”。官方文档里 kNN 搜索要求查询向量和文档向量使用同一模型、维度一致；近似 kNN 有内存、延迟和召回取舍；过滤条件可能让 kNN 探索更多图节点，反而降低性能。

真正的问题不是能不能搜，而是：

  • 分数怎么解释。
  • BM25 和向量权重怎么调。
  • RRF / rerank 后为什么这个结果排第一。
  • 权限过滤放在检索前还是检索后。
  • 新数据 reindex 后结果是否漂移。

下一步实验

做一个 retrieval_failure_benchmark：

  1. 每个问题标注应该命中的文档、段落和不可命中的负样本。
  2. 同时跑 BM25、vector、hybrid、rerank。
  3. 记录 top-k recall、MRR、无关高分样本、延迟和 token。
  4. 专门加入反例：
  5. 同义但权限不同。
  6. 关键词很像但业务对象不同。
  7. 旧资料和新资料冲突。
  8. 问题需要跨两个上下文库组合。

通过标准

  • 每次结果都能输出 route log、query log、rank log。
  • top-3 证据必须包含正确来源，或明确报告 gap。
  • 权限过滤必须在证据进入 prompt 前完成。

风险 3：权限模型晚做但不能不设计

问题

我们可以晚做完整 MVC，但不能晚设计权限字段。否则 ES index、MCP output、knowledge card、audit log 都会返工。

最小字段至少要有：

text tenant_id department project owner permission_scope source_acl field_mask review_status expires_at audit_trace_id

下一步实验

做一个 permission_leak_test：

  1. 构造同一问题下不同角色：成员、项目 owner、财务、外部访客。
  2. 同一上下文中混入 public、team、project、restricted、task_only 材料。
  3. 检查搜索结果、摘要、证据路径、owner 信息是否泄露。

通过标准

  • 无权限用户不仅不能看到内容，也不能看到敏感对象存在性。
  • 任何进入 prompt 的 evidence 都带权限判断记录。
  • 权限不足时只能生成授权路径或主动询问，不泄露证据。

风险 4：MCP 工具安全和可审计性

问题

MCP 是工具协议，不是安全边界本身。MCP 官方工具规范要求服务端校验输入、做访问控制、限流、净化输出；客户端需要对敏感操作做确认、展示工具输入、校验结果、设置 timeout 并记录审计。

如果我们把 MCP server 当成“Agent 想调就调”的开放工具层，会有几个坑：

  • 工具描述被注入或误导。
  • Agent 把敏感参数传给错误工具。
  • 工具返回未净化文本，继续污染模型上下文。
  • 错误结果被当成事实写入知识库。

下一步实验

做一个 mcp_safety_harness：

  1. 定义只读工具、草稿工具、高风险工具三类。
  2. 给每个工具加 schema、permission、risk_level、audit_fields。
  3. 注入恶意参数、越权 user、超时、错误返回。
  4. 验证工具网关是否拒绝、脱敏、审计和要求人工确认。

通过标准

  • 高风险工具不能被 Agent 直接执行，只能生成草稿或等待确认。
  • 所有工具调用有 trace id。
  • 工具输出进入模型前必须做 schema 校验和敏感字段过滤。

风险 5：Zenoh 可能过早增加复杂度

问题

Zenoh 适合做 discovery、pub/sub、queryable 和总线组合，但它也带来部署和治理复杂度。

官方部署文档显示 Zenoh 有 peer、client、router、gateway 和 region 等多种拓扑；peer 模式会自动发现可访问节点；ACL 配置可以做 allow/deny，但 ACL 不能运行时更新，需要重启实例才能生效。

对我们来说，真正风险是：

  • 服务发现失控：Agent 看到不该看到的 MCP 服务。
  • key expression 命名混乱：部门、项目、权限边界无法表达。
  • ACL 策略和组织权限模型重复或冲突。
  • Debug 难：一次查询跨多个服务后很难知道错在哪里。

下一步实验

短期不要直接引入 Zenoh runtime。先做 zenoh_registry_sim：

  1. 用 JSON 模拟 key expression。
  2. 定义 capability announce、liveness、queryable 三类记录。
  3. 对每条 capability 加 owner、permission_scope、risk_level、ttl。
  4. 先验证命名、权限和路由日志。

只有当上下文库超过 5 个、MCP server 超过 5 个、需要跨进程 discovery 时，再接真实 Zenoh。

通过标准

  • Agent 每次选择 MCP 服务都有可解释 route log。
  • discovery 结果经过权限过滤。
  • 服务下线、过期、重复注册都能被检测。

风险 6：企微主动询问可能破坏组织体验

问题

主动询问不是“会发消息”就结束。最大风险是问错人、问太多、问得不清楚。

下一步实验

做一个 ask_router_simulation：

  1. 用 20 个真实问题模拟问谁。
  2. 每题限定最多问 1 到 3 人。
  3. 记录选择原因、期待回答格式、超时策略和是否进入知识库。
  4. 加入负反馈：被问人说“我不是负责人”后，router 如何学习。

通过标准

  • 不群发。
  • 每次询问说明原因和用途。
  • 回复默认 task_only，review 后才能提升。
  • 能记录“问错人”的反馈并调整 owner registry。

当前 Demo 应该如何重新定位

context_router_demo.py 保留，但只作为 baseline：

  • 验证 registry 结构是否能表达上下文库。
  • 验证 benchmark 机制是否可跑。
  • 粗估 token 和成本。
  • 不再把“路由能省 token”作为主要成果。

下一步真正的 Demo 应该按风险排序：

  1. ingestion_quality_demo：已完成第一轮本地验证。
  2. retrieval_failure_benchmark
  3. permission_leak_test
  4. mcp_safety_harness
  5. ask_router_simulation
  6. zenoh_registry_sim

官方依据