RAG 2.0，让RAG 终成正果
原创RAG 2.0，让RAG 终成正果
原创
在观察人工智能行业的时候，我们已经习惯了每天看到各种事物被“淘汰”。有时候，当我不得不第23923次谈论某个事物突然被“淘汰”时，我自己也会感到不安。
然而，像Contextual.ai提出的基于情境语言模型（CLMs）的“RAG 2.0”这样的案例却很少见，它试图让目前最流行（如果不是最受欢迎的话）的生成式AI模型实现方式之一——标准检索增强生成（RAG）变得过时。提出这种主张的，恰恰是RAG的创造者。
虽然这是对生产级生成式AI现状的一次重大改进，但整个子领域仍存在一个疑问：RAG是否正在走向末路，这些创新是否只是在对一个已经死去的马施加无效的鞭打？
从数据的角度看问题
你可能知道，也可能不知道，所有的独立大规模语言模型（LLMs），如ChatGPT等，都有一个“知识截止日期”。
这意味着预训练是一次性的任务（与持续学习方法不同）。换句话说，LLMs只能“看到”截止到某一时间点的数据。例如，撰写本文时，ChatGPT的数据截止于2023年4月。因此，它们无法回答在那个日期之后发生的事实和事件。
这就是RAG发挥作用的地方。
一切都关于语义相似性
顾名思义，RAG的理念是从已知数据库中检索数据，这些数据可能是LLM从未见过的，并实时地将它们输入模型，以便为模型提供最新的，更重要的是，语义相关的上下文，从而提供准确的答案。
那么，这个检索过程是如何运作的呢？
整个架构基于一个单一的原则：有能力检索与请求或提示上下文语义相关、有意义的数据。
来源
这个过程涉及到三个元素：
- 嵌入模型
- 检索器，通常是一个向量数据库
- 生成器，也就是LLM
首先，为了让检索过程有效，我们需要将数据转换为“嵌入”形式，也就是将文本表示为数值向量。
这些嵌入遵循一个相似性原则：相似的概念会有相似的向量。例如，“狗”和“猫”的概念在我们看来是相似的：它们都是动物、哺乳动物、四足动物并且可以被人类驯养。因此，当它们被转换为向量后，“狗”可能是3, -1, 2，“猫”可能是2.98, -1, 2.2，我们可以将每个数字视为该概念的一个“属性”。因此，相似的数字意味着相似的属性。
如果你想深入了解什么是嵌入，请查阅我的深度解析文章。
当我们得到了嵌入后，我们将它们插入到向量数据库（也就是检索器）中，这是一个存储这些嵌入的高维数据库。
根据之前讨论的相似性原则，在这个空间中，相似的事物会彼此更接近。
然后，每当用户发送如下请求：“给我与‘黄色猫’类似的结果”时，向量数据库就会执行一次“语义查询”。
用通俗的话说，它会提取出与用户查询向量距离最近的向量。
由于这些向量代表了底层的概念，所以相似的向量将代表相似的概念，在这个例子中，就是其他的猫。
来源
一旦我们提取了相关的内容，我们就为大型语言模型（LLM）构建了一个提示，这个提示包括了：
- 用户的请求
- 提取的内容
- 通常还包括一组系统指令
那么，什么是系统指令呢？
在构建提示的过程中，你可能会希望调整模型的响应方式。一个典型的系统指令可能是“要简洁”。
这就是RAG（Retrieval-Augmented Generation，检索增强生成）的精髓，一个能够在推理时提供与用户查询相关的实时内容以增强LLM响应的系统。
RAG系统之所以能工作，是因为LLM的一个重要特性：上下文学习。这使得模型能够使用以前未见过的数据，在没有进行权重训练的情况下进行准确的预测。
让我们深入探讨一下上下文学习，以及LLM是如何学习使用它的。
但这个过程听起来好得令人难以置信，当然，事情并不像看起来那么惊人。
理解推动前沿AI模型发展的关键直觉是困难的。但它不必如此。
无需拼凑的解决方案，已经过时
我们可以用下面的裤子图形象地表示当前的RAG系统：
虽然这些裤子可能适合某些观众，但大多数人永远不会穿它们，因为尽管补丁裤最初是为了不引人注意，但它们并没有统一性。
这个类比背后的原因是因为标准的RAG系统组装了三个不同的组件，这些组件是分别预训练的，并且根据定义，它们本来就不应该在一起。
相反，RAG 2.0系统从一开始就被定义为“一体”。#RAG2.0#
这里不允许有“弗兰肯斯坦”（意指拼凑而成的东西）
在实践中，整个系统是端到端训练的，同时保持连接，就像假设大型语言模型（LLM）应该始终有一个向量数据库与之相连，以保持更新。
与标准的RAG相比，预训练、微调以及从人类反馈中学习强化学习（RLHF），所有这些是标准LLM训练的基本组成部分，都是从头开始执行的，包括大型语言模型和检索器（向量数据库）。
用更专业的术语来说，这意味着在反向传播过程中，用于训练这些模型的算法，梯度不仅会在整个LLM中传播，还会在检索器中传播，以便整个系统作为一个整体从训练数据中学习。
而结果证明了这一点：
尽管使用的模型几乎肯定比GPT-4更差，但这种新的方法在所有可能的GPT-4和其他检索系统的RAG 1.0组合中表现最好。
来源：Contextual.ai
原因很简单：在RAG 1.0中，我们分别训练各个部分，然后把它们拼接在一起，希望得到最好的结果。但在RAG 2.0中，所有组件从一开始就在一起。
用更专业的术语来说，把两个独立训练的系统拼接在一起是制造灾难的配方，尤其是在学习到的表示不平衡的情况下。
这就像一个英国人试图使用一个日本数据库；虽然上下文存在，但它不能被英国人理解。
但即使RAG 2.0的优势明显，还有一个重大问题仍未解决。
真正的问题还未得到解答
尽管RAG 2.0可能很快成为那些不愿与大型语言模型（LLM）提供商共享机密数据的公司的企业标准，但有理由怀疑，无论是哪个版本的RAG，最终可能都不再需要。
巨大序列长度的到来
我相信你非常清楚，我们今天的前沿模型，比如Gemini 1.5或Claude 3，它们的上下文窗口非常大，在生产发布的模型中可以达到一百万个令牌（75万字），在研究实验室中可以达到一千万个令牌（750万字）。
用通俗的话来说，这意味着这些模型可以在每个提示中输入非常长的文本序列。
作为参考，《指环王》系列书籍总共有576,459个单词，而《哈利·波特》整个系列书籍大约有1,084,170个单词。因此，一个750万字的上下文窗口可以在每个提示中五次装下这两个故事。
在这种情况下，我们真的需要一个知识检索知识库，而不是仅仅在每个提示中输入信息吗？
一个可能放弃这个选项的理由可能是准确性。序列越长，模型检索正确上下文的难度应该越大，对吗？
另一方面，与在每个提示中输入整个上下文相比，RAG过程允许只选择语义相关的数据，从而使整个过程更加高效。
然而，正如谷歌所证明的那样，在长序列中准确性并不会受到影响，他们甚至在一千万个令牌长度的上下文中展示了几乎100%的准确性，对于“大海捞针”任务，其中在提示的深处隐藏了一个很小的，有时不相关的事实，以查看模型是否能够正确检索它。
而它确实做到了：
但这是如何做到的呢？
这些模型无论长度如何都能表现出惊人性能的背后的技术支持是，这些模型的基本操作符——注意力机制——具有绝对的全局上下文，因为注意力机制迫使序列中的每一个单独的令牌（也就是一个单词或子词）去关注序列中每一个其他的之前的单词。
这确保了无论依赖关系有多远，无论信号有多小（关键信息可能存储在一个距离数百万单词的单个单词中），模型应该能够——而且确实能够——检测到它。
因此，在我看来，RAG最终是否存活下来不会取决于准确性，而是取决于另一个超越技术的关键因素：
成本。
更好的商业案例，或者死亡
今天，由于Transformer无法压缩上下文，更长的序列不仅意味着成本呈二次方增长（序列增加2倍意味着计算量增加4倍，或者序列增加3倍意味着计算成本增加9倍），而且还意味着由于KV缓存大小的增加，内存需求会爆炸性增长。
KV缓存是模型的“缓存内存”，用于避免重新计算大量冗余的注意力数据，否则这个过程在经济上是不可行的。这里是关于KV缓存是什么以及它如何工作的深入回顾。
简言之，运行非常长的序列非常昂贵，以至于对于具有极长序列长度的模态，如DNA，甚至不考虑使用Transformer。
事实上，在像EVO这样的DNA模型中，研究人员使用了海纳（Hyena）操作符而不是注意力来避免前面提到的二次方关系。海纳操作符使用长卷积而不是注意力来以次二次方的成本捕捉长距离依赖。
但等等，卷积不也是一个二次方操作吗？
是的，但标准卷积的成本确实是二次方的，但通过应用卷积定理，该定理指出两个函数之间的卷积的傅里叶变换是它们各自傅里叶变换的逐点乘积（哈达玛乘积），你可以在次二次方的时间和成本内执行操作，这种操作被称为“快速卷积”。
本质上，虽然你在时间域中计算卷积，但你是作为频率域中的逐点乘积来计算它，这更快、更便宜。
其他的替代方案在寻求一种混合方法，而不是完全放弃注意力，而是找到注意力和其他操作符之间的最佳平衡点，以在保持性能的同时降低成本。
最近的示例包括Jamba，它巧妙地将Transformer与其他更高效的架构（如Mamba）混合在一起。
Mamba、Hyena、Attention……你可能认为我只是为了证明一个观点而随意列举一些花哨的词汇。
但忘掉这些不同的名字吧，在一天结束时，一切都归结为同一个原则：它们是揭示语言模式的不同方式，帮助我们的AI模型理解文本。
注意力机制驱动了当今99%的模型，其余的只是在尝试找到尽可能最小的性能降低的更便宜的方式，使大型语言模型（LLM）更加经济。
总的来说，我们很快就能看到处理极长序列的成本仅为现在的一小部分，这应该会增加对RAG架构需求的怀疑。
当那个时刻到来时，我们可以几乎肯定它会发生，我们还会依赖RAG吗？我不知道，但有可能我们现在正在做的都是无用功。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。