企业官网建设流程全解析

从 HTML 到 OTSL：Docling 表格结构识别中的优化表结构语言解析

【免费下载链接】doclingGet your documents ready for gen AI项目地址: https://gitcode.com/GitHub_Trending/do/docling

本仓库tests/data/pdf/groundtruth/2305.03393v1.md保存的是 arXiv 论文Optimized Table Tokenization for Table Structure Recognition（IBM Research，2023）经 Docling 文档管线转换出的 Markdown Groundtruth。这篇论文提出的OTSL（Optimized Table Structure Language）正是 Docling 表格结构识别（Table Structure Recognition, TSR）环节所依赖的核心表示语言：Docling 通过 TableFormer 系模型把"表格图片 → 结构序列"建模为序列生成任务，并直接以 OTSL 序列作为模型输入输出与数据载体。阅读本文后，你将掌握 OTSL 的设计动机、5 个核心 Token 的编码语义、6 条向后校验语法规则、错误检测与纠正机制、论文报告的精度/推理耗时数据，以及 OTSL 在 Docling 源码中的真实落地形态，从而理解 Docling 表格提取链路的底层原理。

1. 文档溯源：这份 Groundtruth 从何而来

tests/data/pdf/groundtruth/2305.03393v1.md并不是一份原创技术文档，而是 Docling 对 arXiv 预印本2305.03393v1（cs.CV，2023-05-05）的标准 PDF 转 Markdown 导出结果。在该 Groundtruth 同目录下，还配套存放了同名的 JSON（含版式、单元格、边界框等结构信息）、.doctags.txt与.pages.meta.json等产物，形成一组可交叉验证的多格式 Groundtruth 集合：

• 源文件：tests/data/pdf/sources/2305.03393v1.pdf（论文原版 PDF，另有单页切片2305.03393v1-pg9.pdf）；
• 导出产物：tests/data/pdf/groundtruth/2305.03393v1.md、2305.03393v1.json、2305.03393v1-pg9.json等。

从源码角度可以确认这套数据的测试用途：多个后端测试（如 docling/models/…/managed_pdfium 的 test_backend_pdfium.py 与 test_backend_docling_parse.py）都会引用2305.03393v1-pg9.pdf页面来验证文本提取、旋转 OCR 定位等行为；它同时也是 Docling 输出"结构化 Markdown"这一格式的样例素材。换言之，这是一篇通过 Docling 标准 PDF 管线转写为 Markdown 的学术论文正文，论文主题恰是 Docling 表格结构识别所用语言——OTSL。

2. 论文背景：表格提取与表格结构识别（TSR）

论文的摘要指出，表格是科学论文、专利、报表、说明书、营销材料等文档中高价值信息的常见载体，必须高精度地抽取。表格外观千差万别（尺寸、样式、结构各异），纯解析方法难以恢复其真实结构，因此现代文档理解系统普遍采用机器学习方法。典型的表格抽取是两步式流程：

1. 表格检测（Table Detection）：先用目标检测在页面上定位出每个表格的包围框；
2. 表格结构识别（TSR）：识别表格的逻辑行、列与跨行跨列结构。

论文认为，表格检测在当代已接近人类水平，而 TSR 仍是活跃研究课题。针对 TSR 的深度学习方法可划分为三类：

• 目标检测（OD）方法：以（相互重叠的）包围框标注训练，输出单元/行/列的包围框；
• 图神经网络（GNN）方法：把表格建模为图，节点是单元格内容/图像嵌入/几何坐标，边表达"同列、同行、同一单元格"等关系；
• Image-to-Markup-Sequence（Im2Seq）方法：把问题变成序列生成任务，直接预测一段描述结构的标记序列（如 HTML、LaTeX、Markdown）。

Im2Seq 方法理论上天然具备"直接输出结构"的优势——无需像 OD/GNN 那样依赖后处理规则；但实践中预测出的标记序列未必语法正确，因此仍需后处理来保证输出的合法性。论文将研究落点放在表结构表示语言本身，在保持神经网络架构不变的前提下，考察"用更优的表示语言能否同时提升精度与推理速度"，并选取当时的 SOTA Im2Seq 模型 TableFormer（Nassar et al., CVPR 2022）作为实验载体。

