ExtractBench 数据集解剖：一行 JSONL 里的 8 个字段与 JSON Schema 定义完全详解

做文档信息抽取（Information Extraction）评测时，你是否想知道一个基准数据集到底长什么样？这篇文章带你逐字段拆解ExtractBench 数据集：它的每一行 JSONL 里藏着 8 个字段——从id到tags，再到 JSON Schema 定义与评分规则，帮你快速看懂这套 schema 引导式企业文档抽取基准的完整结构。

ExtractBench 数据集简介：什么是 Schema 引导式文档抽取

ExtractBench 由 LlamaIndex 团队发布（Apache 2.0 协议），面向企业真实文档的结构化抽取：给定一份完整文档（born-digital 或扫描件）和一个由用户书写的 schema，系统必须返回一份通过 schema 校验的 JSON 对象，并为每个值附上**页码 + 边界框（bbox）**作为证据。

数据集规模：

• 📄370 份文档、4,869 页，覆盖8 个业务领域（D1–D8）、67 种文档类型
• 每种文档类型有且仅有一份 schema，被该类型下所有文档共享
• 325 份真实文档 + 45 份合成长列表；134 份含扫描件、55 份含手写、38 份为退化重拍版本
• 任务挑战分三类：T1 长列表完整性、T2 大海捞针、T3 密集文档

数据集元信息定义在 eval.yaml，三份分割文件分别是 short.jsonl、medium.jsonl 和 long.jsonl，源 PDF 按分割存放在 docs/short/、docs/medium/、docs/long/ 目录下，完整说明见 README.md。

一行 JSONL 的完整解剖：先看整体结构

JSONL 的每一行 = 一个文档 + schema 测试用例。下面是 README.md 中 Dataset Format 一节给出的结构示例（字段顺序与实际数据一致）：

