古籍OCR批量识别：技术选型与落地实践

一、问题的提出：古籍OCR为何难做

古籍数字化是文化传承与学术研究的基础工程，而OCR（光学字符识别）是其中最关键的一环。与普通印刷文档不同，古籍OCR面临几类叠加的困难：

• 版式复杂：竖排、从右至左的阅读顺序，双行夹注、眉批、边框、鱼尾等版式元素普遍存在，通用OCR模型往往按现代横排版式切分文本行，导致输出顺序错乱。
• 字形特殊：繁体字、异体字、俗字、避讳字大量出现，部分字形在现代字库中甚至没有对应编码，识别模型必须具备较强的古文与繁体字符集覆盖能力。
• 图像质量参差：扫描件常有透印、污渍、折痕、页面弯曲等问题，二值化与版面分析稍有不慎就会丢失笔画信息。
• 批量处理需求强：整本古籍动辄数百页，逐页手工上传、逐页校对的时间成本极高，能否批量化直接决定项目可行性。

因此，评价一款OCR方案是否“识别率高”，不能只看单页demo的观感，而要看它在批量、复杂版式、繁体字形三个维度上的综合表现。市面上能做到批量处理、正确还原古籍阅读顺序、且错误率可控的方案并不多；面向公众开放的在线演示界面通常有人工配额与频次限制，难以支撑整本书的处理需求。这正是许多开发者转向“批量接口 + 视觉大模型”自建流水线的动机。

二、技术选型：三条主流路线及其取舍

从工程角度看，古籍OCR大体有三条路线，各有适用边界。

路线一：商用OCR服务。 通用云厂商的文字识别能力成熟，部分厂商针对古籍场景做过专项优化，识别率在理想图像上可以做到很高。但其短板在于：按页计费的模式在整本书规模下成本可观；部分高精度能力仅面向机构合作开放，个人开发者难以直接调用；输出格式多为通用阅读顺序，对竖排夹注的还原需要额外后处理。

路线二：开源OCR引擎自建。 开源方案自由度高、无调用成本，但古籍场景下需要自行完成版面分析、方向检测、字符集适配等大量工作，且对繁体异体字的召回往往不足，调优周期长。

路线三：视觉大模型 + 批量接口。 这是近年兴起的路线。多模态大模型具备较强的版面理解与古文字形识别能力，配合云厂商提供的批量异步接口，可以在成本可控的前提下完成整本处理。其代价是需要自行设计提示词、输出格式约束与校验环节。

综合来看，对于数据安全与隐私要求不高、以公域数据为主、面向私域使用的场景，路线三是性价比最高的选择。需要强调的是，若扫描件涉及未公开的孤本、拓片或敏感资料，应优先选择可私有化部署的方案，避免数据出域。

三、方案设计：批量OCR流水线的四个阶段

一条可复用的古籍OCR流水线可以拆解为四个阶段：预处理、任务封装、批量识别、后处理与校验。

3.1 预处理：从PDF到单页图像

第一步是把扫描版PDF逐页导出为图像。建议统一分辨率为300dpi左右的灰度图或彩色图，过高的分辨率会显著增加单页token消耗与传输耗时，过低则损失笔画细节。导出后应建立“书名/页码”的稳定命名规则，便于后续结果回填与人工校对定位。

对于页面弯曲、透印严重的扫描件，可在导出前做轻度的去噪与纠偏；但要注意，过度二值化可能抹掉淡墨笔画，建议保留原始灰度图作为备份。

3.2 任务封装：提示词与输出格式约束

视觉大模型的输出质量高度依赖提示词设计。针对古籍场景，提示词至少应明确以下几点：

1. 阅读顺序：声明按竖排、从右至左的顺序输出，双行夹注需标明归属关系；
2. 字符策略：要求保留繁体原字形，对无法确认的字以占位符标注而非臆测；
3. 输出结构：约定为纯文本或带页码、栏位的结构化格式，便于后续解析；
4. 拒绝幻觉：明确要求不得补写、改写或翻译原文内容。

示意性提示词如下：

你是一名古籍转录员。请将图像中的文字按竖排、从右至左的顺序转录为横排文本。
要求：
- 保留繁体原字形，不做简繁转换；
- 双行夹注以【注：...】包裹并紧随其所属正文；
- 无法辨认的字用□代替，不得猜测补写；
- 仅输出转录结果，不要添加任何解释。

输出格式建议采用带分隔符的纯文本或轻量结构化文本，避免要求模型生成复杂嵌套结构，否则解析失败率会上升。

3.3 批量识别：异步接口的组织方式

整本处理的关键在于批量化。主流云厂商的批量接口通常采用“提交任务—轮询状态—下载结果”的异步模式，适合大规模、非实时的处理需求。工程上需要注意：

• 任务分片：按页码或每若干页一个任务进行分片，单任务过大易触发超时，过小则增加调度开销；
• 并发控制：设置合理的并发上限与重试退避策略，避免触发限流；
• 结果映射：每个任务的标识中携带页码信息，确保结果可按页回填；
• 断点续跑：记录已完成页码，任务中断后可从断点继续，避免重复计费。

以伪代码示意任务提交与轮询的基本结构：

# 伪代码：批量OCR任务的组织方式
tasks = []
for page in pages:
    task = client.submit(
        image=page.image_path,
        prompt=OCR_PROMPT,
        meta={"book": book_id, "page": page.number}
    )
    tasks.append(task)
for task in tasks:
    result = client.wait(task, timeout=600, retry=3)
    save_result(task.meta, result.text)

实际实现时，提交与轮询应解耦，先批量提交再统一轮询，可显著提升吞吐。

3.4 后处理与校验：把错误率压下去

模型输出不等于可用文本，后处理是保证质量的关键环节：

• 格式还原：将带页码、栏位标记的文本还原为连续正文，按原书顺序拼接；
• 规则校验：检查占位符比例、异常字符比例、页均字数是否落在合理区间，超阈值的页面标记为“需人工复核”；
• 交叉比对：对已有电子版的常见古籍，可将OCR结果与既有文本做粗粒度比对，快速定位差异段落；
• 抽样人工校对：按比例抽样精校，既控制成本又能评估整体质量。

经验上，经过提示词约束与规则校验的流水线，在清晰扫描件上的可用率可以做到很高；模糊页面与异体字密集的段落仍需人工介入，这一点应在项目排期时预留工时。

四、成本与合规的边界

采用批量接口 + 视觉大模型的方案，成本主要由图像token量与调用页数决定，整本书的处理费用通常远低于按页计价的商用服务。但需注意两点边界：

其一，数据边界。该方案适用于公域数据与对隐私要求不高的场景。涉及版权保护期内的整理本、未公开的馆藏资料，应改用私有化部署或离线方案。

其二，质量边界。大模型存在幻觉风险，即便提示词明确禁止补写，仍可能出现个别臆测字符。因此任何自动转录结果都不应直接作为最终定本，必须保留人工校勘环节，这也是古籍数字化的行业惯例。

五、小结

古籍OCR的核心矛盾在于“批量、版式、字形”三者的兼顾。商用服务精度高但成本与开放性受限，开源引擎自由但调优成本高，而“视觉大模型 + 批量异步接口”的组合提供了一条成本可控、可批量、格式可约束的中间路线。落地时把握四个要点：合理的预处理分辨率、严格的提示词与输出格式约束、健壮的批量任务调度、以及不可省略的后处理校验。把这条流水线搭好，整本古籍的数字化就从“逐页手工”变成了“一次提交、分批回收、抽样精校”的工程化流程。