企业官网建设流程全解析

表格OCR这个词，听着像是“能认表格里的字”就行，但真正把它接进业务系统的人都知道，事情远没那么简单。我最早接触表格OCR时也天真地以为，它跟普通OCR的区别无非是多识别几个单元格，结果第一批测试样本就给了我一个下马威：文字全部认对了，可表格的行列关系完全乱了，表头串到了数据列，合并单元格拆出来一堆空值，整个结果根本没法落库。那时候我才意识到，表格OCR的核心难点从来不在“认字”，而在“还原结构”——你要让机器不仅读得出图像里的文字，还要理解这些文字在二维表格中的位置关系、从属关系、表头层级和单元格边界，才算真正完成了任务。

这篇文章就来聊聊表格文字OCR到底是什么、它内部是怎么工作的、实际落地时有哪些绕不开的坑，以及怎么从工程角度判断一个表格OCR方案靠不靠谱。内容面向的是要选型、要接入或者正在被表格解析折磨的开发者与产品同学，也适合想搞清楚“OCR还能干这事”的好奇读者。

1. 表格OCR的定义：把“识别文字”和“复原表格”拆成两件事

1.1 普通OCR的输出，为什么直接拿来做表会翻车

普通OCR的输出结构很简单：一句话描述就是“图里有哪些字，分别出现在什么位置”。具体到实现上，它通常是按行输出文本块，每个文本块带一个矩形框坐标和置信度。这种粒度放在整段文本识别场景里完全够用，可一旦落到表格里，问题立刻就暴露了。

想象一张常见的费用报销表，里面有日期、项目、金额、备注四列，每列下面有若干行数据。普通OCR会告诉你“2024-03-01”这几个字在图片的哪个位置，“差旅费”在哪个位置，但它不会告诉你“2024-03-01”和“差旅费”是不是同一行的内容，也不会告诉你“差旅费”到底属于“项目”列还是“备注”列。坐标信息倒是都有，可要把坐标换算成行列关系，中间隔着大量推算工作：如果表格线没有完整贴齐，如果表头有合并单元格，如果某一行的文字被扫描歪了，坐标推算就会连环出错。

所以很多团队最开始的做法是“OCR识别完再用坐标自己排行列”，结果做到一半发现，工作量几乎等于重新写了一个表格结构解析器，而且每个新表格版式都得重新调规则。这正是表格OCR存在的意义：它不是普通OCR加一个后处理脚本，而是把“版面分析-文本检测-结构还原-内容填充”放在一起通盘考虑的一条完整流水线。

1.2 表格结构还原具体还原的是什么

要理解表格OCR的目标，得先把“表格结构”拆成四个层次来看。

第一层是物理结构，也就是表格在图像里占哪块区域、表格内部有哪些矩形单元格、这些单元格的物理边界大致在什么位置。这一层解决的是“格子在哪”。

第二层是逻辑结构，也就是哪些单元格属于同一个表头分组、哪些单元格在语义上是某一列的数据、哪些行属于数据区、哪些行属于表头区。这一层解决的是“格子和格子之间是什么关系”。

第三层是内容结构，即每个单元格中提取出来的文字，经过语义理解后应该归属到哪一个行列交叉点上。它解决的是“哪个字放进哪个格子”。

第四层是导出结构，也就是把上面三层的结果序列化成表格数据格式，通常是二维数组、HTML表格、Markdown表格或CSV。导出结构要求处理合并单元格的跨行跨列关系、空单元格的补齐、表头层级的多行列合并等细节。

好的表格OCR方案，这四个层次都能给出合理输出；差的方案可能只给了第一层和第三层的一部分，逻辑结构靠猜，导出结构靠“大致拼接”，结果就是看起来识别率很高、用起来处处都是坑。

1.3 判断“成功还原”的三个硬标准

我在项目中总结过三个判断表格OCR是否真正可用的硬标准，跟一般OCR的“字符准确率”不完全是一回事。

第一个标准是行列对齐率。什么叫对齐？就是导出结果里每一行数据的单元格数量一致，且同一列的语义字段没有被串到别的列。举个例子：一个5行4列的表格，导出后如果某些行只有3个值、某些列的数值错位到了下一行，哪怕每个文字本身都识别对了，这张表也是废的。

第二个标准是合并单元格保持率。真实世界里的表格几乎不可能全是一格一值，表头跨列、行标题跨行都是常态。一个可用方案必须能在导出结构中保留这种合并关系，比如用rowspan和colspan来表达，或者在二维数组里用空值加标记来表达，而不是简单粗暴地给每个合并区域重复填充同样的值或者留一堆空白让下游自己猜。

