202406 arxiv
1 intro
- 传统上，复杂的AI任务需要多个专门系统协作完成。
- 这类系统通常需要独立的模块来进行信息检索、问答和数据库查询等任务
- 大模型时代，尤其是上下文语言模型（LCLM）时代，上述问题可以“一体化”完成
- LCLM可以直接接收包含文本、图像、音频等多模态信息的整个语料库作为输入。
- 通过"语料库中的上下文"（CiC）提示方法，模型能够在统一的框架内执行各种任务，包括检索、推理和答案生成
- ——>大大简化了流程
- ——>避免了多个独立系统可能带来的错误累积问题
- 然而，评估这些模型的性能并不容易。现有的方法往往局限于特定任务，难以全面测试长上下文模型的能力
- ——>论文提出了LOFT（Long-Context Frontiers）基准测试
- 包含6种任务类型，涵盖35个数据集，横跨文本、视觉和音频多个模态
文本检索：从大量文档中找出相关内容
视觉检索：根据文本描述找出相关图像或视频
音频检索：匹配文本与相应音频
RAG：基于检索信息生成答案
SQL：理解自然语言查询并从数据库中提取信息
多示例上下文学习：从大量示例中学习并完成任务
LOFT的一个关键特性是其可扩展性
支持从32k到128k，再到1M个标记的上下文长度
——>能够系统地评估模型性能随上下文长度增加的变化
- 包含6种任务类型，涵盖35个数据集，横跨文本、视觉和音频多个模态
- ——>论文提出了LOFT（Long-Context Frontiers）基准测试
2 Corpus-in-Context prompt
- 为了充分发挥长上下文模型的潜力，研究团队提出了"上下文中的语料库"（Corpus-in-Context，CiC）提示方法
- 这种方法允许模型直接在给定的大规模语料库中进行检索和推理
3 实验结果
3.1 评估的模型
- 评估了三个最先进的长上下文模型：
- Google的Gemini 1.5 Pro
- OpenAI的GPT-4o
- Anthropic的Claude 3 Opus
3.2文本检索任务
- 在文本检索任务中，Gemini 1.5 Pro的表现尤为出色。
- 在128k上下文长度的测试中，Gemini 1.5 Pro在多个数据集上达到了与专门训练的检索系统Gecko相当的性能。
- 例如，在NQ数据集上，Gemini 1.5 Pro和Gecko都达到了0.99的Recall@1分数，而Gemini 1.5 Pro并没有经过专门的检索训练。
- 然而，随着上下文长度增加到1M标记，模型性能出现了一定程度的下降。这表明在处理超长上下文时，模型仍面临着挑战。
3.3 视觉检索 &音频检索
- 在视觉检索任务中，Gemini 1.5 Pro同样表现出优异的性能表现。
- 其在多个数据集上超越了专门的视觉-文本检索模型CLIP。
- 例如，在OVEN数据集上，Gemini 1.5 Pro达到了0.93的分数，而CLIP只有0.79。
- 在音频检索任务上，Gemini 1.5 Pro在所有五种语言的FLEURS数据集上都达到了完美或接近完美的表现，超过了专门的音频检索模型。
3.4 RAG
- 在RAG任务中，长上下文模型展现出了强大的推理能力。
- 在需要多跳推理的数据集（如HotpotQA和MusiQue）上，Gemini 1.5 Pro的表现超过了传统的RAG pipeline。
- 例如，在HotpotQA上，Gemini 1.5 Pro得分为0.75，而专业的RAG系统得分为0.70。
3.5 SQL任务
- 在SQL类任务中，长上下文模型的表现相对较弱。
- 在Spider和SparC数据集上，专门的SQL系统的性能显著优于长上下文模型。
- 这表明在处理需要复杂结构化推理的任务时，这些模型还有很大的改进空间。
3.6多示例上下文学习
- 在多示例上下文学习任务中，长上下文模型展现出了良好的表现。
- 在某些任务中（如LIB-dialog），模型的性能随着示例数量的增加而稳步提升。
- 然而，在一些推理密集型任务中（如BBH-tracking7），增加示例数量并未带来显著改善，这表明模型在复杂推理任务上仍有局限性。
