大模型后端缓存：缓存回答之前先缓存证据

一、AI 缓存不能简单按问题文本命中

大模型调用成本高、延迟高，做缓存很自然。但 AI 后端缓存不能像普通接口那样只按请求文本缓存回答。同一个问题在不同租户、不同知识库版本、不同权限和不同时间下，答案可能完全不同。缓存错了，比不缓存更危险。

更稳妥的思路是先缓存证据，再缓存回答。比如 RAG 场景中，可以缓存检索结果、文档片段、摘要中间结果和模型输出。每一层缓存都要带版本和权限边界。AI 缓存的核心不是命中率，而是正确性。

二、缓存层级：从检索到生成分层处理

flowchart TD
    A[用户问题] --> B[查询改写缓存]
    B --> C[检索结果缓存]
    C --> D[证据摘要缓存]
    D --> E[模型回答缓存]
    F[知识库版本] --> C
    G[权限上下文] --> C

检索结果缓存要包含知识库版本、租户、权限范围和查询向量版本。知识库更新后，旧检索结果可能失效；权限变化后，旧结果可能越权。缓存 key 设计不严谨，迟早会出数据问题。

回答缓存更要谨慎。适合缓存的是稳定 FAQ、公开文档问答、无个性化的摘要结果。不适合缓存的是账户数据、实时状态、权限敏感内容和高风险决策。缓存策略要按任务类型配置，不要一刀切。

三、缓存 Key：版本和权限必须进入

下面是一个简化的缓存 key 构造示例。重点是把影响答案的因素都纳入。

String cacheKey = String.join(":",
        "rag",
        tenantId,
        knowledgeBaseVersion,
        permissionScopeHash,
        embeddingModelVersion,
        DigestUtils.sha256Hex(normalizedQuestion)
);

这个 key 看起来长，但每个字段都有意义。少了知识库版本，文档更新后可能返回旧答案；少了权限范围，可能把 A 用户可见内容给 B 用户；少了 embedding 版本，检索结果可能不一致。

缓存值也要记录元信息，例如生成时间、模型版本、证据文档 ID 和过期时间。排查错误回答时，能知道当时用了哪些证据，而不是只看到一段自然语言。

四、失效策略：别迷信永久缓存

AI 缓存要有明确 TTL 和主动失效。知识库更新、权限变更、模板变更、模型版本变更，都可能触发失效。对于高频 FAQ，可以 TTL 长一点；对于实时数据，宁可不缓存回答，只缓存结构化中间结果。

还要防止缓存击穿。热门问题缓存失效时，可能大量请求同时打到模型。可以用互斥重建、请求合并或异步刷新。模型调用比数据库查询贵得多，击穿成本也更高。

最后，缓存命中率不是唯一指标。要同时看错误回答率、过期命中率、平均节省 token、延迟下降和用户反馈。命中率高但经常答错，说明缓存边界错了。

缓存还要考虑审计。高价值回答命中缓存时，也应记录命中的缓存版本和证据来源。否则用户质疑某个回答时，只能看到“来自缓存”，却不知道缓存当时基于哪些文档生成。AI 系统的可解释性，不能因为缓存而消失。

对实时性要求高的场景，可以采用 stale-while-revalidate。先返回短时间内可接受的旧答案，同时异步刷新证据和回答。这样能降低延迟，但必须明确哪些任务允许旧答案，哪些任务绝对不能用旧数据。

五、总结

大模型后端缓存要先考虑正确性，再考虑命中率。检索证据、摘要和回答应分层缓存，key 中必须包含租户、知识库版本、权限范围和模型版本。缓存回答之前，先确认缓存的是正确证据。