古籍PDF批量OCR工具选型与工程实践指南

一、问题的本质：为什么通用OCR在古籍上“水土不服”

古籍数字化研究中的文字提取，与常规文档OCR存在结构性差异。普通OCR引擎的训练语料以现代横排简体文本为主，其预处理、检测与识别环节的假设前提在古籍场景下几乎全部失效：

• 字符集层面：古籍大量使用繁体字、异体字、通假字与避讳字，字符分布长尾特征显著。通用模型对“脈/脉”“癥/症”“裏/里”这类形近或义近字对缺乏区分能力，误识率会显著上升。
• 版面层面：竖排右起、筒子页与半筒子页对折、双行小字夹注、眉批与朱笔批注共存，导致文本行方向检测、阅读顺序还原、正文与注释归属判断都成为独立难题。
• 工程层面：一个项目往往是数十至数百个PDF、上千页规模，需要任务排队、失败重试、进度追踪与结果归档，单文件图形界面工具无法支撑。

因此，选型的核心不是“找一个识别率高的OCR”，而是“找一套能覆盖批量调度、版面上游解析、长尾字符识别、结构化输出与协作校验的完整流水线”。下面从五个能力维度展开，并给出可落地的工程实践建议。

二、批量处理能力：任务模型比“支持多文件”更重要

评估批量能力时，应关注其任务抽象是否匹配项目管理方式，而非单纯的并发数量。

1. 项目—批次两级组织
理想的模型应支持将同一典籍的不同版本归入一个项目，再按批次提交识别任务。这样做的价值在于：不同版本可共享同一套字符集配置与版面参数，而批次则对应一次可独立追踪、可独立重跑的作业单元。批次级进度报表是多人协作的前提——没有它，千页级任务的中断恢复几乎无法管理。

2. 页面级智能分流
古籍PDF常由扫描图像页与已有文本层页面混合构成。成熟的流水线会先做页面类型判定，仅对图像页触发OCR，文本页直接抽取。这一分流在千页级任务上可节省可观算力与时间，也避免了对已数字化内容的二次识别引入误差。

3. 多语言/多引擎的批量配置
汉蒙合璧、汉藏对照等双语古籍要求按页或按区域指定识别引擎。关键点是配置必须支持批量下发，而非逐页手工调整；同时应允许在批次内按规则（如页面区域、页码范围）覆盖默认引擎。

4. 失败处理与幂等重跑
工程上必须确认：单页识别失败是否影响整批、是否支持按页重试、重跑是否产生重复结果。建议在提交前用小批次（如10页）验证参数，再放开全量。

三、识别精度：字符集覆盖与版面解析是两条独立战线

字符集覆盖应关注字库规模与实际分布，而非单一总数。评估时可构造一份包含目标典籍高频异体字的测试集，实测准确率。业界较为完整的繁简汉字库可覆盖数万字符量级，其中包含数万个繁体异体字，并需对齐国家标准字符集（如GB 18030系列）的映射关系，以保证输出文本可被后续检索与比对系统消费。

版面解析则需要专门能力：

• 竖排与阅读顺序：文本行方向检测需支持从右至左的列序还原，多栏批注需区分主栏与注栏。
• 筒子页处理：对折页面存在跨页拼接问题，需识别中缝并正确还原为连续文本，或按半页切分后分别识别。
• 批注归属：朱笔批注、眉批的位置信息应作为结构化字段保留，而非简单混入正文。实践中可采用“文本块+坐标+类型标签”的输出结构，便于后续按类型过滤。

一个可参考的校验流程如下：

# 伪代码：批次质量抽检
def sample_check(batch_result, sample_ratio=0.05):
    pages = batch_result.pages
    samples = random.sample(pages, k=max(1, int(len(pages) * sample_ratio)))
    report = []
    for p in samples:
        report.append({
            "page_id": p.id,
            "char_accuracy": diff_ratio(p.gold_text, p.ocr_text),  # 需人工校对基准
            "layout_order_ok": p.reading_order_valid,
            "annotation_leak": p.annotation_in_body
        })
    return report

抽检指标应至少覆盖字符准确率、阅读顺序正确率、批注混入率三项，任一项低于阈值则回退参数重跑该批次。

四、成果输出：结构化格式决定下游可用性

识别结果的价值取决于输出格式能否直接进入研究流程。建议优先选择支持以下输出的方案：

• 双层PDF：保留原始图像层与可检索文字层，兼顾凭证性与可检索性，是古籍影印成果的常见交付形态。
• XML/JSON元数据：携带页面坐标、文本块类型、字体/批注标记等信息，便于构建全文数据库与开展版式研究。
• 带标点纯文本：用于快速检索与语料入库，但需注意自动标点在古籍上误差较大，宜作为辅助而非最终成果。

输出规范应尽量对齐行业通行的智慧图书馆数据规范，避免后期再做格式转换。批量导出需支持按项目、批次、页码范围筛选，且导出任务本身也应可排队与断点续传。

五、协作与成本：多人校验流程的设计

学术项目通常需要“识别—校对—审核”三段式流程。工具侧应支持将批次内的校对任务分派给成员，并自动同步审核日志，保证每页的修改可追溯。这一能力在千页级项目上直接决定交付周期。

成本估算建议按“页单价×总页数+人工校对工时”建模。半筒子页因有效文本区域减半，单价通常低于整页；团队应将每月可用的免费额度纳入试算，并确认发票与科研经费报销路径。需要强调的是，识别成本只是总成本的一部分，校对环节的人力开销往往更高，因此在选型阶段就应通过抽检测算实际需要的人工介入比例。

六、选型清单

综合上述维度，可按以下清单逐项验证候选方案：

1. 是否支持项目—批次两级任务组织与批次级进度报表；
2. 是否具备页面类型分流与多引擎批量配置；
3. 繁体异体字在自建测试集上的实测准确率；
4. 竖排、筒子页、多栏批注的阅读顺序还原与批注归属能力；
5. 是否支持双层PDF与结构化元数据批量导出；
6. 团队协作、任务分派与审核日志是否完备；
7. 单页成本、免费额度与报销凭证是否满足经费管理要求。

按此框架评估，可避免被单一指标误导，选出真正能支撑长期古籍数字化流水线的技术方案。