OCR版面分析实战：从分区定序到开源方案选型与避坑

做文档数字化这行久了，你会发现一个挺有意思的现象：大家聊OCR，十有八九都在聊识别率——这个模型认字准不准、那个引擎对模糊图片扛不扛得住。但真正把一堆扫描件、拍照件、PDF丢进流水线跑过一遍的人都知道，认字准只是最后一公里，前面还有一大段路要走。一段双栏排版的论文，你直接喂给识别引擎，它大概率会按行从左扫到右，把左栏的半句话和右栏的半句话拼成一句莫名其妙的东西；一张带表格的报表，识别出来是一堆散落的数字，行列关系全丢；一份带页眉页脚页码的合同，每一页都混进一堆无关字符。这些问题，靠调识别模型是解决不了的，得靠版面分析。

这篇记录就是围绕版面分析这个环节展开的。它属于OCR开源项目里经常被单独拎出来、又经常被低估的一块。我打算把版面分析到底在解决什么问题、主流的开源方案各自什么脾气、怎么在自己的项目里把它跑起来、以及实际落地时会踩哪些坑，尽量讲透。适合两类人看：一类是刚开始搭文档处理流水线、还没意识到版面分析重要性的朋友；另一类是已经用上了、但效果总是不太对、想搞清楚问题出在哪的朋友。文中涉及的工具和方案都是开源生态里常见的，具体选型你按自己的场景来。

1. 版面分析到底在OCR流水线里干什么活

先把位置摆正。一个完整的文档识别流水线，粗略分可以拆成这么几段：图像预处理（去噪、纠偏、二值化）、版面分析（找出页面上的各个区域并判断类型）、区域内的文字识别、后处理与结构化输出。版面分析夹在中间，它的输出直接决定了后面识别引擎"看什么、按什么顺序看"。

1.1 不做版面分析会发生什么

我用一个具体的例子说明。假设你有一张A4纸扫描的学术论文，典型双栏布局，左上角是标题和作者，下面是摘要，然后正文分左右两栏，中间可能插一张跨栏的图或者表，页脚有页码。如果你把整页图直接丢给一个通用文字识别接口，它内部通常是按检测框的位置做行排序，遇到双栏就会出问题：它可能把左栏第一行和右栏第一行当成同一行，因为它们的纵坐标接近。结果就是你拿到一段读起来逻辑断裂的文字，句子被拦腰截断又错位拼接。

再比如表格。表格里的文字识别本身不难，难的是恢复结构。你得先知道这块区域是表格，才能对它用专门的表格结构识别逻辑；如果当成普通文本区处理，单元格之间的对应关系就彻底丢了。还有页眉页脚，很多正式文档每页都有公司名、文档编号、页码，这些内容对正文理解是噪声，但如果整页统一识别，它们会混进正文流里，干扰后续的检索和抽取。

所以版面分析的核心价值，说白了就三件事：分区（把页面切成有意义的块）、分类（判断每块是正文、标题、表格、图片还是页眉页脚）、定序（给出符合人类阅读习惯的阅读顺序）。这三件事做扎实了，后面的识别和结构化才有基础。

1.2 版面分析和文字检测不是一回事

这里有个概念经常被混淆，值得单独说清楚。文字检测（text detection）回答的是"哪里有字"，输出是一堆文字行的包围框；版面分析（layout analysis）回答的是"这块区域是什么、它和别的关系怎样"，输出是区域级别的框加类别。粒度不一样，目的也不一样。

一个页面可能有几百个文字行框，但只有十几个版面区域。文字检测是识别的前置，版面分析是理解的前置。有些轻量方案会用文字行框的密度和排列规律去反推版面结构，比如一行文字特别长且横跨整页，可能是标题；文字行密集且等宽排列，可能是正文栏。这种启发式方法在简单版面上能用，但遇到复杂排版就露怯。真正稳的做法还是用专门的版面分析模型，把区域检测和分类一起做掉。

1.3 阅读顺序为什么是个独立难题

