词典类图书PDF文档版面自动分析、加工的初步探索

技术交流与词典编修
1

前些日子因缘际会接触了MinerU这一PDF解析转化工具，其内嵌的版面分析、要素识别等功能模块深深吸引了我，但在最终的OCR识别输出效果上却远远达不到意想中的水准。失望之余，尝试着结合GLM、Grok、Qwen等AI模型编程助手进行逆向工程，从MinerU解析架构所依赖的源头工具之一——PaddleOCR着手进行反推导，在一步步的寻绎、推阐中累计创出三千多行的代码成果。
我主要的思路是调用PaddleOCR中的PP-StructureV3模型产线，在可视化界面对电脑本地pdf文档版面各个要素区块进行分析、加工，集成有版面要素分析标注、特定要素区块马赛克色块掩覆、基于页面解构的分栏裁切、加工图像导出等功能模块，初步测试阶段选定的样本是汉语大词典部分内页样张，相关参数的设置也是根据该词典内页版面布局而定，移用到其他词典需要有针对性地进行个别参数调改。
因为仅是初步探索的产物，各种缺憾在所难免，比如：
一、代码运行效率方面：一者，鉴于个人笔记本是普通的商务本，仅有集成显卡，在硬件受限的情况下缺乏GPU版本可有的cuda算子加持，代码运行进程稍显迟缓，在小体积的PDF样本测试已见端倪，应用到成规模的正式文档上估计会有“小马拉大车”的吃力感。二者，也可能由于PDF导入时先行重构为图像，相关预处理参数调试不当导致。
二、代码再编译方面：因为全程高度依赖于AI大模型进行编程作业，从初始的单功能模块实现起步，代码层层堆叠，嵌入各种功能模块后俨然是一座代码山，各种历史代码、标注残痕在所难免，整体臃肿的弊端之一就是阻碍代码的释读、优化。
缘此，坛友在进行具体应用实践中，有必要结合PaddleOCR的示例教程、参数说明进行相应调试。

操作界面截图：

局部截取_20250809_172508
局部截取_20250809_1725081458×934 359 KB

局部截取_20250809_172544
局部截取_20250809_1725441459×938 354 KB

代码及测试样本：

test1（glm·全功能模块v2）.py (130.5 KB)

新建12.pdf (1.4 MB)

MinerU在线使用地址：

PaddleOCR相关产线使用教程地址：

★★★截至9月22日最新版本代码——
test1（glm·全功能模块v3）.py (219.6 KB)

相较于最初发布版本，主要的改进点体现在——
改进1：复盘官方使用教程中的方法/参数说明，对部分可增设的参数项（device、enable_hpi、use_tensorrt、precision、enable_mkldnn、mkldnn_cache_capacity、cpu_threads等）在代码中进行补充。
改进:2：UI界面增设“高级参数设置”模块（弹出式新窗口，融合上下、左右滚动条功能，使得输入框设置参数时可以醒目看到设置的数值），使得在执行版面分析前可以对img_size、threshold、layout_unclip_ratio、layout_merge_bboxes_mode四项参数进行设定。同时引入参数值定型记忆功能，保持最近一次的具体设定（重新运行代码启动界面时仅需在UI面板参数模块模块点击确定（“OK”）进行激活）。
改进3：增加参数测试验证环节，在参数设置模块设定相关参数后、执行全局性分析动作前可以对导入的PDF进行选页测试，选择一定页数/比例/范围页码的图像进行参数设定效果预览（版面标注效果检验的预览窗口与“版面标注图像”窗口合一），方便根据效果进行动态调试。UI界面同步增设“局部分析”模块。
改进4：引入智能分栏算法（原分栏逻辑仅是简单粗暴的等宽分栏），基于检测到的特定类型版面要素区块——文本（text）区块的位置信息来进行裁切分栏，确保分栏裁切后text区块不存在跨栏现象。UI界面同步增设“预览分割线”模块，实现在标注图像上显示栏位分割线绘制预览，以预判基于当前算法逻辑的分栏裁切是否存在偏差。
改进5：优化进度条显示，更精确显示当前处理进度节点和预估剩余时间。

待进一步改进优化的地方 or 仍然存在的问题点——
一、分栏裁切是基于正文（text）要素区块的识别而进行的，若同一页该要素区块均无法正确识别则仍按照等宽分栏进行裁切动作。若同一页存在跨栏位的要素区块，例如图像（image）要素区块，该缺块将一分为二。
二、执行版面分析前，导入的PDF将进行转换为图片格式的先置动作，致版面图像“雾面化”（清晰度下降），间接影响各要素区块的识别精度以及导出的PDF/图片的清晰度。后续可探索参照官方体验平台直接导入图片格式图档的方式。

9 个赞
2

图书、词典的版面一般来说比较简单，它并不是目前阻碍中文OCR的瓶颈。我的体验是当下ai模型OCR的主要问题是可识别的字库容量太小，通常是6000-8000字上下，对于通俗文艺作品、普及性的学术著作、理工政经商图书等问题不大，但涉及稍微专业一些的古籍、文史类著作，就力不从心了。

这并不是不可解决的，云聪的ocr软件号称可以识别8万字。从实用的层面讲，OCR软件能识别15000-20000汉字基本就差不多了，20000以外不是异体字，就是死字（即没有实际用例，所以《汉语大词典》就只收2万单字），通用工具可以不管。

