问题背景：设备问答的成本压力
我们做的是 IoT 设备运维平台，接入了大概 12 万台在线设备，每天设备侧和运维侧发起的自然语言问答请求在 40 万次左右。这些请求大部分走大模型链路：用户问“这台网关最近为什么频繁掉线”“空压机排气温度 95 度正常吗”，后端把设备时序数据、告警记录、知识库文档拼成上下文，再调模型生成回答。单次请求平均输入 2800 token、输出 350 token，按我们用的模型单价折算，一次问答的模型成本大约 0.012 元，一天就是 4800 元，一个月接近 14 万。这还没算上向量检索和上下文拼装的 CPU 开销。
真正让人难受的不是总成本，而是重复率。我们把线上 30 天的问答日志拉出来做了聚类，发现语义上高度相似的提问占比 61%。典型场景是同一型号设备的同类告警，几百台设备会问出几乎一样的问题，只是设备 ID 和时间戳不同；还有运维人员交接班时会反复问同一批设备的健康状态。这些请求每次都完整走一遍检索加推理，钱花得非常冤枉。于是我们开始评估语义缓存：把历史问答的语义向量存下来，新请求先做相似度匹配，命中就直接返回，不调模型。
方案选型：三种缓存路径的取舍
最朴素的做法是精确匹配缓存，key 用问题原文的哈希。上线两天命中率只有 8%，因为用户措辞差异太大，“掉线”和“离线”、“频繁断连”在字符串层面完全不同。这条路直接放弃，它只适合固定话术的 FAQ。
第二条路是语义缓存，用 embedding 模型把问题向量化，在向量库里做 ANN 检索，相似度超过阈值就复用答案。我们对比了两种实现：一是自建 Redis + FAISS，问题向量维度 768，用 float32 存储，12 万条历史问答占 350MB 左右，检索 P99 在 15ms；二是用托管向量检索服务，省运维但单次查询费用约 0.0004 元，按每天 40 万次算，一个月多出 4800 元检索费，且跨网络调用带来额外 20ms 延迟。考虑到我们已经有 Redis 集群和成熟的运维体系，最终选自建方案，用 Redis Stack 的向量检索能力，不引入新组件。
第三个取舍点是阈值。阈值定 0.92 时命中率 47%，但抽样 200 条命中结果人工核验，错误率 6.5%，主要是把“A 型号网关掉线”错配到“B 型号网关掉线”，设备型号不同答案不能通用。阈值提到 0.96 后命中率降到 38%，错误率降到 1.2%。我们最终取 0.95，并且在向量检索前加了一层硬过滤：把设备型号、告警类型作为 tag 写进 Redis 的过滤条件，先缩小候选集再做相似度匹配。这一步把错误率压到 0.8% 以下，命中率回升到 43%。另外我们设定缓存 TTL 为 6 小时，设备状态类问答时效性强，超过 6 小时的答案即使语义匹配也不复用。
落地步骤：从旁路到主链路的灰度
第一步是埋点，不动主链路。在所有问答请求的出口加一个异步旁路，把问题文本、设备型号、告警类型、最终答案、模型耗时都写进 Kafka，消费端做向量化后写入 Redis。跑了 5 天，积累了 9 万条样本，用来离线评估命中率和错误率，确认阈值和过滤字段的设计。
第二步是影子模式。在主链路前面挂一个缓存查询，命中了也只记录不返回，同时照常调模型，对比缓存答案和模型答案的差异。这一步跑了 7 天，每天抽 500 条命中样本做人工核验，把错误案例归类后反哺过滤字段，比如补充了“固件版本”这个 tag，因为同型号不同固件版本的故障原因差异很大。
第三步是灰度放量。按设备维度切 5% 流量走缓存优先，命中直接返回，未命中走原链路并回填缓存。观察核心指标：缓存命中率、答案错误率、P99 延迟、模型调用量。灰度 3 天后扩到 30%，再 3 天扩到 100%。回填策略上我们做了个小优化：只回填模型回答置信度较高的结果，具体做法是模型输出里带一个自评字段，低于阈值的答案不进缓存，避免把错误答案扩散出去。
效果与成本：算清楚的这笔账
全量上线稳定运行一个月后，数据如下。缓存命中率稳定在 42%，也就是每天 40 万次请求里有 16.8 万次不再调模型。模型调用量从日均 40 万次降到 23.2 万次，降幅 42%，对应模型成本从每月 14 万降到 8.1 万，成本下降 42%，每月省下约 5.9 万。加上向量检索和 Redis 的资源开销（每月约 2000 元），净节省仍在 5.7 万左右。
延迟方面的收益比预期更明显。原链路 P99 是 2.8 秒，其中模型推理占大头；缓存命中请求的 P99 是 38ms，整体链路 P99 降到 1.9 秒。对于运维人员在高频排查故障时连续追问的场景，体感差异非常大。并发能力上，模型侧并发压力从峰值 120 QPS 降到 70 QPS，峰值并发下降 42%，我们顺势把模型侧的限流阈值下调，腾出的配额分给了新上的日志分析问答场景，没有额外扩容。
需要说清楚的是代价。一是答案新鲜度，TTL 6 小时意味着设备状态类问题最多有 6 小时的滞后，我们在答案里加了“该回答基于 X 小时前的数据”的提示，涉及实时指标的提问通过意图识别直接绕过缓存。二是维护成本，过滤 tag 的 schema 需要跟着设备模型演进，每次新增设备类型都要评估是否补充过滤字段，这块每月大概占用 2 人天。三是错误答案的排查链路变长了，我们给每条缓存命中都打了 trace 标记，出问题能快速定位是缓存错配还是模型本身的问题。
结论是这笔账划算，但前提是重复率足够高、且业务能接受一定的新鲜度折损。如果问答内容高度个性化、每次上下文都不同，语义缓存的命中率会很难看，不建议上。
