RAG 2.0，终于让 RAG 正确了！

纵观人工智能行业，我们已经习惯了每天都看到一些东西被“杀死”。当这个话题被反复提起，次数多到自己都觉得有点尴尬时，新的案例还是出现了。

这一次的主角是Contextual.ai，他们推出了一种叫做上下文语言模型的新东西，并将其命名为“RAG 2.0”。这个新版本的推出，让标准检索增强生成——目前实现生成式AI模型最主流的方法之一——直接显得过时了。

有意思的是，这个说法的提出者，正是RAG这个概念的最初创建者本人。

不过，尽管这比当下生产级AI的发展现状已经领先了一大截，整个领域里始终有一个核心疑问挥之不去：RAG是不是真的在走向末路？这些所谓的创新，会不会只是在做无用功？

以数据为基础

聊正题之前，先说个基础概念。你可能知道，也可能不太清楚：所有独立的大语言模型（比如ChatGPT这类明星产品）其实都有知识截止日期。

换句话说，预训练这件事本质上是一次性的练习（这里先不讨论持续学习的方法）。也就是说，LLM只“看到”过某个时间点之前的数据。

拿现在的情况举例：在写这篇文章的时候，ChatGPT的知识更新截止在2023年4月。所以，它没法回答这个时间点之后发生的事实和事件。

而这也正是RAG这个角色登场的关键价值所在。

本质上，就是语义相似性

顾名思义，RAG的核心思路是：从一个已知数据库里检索数据——这些数据LLM很可能从未见过——然后在运行时实时输入给模型，这样它就有了更新的、且语义相关的上下文，能够给出更准确的回答。

那么这个检索过程具体是怎么实现的？

整个架构的根基其实就一个原则：具备根据请求或提示的上下文，检索出语义上有意义的数据的能力。

这个过程主要涉及三个元素：

1. 嵌入模型

2. 检索器——通常是一个向量数据库

3. 生成器——也就是LLM本身

第一步，要让检索流程正常工作，数据必须先被转换为“嵌入形式”，也就是用一串数字向量来表示文本。

这里面还有一个关键原则：相似的概念会拥有相似的向量。

举个例子：对”狗”和”猫”这两个概念，我们很容易理解它们是相似的——都是动物、哺乳动物、四足动物、家养动物。转换成向量之后，”狗”可能是[3, -1, 2]，”猫”可能是[2.98, -1, 2.2]。你可以把每个数字理解成该概念的一个“属性”，数字越相近，意味着属性越相似。

有了嵌入数据之后，下一步是把它们放进向量数据库（也就是检索器），这是一个用来存储这些高维嵌入数据的数据库。根据前面提到的相似性原理，在这个高维空间里，越相似的事物自然会彼此靠近。

每次用户发送请求，比如“给我‘黄猫’类似的结果”，向量数据库就会执行一次“语义查询”。通俗点说，就是从数据库中提取出离用户查询距离最近的向量（距离越近越相似）。因为这些向量代表的是底层概念，相似的向量自然代表相似的概念——这个例子中，就是检索出其他猫。

一旦提取到相关内容，我们就需要构建一个LLM提示。这个提示里通常封装了三样东西：

• 用户的请求

• 从数据库提取出的内容

• 一组系统指令（用于控制模型的回答方式，比如让它“简洁回应”）

以上就是RAG的基本框架——在推理阶段，实时给用户查询提供相关内容，用来增强LLM的回应能力。这套系统之所以能跑通，首先要归功于LLM最强大的超能力之一：情境学习。它让模型即使面对从未见过的数据，也能做出准确预测，而不需要重新调整权重。

但说实话，这个过程听起来这么好，事情当然不会这么简单。

---

毫无缝线的缝织已成过去

要理解当前RAG系统的问题，可以直观地用一张图来表示：

虽然这条“补丁裤子”对某些人来说可能还凑合，但大多数人不会穿它——因为各个部件之间完全没有统一感。尽管起初这些补丁并不起眼，但拼凑的感觉还是很明显。

这个类比背后有个很现实的原因：标准RAG系统将三个独立组件组装在一起，而这三个组件都是单独预训练的，本质上它们并不是为了放在一起而设计的。

而在RAG 2.0里，情况完全不同——系统从一开始就被定义为一个整体，一个有机的“一件事”。

这里不允许出现弗兰肯斯坦

具体来说，RAG 2.0整个系统在连接的同时，会进行端到端的联合训练。就好比说，设计者从一开始就默认：LLM应该始终和一个向量数据库绑定在一起，以此保持信息的实时更新。

相比之下，在标准RAG中，预训练、微调、基于人类反馈的强化学习（RLHF）等环节，LLM和检索器（向量数据库）是分开进行的。而在RAG 2.0 里，所有标准LLM训练的必要组件，都是从头开始一起训练的——包括LLM和检索器。

用更专业的话说：在反向传播（也就是训练这些模型的算法）过程中，梯度不仅会贯穿整个LLM，还会同步传播给检索器。这样一来，整个系统就能作为一个整体，从训练数据中共同学习。