分区和分类做完，很多人以为就完事了，其实阅读顺序才是最容易翻车的地方。人类看双栏文档，眼睛会自动先读完左栏再读右栏，遇到跨栏元素会跳过去再回来。但机器不知道这个约定，它只看到一堆框的坐标。

阅读顺序的确定，本质上是在区域之间建立一个偏序关系。简单版面可以按"先上后下、先左后右"的规则排，但一旦有多栏、有跨栏图、有侧边栏注释，规则就不够用了。学术论文里图注在图的下方、表注在表的上方，这些约定也得考虑进去。有些开源方案会专门训练一个阅读顺序预测模块，把区域框和类别作为输入，输出一个排序；也有方案用简单的几何规则加启发式修正。这块的复杂度经常被低估，实际项目里阅读顺序错了，下游的信息抽取基本就废了。

2. 主流开源版面分析方案的脾气对比

开源生态里做版面分析的项目不算少，但路数差别挺大。有的走轻量规则路线，有的走深度学习检测路线，有的干脆把版面分析和文档解析打包成一个完整工具链。选型的时候不能只看指标，得看你的文档类型、部署环境和对结构化的要求。下面这张表是我自己整理的一个横向对比，参数和结论基于常见实践，具体数值你以各项目官方文档为准。

2.1 规则派：投影法为什么在固定版式上依然好用

投影法的思路特别朴素：把图像按行或按列做像素投影，文字密集的地方投影值高，空白的地方投影值低，于是空白处就成了天然的分割线。对于版式高度固定的文档，比如某种标准发票、某种固定表单，投影法又快又稳，还不需要任何模型和标注数据。

我在一个票据类项目里就用过这套思路。票据的字段位置基本固定，先用投影切出几个大区块，再在每个区块里做识别，准确率和速度都很理想。但它的边界也很清楚：一旦版面有轻微旋转、有跨区的表格线、或者文档类型不统一，投影法就会切错。所以规则派适合"版式已知且稳定"的场景，不适合"什么文档都来一点"的通用场景。用之前先问自己一句：我的文档版式是不是真的固定？如果答案是"大部分是但有例外"，那规则派只能当预处理，不能当主力。

2.2 检测派：把版面区域当目标来框

深度学习路线里最直观的做法，就是把版面分析当成目标检测任务：正文区、标题区、表格区、图片区各是一个类别，模型学的是把这些区域框出来并分类。这条路线的优点是类别体系可以自己定，想加"公式区""页眉区"都行，只要你有标注数据。

代价是标注成本。版面区域的标注比文字行标注粗，但依然需要人工画框、定类别，几百页起步才能训出一个像样的模型。而且文档版面的长宽比分布很极端——标题可能是又扁又宽的一条，正文栏可能是又高又窄的一块，通用检测模型里常用的锚框设计未必适配，需要针对文档特点调整。这也是为什么有些团队直接用文档专用检测模型，而不是拿通用检测框架硬套。

2.3 端到端派：省事但别指望它什么都对

端到端文档解析工具是这几年比较受欢迎的一类，输入一张文档图或PDF，输出带结构的文本，中间的分区、分类、识别、排序它全包了。对快速验证和通用文档处理来说，这类工具确实省心，几行代码就能跑出结果。

但省心的另一面是黑盒。当结果不对的时候，你很难定位是分区错了、分类错了还是排序错了。而且这类工具通常对文档类型有隐含假设，遇到特别偏门的版式，效果会明显下滑。我的建议是：端到端工具适合做基线（baseline），先跑一遍看看整体效果，再决定哪些环节需要自己接管。如果你的业务对某类文档的结构化要求很高，最终大概率还是要拆开自己控制每个环节。

2.4 选型时我实际会看的几个维度

光看对比表不够，实际选型我会重点确认四件事。第一是类别体系是否覆盖我的需求，有些模型只分正文、标题、表格、图片四类，但我可能需要区分页眉页脚和脚注。第二是输入分辨率的适配，版面分析对分辨率比文字识别更敏感，太小的图会让小区域检测不出来。第三是推理速度和部署形态，能不能在目标环境跑起来、单页耗时多少。第四是许可证，开源不等于随便用，商用前一定看清楚。