第三个标准是表头字段与数据列的语义对应准确率。这比前两条更深一层，要求系统不仅能识别“这是一个表头”，还能理解“这一列表头下面挂的是哪一列数据”。多级表头场景下尤为重要，比如“销售情况”下面分“线上”、“线下”两列，每个大列下面又分“金额”、“占比”，结构还原系统需要还原出这三层嵌套关系。

只要能在这三个标准上经得起检验，才可以说这个表格OCR方案“还原了表格结构”，而不只是“识别了表格里的字”。

2. 从图像到二维表的全过程：表格OCR的内部流水线

2.1 表格区域检测：先搞清楚图里有没有表

表格OCR处理的第一件事不是去认文字，而是先做版面分析，把图像里的内容划分成不同区域：这是一段正文，那是一个图片，右边是一个表格，下面有个签名栏。只有先定位到表格区域，后续的结构解析才有边界。

这一步说起来简单，实际做起来需要考虑不少细节。比如说，一张扫描件里既有表格又有普通文本段落，模型需要判断哪块区域是表；又比如说，一个页面里有多个表格，表格和表格之间的分隔怎么界定；再比如，有些表格没有外边框，完全靠空白间距和字体的对齐关系形成视觉上的表意，判断“这里是一个表”比有框线的场景难得多。

当前主流做法通常是基于目标检测或语义分割模型，把图像切分并预测每个区域的类别，再配合一些后处理规则把相邻的文本块归类到一个表格上下文里。工程上我比较看重的点是：表格区域检测模型的输出是否带坐标边界，因为只有边界可靠，后续的单元格切分才可能可靠。

2.2 有框线表格的单元格切分：检测线条在哪

如果表格带框线，单元格切分最直观的做法就是检测表格线：横线和竖线各检测一遍，然后求它们的交点，交点连线就圈定了单元格边界。

但照片和扫描件里的表格线往往不是干净的黑色线条，可能有断线、粗细不均、背景纹理干扰。所以这一步的工程细节很重：图像预处理阶段要做二值化、形态学变换把线连起来，检测模型要有一定的抗干扰能力，后处理还得根据交点的分布规律做线段的延伸和裁剪。

实际做下来，我用过的所有方案都逃不掉一个后处理环节：把检测到的线段聚类成“横线族”和“竖线族”，再按坐标排序，相邻线段距离在阈值内就合并为同一条线，断线超过阈值就按预测方向补齐。这个处理对扫描倾斜、线宽不均的样本特别有效，也是很多开源方案里最容易被人忽略的一段代码。

2.3 无框线表格的单元格推断：没有线怎么知道格子在哪

无框线表格是表格OCR里面最挑战的一类，像财务软件的导出版本、网页截图里的表格、手机上拍的Excel截图，很多都没有完整的框线，甚至一条线都没有。它靠的是行间距、列间距和对齐关系来表达结构。

这类表格的解析思路和二值化检测线完全不一样，要靠文本块聚类再加上几何规则推断。大致流程是：先把识别出的所有文本块按y坐标聚类成若干行，再在每一行内部按x坐标区间划分列边界，然后跨行对齐这些列边界，最终形成一个不依赖线条的虚拟网格。

这个过程中最考验算法的地方在于：某一行可能因为单元格内容过长被挤成了两行视觉行，某两列在不同行之间的分隔位置可能略有偏移，某些合并单元格会让某一行的列数和别的不一样。所有这些偏差都要靠聚类和拟合算法去纠正，否则结构就会崩。实测下来，纯无框线表格对引擎的模型能力要求是最高的，很多号称支持表格识别的方案，在这个场景下准确率会明显跳水。

2.4 文字识别与内容回填：角色分离是关键

结构解析和文字内容识别，在很多方案中是两条并行处理的路径，最后再合流。结构解析负责画出表格的“骨架”——有哪些单元格、属于哪一行哪一列、有没有合并关系；文字识别负责把图像中每个区域的文字提取出来，并保留其精确位置。

合流阶段就是把文字块按位置“填充”到对应单元格里。这里有一个常见的坑：文字块和单元格边界往往不是完全重合的，有的文字溢出到相邻单元格，有的文字块跨越两个单元格。简单粗暴的“文字中心点落在哪个格子就归哪个格子”策略，在文字溢出时会出错。更好的做法是同时考虑文字中心点和覆盖面积，再结合该表格的行列语义约束来做归属判定。比如，一行里已经有一个单元格填进了内容，相邻单元格就不可能再接收同一段文字，这类约束能挡掉很多误判。

