语义缓存实测 — 双层判定、命中率真相与假阳的代价

日期: 2026-07-29 阶段: Phase 2 - AI-native 参考架构 标签: #semantic-cache #cost-control #false-positive

核心问题

Day 43 选了 LiteLLM 做 gateway，但留了个尾巴：LiteLLM 的缓存以 Redis 精确匹配为主，语义缓存是 Bifrost/Portkey 的差异化卖点（降本 60-85% 的口径就来自语义缓存）。今天回答三个问题，决定本项目要不要为语义缓存换 gateway 或外挂插件：

1. 语义缓存怎么工作？ 「精确 hash + 语义余弦」双层是怎么串的、为什么是这个顺序。
2. 降本 40-70% 是真的吗？怎么测？ 厂商 slide 上的「95% 命中率」是不是话术。
3. 代价是什么？ 一个反直觉的硬道理——语义缓存命中错误（假阳）比未命中更危险，尤其在金融/合规场景。

这对 AML Copilot 不是「省钱」的小优化，而是正确性红线问题：一个合规产品里，「缓存返回了一个看似相关、实则错误的答案，还带 200 OK 满分置信」是比「慢一点」严重得多的事故。

关键内容

A. 双层缓存判定：为什么是「先精确、后语义」

语义缓存的标准实现是两层串联（Bifrost 语义缓存插件 / tianpan.co 生产文，2026-04）：

请求进来
   │
   ▼
[L1 精确 hash 缓存]
   hash(完整 query 字符串) ──► 命中? ──是──► 立即返回（零额外成本）
   │ 否                              ▲ 抓 15-30% 流量（自动化管道+用户重试）
   ▼
[L2 语义缓存]
   embed(query) ──► 向量库查最近邻 ──► cosine ≥ 阈值? ──是──► 返回缓存响应
   │ 否                                                         ▲ 抓 5-45% 长尾近似
   ▼
[未命中] ──► 真调 LLM ──► 写回 L1+L2

判定算法（伪代码）：

def cache_lookup(query, threshold):
    h = sha256(normalize(query))           # L1：归一化后哈希
    if (hit := L1.get(h)) is not None:
        return hit, "exact"                # 零成本、零正确性风险
    emb = embed(query)                     # L2：一次 embedding 调用（远便宜于 LLM）
    cand, score = vector_store.nearest(emb)
    if score >= threshold:                 # 阈值是「整场游戏」
        return cand.response, f"semantic@{score:.3f}"
    return None, "miss"                    # 真调 LLM，然后写回两层

为什么这个顺序不能反：L1 精确匹配零额外成本（一次哈希查找），L2 需要一次 embedding API 调用——虽远便宜于完整 LLM 调用，但不是免费的（tianpan.co，2026）。先 L1 后 L2，等于「能白嫖就白嫖，白嫖不到才花 embedding 钱」。另一个硬约束：整条缓存查找路径必须 <50ms，否则 embedding+向量检索的开销会吃掉缓存本该省下的延迟收益。

为什么 L1 单独存在有意义：直觉以为「都上语义了，精确层是多余的」。实际上自动化管道（定时任务、批处理）和用户重试会制造大量字符级完全相同的请求，L1 单层就能抓 15-30% 流量（tianpan.co，2026），且零正确性风险——这是「便宜又安全」的一层，不能省。

B. 命中率与降本：厂商话术 vs 生产真相

「95% 命中率」是偷换概念。tianpan.co（2026-04）直接拆穿：厂商 slide 上的 95% 指的是**「找到命中时的匹配准确度」，不是「多久能找到一次命中」**。真实生产系统的命中率是 20-45%，按工作负载分布：

降本的算术很朴素：25% 命中率 × 月 LLM 花费 = 省下的钱（扣基础设施成本前）。tianpan.co 例子：月花 $5000、25% 命中，约省 $1000/月。所以**「降本 40-70%」只在 FAQ 类高命中负载成立**；对 agent-v2 这种以工具调用（5-15%）和 RAG（15-25%）为主的负载，现实降本更可能落在 15-30%——这是 Day 43 引用「60-85% 降本」时必须打的折扣。

反直觉洞察①（agent 工具调用恰恰是语义缓存最不受益的负载）：直觉觉得「agent 调用多、最该缓存」。真相相反——agent 的工具调用命中率只有 5-15%（全场最低），因为每次工具调用的参数（地址、金额、时间窗）几乎都不同，语义上「相似」但实质参数不同的请求绝不能命中同一缓存。本项目最该上语义缓存的是 typology 分类（50-70%，问法变、答案稳）和重复的科普类知识问答，而不是 research/portfolio 这类带实时参数的工具调用。给 agent 全局开语义缓存是用错地方。

C. 假阳的代价：金融场景里「错命中」是事故，不是省钱

阈值是「整场游戏」（tianpan.co，2026）。这是一个命中率 ↔ 假阳率的直接权衡：

数据来源：getmaxim / Portkey 阈值指南 + tianpan.co（2026）。「精确缓存零正确性风险；语义缓存按阈值有 1-15% 假阳」。

反直觉洞察②（语义缓存「错命中」比「未命中」危险得多，而且静默）：未命中只是慢一点、贵一点——可恢复。错命中（false hit）返回一个错误答案，还带满分置信和 200 OK（getmaxim，2026），系统看不出自己在悄悄退化。tianpan.co 记录的真实金融事故：用户说「I don't want this business account anymore」被以 88.7% 余弦相似度路由到了「自动取消付款流程」，而该请求本该触发「账户关闭审查」——一字之差、语义高度相似，但业务后果天差地别。在 AML/合规场景，语义缓存绝不能用于任何「触发动作」或「判定结论」的路径——它至多缓存「科普解释」这类无副作用的只读内容。

