当前位置:首页|资讯|GPT-4

RAG+GPT-4 Turbo让模型性能飙升,更长上下文不是终局,「大海捞针」实验成本仅4%

作者:新智元发布时间:2023-12-08

RAG或许就是大模型能力飙升下一个未来。

RAG+GPT-4,4%的成本,便可拥有卓越的性能。

这是最新的「大海捞针」实验得出的结论。

在产品中使用LLM的下一阶段,重点是让它们生成的响应/回复更加「超前高速化」(hyper-specific)。

也就是LLM需要按照不同的使用情况,针对数据集、用户、使用案例,甚至包括针对特定调用,生成完全不同的响应。

这通常是通过 3 种基本技术中的一种来实现的:

1. 上下文窗口填充(Context-window stuffing)

2. RAG(检索增强生成)

3. 微调

正如实践者所知,与炒作相反(「在您的数据上训练的 GPT......!」),主要是使用上下文窗口填充和 RAG(而不是微调)来专门化 LLM 的响应。

作者Atai Barkai最近在CopilotKit中添加了一个新的面向文档的react hook,专门用于容纳(可能是长格式的)文档。

为了帮助选择合理的默认值(受到Greg Kamradt的启发),BarkaiRAG 和 GPT-4-Turbo 的上下文窗口进行了一次「大海捞针」式的压力测试,涉及3个关键指标:(1) 准确性;(2) 成本;(3) 延迟。

他还对2个不同的RAG管道进行了基准测试:

- Llama-Index最流行的开源RAG框架(默认设置)。

- OpenAI的新助手API的检索工具——在后台使用 RAG(已证明可使用Qdrant向量数据库)。

实验结果

先来看下结果,再来讲方法论。

长话短说,现代的检索增强型生成(RAG)模型的效果非常好。

根据你的使用情况,你可能永远都不想把上下文窗口塞得太满(至少在处理文本时)。

准确性

如上图所示,assistant API (GPT-4+RAG)的性能近乎完美。

注意:这一性能仅适用于搜索式查询。大型上下文窗口还有其他用例(如少样本学习)。

成本

上下文窗口填充仅产生每个token的成本,而RAG产生每个token的成本,以及额外的固定LLM推理成本。

以下是每个token的成本:

如果你没有注意到,这个差值跨越了4个数量级(对数刻度)。

但同样,RAG也会产生固定的LLM智能体循环成本。

对于128k上下文窗口,平均总成本约为0.0004 美元/1k token,或GPT-4-Turbo成本的4%。

Llama Index的成本略低,但与之相当,为0.00028 美元/1k token(由于智能体循环不那么复杂)。

延迟

RAG通常是针对离线数据进行的,检索延迟以毫秒为单位,端到端延迟主要由LLM调用决定。

但作者认为,比较一下从文件上传到返回结果的端到端延迟时间,看看RAG是否能与「在线」(而非离线)数据竞争,会很有意思。

以下是对128k token文档进行查询的端到端延迟:

- LlamaIndex RAG最低,平均为12.9秒。

- 其次是GPT4-Turbo,平均用时21.6秒,但差距很大,为7-36秒。

- assistant API RAG检索时间为24.8秒。

此外,大多数应用程序都能从乐观的文档上传中获益,从而最大限度地减少感知延迟。由于RAG索引的成本很低,通常不会有太大损失。

「大海捞针」实验

作者Atai Barkai以Greg Kamradt的出色工作为基础,他最近进行了GPT-4-Turbo和Claude 2.1的「大海捞针」(needle in a haystack)压力测试。

从本质上讲,我们给一个「大海」,并在其中的某个地方隐藏了一根「针」,然后询问AI系统关于针的情况。

作者会把这根「针」放在大海的不同位置,从最开始到结束的地方,每个位置间隔约10%。

在上下文窗口填充实验中,作者只是将「大海捞针」推到了LLM调用上下文窗口上。在RAG实验中,作者创建了一个文档并对其执行了RAG。

(正如格雷格的出色分析一样,「大海捞针」是Paul Graham的论文集,而「针」是一个不相关的事实。

进一步分析

准确性

GPT-4+RAG表现非常出色。

这并不完全令人惊讶。在LLM上下文窗口中放置不相关的信息不仅成本高昂,而且对性能有害。

更少的垃圾=更好的结果。

这些结果凸显了我们仍处于LLM革命的初期。广大社区仍在摸索将新的LLM构建模块组合在一起的最合理方法。

过去一年的上下文窗口大战完全有可能在平淡无奇中结束。

大家都明白,基于RAG的日益复杂的技术,而不是更大的上下文窗口,才是关键所在(至少对于文本而言)。

LlamaIndex

作者本以为随着上下文窗口的增加,RAG的性能会大致相同。

但事实并非如此,当上下文长度超过约100k时,性能明显下降。他的猜测是,超过一定的上下文大小后,「针」就不再被检索过程获取了。

不同的分块和检索配置可能会影响此结果。

总的来说,作者非常看好LlamaIndex和开源LLM技术。

很明显,RAG仍然处于唾手可得的领域,简化框架是关键。Llama-Index已经做好准备,可以继续整合新技术和最佳实践。

这张泄露的OpenAI开发者日幻灯片提供了一些灵感:

成本

RAG 成本分析有点微妙,因为它只是部分确定性的。RAG 的第一部分是检索,根据一些启发式(通常是矢量搜索)从更广泛的数据集中选择最「有前途」的文档块。

第二部分是生成增强,选择的块被输入到「标准」LLM调用中(并且随着通用性的增加,被输入到智能体LLM循环中)。

原则上,检索可以使用多种技术来实现,从关键字搜索到关系搜索,再到混合技术。

在实践中,大多数当代RAG方法主要使用矢量搜索,这会产生一次性、按token索引的成本。随着生态系统的成熟,混合技术的使用可能会越来越多。

每个token的成本

让我们首先看一下每个token的成本:

- GPT-4-Turbo 以 $0.01/1k token的价格。(与GPT-4和GPT-4-32k相比,价格分别降低了3倍和6倍) - OpenAI 的 ada v2 嵌入模型收费 0.0001 美元/1k token。这比GPT-4-Turbo便宜100倍。

- OpenAI 的助手 API 的检索功能价格更加昂贵。它以「无服务器」方式收费,0.20 美元/GB/助手/天。假设 1 个token ~ 5 个字节,即1×10^-6 美元/1k 个token/助手/天。

固定开销

开销部分很难计算(或者说不可能,在 OpenAI 的情况下),所以作者也只是凭经验测量它。

如结果部分所述,RAG还会产生固定开销,该开销源自LLM推理步骤。对于128k上下文,此固定成本为GPT-4上下文窗口的4%。

延迟

原则上,嵌入计算是高度可并行化的。因此,考虑到市场需求,未来的基础设施改进可能会将延迟降低到单个块嵌入的往返。

在这种情况下,可以看到即使是「在线」RAG管道延迟也会大大减少,以至于「在线」RAG延迟仅由LLM思维链循环的延迟主导。

参考资料

https://www.reddit.com/r/MachineLearning/comments/18bivxa/d_needle_in_a_haystack_experiment_assistants_api/

本文来自微信公众号“新智元”(ID:AI_era),作者:桃子,36氪经授权发布。


Copyright © 2024 aigcdaily.cn  北京智识时代科技有限公司  版权所有  京ICP备2023006237号-1