arXiv 2305.03393 第 9 页全解读：docling 基准数据中的 OTSL 与 HTML 表格结构识别对比实验

关联文档：tests/data/pdf/groundtruth/2305.03393v1-pg9.md（docling 仓库中的 PDF→Markdown 页面级 groundtruth）

本篇技术指南围绕 docling 仓库中的一份特殊"文档"展开——tests/data/pdf/groundtruth/2305.03393v1-pg9.md。它并非一篇项目使用手册，而是 docling 文档转换流水线的单页 PDF 转换基准（groundtruth）：对应学术论文《Optimized Table Tokenization for Table Structure Recognition》（arXiv 2305.03393，作者 Maksym Lysak 等）的第 9 页。通过逐行精读这份基准，读者能同时掌握三件事：① 该论文在 TableFormer 架构上对比 OTSL 与 HTML 两种表格结构序列语言的全部实验数据；② docling 如何用 *_pg9.md / .json / .doctags.txt 三元组基准来验证 PDF 转换质量；③ 论文所提出的 OTSL 语言如今如何落地于 docling 的表格结构识别模型（TableFormerV2）代码中。

一、这份"文档"在仓库中的真实身份：页面级转换基准

1.1 基准文件三元组与同源兄弟文件

该目录下围绕论文 2305.03393v1 共维护了两组 groundtruth：

• 整篇论文版：2305.03393v1.md、2305.03393v1.json、2305.03393v1.doctags.txt
• 单页（第 9 页）版：本关联文档 2305.03393v1-pg9.md 及其同名的 .json（结构化 DoclingDocument）与 .doctags.txt（Docling Tags 文本级标注）

它们共同对应的真实输入 PDF 位于 tests/data/pdf/sources/2305.03393v1-pg9.pdf 与 tests/data/pdf/sources/2305.03393v1.pdf。也就是说，任何对 docling PDF 后端（如 pypdfium2、docling-parse、PDFium）的回归测试，都可以拿"原始 PDF → 期望的 Markdown/JSON"做逐字断言。例如 tests/test_interfaces.py 中就通过 pdf_path = Path("./tests/data/pdf/sources/2305.03393v1-pg9.pdf") 引用该 PDF 进行转换；tests/test_backend_pdfium.py、tests/test_cli.py、tests/test_invalid_input.py、tests/test_threaded_pipeline.py 等文件也引用了 2305.03393v1 数据族。

1.2 论文 LaTeX 源也是仓库的一部分

值得强调的是，仓库中同时保存了这篇论文的完整 LaTeX 工程 tests/data/latex/sources/2305.03393/main.tex（标题即《Optimized Table Tokenization for Table Structure Recognition》），并配套 LNCS 宏包（llncs.cls）、参考文献（papers.bib、main.bbl）等。该目录还存放其 LaTeX→Docling 转换的 groundtruth：tests/data/latex/groundtruth/2305.03393_main.tex.itxt 与 .json/.md。因此这份第 9 页内容拥有双通道参照系：PDF 通道的 groundtruth 与 LaTeX 源码可相互校核——文章后续恢复出的实验表格即以此为依据。

二、实验背景：OTSL 是一种为 Im2Seq 表结构识别而生的紧凑序列语言

第 9 页是论文的实验章（Section 5）开端。要读懂它，先要明确 OTSL 的定位（据 main.tex 第 106-160 行）：

• 任务范式（Im2Seq）：仅凭表格图像，让 transformer 模型预测一段描述表结构的 token 序列（传统上为 HTML、LaTeX 等标记语言）。
• OTSL 的动机：HTML 序列在长表格上易出现"列漂移（column drift）"与结构非法输出；OTSL 将词汇表缩减为极少量 token，序列更短、结构更规整。
• OTSL 的三条性质：① 强制严格矩形结构，每行 token 数固定；② 表示无歧义，跨单元格（span）的 C token 恒位于其包围盒左上角；③ 语法规则只向后看（backward-looking），可一边解码一边校验每个 token，从而在推理期即时纠错。

第 9 页正文开篇的硬件与评测口径值得先抄录（本关联文档第 1 行）：所有推理耗时均在同一台机器的单核 AMD EPYC 7763 CPU @2.45 GHz 上测得；预测出的 OTSL 结构需先转回 HTML 再计算 TED 分数（这一口径与 main.tex 中 Section 5 的描述完全一致）。

三、Section 5.1：HPO（超参数优化）实验全解析

3.1 实验设计

论文选择 PubTabNet 做 HPO，因为其表格多样性高；同时把 TED 分数按 simple（简单表格）与 complex（含单元格跨度的表格）分开报告。核心结论（第 5 行原文语义）是：

在相同 TableFormer 架构上，OTSL 能达到与 HTML 相同的 TED 分数且 mAP 略优；同时 OTSL 将推理耗时相对 HTML 提速约 2 倍。

3.2 Table 1 数据还原

groundtruth 中 Table 1 以两行表头的原始形式保存（第一行标题、第二行单位/类别说明），随后四行数据把 OTSL 与 HTML 的指标对并排拼在一个单元格内。将其还原为可读的双语序列对比表如下：

