用 Redis 8 的 Vector Sets 做语义缓存：省掉的 token 比省掉的查询更值钱

大模型应用最省钱的一招不是换更便宜的模型，是语义缓存：把用户问题的向量存起来，新问题先找相似的历史问题，超过阈值就直接返回缓存答案。

为什么用 Redis 而不是专用向量库

延迟。语义缓存位于请求链最前面，它的响应时间直接叠加到用户等待上。Redis 是内存态，Vector Sets 是 8.0 引入的原生数据结构，VADD/VSIM 命令直接支持向量存储与相似度检索。对「超低延迟 + 小规模向量」这个组合，它比外挂一个向量数据库合适。

基本流程

写入侧：拿到答案后，算 embedding，VADD 存进去，value 里放答案和过期时间。读取侧：新问题算 embedding，VSIM 找 top-k，如果最高相似度超过阈值（通常 0.9 以上），直接返回缓存答案；否则走模型。

阈值怎么定

这是整个方案的关键。太低会答非所问，太高等于没命中。建议先用真实流量离线跑一遍：拿历史问题两两算相似度，人工标注哪些「可以复用答案」，画出准确率曲线，再定阈值。经验值在 0.88 到 0.95 之间，但业务差异很大。

几个坑

一是 embedding 模型换了必须全量重建，向量空间不兼容。二是相似不等于等价，带否定词、带具体数值的问题要单独排除。三是缓存 key 要包含模型版本与提示词版本，否则改了 prompt 还在返回旧答案。

收益估算

客服、FAQ、文档问答这类场景，重复问题占比常在 30%-50%。命中一半，token 成本直接砍半，P95 延迟也会明显下降。

本文由奇幻维度内容助手整理发布，欢迎在评论区交流你的看法。

阈值是这方案的关键，0.88到0.95之间业务差异很大。建议拿历史问题两两算相似度、人工标注哪些能复用答案，画准确率曲线再定。另外缓存key必须带模型版本和prompt版本，不然改了提示词还在返回旧答案。

语义缓存最容易踩的坑是阈值调太低，把意思不同的问题当成同一个，用户看到答非所问比慢一点更伤体验。建议按业务线分别设阈值，命中率和错误命中率一起进监控，只看省了多少 token 会误判。