多模态长文档新基准来了！20多项任务覆盖理解推理定位

LongDocURL团队 投稿
量子位 | 公众号 QbitAI

GPT-4o仅得分64.5，其余模型均未及格！
全面、细粒度评估模型多模态长文档理解能力的评测集来了～
名为LongDocURL，集成了长文档理解、数值推理和跨元素定位三个主任务，并包含20个细分子任务。


添加图片注释，不超过 140 字（可选）
LongDocURL主打多模态、长上下文，专注于篇幅在50～150页的英文文档，平均页数和文档标记数分别为85.6和43622.6。
数据质量也很高，经过了模型自动验证和人工验证，包括21位全职外包标注员和6位经验丰富的硕博研究生的监督。


△图1 新Benchmark与其它数据集在单文档平均页数、文本标记数上的比较


△图2 新Benchmark与其它文档理解基准的比较。(U) 理解任务、(R) 推理任务和 (L) 定位任务
这项工作由中科院自动化研究所刘成林课题组和淘天集团算法技术-未来生活实验室团队合作完成。


添加图片注释，不超过 140 字（可选）
团队在多模态输入和纯文本输入共26种配置下全面评估了国内外主流的开源和闭源大模型。
目前在评测集上GPT-4o排第一，但也仅刚过及格线，正确率64.5。


添加图片注释，不超过 140 字（可选）
更全面细粒度的评估任务分类标准
大型视觉语言模型 (LVLMs) 显著提高了文档理解能力，能够处理复杂的文档元素、更长的上下文和更广泛的任务。
然而，现有的文档理解基准仅限于处理单页或少页文档，也未提供模型对文档布局元素定位能力的全面分析。
本文研究团队指出了现有文档理解基准的一些局限性：
复杂元素：大多数基准未能涵盖段落、标题、表格和图形等所有元素，而是仅关注部分内容。此外，关于不同元素之间相互关系的讨论很少。长上下文：当前的多页文档问答基准，例如 MPDocVQA 和 DUDE ，不评估超过 20 页的文档。虽然 MMLongBench-Doc 收集了较长的文档，但它仅提供了大约 1k 个有效样本，只有大约 30% 的问题涉及跨页信息。更多样的任务：现有工作更多侧重于OCR或简单的问答任务，而忽略了跨元素定位任务等其他领域能力的探索。这表明，现有基准落后于模型的进步，可能会阻碍文档理解的发展。
那么，LongDocURL究竟新在哪，又难在哪？
团队首先定义了三个主任务类别：
1）理解(Understanding)：通过识别关键字、解析表格结构等从文档中提取信息。答案直接在文档中找到。
2）数值推理(Numerical Reasoning)：通过计数 (count)、计算 (calculate)、比较 (compare) 和总结 (summarize) 来处理文档中的数值信息。在提取信息的基础上进一步推理才能得出正确答案。
3）跨元素定位(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 细粒度分析
任务类型：
（1）专有LVLM在推理和定位任务上的表现相当，但图像到文本的转换对推理能力的影响更大。例如，切换到文本输入，GPT-4o的推理分数下降了31.6分，而定位分数下降了22.4分。
(2) 强模型在推理和定位方面表现均衡，而较弱的模型在定位方面表现不佳，这表明在定位任务中，训练的重点是理解和推理能力，而不是空间和逻辑关系。
文档元素：
模型在文本问题上的得分最高，在表格问题上的得分最低，凸显了文档结构解析方面的不足。图形和布局问题类型的得分相似。跨元素任务的分数介于单页和多页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