古籍PDF批量OCR识别的技术难点与工程实践

一、为什么古籍PDF批量识别是块“硬骨头”

做古籍数字化研究的人几乎都绕不开批量处理PDF：图书馆的馆藏扫描件、学术机构的影印本、民间收集的民国报刊合集，动辄成百上千页，靠人工录入既不现实也不经济。OCR（光学字符识别）本是标准答案，但把处理现代文档的通用OCR直接套在古籍上，往往在三类问题上翻车：字认不准、版面理不清、批量跑不动。

这三类问题背后，是古籍与现代文档在“字符、版面、介质、规模”四个维度上的系统性差异。理解这些差异，是设计古籍批量识别方案的前提。

二、古籍OCR的三大技术难点

2.1 字符层：繁体、异体字与生僻字

古籍用字与现代规范汉字差异巨大，可以分三层看：

• 繁简与异体差异：馆藏古籍以繁体为主，大量使用异体字、通假字、俗字；
• 生僻字：中医药籍、地方志中的专名用字常超出常用字库范围；
• 版本特有现象：避讳字、刻工省笔字等，同一字在不同版本中写法不同。

这对工程提出两个要求。其一，识别系统的字符集必须足够大，业界通常以国家标准 GB18030-2022 为基准（该标准收录汉字八万余个，包含大量生僻与繁体字形）。其二，识别之后要做“字形规范化”——把异体字映射到通行字形。例如中医古籍中“脈/脉”“癥/症”这类异体关系，若不建立映射表，检索与统计时就会因“同书异字”割裂数据。

常见做法是维护一张异体字映射表：识别结果先保留原字形（存真），再并行生成一列规范化文本（通用），两套文本同时输出，既服务文献考据，也服务下游检索。

2.2 版面层：竖排、批注与筒子页的阅读顺序

现代文档的版面分析只需处理“行、段、栏”三级结构，古籍则是另一套版面语法：

• 竖排右起：文字自上而下成列，列序从右向左，通用OCR默认的横向行切分会直接失效；
• 双行夹注：正文行内嵌小字双行注释，字号、行距不同，极易被误当作独立正文；
• 眉批、旁批、圈点：批注与正文空间交错，不分离则输出文本“注不注、正文不正”；
• 筒子页：古籍装帧扫描后，一个版面包含前后两个半叶，需先做版心切分再恢复半叶顺序；
• 多栏版面：类书、佛经等存在多栏并行，阅读顺序需“先栏内、后栏间”恢复。

共同解法是“版面分析 + 阅读顺序重排”：先把页面切分为带类型标签（正文、注文、批注、版心、图）的区块，再按古籍行款规则对区块重排序。版面结构正确，后续识别文本的拼接顺序才有意义——这是古籍OCR区别于通用OCR最核心的一步。

2.3 图像层与规模层：老旧介质 + 大批量任务

介质层面，古籍扫描件普遍存在纸张泛黄、透字、污渍、虫蛀、装订阴影与页面弯曲，显著影响二值化质量；民国报刊还有铅字压印不均、油墨洇染等印刷缺陷。

规模层面则引入纯工程问题：任务如何调度？单页失败如何重试而不重跑整批？上百个PDF如何组织与追踪？多语种混排（如汉蒙合璧文献）如何分配识别引擎？这些问题在单页演示中不可见，却在真实项目中决定成败。

三、批量识别流水线的设计

一条可落地的古籍PDF批量OCR流水线，建议按六个阶段构建：

1. 入库分类：自动判别PDF中的文本型页面与扫描图像页，文本页直接抽取内嵌文字、不做OCR——省算力省时间，在“影印正文+排印前言”的混排PDF中尤其重要；
2. 图像预处理：灰度化 → 自适应二值化 → 去噪 → 倾斜校正 → 版心切分，预处理质量直接决定识别上限；
3. 版面分析与排序：输出带类型标签的区块序列，并按古籍行款重建阅读顺序；
4. 识别调用：按区块类型与语种路由识别引擎，竖排区块传竖排参数；
5. 后处理：异体字映射、置信度过滤（低置信度字符标记待校）、标点恢复；
6. 成果输出：双层PDF（原图层+隐藏文本层，可检索可复制）、结构化XML元数据、带标点TXT。

流水线骨架可用如下伪代码表达：

for task in batch_queue:                      # 批量任务调度
    for page in task.pages:
        if page.has_text_layer:               # 文本页直接抽取，不走OCR
            emit(page.extract_text())
            continue
        img    = preprocess(page.image)       # 二值化/去噪/纠偏/版心切分
        layout = analyze(img, direction="vertical_rtl")
        for zone in layout.sort():            # 阅读顺序重排
            label = zone.type if zone.type in ("眉批","旁批","夹注") else "正文"
            txt   = recognize(zone.image, charset="GB18030")
            txt   = normalize(txt, mapping=variant_table)   # 异体字映射
            emit(label, txt, zone.box, conf=confidence)
    export(["双层PDF", "XML", "带标点TXT"])
    report(task)                              # 生成批次进度报表