2.5 导出为结构化数据：Markdown、HTML、CSV还是数据模型

流水线的最后一步是把识别结果导出成某种结构化格式。这一步看似简单，实际上直接决定了下游系统能不能无缝对接。

如果你要把结果给人看，Markdown表格最直观，轻量、易读，还能直接嵌进文档。如果结果要渲染成网页，HTML表格是标准答案，支持完善的rowspan、colspan，能完美表达合并单元格。如果结果要进数据库或Excel，CSV或结构化JSON更合适，但CSV不支持合并单元格，需要把跨行跨列的值做复制填充，或者用特定标记表示，这点要提前想清楚。

我个人的建议是，官网方案内部最好统一走一个JSON结构，把所有单元格的行列坐标、合并范围、文字内容都保存下来，再按需格式化成不同输出。这样前期多写一点转换代码，后期换输出格式只需要改一层，不用重新跑整个识别流程。

3. 真正拉开差距的难点：合并单元格、跨页表格与无线表格

3.1 合并单元格：全局关系，不是局部问题

合并单元格为什么难？因为它不是某个单元格本身的属性，而是单元格之间的一种关系。你要判断两个相邻单元格是不是合并成了一个，不能只看这两个格子内部的内容，还要参考整行整列的结构规律。

比如一个表格第1行有两个单元格，第2行有四个单元格，在没有合并的前提下，这通常意味着第1行有两个单元格横跨了第2行的四个单元格。但如果第1行是表头，它可能只是简单的两列表头，下面裂变成四列，这时第1行的两个单元格并不构成“水平合并”，而是“层级关系”。两种解释都合理，但从图像上看几乎一样，机器需要借助上下文语义才能判断。

处理这个问题的技术路线有两类：一类是规则驱动，基于检测到的单元格边界做几何推导，用“面积包含”“边界对齐”等规则判断跨行跨列关系；另一类是模型驱动，让深度学习模型直接预测每个单元格的rowspan和colspan，或者在表格整体结构中回归出合并关系。后者在复杂版面下更鲁棒，但需要大量标注样本。

3.2 多级表头的层级还原：表头和数据的父子关系

多级表头在报销单、财务报表、比赛积分表里极其常见。它的难点在于，不仅要识别出表头占了几行，还要还原表头字段之间的父子关系。

举个典型场景：一个季度销售表，表头从左到右是“一季度”和“二季度”两个大列，每个大列下面又拆出“华北”、“华东”、“华南”三个小列，小列下面再细分“金额”和“同比”。这种三层嵌套的结构，如果解析结果只有一个扁平的列名列表，那么把数据映射到数据库字段时就会彻底乱套。

好的方案会输出一个表头的层次树：季度层级、区域层级、指标层级，每个数据单元格记录它在树上的完整路径。我见过一些方案用“表头行掩码”的方式来做层级判断：先找出表头占用的行范围，再对每一行的列边界做聚类，不同行之间列边界有包含关系的就建立父子连接。这个思路实现起来相对可控，也是我目前在项目里比较推荐的做法。

3.3 跨页长表和续表：一个表被拆成两半怎么办

现实业务里很多表不止一页，特别是财务审计、合同附件、科研数据这类动辄几十页的大表。跨页表处理的难点在于：上页表格和下页表格没有物理连续线，但逻辑上是同一个表，列头在下一页通常还会重复出现，而数据行是连续编号的。

表格OCR方案遇到跨页表时，最忌讳的做法是把两页当成两个完全独立的表格分别解析，这样下游拼接数据时会出现列对不齐、表头重复等问题。正确的做法是：对跨页表格做“表格延续识别”，识别出下一页顶部重复的表头，将其标记为continuation header，而不当作正式数据行；同时给每个分页表格一个相同的表格ID，并保留分页编号顺序，让下游知道怎么拼接。

这个功能在开源OCR方案里支持得极少，商业方案里也良莠不齐。如果你要处理的表格有大量跨页场景，选型时建议专门用跨页样本来测试，别只看单页样例的效果。

3.4 旋转、倾斜和畸变：预处理是结构解析的隐形地基

