CAG vs RAG：哪一个适合您？

在大语言模型（LLMs）发展初期，上下文窗口（即我们输入给模型的文本）很小，通常限制在4000个词元（或3000个单词），这使得加载所有相关上下文信息变得不可能。这种限制促使了检索增强生成（RAG）在2023年出现，它能够动态获取所需的上下文信息。随着大语言模型的发展，如今上下文窗口已大幅扩大，可达10万个甚至数百万个词元。于是，像缓存（即CAG）这样的新方法开始出现，为RAG提供了一种全新的替代方案。为什么它这么晚才出现呢？虽然CAG效率很高，但确实存在成本问题。在GPT-4刚推出时，使用这些大上下文模型的成本是如今模型的20倍，与当前的小型模型相比，成本更是高出数百倍。这些早期的挑战使得RAG在许多应用场景中占据主导地位。不过，我们接下来会了解到，模型效率的提升和成本的降低，是如何让CAG成为更可行的替代方案的。

那么，CAG究竟是什么呢？在使用语言模型时，速度和准确性之间通常需要权衡。RAG在准确性方面表现出色，但需要时间搜索和对比文档。而且数据量越大，这个问题就越明显。CAG的出现带来了新思路：“如果我们直接将所有知识预加载到模型的内存中会怎样？”就像在像Gemini这样的长上下文模型中，你可以在一次查询中发送数百万字的内容。但CAG让这一过程变得更有趣。

如今，我们到处都能听到大语言模型（LLMs）、提示词（prompts）和RAG的相关信息，而CAG也正变得同样重要，尤其是在对速度要求极高的应用场景中。最近，我和“一起学AI”Discord社区的开发者们交流时发现，几乎每个人都想在自己的应用中集成CAG。

让我们快速了解一下CAG的工作原理，以便更好地理解何时应该使用它。CAG使用一种称为键值（Key-Value，简称KV）缓存的技术。在普通的大语言模型中，处理文本时会创建这些键值对——可以把键看作标签，把值看作实际信息。然后，语言模型通过键和值来理解内容并生成回复。通常情况下，这些键值对是临时的，每次回复后就会消失。但CAG提出：“嘿，为什么不把这些保存下来并重复使用呢？”没错，CAG用于将所有信息保存到模型的缓存中。更确切地说，它将从文本到Transformer模型处理得到的中间结果保存下来，如果你每次查询都发送相同的长上下文信息，这确实能节省大量计算资源。虽然将所有文本处理成这两个键值对能节省时间，但为了用完整的数据集填充上下文窗口，我们也需要投入更多计算资源。

CAG越来越受欢迎，主要原因有三点：

速度快：无需再逐文档搜索。
可靠性更高：没有检索错误的风险，但每次查询可能会添加不相关信息，这往往会导致大语言模型难以从中找到有价值的信息。
操作简单：无需复杂的搜索和检索流程，只需要大语言模型及其预加载的缓存即可。

简而言之，与RAG每次都在数据库中搜索不同，CAG会将所有信息预加载到模型内存中。基于CAG的系统工作流程如下：预加载知识到KV缓存→用户提问→直接访问缓存知识→即时给出答案。

正如你所见，CAG完全省去了搜索步骤，这使得回复速度极快，而且由于无需依赖搜索算法来查找正确信息，回复也更加可靠。不过，它也存在一些明显的缺点：

受模型上下文窗口限制：目前大多数模型的上下文窗口约为12.8万个词元（约10万个单词）。这意味着你无法直接加载数百万行的庞大数据集，并获得即时、可靠的答案，实际情况并非如此简单。
成本较高：尽管CAG效率超高，但每次向大语言模型发送大量上下文信息（即使是简单查询），成本也比RAG高，因为RAG只发送必要信息。
信息过载问题：发送过多信息可能导致难以找到相关内容。CAG面临的一个重要挑战是“信息迷失”问题：即使有较大的上下文窗口，大语言模型在检索分散于输入内容多个部分的特定信息时，往往也会遇到困难，而RAG则能够精准定位所需信息。

说到数百万字的处理能力，谷歌在其Gemini API中提供了一项非常相似的功能——他们称之为“上下文缓存”。本质上，二者原理相同：你只需加载一次内容并缓存，后续请求可直接复用。这大大提高了效率，因为减少了词元的使用量。其实，CAG并不是一项新技术，它已经存在一段时间了！

如果你是技术爱好者，想要深入了解整个过程，下面的内容可能会对你有所帮助：构建基于CAG的系统，首先要预处理整个知识库。与RAG不同，CAG不是创建嵌入向量，而是生成并保存数据在模型内部的表示（即KV缓存）。在原始论文中，这一过程称为KV编码（KV-Encode），它将文本转换为模型能够即时访问的格式。

然后，当收到问题时，模型直接利用缓存的知识精准回答问题！而且，你可以在需要时高效地重置或更新这个缓存。

需要注意的是，在大多数情况下，这一功能由大语言模型提供商实现，除非你选择自行部署模型。作为用户，你只需将与使用缓存相关的变量设置为“true”，其余的由提供商处理。

就像我们在讨论RAG时提到的嵌入向量优化技术一样，CAG也有自己的优化方法。例如，你可能需要进行缓存管理、实施高效的截断策略，或者处理位置ID重排等问题。

为了让大家更直观地了解何时该考虑使用CAG，这里有一些简单的规则：

当知识库大小在模型上下文窗口范围内时；
当需要极快的回复速度时；
当信息变化不频繁时；
当应用场景能够接受更高的总体成本时；
当与RAG相比，使用CAG不会导致输出质量明显下降时。

如果你选择自行部署模型，在有足够GPU内存的情况下可以考虑使用CAG（要知道，KV缓存需要占用空间，填充上下文窗口的成本可不低！）。如果你通过API使用模型，那就不用担心这个问题，只需将缓存功能设置为“开启”，剩下的交给系统就好！

举个例子，如果你有一个聊天机器人，经常需要回答相同的常见问题，使用CAG能让机器人快速响应。或者，在快速回答特定报告或会议记录相关问题时，比如开发一个类似YouTube“与视频对话”的插件，CAG也非常适用。

如果你想通过一个简单的类比来做出决策，可以想象你即将参加一场考试，现在面临一个选择：你是希望在考试时能随时查阅整本教材来寻找答案，还是提前完美记住教材的第6章和第7章内容呢？这两种方法都可行，但适用场景不同！如果这场考试需要用到整本书的知识，RAG就是最佳选择；而如果考试内容仅涉及第7章，那么CAG则更为理想！

可能有人会问，能否将CAG和RAG结合，采用混合方法呢？答案是肯定的。你可以将最常访问的信息通过CAG进行即时访问，同时利用RAG获取较少使用的详细信息。这就好比既有对专业知识的完美记忆，又有一座大型图书馆供你查阅各种资料！

随着大语言模型在低成本管理大量上下文信息方面的能力不断提升，一个高效的上下文缓存功能很可能会成为大多数项目的默认配置，因为它实在是太高效了。不过，在知识库特别庞大或变化非常频繁的极端情况下，RAG可能仍然不可或缺。

本文由mdnice多平台发布

CAG vs RAG：哪一个适合您？