LLM API 网关缓存设计：为什么语义哈希不如业务规则分层有效

2600_96011480

1人浏览 · 2026-05-28 18:14:42

2600_96011480 · 2026-05-28 18:14:42 发布

在 LLM API 网关层引入响应缓存时，多数团队首先尝试对用户query做全文MD5或嵌入向量相似匹配，但实测中这两种方法会同时遭遇技术瓶颈与合规风险。以下是我们在金融工单场景用 DeepSeek-R1（基于DeepSeek-V4微调）部署时总结的工程实践。

语义缓存的三大失效场景

个性化应答污染
当用户问「我的信用卡额度多少」时，相同query对不同用户需返回不同结果。用传统哈希键会导致A用户的敏感数据泄露给B用户。即便引入用户ID作为缓存键组成部分，仍无法处理「帮我查最近一笔交易」这类时间敏感请求。我们通过抽样发现，仅添加用户ID维度会使缓存命中率从78%骤降至32%。
模型迭代的版本污染
DeepSeek-V3到V4的还款政策解释存在差异，若缓存未按模型版本隔离，旧版错误答案会持续返回。我们通过X-Model-Version请求头强制版本隔离，但因此牺牲了30%的缓存命中率。更严重的是，当采用蓝绿部署时，两个版本并存的15分钟窗口期内会出现缓存键冲突，必须引入版本号+时间戳的双重隔离机制。
小微编辑引发的缓存失效
用户将「怎么提前还款」改为「如何提前还款」时，两句话的语义嵌入余弦相似度达0.98，但业务要求必须重新执行风控计算。此时基于向量的缓存反而增加复杂度。实测显示，在客服场景中这类同义替换占比达17%，导致大量本可命中的请求穿透到LLM。

业务规则分层的实施要点

我们最终采用三层缓存策略（均需审计日志记录）：

层级	缓存键构成	适用场景	TTL	存储引擎
静态知识	问题MD5+模型版本	产品说明书条款	7天	Redis
业务规则	问题MD5+用户类型+业务日期	费率计算类	1小时	Memcached
完全动态	不缓存	含PII数据的查询	0	-

关键技术决策点： - 静态知识层使用Redis是为利用其持久化特性，避免服务重启导致高频问答缓存雪崩 - 业务规则层选择Memcached因其更低的内存开销和更快的过期机制 - 采用user_type而非具体user_id作为维度，既满足合规又保留部分复用性

关键实现代码（网关层Groovy脚本片段）：

// 判断是否可缓存
boolean isCacheable(Request req) {
  // 规则1：不含动态变量
  if(req.query.contains('我的') || req.query.contains('今天')) 
    return false
  // 规则2：非敏感端点
  return !req.path.contains('/account/') 
}

// 构建缓存键
String buildCacheKey(Request req) {
  def baseKey = DigestUtils.md5Hex(req.query)
  if(req.path.contains('/product/')) {
    return "static:${baseKey}:${req.headers['X-Model-Version']}"
  }
  return "biz:${baseKey}:${req.userType}:${LocalDate.now()}"
}