扫描件最常见的毛病就是歪：纸张没摆正，扫描时倾斜了几度，或者拍照片时镜头畸变导致表格线变成弧线。文字识别引擎对轻微倾斜的抗性还行，但结构解析对这些几何偏差特别敏感——因为表格线检测、单元格划分都依赖坐标和方向，歪一点，交点算错，单元格就偏了。

所以正规流水线在结构解析之前一定会做图像校正：检测表格线的整体倾斜角度，做旋转校正；检测页面边缘做透视校正或梯形校正。这一步我踩过不少坑，最大的教训是不要迷信“全局校正能解决所有问题”——倾斜角度可能在页面的不同区域不一致，这时候需要做分区校正或者用更鲁棒的局部变换模型。

4. 工具选型与自建方案的权衡：模型、后处理与二次开发成本

4.1 三类主流技术路线的横向对比

当前做表格OCR，技术路线可以粗分成三类，每类都有明显的能力边界。

第一类是通用OCR引擎加自研表格后处理。方案的成本最低，先用通用OCR拿到所有文字和位置，再用几何规则做行列聚类和单元格推断。优点是灵活，你能完全控制每一步逻辑；缺点是所有结构推断的脏活累活都要自己写，而真实表格的版式变化几乎是无穷的，规则写起来没完没了，维护成本很高。

第二类是基于深度学习的端到端表格结构识别模型。这类模型专门为表格结构而设计，直接预测表格的HTML结构或者单元格包围框加行列关系。优点是复杂版式下准确率明显优于规则方案，对无框线表格也更有鲁棒性；缺点是模型训练和调参需要一定门槛，对中文表格的适配还要看有没有对应的训练数据，推理资源也比纯文本OCR要多一些。

第三类是更完整的端到端文档智能方案，把版面分析、表格结构识别、文字识别甚至关键信息抽取都打包在一起，通常以商业服务或重量级开源项目的形式存在。优点是开箱即用，表格结构还原效果相对稳定；缺点是定制化能力弱，某些特定版式需要反复调优，价格和算力成本也更高。

三类路线没有绝对的优劣，关键看你的样本是否规整、表格版式是否单一、对准确率的要求有多高。如果只处理固定版式的报表，规则方案加少量模型辅助完全够用；如果面对的是五花八门的拍摄件和扫描件，端到端模型几乎是必须的。

4.2 自建流水线时的模型选型要点

如果决定自建，模型选型我建议关注四个维度。

一是表格结构识别模型是否支持表格线检测和无线表格推断两种模式。有些模型只擅长有线表格，遇到无线场景直接抓瞎，测试时一定要两类样本都过一遍。二是模型输出的结构表达是什么格式。有的模型输出HTML片段，有的输出单元格坐标加类型标签。HTML格式更方便，因为它天然表达了合并单元格和行列关系；坐标格式则方便做几何后处理，两种格式如果能同时输出，后续对接会省很多事。

三是中文长字符识别的能力。表格里中文是重头戏，很多通用模型在长段中文和数字混排的单元格里表现不太稳定，特别是金额、日期、编号这类含数字和特殊符号的内容，对识别模型的细节精度要求比普通段落高得多。

四是推理速度和并发能力。表格结构识别通常比普通文字识别要慢，因为模型要做版面分析再二次推理。如果业务要求实时处理，一定要提前压测模型在目标硬件上的单张耗时，别等上线了才发现性能不达标。我在实际项目中曾经遇到过一个模型，识别效果很好但单张耗时到5秒，用作批量处理没问题，用户直接上传图片的实时场景就几乎没法用。

4.3 后处理与规则引擎：不要小看这部分工作量

模型再强，也不可能一把梭把所有表格迁就完。后处理规则引擎是表格OCR流水线里最容易被低估的部分，实际工作量常常占整个项目的一半以上。

后处理要处理的典型问题包括：把模型预测的单元格坐标纠正为标准对齐网格、把跨行的单元格在导出结构里正确标出、把表头里的同一层级列合并分组、把识别置信度低的单元格标记出来供人工复核、把多页表格拼接成完整逻辑表格等等。

一项经验是，后处理规则要尽量做成配置驱动，而不是硬编码。比如“表格最小列宽阈值”“同一行最大跨行数”“表头层级最大深度”这类参数，最好放在配置文件里，因为每来一个新客户、每接触一类新版式，这些参数大概率都要调。如果规则是硬编码的，每次改动都要动代码、走发布流程，迭代效率会低很多。

4.4 评估表格OCR效果的正确姿势

