GPT-4o僅得分64.5，其余模型均未及格！

全面、細粒度評估模型多模態長文檔理解能力的評測集來了～

名為LongDocURL，集成了長文檔理解、數值推理和跨元素定位三個主任務，并包含20個細分子任務。

LongDocURL主打多模態、長上下文，專注于篇幅在50～150頁的英文文檔，平均頁數和文檔標記數分別為85.6和43622.6。

數據質量也很高，經過了模型自動驗證和人工驗證，包括21位全職外包標注員和6位經驗豐富的碩博研究生的監督。

△圖1 新Benchmark與其它數據集在單文檔平均頁數、文本標記數上的比較

△圖2 新Benchmark與其它文檔理解基準的比較。(U) 理解任務、(R) 推理任務和 (L) 定位任務

這項工作由中科院自動化研究所劉成林課題組和淘天集團算法技術-未來生活實驗室團隊合作完成。

團隊在多模態輸入和純文本輸入共26種配置下全面評估了國內外主流的開源和閉源大模型。

目前在評測集上GPT-4o排第一，但也僅剛過及格線，正確率64.5。

更全面細粒度的評估任務分類標準

大型視覺語言模型 (LVLMs) 顯著提高了文檔理解能力，能夠處理復雜的文檔元素、更長的上下文和更廣泛的任務。

然而，現有的文檔理解基準僅限于處理單頁或少頁文檔，也未提供模型對文檔布局元素定位能力的全面分析。

本文研究團隊指出了現有文檔理解基準的一些局限性：

• 復雜元素：大多數基準未能涵蓋段落、標題、表格和圖形等所有元素，而是僅關注部分內容。此外，關于不同元素之間相互關系的討論很少。
• 長上下文：當前的多頁文檔問答基準，例如 MPDocVQA 和 DUDE ，不評估超過 20 頁的文檔。雖然 MMLongBench-Doc 收集了較長的文檔，但它僅提供了大約 1k 個有效樣本，只有大約 30% 的問題涉及跨頁信息。
• 更多樣的任務：現有工作更多側重于OCR或簡單的問答任務，而忽略了跨元素定位任務等其他領域能力的探索。這表明，現有基準落后于模型的進步，可能會阻礙文檔理解的發展。

那么，LongDocURL究竟新在哪，又難在哪？

團隊首先定義了三個主任務類別：

理解 (Understanding)：通過識別關鍵字、解析表格結構等從文檔中提取信息。答案直接在文檔中找到。

• 數值推理 (Numerical Reasoning)：通過計數 (count)、計算 (calculate)、比較 (compare) 和總結 (summarize) 來處理文檔中的數值信息。在提取信息的基礎上進一步推理才能得出正確答案。
• 跨元素定位 (Cross-element Locating)：團隊注意到，建立一個任務來評估模型分析不同類型元素之間關系的能力本來是很重要的，但是以前的研究在這方面的關注很少。

例如，在段落標題定位任務中，模型必須總結相關章節以識別與給定摘要匹配的部分，然后確定段落與其章節標題之間的關系。此任務需要在回答過程中切換元素類型（即段落到標題）。

△圖3 三類任務問答對示意圖。

（上）文檔樣例的縮略圖。橙色框表示答案證據頁面。（下）從文檔生成的數據示例和答案證據頁面相關部分的截圖。

團隊根據不同的主任務類別和答案證據，將數據集進一步細分為 20 個子任務。

首先，每個問答對都可以根據三個主任務進行分類：理解、推理和定位。其次，根據元素類型定義四種類型的答案證據：

• 文本 (Text)：純文本，例如段落；
• 布局 (Layout)：具有特殊布局含義的文本元素（Generalized Text），例如標題、頁眉、頁腳、表名和圖名；
• 圖 (Figure)：包括圖表 (Chart) 和一般圖像 (Image)。
• 表格 (Table)。

此外，每個問答對可以根據答案證據頁數分為單頁或多頁，根據證據元素類型的數量分為單元素或跨元素。

△圖4 任務分類體系。

內環：按主要任務類別（理解、推理和定位）劃分。中環：按答案證據頁數（單頁、多頁）和證據元素類型數量（跨元素）劃分。外部：按證據元素類型（文本、表格、圖形、布局）劃分。

半自動化數據構造流程

為了高效、低成本構建LongDocURL的評估數據集，團隊設計了一個由四個模塊組成的半自動化流程。

△圖5 構建流程概述。

該流程包含四個模塊：(a) 提取和過濾；(b) QA 生成；(c) 自動驗證；(d) 人工驗證

首先，提取和過濾模塊 (Extract&Filter module) 從不同的文檔源中挑選豐富布局且長度合適的文檔，并用Docmind工具獲得 “text-type-bbox” 三元組符號序列。

其次，問答對生成模塊 (QA Generation module) 基于三元組符號序列和強模型（如GPT-4o），多步驟迭代提示生成具有證據源的問答對。

