Retrieval Platform Benchmark：第二轮检索风险实验

这个实验验证什么

这个实验验证第二个关键风险：检索系统不是“接上 ES、embedding 或向量库”就结束，真正难点在于权限、删除、旧新冲突、别名、精确编号和 gap 判断。

当前版本是本地可复跑 benchmark，不是真实 OpenSearch / Elasticsearch 或 Postgres + pgvector / FTS 压测。它先把失败模式固化成样例和指标，后续再把同一批样例接到真实平台 adapter。

运行命令：

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

输出文件：

text vault/50-outputs/retrieval-platform-benchmark-results.json vault/50-outputs/retrieval-platform-benchmark-analysis.md

样例设计

当前样例包含 8 条文档、7 个问题，专门覆盖反例：

• restricted 薪酬材料：验证权限泄漏。
• deleted 供应商账号：验证删除 chunk 是否仍被搜到。
• superseded 星河付款旧记录：验证旧新冲突。
• WeCom / 企业微信别名：验证语义别名。
• 合同号 ARR-77 和 CT-2026-014：验证精确匹配。
• docs / vault 边界：验证团队知识库基础问答。

当前结果

策略	Recall@3	Top1	Gap 准确率	安全回答率	权限泄漏	生命周期违规	禁止命中
lexical_unsafe_global	60%	60%	0%	14%	2	5	3
lexical_acl	60%	60%	0%	14%	0	6	2
semantic_acl	100%	100%	0%	29%	0	5	2
hybrid_guarded	100%	80%	100%	100%	0	0	0

这里的 hybrid_guarded 指：

text permission filter -> active lifecycle filter -> lexical + semantic scoring -> confidence threshold -> evidence

结论

第一，权限过滤必须前置。lexical_unsafe_global 会把 restricted 薪酬材料检出，说明不能先全局检索再让模型或后处理过滤。

第二，只做 ACL 不够。lexical_acl 和 semantic_acl 虽然不会泄漏 restricted 材料，但仍会命中 superseded / deleted chunk。旧材料会污染答案，已删除材料会暴露存在性。

第三，语义检索有价值，但不能单独承担安全和正确性。semantic_acl 能解决 WeCom / 企业微信别名，但仍处理不了删除、过期、旧新冲突和 gap。

第四，最低置信阈值是必要组件。否则用户问 restricted 或 deleted 材料时，系统会返回弱相关文档，导致本该报告 knowledge gap 的问题被硬答。

对架构的影响

context_document schema 需要补齐这些字段：

text permission_scope lifecycle review_status updated_at supersedes source_uri audit_trace_id

Retrieval Gateway 需要在 evidence 进入 prompt 前输出：

text filter log rank log permission decision lifecycle decision gap decision

ES/OpenSearch 与 Postgres+pgvector/FTS 的选择不能只看 Recall。下一步真实平台 benchmark 要同时看 ACL 表达、删除传播、更新延迟、中文分词、精确编号、运维成本和调试成本。

下一步

1. 把当前反例集接到 OpenSearch/ES adapter。
2. 把同一反例集接到 Postgres + pgvector / FTS adapter。
3. 增加 P50 / P95 / P99、索引成本、增量更新延迟和删除传播时间。
4. 加入 rerank top50 / top100，对比 Recall、MRR、nDCG 和成本。
5. 把权限泄漏测试从检索结果扩展到路径、owner、摘要和对象存在性。

详细风险序列见：风险驱动验证计划。