语义缓存的核心风险，不是“相似问题返回了旧答案”，而是系统把不同租户的请求错误地判定为可复用。两个问题即使语义接近，所属租户、用户角色、权限范围、知识库版本和实时业务状态也可能完全不同。若缓存键只包含用户输入，或者向量检索只按相似度排序，就可能将一个租户的内部文档、客户对话或业务结论返回给另一个租户。
先定义安全的复用边界
多租户场景下，租户标识应首先参与缓存命名空间或等价性判断，而不能在完成语义匹配后才补做检查。用户角色、权限范围、地区、语言、系统提示词版本、知识库或检索索引版本，也应纳入影响答案的条件。对于强个性化请求，用户身份和权限变化会直接改变答案，此时不应仅凭语义相似度复用结果。
更稳妥的查询顺序是：先依据租户和权限范围缩小候选缓存，再进行语义相似度匹配，最后对命中的答案执行业务校验。校验至少应关注实体、时间、金额、地区、用户身份以及工具结果是否一致。语义阈值只能衡量表达接近程度，不能证明两个请求在安全和业务上等价。
哪些内容不应进入共享缓存
实时价格、库存、账户余额、订单状态、风控判断和强个性化推荐通常不适合直接缓存最终答案。身份证件、账户信息、密钥、令牌、密码、未脱敏客户对话和内部文档，也不应无条件写入共享缓存。确需缓存时，应进行脱敏、字段裁剪，并明确租户、用户和权限边界。
缓存写入同样需要控制。外部输入、低可信文档或未经审核的工具结果如果被直接写入高复用缓存，可能造成缓存投毒，使错误答案跨请求扩散。可信来源分级、答案校验和异常命中监控，应成为写入策略的一部分。
失效、审计与回退
权限变化、租户隔离规则变化、知识库更新和模型版本切换，都可能使历史结果失效。缓存应按模型版本、系统提示词版本和知识库版本隔离，并支持主动清理，而不只是依赖固定有效期。删除操作还要覆盖向量索引、备份和日志等副本。
上线前应在低风险场景采用小流量对照验证，分别观察有效命中率、错误率、回源率和权限校验结果。所有查询、命中、写入、删除及管理员访问都应保留审计记录，并提供一键停用和自动回源机制。语义缓存只有在“先隔离、再匹配、后校验”的链路下，才可能兼顾复用收益与跨租户安全。