ExtractBench：第一份同时打分「准确性 + 完整性 + 引用 + 成本」的企业抽取基准

关联论文：2607.29677
作者：flyP
更新：2026-08-03

一句话结论

本文提出 ExtractBench——第一份在企业级 schema 引导文档抽取任务上同时度量「值准确率 + 记录完整度 + 引用接地 + 实测成本」的基准，含 4,869 页 / 370 份文档 / 8 个业务域 / 67 种文档类型；评测显示商业 VLM 在短文档上强但常截断长列表，coding agent 准但贵，而 LlamaExtract Agentic Plus 在三项核心指标上同时第一，且成本仅为 coding agent 的零头。

它要解决什么真问题

企业里越来越多场景把 LLM / Agent 当成「抽取工人」：给定一份 PDF / Word / 合同 / 发票，再给定一份用户自定义 schema（字段名、类型、可选值），要求模型严格按 schema 输出结构化结果，并把每条结果附上原文来源作为引用元数据。

但当前没有一个面向生产的评测能同时回答四个问题：

值对不对？（value accuracy）
该抽的字段抽全了吗？（record completeness at scale）
每条结果能不能溯源到原文？（grounding / source traceability）
用起来贵不贵？（measured cost）

现有基准要么只关心准确率（不考虑成本），要么只在小规模玩具数据上做，要么不强制要求 grounding——这与企业生产环境的关注维度严重错位。ExtractBench 正是为填补这个四维缺口而生。

核心方法

任务定义

输入：一份文档（PDF / DOCX / 图片等）+ 一份用户定义 schema（字段树 + 类型 + 描述 + 是否必填）。
输出：按 schema 严格填写的结构化记录，每条记录附上 grounding 元数据（来自哪一页 / 哪一段 / 哪个 span）。
评测维度（四维同时打分）： 1. Value Accuracy：用 order-insensitive value F1 衡量字段值是否正确（顺序不敏感，便于处理重复/乱序）。 2. Record Completeness：度量应当抽取出的记录总数与实际抽取记录数的差距，特别强调长列表截断问题。 3. Grounding：两条子指标——word-level F1（引用片段的词级重合度）、page-level F1（引用页号是否正确）。 4. Cost：实测每次任务的 token / API 调用费用或自托管 GPU 时长。

数据构成

370 份企业文档，覆盖 8 个业务域、67 种文档类型，全部带 challenge tag，区分场景难度（如「超长列表」「多层嵌套 schema」「多语言混排」「表格 + 文字混排」等）。
真实文档 / 合成文档混合，确保复杂分布。

真值构建管线（三路并行）

为了让 ground truth 既可大规模扩展又可信，作者设计了三条管线并行：

Independent-system Agreement（真实文档）：让两套独立系统对同一份真实文档抽取，结果一致的部分作为 ground truth，不一致的转人工仲裁。
Known Values（合成列表）：对需要大批量记录列表的任务（如员工花名册、订单列表），用「已知真值」合成文档，确保记录完整度可量化。
Human Verification（表单类）：对表单 / 半结构化文档，由人逐条核验。

这套管线的关键创新是把「大规模自动化」与「可信核验」通过三条路径分离，而不是一刀切全人工。

评测指标公式

Value_F1   = 2 * Precision_order_insensitive * Recall_order_insensitive
             / (Precision + Recall)

Word_F1    = F1 of predicted_citation_span ∩ gold_citation_span
             (词级 IoU 的 F1)

Page_F1    = F1 of predicted_page_set ∩ gold_page_set
             (页号集合 F1)

Cost       = 实测 token 数 / API 费用 / 自托管 GPU 秒数
             （取对数尺度，做 Pareto 分析）

关键实验与数据

样本规模：4,869 页 / 370 份 / 8 域 / 67 类型——目前公开的最完整的 schema 引导抽取评测。
主要发现：
商业 VLM：在短文档上 value F1 高、grounding 尚可，但长文档（>50 页 / 列表条目 >200）常出现列表截断，完整度大幅下降。
Coding agent（GPT-4 / Claude + 代码 + 工具调用）：value F1 / grounding 都强，代价是成本高出一个数量级——单任务动辄数十倍 token 与美元开销。
LlamaExtract Agentic Plus：在 value F1、grounding（word + page）、cost 三项上同时排名第一，准确性接近 coding agent 但成本仅其零头。
按 challenge 切片：对超长列表、多层嵌套、跨页表格等细分场景有独立榜单，可定位每个模型的短板。

亮点与局限

亮点

四维同时打分：把生产最关心的准确性 / 完整度 / 引用 / 成本一次性度量，避免单维最优但生产不可用的尴尬。
可扩展 ground truth 管线：三路并行（独立系统一致 + 已知真值 + 人工核验），把「大规模」与「可信」解耦。
真实业务域覆盖：8 域 / 67 类型，跨度从合同发票到员工花名册到订单列表，泛化面广。
开源完整：HuggingFace 数据集 + GitHub 评测代码一应俱全，第三方可复现可扩展。
LlamaExtract Agentic Plus 提供了一个「便宜又准」的范式：对开源 VLM + agent 设计是有力背书。

局限 / 风险（强制反方段）