提示：选型阶段别急着上最重的模型。先用一小批真实文档跑几个候选方案，人工看分区和排序结果，比看论文指标有用得多。指标高的模型在你的文档类型上未必最好。

3. 把版面分析跑起来：从环境到第一版结果

这一节讲落地。我按"最小可跑通"的思路来组织，先让流程转起来，再谈优化。具体命令和接口以你选定的项目文档为准，这里给的是通用路径和关键注意点。

3.1 环境准备里最容易被忽略的两件事

第一件是图像分辨率。版面分析模型通常在固定输入尺寸上训练，比如把短边缩放到某个值。如果你的原始扫描件分辨率很高（比如600dpi），直接缩放会丢失小区域细节；如果分辨率太低，小字区域又检测不出来。我的经验是把页面短边控制在1000到1600像素这个区间做版面分析，既能保住区域结构，又不至于让推理太慢。这个值不是死的，得拿你的文档试。

第二件是PDF的处理方式。很多文档是PDF，但PDF分两类：一类是原生带文字层的，一类是扫描图。原生PDF可以直接抽取文字和坐标，根本不需要走图像识别；扫描PDF才需要先渲染成图再做版面分析。实际项目里经常混着来，所以流水线第一步应该是判断PDF类型，别一股脑全渲染成图，白白浪费算力还损失精度。

# 判断PDF是否带可抽取文字层的思路示意 import fitz # PyMuPDF def has_text_layer(pdf_path, sample_pages=3): doc = fitz.open(pdf_path) for i in range(min(sample_pages, len(doc))): page = doc[i] text = page.get_text().strip() if len(text) > 50: # 阈值按实际情况调 return True return False

这段逻辑很简单，但能帮你省掉大量不必要的图像处理。阈值50是我随手写的，实际要按文档类型调，比如纯图封面页文字少是正常的，多采样几页更稳。

3.2 版面分析模型的输入输出长什么样

不管用哪个方案，版面分析的输入基本都是一张页面图，输出是一组区域，每个区域包含包围框坐标、类别标签，有的方案还会给置信度和阅读顺序序号。坐标通常是相对坐标或绝对像素坐标，用之前一定确认清楚，不然框会画偏。

拿到区域列表后，第一件事是可视化验证。把框画回原图上，人眼扫一遍，比任何指标都直观。我习惯一次抽二三十页不同版式的文档做可视化，重点看三类问题：有没有该检测的区域漏了、有没有把正文和标题分错、跨栏元素有没有被切碎。这一步花的时间绝对值。

3.3 按区域裁剪再识别的基本流程

版面分析给出区域后，标准流程是：按阅读顺序遍历区域，对文字类区域裁剪出来送识别，对表格区域送表格结构识别，对图片区域单独保存或跳过。这里有个细节：裁剪时要在框的基础上外扩几个像素，避免文字边缘被切掉导致识别丢字。外扩量按分辨率定，一般几个像素到十几个像素。

# 按区域裁剪并外扩的示意 def crop_with_padding(image, box, pad=8): x1, y1, x2, y2 = box h, w = image.shape[:2] x1 = max(0, x1 - pad) y1 = max(0, y1 - pad) x2 = min(w, x2 + pad) y2 = min(h, y2 + pad) return image[y1:y2, x1:x2]

外扩不是越大越好，扩太多会把相邻区域的文字带进来，反而引入噪声。双栏文档里两栏间距小，外扩过量很容易串栏，这点要特别注意。

3.4 阅读顺序的落地处理

如果用的方案自带阅读顺序输出，直接用；如果没有，就得自己排。我的做法是分两步：先按区域类别和几何位置做一个初始排序，再针对跨栏元素做修正。初始排序可以用"先按纵向分带、带内按横向"的规则，跨栏的大图或大表单独识别出来，在排序时把它前后的区域接上。

