202406 arxiv

1 intro

• 传统上，复杂的AI任务需要多个专门系统协作完成。
  • 这类系统通常需要独立的模块来进行信息检索、问答和数据库查询等任务
• 大模型时代，尤其是上下文语言模型（LCLM）时代，上述问题可以“一体化”完成
  • LCLM可以直接接收包含文本、图像、音频等多模态信息的整个语料库作为输入。
  • 通过"语料库中的上下文"（CiC）提示方法，模型能够在统一的框架内执行各种任务，包括检索、推理和答案生成
  • ——>大大简化了流程
  • ——>避免了多个独立系统可能带来的错误累积问题

• 然而，评估这些模型的性能并不容易。现有的方法往往局限于特定任务，难以全面测试长上下文模型的能力
  • ——>论文提出了LOFT（Long-Context Frontiers）基准测试
    • 包含6种任务类型，涵盖35个数据集，横跨文本、视觉和音频多个模态

      • 文本检索：从大量文档中找出相关内容

      • 视觉检索：根据文本描述找出相关图像或视频

      • 音频检索：匹配文本与相应音频

      • RAG：基于检索信息生成答案

      • SQL：理解自然语言查询并从数据库中提取信息

      • 多示例上下文学习：从大量示例中学习并完成任务

    • LOFT的一个关键特性是其可扩展性

      • 支持从32k到128k，再到1M个标记的上下文长度

      • ——>能够系统地评估模型性能随上下文长度增加的变化

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），增加示例数量并未带来显著改善，这表明模型在复杂推理任务上仍有局限性。