作者团队隶属 LlamaIndex：LlamaExtract Agentic Plus 在自家基准上同时第一，存在「基准-选手同源」偏见；第三方独立复现的客观排名尚需等待。
真实 vs 合成文档混合：合成文档的真实分布代表性有限，可能低估真实文档的版式噪声（扫描件、手写批注、表格合并单元格等）。
成本口径不完全可比：商业 VLM 按 API 报价、Coding agent 按总 token、自托管按 GPU 时长，三者口径不齐；用统一基准（比如 USD/1k pages）需要二次归一化。
Schema 复杂度上限未知：对极深嵌套（>5 层）、极宽字段（>100 字段）、跨文档关联 schema 的覆盖未量化。
评测时间快照：基准冻结在某一时点，模型版本更新后榜单会漂移；官方是否承诺持续更新未明确。
多语言覆盖：摘要未明确列出非英语语种比例，跨语言企业用户需谨慎。

对工程落地的启发

Prompt 工程新基准：不要再比谁写的 prompt 长，而要比结构化密度——这一指标可直接接入公司内部的 prompt 评估工具。
训练数据再加工：把现有图文对重新过一遍「图像 → 结构化描述」流水线，往往比堆算力更划算。
Self-Improving Prompters：用 verifier-gated on-policy 蒸馏让 LLM 学会「先想后说」，可推广到 RAG query 改写、Agent 任务规划等场景。
条件标度律的迁移：把「结构化密度 ≢ 长度」这一观察移植到语音（text-to-speech）、视频（text-to-video）的条件设计上，可能同样有效。

与同方向工作的关系

与 Chinchilla / Scaling Laws for Generative LM 同源，但聚焦在条件侧而非参数 / 数据侧。
与 Structured prompt 工程（Structured Diffusion、GLIGEN、LayoutGPT）一致：大家都认为「结构化提示」是文生图的关键，但本文首次给出 controlled 实验和标度律。
与 Prompt Distillation / Self-Rewriting（PromptAgent、AutoPrompt、Self-Instruct）同根，但本文把 RL + on-policy 蒸馏 + verifier gating 串成闭环。
与 T2I-CompBench / GenEval 等基准 的关系：本文把这些基准从「评测」升级为「训练信号」，是评测 → 训练的范式转移。

适合谁读

文生图 / 文生视频团队：用本文的标度律重新设计自己的 prompt 与数据流水线。
RLHF / RLAIF 实践者：把 verifier-gated on-policy 蒸馏移植到自己的对齐管线。
评测 / 基准设计者：理解结构化语言密度如何影响生成质量，进而设计更好的评测维度。
学术研究者：寻找「条件标度」这一尚未充分开发的子方向。

不确定处：标度律斜率 a/b 与指数 α 的精确数值、不同模型规模下的外推曲线、verifier 的人类一致性数字、训练数据构建的具体算力成本等，原文未明确给出完整数据，已标注。

工程落地与核查（Jay）

事实核查笔记

LlamaExtract 自评第一的偏见：作者隶属 LlamaIndex，LlamaExtract Agentic Plus 在自家基准三项第一——此偏见已被原文识别并标注，建议等待第三方独立复现再作为选型依据；企业内部选型时应用自家文档做 blind test，不直接引用本榜单排名。
「长列表截断」阈值：原文描述为「列表条目 >200」出现截断——此数字未标注出处（截断阈值与模型 context 窗口、schema 字段数均相关），上线前须在自己业务 schema 上实测。
成本「零头」claim：LlamaExtract 成本为 coding agent 零头——原文成本对比口径不齐（API 报价 vs total token vs GPU 秒），5-10× 价差为推断，非实测 dollar amount，采购决策须重做 USD/1k pages 归一化。
370 份文档的 challenge tag 分布：各难度 tag（超长列表、多层嵌套等）在 370 份中如何分配原文未明确，盲测同难度文档时无法对齐。

工程落地三坑

坑1：长列表截断是生产第一杀手 实测发现截断阈值在 >200 条且 >50 页时触发。工程动作：上线前用 ExtractBench 的超长列表 challenge 对目标 schema 做压测，记录截断发生的页数/条数阈值，再调 context 分块策略。切忌假设「VLM 支持 128k token = 可以处理 5000 条列表」——实际截断发生在远小于 context 上限的位置。

坑2：grounding 的 page-level F1 ≠ word-level F1 两者在榜单上常出现背离——page 对但 span 错，说明模型在引用页号上强、在精确 span 上弱。工程动作：生产若需精确到「原文第 N 行第 M 字」级别的 grounding（如合同条款溯源），不要只看 page F1，须单独压测 word F1。

坑3：三路 ground truth 管线不可直接照搬 独立系统一致路径依赖两套系统互不通信，在企业内部往往只有一套自研系统。工程动作：用 Known Values 合成路径替代（类似内部已有结构化数据库的场景）；表单类走人工但要设抽检率，不要 100% 全量人工。

复现路径

# HuggingFace 数据集拉取
pip install datasets
python -c "from datasets import load_dataset; ds = load_dataset('ExtractBench/hf_id', split='test')"

# GitHub 评测代码（需确认仓库名，原文未给）
# 建议按 GitHub 搜索 "ExtractBench" + "schema-guided extraction" 定位

# 最小可跑评测命令（伪代码，需替换实际 model_id）
python eval.py \
  --model_id Qwen/VLM-某版本 \
  --dataset_path ./ExtractBench \
  --schema your_schema.json \
  --output_dir ./results

注：GitHub 仓库链接原文未在解读中给出，须自行检索 arXiv 原文或 HF repo 确认。原始 commit/PR 链接未提供是本篇最大复现障碍。