MMLongBench團隊 投稿量子位 | 公眾號 QbitAI
多模態長文字理解有綜合性的評判標準了！
來自香港科技大學、騰訊西雅圖AI Lab、愛丁堡大學、Miniml.AI、英偉達的研究者聯合提出了MMLongBench，旨在全面評估多模態模型的長文字理解能力。
隨著多模態大模型的單次推理的文字視窗快速提升，長上下文視覺-語言模型（Long-Context Vision-Language Models; LCVLMs）應運而生，使模型能夠在單次推理中處理數百張影像與較長的交錯文字。
但當前，由於評估多模態長文字的基準測試稀缺，現有的測試集僅關注單個任務，比如大海撈針或者長文件問答。目前尚不清楚現有的模型在長上下文環境下的綜合表現，具體在哪些任務上存在短板，以及它們對不同輸入長度變化的適應能力究竟如何。
MMLongBench覆蓋5大型別任務的16個不同的資料集，包含13,331個長文字樣本，涵蓋Visual RAG、大海撈針 (needle-in-a-haystack)、many-shot in-context learning、長文件摘要和長文件VQA。同時，豐富的任務設計兼顧了多樣的影像型別，既包括自然影像（如實景照片），也涵蓋了各類合成影像（如diffusion生成的圖片和PDF文件截圖）。
該資料集還提供了跨模態長度控制：使用image patch和text token來計算上下文長度，嚴格標準化8K/16K/32K/64K/128K輸入長度。
其評測資料集以及評測程式碼現已全部開源。
作者對46個領先的多模態大語言模型進行基準測試，其中包括Gemini-2.5-Pro、Claude-3.7-Sonnet、GPT-4o和Qwen2.5-VL-72B。
結果顯示，無論閉源還是開源模型，在長上下文視覺-語言任務上都面臨較大挑戰，仍有巨大的提升空間。
此外，進一步的錯誤分析表明，(1) OCR能力和 (2) 跨模態檢索能力仍然是當前LCVLMs在處理長文字時的瓶頸。
多工多模態長文字測試集
多工的資料構建
MMLongBench是一個包含了13,331個多模態長文字樣例的大規模基準，涵蓋五大具有挑戰性的任務，分別是Visual RAG， Needle-in-a-Haystack，Many-Shot ICL，Summarization和Long-Document VQA。
這些任務旨在從多角度考察Long-Context VLMs (LCVLMs)對長文字下游任務的理解能力，提供一個完整詳細的評估。
MMLongBench充分利用了現有的高質量多模態資料資源，系統性地篩選和整合了16個公開的、多樣化的多模態資料集。所有問題和答案均來源於原始資料集。為了支援長上下文能力的評估，作者對原始資料進行了上下文長度控制，將原本較短的樣本擴充套件至8K-128K token的上下文長度，並將較長樣本進行截斷，以適配不同長度的測試需求。
例如在Visual RAG任務中，研究團隊從Wikipedia中檢索與問題相關的段落，將其拼接為長上下文，以模擬真實的Visual RAG應用場景。同時，在summarization任務中，作者選用長PDF文件作為輸入，並對文件末尾進行截斷，以滿足不同上下文長度的需求。
跨模態長度控制
現有多模態長文字資料集通常以圖片數量作為樣本長度的衡量標準，而忽略了不同圖片的尺寸差異以及問題中的文字內容。為了統一不同資料集的樣本長度，MMLongBench將文字Token和圖片patch共同計入總輸入長度，而不是僅以圖片數量粗略衡量樣本長度。
具體來說，作者採用Llama2的分詞器計算文字token數量，並將每張圖片劃分為14×14的patch，同時應用2×2的pixel unshuffle操作以壓縮視覺token數量。這種處理方式相容當前主流的多模態大模型，例如Qwen2.5-VL和InternVL3，能夠更真實地反映不同樣本的實際輸入長度，也使跨資料集的評估更加公平和標準化。
同時，MMLongBench為每個樣本都提供了8K、16K、32K、64K和128K五種長度的上下文，便於分析模型在不同長度下的表現變化。此外，這一設計也支援進一步擴充套件至更長的輸入長度，滿足未來模型發展需求。
總體來說，透過多工的資料構建和跨模態長度控制，MMLongBench為當前多模態大模型的長文字能力提供了更加完整和細緻的評估。以下是MMLongBench和現有資料集的對比:
效能評估
研究團隊對46個領先的LCVLMs進行了全面評估，其中包括閉源模型Gemini-2.5-Pro、GPT-4o、Claude-3.7-Sonnet，以及多種開源模型，例如Qwen2.5-VL-72B、InternVL3-38B。結果發現，無論是閉源還是開源的多模態大模型，在長上下文視覺-語言任務上都面臨較大挑戰，仍有巨大的提升空間。
發現1：所有模型在長上下文視覺-語言任務上都面臨較大挑戰
總體來看，所有模型在長上下文任務上都表現不佳。在128K token長度下，InternVL3-38B、Qwen2.5-VL-72B和Gemma3-27B這些頂尖的開源多模態大模型獲得的平均分僅為49.8、48.7和51.2。GPT-4o的平均分也只有62.9，並且得分最高的閉源模型Gemini-2.5-Pro也沒有超過80分。
發現2：推理能力更強的模型往往在長上下文任務中表現得更好。
團隊在評測中引入了 Gemini-2.0-Flash-T (gemini-2.0-flash-thinking-exp-01-21)，它是 Gemini-2.0-Flash 的推理版本。從結果來看，推理能力能夠在所有任務上持續提升 Gemini-2.0-Flash的表現。在summarization和DocVQA任務上的提升則分別達到了25.3%和10.1%。此外，Gemini-2.5系列模型作為原生的推理模型，表現則更為強勁。
發現3：單一任務的效能難以有效反映模型的整體長上下文能力
基於模型的分數，研究團隊計算了不同任務之間的 Spearman 相關係數。結果發現，不同類別之間的相關性普遍不高（低於0.85）。這表明，僅依賴單一任務的效能難以全面反映模型的整體長上下文理解能力，也進一步證明了MMLongBench採用多樣化下游任務進行評估的必要性。
錯誤分析 (Error Analysis)
研究團隊進一步針對模型在Long-Document VQA和Visual RAG任務上的表現進行了分析。
1. OCR能力是處理長文件輸入時的瓶頸
研究人員將PDF格式的文件透過OCR技術轉化為純文字（w/ OCR），再輸入到模型當中。總體來看，使用影像格式的PDF文件輸入和OCR提取的純文字輸入並沒有絕對的優劣。Qwen2.5-VL系列模型在大多數情況下對影像格式的PDF文件處理效果更佳，而Gemma3-27B則在較短輸入長度（≤ 32K）時更偏好純文字。
此外，研究團隊還根據答案來源將樣本細分為兩類：純文字 (text-pure) 和需要視覺理解 (vision-needed) 的樣本。結果顯示，在需要視覺理解 (vision-needed) 的樣本上，模型使用影像格式的PDF文件輸入能夠獲得更高的分數；而在純文字 (text-pure) 樣本上，尤其是在64K和128K的長輸入下，OCR提取的純文字輸入能帶來更好的效果。同時，當使用OCR提取的文字時，將LCVLMs替換為相應的純文字大語言模型 (Qwen2.5-7B和Qwen2.5-32B，圖中為w/ LLM），在text-pure樣本上能獲得更好的效果。
這表明，當前LCVLMs在處理長文件輸入時，OCR能力仍然是一個瓶頸。未來的工作可以考慮結合兩種輸入以進一步提升效能。
2、跨模態檢索能力限制長文字表現
研究團隊還對現有模型在Visual RAG任務中的錯誤來源進行了分析。研究團隊將ViQuAE (Visual RAG任務中的資料集) 中的圖片替換為對應命名實體的名稱，從而所有樣本都變為純文字輸入 (w/ name)。將這些純文字的問題輸入到LCVLMs中，結果顯示，所有模型的表現都有不同程度的提升，其中Gemma3-27B在128K長度下提升最大，達到了26.4。這表明現有的LCVLMs在跨模態資訊檢索方面存在瓶頸限制長文字能力。
此外，將這些問題輸入到Qwen2.5-VL對應的LLMs當中 (Qwen2.5-7B和Qwen2.5-32B，圖中為w/ LLM), 也能提升模型表現。這說明在LCVLMs訓練過程中，多模態能力與純文字的長上下文能力之間存在tradeoff。
論文：https://arxiv.org/abs/2505.10610主頁:https://zhaowei-wang-nlp.github.io/MMLongBench-page/程式碼:https://github.com/EdinburghNLP/MMLongBench資料集:https://huggingface.co/datasets/ZhaoweiWang/MMLongBench
一鍵三連「點贊」「轉發」「小心心」
歡迎在評論區留下你的想法！
— 完 —
🌟 點亮星標 🌟