表格识别SOTA路线解析：从Transformer端到端到工程落地选型

最近被几位做文档智能的同行问到同一个问题表格识别做到现在SOTA 到底是哪条路线问的人多了我干脆把自己这段时间的调研、踩坑以及对公开结果的理解整理成一篇聊一聊我眼中表格识别目前真正前沿的状态。如果你正准备接表格识别方向的需求或者正在为一个内部系统的“结构化抽取”功能选型这篇文章可以给你一个相对清晰的参考坐标。先说结论表格识别目前的 SOTA 并不是某一个模型的名字而是一套以 Transformer、端到端结构预测、大规模预训练为核心的技术组合。榜单上好看的数字和真实业务可用之间仍然存在很现实的落差。下面我按自己的理解把任务拆开、把路线捋一遍再落到工程选型上尽量把“为什么这样做”也说清楚。1. 先拆明白表格识别里“SOTA”到底指的哪一个任务表格识别Table Recognition在文档智能里是一个复合任务很多讨论“SOTA”聊不到一起去根源就是把任务口径搞混了。我一般会先把它拆成三块表格检测Table Detection在一整页图片上找到“哪里有表格”输出表格区域的外接框通常是矩形坐标(x_min, y_min, x_max, y_max)。它解决的是定位问题。表格结构识别Table Structure Recognition, TSR在已经裁剪出的表格图片里还原行列结构、合并单元格、单元格坐标与逻辑顺序。输出通常是 HTML 结构、XML或者一组带标签的单元格坐标。单元格文本识别也就是对每个单元格里的文字做 OCR。很多时候它被单独拆出去但端到端表格识别也会把它一起做掉。现在大家说“表格识别 SOTA”默认大多指的是表格结构识别也就是 TSR。原因不难理解检测问题在通用目标检测里已经相对成熟迁移到表格场景效果比较稳定而结构识别才是表格解析里最难、最有区分度的部分。我习惯用一个公式概括落地任务的复杂度表格识别落地难度 ≈ 表格检测难度 结构识别难度 单元格文本识别难度 版面/域适配难度这四个部分不是等权的。普通的横线表、印刷清晰的报表前三项都不难一旦出现无框表、多层表头、合并单元格、跨页表、盖章遮挡、手写内容难度立刻翻倍。下面用一个表格把任务和常见难点对起来方便你对照自己的场景。任务输入输出典型难点表格检测整页图 / PDF渲染图表格外接框小表格、嵌套表格、图表混排表格结构识别表格区域图HTML / XML / bbox列表无框表、合并单元格、多级表头、斜线表头单元格文本识别单元格子图文本序列打印体、手写、印章、亮度不均端到端表格识别整页图带结构的HTML文本长表格、跨页、域外格式当你去翻某篇论文里的“我们的方法取得了 SOTA”一定先看它是在哪一个子任务上、在哪个公开集上做的对比。有些论文只做 TSR有些只做表格检测还有些做的是“图转HTML”的端到端生成三个方向的指标口径完全不同混在一起看容易得出非常乐观或非常悲观的错误结论。2. 这条赛道怎么卷起来的从两阶段到单阶段 Transformer表格识别这几年走了一条和通用目标检测、OCR 很像的路先规则后深度再由 CNN 切换到 Transformer最后走向端到端。2.1 早期的规则方法与“检测后处理”老思路最早一批生产级表格识别基本靠形态学运算找横线、竖线再求交点切格子。它对待识别图片的要求很苛刻表格线要完整背景要干净分辨率要够。只要有一条线被印章盖住整行整列可能就对不齐。这种方案现在没有团队会当作主路线但其中的几何直觉在后处理里仍然很值钱——坐标排序、线对齐、单元格拼接这些逻辑到现在都是绕不开的。进入深度学习阶段后比较成熟的做法是把表格识别拆成两段。先用检测网络比如通用目标检测框架找到表格区域再用一个结构网络去还原行列。 结构网络早期流行过分割思路预测行列所在的像素掩码再通过投影把行和列物理切出来。问题也随之而来单元格掩码只是在“画格子”当表格没有物理线、或者单元格跨行跨列时分割得到的像素结果很难直接转换成逻辑表格。2.2 序列生成思路的兴起把表格当成一份“代码”后来业界把目光转向“把表格写出来”。这种方法不输出坐标而是让模型直接生成一段 HTML 或类 XML 的结构描述。例如给模型看一张表格图让它输出table thead trth姓名/thth部门/th/tr /thead tbody trtd张三/tdtd技术部/td/tr trtd李四/tdtd市场部/td/tr /tbody /table好处非常直观不需要纠结单元格坐标不需要设计复杂的匹配逻辑模型直接学“图到结构”的映射。编码器用视觉特征解码器用自回归方式逐 token 生成结构。这也是早期某些端到端表格识别方案的核心思路代表思路可以统称为“图片转HTML”范式。它看起来优雅实际跑起来有一个隐患一旦表格变长、单元格变多需要生成的 token 序列会非常长自回归模型很容易在生成到一半时产生结构漂移——前面少了一个td后面所有单元格都对不齐了。而且这种方案通常还需要单独接 OCR 来识别文字并不是严格意义上的全流程端到端。2.3 DETR 范式的渗入检测与结构统一Transformer 目标检测范式出现后表格识别很快吸收了这一思路。它的核心变化是把“找表格框”和“找单元格框”统一成集合预测问题模型输入一张图片直接输出若干个对象框每个框带标签比如table、row、column、cell再用二分图匹配计算损失。这种方案不再依赖手工设计的先验框也不需要在输出端维护冗长的 HTML 序列而是把表格结构拆成一组空间对象。这种转变的意义在于结构识别第一次可以和物体检测共享同一套建模语言。合并单元格可以是一个覆盖多行多列的cell框行框和列框可以通过几何关系推导逻辑结构。模型要学的不再是“把像素分割成行和列”而是“理解哪些区域在逻辑上属于同一行”这更接近人对表格的理解方式。2.4 预训练和多模态信息加入表格毕竟是文档类数据光看图像信息是不够的。当前头部方案的另一个共同点是把“图像”和“文本”两个模态一起建模文字内容、字体大小、坐标位置、版面顺序全部进入同一个 Transformer。这其实借鉴了多模态文档理解的做法——先在大量无标注文档上做掩码预测预训练再在下游表格结构任务上微调。预训练带来的提升非常明显尤其对“没见过的版式”鲁棒性比从零训练高出一截。把这几条路线放一起看演进逻辑其实很清楚从依赖人工规则的几何切割到让网络自己学像素分割再到用序列生成表示结构最后收敛到“空间坐标语义信息”的端到端集合预测。每一步都是在解决同一个问题如何让模型既理解表格的物理位置又理解表格的逻辑结构。3. 我调研下来真正能打的 SOTA 方案共性都在哪我看了不少公开实现和一些最新论文的对比结果也自己在业务数据上复现过几种主流思路。要说现在真正处于第一梯队的方案我认为共性集中在五个方面。3.1 端到端 Transformer 结构是绝对主流不管是走“检测表格识别结构”两段式还是走“单模型一次输出全部框”的单阶段路线第一梯队方案的主干网络都已经换成了 Transformer 架构。CNN 仍然承担视觉特征提取的底层工作但跨行跨列、表头层级这类长距离依赖只有全局注意力机制处理得比较自然。我自己的体感是纯 CNN 方法在简单有线表上还能打遇到复杂合并单元格几乎必输给 Transformer 系方案。3.2 输出既可以是“框”也可以是“HTML”但内部都带空间坐标目前主流方案在输出形式上分两派集合预测派输出table、cell等对象框靠几何关系推断行列。序列生成派输出 HTML 类 token但解码过程中通常也引入空间注意力让每个 token 能“看到”对应图像区域。这两派在公开集上互有胜负但集合预测派在工程上更受青睐因为它天然保证了每个单元格有明确的坐标方便后续 OCR、按坐标排序、还原 Excel。纯 HTML 生成的长表漂移问题到目前为止还没有彻底解决所以做工程的朋友优先考虑带坐标输出的方案基本不会错。3.3 大规模预训练成为“隐形分水岭”现在拉开模型差距的往往不是网络结构少了一个模块而是预训练数据规模。文档领域的多模态预训练方法把扫描件渲染图、PDF 原生文字、版面坐标放在一起做自监督学习随后把模型参数迁移到表格结构识别上。这种“预训练-微调”范式的效果非常稳定。我实际比较过同一个网络结构用随机初始化和预训练初始化的差距在私有业务数据上结构准确率能差出 5 到 8 个百分点这在识别领域算是非常显著的差距。所以当你评估一个开源模型时不要只看结构要先看它的训练数据长什么样。 在几百万张印刷文档上预训练过的模型和只在几万张论文扫描页上训练过的模型即便测试集指标接近真实业务里的泛化能力可能完全不在一个量级。3.4 表格结构被当成“图”来建模另一个值得留意的趋势是把表格的行列关系建模成图结构单元格是节点合并、跨行、跨列是边解码时同时预测节点和边。这样做的好处是复杂的逻辑关系统一成了关系预测任务输出形式比长 HTML 序列更紧凑也不容易出现序列漂移。这类方案目前的宣传声势没有 DETR 系大但在多级表头、不规则合并场景下常常表现更好。3.5 不同公开榜单的头部方案特征结合公开的评测结果来看表格结构识别榜单上最高的几档方案几乎都具备我上面说的几个要素Transformer 主干、多模态预训练、带坐标的结构化输出、加上针对表格结构的专门解码头。如果想快速做技术选型直接看榜单头部那几篇方案再对照自己的数据复杂度选择“单阶段”还是“两阶段”比从零搭网络高效得多。下面这张表是我的快速选型参考不是绝对答案但方向上是稳的业务场景推荐范式理由扫描清晰的横向/纵向有线表检测结构识别两阶段稳定、可替换、调试方便复杂合并单元格、多层表头报表端到端集合预测DETR式单元格空间关系建模好不规则表格、斜线表头、跨页图结构/关系预测类方案逻辑关系表达能力更强移动端拍照表格大规模预训练的端到端方案对光照、角度、噪点鲁棒性好4. 公开榜单分数高实际业务里为什么还是翻车很多人在公开集上看到 TEDSTree Edit Distance based Similarity树编辑距离相似度能到 90 多分立刻觉得“表格识别已经被解决了”结果放到真实业务里模型跑得一塌糊涂。我把这个落差拆开聊一下。4.1 公开数据的“长相”和真实数据差得太远公开表格识别基准里大量源于论文扫描页和电子文档渲染图版面规整、光照均匀、横平竖直、字体统一。真实业务里的表格是拿手机拍的、从扫描仪出来的、或者是传真件转 PDF 再渲染的。表面有折痕、背面的字透过来、光线不均匀、表格线断断续续这些在公开集里几乎不存在。一个在公开集上很能打的模型到了真实数据上漏检和结构错乱往往同时爆发。4.2 TEDS 这个指标本身存在盲区TEDS 的核心思想是把识别出的表格结构转成一棵树然后和真实结构树算编辑距离相似度。它能衡量单元格内容和大体结构但并不能很直观地反映“这张表能不能直接用”。举个例子模型把两行内容识别成一行TEDS 只会把它当成一次结构替换扣一点分但业务上这意味着整行的数据全部对错位置几乎是不可用。反过来如果只是错了一个单元格的文字TEDS 扣分反而更明显。所以在 TEDS 90 和 TEDS 92 之间业务体验很可能是反直觉的分高的方案不一定更好用。4.3 榜单优化和“针对数据集的先天优势”有些方案为了让公开指标好看会针对固定 benchmark 做比较重的后处理比如对输出坐标做专门排序、对表格数量做统计修正。这一类“考试型调优”在榜单上是合法的但在真实未知数据上是帮不上忙的。你复现出来跑自己的数据面对的是完全不一样的分布效果自然打折扣。4.4 真实场景里常见的失败模式我在实际项目里遇到比较多的问题大概有这么几类印章遮挡红章压住了表头线和若干单元格线检测断掉结构识别错位。跨页表格一张表跨两页第二页没有表头模型把第二页单独当成一张不含表头的新表。多级表头像“销售收入”下面再分“本年”“上年”这种两层以上表头模型经常只还原一层。无框表格版式上用空白间距分隔单元格模型容易把一行吞掉。表内插入图片/签名单元格不是一个“纯文字块”模型可能把签名区域当成文本行输出或者干脆漏掉整行。最近一个做票据处理的客户就踩过坑他们的扫描件里有一张密集的财务报表三个大列每个大列又分三个小列表头占三行。开源模型在公开集上 TEDS 超过 92但在这张表上表头逻辑直接乱掉导出 Excel 后整张表完全没法看。后来花了两周做了针对性的标注微调和后处理才勉强达到可用状态。这个例子很能说明问题SOTA 在榜单上是“场景内”的业务数据才是真正的考试。5. 工程落地怎么选型我的实操经验与建议如果你看到这里说明你是真的要做这个事不是单纯看热闹。那我直接给一套可以“抄作业”的思路。5.1 动手之前先量化业务数据的复杂度不要拍脑袋选模型先做一个小样本评估。从真实业务图里抽出 500 到 1000 张至少标注一遍表格区域和单元格结构统计三类指标有多少表格是有完整横竖线的有多少表格存在合并单元格、多层表头、跨页文本质量如何是打印体、手写还是混合这三组数字直接决定了技术路线。如果 95% 是有线表且没有合并单元格传统两阶段方案足够成本最低如果有大量复杂逻辑结构直接上端到端 Transformer 加图结构后处理如果有人手写那还得单独评估 OCR 能力表格识别模型救不了手写识别问题。5.2 我推荐的“默认组合拳”在没有特殊约束的情况下我一般推荐这套组合表格检测用基于 Transformer 的检测器或者成熟的通用检测框架保证召回优先。宁可多框出一个非表格区域也不要漏掉半个真正的表格。结构识别端到端集合预测类方案输出单元格坐标和行列归属。单元格文本识别独立 OCR 引擎按坐标裁剪后逐格识别不要把文本识别硬塞进结构模型。后处理根据坐标做行列排序补推断合并单元格用几何约束修正明显越界框。这套组合的优点是每一环都可以单独替换、单独评估。哪天 OCR 换了结构模型不用动哪天检测漏检变多了单独调检测数据就够了不用把整个链路推倒重来。5.3 一个典型的推理管线大概长这样# 表格识别管线示意伪代码 def table_recognition_pipeline(page_image): # 1. 表格检测输出页面上的所有表格框 table_boxes detect_tables(page_image) structured_results [] for box in table_boxes: # 裁出表格区域 table_region crop_image(page_image, box) # 2. 结构识别输出单元格 bbox 行列归属 cells recognize_table_structure(table_region) # 3. 单元格 OCR按坐标逐格识别 for cell in cells: cell_image crop_cell(table_region, cell.bbox) cell.text ocr_recognize(cell_image) # 4. 后处理坐标排序、合并推断、行列表重建 html convert_cells_to_html(cells) structured_results.append(html) return structured_results这个管线的关键点是把“结构”和“文本”解耦。在复杂表格里文本错一个字不影响结构结构乱掉了即使每个字都识别对数据也是错的。分开处理至少有一个维度是可控的。5.4 几条真正有用的避坑经验第一对输出坐标做排序时不要只按 y 坐标排。扫描件角度稍微歪一点y 坐标就会互相穿插。建议先按角度做旋转矫正或者做一个主方向估计再按投影坐标排序。否则一整列的数据会串到相邻列排查起来会怀疑人生。第二合并单元格推断要多一道校验。模型输出的单元格框通常有重叠别直接进 Excel。先用 IoU 判断两个框是否属于同一逻辑格再用行列投影关系确认最后才生成合并属性。这道规则虽然简单但能拦住大量结构错乱。第三人工兜底机制不是可选项。对模型输出的置信度做分档低置信度的表格转人工校验。很多业务问题不是模型扛不下来而是缺了一个退路。把低质量样本交给人工比让模型硬撑然后全量返工要便宜得多。第四跨页表处理一定要单独设计。别把页面简单裁开识别完就完事先通过表头重复性判断是否是续页表格再把各页结构拼回一张逻辑表。这块在公开集里几乎没人考但真实业务几乎绕不开。5.5 性能和成本要提前算表格识别比普通 OCR 更吃算力。一张正常分辨率的 A4 扫描图走完整条管线在普通 GPU 上可能需要几百毫秒到一秒多。如果你的业务是每天几万张的异步处理这个速度还能接受如果要做实时拍摄、实时返回结果就必须考虑模型裁剪、TensorRT 加速、以及减少单图串联步骤等方案。我通常会建议先用“离线批量”跑通业务再考虑实时性不要一上来就追求极致的单图延迟。5.6 如果从零开始建议按这个顺序迭代第一步用公开模型在你的小样本集上跑一遍看失败原因分布。第二步针对性标注 2000 到 5000 张业务图做预训练模型的微调。第三步把后处理规则叠上去再观察指标提升。第四步如果复杂结构问题仍然突出再考虑换图结构方案或做二次解码修正。绝大多数场景在第二步、第三步就能达到可用水平。我在不同项目里把前面说的三条路线都试过最深的感受是表格识别目前的 SOTA 还没有到“一键全自动”的程度。 模型负责把 90% 的标准场景做干净剩下的 10% 复杂结构还得靠后处理和人工确认来兜底。真正靠谱的方案从来不是追求一个最贵的模型而是把检测、结构、OCR、后处理、人工分诊这几个环节组合成一条稳定的流水线。希望这篇整理能让你在选型和被业务挑战时少走一点弯路。