为什么 Gemini 1.5（以及其他大型上下文模型）反而利好 RAG 技术？

Gemini 1.5 拥有 100 万个 token 的上下文窗口，引发了 AI 社区的热议，一些人预测 RAG 可能会因此受到影响。我认为，Gemini 1.5 对 RAG 来说是一个重要的积极发展，因为它突显了 RAG 的核心优势——以非黑盒方式优化成本、准确性和延迟，而依赖于 Gemini 1.5 并不能体现这些优势。我还指出了 Gemini 性能上的明显局限性，这些局限性在 Google 的技术论文 中有所说明。

Gemini 1.5的明显缺点是成本高和延迟，这些因素在实践中成为企业级RAG系统的障碍。

大多数反对这种观点的论点会认为，从长远来看，LLM模型的最终目标是将成本和延迟降低到几乎可以忽略不计的程度，这一点我认同。然而，对于今天使用LLM进行信息检索的企业来说，使用Gemini 1.5采取暴力全上下文窗口的方法来将应用投入生产不太可能成为途径。

在某些强调精确性的语境中，使用“精确性”可能更为自然。

尽管 Gemini 1.5 能够很好地处理 1M 上下文窗口这一消息引起了人们的注意，但谷歌自己的论文显示，如此多的 token 在上下文中确实存在量化上的挑战。下面是一些“大海捞针”测试的示例，要求模型从一大段文字中找出几个特定的句子。召回率是指模型成功找到这些特定句子的比例。

Chris Bartholomew of Vectorize.IO 这样说道：“从图中可以看出，尽管 Gemini 1.5 在重叠的上下文窗口范围内比 GPT-4 Turbo 更好，并且 Gemini 能够在其上下文窗口达到 1M 时保持其记忆能力，但平均记忆能力徘徊在 60% 左右。虽然上下文窗口中可能充满了许多相关事实，但有 40% 或更多的信息对模型来说是“丢失”的。如果你想确保模型真正用上了你给它的上下文，最好先筛选一下，只发最相关的信息。换句话说，就是传统的 RAG 方法。”

在实际生产环境中，40%的失败率使得系统并不可靠，尤其是在需要确保答案准确时。Gemini 1.5 在单针（即识别单一句子）和多针（即识别多个句子）之间存在明显的成功率差异。这表明，现实世界中的问题往往比“找到这个句子”更复杂，在较大的上下文窗口中进行检索时会遇到困难，即使是使用 Gemini 也是如此。

给大语言模型提供过多无关信息客观上总是不好的，而且我们离大语言模型能够确保处理所有信息的程度还很远。这些基准在各种实际应用场景中的通用性也不清楚。

我对谷歌和Gemini最终会在基础模型领域成为顶级竞争者之一持乐观态度。然而，Gemini 1.5的技术论文在针在稻草堆中测试中奇怪地只与GPT-4进行了比较。

对于其他像文本、视觉、音频等这样的基准测试，这值得注意，双子没有将其与GPT-4相比，而是与较早版本的双子相比。这让人怀疑，这些相比GPT-4的测试结果可能没有公布，因为这些结果可能不太好看。

死去的也许永不消逝——双子无法杀死RAG，复杂的RAG仍然需要更好的系统才能投入生产：较长的上下文窗口，如Gemini 1.5中的窗口，可以为RAG系统提高精度的余地，即使检索不够精准，也能进行有意义的处理。这使得RAG的生产变得更加容易，解决了当前基础设施不足的问题，加快了开发进度，最终提升了RAG的应用。这很重要，因为实际上还没有真正的生产RAG。我们需要更多的Gemini这样的基础设施来支持生产RAG。

优化至最终状态：让我们想象一个出现了真正可靠的大上下文窗口模型的世界。在这个世界里，所有公司都采用了这个模型。这些模型将如何竞争呢？它们会希望降低成本并减少延迟。我们最常听到的开发者的要求是“以GPT-3.5的成本达到GPT-4的性能”。模型成本是开发者在实际应用中努力降低的真实障碍。

他们怎么降低成本并减少延迟呢？他们会通过尽可能减少发送到上下文窗口的信息量来实现这一点。这也就是RAG。RAG本质上是一个信息优化手段，旨在减少发送给模型的无关信息量。即使是今天最强大的模型，如果提供更相关的信息，其准确性也会得到提高。RAG很可能成为一种持久机制，尤其是在企业级系统和复杂RAG系统中。

故障排查赋能，而非黑盒：用单一模型替换工作流系统，会减少调整系统的灵活性。如果LLM输出不符合你期望的结果，你将会有更少的方式来调整系统。

开发人员在使用大型语言模型（LLM）支持的软件时，经常提到的一个观点是减少LLM在一个工作流程中的接触点。相反，他们更喜欢将LLM的工作流程分解成可以单独审计和调试的任务。这样做可以让开发人员更清楚地理解特定的推理或LLM工作流程在具体步骤上失败的原因，并且仅在这些具体点上进行修复尝试。

在将所有信息都放入上下文窗口并给出输出的单体模型中，除了通过“黑盒”提示之外，没有其他方法来排查系统问题。这种方法相当于反复尝试把东西扔到墙上，看看什么能粘住，这并不是构建企业级产品的可靠方法。

一个非单一系统，如RAG，为开发人员提供了工具，以便及时理解这些错误，并调整给LLM的反馈信息。

• RAG已死，长生RAG – Vectorize.io
• 推特用户ptsi的推文
• Hacker News上的讨论

WhyHow.AI 正在构建工具，帮助开发人员利用图结构为他们的 RAG 流程增加更多的确定性和控制。如果您正在考虑、进行或将知识图纳入 RAG 流程中，我们很乐意在 team@whyhow.ai 与您交流，或者在 WhyHow.AI 订阅我们的新闻通讯。加入我们在 新创建的 Discord 上关于 RAG 中规则、确定性和知识图的讨论。