最后，自動驗證 (Automated Verification module) 和人工驗證模塊 (Human Verification module) 確保問答對的質量。

通過這個半自動化流程，團隊最終生成了 2,325 個問答對，涵蓋了超過 33,000 頁的文檔。

長上下文理解能力綜合評估

主實驗

△圖6 歸一準確度分數（0~1）。

任務分為 3 種類型：理解（U）、推理（R）和定位（L）。證據元素分為 4 種類型：純文本（TXT）、布局（LAY）、圖表和圖像（FIG）和表格（TAB）。證據頁數/元素分為 3 種類型：單頁（SP）、多頁（MP）和跨元素（CE）。CTi：跨標題，CTa：跨表格，PTi：副標題，FTa：圖表-表格。得分最高的模型以綠色突出

關于 LVLMs，團隊得出以下結論：

（1）得分最高的模型：只有 GPT-4o 及格，獲得 64.5 分，這表明 LongDocURL 對當前模型是一大挑戰。

（2）開源和閉源模型的比較：閉源模型與開源模型相比表現出更好的整體性能。在開源模型中，只有 Qwen2-VL（得分30.6）和 LLaVA-OneVision（得分22.0和25.0）的得分超過 20，而其他參數少于 13B 的模型都低于此閾值。

為了比較使用文本輸入和圖像輸入的模型性能，團隊加了O1-preview和Qwen2.5系列。

實驗結果表明，LLM的總體得分明顯低于LVLM，最高LLM得分落后最高LVLM得分約30分。

團隊分析，這一差距主要是因為使用PyMuPDF解析為純文本時丟失了重要的文檔結構信息。考慮到我們的數據集包含大量與表格和圖表相關的問答對，結構信息的丟失阻礙了LLM提取關鍵證據的能力。這些結果凸顯了 LongDocURL作為評估LVLM文檔結構解析能力的基準的重要性。

細粒度分析結果

團隊挑選了3個閉源和開源模型，根據文檔來源、任務類別、文檔元素和證據頁對實驗結果進行了更細粒度的分析。

△圖7 細粒度分析

任務類型：

專有LVLM在推理和定位任務上的表現相當，但圖像到文本的轉換對推理能力的影響更大。例如，切換到文本輸入，GPT-4o的推理分數下降了31.6分，而定位分數下降了22.4分。

強模型在推理和定位方面表現均衡，而較弱的模型在定位方面表現不佳，這表明在定位任務中，訓練的重點是理解和推理能力，而不是空間和邏輯關系。

文檔元素：

模型在文本問題上的得分最高，在表格問題上的得分最低，凸顯了文檔結構解析方面的不足。圖形和布局問題類型的得分相似。跨元素任務的分數介于單頁和多頁QA之間，與整體評估緊密相關。

單頁與多頁：

單頁QA準確率低于多頁QA。這表明一些問題的答案可以從多頁中收集，從而降低了難度。然而，像GPT-4o和Qwen-VL-Max這樣的模型在多頁QA上的準確率較低，表明矛盾的是，他們在多頁QA中的定位任務得分較低，從而影響了整體表現。

輸入方式消融實驗

為了探索長文檔問答中的最佳輸入格式，團隊在兩種圖像輸入和兩種文本輸入范式中進行了消融實驗。

圖像輸入范式包括：(1) 截斷 (cut-off)，主實驗的配置，以及 (2) 合并 (merge)，將文檔圖像從原始文檔長度（50~150）組合成20~30張新圖像。

團隊注意到，表格結構信息在PyMuPDF解析時會顯著降低，而Docmind解析的markdown格式表格文本保留了更高的結構完整性。為了評估結構信息丟失對模型性能的影響，團隊對兩種輸入類型進行了實驗：docmind解析文本輸入、pymupdf解析文本輸入。

△圖8 輸入方式消融實驗

文本輸入vs.圖像輸入：截斷范式中的分數高于文本輸入-pymupdf范式中的分數，但低于文本輸入-docmind范式中的分數，表明該方法可以有效提取表格結構信息，但可以進一步改進。

截斷vs.合并：合并方法通過連接多個圖像保留了更多的上下文標記，而截斷方法通過縮短上下文窗口成功獲取了先驗信息。實驗結果表明，截斷可能比合并產生更好的問題解決能力，為未來構建多模態檢索增強生成 (RAG) 系統提供了見解。

結構信息的影響：對于專有模型，使用Docmind的性能至少比使用 PyMuPDF高25分，而開源模型的差異為15分。缺乏表結構信息會嚴重阻礙開源和專有模型的性能。

Case Study

（a）錯誤的證據源

△圖9 示例1

（b）缺失證據源

△圖10 示例2

示例樣本

Understanding

△圖11 Understanding QA示例

Reasoning

△圖12 Reasoning QA示例

Locating

△圖13 Locating QA示例

論文鏈接：https://arxiv.org/abs/2412.18424
項目主頁：https://longdocurl.github.io/
數據集：https://huggingface.co/datasets/dengchao/LongDocURL