企业官网建设流程全解析

最近被几位做文档智能的同行问到同一个问题：表格识别做到现在，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。原因不难理解：检测问题在通用目标检测里已经相对成熟，迁移到表格场景效果比较稳定；而结构识别才是表格解析里最难、最有区分度的部分。

我习惯用一个公式概括落地任务的复杂度：

表格识别落地难度 ≈ 表格检测难度 + 结构识别难度 + 单元格文本识别难度 + 版面/域适配难度

这四个部分不是等权的。普通的横线表、印刷清晰的报表，前三项都不难；一旦出现无框表、多层表头、合并单元格、跨页表、盖章遮挡、手写内容，难度立刻翻倍。下面用一个表格把任务和常见难点对起来，方便你对照自己的场景。

当你去翻某篇论文里的“我们的方法取得了 SOTA”，一定先看它是在哪一个子任务上、在哪个公开集上做的对比。有些论文只做 TSR，有些只做表格检测，还有些做的是“图转HTML”的端到端生成，三个方向的指标口径完全不同，混在一起看容易得出非常乐观或非常悲观的错误结论。

2. 这条赛道怎么卷起来的：从两阶段到单阶段 Transformer

表格识别这几年走了一条和通用目标检测、OCR 很像的路：先规则，后深度，再由 CNN 切换到 Transformer，最后走向端到端。

2.1 早期的规则方法与“检测+后处理”老思路

最早一批生产级表格识别，基本靠形态学运算找横线、竖线，再求交点切格子。它对待识别图片的要求很苛刻：表格线要完整，背景要干净，分辨率要够。只要有一条线被印章盖住，整行整列可能就对不齐。这种方案现在没有团队会当作主路线，但其中的几何直觉在后处理里仍然很值钱——坐标排序、线对齐、单元格拼接，这些逻辑到现在都是绕不开的。

进入深度学习阶段后，比较成熟的做法是把表格识别拆成两段。先用检测网络（比如通用目标检测框架）找到表格区域，再用一个结构网络去还原行列。 结构网络早期流行过分割思路：预测行列所在的像素掩码，再通过投影把行和列物理切出来。问题也随之而来：单元格掩码只是在“画格子”，当表格没有物理线、或者单元格跨行跨列时，分割得到的像素结果很难直接转换成逻辑表格。

2.2 序列生成思路的兴起：把表格当成一份“代码”

后来业界把目光转向“把表格写出来”。这种方法不输出坐标，而是让模型直接生成一段 HTML 或类 XML 的结构描述。例如给模型看一张表格图，让它输出：

<table> <thead> <tr><th>姓名</th><th>部门</th></tr> </thead> <tbody> <tr><td>张三</td><td>技术部</td></tr> <tr><td>李四</td><td>市场部</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 主干、多模态预训练、带坐标的结构化输出、加上针对表格结构的专门解码头。如果想快速做技术选型，直接看榜单头部那几篇方案，再对照自己的数据复杂度选择“单阶段”还是“两阶段”，比从零搭网络高效得多。

下面这张表是我的快速选型参考，不是绝对答案，但方向上是稳的：

4. 公开榜单分数高，实际业务里为什么还是翻车

很多人在公开集上看到 TEDS（Tree 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 我推荐的“默认组合拳”

在没有特殊约束的情况下，我一般推荐这套组合：

1. 表格检测：用基于 Transformer 的检测器，或者成熟的通用检测框架，保证召回优先。宁可多框出一个非表格区域，也不要漏掉半个真正的表格。
2. 结构识别：端到端集合预测类方案，输出单元格坐标和行列归属。
3. 单元格文本识别：独立 OCR 引擎，按坐标裁剪后逐格识别，不要把文本识别硬塞进结构模型。
4. 后处理：根据坐标做行列排序，补推断合并单元格，用几何约束修正明显越界框。

这套组合的优点是每一环都可以单独替换、单独评估。哪天 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、后处理、人工分诊这几个环节组合成一条稳定的流水线。希望这篇整理能让你在选型和被业务挑战时，少走一点弯路。