{ "id": "short/grafton_isotrope_invoice_19503", // 唯一用例 ID：<split>/<stem> "category": "short", // 分割名（short | medium | long） "pdf": "docs/short/grafton_isotrope_invoice_19503.pdf", // 源文档相对路径 "data_schema": "{...}", // JSON 编码的 JSON Schema "expected_output": "{...}", // JSON 编码的标准答案 "field_rules": "{...}", // JSON 编码的逐字段评分规则 "repeated_structure": "{...}", // JSON 编码的记录身份键配置 "tags": ["source:real", "challenge:T3.b", "length:short", "domain:D1"] }

8 大字段总览：谁负责什么

按职责可以分三组：

• 🎯输入侧（id/category/pdf）：告诉你文件在哪、属于哪个长度桶
• 📐任务与真值侧（data_schema/expected_output/field_rules/repeated_structure）：定义"要抽什么、什么算对、怎么对齐记录"
• 🏷️分析侧（tags）：低分时帮你定位原因出在哪个维度

前 3 个字段详解：id、category 与 pdf

id是全局唯一标识，格式为<split>/<stem>。以"short/grafton_isotrope_invoice_19503"为例：前半段是分割名，后半段就是源文件去扩展名后的文件名（stem），例如docs/short/grafton_isotrope_invoice_19503.pdf。这意味着通过id就能直接定位到源文档，不需要任何额外索引。

category只取三个值：short（L1，≤10 页）、medium（L2，11–50 页）、long（L3，>50 页），与 JSONL 所在文件一一对应，且始终与tags里的length标签一致。

pdf是相对仓库根目录的源文档路径，指向 docs/short/ 等目录下的真实 PDF。评测框架会按这个路径下载文档；本地查看某份样例时，可直接打开 docs/short/grafton_isotrope_invoice_19503.pdf 对照字段理解抽取任务。

4 个 JSON 编码字段：为什么 schema 要"藏"在字符串里

data_schema、expected_output、field_rules、repeated_structure四个字段存的都是JSON 编码的字符串，而不是结构化列。这是理解整个数据集的关键：

每种文档类型的 schema 完全不同——电费单、SEC 13F 持仓表、海关 7501 表、购房披露表的字段结构天差地别，没法用一张统一表格装下所有字段。因此这四个字段采用 JSON-in-string 的形式，加载后用json.loads解码即可。

这也是一个实用提醒：在最大的长列表文档里，单个field_rules可高达21 MB，所以在线数据集查看器只能显示单元格预览，完整数据以下载的 JSONL 文件为准。

data_schema：输出的 JSON Schema 定义

data_schema解码后就是一份标准JSON Schema，规定输出 JSON 的字段名、类型、必填项、数组元素结构等。系统的输出必须通过这份 schema 校验，否则直接判错——这正是"Schema-Guided"（schema 引导式）的含义：schema 既是任务说明书，也是输出的硬约束。

field_rules：逐字段评分规则

field_rules把 schema 中每个字段路径映射到一条评分规则，决定"什么才算对"：

evidence的设计很聪明：同一个值可能允许多种读法（比如日期写成2024-01-15或01/15/2024），标注时把每种可接受读法的页码、bbox、原文引文、规范化值都记录下来。这让评分既严格（值必须落在可接受集合内）又宽容（允许文档中真实存在的不同写法），同时天然支撑了 bbox 级别的 grounding 打分。

repeated_structure：重复记录的身份键

发票行项目、持仓列表这类"记录数组"是评分难点。repeated_structure为数组指定**身份键（identity key）**用于对齐期望记录。例如发票行项目可以用(description, amount)做身份键：预测记录与期望记录按键配对，数组顺序不影响得分。它同时记录列表的完整性要求——这正是 T1 长列表挑战"一条都不能少"的落点。

tags：多维标签，让低分可归因

tags是字符串数组，形如"source:real"、"challenge:T3.b"、"length:short"、"domain:D1"，采用前缀:值的统一格式，覆盖五个独立分析维度：

• challenge：T1.a–e长列表完整性 /T2.a–d大海捞针 /T3.a–e密集文档
• perception：P1旋转或纯图像 /P2扫描件 /P3手写
• structure：S1–S5各种表格结构难题（合并表头、跨页表格、超千行表格……）
• length：short/medium/long，恒与category一致
• domain：D1金融（145 份）→D8房地产（6 份）

此外还记录交付要求（G1–G4）与source（325 份 real / 45 份 synthetic）。一份文档可同时属于多个任务挑战，所以各挑战的文档数相加大于 370（总期望值 841,934 个，T1 一项就占 81 万+）。正因为维度独立，一个低分可以被精确归因——是长列表截断、表格跨页，还是扫描件识别出错。

如何加载与使用：3 行代码上手

用 Hugging Facedatasets库加载任意分割，每条记录就是一个上面的对象，四个字符串字段用json.loads解码即可：

from datasets import load_dataset import json ds = load_dataset("llamaindex/ExtractBench", split="short") case = ds[0] schema = json.loads(case["data_schema"]) expected = json.loads(case["expected_output"])

跑完整评测则用官方框架两条命令：uv run extract-bench download拉取data/<split>/<doc>.pdf与<doc>.test.json，再uv run extract-bench run <pipeline>完成推理、评测与报告。评分是完全确定性的——同一份预测与真值永远得到同一个分数，流程中不引入任何模型。

三个核心指标各回答一个问题：

• Unified value F1：提取的值对不对（标量字段与记录数组统一口径）
• Word-level grounding F1：值对，且预测 bbox 与该字段某个可接受 box 的 IoU ≥ 0.5
• Page-level grounding F1：至少把来源页找对

三个 split 的规模速览

写在最后

把 8 个字段串起来看：id/category/pdf指向输入，data_schema/expected_output/field_rules/repeated_structure定义任务与真值，tags负责切片归因。读懂这一行 JSONL，就理解了 ExtractBench 的全部评测逻辑——给定文档与 schema，返回 schema 合法的 JSON，值要全对、缺失要正确返回null、每个值都要有页码和 bbox 背书。

如果你想动手试试，可以克隆仓库后从 short.jsonl 的第一条记录开始，对照 docs/short/ 里的源 PDF 手工"抽"一遍，再回头读field_rules——你会发现评分规则比想象中细致得多。