大模型结果缓存：Java 服务别把语义缓存当普通 KV
一、AI 缓存不是简单 key-value
普通接口缓存通常按请求参数生成 key，相同参数命中缓存。大模型结果缓存更复杂，因为用户问题可能表达不同但语义相近，知识库版本也可能变化。把它当普通 KV 用，很容易返回过期或不适用答案。
语义缓存的价值是降低成本和延迟，但风险是把错误答案放大。缓存命中越高，不代表系统越好。关键要看命中结果是否仍然被当前证据支持。
二、缓存 key 要包含上下文版本
flowchart TD A[用户问题] --> B[语义向量] B --> C[相似缓存查询] C --> D{版本是否匹配} D -- 是 --> E[返回缓存] D -- 否 --> F[重新生成]AI 缓存至少要考虑问题语义、租户、权限范围、模型版本、提示词版本、知识库版本和工具结果版本。缺少任何关键维度，都可能命中错误结果。
权限尤其重要。两个用户问同一个问题，但可见文档不同，答案可能不同。缓存 key 中必须有权限范围摘要，或者缓存结果只在同一权限域内复用。
三、缓存结果要带证据
public record AiCacheEntry( String cacheId, String answer, List<String> citationIds, String modelVersion, String promptVersion, String knowledgeVersion, Instant expireAt ) {}缓存不应只保存 answer。引用证据、模型版本、提示词版本、知识库版本和过期时间都要保存。命中缓存后，仍然要检查引用是否可见、是否过期。
if (!entry.knowledgeVersion().equals(currentKnowledgeVersion)) { return CacheDecision.miss("knowledge version changed"); }这类显式 miss 原因很重要。它能帮助团队知道缓存命中率为什么下降，是知识库更新太频繁，还是权限范围太细。
四、过期策略要按风险分级
低风险 FAQ 可以缓存久一点，政策、价格、权限、配置类答案要短缓存甚至不缓存。不同业务场景要有不同 TTL。统一缓存一天，看起来简单，实际上很危险。
缓存命中后也可以做轻量校验。比如检查关键引用是否仍存在，检查文档更新时间是否晚于缓存时间。成本比重新生成低，但能挡住一部分过期答案。
语义相似阈值也要谨慎。阈值太低，很多不相干问题会命中；阈值太高，缓存效果又有限。可以按场景设置不同阈值。FAQ 类问题可以宽一些，合规、价格、权限类问题应更严格。
缓存结果还要区分“直接返回”和“作为上下文参考”。相似但不完全相同的问题，可以把缓存答案作为参考证据，让模型重新生成，而不是直接返回。这样既能节省部分成本，又能降低误用风险。
还要记录负样本。用户点踩、人工驳回、引用失效的缓存结果，应进入黑名单或降低权重。缓存系统如果只学习命中，不学习失败，会不断重复同类错误。
最后，缓存指标不能只看命中率。还要看命中后采纳率、投诉率、重新提问率和节省成本。命中率高但用户反复追问，说明缓存可能在制造假效率。
缓存分层也能提升效果。热门 FAQ 可以本地缓存加语义缓存双层结构：本地缓存放精确匹配的结果，语义缓存放相似问题的结果。本地缓存命中时延迟更低，语义缓存命中时节省模型调用。两层可以并设置不同 TTL，平衡新鲜度和成本。
五、总结
大模型结果缓存要把语义、权限、模型版本、提示词版本和知识库版本纳入判断，并保存引用证据和过期策略。
语义缓存不是普通 KV。省下 token 之前，要先确认缓存答案仍然适合当前用户和当前知识。建议在缓存命中时附带一个轻量级的权限重检和知识库版本比对，开销控制在 5ms 以内，确保缓存的便捷不牺牲安全性。
