缓存键设计：语义相似度 vs 全文哈希

当为 LLM 网关设计缓存层时，第一个工程决策是缓存键的生成方式。常见两种方案： 1. 全文哈希：对原始 query 做 MD5/SHA 等哈希，简单但无法识别语义相似的查询 2. Embedding 相似度：用 DeepSeek-V4 生成 1024 维向量，通过余弦相似度判断命中（需设定阈值如 0.85）

实测发现，在客服场景下采用 embedding 方案可使缓存命中率提升 40%，但引入两个关键问题： - 需要持续监控 embedding 漂移（建议每周用 STS-B 基准测试） - 高相似查询可能返回用户特定数据（如订单号），需在缓存前过滤 PII 字段

实现细节补充

对于 embedding 方案，推荐使用以下参数配置： - 向量维度：1024（与 DeepSeek-V4 原生输出对齐） - 相似度阈值：0.82-0.88 区间需根据业务调试 - 距离计算：优先余弦相似度而非欧式距离 - 分片策略：按 query_type 分片可提升 30% 查询性能

TTL 动态调整策略

固定 TTL 会遭遇以下典型故障： - 模型升级后（如 DeepSeek-V3→V4）未及时清空缓存，导致旧答案污染 - 个性化查询（如"我的工单状态"）被错误缓存

推荐采用分层 TTL 设计：

# 基于查询类型的 TTL 决策
def get_ttl(query):
    if contains_personal_data(query):  # 使用正则+NER 检测
        return 0  # 不缓存
    elif is_factual_query(query):     # 事实型问题如产品规格
        return 86400  # 24小时
    else:                             # 通用建议类问题
        return 3600   # 1小时

动态调整进阶方案

可引入以下增强逻辑： 1. 版本感知：自动在模型发布新版本时清空相关缓存 2. 热度加权：高频查询自动延长 TTL（上限不超过 7 天） 3. 错误反馈：当用户点击"结果不满意"时主动淘汰该缓存

审计红线检查清单

必须禁止缓存的情况包括（需在网关层前置过滤）： 1. 含身份标识符（用户ID/手机号/邮箱） 2. 涉及敏感领域（医疗建议/法律意见） 3. 模型版本变更后 12 小时内的查询 4. 流式响应未完整接收的请求

实施检查项

建议在代码审查时验证： - [ ] 正则表达式覆盖常见 PII 模式（身份证/银行卡号等） - [ ] 敏感领域关键词列表每月更新 - [ ] 缓存清除API有认证和速率限制 - [ ] 所有缓存操作记录完整审计日志

命中率监控与告警

有效的观测指标应包含： - 语义命中率：相似度 >0.85 且未触发红线的请求占比 - 误缓存率：事后发现应禁缓存但实际缓存的查询比例 - 节省 token 成本：按实际调用量 × 平均 token 数 × 单价计算

监控系统集成示例

# Prometheus 指标示例
llm_cache_hits_total{type="semantic"} 1423
llm_cache_miss_reasons{reason="pii_filtered"} 56
llm_token_savings_usd 283.71

边界与取舍

以下场景不建议启用缓存： - 实时数据依赖强的场景（股票报价/运维告警） - 对话状态复杂的多轮会话 - 小规模部署（QPS < 10 时缓存维护成本可能高于收益）

混合方案建议

对于边缘场景可考虑： 1. 部分缓存：仅缓存回答中的通用段落（如产品介绍） 2. 分级存储： - 内存缓存：高频通用查询（5分钟TTL） - Redis：事实型查询（24小时TTL） - 不持久化：含用户上下文的数据 3. 语义分片：对领域专有名词建立独立缓存池

实施路线图

推荐分三个阶段推进： 1. 基线阶段（1-2周） - 实现基础哈希缓存 - 建立PII过滤机制 - 监控基础命中率

1. 优化阶段（3-4周）
2. 引入embedding相似度
3. 实现动态TTL

4. 建立误缓存检测

5. 高级阶段（5-6周）

6. 模型版本感知
7. 成本效益面板
8. 自动化缓存策略调优

关键风险控制

需特别注意： - 数据残留：确保缓存存储支持自动过期 - 雪崩效应：批量清除时采用渐进式淘汰 - 合规审查：定期抽样检查缓存内容 - 性能反模式：避免多层缓存导致延迟增加

最终建议每月执行一次缓存策略健康度检查，包含命中率分析、误缓存审计和成本收益评估三个维度。