评估表格OCR不能只看字符识别准确率，我建议至少跑四个维度的评估指标。

第一个是单元格级准确率，即预测的每个单元格与非空真实单元格的正确匹配率，既看位置，也看内容。第二个是表格结构准确率，把预测的HTML结构和标注的真实HTML结构做树形编辑距离比较，误差越小越好。第三个是行列归属准确率，对每一个提取出的单元格，它的行号和列号是否与真实值一致。第四个是端到端任务准确率，也就是下游系统真正关心的指标——比如拖进数据库的表，字段值错没错、行数对不对、能不能直接参与汇总统计。

很多时候模型单独各项指标都还行，端到端任务准确率却不高，原因往往出在导出格式转换和后处理上，而不是模型本身。所以评估一定要从最终使用的角度来做，别停留在模型的演练指标上。

5. 实战中的典型场景与调参心得

5.1 财务报销单中的表格解析：多级表头怎么治

财务报销单是我遇到最多的场景之一。它的特点是结构固定、表头层级多、单元格里以金额和日期为主，而且经常是从PDF附件或手机拍照里来，图像质量参差不齐。

这类场景的表格解析，我总结的关键动作是先做版式分类：拿到的图是标准PDF渲染，还是手机翻拍？是彩色扫描件，还是灰度扫描件？不同来源的图像质量差异很大，预处理策略也应该分开。标准PDF渲染可以做高分辨率渲染再直接识别；手机翻拍件则要重点做去阴影、去反光、摆正和增强对比度。

多级表头则建议用“表头行掩码法”：先定位表头区域占用的行范围，然后对每一行做列边界聚类，对不同行的列边界做包含关系判断，逐层建立父子关系，最终生成一个层级表头树。这个方案的好处是不依赖模型去“理解”表头语义，纯粹从几何结构出发，稳定性和可解释性都更好。

5.2 手机拍摄表格后的修复链路：摆正、增强与文字补齐

手机拍的表格，图歪、光影不均、透视变形是常态。我在预处理上总结了一套链路，实测效果比较稳。

第一层是做透视检测和校正。利用表格线或页面边界的直线检测结果来估算变换矩阵，把表格区域校正为正视角度。这个校正要在结构解析之前做，因为它直接决定后续单元格切分的准确性。

第二层是做做背景压制和增强。拍摄件里经常有阴影、皱褶、手指挡住一部分表格线的情况，用灰度化、自适应二值化、形态学闭运算把表格线连起来，再对文字区域做对比度增强，能明显提升识别率。

第三层是置信度复查。拍摄件里总有部分单元格因为反光或遮挡识别不出来，这个没法完全避免。更现实的策略是让系统给出低置信度单元格的位置列表，交给人工补充录入，而不是让识别错误悄悄溜进导出结果里。这个策略落地后，整个处理流程的可用性提升比模型换参的效果还明显。

5.3 参数调节中容易忽略的几个细节

在调参与调优的过程中，有几个细节特别容易被人忽略，但影响却非常大。

第一个是图像分辨率。OCR引擎对不同分辨率的敏感度是不一样的。太高会导致单元格定位偏差增大，太低又会丢失细粒度线条。我自己习惯按表格最小字号反推分辨率，保证最小字号的字在图像上的高度不低于8像素，这样识别和结构检测都能兼顾。

第二个是空单元格的处理。有些表格的某些单元格故意留空，有些表格的单元格看起来空其实有浅色底纹或水印。结构解析很容易把“空单元格”误判为“单元格不存在”，把行压缩掉。所以模型和后处理要对空单元格保留占位信息，这一点在表格数据合并时尤其重要。

第三个是合并单元格后内容填充策略。跨行合并的单元格，内容通常只写一次，但导出到CSV时需要决定是复制填充还是置空。选复制填充，下游统计时可能会重复计算；选置空，下游按索引取值时可能会错位。我的建议是导出两种版本：CSV用复制填充并加注说明，JSON结构里用专门的rowspan标记，让下游根据场景选择。

5.4 细粒度特殊表的应对策略

有一种表特别难弄：行列不规则，表格线时有时无，单元格大小极不均匀，甚至一张表内混合了有框线、无框线、合并单元格、斜线表头等多种特征。比如某些医院的检查单、学校的成绩分析表、实验室的仪器数据表就是这种风格。

对这类极端版面，我目前见过最有效的策略是“多模型投票”：让多个结构识别模型或多种结构化规则同时跑同一张图，对结果做一致性投票，以多数一致的结构优先，不一致的单元格打标进入人工复查队列。这个方案会增加一些计算和开发成本，但在错误代价高的业务场景里，非常值得。