3. HTML 表结构表示的三个硬伤

在 OTSL 出现之前，公开数据集（PubTabNet、FinTabNet）以 HTML 作为 Groundtruth 格式，主流 Im2Seq 模型也直接采用 HTML token 序列作为建模对象。论文从三个角度论证了 HTML 并不适合 Im2Seq：

3.1 Token 词表过大、分布极端倾斜

理论上<table>/<tr>/<td>等少量标签足以表达简单表格，但真实文档中的跨行（row-span）与跨列（col-span）需要将跨度的枚举词面展开。要把 PubTabNet 数据集中最常见的复杂表格全部覆盖，至少需要 28 个不同的 HTML token。且这些 token 的出现频率严重不均（论文图 2 的频次分布），自回归模型难以学好这种长尾分布。

3.2 序列长度长，行长度可变

每个单元格至少对应开闭两个 token（如<td>与</td>），还要为各种 span 显式添加额外词面，导致整体序列显著变长。Im2Seq 是逐 token 自回归生成，序列越长推理越慢、出错概率越大；而行与行之间的 token 数量随跨格情况剧烈波动，模型必须隐式学习"每行 token 数一致"这一未被任何语言结构显式保证的约束。

3.3 无法边生成边校验

理想的表示应当支持在序列尚未生成完时就即时发现非法 token。但 HTML 中开放/闭合标签必须满足层级匹配，且行、列长度需要在知道跨格信息后才能对齐，因此校验不完整序列非常困难甚至不可能。模型必须在训练中自己学会整套复杂语法，只为输出合法结果。

3.4 实际观测到的两种预测劣化

论文在实际训练中发现两大问题：

• 视觉注意力漂移（drift）：面对大表格，模型注意力不再按单元格顺序推进，表现为同一列靠后行的定位逐步偏移，甚至完全失去纵向对齐；
• 结构非法输出：模型输出存在结构矛盾或明显的非法 HTML，几乎无法纠正。

两者都会波及单元格内容的识别与匹配，严重拖累 TSR 质量。

4. OTSL：最小词表的表结构语言定义

为消除 HTML 的上述缺陷，论文提出Optimised Table Structure Language（OTSL），用"原子 2D 网格"上的少量符号直接刻画结构。其词汇表仅 5 个 Token：

OTSL 的关键属性是：在网格上按行主序（row-major）逐格写出，NL结束每一行；每个真实表格单元格对应一个C，跨格由其右方/下方的L、U、X表达。论文以 Fig.1 的复杂表为例对比：HTML 需 12 个 token、序列长 55，而 OTSL 只需 5 个 token、序列长 30；更重要的是OTSL 各行 token 数固定（每行都以NL终止、长度相等），内部结构远强于 HTML 的可变行长度。同时 OTSL 支持无损转换回 HTML，保证与现有数据集和下游消费方兼容。

5. OTSL 的六条语法规则

OTSL 的合法性由以下规则约束（以网格坐标理解最直观）：

1. 向左合并规则：L的左邻必须是另一个L或C；
2. 向上合并规则：U的上邻必须是另一个U或C；
3. 十字合并规则：X的左邻必须是另一个X或U，其上邻必须是另一个X或L；
4. 首行规则：第一行只允许L与C（第一行无上邻，天然不可能出现U/X）；
5. 首列规则：第一列只允许U与C（同理排除L/X）；
6. 矩形规则：表示永远是矩形，所有行 token 数必须相等并以NL收尾。

由这组规则推导出的三条性质，构成 OTSL 的价值核心：

• 严格矩形结构：所有行、列拥有完全一致的 token 数，与跨格无关，模型无需自行推断"何时换行才合法"；
• 无歧义（unambiguous）：每个表格结构有且仅有一种OTSL 表示，跨格单元格的C恒定位在结构左上角，编码解码互为确定；
• 纯向后校验（backward-looking）：每条规则的判定只依赖已生成的前缀序列，因此可以在自回归生成过程中对每一个新 token即时做语法校验，从而在结构上保证任何（经校验的）输出序列语法正确。