最终的结果也证明了这一点：即使RAG 2.0使用的独立模型几乎肯定比GPT-4弱，但采用新方法的系统，在所有可能的RAG 1.0组合（与其他检索系统拼在一起）中，性能依然超越了后者。

原因其实很简单。在RAG 1.0里，我们分开训练各个部件，再拼接在一起，只能祈祷最后结果不差。而在RAG 2.0中，所有组件从一开始就在一起运作。

用更专业的术语来说：把两个单独训练的系统拼在一起，结果往往是灾难性的——尤其是在学习到的数据表现形式根本不一致的情况下。这就好比一个英国人面对一个日文数据库：信息都在，但英国人完全看不懂。

尽管如此，即便RAG 2.0的优势摆在眼前，还是有一个更大的问题悬而未决。

---

真正的问题，至今没有答案

表面上看，RAG 2.0很可能很快会成为企业级应用的标准——因为它的设计恰好迎合了一批公司：那些不希望把自己机密的内部数据分享给LLM提供商的客户。但深究下去，一个不容回避的事实是：不管哪个版本的RAG，最终可能根本都不需要存在。

巨大序列长度的时代来了

相信你很清楚，现在的前沿大模型——比如Gemini 1.5或Claude 3，在生产级发布版本中已经可以处理多达一百万个Token（约75万个词），而在研究实验室里甚至达到了上千万个Token（约750万个词）。

说得直白点，这些模型在每个提示词里都能“吞下”极其冗长的文本序列。

举个具体数字：《指环王》系列一共57万多个词，而《哈利波特》系列约108万词。也就是说，如果有一个750万字的上下文窗口，你可以在每个提示里把这两个系列的故事同时塞进去，而且还能翻五倍。

在这种情况下，我们真的还需要一个知识检索器来做知识库吗？还是说，干脆在每个提示里直接把所有信息喂进去就行了？

常规思维可能会觉得：序列越长，模型准确检索正确上下文的难度就越大，对吧？

从RAG的角度来看，它的流程并不需要在每个提示里塞全量上下文——它只挑选语义相关的数据，所以整体效率更高一些。

但谷歌那边的实验结果却给出了相反的结论：即便是面对1000万个Token的超长上下文，在“大海捞针”任务中——也就是把一个小而分散的事实埋在提示词深处，看模型能不能找出来——他们依然实现了近乎100%的准确率。

这怎么可能？

背后的技术原因是，这些模型底层的操作符——注意力机制——拥有绝对的全局上下文能力。注意力机制强制每一个单独的Token（可以理解为单词或子词）去关注序列中每一个其他的单词。无论依赖关系多远、信号多微弱（哪怕一个关键信息藏在数百万个单词后的某个词里），模型都能检测到。

所以，RAG最终的存亡，很可能并不取决于准确率，而是取决于另一个更现实的因素：

成本。

更好的商业案例，或者死亡

现阶段，受限于Transformer架构的固有特性，更长的序列不仅意味着成本的二次方增长（序列翻倍，计算量翻四倍；序列三倍，计算量九倍），还因为KV缓存（模型的缓存内存）的膨胀，导致内存需求急剧上升。

说白了，运行超长序列的成本实在太高了。以至于在DNA分析这类需要极长序列的应用场景中，Transformers压根不被考虑——研究人员用的是鬣狗算子来替代注意力机制，用长卷积以低于二次方的成本来捕捉长距离依赖关系。

等一下，卷积不是也是二次运算吗？没错，标准卷积的成本确实是二次的。但通过应用卷积定理——两个函数之间的卷积，其傅里叶变换等于它们各自傅里叶变换的逐点积——你可以在低于二次方的时间和成本内完成计算。这种操作叫作“快速卷积”。本质上，你是在频域里算逐点乘积，而不是在时域里搞卷积，显然更快、更便宜。

还有其他替代方案走的是混合路线——不是完全抛弃注意力，而是在注意力和其它操作之间找到最佳平衡点，用更低成本来保持性能。最近的例子就是Jamba，它巧妙地融合了Transformers和另一个更高效的架构Mamba。

鬣狗、曼巴、注意力……你可能会觉得我是在堆一堆花哨名字来证明观点。但回到本质，所有这些架构最终都在遵循同一个原则：用不同方式来揭示语言中的模式，帮助我们的人工智能模型理解文本。目前，注意力机制驱动着99%的模型，剩下的则都在努力寻找更便宜的方法，同时在尽可能少的性能损失下，把LLM的运营成本压下来。

因此可以合理预测，要不了多久，极长的序列就能以现在几分之一的价格被处理。而这无疑会加剧人们对RAG架构必要性的怀疑。等到那一天真的到来——几乎可以肯定它一定会来——我们还会继续依赖RAG吗？坦白说，目前没人能给出确切答案。但现在做的一切努力，或许真的只是在做无用功。