从 HTML 到 OTSLDocling 表格结构识别中的优化表结构语言解析【免费下载链接】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 RecognitionIBM Research2023经 Docling 文档管线转换出的 Markdown Groundtruth。这篇论文提出的OTSLOptimized 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.03393v1cs.CV2023-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论文的摘要指出表格是科学论文、专利、报表、说明书、营销材料等文档中高价值信息的常见载体必须高精度地抽取。表格外观千差万别尺寸、样式、结构各异纯解析方法难以恢复其真实结构因此现代文档理解系统普遍采用机器学习方法。典型的表格抽取是两步式流程表格检测Table Detection先用目标检测在页面上定位出每个表格的包围框表格结构识别TSR识别表格的逻辑行、列与跨行跨列结构。论文认为表格检测在当代已接近人类水平而 TSR 仍是活跃研究课题。针对 TSR 的深度学习方法可划分为三类目标检测OD方法以相互重叠的包围框标注训练输出单元/行/列的包围框图神经网络GNN方法把表格建模为图节点是单元格内容/图像嵌入/几何坐标边表达同列、同行、同一单元格等关系Image-to-Markup-SequenceIm2Seq方法把问题变成序列生成任务直接预测一段描述结构的标记序列如 HTML、LaTeX、Markdown。Im2Seq 方法理论上天然具备直接输出结构的优势——无需像 OD/GNN 那样依赖后处理规则但实践中预测出的标记序列未必语法正确因此仍需后处理来保证输出的合法性。论文将研究落点放在表结构表示语言本身在保持神经网络架构不变的前提下考察用更优的表示语言能否同时提升精度与推理速度并选取当时的 SOTA Im2Seq 模型 TableFormerNassar et al., CVPR 2022作为实验载体。3. HTML 表结构表示的三个硬伤在 OTSL 出现之前公开数据集PubTabNet、FinTabNet以 HTML 作为 Groundtruth 格式主流 Im2Seq 模型也直接采用 HTML token 序列作为建模对象。论文从三个角度论证了 HTML 并不适合 Im2Seq3.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 LanguageOTSL用原子 2D 网格上的少量符号直接刻画结构。其词汇表仅 5 个 TokenToken语义合并方向CCell——一个新单元格可有内容也可无内容单元格的锚点span 情形下总位于单元格左上角LLeft-looking——与左邻单元格合并成跨格向左合并UUp-looking——与上邻单元格合并成跨格向上合并XCross——同时与左邻和上邻单元格合并同时向左、向上合并NLNew-Line——换行切到下一行行的终止符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 的合法性由以下规则约束以网格坐标理解最直观向左合并规则L的左邻必须是另一个L或C向上合并规则U的上邻必须是另一个U或C十字合并规则X的左邻必须是另一个X或U其上邻必须是另一个X或L首行规则第一行只允许L与C第一行无上邻天然不可能出现U/X首列规则第一列只允许U与C同理排除L/X矩形规则表示永远是矩形所有行 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实验设置结构预测质量用 TEDsTree Edit Distance score将 OTSL 结果转回 HTML 后计算衡量单元格包围框用 mAP0.75 衡量推理耗时统一在单核 AMD EPYC 7763 2.45GHz 机器上测量。所有数据集的 Groundtruth 均转换为 OTSL 格式。7.1 HPO 超参扫描Table 1仅 PubTabNet论文在 PubTabNet 上对不同编码器/解码器层数做超参优化TEDs 按简单表/复杂表含跨格/全部三档报告enc-layersdec-layers语言TEDs(simple)TEDs(complex)TEDs(all)mAP0.75推理时间(s)66OTSL0.9650.9340.9550.8802.7366HTML0.9690.9270.9550.8575.3944OTSL0.9380.9040.9270.8531.9744HTML0.9520.9090.9380.8433.7724OTSL0.9230.8970.9150.8591.9124HTML0.9450.9010.9310.8343.8142OTSL0.9520.9200.9420.8571.2242HTML0.9440.9030.9310.8242.00从表可见OTSL 在全部 TEDs 相当的前提下获得更高的 mAP且推理约快 2 倍同精度下模型可显著缩小编码器/解码器层数配合 HPO 论文称最大可获得 5~6 倍的推理加速。注意这些是论文报告的实验数据来自文档原文直接搬用时应以论文为准。7.2 跨数据集定量结果Table 2取质量最佳的超参enc6、dec6、heads8在三个公开数据集上独立训练与评测数据集语言TEDs(simple)TEDs(complex)TEDs(all)mAP0.75推理时间(s)PubTabNet (~395k)OTSL0.9650.9340.9550.8802.73PubTabNetHTML0.9690.9270.9550.8575.39FinTabNet (~113k)OTSL0.9550.9610.9590.8621.85FinTabNetHTML0.9170.9220.9200.7223.26PubTables-1M (~1M)OTSL0.9870.9640.9770.8961.79PubTables-1MHTML0.9830.9440.9660.8893.26结论是OTSL 在稀疏、大尺寸的金融表FinTabNet上优势尤其明显complex TEDs 0.961 vs 0.922mAP 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 管线中负责表格结构识别的是 TableFormerV1模型实现在 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-models3.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 V2table_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.pyTableFormerMode枚举fast/accuratefast优先速度适合简单表格或高吞吐批量场景accurate提供更高质量、更慢生产环境推荐CLI 默认值即为TableFormerMode.ACCURATE见 cli/main.pyTableStructureOptions默认实现kinddocling_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 预测器、TableStructureOptionsfast/accurate、do_cell_matching等源码结构融入 Docling 的日常表格提取流程——你看到的 2305.03393v1.md 这份 Groundtruth既是该论文思想的文字载体也是 Docling 自身 PDF→Markdown 能力的直接产物。若希望继续深入建议依次阅读同目录下的2305.03393v1.json结构化标注、table_structure_model.pyTableFormer V1 推理全流程与 pipeline_options.py表格模型的可配置项即可从表示语言 → 模型 → 配置三个层次完整打通 Docling 的表格结构识别链路。【免费下载链接】doclingGet your documents ready for gen AI项目地址: https://gitcode.com/GitHub_Trending/do/docling创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 从 HTML 到 OTSL：Docling 表格结构识别中的优化表结构语言解析
从 HTML 到 OTSLDocling 表格结构识别中的优化表结构语言解析【免费下载链接】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 RecognitionIBM Research2023经 Docling 文档管线转换出的 Markdown Groundtruth。这篇论文提出的OTSLOptimized 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.03393v1cs.CV2023-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论文的摘要指出表格是科学论文、专利、报表、说明书、营销材料等文档中高价值信息的常见载体必须高精度地抽取。表格外观千差万别尺寸、样式、结构各异纯解析方法难以恢复其真实结构因此现代文档理解系统普遍采用机器学习方法。典型的表格抽取是两步式流程表格检测Table Detection先用目标检测在页面上定位出每个表格的包围框表格结构识别TSR识别表格的逻辑行、列与跨行跨列结构。论文认为表格检测在当代已接近人类水平而 TSR 仍是活跃研究课题。针对 TSR 的深度学习方法可划分为三类目标检测OD方法以相互重叠的包围框标注训练输出单元/行/列的包围框图神经网络GNN方法把表格建模为图节点是单元格内容/图像嵌入/几何坐标边表达同列、同行、同一单元格等关系Image-to-Markup-SequenceIm2Seq方法把问题变成序列生成任务直接预测一段描述结构的标记序列如 HTML、LaTeX、Markdown。Im2Seq 方法理论上天然具备直接输出结构的优势——无需像 OD/GNN 那样依赖后处理规则但实践中预测出的标记序列未必语法正确因此仍需后处理来保证输出的合法性。论文将研究落点放在表结构表示语言本身在保持神经网络架构不变的前提下考察用更优的表示语言能否同时提升精度与推理速度并选取当时的 SOTA Im2Seq 模型 TableFormerNassar et al., CVPR 2022作为实验载体。3. HTML 表结构表示的三个硬伤在 OTSL 出现之前公开数据集PubTabNet、FinTabNet以 HTML 作为 Groundtruth 格式主流 Im2Seq 模型也直接采用 HTML token 序列作为建模对象。论文从三个角度论证了 HTML 并不适合 Im2Seq3.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 LanguageOTSL用原子 2D 网格上的少量符号直接刻画结构。其词汇表仅 5 个 TokenToken语义合并方向CCell——一个新单元格可有内容也可无内容单元格的锚点span 情形下总位于单元格左上角LLeft-looking——与左邻单元格合并成跨格向左合并UUp-looking——与上邻单元格合并成跨格向上合并XCross——同时与左邻和上邻单元格合并同时向左、向上合并NLNew-Line——换行切到下一行行的终止符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 的合法性由以下规则约束以网格坐标理解最直观向左合并规则L的左邻必须是另一个L或C向上合并规则U的上邻必须是另一个U或C十字合并规则X的左邻必须是另一个X或U其上邻必须是另一个X或L首行规则第一行只允许L与C第一行无上邻天然不可能出现U/X首列规则第一列只允许U与C同理排除L/X矩形规则表示永远是矩形所有行 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实验设置结构预测质量用 TEDsTree Edit Distance score将 OTSL 结果转回 HTML 后计算衡量单元格包围框用 mAP0.75 衡量推理耗时统一在单核 AMD EPYC 7763 2.45GHz 机器上测量。所有数据集的 Groundtruth 均转换为 OTSL 格式。7.1 HPO 超参扫描Table 1仅 PubTabNet论文在 PubTabNet 上对不同编码器/解码器层数做超参优化TEDs 按简单表/复杂表含跨格/全部三档报告enc-layersdec-layers语言TEDs(simple)TEDs(complex)TEDs(all)mAP0.75推理时间(s)66OTSL0.9650.9340.9550.8802.7366HTML0.9690.9270.9550.8575.3944OTSL0.9380.9040.9270.8531.9744HTML0.9520.9090.9380.8433.7724OTSL0.9230.8970.9150.8591.9124HTML0.9450.9010.9310.8343.8142OTSL0.9520.9200.9420.8571.2242HTML0.9440.9030.9310.8242.00从表可见OTSL 在全部 TEDs 相当的前提下获得更高的 mAP且推理约快 2 倍同精度下模型可显著缩小编码器/解码器层数配合 HPO 论文称最大可获得 5~6 倍的推理加速。注意这些是论文报告的实验数据来自文档原文直接搬用时应以论文为准。7.2 跨数据集定量结果Table 2取质量最佳的超参enc6、dec6、heads8在三个公开数据集上独立训练与评测数据集语言TEDs(simple)TEDs(complex)TEDs(all)mAP0.75推理时间(s)PubTabNet (~395k)OTSL0.9650.9340.9550.8802.73PubTabNetHTML0.9690.9270.9550.8575.39FinTabNet (~113k)OTSL0.9550.9610.9590.8621.85FinTabNetHTML0.9170.9220.9200.7223.26PubTables-1M (~1M)OTSL0.9870.9640.9770.8961.79PubTables-1MHTML0.9830.9440.9660.8893.26结论是OTSL 在稀疏、大尺寸的金融表FinTabNet上优势尤其明显complex TEDs 0.961 vs 0.922mAP 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 管线中负责表格结构识别的是 TableFormerV1模型实现在 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-models3.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 V2table_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.pyTableFormerMode枚举fast/accuratefast优先速度适合简单表格或高吞吐批量场景accurate提供更高质量、更慢生产环境推荐CLI 默认值即为TableFormerMode.ACCURATE见 cli/main.pyTableStructureOptions默认实现kinddocling_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 预测器、TableStructureOptionsfast/accurate、do_cell_matching等源码结构融入 Docling 的日常表格提取流程——你看到的 2305.03393v1.md 这份 Groundtruth既是该论文思想的文字载体也是 Docling 自身 PDF→Markdown 能力的直接产物。若希望继续深入建议依次阅读同目录下的2305.03393v1.json结构化标注、table_structure_model.pyTableFormer V1 推理全流程与 pipeline_options.py表格模型的可配置项即可从表示语言 → 模型 → 配置三个层次完整打通 Docling 的表格结构识别链路。【免费下载链接】doclingGet your documents ready for gen AI项目地址: https://gitcode.com/GitHub_Trending/do/docling创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考