微信扫码
与创始人交个朋友
我要投稿
纵观人工智能行业,我们已经习惯了每天都看到一些东西被“杀死”。当我谈到第 23923 次某件事突然被“杀死”时,我自己有时也会感到尴尬。
但很少有案例能像Contextual.ai在他们所谓的“ RAG 2.0 ”中提出的上下文语言模型 (CLM)那样引人注目,它使标准检索增强生成 (RAG)——实现生成式 AI 模型的最流行方法之一(如果不是最流行的话)——过时。
这一说法的背后,正是RAG 的最初创建者。
虽然这比生产级生成式人工智能的现状有了很大的进步,但整个子空间仍然存在一个问题:RAG 是否正在走向末路,而这些创新是否只是在做无用功?
您可能知道或不知道,所有独立的大型语言模型 (LLM)(以 ChatGPT 等突出示例)都有知识截止。
这意味着预训练是一次性的练习(与持续学习方法不同)。换句话说,LLM 已经“看到”了某个时间点的数据。
例如,在撰写本文时,ChatGPT 的更新期限为 2023 年 4 月。因此,他们不准备回答该日期之后发生的事实和事件。
这正是 RAG 发挥作用的地方。
顾名思义,这个想法是从已知数据库中检索数据,LLM 很可能从未见过的数据,并将其实时输入模型,以便它具有更新的(重要的是,语义相关的)上下文来提供准确的答案。
但是这个检索过程是如何进行的呢?
整个架构源于一个单一原则:检索与请求或提示上下文相关的语义上有意义的数据的能力。
该过程涉及使用三个元素:
嵌入模型
检索器,通常是一个矢量数据库
以及生成器,LLM
首先,为了使这个检索过程正常工作,您需要将数据设为“嵌入形式”,即以数字向量形式的文本表示。
更重要的是,这些嵌入具有相似性原则:相似的概念将具有相似的向量。
例如,“狗”和“猫”的概念对我们来说是相似的:它们都是动物、哺乳动物、四足动物和家养动物。转换成向量,“狗”可以是 [3, -1, 2],“猫”可以是 [2.98, -1, 2.2],你可以将每个数字视为该概念的“属性”。因此,相似的数字意味着相似的属性。
查看我对嵌入的深入评论。
有了嵌入之后,我们将它们插入到向量数据库(检索器)中,这是一个存储这些嵌入的高维数据库。
应用我们之前讨论过的相似性原理,在这个空间中相似的事物会更接近。
然后,每当用户发送类似下面的请求“给我类似于‘黄猫’的结果”时,矢量数据库就会执行“语义查询”。
通俗地说,它会提取与用户查询距离最近的向量(在距离上)。
由于这些向量代表底层概念,因此相似的向量将代表相似的概念,在本例中就是其他猫。
一旦我们提取了内容,我们就构建 LLM 提示,封装:
用户的请求
提取的内容
通常是一组系统指令
但是系统指令是什么?
作为快速工程过程的一部分,您还需要调整模型的响应方式。典型的系统指令可能是“简洁”。
这就是 RAG 的概要,它是一种在推理时向用户查询实时提供相关内容以增强 LLM 响应的系统。
RAG 系统之所以能够发挥作用,首先要归功于 LLM 最强大的超能力:情境学习,它允许模型使用以前未见过的数据来执行准确的预测,而无需进行权重训练。
以下是对情境学习以及 LLM 如何学习使用它的深入探讨。
但这个过程听起来好得令人难以置信,当然,事情并不像看上去那么令人惊奇。
理解推动前沿人工智能模型演进的关键直觉很难。但其实并非如此。
如果您想了解人工智能的狂热世界,同时又想受到启发采取行动,或者至少为未来做好充分准备,那么本期简报适合您?
可视化当前 RAG 系统的一种方法是以下方式:
虽然这些裤子可能适合某些观众,但大多数人永远不会穿它们,因为没有同质性,尽管补丁裤子最初是不引人注意的。
这种类比背后的原因是,标准 RAG 系统组装了三个不同的组件,这些组件经过单独预训练,而且根据定义,它们不应该放在一起。
相反,RAG 2.0系统从一开始就被定义为“一件事”。
实际上,整个系统在连接的同时进行端到端的训练,就像假设 LLM 应该始终有一个与之绑定的矢量数据库以保持更新一样。
与标准 RAG、预训练、微调和基于人类反馈的强化学习 (RLHF) 相比,标准 LLM 训练的所有必要组件都是从头开始执行的,包括 LLM 和检索器(向量数据库)。
用更专业的术语来说,这意味着,在反向传播过程中,训练这些模型的算法,梯度不仅通过整个 LLM 传播,而且还通过检索器传播,以便整个系统作为一个整体从训练数据中学习。
结果无可否认地表明了这一点:
尽管使用的独立模型几乎肯定会比 GPT-4 更差,但这种新方法的性能优于 GPT-4 与其他检索系统之间的所有其他可能的 RAG 1.0 组合。
原因很简单:在 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 流程不是在每个提示中提供整个上下文,而是只选择语义相关的数据,从而使其整体上成为一个更高效的流程。
然而,正如谷歌所证明的,长序列的准确性并不受影响,因为他们在“大海捞针”任务中,即使在 1000 万个标记长的上下文中也表现出几乎 100% 的准确率,其中一个小的、有时不相关的事实隐藏在提示的深处,看看模型是否正确检索到它。
事实确实如此:
但这怎么可能呢?
无论长度如何,都能实现如此惊人的性能,其背后的技术原因是,这些模型背后的底层操作符——注意力机制,具有绝对的全局上下文,因为注意力机制强制每个单独的标记(又名单词或子词)关注序列中每个其他先前的单词。
这确保了无论依赖关系有多远,无论信号有多小(关键信息可能存储在数百万个单词之外的一个单词中),模型都应该能够(而且确实能够)检测到它。
因此,我认为,RAG 最终能否生存下来,并不取决于准确性,而是取决于超越技术的另一个关键因素:
成本。
如今,由于 Transformer 无法压缩上下文,更长的序列不仅意味着成本的二次方增加(序列增加 2 倍意味着计算量增加 4 倍,而增加 3 倍则意味着计算成本增加 9 倍),而且还意味着由于KV Cache大小的增加,内存需求会激增。
KV Cache 是模型的“缓存内存”,避免了重新计算大量冗余注意力数据,否则会导致该过程在经济上不可行。以下是 KV Cache 是什么以及它如何工作的深入评论。
简而言之,运行非常长的序列的成本非常高,以至于对于具有极长序列长度的模态(如 DNA),Transformers 甚至不会被考虑。
事实上,在 EVO 等 DNA 模型中,研究人员使用Hyena 算子代替注意力来避免前面提到的二次关系。Hyena 算子使用长卷积代替注意力来以次二次成本捕获长距离依赖关系。
但是等一下,卷积不也是二次运算吗?
是的,但是虽然标准卷积的成本确实是二次的,但通过应用卷积定理,该定理指出两个函数之间的卷积的傅里叶变换是它们各自傅里叶变换的逐点积(哈达玛积),您可以在亚二次时间和成本内执行该操作,这种操作称为“快速卷积”。
本质上,虽然您是在时间域中计算卷积,但您是在频域中将其作为逐点乘积进行计算,这样更快、更便宜。
其他替代方案则力求采用混合方法,即不是完全放弃注意力,而是在注意力和其他操作之间找到最佳平衡点,以较低的成本保持性能。
最近的例子包括Jamba,它巧妙地将 Transformers 与其他更高效的架构(如Mamba)结合在一起。
曼巴、鬣狗、注意...... 你可能认为我只是用一些花哨的词语来证明一个观点。
但是,忘记那些不同的奇怪的名字吧,归根结底,一切都归结为同一个原则:它们是揭示语言模式的不同方式,以帮助我们的人工智能模型理解文本。
如今,注意力驱动着 99% 的模型,而其余模型只是试图找到更便宜的方法,同时尽可能减少性能损失,以使 LLM 更加便宜。
总而言之,我们很快就会看到极长的序列被当前价格的一小部分所处理,这应该会增加人们对 RAG 架构必要性的怀疑。
当那个时候到来时,我们几乎可以保证一定会发生,我们还会依赖 RAG 吗?我不知道,但我们现在有可能是在做无用功。
53AI,企业落地应用大模型首选服务商
产品:大模型应用平台+智能体定制开发+落地咨询服务
承诺:先做场景POC验证,看到效果再签署服务协议。零风险落地应用大模型,已交付160+中大型企业
2024-11-24
解读GraphRAG
2024-11-24
RAGChecker:显著超越RAGAS,一个精细化评估和诊断 RAG 系统的创新框架
2024-11-23
FastRAG半结构化RAG实现思路及OpenAI O1-long COT蒸馏路线思考
2024-11-23
检索增强生成(RAG):解密AI如何融合记忆与搜索
2024-11-23
如何提高RAG系统准确率?12大常见痛点及巧妙解!
2024-11-23
RAG 2.0性能提升:优化索引与召回机制的策略与实践
2024-11-22
RAG技术在实际应用中的挑战与解决方案
2024-11-22
从普通RAG到RAPTOR,10个最新的RAG框架
2024-07-18
2024-05-05
2024-07-09
2024-05-19
2024-07-09
2024-06-20
2024-07-07
2024-07-07
2024-07-08
2024-07-09
2024-11-06
2024-11-06
2024-11-05
2024-11-04
2024-10-27
2024-10-25
2024-10-21
2024-10-21