跳转至

技术路线外部调研与方案修正

为什么做这轮调研

前一轮实验已经验证了入库阶段不能过早摘要化。但这些实验仍然默认了既有技术路线：ES / embedding / MCP / Zenoh / 企微入口。

为了避免在既定路线里自证，本轮并行调研了企业 RAG、开源知识库、检索引擎、GraphRAG、MCP 工具层和总线/编排方案。结论是：当前主线不用推倒，但需要做关键修正。

总结论

OrgReOrg / Harness 的核心不应被 Dify、RAGFlow、Open WebUI 或 AnythingLLM 整体替代。它们更适合被拆成可借鉴模块：

  • Dify：Knowledge Pipeline、External Knowledge API、retrieval testing。
  • RAGFlow：复杂文档解析、可视化 chunk、引用溯源。
  • Open WebUI：语义查询、精确 grep、按行读取组合成 agentic knowledge tools。
  • AnythingLLM：attached document 与 RAG 的产品边界。
  • LlamaIndex / Haystack：ingestion、pipeline、eval 和 workflow 组件。
  • LangGraph / Temporal：checkpoint、human-in-the-loop、durable execution。

需要立刻修正的地方：

  1. 检索底座不能只验证 ES / OpenSearch，也要纳入 Postgres + pgvector / FTS。
  2. MCP 不作为安全边界，必须经过 Tool Gateway。
  3. Zenoh 暂时不进入核心 Demo 主线，先用 registry + HTTP/gRPC，必要时再评估 NATS、Kafka / Redpanda 或 Zenoh。

检索底座对比

路线 适合什么 当前判断
OpenSearch / Elasticsearch BM25、hybrid、RRF、rerank、explain、索引生命周期、权限过滤 第一候选，但要验证运维复杂度和许可边界
Postgres + pgvector / FTS 小中规模、强一致、低运维、RLS、业务数据同库 必须进入第一批 benchmark
Qdrant / Weaviate 快速向量和混合检索原型 可作为第二批对照
Vespa 大规模、复杂排序、在线特征、强 ranking expression 当前过重，除非排序逻辑明显复杂
GraphRAG / LightRAG 多跳、全局总结、跨文档关系 只作为增强层，不替代基础检索

下一轮实验从 retrieval_failure_benchmark 升级为：

text retrieval_platform_benchmark

同一批文档、同一批查询、同一批权限和 stale data 反例，同时跑：

  • BM25 only
  • vector only
  • BM25 + vector + RRF
  • weighted fusion
  • rerank top50 / top100

指标包括 Recall@20 / 50、nDCG@10、MRR、P50 / P95 / P99、update/delete 可见延迟、权限泄漏数和资源成本。

必须验证的坑

  • 只做 vector search 会漏掉合同号、错误码、SKU、政策条款。
  • BM25 分数和 cosine 分数直接相加会因为尺度不同而失真。
  • ANN topK 后过滤权限会导致召回断崖，甚至泄露候选存在性。
  • reranker topK 太小无法救回第一阶段没召回的结果；太大则增加延迟和成本。
  • 只 upsert 不 delete 会留下旧 chunk、旧 embedding 和旧 ACL。
  • 中文、英文、编号、缩写和专有名词 analyzer 配置会明显影响 BM25。
  • GraphRAG 社区摘要如果跨权限域，会把受限材料混入摘要，后续很难安全裁剪。

工具层修正

MCP 只解决工具接入协议，不解决安全。第一阶段应新增 Tool Gateway：

text Agent Orchestrator -> Tool Gateway -> Tool Registry -> MCP / HTTP / internal function tools -> Audit Log

Tool Gateway 至少负责：

  • 身份、租户、scope 校验。
  • 工具 allowlist 和 schema hash 固定。
  • 高风险写操作人工确认。
  • 输入摘要、输出 hash、trace id、耗时和错误审计。
  • 工具输出进入模型前的 schema 校验和敏感字段过滤。
  • 阻断 token passthrough、SSRF、越权 scope 和工具描述注入。

总线路线修正

原先把 Zenoh 放在 capability registry / queryable 的较前位置。现在修正为：

阶段 选择 原因
Demo JSON / Postgres registry + HTTP/gRPC 低复杂度、易调试、权限可落表
内部服务发现 NATS 更贴近服务发现、request/reply 和 subject 权限
审计事件流 Kafka / Redpanda 适合不可变事件、长期留痕和回放
长流程恢复 Temporal / LangGraph 适合人审、长任务、失败恢复和 checkpoint
弱网络 / 边缘 / 多机房 Zenoh spike 出现真实需求后再接入

Zenoh 的 pub/sub/query/location transparency 思想仍然有价值，但当前 Demo 最大风险在检索质量、权限过滤、工具治理和长流程恢复。过早引入 Zenoh 会增加调试和运维复杂度。

更新后的实验优先级

  1. retrieval_platform_benchmark：OpenSearch/ES vs Postgres+pgvector/FTS，带权限、删除、旧新冲突和中文分词反例。
  2. tool_gateway_safety_harness：MCP 工具描述注入、输出注入、SSRF、越权 scope 和写操作审批。
  3. document_parser_spike：RAGFlow / Docling / MinerU 处理 PDF、表格、扫描件，验证复杂文档入库质量。
  4. external_knowledge_api_adapter：设计兼容 Dify External Knowledge API 的 /retrieval 接口。
  5. graph_rag_spike：只在多跳、全局总结和跨文档关系问题上测试 GraphRAG / LightRAG。

关键来源