这块没有银弹，规则要按你的文档类型调。学术论文和商业报告的排版约定就不一样，前者图注在下、表注在上，后者可能完全相反。我的建议是先把最常见的几种版式各挑几页，手工标出正确阅读顺序，然后拿你的排序逻辑去对，对不上的地方就是规则要补的地方。

4. 实际落地时那些文档里不会写的坑

前面讲的是"应该怎么做"，这一节讲"实际做起来会怎么翻车"。这些经验基本都是从返工里攒出来的，文档里通常不会写。

4.1 倾斜和透视：预处理没做好，后面全白搭

扫描件轻微倾斜是常态，拍照件透视变形更严重。版面分析模型对倾斜有一定容忍度，但超过几度，区域框就会歪，裁剪出来的文字也跟着歪，识别率直线下降。所以预处理里的纠偏不能省。纠偏的做法是先估计页面倾斜角（可以用文字行方向、也可以用霍夫变换找直线），再旋转校正。拍照件还要考虑透视校正，用四个角点做透视变换。

我踩过的一个坑是：纠偏做过头了。有些文档本身有设计性的斜排元素（比如斜放的印章、艺术字标题），全局纠偏会把这些也掰正，反而破坏版面。所以纠偏要判断是"整体倾斜"还是"局部设计"，前者校正，后者保留。这个判断用简单的角度直方图就能做，主方向明显集中才校正。

4.2 表格和正文粘连：分类边界模糊地带

表格紧贴正文、没有明显留白的情况非常常见，尤其是密集排版的报告。这时候版面分析容易把表格的一部分划进正文，或者把正文的一段划进表格。结果就是表格结构识别拿到残缺的表格，正文识别混进表格线。

处理这类问题，我的经验是不要完全信任单一模型的分类结果，加一层后处理校验。比如检测到的表格区域，检查它内部是否有明显的横竖线结构，没有的话降级为正文；正文区域如果内部检测到大量规则网格线，提升为表格候选。这种交叉校验能救回不少边界错误。另外，表格区域裁剪时宁可稍微多留一点边，让表格结构识别模块自己去判断边界，比切得太紧导致表格缺行缺列要好。

4.3 页眉页脚的误判与漏判

页眉页脚看着简单，实际挺烦人。有的文档页眉就是一行小字，有的页眉带logo和装饰线，有的页码在页脚居中、有的在角落。版面分析模型如果训练数据里页眉页脚样本不足，就容易把它们当正文。

我的处理策略是几何先验加内容特征双管齐下。几何上，页面顶部和底部一定比例范围内的窄条区域，优先怀疑是页眉页脚；内容上，如果这个区域的文字在多页里重复出现（比如公司名、文档标题），基本可以确认。多页重复这个特征特别有用，单页看不出来，跨页一比对就清楚了。实现上可以抽取每页顶部底部区域的文本做哈希，出现频率高的标记为页眉页脚。

4.4 小目标区域：公式、脚注、图注的检测困境

公式、脚注、图注这类小区域，是版面分析里最容易漏检的。它们面积小、和正文长得像，模型稍不留神就归到正文里了。漏检的后果是：公式被当正文识别成一堆乱码，脚注混进正文干扰阅读，图注和图片失去关联。

针对这类问题，如果业务确实需要，就得在训练数据里专门补这类样本，或者用专门的公式检测、图注关联逻辑做补充。通用版面分析模型很难对所有小类别都照顾到，这是现实。我的建议是分清主次：如果公式对你的业务不重要，漏了就漏了，别为它过度投入；如果重要，就单独做一块，别指望通用模型顺手解决。

4.5 多栏文档的串栏问题

双栏、三栏文档的串栏，是阅读顺序和裁剪环节的高发问题。表现是左栏末尾的文字和右栏开头的文字被拼到一起，或者裁剪时把相邻栏的文字带进来。根因通常是栏间分割不干净，或者区域框跨了栏。

解决思路有两个方向。一是先分栏再分析，用投影法或列检测先把页面切成栏，每栏单独做版面分析和识别，最后按栏顺序拼接。这个思路对规整的多栏文档很有效。二是依赖区域框的精确性，要求版面分析输出的正文区域本身就是按栏分开的，而不是一整块跨栏区域。前者更可控，后者更依赖模型质量。我一般倾向第一种，因为分栏这一步用规则就能做得比较稳，把不确定性降下来。

