Agentic Search Option Benchmark：技术路线选型实验

实验定位

retrieval_platform_benchmark 已经验证了检索策略的失败模式，但它还没有回答一个更上游的问题：P0 阶段到底先落哪种 Agentic Search 架构，哪些方案只作为后续规模化候选。

本实验用合成评分矩阵对比 6 类方案：

• Markdown 渐进披露 only。
• Postgres FTS + pgvector。
• OpenSearch / Elasticsearch hybrid search。
• managed vector database only。
• Markdown + Postgres FTS/pgvector 分层方案。
• Markdown + OpenSearch/ES 分层方案。

它不是正式压测。它的作用是把当前选型标准显式化，避免只凭直觉决定“要不要 ES”“要不要向量库”“要不要继续保留 Obsidian/Markdown”。

运行命令：

bash python scripts/agentic_search_option_benchmark.py --write-report

当前结果

Profile	Winner	含义
P0 MVP Agentic Search	tiered_markdown_postgres	P0 默认采用 Markdown 渐进披露 + Postgres FTS/pgvector 检索缓存
Scale Multi-Department Search	tiered_markdown_opensearch	规模上来后再引入 OpenSearch/ES hybrid search adapter
Ontology Authoring And Review	markdown_progressive_only	docs/vault 仍是团队本体制品生产和 review 层，不被索引后端替代

汇总指标：

• Profile 数：3。
• 期望 winner 命中率：100%。
• managed_vector_only 进入 Top2 次数：0。

关键结论

P0 不直接以 ES/OpenSearch 作为默认主线。当前小团队阶段最重要的是流程闭环、权限字段、生命周期、原文追溯和调试日志。Postgres FTS/pgvector 更适合先承担 D3 检索投影和 context document 表。

ES/OpenSearch 没有被废弃，而是后置为规模化 adapter。当部门、上下文库、connector 和查询并发变多后，它在 BM25、中文分词、hybrid、RRF、rerank、explain 和大规模索引上会更有价值。

纯向量库不作为核心默认方案。它可以作为组件，但不能独自承担合同号、错误码、政策条款、人名、权限过滤、删除传播、审计和证据追溯。

Markdown/Obsidian 的位置也更清楚了：它是 Ontology 本体制品生产、review、渐进披露和人类协作层，不是 D3 大规模检索后端。后续系统应让检索投影回指 Ontology artifact 和 Evidence 原始来源，而不是复制出第二套事实源。

下一轮要验证什么

下一轮不是继续调权重，而是把已落地的 adapter skeleton 接到真实测试服务做 live conformance 和真实对照。SearchConnector contract、ContextDocumentRecord schema 和 adapter conformance test 已经落地，真实 adapter 必须复用同一验收集：

1. 用真实 Postgres FTS/pgvector 测试服务跑 live conformance、延迟、成本、rank log 和删除传播。
2. 用真实 OpenSearch/ES 测试服务跑 live conformance、索引传播、权限过滤和规模化查询成本。
3. 用同一批 context document 对比两个 adapter。
4. 对比 chunk 策略：section chunk、sliding window、record-aware chunk。
5. 对比 ranking 策略：BM25/FTS only、vector only、RRF、weighted fusion、rerank top50/top100。
6. 记录 P50/P95、索引更新延迟、删除传播、权限泄漏、rank log 可解释性和 token 成本。

原始输出见 vault/50-outputs/agentic-search-option-benchmark-analysis.md。