目前开源的OCR模型，很多是以qwen 3b等为base model的，这一系列的视觉模型就只能识别8000汉字左右，有这种取舍，可能是为了把固定总参数的性能压缩到极致，毕竟它是视觉模型，不是ocr模型，不愿把参数浪费在认为不必要的生僻字上。

3

你说的在理，用户群规模决定了OCR的发展方向。就经济层面而言，正常日常阅读、交流中6-8千常用字已经可以涵盖几近百分百的需求了。专用模型把精力投入到生僻字的识别上确实不上算，甚至有可能故此失比。即便像识典有开辟专用古籍场景的OCR识别，现在也还只是堪堪可用，需要大量的志愿者（调参员）在校读过程中以改助识，慢慢调高精度。关于这个版面自动分析就只是一个小小的实验而已，更多是基于我现在的OCR需求而来的，略带点任务导向性质，也是跟坛友haoshu君交流中意外催生出来的

4

对于欧美使用拉丁字母的人士来说，OCR实际上是一个已经解决了的问题，目前的工具可以达到很高的识别精度，对于目前研发ai模型的中文理工男来说，很多没什么文史素养或阅读需求，古籍、中文生僻字等于不存在，所以当下并没有优异趁手的开源中文词典OCR工具。

5

还行吧，科技公司硬堆人力，总会改进提升的 :sweat_smile: 夸克就是一个例子，短短几年进步神速，感觉未来完全有可能把不思进取的扫描全能王死死摁在替补席上

6

商业模型，合合、百度高精度、夸克这些已经做得不错了，但收费昂贵，现在实际比较划算的是api调用 Gemini 2.5 Pro 或者 ERNIE-4.5-VL-28B-A3B（它指令服从性差，需要较多的后续编辑工作）。

7

我的看法跟你相反，夸克、扫描王等专用模型才是主力工具，其他发散性较强的视觉大模型现在还没办法取代前者，api调用识别文本量一上来，反倒不划算。不过未来谁也说不准，说不定有适应性更佳且开源的古籍ocr模型可以用的上

1 个赞
8

就效率高而言，当然是专用工具强，我说的是api直接调用费用比较，至于夸克、扫描王这些包月等费用怎么算的，我不大清楚。

9

中文（也包括多种外语）的OCR识别专用模型，我估计1b以内的参数就足够了，可以达到夸克、合合、百度高精度等的识别性能，但像Gemini 2.5 Pro这种模型，参数是和deepseek r1、kimi k2等一个量级的，用来OCR实际成本会高很多。

10

这个自动分析感觉只能分块，不太能实际提取结构。我最近做日语anki卡组的时候用了另一个思路，就是首先pdf用chrome自带的pdf加文本层处理然后保存（实际OCR效果还不错）。然后用python解析pdf提取文本，这里需要自己写逻辑根据位置等信息分块提取，提取后除了把文本保存外，pdf中的位置信息也保存到json中。 然后我另外用python的nicegui写了一个校对程序，主要用来校对假名注音（因为字非常小识别的根本没法用，只能另外用NLP工具加）。可以自动切片pdf，显示图片原文和解析后的文本，还能自动查可选读音。

效果大概这样，点击以后会更新读音然后自动保存：

image
image1025×869 137 KB

1 个赞
11

miner我只用自带的免费api试了下，处理简单版面的pdf的识别还行，词典类pdf，内容庞杂，版式复杂，不容易识别啊。

12

你的问题我有考虑过，我的思路是在导出的区块图像（按我代码逻辑，导出的区块图像是有按页码、栏位、上下顺序等进行命名的）设置条件筛滤，对部分跨栏、跨页的词条进行选择性拼组。这个如果需要的话我会另外编写代码脚本进行后续处理。我执行版面分析标注操作更优先考量的是分栏裁切、页眉页码插图掩码的需要

13

mineru之前和之后又涌现出了许多类似工具，包括有近日入局的的dots.ocr（小红书团队研发，部分网友锐评带有黑马潜质），无一例外都在最后一关OCR上发挥的不是那么完满 :laughing:

14

这一点也是最关键一点，ocr不完美，那就得累死大佬。

15

“识典古籍”APP正在干这样的事情。

而中华书局、上海古籍这些收费的APP平台反而要花大钱去搞生僻字OCR

16

预处理是文本识别里最重要的一环。词典 ocr 第一步就要做版面拆分双栏变单栏，然后单栏合并成一页再去识别，有妨碍识别效果的文本需要用白色贴条先挡掉，比如顶部和侧边的页码，日文的话也类似，需要先把注音假名用白色贴掉。

如何分栏拆分和贴条直接问 ai 就行了，现在都很简单了。

17

生僻字OCR自身没什么技术上的难度，无非是把这些字加入训练样本而已。要求不高的话，图像样本都不用去找，可以文本→图像大量合成，训练时颠倒顺序：图像→文本。

不过这里有一个是否必要的tradeoff，比如一个模型只能识别“或”字，每次都会把“彧”认成“或”，另一个模型则能识别分辨“或”和“彧”，但有1%的可能把“或”认成“彧”。假设“彧”出现的概率只有“或”的千分之一或者万分之一，能识别更多的生僻字反而会导致更高的错别率，反而成得不偿失了。

1 个赞
18

本质上都是走的众包，区别在于识典是爱心发电为主，义务校员的水平也是参差不齐 :laughing:

19

ai is all we need :grin:

20

嗯嗯，参数量不必很大，阿里的7b模型只要硬件够3090马马虎虎都能跑了，当然远程调用api接口就比较吃亏了。你去看看夸克的年费价，会有惊喜 :grinning_face_with_smiling_eyes: