【免费下载链接】ExtractBench
做文档信息抽取（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 大字段总览：谁负责什么
| # | 字段 | 类型 | 一句话说明 |
|---|---|---|---|
| 1 | id | string | 测试用例唯一标识，格式<split>/<stem> |
| 2 | category | string | 分割名：short/medium/long |
| 3 | pdf | string | 源 PDF 的相对路径 |
| 4 | data_schema | string | JSON 编码的JSON Schema，输出必须通过它的校验 |
| 5 | expected_output | string | JSON 编码的标准答案（ground truth） |
| 6 | field_rules | string | JSON 编码的逐字段评分规则 |
| 7 | repeated_structure | string | JSON 编码的记录身份键配置（用于数组对齐） |
| 8 | tags | string[] | 多维标签数组，支持切片分析 |
按职责可以分三组：
- 🎯输入侧（
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 中每个字段路径映射到一条评分规则，决定"什么才算对"：
| 子字段 | 含义 |
|---|---|
comparator | 比较方式：exact、case_insensitive、number、date、boolean、enum等 |
evidence | 所有可接受的读法及出处，存为{page, bbox, quote, value}；任一可接受读法都算正确 |
source_policy | 该值是否必须逐字出现在原文中 |
evidence_required/verified | 是否存在 grounding 证据，以及是否经过人工核验 |
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 的规模速览
| 分割 | 测试案例数 | 页数 | 每篇页数 |
|---|---|---|---|
| short.jsonl | 252 | 615 | ≤ 10 |
| medium.jsonl | 98 | 2,438 | 11–50 |
| long.jsonl | 20 | 1,816 | > 50 |
写在最后
把 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——你会发现评分规则比想象中细致得多。
【免费下载链接】ExtractBench
相关推荐
skill-creator 数据契约全解：evals、grading、benchmark 等 8 个 JSON Schema 的字段规范与实战消费链路
skill creator 数据契约全解：evals、grading、benchmark 等 8 个 JSON Schema 的字段规范与实战消费链路 本指南以
AI 插件开发工具插件系统GSM8K-in256-bs1数据格式深度解析：in256与bs1参数、JSON/JSONL字段逐个拆解
GSM8K in256 bs1数据格式深度解析：in256与bs1参数、JSON/JSONL字段逐个拆解 想搞清楚 GSM8K in256 bs1 数据格式 长
olmOCR-bench数据结构全解析：7大类别测试集与JSONL字段逐行讲解
olmOCR bench数据结构全解析：7大类别测试集与JSONL字段逐行讲解 olmOCR bench 是 AI2 开源的 OCR 评测基准数据集 ，包含 1
数据集AI 评测模型评测人工智能OCR
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
