直说结论:如果你的 Agent 线上有大量重复或相似的问题,不加缓存就是在烧钱。我有个客服 Agent,上线第一个月账单出来我差点没绷住,一看日志,30% 的问题都是"营业时间""怎么退款""客服电话"这种翻来覆去的。次次喂模型,纯纯浪费。后来加了两层缓存,token 消耗砍了快一半。这篇讲讲怎么加、坑在哪。

缓存什么、怎么命中

我分了三层,从易到难:

第一层:完全相同的问题,精确缓存。 "客服电话多少"这种标准问法,问题文本一模一样的,直接缓存答案,连模型都不调。命中就秒回。实现就是拿规范化后的问题文本当 key。

第二层:语义相近的问题,向量缓存。 "客服电话""你们电话多少""怎么联系客服"意思一样但文本不同,精确缓存抓不住。我把历史高频问题做成向量,新问题进来先算相似度,超过阈值就复用已有答案。阈值这块要调,我设太低会误命中(把不同问题答串了),设太高又基本不命中,来回试了几轮卡在 0.9 左右才合适。

第三层:工具调用结果缓存。 有些工具结果短时间内不变,比如查今天的菜单、查门店列表。同样的工具+同样的参数,我缓存几分钟,别每次都真去调接口。

必须注意的坑

  1. 个性化/实时的内容别缓存。 "我的订单到哪了"这种带用户身份、带实时状态的,缓存了就出大事——A 看到 B 的订单。我用一个白名单只缓存通用问题。

  2. 缓存要能失效。 营业时间改了、政策变了,旧缓存还在答老答案。我给缓存设了过期时间,关键信息变更时手动清。

  3. 语义缓存的误命中最难查。 上面说的阈值问题,有阵子用户反馈"答非所问",排查半天发现是两个相近问题被向量缓存串了,把阈值提上去 + 加了人工抽检才稳住。

落地

我搭这套用的是个能拖拽配流程、节点里能挂判断和缓存逻辑的智能体平台,精确缓存和工具结果缓存在流程里加个判断节点就行;向量这块我接了它的知识库做相似度匹配。要吐槽的是,它内置的缓存粒度对我来说偏粗,精细控制过期我还是自己在外面接了层 Redis 兜着。

模型那层走讯飞 MaaS,API 调用按量计费,所以缓存省下来的就是真金白银,体感很直接。

你们的 Agent 缓存命中率做到多少了?用啥策略?评论区交流下,我这阈值还想再优化。

Logo

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念,把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起,为开发者提供从开发、训练到部署的一站式体验。

更多推荐