语义缓存能省下模型调用，但先测出错答案

两位客户分别输入“怎么修改密码？”和“我忘了密码，怎么重置？”，你的 Agent 调了两次模型，得到的是同一个答案。

DeepLearning.AI 的短课程 Semantic Caching for AI Agents 教的就是怎样省掉第二次调用。不过对前线部署工程师（FDE）来说，最有价值的部分不在这里，而在于判断：省掉的这次调用什么时候会给客户一个错误答案。

设想一个常见场景：客户问能不能降低模型账单，能不能让 Agent 更快。缓存是最直接的答案。但如果不做测量，它也是最快失去终端用户信任的办法。

谁来讲，为什么要有选择地听？

根据课程页面，这是一门中级（Intermediate）短课程，时长 1 小时 24 分钟，与合作方 Redis 联合制作。目标学员是已经熟悉 Python、嵌入和基础大模型（LLM）应用的开发者与机器学习工程师，不需要缓存方面的基础。

两位讲师都来自 Redis：Tyler Hutcherson 负责 Applied AI Engineering 团队，Iliya Zhechev 是高级研究工程师。厂商讲自家工具本身没有问题，前提是你能把通用原理和产品推广区分开。

按含义复用答案，而不是按措辞

机制很简洁。查询先转成嵌入，再与已存储的查询计算余弦相似度。据 Redis 博客介绍，如果相似度超过阈值（通常在 0.85-0.95 之间），系统就直接返回存储的答案，不再调用 LLM。

这种做法的固定成本常被忽视。每次向量检索会增加 5-20ms；作为回报，一次命中能省下 1-5 秒。未命中时，用户仍要等完整的 LLM 时间，外加这笔开销。所以只有重复查询足够多，缓存才划算。

精确率比命中率更重要

课程的时间分配说明了重点所在。7 个视频中最长的三个是“Measuring Cache Effectiveness”（13 分钟）、“Enhancing Cache Effectiveness”（12 分钟）和“Fast AI Agent with Semantic Cache”（16 分钟）：先花 41 分钟讲测量和改进，之后才讲把缓存接入 Agent。

课程讲了三个指标：命中率、精确率和延迟。命中率告诉你省了多少；精确率告诉你这些命中里有多少返回了正确答案，其余的都是错的。

假设有 10,000 条客服查询，阈值设为 0.90，命中率 30%，也就是省下 3,000 次模型调用。如果其中 4% 是误命中，就有 120 个人收到了答非所问的回复。

现在把阈值提高到 0.95，命中率降到 20%，误命中降到 1%。节省的调用次数变成 2,000，比之前少了 1,000。换来的是错误答案从 120 个降到 20 个。

这个例子里的数字是假设的，但这种权衡真实存在，平衡点在哪里只有客户的日志能说明。Redis 建议从 0.90-0.95 的阈值起步，并跟踪误命中率。如果误命中率超过 3-5%，光调阈值已经不够，必须改架构。

因此，到客户现场的第一件事很具体：抽一批真实日志，把查询两两标注为“含义相同”或“含义不同”，按上面的方法测两个阈值，再根据精确率做选择。不要在演示时凭感觉定阈值。

数据变了，缓存也得跟着变

演示很少涉及数据变化的问题。对于价格、库存这类变化快的数据，Redis 建议设置 5-15 分钟的生存时间（TTL），或者在源数据变化时立即清除缓存。否则 Agent 会很有把握地报出一个已经失效的价格。

语义缓存也不能取代提示词缓存。提示词缓存针对大段、固定的上下文；语义缓存针对意图相同的重复查询。Redis 把两层结合称为“双重缓存”（double caching），如果客户既有很长的系统提示词，又有大量重复问题，值得考虑。

哪些可以跳过，按什么顺序学？

可以跳过的是那个醒目的数字。Redis 写道，使用语义缓存的团队通常能把 LLM 成本降低“50% 或更多”，具体取决于查询重复的频率。这是厂商自己给出的数字，不是独立测量结果。所以向客户承诺的应该是在他们日志上做一次测量，而不是一个百分比。

至于顺序，可以按顺序看完视频，但在做那个 10 分钟的可选项目之前，把讲测量和提升效果的两个视频再看一遍。然后读一下 Redis 比较提示词缓存与语义缓存的博客文章，把全貌补齐。

对职业发展来说，简历上写一句“搭建语义缓存，基于标注查询对上测得的精确率选定 0.92 阈值，误命中率控制在 3% 以下”，远比“熟悉 Redis”有分量。这句话里的数字必须是你自己测出来的。

这门课教你怎样让 Agent 更快。当客户问“我们能省多少？”，答案只能来自他们自己的日志。