这两年做文档数字化的朋友应该都有同感：OCR 单看文字识别率已经很能打了，可一旦丢过来一份带表格的扫描合同、两栏排版的论文 PDF、或者一张手写备注的报销单，问题就全冒出来了——表格线乱断、单元格错位、多栏内容读成一路、手写汉字直接变成乱码。说白了，传统 OCR 只是“会认字”，但整份文档的版式、结构、阅读顺序它完全没概念，结果就是识别出来的文字框一堆，却拼不出一份能直接用的结构化数据。
这篇博文要聊的，就是我从一个开源国产 OCR 项目里实测得出的完整解法：它不单做文字识别，还把表格结构还原、多栏版面分析、手写识别这三块硬骨头一起啃了下来。我会从技术选型的逻辑讲起，把表格识别、版面分析、手写识别的核心参数和调用方式拆开说透，再附上一套可以直接拿去改的工程代码思路。适合正在做文档解析系统、想给项目加上 OCR 结构化能力的开发者，或者被表格/多栏识别折腾过一阵子的朋友参考。
1. 整体设计思路：从“文字框”到“文档结构”的三层演进
1.1 传统 OCR 为什么拿表格和多栏没辙
先澄清一个很多人没意识到的问题。传统 OCR 管用的地方在于“检测+识别”这个闭环：先用检测模型把图片里的文字区域框出来，再交给识别模型把框里的内容转成字符串。这套流程对整段整段的印刷体文字效果不错，但一碰上结构化版面就露怯了。
拿表格来说，一张三线表在图片里会被检测模型切成七八个互不相干的文字框，每个框里只有单元格里的碎片文字。OCR 根本不知道哪几个框属于同一行、哪几个框属于同一列，更别提合并单元格、跨行跨列这种复杂结构。输出结果就是你拿到一堆乱序字符串，想还原成表格还得自己写一堆启发式规则去猜，而且猜错率极高。
多栏排版又是另外一个维度的问题。检测模型按空间位置出框，但报纸、论文这类多栏文档的阅读顺序是从左栏顶部往下、再回到右栏顶部。如果没有版面分析，OCR 会按坐标从上到下输出，左右栏内容交织在一起，读出来就是一段逻辑完全错乱的文字流。
1.2 我选型时看重的三个能力点
我在评估这套国产开源 OCR 方案时，核心就盯三件事。
第一是表格结构还原能力。不是简单把表格文字识别出来，而是能输出完整的表格结构——每个单元格的行列坐标、合并范围、内容文本，这样我才能直接把它转换成 Excel 或者 HTML 表格。
第二是版面分析能力。模型要能把页面里不同功能区域区分开：正文、标题、图片、表格、页眉页脚，并且识别出正确的阅读顺序。这块能力决定了多栏文档能不能被正确重组。
第三是手写识别的可用度。手写和印刷体不一样，笔画变形大、字间距不固定，同一个字不同人写出来差异性很大。模型必须在手写数据集上有过专门训练，而不是拿印刷体模型硬扛。
1.3 这条流水线是怎么串起来的
这套方案的完整处理链路大致是这样的：输入一张图片或者 PDF 页面，先做版面分析，把页面切成不同功能区域；每个区域再根据类型分流——表格区域走表格结构识别，正文区域走文字检测+识别，手写区域走手写识别模型。最底层其实是一个统一的检测识别引擎，只不过上层根据不同任务挂了不同的任务头和前后处理逻辑。
这个设计的好处是模块化解耦。底层引擎负责“看见”文字，上层任务模块负责“理解”结构。我后面集成的时候可以只替换其中某一个环节，而不需要动整条链路。
2. 表格识别：把格子线变成行列坐标
2.1 无表格线场景才是真难题
表格识别里最难处理的方案我心里有数：不是有线表格，而是无线表格。有线表格至少能靠线段检测辅助定位单元格边界，无线表格整个版面只有文字和间距，机器要凭空判断哪些文字属于同一逻辑行、同一逻辑列，难度直接翻倍。
这套国产 OCR 方案对两类表格都做了处理，但精度表现差异明显。我在实测里用了一张印刷清晰的电子表格截图，结构还原准确率能到九成以上；但换成一张扫描版手填表格，由于纸张有底色、表格线有断裂、文字有压线，准确率会明显下降。
所以表格识别的核心不是模型本身，而是预处理有没有做干净。二值化、去噪、倾斜校正这三步缺一不可。倾斜校正尤其关键，因为只要页面倾斜超过两度，表格线的检测就会全面失真。
2.2 表格结构输出的数据格式长什么样
表格识别模块的输出绝不是一张“带文字的图片”，而是一个结构化的 HTML 表格片段或者带坐标的单元格数据列表。我这边拿到的是后者，每个单元格包含行号、列号、行合并跨数、列合并跨数、以及识别文本。
有了这套数据结构，转成 Excel 或者 JSON 输出就只是写个几十行的序列化脚本的事。关键的坑在于合并单元格——模型返回的行列坐标是逻辑坐标，不是像素坐标，如果你不了解这一点，转坐标的时候强行套用像素位置，必然对不上。
下面是我在代码里处理表格输出的一个核心片段，逻辑很清晰：先把每个单元格的文本按行列号填进一个字典矩阵，再根据合并信息构造 Excel 的合并区域。
import pandas as pd def table_results_to_dataframe(table_res): # table_res 结构: [{ "row": 0, "col": 0, "text": "姓名", "rowspan": 1, "colspan": 2 }, ...] max_row = max(cell["row"] + cell["rowspan"] for cell in table_res) max_col = max(cell["col"] + cell["colspan"] for cell in table_res) matrix = [["" for _ in range(max_col)] for _ in range(max_row)] merge_map = {} for cell in table_res: r, c = cell["row"], cell["col"] matrix[r][c] = cell["text"] if cell["rowspan"] > 1 or cell["colspan"] > 1: merge_map[(r, c)] = (cell["rowspan"], cell["colspan"]) df = pd.DataFrame(matrix) if merge_map: # 这一步用 openpyxl 写入时再合并对应区域 for (r, c), (rs, cs) in merge_map.items(): df.merge_cells(r, c, r + rs - 1, c + cs - 1) # 伪代码示意 return df2.3 表格识别踩过的三个坑
先说说表格线断裂的问题。扫描件的表格线经常是断的，而有些模型的表格结构头会对断线很敏感，一个行没闭合就可能导致整行单元格识别错位。我的处理办法是识别前在预处理阶段做一次形态学闭运算，把短的断线尽量接上。
然后是单元格内文字溢出。文字超出单元格边界时，模型有时会把文字归到邻格去。这个没有特别好的模型侧解法，我一般会在后处理里做一次校正：如果识别出的坐标跨越了表格线坐标，就把溢出的文本按比例回退到原单元格。
最后要提醒的是，千万别让表格区域走普通文字检测流程。表格区域如果被普通检测模型切碎，后续结构还原等于空谈。所以流程设计上必须先在版面分析阶段把表格区域识别出来，再单独分流。
3. 多栏版面分析：让阅读顺序回归正常
3.1 版面分析的输出是什么
版面分析模型做的事情，是给页面上每个区域贴一个语义标签和一组坐标框。标签一般分正文、标题、图片、表格、页眉页脚这几类。有了这些标签，系统才知道每个区域该怎么处理。
这张区域列表本身就是极有价值的结构化信息。拿它去做段落重排，多栏文档就能从左栏到右栏正确阅读；拿它去做信息抽取，比如只抽标题和正文，也只需要多写几个过滤条件。
3.2 识别顺序重排的关键代码
版面分析出来之后，按阅读顺序排列区域这块主要靠坐标计算。我整理了一套实际能用的逻辑：先按区域 y 坐标粗略分行，再在同一“行高度带”里按 x 坐标排序。这样做的好处是能够处理两个栏目的高度差不完全对齐的情况。
def sort_regions_by_reading_order(regions, overlap_threshold=0.3): # 先按 y0 坐标排序 regions_sorted = sorted(regions, key=lambda r: r["y0"]) lines = [] for reg in regions_sorted: placed = False for line in lines: # 判断是否与当前行高度带重叠 if line_overlap(line, reg, overlap_threshold): line.append(reg) placed = True break if not placed: lines.append([reg]) # 每个行高度带内，按 x0 从左到右排 ordered = [] for line in lines: line_sorted = sorted(line, key=lambda r: r["x0"]) ordered.extend(line_sorted) return ordered这套逻辑处理标准双栏完全没问题，但有个边界情况要注意：遇到通栏大图或者跨栏标题，它会被排到某个栏的中间位置。我实测中遇到这个问题的概率不低，稳妥的办法是额外加一条规则：如果区域宽度超过页面宽度的三分之二，就把它单独抽出来排到整段之前。
3.3 版面分析模型的精度边界
说到精度，坦白讲版面分析模型对扫描文档的敏感度要高于电子文档。电子版 PDF 的文字边缘清晰、区块分明，准确率很高；扫描文档如果角度不正，或者扫描光线不均匀导致一半亮一半暗，区域边框就会偏移。
我在测试中遇到过一个很有意思的情况：页面上有一个左对齐的小段引用，模型把它和上一段正文合并成了同一个区域。解决方案不是调模型，而是在后处理里检测段落间距：如果同一区域内部文字块之间的 y 间距明显大于正常行距，就把它按行距阈值拆成两个区域。这类“模型输出不满足需求，用后处理规则补齐”的思路，在实际工程里比重新训练模型要快得多。
4. 手写识别：比印刷体难在哪些环节
4.1 手写和印刷体在模型层面的差异
手写识别的本质难点在于形变空间太大。印刷体汉字是规范化的方块字，结构稳定，模型学起来容易；手写汉字讲究“同字异形”，每个人写出来的起笔、连笔、结构比例都不一样。
所以手写识别必须用专门在数据上训练过的模型。我用的这套方案里，手写识别走的是独立的分支模型，和印刷体识别模型不共用网络参数。实际效果差别非常明显：印刷体模型去认手写，正确率可能只有六成；换上手写专用模型之后，同样的测试样本正确率能拉到八成以上。
4.2 手写识别推理参数怎么调
手写识别和印刷体识别有一组很关键的前处理差异：手写文字框往往更扁更矮，而且字符间距不均匀。如果直接沿用印刷体的检测配置，很容易把两个字黏在一个框里。
我实测下来的参数配置是这样：检测框的宽度阈值相对放宽，因为手写文字经常略微倾斜导致检测框偏大；识别阶段的均值方差归一化参数保持默认，但输入图像分辨率建议统一到 32 倍数的长度，避免边界拉伸变形。
还有一个很多文章不提的细节：手写识别的图像，尽量先转成灰度图再做归一化，不要直接彩色图推理。彩色图里有背景色干扰时，模型注意力容易被分散。这是我对比多次之后觉得最稳定的做法。
4.3 手写模型的实际表现与分析
把话放在前面：手写识别能达到的水平是“辅助人读”，不是“顶替人读”。字形工整的样本，正确率确实可观；但潦草样本还是会大量出错，尤其是形近字之间的混淆。
我拿一批实际业务里的手写数字和手写汉字样本测过，数字识别率明显高于汉字，单字汉字识别率比连笔词识别率也高出一截。原因不难理解：数字的结构复杂度远低于汉字，而连笔词里字符边界模糊的问题会大幅加重。
所以在应用手写识别时，我强烈建议叠加一层业务规则校验。比如识别报销单里的金额，识别结果不是“50”而是“5O”，你完全可以把 O 映射成 0，这就能救回一部分高置信度错误。
5. 工程集成：把表格、版面、手写拼成完整流水线
5.1 整体工程结构如何组织
我最终落地的工程结构是按“引擎层、任务层、服务层”三层来划分的。引擎层统一封装加载模型做推理，任务层分表格识别、版面分析、手写识别三个模块，服务层负责对外提供接口。
这个结构最大的好处是隔离性强。我在前期调试的时候，经常只需要改任务层某个模块的几十行代码，完全不碰其他部分。后期如果某一个模型版本需要升级，也只替换引擎层对应的模型文件，不用改调用逻辑。
5.2 流水线主流程代码
主流程逻辑其实不复杂，但分流逻辑一定要写对。我贴一下核心代码，直接用来说明整个调用顺序。
def parse_document(image_path): image = load_image(image_path) # 第一步：版面分析，得到区域列表 layout = layout_engine.analyze(image) results = {"text": [], "table_html": [], "handwritten": []} for region in layout: x1, y1, x2, y2 = region["bbox"] crop = image[y1:y2, x1:x2] if region["type"] == "table": # 第二步：表格区域走表格结构还原 table_struct = table_engine.struct(crop) results["table_html"].append(table_struct) elif region["type"] == "handwritten": # 第三步：手写区域走手写识别 text = handwritten_engine.recognize(crop) results["handwritten"].append({"bbox": region["bbox"], "text": text}) else: # 默认区域走通用文字识别 text = ocr_engine.recognize(crop) results["text"].append({"bbox": region["bbox"], "text": text}) return results这套代码串起来的业务能力，才是这个国产 OCR 项目“不再只会认字”的真正体现。区域类型判断直接决定后续处理质量，所以这里建议在实际业务里基于真实文档验证版面分析模型的标签准确率，必要时补充规则修正。
5.3 性能优化实践记录
我最初串完流水线之后发现一个性能瓶颈：直接对整页图片做检测识别，耗时偏高。后面做了两项优化，效果立竿见影。
第一项是版面分析后的区域级并发。不同区域之间的识别是相互独立的，可以用多线程并行处理。区域数量不多，开四个工作线程就基本能压满 CPU。
第二项是识别前压缩输入尺寸。很多扫描文档的原始分辨率大得离谱，但识别模型的有效输入窗口有限，盲目全尺寸推理只会在缩放阶段消耗大量算力。先把长边压到 1280 以内，实际识别效果不下降，耗时却能降一半左右。
6. 常见问题排查与避坑速查
6.1 表格线断点错误
- 现象：合并单元格被识别成两个独立单元格
- 排查方向：先在预处理阶段做膨胀闭运算补线
- 实测结论：闭运算的迭代次数建议从 1 开始逐步加，补过头会把本该分离的列黏在一起
6.2 多栏文字顺序依然错乱
- 现象：版面分析正确，但输出文字还是左右栏交错
- 排查方向：检查你的区域排序代码是不是只按 y 坐标排了，没有做高度带聚类
- 实测结论：只按 y 排序对标准版式偶尔有效，但碰上页面上有通栏小标题就一定乱
6.3 手写识别率偏低
- 现象：工整手写汉字也经常识别错
- 排查方向：确认走的是手写专用模型分支，不是印刷体分支
- 实测结论：这个原因占了七成以上的“手写识别差”反馈，很多人根本没意识到需要分流
6.4 整页识别非常慢
- 现象：单页耗时超过三秒
- 排查方向：确认是否在整页全分辨率图上做了推理，而不是先缩放
- 实测结论：压缩到适配尺寸后耗时大幅下降，这个优化建议优先做
我在实际项目里反复打磨这套流水线之后，最深刻的体会是模型能力只是下限，工程细节才决定上限。表格、版面、手写这三块能力的底层模型已经开源且足够好用，但从“模型能跑”到“业务能用”，中间隔着一整层数据清洗、参数调优、后处理规则和分流设计的功夫。如果你正被文档解析的复杂版式搞到头大，不妨照这套思路先把流水线搭起来，再逐模块去优化精度。
