谷歌宣布长上下文大模型可告别RAG检索增强

先抛出一个核心判断：大语言模型（LLM）的发展，可能正在改写AI应用的底层逻辑。当大多数人的目光还停留在参数规模和对话流畅度上时，一个更底层的范式转变已经悄然发生——长上下文模型的崛起，或许会让“检索增强生成”（RAG）这一技术栈变得不再必要。

最近，谷歌发布了一个名为LOFT的基准测试，专门用来评估长上下文语言模型（LCLM）的真实能力。这个测试涵盖信息检索、问答、数据库查询等五花八门的实际任务。结果相当震撼：在某些任务上，最先进的长上下文模型已经能与专门训练的系统打得有来有回，甚至表现更好。

这意味着什么？一个可能碘伏现有AI应用架构的结论浮出水面：在不远的将来，我们或许只需要一个强大的语言模型，就能包揽过去需要多个专门系统（比如检索器、问答模块、SQL解析器）才能完成的复杂任务。当然，研究也毫不客气地指出了当前模型的短板——事情远没有那么简单。

AI界的新挑战与机遇

过去，处理一个复杂的AI任务，往往需要像搭积木一样，把不同的专门模块拼在一起。比如，先让一个检索系统去翻文档，再把结果喂给一个问答模型，最后才能生成答案。整个过程链条长，任何一个环节出错都会累积，导致最终结果跑偏。

长上下文语言模型（LCLM）的出现，提供了一个完全不同的思路。它不再需要那些独立的检索模块。看看下面的对比就明白了——左侧是传统的“多模块协同”模式，右侧是LCLM的“大一统”方案。

右边那个方案的核心在于一个叫做“语料库中的上下文”（Corpus-in-Context, CiC）的提示方法。简单说，就是把整个语料库——包括文本、图片、音频——一股脑儿作为输入，全部塞进模型的上下文窗口里。模型直接在这个“大池子”里完成检索、推理和答案生成。流程大大简化，也避开了多个独立系统带来的误差累积风险。

但是，这些模型到底行不行？光看广告不行，得拉出来遛遛。而现有的评估方法往往只盯着某一项特定任务，没法全面衡量长上下文模型的综合实力。正是基于这个痛点，研究者们才设计出了LOFT基准测试。

LOFT的覆盖面相当广，包含了6种任务类型、35个数据集，横跨文本、视觉和音频三大模态。更重要的是，它能动态调整上下文长度，从32k到1M个token，这样就能系统性地观察模型在不同长度上下文下的表现差异。

可以说，LOFT的诞生，为这个领域提供了一个标准化的“测量尺”。它既是探照灯，也是试金石，帮我们看清长上下文模型的潜力和边界。

LOFT：一个全面的长上下文语言模型评估基准

LOFT的六类任务，基本上覆盖了实际应用中可能遇到的大部分场景：

• 文本检索：从海量文档中精准定位目标内容。
• 视觉检索：根据一句话描述，从一堆图片或视频里找出匹配项。
• 音频检索：让文本和音频“对上号”。
• 检索增强生成（RAG）：基于检索到的信息生成答案。
• SQL类任务：把人类的自然语言查询，转化为结构化数据库的提取操作。
• 多示例上下文学习：从大量案例中“无师自通”，学会完成新任务。

这个基准测试的另一个亮点，是其可扩展性。它支持从32k、128k一直到1M token的上下文长度，让研究者能清晰地看到模型性能随上下文“膨胀”而变化的曲线。

为了让长上下文模型发挥出最大潜力，研究团队还专门设计了CiC提示方法。它由四个部分构成：

• 指令：明确告诉模型“你需要干什么”。
• 语料库格式化：把整个语料库塞进上下文，并为每个候选项分配一个唯一的编号ID。
• 少样本示例：给模型几个带“思考过程”的示范。
• 查询格式化：按照示范的格式，向模型提问。

这套方法就像是给模型画好了“地图”和“说明书”，让它即便面对海量信息，也能有条不紊地找出答案。

实验结果：惊喜与挑战并存

LOFT的实验结果，可以说是一份“喜忧参半”的成绩单。研究团队挑选了当前最顶尖的三个长上下文模型——谷歌的Gemini 1.5 Pro、OpenAI的GPT-4o和Anthropic的Claude 3 Opus——进行了一场硬碰硬的较量。

文本检索：令人意外的“跨界王”

在文本检索任务中，Gemini 1.5 Pro的表现堪称惊艳。在128k上下文长度的测试下，它在多个数据集上竟然追平了专门训练的检索模型Gecko。举个例子，在NQ数据集上，两者的Recall@1分数都达到了0.99——而Gemini 1.5 Pro从未接受过专门的检索训练！

不过，当上下文长度被拉到1M token时，模型性能还是出现了下滑。这说明，处理“超长卷”信息时，模型仍面临不小的挑战。

视觉与音频检索：跨界碾压

视觉检索任务中，Gemini 1.5 Pro同样表现出色。在OVEN数据集上，它的得分是0.93，而专门的视觉-文本检索模型CLIP只有0.79。

音频检索更是“降维打击”。在所有五种语言的FLEURS数据集上，Gemini 1.5 Pro都拿到了完美或接近完美的分数，直接超越了专门的音频检索模型。

检索增强生成（RAG）：单挑“专门团队”

在RAG任务中，长上下文模型展现出了强大的推理能力。尤其是在需要多跳推理的数据集（如HotpotQA和MusiQue）上，Gemini 1.5 Pro的表现甚至盖过了传统的RAG pipeline。在HotpotQA上，它的得分是0.75，而专业的RAG系统只有0.70。

SQL任务：遭遇“滑铁卢”

然而，在SQL类任务中，长上下文模型的表现就没那么亮眼了。在Spider和SparC数据集上，专门的SQL系统明显强于这些通用模型。这说明，在处理需要复杂结构化推理的任务时，通用模型还有很大的提升空间。

提示策略的玄机

研究还发现，怎么“问”对结果影响巨大。在文本检索任务中，金标准文档在语料库中的位置会直接左右模型的注意力。

一个有趣的技巧是：把少样本示例中的金标准文档放在语料库的末尾，有助于模型把注意力集中到那个区域，从而提升整体表现。

多示例上下文学习：长板与短板

在多示例上下文学习任务中，长上下文模型的表现可圈可点。在某些任务（如LIB-dialog）上，模型性能会随着示例数量的增加而稳步提升。

但是，在一些推理密集型任务（如BBH-tracking7）上，即便给模型看了再多的例子，表现也没有明显改善。这再次印证了模型在复杂推理能力上的局限性。

总结与展望

LOFT的测试结果，向我们传递了一个清晰的信号：长上下文语言模型在检索和多模态任务上的能力，正在逼近甚至超越专门系统。这意味着，我们过去习以为常的“多个独立系统拼凑”的AI应用架构，可能真的要迎来一次“格式重组”。

当然，问题依然存在。处理超长上下文时性能衰减、在复杂结构化推理任务上表现乏力——这些都是未来需要攻克的高地。接下来的研究，大概率会集中在几个方向上：如何改进超长上下文的处理技术？如何增强模型的结构化推理能力？如何设计更聪明的提示策略？以及，如何让通用模型与专门系统更好地结合，取长补短？

无论如何，LOFT为这个领域提供了一把精准的标尺。沿着这条路走下去，一个更加统一、强大且灵活的AI系统，或许离我们并没有想象中那么遥远。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：谷歌宣布长上下文大模型可告别RAG检索增强要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题