向量缓存到底该放在哪一层向量检索加缓存听起来像给慢查询盖一条快速通道放错位置以后却可能把过期答案和越权结果送得更快。缓存设计的起点不是“命中率要多高”而是某类结果能否安全复用、何时必须失效、谁可以读取。把这些问题放在键设计之后再想通常就已经晚了一步。区分可缓存的对象先分开看查询向量、候选文档、重排结果和最终回答。查询向量通常可按模型版本和规范化后的输入复用但要注意用户文本是否含敏感内容候选文档必须带租户、权限范围和索引版本重排结果还受查询、候选集和重排策略影响最终回答则常含会话语境复用范围最窄。把它们统统塞进同一层键值存储日后很难解释一次命中究竟复用了什么。缓存键应包含真正影响结果的维度而不是只取原始问题。至少考虑语料版本、嵌入或重排模型版本、过滤条件、语言处理方式和权限范围。键过粗会串数据键过细会很难命中可先用少量可解释字段建立基线再依据真实访问模式调整。不要为了节省几个字符省掉权限或版本信息那属于把门牌号写成“这附近”。把失效视为数据协议的一部分文档新增、更新、删除和权限变更都可能让缓存失效。仅依赖固定过期时间很简单却无法保证敏感文档撤权后立即停止可见。更稳的做法是让索引版本或权限版本进入键更新时发布失效事件当事件链不可用时再用较短过期时间做兜底。是否需要主动删除取决于数据风险和存储成本但这个选择应有明确记录。多级缓存可以把本地进程缓存、共享缓存和向量库本身的能力组合使用不过每层都要说明一致性预期。本地缓存适合短生命周期的配置或热查询却会因实例间不同步而保留旧值共享缓存便于统一失效却增加网络依赖和序列化成本。不要把“缓存未命中”当异常也不要把缓存服务不可用变成整条问答链路不可用必要时应回落到受限的直接查询。防止缓存绕过权限检查读取缓存前就要完成身份和范围解析缓存条目中也要保留可验证的授权维度。不能先按问题命中答案再在最后一步尝试删词信息一旦进入后续上下文风险已经产生。对于跨租户完全相同的公共资料可建立显式标记的公共命名空间而不是悄悄共用所有条目。调试日志记录键摘要、命中层级和失效原因即可避免把完整提问和文档内容再次复制出去。用场景验证取舍验证集至少包括文档更新后查询、撤销权限后的查询、相同问题不同租户、模型升级前后、缓存服务超时和并发下的重复请求。每个场景写明预期返回新结果、拒绝访问、回源查询还是给出稍后重试提示。若要比较成本或时延固定语料、请求组成、并发策略和资源条件脱离这些前提的数字只能说明一次运行不说明通用效果。缓存不是检索质量问题的创可贴。先保证过滤、来源和索引更新正确再决定哪些中间结果值得复用。一个能说明“为什么命中、为什么失效、为什么不能共享”的缓存才会在系统变复杂后仍然好维护。