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/
快抢沙发！
