近年来，大语言模型在知识密集型任务中的表现令人瞩目。传统的检索增强生成（RAG）方法通过引入外部知识库提升回答质量，有效解决了信息孤岛与时效性两大难题。
然而，RAG并非完美无缺。检索延迟始终是难以回避的痛点，更令人困扰的是，检索到的文档可能并不相关。针对这些局限，康奈尔大学研究团队提出了一种全新思路——缓存增强生成（CAG）。
康奈尔提出新方法 CAG
随着大模型上下文窗口的持续扩展，康奈尔大学认为，或许可以跳过“实时检索”这一环节。他们的方案是：将相关资源——尤其是当知识库规模有限且可控时——全部预加载到模型的长上下文中，同时将运行时的参数一并缓存。
在推理阶段，模型直接利用这些预加载的参数来回答查询，检索环节被彻底省略。对比分析显示，CAG的优势十分突出：检索延迟完全消除，检索错误率降至最低，同时上下文相关性丝毫不减。多组基准测试结果表明，在处理长上下文场景时，CAG不仅不逊于传统RAG，甚至在某些方面表现更优。尤其对于知识库相对固定的应用场景，CAG提供了一种更简单、更高效的替代方案——以更低的复杂度，换来至少同等的效果。
简而言之，缓存增强生成（CAG）让拥有长上下文窗口的模型能够实现“开卷有益”——将所有已知信息提前内化，而非临时检索。
01 CAG 的优势
响应速度更快
出错风险更低
架构更简洁
02 CAG 的理论基础
每款大模型都有其上下文窗口，该窗口决定了模型能同时“消化”多少信息。CAG的思路非常直接：在查询进入之前，将所有必要信息一次性填入上下文窗口。这样一来，模型在回答问题时无需再动态抓取其他信息源。
这一思路的核心在于Key-Value（KV）缓存。
LLM 中的标准 KV 缓存
在Transformer模型中，每个输入token通过自注意力机制与其他token产生关联。在此过程中，每个token被拆分为两个角色：
Key： 相当于一个“检索标签”，决定该token如何与其他token建立联系。
Value： 是token携带的“实质内容”，在生成响应时被重点参考。
例如，在句子“I eat an apple.”中，“apple”的Key决定了它在句子中与其他单词的关联方式，而Value则承载了“apple”本身的含义。这种机制使模型能够计算每个token与其他所有token的交互方式。当需要频繁处理长文本或反复使用相同信息时，这种设计的优势尤为明显。
CAG 中的 KV 缓存：一种更聪明的用法
在CAG中，KV缓存被赋予了新的玩法。整个知识库被整体加载，作为KV缓存预置在模型中。知识库中所有文档的Key和Value都被提前计算并存储。
当用户提交查询时，模型直接调用这份现成的缓存来响应，无需从外部系统获取信息。这样做有两大好处：一是省去了对每个查询重复计算的过程，二是在不同查询之间维持了上下文一致性。由于缓存中的信息作为一个整体加载到模型上下文窗口中，答案的准确性自然得到提升。
这种做法的优势可概括为：
时间成本大幅降低
几乎不会检索到无关文档
速度与效率均得到保障
节省内存与处理资源
上下文处理更连贯
系统架构也更简单
这里有一个绕不开的现实问题：硬件。处理大型知识库时，GPU内存和RAM是关键。对知识库进行首次编码确实需要时间和计算资源，但一旦完成，后续便无需重复计算。
03 RAG 与 CAG 的同场竞技
RAG的思路是，模型独立动态地检索信息源，然后基于这些信息生成答案。这一流程的缺陷也很明显：延迟高、文档选择错误、系统复杂度高。
CAG则反其道而行之，将所有相关信息预加载到模型长上下文中，彻底告别实时检索。研究人员通过实验对比了两者的表现，结果清晰显示，提出的CAG方法与传统RAG系统之间存在显著差异。在知识库规模有限的前提下，CAG给出的答案更快、更准，全面胜出。
实验结果
04 CAG 适用于所有场景吗？
CAG有一个硬性约束：模型的上下文窗口大小。假设一个模型能处理128,000个tokens的上下文，那么知识库也必须控制在这个规模内。举例说明：
假设我们有100份文档，每份文档超过150页。按每页300-500个tokens计算，一份150页的文档大约有45,000-75,000个tokens。100份文档的总量达到450万至750万个tokens。
这样一个知识库已远远超出单个模型的上下文限制，会产生两个问题：
一次性缓存所有信息不现实，超出上下文窗口限制，内存直接告急。
KV缓存的大小将带来巨大的内存消耗，对GPU/CPU资源的要求会陡然上升。
那么，有哪些破解之道？
a. 分割与动态 CAG
可以将庞大的知识库拆分为更小的子组，例如每个子组包含10份文档，约45万至75万个tokens。然后根据用户查询的范围，只预加载相关的子组。这样既利用了CAG的优势，又绕开了内存瓶颈。
b. 混合方法（CAG + RAG）
将常用的核心知识库用CAG预缓存，用于处理高频查询；而对于不常用或边缘化的查询，则使用RAG进行实时检索。这种混合模型兼顾了速度与灵活性。
c. 预筛选或过滤
如果用户查询经常集中在文档的特定部分，可以设计一个预筛选机制，只加载相关片段。例如，在收到用户查询时，用一个快速分类器判断应该调用哪些文档或章节。
d. 更大的模型和资源
如果具备技术条件，可以直接选用支持更大上下文窗口的模型，或搭建专门的基础设施（如使用多个GPU进行并行上下文处理），同样能解决问题。
结论
实验结果表明，在知识库规模可控的情况下，CAG的表现优于RAG。而且，随着未来模型上下文窗口容量的不断扩展，CAG的应用场景只会越来越广阔。