5. 让版面分析结果真正可用的几个进阶思路

跑通只是起点，要让版面分析的结果在下游真正好用，还有几件事值得做。这些不是必须，但做了之后整个流水线的稳定性和可维护性会上一个台阶。

5.1 建立自己的版面评估集

没有评估集，优化就是盲人摸象。我建议从真实业务文档里抽一两百页，人工标注区域框和类别，形成一个小的评估集。不用很大，但要覆盖你的主要文档类型和典型难点（多栏、表格密集、页眉页脚复杂等）。每次调整模型或规则，都在这套评估集上跑一遍，看分区准确率和阅读顺序正确率的变化。

评估指标不用搞太复杂，区域级别的召回率和类别准确率就够用。重点是固定评估集，别每次换一批文档评估，那样结果没法比较。这套东西搭起来花不了太多时间，但能让你后面每一次优化都有据可依。

5.2 版面分析结果的结构化输出设计

版面分析的输出不该只是框和类别，最好设计成带层级和顺序的结构。比如一页文档输出成一个区域列表，每个区域带序号、类别、坐标、以及它包含的文字（识别后回填）。这样下游做信息抽取时，可以直接按序号顺序读，也可以按类别筛选。

更进一步，可以把跨页的同类区域关联起来，比如把多页的页眉页脚统一标记、把跨页表格拼接。这些结构化设计在项目初期想清楚，后面扩展会轻松很多。我见过不少项目一开始只输出裸框，后面要做检索和抽取时发现结构信息不够，又回头重构，成本很高。

5.3 规则和模型的混合策略

纯模型和纯规则都有短板，实际项目里混合用往往效果最好。模型负责主体分区和分类，规则负责后处理修正和边界情况兜底。比如模型输出的区域，用规则检查有没有重叠、有没有异常小的碎片区域、阅读顺序有没有明显违反几何直觉的地方，发现问题就修正。

这种混合策略的好处是可控。模型升级换代时，规则层可以作为稳定器；规则覆盖不到的复杂情况，模型来兜。关键是规则要写得克制，别写一大堆互相冲突的启发式，那样维护起来是灾难。我的原则是：每条规则都要能说清楚它解决什么具体问题，说不清的就别加。

5.4 性能与并发的现实考量

版面分析模型推理是有成本的，尤其是处理大批量文档时。几个实际优化点：一是按需分析，原生带文字层的PDF直接走文字抽取，不跑图像版面分析；二是批处理，多页一起送模型比逐页送效率高；三是缓存，同一文档重复处理时缓存版面结果；四是降级策略，对版式简单的文档用轻量规则先过一遍，复杂的才上重模型。

并发方面要注意模型实例的资源占用，GPU显存有限时别盲目开高并发，容易OOM。我的做法是控制并发数在显存能承受的范围内，用队列削峰。这些工程细节看着琐碎，但直接决定流水线能不能稳定跑起来。

6. 一些收尾的实操体会

版面分析这块，我最大的体会是：它不是一个可以一劳永逸的环节。文档类型一变、版式一复杂，之前调好的参数和规则就可能失效。所以与其追求一个万能方案，不如把流程设计成可观测、可调整的——每个环节的输出都能可视化、能评估、能替换。

另一个体会是关于投入产出的判断。不是所有项目都需要精细的版面分析。如果你的文档版式单一、对结构化要求不高，一个轻量方案甚至规则派就够了，没必要上重模型。但如果你的业务依赖文档结构（比如合同要素抽取、报表数据提取、论文信息整理），那版面分析就是地基，值得认真对待。先想清楚下游要什么，再决定这一层做到什么程度，比盲目堆模型务实得多。

最后分享一个小习惯：每次处理一批新类型文档前，先抽几页跑一遍可视化，人眼过一遍再批量跑。这个动作花不了几分钟，但能提前发现大部分版式适配问题，省下后面大量返工。