缓存增强生成（CAG）对比检索增强生成（RAG）：谁才是大语言模型的最优解？

缓存增强生成（CAG）对比检索增强生成（RAG）：谁才是大语言模型的最优解？

1. 前期准备：RAG与KV-Cache（CAG）

RAG

是什么

RAG是一种检索增强生成方法，它利用检索器查找相关文档，然后将这些文档传递给大语言模型，以生成最终答案。

优势

• 处理大型或频繁更新的数据集时，无需一次性加载全部内容。
• 避免了大量提示信息导致的截断或上下文过载问题。

关键局限

• 增加了检索步骤，可能会导致速度变慢。
• 通常依赖外部API或索引，存在额外开销。

KV-Cache（CAG）

是什么

这种方法旨在将所有文档直接加载到模型的上下文窗口中，实现近乎零检索时间，从原理上来说，它完全省去了检索器。

注意：在我们的基准测试中，由于模型太大无法在本地运行，所以使用了 “无缓存” 版本的KV-Cache。我们通过OpenRouter这个API，每次都输入所有文档，来模拟相同的行为。这里我们不比较检索速度，因为如果在合适的本地环境中运行，KV-Cache显然在这方面更具优势。

优势

• 如果整个知识库能轻松适配模型的上下文，几乎可以立即获得答案（无需检索步骤）。
• 非常适合极少变动的稳定数据集。

关键局限

• 上下文大小：如果超出模型的容量，就必须进行截断或压缩处理，这会降低准确性。
• 本地要求：真正的缓存需要对内存进行控制，这意味着必须在自己的基础设施上运行模型。
• 频繁更新：对于动态数据而言，每次重新加载上下文中的全部知识并不现实。

2. 一个重大问题

长上下文的大语言模型（如谷歌的Gemini或Claude，拥有数十万的令牌容量）正在兴起，这使得CAG在某些应用场景中更具吸引力。但有一个重要前提：必须在本地运行模型，并能够访问其内存以启用缓存。然而，许多强大的大语言模型都是托管式的，有上下文长度限制，而且显然无法通过API在用户层面访问内存进行操作。

一旦数据集超过一定阈值，就可能超出上下文窗口。如果出现这种情况，该方法可能会完全失效，或者迫使你截断关键信息，导致准确性大幅下降。下面这条错误日志就很能说明问题：

{
    "error":{
        "message":"This endpoint’s maximum context length is 131072 tokens. However, you requested about 719291 tokens…"
    }
}

也就是说：除非对数据进行压缩或分块处理，否则就只能自认倒霉，而这样做又会极大地降低性能。

3. 我们的基准测试设置

我们使用了HotpotQA数据集（以多跳问答任务而闻名），并在meta-llama/llama-3.1-8b-instruct模型上进行测试。针对两种不同规模的知识库（分别包含50个文档和500个文档），各提出50个问题，以此观察每种方法在不同规模下的表现。

由于在测试KV-Cache时使用了OpenRouter这个API，所以实际上并没有真正的 “缓存” 或本地内存优化；每次请求时，只是简单地传入所有文档。

RAG的检索参数top_k设置为5，而KV-Cache没有设置top_k（因为它会加载全部内容）。

不进行检索时间的比较：我们主要关注语义准确性，因为如果KV-Cache在本地真正实现缓存，检索开销显然为零。

4. 测试结果

对HotpotQA数据集的基准测试，让我们对RAG和KV-Cache（CAG）在不同知识库规模下的性能有了有趣的发现。

主要结论

• KV-Cache在规模扩展上存在困难：随着数据集的增大，KV-Cache会面临上下文大小的限制，需要对提示进行截断或压缩。
• RAG能更好地处理复杂情况：RAG的检索机制确保只使用相关文档，避免上下文过载，从而保持较高的准确性。

总结

虽然KV-Cache在处理小型、稳定的数据集时表现出色，但RAG在处理大型、动态的知识库时更具稳健性，更适合现实世界中的企业级任务。

5. KV-Cache（CAG）：优缺点

在早期或小规模测试（例如约50个文档）中，CAG可能看起来无可匹敌。但当扩展到500个以上文档时，一些关键问题就会暴露出来：

上下文溢出

当超出模型的最大上下文窗口时，提示信息可能会被截断，甚至出现令牌限制错误。关键信息被删除，准确性也会受到影响。

本地硬件要求

为了真正发挥KV-Cache的优势，需要直接访问模型的内存。如果依赖托管式或API驱动的模型，就无法自行管理缓存。

频繁更新问题

每次数据发生变化，都必须重新构建整个缓存。这种额外的开销可能会削弱KV-Cache所宣称的 “即时” 优势。

6. 测试时间：分数背后的较量 —— 为什么 “Rosie Mac” 是赢家

并非所有分数都能反映全部情况。在评估模型的回答时，相似性指标会将生成的答案与参考文本进行比较。但如果一个答案比参考文本更详细，会怎样呢？它会得到奖励还是惩罚？让我们来看一个基准测试中的真实例子。

问题

《权力的游戏》中扮演丹妮莉丝·坦格利安的艾米莉亚·克拉克的替身是谁？

两个正确答案

• 答案A：“Rosie Mac是艾米莉亚·克拉克在《权力的游戏》中饰演丹妮莉丝·坦格利安时的替身。”
• 答案B：“Rosie Mac。”

你认为哪个答案在相似性指标上得分更高呢？大多数人可能会认为更详细的答案A会获胜。但实际得分如下：

• 答案A：0.60526
• 答案B：0.98361

没错，更简短的 “Rosie Mac.” 得分更高。为什么呢？因为标准答案就是 “Rosie Mac”，所以更详细的回答引入了额外的词汇，降低了匹配得分。

这并不意味着更长的答案就更差，通常情况下，它们能提供更好的上下文。但这也凸显了在解释相似性指标时要谨慎，尤其是在处理复杂或多跳推理任务时。我们的整体测试结果仍然有效，但重要的是不能只看原始分数，而要全面、客观地了解这些模型的真实表现。

7. 最终思考：天下没有免费的午餐

确实，如果整个知识库和上下文能够轻松适配本地的大语言模型，缓存增强生成（CAG）可以真正实现零检索开销。但对于许多企业级或多跳任务来说，这是一个很大的 “如果”。

如果数据量很大或更新频繁，像CustomGPT.ai这样基于RAG的方法可能仍然是更稳健、更灵活的选择。

本文由mdnice多平台发布