这条洞察直接定本项目的缓存策略：按内容副作用分路缓存，而不是全局一刀切阈值。

命中率/降本/假阳怎么实测——golden 流量回放 + 影子模式（综合方法，规范化 tianpan.co 未给的测量细节）：

1. 录制 golden 流量：从 Day 8 trace 导出真实历史请求集（去敏）
2. 影子模式（shadow）：缓存层只「判定+记录」不真返回，旁路跑
3. 三指标同时测：
   - 命中率 = 语义命中数 / 总请求数（按工作负载分桶）
   - 降本%  = (命中省下的 LLM token 成本) / 总成本
   - 假阳率 = 人工/judge 复核「命中的缓存答案 vs 真 LLM 答案」语义不等的比例
4. 阈值扫描：从 0.97 起步，逐步放松，画「命中率↑ vs 假阳率↑」曲线，
   选满足「假阳率 < 红线」的最大命中率点
5. 响应头回传 similarity score，让每次命中可审计（无需自建 eval harness）

注意第 3 步的假阳率测量复用 Day 17 的 judge ——judge 已校准（κ≥0.6），正好用来批量判「缓存答案和真答案是否语义等价」。缓存假阳率的度量，本质是又一个 LLM-as-judge 任务。

设计要点/决策表

对本项目的落地

• 不为语义缓存换 gateway：维持 Day 43 的 LiteLLM 选型，L1 精确缓存用 LiteLLM 自带 Redis 缓存即可（全局开，抓 15-30%）。L2 语义缓存仅对 typology 分类路径外挂一个小向量缓存（复用 src/agent/rag/embeddingClient.ts 的 embedding + vectorSearch.ts 的最近邻），不引入重型 Bifrost。
• 新建 src/agent/cache/semanticCache.ts（规划）：实现 A 节双层判定，lookup(query, {threshold, scope}) 返回 {hit, source: 'exact'|'semantic'|'miss', score}；scope 标注内容副作用（readonly-explain 才允许语义层，action/tool-call 强制只走 L1 或直穿）。这把 B/C 节「按副作用分路」编码进类型。
• 假阳率测量接 Day 17 judge：在 src/aml/judgeCalibration.ts 基础上加一个 cacheFalseHitRate(goldenReplay)，对语义命中样本用已校准 judge 判「缓存答案≈真答案」，输出假阳率，作为阈值扫描的红线指标（合规路径假阳红线设 <0.5%，对应 0.97 阈值）。
• 接 Day 8 trace 做 golden 回放：从 useTraceStore.ts 导出的历史请求做影子模式回放，按工作负载分桶统计命中率，验证「typology 高、工具调用低」的预期，回填决策表的真实数字。
• 诚实标注：语义缓存为 P2 规划；命中率/降本/假阳的具体数字须用本项目 golden 流量实测后回填，当前表内为行业区间（2026 口径）。阈值 0.97 为合规路径保守起点，按实测曲线调整。

参考资料

1. tianpan.co — Semantic Caching for LLM Applications: What the Benchmarks Don't Tell You（一手生产工程文）：双层（L1 hash 抓 15-30% / L2 语义）、先精确后语义的成本理由、<50ms 查找预算、「95% 命中率」是匹配准确度非命中频率、真实命中率 20-45% 分负载表、阈值 0.92 全局默认不适异构负载、0.85 financial 事故（88.7% 余弦错路由账户取消）(2026-04)
2. getmaxim — Semantic Caching for LLMs: Cut AI Costs and Latency：降本最高 86%、延迟最高 88%、30-40% 命中即有意义节省；错命中带 200 OK 满分置信、静默退化 (2026)
3. Portkey — Semantic Caching Thresholds and Why They Matter：阈值 0.95-1.0 严格/0.85-0.95 平衡/<0.85 探索；0.92 sweet spot；阈值定假阳 (2026)
4. Bifrost 语义缓存插件文档 + getmaxim Top Semantic Caching Solutions 2026：双层架构（exact hash + vector similarity）、先 hash 后 embed 的成本顺序 (2026)
5. 本仓库 src/agent/rag/embeddingClient.ts、src/agent/rag/vectorSearch.ts、src/aml/judgeCalibration.ts(Day 17)、src/agent/trace/useTraceStore.ts(Day 8)、src/aml/typology.ts (2026-06)

SOTA 检查 (2026-06-11)

• 双层（精确+语义）缓存是 2026 gateway 缓存的标准架构：Bifrost/Portkey/TrueFoundry 口径一致，先 L1 hash 后 L2 语义；本日 WebSearch 未见替代架构。
• 「95% 命中率」话术已被生产社区集体拆穿：tianpan.co / dev.to「95% Hit Rate Myth」多篇 2026 文指出真实命中率 20-45%、按负载分布大；「降本 40-70%」仅 FAQ 类高命中负载成立，agent 工具调用负载现实降本远低。引用 Day 43 的 60-85% 时必须按本项目负载打折。
• 假阳（错命中）是 2026 语义缓存的头号生产风险：金融场景已有真实事故（88.7% 余弦错路由），共识是「正确性敏感路径不上语义缓存，或用极高阈值 0.97+」。本项目合规定位决定语义层只用于只读科普内容。
• 过时认知警示：「语义缓存=纯收益、全局开」过时——错命中静默退化、按内容副作用分路是 2026 工程共识；缓存层必须可审计（响应头回传相似度分）。
• 待跟踪：用本项目 golden 流量实测 typology 路径真实命中率与假阳曲线；评估是否值得为更高命中率引入 Bifrost 内置语义缓存（vs 自外挂小向量缓存的维护成本）；arXiv 2603.03301「From Exact Hits to Close Enough」（2026）的近似度量方法可作进阶阅读。