6. 生成期的错误检测与纠正

语法只保证"合法"，不保证"正确"——合法序列仍可能是错误的预测。OTSL 的优势在于把"检测非法 token"变成了前缀上的廉价操作：在一个未完成的序列上就能完成结构校验。论文给出了一种可用的在线启发式纠错：

若置信度最高的预测 token 会使当前前缀序列非法，则依次尝试置信度次高的 token，直到所选 token 使 OTSL 规则得到满足。

这类启发式既可在每个 token 预测后即时执行，也可在整个序列生成完毕后统一执行，从而把"后处理清非法输出"从不可控的 HTML 修复，降维为 OTSL 规则约束下的局部替换。

7. 实验设计与量化结论

论文基于 TableFormer 架构在两个层面评估 OTSL vs HTML：

实验设置：结构预测质量用 TEDs（Tree Edit Distance score，将 OTSL 结果转回 HTML 后计算）衡量，单元格包围框用 mAP@0.75 衡量；推理耗时统一在单核 AMD EPYC 7763 @2.45GHz 机器上测量。所有数据集的 Groundtruth 均转换为 OTSL 格式。

7.1 HPO 超参扫描（Table 1，仅 PubTabNet）

论文在 PubTabNet 上对不同编码器/解码器层数做超参优化，TEDs 按简单表/复杂表（含跨格）/全部三档报告：

从表可见：OTSL 在全部 TEDs 相当的前提下获得更高的 mAP，且推理约快 2 倍；同精度下模型可显著缩小编码器/解码器层数，配合 HPO 论文称最大可获得 5~6 倍的推理加速。注意这些是论文报告的实验数据（来自文档原文），直接搬用时应以论文为准。

7.2 跨数据集定量结果（Table 2）

取质量最佳的超参（enc=6、dec=6、heads=8），在三个公开数据集上独立训练与评测：

结论是：OTSL 在稀疏、大尺寸的金融表（FinTabNet）上优势尤其明显（complex TEDs 0.961 vs 0.922，mAP 0.862 vs 0.722）；在更大规模数据集 PubTables-1M 上进一步提升；同时因解码步数（序列长度）显著更少而获得稳定更快的推理。

7.3 定性结果

论文图 5、图 6 的可视化显示：OTSL 模型在稀疏表与超多行复杂表上产生更少重叠、更准的包围框，且能捕获 Groundtruth 中重复的水平合并模式；HTML 模型则出现框漂移、重叠甚至无法闭合的非法序列。这些定性证据直接呼应第 3 节对 HTML 局限性的分析。

8. OTSL 在 Docling 源码中的真实落地

该论文中的 OTSL 并非停留在纸面：Docling 的表格结构识别链路在工程上完整使用了它。下面结合源码说明它的具体位置与作用方式。

8.1 TableFormer 预测器：产出 OTSL 序列

Docling 默认的标准 PDF 管线中，负责表格结构识别的是 TableFormer（V1）模型，实现在 table_structure_model.py 的TableStructureModel.predict_tables。其关键调用链是：

• 读取页面上已被布局模型标为TABLE/DOCUMENT_INDEX的聚类（cluster），按self.scale = 2.0（即放大到约 144 dpi）切出表格区域；
• 从后端（PDFium / docling-parse 等）取回该区域的 word 级文本单元作为tokens；
• 调用第三方推理器docling_ibm_models中的TFPredictor.multi_table_predict(...)（依赖声明见 pyproject.toml 中的docling-ibm-models>=3.13.0,<5）；
• 从返回的predict_details中取出num_rows、num_cols与prediction.rs_seq，即模型预测出的 OTSL 行序列（详见 table_structure_model.py 中otsl_seq = table_out["predict_details"].get("prediction", {}).get("rs_seq", [])）。

8.2 Table 数据模型：otssl_seq 是一等字段

