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），增加示例數量并未帶來顯著改善，這表明模型在復雜推理任務上仍有局限性。