在之前的文章里我们曾经介绍过CAG（Cache-Augmented Generation），当时虽然讨论很多，更是被奉为银弹，同时，也有很多人指出这种方式更多是实验室的产物，就连名字也是哗众取宠的风格《Don’t Do RAG: When Cache-Augmented Generation is All You Need for Knowledge Tasks》
RAG成为过去式？缓存增强生成（CAG）is All You Need？
CAG不是RAG的终结者
CAG的确解决了RAG的一些痛点：
- 没有实时检索延迟
- 避免了文档选择错误
- 系统架构更简洁
- 在某些测试中速度快数十倍
但CAG有个根本限制：需要把所有相关知识预加载到LLM的上下文窗口中。这决定了它更适用于文档集合可控的场景，比如企业内部的规章制度、产品手册等。实测发现单纯依赖缓存会导致三个致命伤：
1）缓存污染问题像慢性病
2）静态缓存难以应对动态知识
3）冷启动阶段反而增加延迟
对于海量且不断变化的知识库，RAG依然不可替代。
融合才是正解
最近，Aurimas分享了他的实践，把RAG的实时检索和CAG的缓存机制做成「动态混合层」获得了比较好的效果。
实施架构分两步走 ：
- 数据预处理
- CAG端：筛选变更频率低、查询频率高的数据源（比如企业规章制度），预计算成LLM的KV缓存。内存驻留，一劳永逸。
- RAG端：按需构建向量数据库，简单场景用传统数据库也行。
- 查询路径
- 动态组装包含用户query和系统指令的prompt
- 通过向量数据库检索外部上下文（或直接查实时数据）
- 最终prompt=原始prompt+缓存上下文+检索上下文
关键点：
- 区分冷热数据，只缓存真正需要的
- 控制上下文窗口使用，避免"大海捞针"问题
- 注意缓存数据的权限控制
- 定期更新缓存以免数据过期
这反映了什么
这个技术演进过程很典型。每当新技术出现，总有"颠覆论"和"融合论"两种声音。颠覆论制造话题，融合论解决问题。
实际上，CAG的出现恰好验证了一个朴素的工程原则：能用模型直接处理的就交给模型，需要外部数据的就去检索。两者结合，发挥各自优势。
OpenAI和Anthropic早就在API中提供了Prompt Caching功能，只是没有包装成"CAG"这个概念。技术本身并不新鲜，新鲜的是对使用场景的重新思考。
真正的进步往往不是非此即彼的替代，而是在合适的场景用合适的方法。CAG+RAG的组合，恰好诠释了这个道理。
关注公众号回复“进群”入群讨论。