Cag Vs.Rag: the Definitive Showdown for Llm Accuracy？

看视频！

如果您正在使用 ChatGPT 或其他 AI 模型，您可能注意到它们有时会提供不正确的信息或产生幻觉。检索增强生成（RAG）通过搜索外部文档来帮助解决这个问题，但这种新方法采取了完全不同的方法——这可能正是您所需要的！

大家早上好！我是 Louis-Francois，Towards AI 的联合创始人和首席技术官，今天我们将深入探讨一个非常令人兴奋的主题：缓存增强生成（CAG）。

在大型语言模型（LLMs）的早期阶段，上下文窗口（即我们发送给它们的文本）很小，通常限制在仅 4,000 个标记（或 3,000 个单词），使得无法加载所有相关上下文。这一限制催生了像 2023 年的检索增强生成（RAG）这样的方案，它动态获取所需的上下文。随着大型语言模型的发展，支持更大的上下文窗口——高达 100k 或甚至数百万个标记——新的方案如缓存或 CAG 开始出现，提供了 RAG 的真正替代方案。为什么花了这么长时间才开始呢？虽然 CAG 高效，但确实有成本。在 GPT-4 首次推出时，使用这些大型上下文模型的费用比今天的模型高出 20 倍，甚至在当前的迷你模型中高出数百倍。这些早期的挑战巩固了 RAG 在许多用例中的主导地位。然而，我们将看到最近在模型效率和成本方面的改进使得 CAG 成为一个更可行的替代方案。

那么，CAG 是什么？在使用语言模型时，通常在速度和准确性之间存在权衡。RAG 在准确性方面表现出色，但需要时间来搜索和比较文档。而且数据越多，情况就越糟。这就是 CAG 的介入，它说：“如果我们将所有知识直接预加载到模型的内存中呢？”就像在双子座等长上下文模型中，您可以在单个查询中发送数百万个单词。但 CAG 使这一切变得更加有趣。

我们到处听到大型语言模型、提示和 RAG，但 CAG 变得同样重要，特别是在速度至关重要的应用中。我最近与我们 Learn AI Together Discord 社区的开发人员进行了交谈，几乎每个人都希望在他们的应用中实现 CAG。

让我们快速澄清 CAG 的工作原理，以便更好地理解何时应使用它。CAG 使用一种称为键值（Key-Value，或 KV）缓存的东西。在常规的 LLM 中，当它们处理文本时，会创建这些 KV 对——将键视为标签，将值视为实际信息。语言模型随后使用键和值来理解内容并生成响应。通常，这些是临时的，在每次响应后消失。但 CAG 说：“嘿，为什么不保存这些并重用它们呢？”是的，CAG 用于将您所有的信息保存在模型的缓存中。更具体地说，它保存从文本到变换器模型所看到的中间结果的计算，如果您每次查询都发送相同的长上下文，这仍然节省了相当多的计算。虽然这在将所有文本处理成这两个 K 和 V 对时节省了时间，但我们通过填充上下文大小来带来更多的计算，使用我们拥有的整个数据集。

虽然 CAG 受欢迎的原因有很多，但主要是因为三件事：

1. 它很快——不再需要搜索文档。
2. 它更可靠——没有检索错误的风险，但存在向每个查询添加无关信息的风险，这通常会导致大型语言模型无法找到其中的有价值信息。
3. 它相当简单——您不需要复杂的搜索和检索管道——只需 LLM 及其预加载的缓存。

简单来说：与每次都搜索数据库（如 RAG 所做的）相比，CAG 将所有信息预加载到模型的内存中。所有信息。以下是基于 CAG 的系统中发生的事情：您将知识预加载到 KV 缓存中 -> 用户提问 -> 直接访问缓存知识 -> 立即回答。

如您所见，使用 CAG，我们完全消除了搜索步骤。这使得响应超级快速且更可靠，因为我们不依赖搜索算法来找到正确的信息。但也有一些重要的缺点。

1. 您受到模型上下文窗口的限制——目前大多数模型的上下文窗口约为 128,000 个标记（约 100,000 个单词）。这意味着您不能简单地直接加载数百万行的巨大数据集并获得即时、可靠的答案。事情并不是这样的。
2. 它非常高效，但代价更高，因为您每次仍在向 LLM 发送大量上下文，即使对于简单的查询，而 RAG 仅发送必要的部分。
3. 您可能会遇到发送过多信息而无法找到相关部分的问题。与 CAG 相关的一个重要挑战是“中间丢失”问题：即使在大型上下文窗口中，LLMs 也常常难以检索分布在输入多个部分的特定内容，而 RAG 则用于精确定位所需的信息。

说到数百万个单词，谷歌在他们的双子座 API 中有类似的东西——他们称之为“上下文缓存”。这基本上是相同的原理：您一次加载内容，缓存它，并在后续请求中重用它。这使得它更高效，因为您使用的标记更少。CAG 并不是那么新，它已经存在了一段时间！

如果您是更技术化的观众，并想了解整个过程，这里有一点小信息：要构建基于 CAG 的系统，您首先需要对整个知识库进行预处理。与 RAG 中创建嵌入不同，您正在生成并保存模型对数据的内部表示（KV 缓存）。这通过原始论文中的一个过程称为 KV-Encode 完成，该过程将您的文本转换为模型可以立即访问的格式。

然后，当问题出现时，模型直接使用这个缓存的知识精确回答问题！您还可以在需要时高效地重置或更新该缓存。

请注意，在大多数情况下，这由 LLM 提供商实施，除非您自己托管。作为用户，您只需将与使用缓存相关的变量设置为 true，他们将管理其余部分。

就像我们在关于嵌入的 RAG 讨论中一样，CAG 也有自己的优化技术。例如，您可能需要处理缓存管理，实现高效的截断策略，或处理位置 ID 重排。

为了更简单一点，这里有一些简单的规则，帮助您了解何时应考虑使用 CAG：

• 当您的知识库适合模型的上下文窗口时
• 当您需要极快的响应时
• 当您的信息不经常更改时
• 当整体成本增加对您的用例是可以接受的时
• 当您没有看到与 RAG 相比输出质量的相关下降时
• 如果您正在托管模型，请在您拥有足够的 GPU 内存时考虑 CAG（是的，那个 KV 缓存需要存放在某个地方，并且占用空间相当昂贵，填满上下文窗口！）。如果您是通过 API 使用模型，则可以忘记这一点；您只需将缓存功能设置为 True 并忘记它！

例如，当您有一个聊天机器人需要频繁回答相同的常见问题时，您可能希望使用 CAG，这样机器人总是知道如何响应。或者快速回答特定报告或会议录音的问题，例如创建一种 YouTube “与您的视频聊天” 类型的附加功能。

如果您想要一个简单的类比来帮助您做出下一个决策，想象一下您需要参加考试，并且需要做出选择。您想要在需要查找信息时访问整个教科书，还是提前完美记住教科书的第 6 章和第 7 章？这两种方法都有效，但在不同情况下表现出色！当您需要整本书来通过考试时，RAG 将是最佳选择，而如果考试仅涉及第 7 章，CAG 将是理想选择！

在一些