6. 踩坑实录：那些你以为没问题、实际却翻车的细节

6.1 文本检测块与单元格边界不完全对齐

我第一次做表格OCR集成时，天真地以为只要文本检测坐标足够准确，把文字分配进单元格就不是难题。直到一份测试表里出现大量“文字串格”现象我才意识到，文本检测返回的矩形框和单元格边界之间从来就不是完美对齐的，特别是汉字带有上下标、单元格里放了两个短数字、以及行高过大时，检测框很容易略宽或略窄。

后来我的处理方案变成了一个约束优化问题：先枚举每一个文本块与所有候选单元格的重叠面积，再结合行列唯一性约束，对每个文本块的归属做贪心加回溯修正。比如，同一行已分配的文本块覆盖过的单元格，下一个文本块就优先考虑仍为空的候选格。这个约束极大减少了串格误判。

6.2 表格外部的文字混入表格区域

表格OCR另一个高发问题是表格外部的注释、页码、表题被当作表格内容识别进结果里。尤其当表格区域检测模型不太准确时，表题“2024年Q3销售汇总表”会被当成表头第一行，页码“第3页”会被当成长表格末尾的一行数据。

处理思路很朴素但有效：结构解析完成后，做一轮“区域外文本过滤”，把文本块中心到表格区域边界的距离作为过滤条件；同时根据行列一致性做二次校验，凡是导出行列数与主结构差异过大的文本块，直接降权或标记为待复核。这个小步骤能过滤掉大量低级错误。

6.3 竖排文字和斜线表头

不遇到竖排文字和斜线表头，你不会知道表格结构解析还能有多复杂。竖排文字在中文表格里通常出现在表头最左侧，比如“备注”两字竖着写，它的检测框在几何上是竖长的，行列归属判断的规则跟横排文字完全不同。斜线表头则是一个单元格被一条或两条斜线分成多个语义区域，每个区域内容代表不同的维度含义。

这类特殊结构目前没有一套统一的完美解法。我的实际经验是，方案里专门预设特殊单元格处理逻辑：检测到竖排文字时，把单元格类别标记为竖排样式并在导出时保留样式属性；检测到斜线时，把斜线区域按相交线的交点划分为子区域，每个子区域独立回填文字。如果你的业务里这类表格占比很低，也可以考虑直接走人工复核流程，不在算法上死磕。

6.4 多页长表拼接后的数据一致性校验

跨页表拼接完成后还有一个隐藏坑：拼接后的表有一个全局的行序号，但分页表格之间可能存在行丢失或重复现象。某次我在处理一个30页的审计表格时，单页解析每个页面都很漂亮，但拼起来后发现少了两行——因为有一页的表格内容刚好卡在纸张切割线上，页面底部半行文字没有被识别进任何一页。

后来我给自己定了一条规则：凡是跨页表，拼接后必须做行数一致性校验。如果各页的数据行数之和与全局期望行数不一致，系统自动把可疑页面的表格重新解析，并标记出来供人工确认。这个规则不复杂，但能让整个流程的可信度上一个台阶。

7. 关于表格OCR落地，我的几点体会与建议

折腾了几年表格OCR，我的整体感觉是：这个方向难不在某个单一技术点，难在工程链路长、版式变化多、偶发问题防不胜防。一个可用方案的形成，往往是模型、预处理、后处理和人工复核四者反复迭代的结果，单靠某一个环节的优化很难撑起整体效果。

如果让我给准备上手的朋友提几条建议：第一，先把你手里表格的版式分好类，弄清哪些是高频标准版式、哪些是低频特殊版式，标准版式优先级最高，先用训练数据覆盖；第二，一定要建立一套带有结构标注的评测集，没有评测集就没有迭代基础；第三，别追求“全自动一把梭”，设置好置信度阈值和人工复查兜底，现阶段大部分业务场景需要的不是100%自动化，而是90%自动化加低成本的人工兜底。

我最后想分享的一个体会是：表格OCR选型时不要只看演示样例，一定要用你自己的真实样本跑批量对比测试。展示样例通常是最整齐最优美的表格，而真实世界的表格永远是歪的、花的、乱的和合并单元格花样百出的。拿着自己的样本去测，把行列对齐率、合并单元格保持率、表头层级还原率这几个硬指标跑出来，比看任何宣传材料都靠谱得多。