# enc-layers	# dec-layers	语言	TEDs (simple)	TEDs (complex)	TEDs (all)	mAP (0.75)	推理耗时 (s)
6	6	OTSL	0.965	0.934	0.955	0.880	2.73
6	6	HTML	0.969	0.927	0.955	0.857	5.39
4	4	OTSL	0.938	0.904	0.927	0.853	1.97
4	4	HTML	0.952	0.909	0.938	0.843	3.77
2	4	OTSL	0.923	0.897	0.915	0.859	1.91
2	4	HTML	0.945	0.901	0.931	0.834	3.81
4	2	OTSL	0.952	0.920	0.942	0.857	1.22
4	2	HTML	0.944	0.903	0.931	0.824	2.00

上表两行一组对比，加粗项为 OTSL 中占优的 mAP 与推理耗时。该组数据与 LaTeX 源 main.tex 第 188-204 行的 tab:HPO 定义逐格一致，可互相校核。

3.3 从数据中读出的两个结论

1. 小模型 + OTSL 更具性价比：缩小编码器/解码器层数后（如 4/4、2/4），OTSL 模型在"识别复杂表格结构"上的退化明显小于 HTML 版，且始终保住更高的 mAP。
2. 耗时优势来自更短序列：4/2 配置下 OTSL 仅 1.22s 而 HTML 需 2.00s。事实上 main.tex 第 256 行进一步总结：OTSL 的序列更短使同配置推理约快 2 倍，若再叠加 HPO 压缩模型，可相对 HTML 达到约 5–6 倍的整体推理加速。

四、Section 5.2：跨数据集定量评估（Quantitative Results）

4.1 方法学与数据规模

第 9 页第 19-21 行交代了协议：先用 PubTabNet 单独训出预测质量最优的配置（enc=6, dec=6, heads=8），再分别在三个公开数据集上独立训练与评测：

• PubTabNet：约 395k 样本
• FinTabNet：约 113k 样本
• PubTables-1M：约 1M 样本

结论原文有三层：① OTSL 在三个数据集上全面优于 HTML，即便在表格稀疏且体型大的 FinTabNet 上也保持高 TEDs/mAP；② 在更大数据集（PubTables-1M）上 OTSL 相对 HTML 的优势进一步放大；③ 由于序列表示更短、解码步数更少，OTSL 推理更快。

4.2 Table 2 数据（仓库 LaTeX 源可补齐）

groundtruth 页只保留了 5.2 的文字部分（Table 2 的图形表在本页未以 Markdown 表格呈现），但仓库内 main.tex 第 215-225 行的 tab:HTMLvOTSL_precision 提供了 OTSL 侧完整数值，可据此补全三数据集下的对比证据：

数据集	语言	TEDs (simple)	TEDs (complex)	TEDs (all)	mAP (0.75)	推理耗时 (s)
PubTabNet	OTSL	0.965	0.934	0.955	0.880	2.73
FinTabNet	OTSL	0.955	0.961	0.959	0.862	1.85
PubTables-1M	OTSL	0.987	0.964	0.977	0.896	1.79

可见在数据量最大的 PubTables-1M 上，OTSL 取得最高 mAP（0.896）与最快单表推理（1.79s），印证了正文"更大数据集上优势更明显"的表述。

五、回到 docling：OTSL 基准背后的模型实现证据

学术基准并非孤立存在。在 docling 源码中，与 OTSL 直接相关的是表格结构识别模型 docling/models/stages/table_structure/table_structure_model_v2.py：

• 该模型类名为 TableFormerV2（docstring 见第 39 行），默认权重来自 docling-project/TableFormerV2；
• 预测流程里先"Decode tokens to OTSL sequence"（第 136、232 行注释），再"Build table cell structures from OTSL sequence and bboxes"（第 259 行），并明确指出解码产物为 fcel / ecel / nl / lcel / ucel / xcel 这类 OTSL 标签序列（第 264 行注释）；
• 即：论文第 9 页实验所验证的语言（OTSL）与其训练出的同源模型权重（TableFormerV2）已实际集成进 docling 的标准文档转换流水线，groundtruth 页面则负责守住"任意 PDF 页面都能被无损还原为结构化文档"这条质量底线。

六、如何自己验证：重跑一次第 9 页转换

仓库只读、不可修改，但你可以就地重放该基准对应的转换任务：

1. 以 tests/data/pdf/sources/2305.03393v1-pg9.pdf 为输入；
2. 参考文档 docs/usage/index.md 与 docs/concepts/serialization.md 完成 DocumentConverter 配置，导出 Markdown / JSON / Doctags 三种格式；
3. 与 tests/data/pdf/groundtruth/2305.03393v1-pg9.json、.md、.doctags.txt 对照，或直接运行引用该数据族的测试文件（如 tests/test_backend_pdfium.py）做回归校验。

这样就能亲手确认：docling 能把包含"双语并排数值、双层表头、超宽表格"的复杂学术页面，还原成可被二次解析的结构化数据——这正是仓库选择这一页作为 PDF 转换基准的原因所在。