三个关键设计点：

• 失败隔离：以“页”为最小重试单元，单页失败不阻塞整批，失败页进入重试队列并记录原因；
• 项目—批次两级组织：按“项目（如某典籍的多个版本）—批次（分次上传）”组织任务，天然对应文献整理的工作方式，也便于多人协作时划分权责；
• 引擎路由：为不同语种/字体配置不同引擎，混排文献按区块级别自动路由，避免逐页人工调整。

若团队选择自建方案，可在流水线中接入通用云文字识别服务作为基线引擎（如百度智能云提供的通用文字识别类能力），再在其上叠加面向古籍的预处理、字符集约束与后处理逻辑；若采购成熟的专业古籍OCR服务，同样建议把这六个阶段当作验收标准逐项核对。

四、精度提升的关键策略

4.1 建立基准测试，用数据说话

选型或验收前，务必抽取50～100页有代表性的样本（覆盖不同版式、清晰度、批注密度）做基准测试，核心指标是字符错误率 CER：

CER = (S + D + I) / N        # S替换、D删除、I插入的错误字数，N为样本总字数
字准确率 = 1 - CER

经验上，印制清晰的近代铅印本，字准确率有望达到95%以上；手抄本、批注本等复杂对象若不针对性优化，通常明显低于该水平。用同一基准集横向比较不同方案，远比看宣传数字可靠。

4.2 置信度分级 + 人工校对闭环

批量场景下人工校对绕不开，问题只是“校多少、校哪里”。合理做法是按识别置信度分级：高置信度文本直接入库存档；中置信度进入抽检队列；低置信度字符强制人工确认。再配合多人协作管理——校对任务按批次分派、修改留痕、审核日志可回溯——把有限人力集中在最需要的地方。

4.3 用文献学方法反哺识别

两个实践中非常有效的策略：

• 版本互校：同一典籍常有多个版本，识别结果可互为校对参照，两版本不一致的字位优先送人审；
• 坐标对齐存批注：批注不混入正文流，而是以“页码+版面坐标”关联到对应正文位置，输出为独立结构化层，既保证正文纯净，又保留批注的文献价值。

五、选型评估清单

无论采购商业服务还是评估自建方案，建议按以下维度逐项核对：

维度	关键问题
批量能力	单批文件数与页数上限？支持并发与断点续传？有无任务/批次管理与进度报表？
古籍适配	字符集覆盖多大？是否支持竖排、双行夹注、批注分离、筒子页切分？多语种混排如何处理？
输出合规	是否支持双层PDF、XML元数据、带标点TXT？元数据是否兼容智慧图书馆体系建设等行业通用规范？
协作支持	是否支持多人分工校对、修改留痕、审核日志同步？
成本与商务	计费模型（按页/按字）？有无免费额度供测试？能否开具发票支持科研经费报销？是否支持私有化部署？
精度验证	方案方是否接受由你方提供基准集做测试？

特别提醒两点：一是免费额度应优先用于基准测试，把精度问题暴露在签约之前，而非直接投入生产；二是对馆藏机构而言，数据安全（原件影像不出内网、支持本地化部署）往往比单价更重要。

六、落地建议与常见陷阱

1. 先试点，后全量：任何方案都先用真实样本跑通全流程（含输出格式与校对流程）再放大规模；预估工期时给人工校对留足余量——识别能把两周压缩到三天，校对才是工期大头。
2. 元数据趁早录入：书名、卷次、版本、页码对应关系等项目级元数据，应在任务创建时录入，识别完成后自动挂接，远比事后补录可靠。
3. 原件与成果双备份：处理前后保留原始PDF与识别成果的双份存储（可借助对象存储类云服务实现版本化与异地冗余），防止任务异常导致返工。
4. 警惕单指标迷信：字准确率不反映版面正确性与阅读顺序正确性，评估时务必人工通读若干页输出，检查批注是否串行、双行注是否错位。
5. 建立“错题本”：把校对中发现的高频错误（形近字、特定版面模式）沉淀为映射表与回归测试集，反哺后续批次，让系统越用越准。

七、结语

古籍PDF批量OCR的本质，是“文献学知识 + 计算机视觉 + 工程化调度”三者叠加的系统工程：字符集与异体字映射体现第一者，版面分析与阅读顺序重排体现第二者，任务组织、失败隔离与协作流程体现第三者。无论是高校团队、文化机构还是个人研究者，选型或自建时与其纠结“哪款软件最好”，不如回到本文框架——难点是否覆盖、流水线是否完整、精度是否可验证、协作是否闭环。把这四个问题答清楚，古籍数字化的路就顺了。