Docling 的页面级数据模型 base_models.py 中，Table直接声明了otsl_seq: list[str]、num_rows、num_cols、orientation、table_cells等字段。也就是说，OTSL 序列本身是 Docling 中间表示的一等公民，随后由页面组装、导出等阶段消费（例如 page_assemble_model.py 在组装文档元素时会为部分对象构造otsl_seq=[]，VLM/实验管线也会把表格区域标记为otsl，见 threaded_layout_vlm_pipeline.py 中Replace TABLE by otsl for consistency with doctags）。这印证了论文所述"预测的 OTSL 结构会再转回 HTML/Markdown 等格式对外输出"的闭环设计。

8.3 可选模型族：TableFormer V2 与 VLM 输出的 OTSL

除 TableFormer V1 外，仓库还提供多种以 OTSL 为输出的表格结构模型：

• TableFormer V2（table_structure_model_v2.py）：模型仓库docling-project/TableFormerV2，通过docling_ibm_models.tableformer_v2.TableFormerV2.from_pretrained加载；
• Granite Vision 表格模型（table_structure_model_granite_vision.py）：模型输出被<otsl>...</otsl>包裹的文本序列，由_parse_otsl_output解析为(otsl_seq, table_cells, num_rows, num_cols)四元组，其中otsl_seq是"裸标签名列表"，例如["ched", "ched", "nl", "fcel", "fcel", "nl"]（这是 VLM 视角下的 OTSL 变体词表，其具体符号到论文 C/L/U/X/NL 的映射由相应模型约定决定）。

8.4 配置项：准确率/速度的取舍与单元格匹配

Docling 把"用哪种 TableFormer、跑多快"暴露为可配置项（pipeline_options.py）：

• TableFormerMode枚举（fast/accurate）：fast优先速度，适合简单表格或高吞吐批量场景；accurate提供更高质量、更慢，生产环境推荐（CLI 默认值即为TableFormerMode.ACCURATE，见 cli/main.py）；
• TableStructureOptions：默认实现kind="docling_tableformer"，含do_cell_matching（默认True）与mode（默认accurate）两个关键参数。do_cell_matching开启时模型会把预测的表格结构与 PDF 原始单元格内容对齐匹配，提升"结构 ↔ 文本"的对应准确度；
• 在 table_structure_model.py 中，accurate/fast分别加载model_artifacts/tableformer/{accurate|fast}目录下的权重，tm_config.json会声明模型类型等元数据。需要指出，Docling 实现为了稳定性会在 MPS 设备上回退到 CPU（源码注释"Disable MPS here, until we know why it makes things slower"）。

把第 8 节与论文第 7 节的实验对照即可看出：OTSL"短序列 + 纯向后校验 + 矩形结构"的理论优势，在 Docling 中被转化成了**数据模型字段（otsl_seq）、推理器输出契约（rs_seq）与多档模型选项（fast/accurate）**这些具体的工程抽象。

9. 小结

OTSL 的核心设计哲学可以浓缩为三点：用极小词表约束解空间、用矩形结构消除行长度不确定性、用向后规则把语法校验变为在线可执行的廉价操作。论文通过 TableFormer 在 PubTabNet、FinTabNet、PubTables-1M 上的对照实验，展示了同架构下约 2 倍的推理加速、跨格表格上更稳的 mAP 以及近乎为零的结构后处理负担。而在本仓库中，这套思想已通过otsl_seq字段、TableFormer 预测器、TableStructureOptions（fast/accurate、do_cell_matching）等源码结构融入 Docling 的日常表格提取流程——你看到的 2305.03393v1.md 这份 Groundtruth，既是该论文思想的文字载体，也是 Docling 自身 PDF→Markdown 能力的直接产物。若希望继续深入，建议依次阅读同目录下的2305.03393v1.json（结构化标注）、table_structure_model.py（TableFormer V1 推理全流程）与 pipeline_options.py（表格模型的可配置项），即可从"表示语言 → 模型 → 配置"三个层次完整打通 Docling 的表格结构识别链路。

【免费下载链接】doclingGet your documents ready for gen AI项目地址: https://gitcode.com/GitHub_Trending/do/docling