检索结果缓存

复用相同查询条件下的候选证据结果。

检索结果缓存复用候选证据，不应直接复用授权结论。相同自然语言查询在不同用户、项目、日期和资料版本下可能有不同合法结果。企业先定义查询的业务条件，再决定哪些请求能够共享结果；不能只用query字符串或embedding相似度作键。

建议缓存键包括规范化query、tenant、授权集合或策略版本、corpus/index generation、as_of以及检索参数。查询重写和过滤条件也会影响结果，应记录版本。缓存返回source_version与定位，最终原文读取仍重新鉴权，避免权限变化和删除传播的竞态。

公开工具安全原则支持在真实数据访问点核验身份与scope；这里的缓存方案是企业设计建议，并非某个框架自动提供。共享缓存可以减少检索负载，但跨用户共享需要证明权限条件一致。即使候选正文不返回，标题、片段和文档存在性也可能泄漏，因此候选与rerank阶段同样受范围约束。

失效不仅靠TTL。源更新、删除、ACL与群组变化、索引切换及时间窗口变化都要触发依赖失效。对于已进入context或摘要的旧证据，应使相关在途Run重建输入并复核待发布产物。清掉缓存后继续使用旧摘要，仍可能输出失去授权的内容。

可以先缓存低风险、稳定公共资料，并对高风险或动态权限任务关闭共享。缓存粒度需平衡成本：过细键降低命中，过宽键增加陈旧与隔离错误。不要为了命中率牺牲业务边界。

测试同一query由不同角色请求，随后撤销一份文档、更新一家公司期间、切换索引generation。检查候选、片段、rerank输入、最终引用与日志都符合当前权限。报告有效命中、陈旧结果与跨scope错误，而不只报告Redis hit rate。

实践重点：键绑定tenant、授权版本、corpus/index generation、as_of和参数；读出再鉴权。

验证抓手：用源更新、删除和ACL变化测试结果失效。

常见误区：相似query跨用户共享，或权限撤回后仍命中。

MCP：安全建议；Anthropic：Context engineering。

检索缓存还应保留被排除结果的安全统计，帮助判断低召回来自数据不足还是权限过滤，但不记录越权正文或可识别片段。