古籍OCR识别的技术难点与批量识别实践方案

一、为什么古籍OCR是“困难模式”

现代印刷体OCR已经相当成熟，在规范文档上的准确率普遍令人满意，但同样的技术放到古籍上往往表现骤降。原因可以归结为四类：

1. 版式差异：古籍多为竖排、自右向左阅读，一页之内常有分栏、界行、鱼尾等版式元素。通用OCR的版面分析模块默认横排阅读顺序，直接套用会导致文本顺序错乱，即便单字识别正确，整段输出也无法阅读。
2. 字符集问题：古籍中存在大量异体字、俗字、避讳字与通假字，很多字符不在常用字符集覆盖范围内。模型要么不认识，要么“强行”识别成形近的常用字，产生看似通顺、实则错误的输出——这类错误比明显的乱码更危险，因为它很难被自动质检发现。
3. 图像质量：传世扫描件常伴有纸张老化、污渍、虫蛀、透印、印章与朱笔批注叠加等问题，前景与背景对比度不稳定，进一步拉低识别上限。
4. 内容结构复杂：正文、夹注、旁批、眉批混排。若不区分处理，批注内容会混入正文，影响后续的整理、标点与检索。

这些因素叠加，使得“识别率最高的那一款工具是哪个”这类问题本身并没有简单答案：在某一类刻本上表现好的方案，换到写本或另一类文献上可能明显退化。更工程化的思路是理解各条技术路线的能力边界，再针对自己手上的语料组合出可行方案。

二、三条技术路线的取舍

路线一：通用OCR软件与云服务。 以现代横排印刷体为主要目标，各大云厂商（含百度智能云）均提供此类通用文字识别服务。优点是接入成本低、并发稳定；缺点是字符集与版面分析都不是为古籍设计的，竖排与异体字场景下错误率明显上升。它适合处理影印本中的“现代附属内容”（如出版说明、目录页），不适合正文主体。

路线二：面向古籍的专用数字化能力。 部分学术机构与专业团队长期建设古籍字库与标注数据，对异体字处理有深厚积累，识别精度高；但通常以项目合作或按页计费的方式提供，规模化时成本可观，且不少能力并不对外开放。对个人研究者或小团队而言，门槛主要在价格与可及性。

路线三：视觉大模型 + 批量推理接口。 这是近两年逐渐实用的解法：视觉大模型对竖排、混排版式有较强的整体理解力，提示词可以显式约定输出格式；配合批量推理接口，可以把成千上万页图像打包提交、异步取回结果，适合大批量任务。代价是需要自己编写工程脚本，并对结果做质量抽检。

对多数个人数字化项目来说，第三条路线是当前性价比与可控性平衡最好的选择，下面展开说明。

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

整体流程分四步：扫描件预处理 → 任务组装 → 批量提交与轮询 → 结果落盘与校对。

1. 图像准备

• 将扫描版PDF按页导出为单页图像，建议长边不低于2000像素，保证小字号夹注可辨；
• 统一编码格式（如JPEG较高质量）与命名规则（按页码编号），便于断点续跑时精确定位；
• 倾斜明显的页面可先做旋转矫正；除非字口严重模糊，一般不做激进的二值化处理，避免丢失墨色浓淡信息。

2. 提示词设计（关键环节）

一段合格的古籍OCR提示词至少应约定以下内容：

• 版式事实：“页面为竖排，自右向左阅读，可能存在分栏”；
• 输出格式：“以横排文本输出，按阅读顺序合并分栏”；
• 特殊内容处理：夹注（小字双行）如何标注、旁批与眉批单独成段输出并注明类型；
• 未知字符策略：“无法确认的字以□占位，禁止根据上下文臆造”；
• 职责边界：只做识别，不做翻译、不做润色、不加现代标点（除非明确要求），避免模型“好心”改写原文。

提示词一旦定稿就应固定下来，随每条任务发送，保证整批输出风格一致，方便后续批量校对。

3. 批量任务脚本（伪代码）

国内主流大模型平台的批量推理接口思路一致：将单条请求打包成任务文件提交，服务端异步执行，完成后提供结果下载。伪代码如下：

SUPPORTED_IMAGE_EXTENSIONS = [".jpg", ".jpeg", ".png"]
OCR_PROMPT  = "……(前述古籍识别指令全文)"
BATCH_SIZE  = 100    # 单批任务数
MAX_TOKENS  = 1024   # 单页输出上限
def build_task(image_path):
    # 读取图像并编码，组装成一条"图像 + 提示词"的请求
    ...
def submit_batch(tasks):
    # 任务列表序列化后提交批量接口，返回 batch_id
    ...
def poll_and_save(batch_id, out_dir):
    # 定时查询批次状态；完成后下载结果文件，
    # 按页码写入txt，失败页面记入重试队列
    ...
def main():
    pages = collect_images("./pages")          # 收集全部单页图像
    for chunk in chunked(pages, BATCH_SIZE):
        batch_id = submit_batch([build_task(p) for p in chunk])
        register(batch_id, chunk)              # 记录映射，支持断点续跑

工程上还要补三件事：一是失败重试与限流退避；二是每页记录模型版本与提示词版本，便于回溯复现；三是增量断点续跑——脚本中断后按“已完成页清单”跳过，避免重复消耗配额。

4. 结果校对与评估

• 抽样人工核对：每50～100页抽取1页，对照原图逐字检查，估算整体质量；
• 字符错误率（CER）：若该古籍存在权威电子文本，可用编辑距离量化整书识别质量；
• 建立高频错误表：把反复识别错的异体字整理成映射表，在后处理阶段统一归一化；
• 错误反哺提示词：将典型错误写成“反面示例”补入指令，迭代两三轮后错误率通常显著下降。

四、适用边界与注意事项

• 数据安全：批量接口意味着数据需经过服务端处理，这条路线适合公域文献或对隐私不敏感的材料；涉及未公开馆藏或敏感内容时，应优先考虑本地化部署方案或与版权方另行约定。
• 识别与整理分离：不要让模型“顺手”翻译或添加标点。识别、校勘、标点是三个阶段，混在一起会放大幻觉，也难以定位错误来源。
• 版本固定：古籍整理讲究可溯源。务必固定模型版本与提示词版本并写入成果元数据，否则同一批数据二次复跑可能得到不一致结果。
• 残卷与缺页：对图像质量过差的页面，在输出中显式标记“疑似缺字/无法辨认”，交由人工处理，好过静默出错。

五、小结

回到最初的问题：“识别率最高的古籍OCR是哪一款”更像一个采购问题；工程上更有价值的问法是——“针对我手上这一类古籍，怎样组合技术路线，把准确率做上去、把成本压下来”。通用识别服务适合处理现代附属内容，专用数字化能力适合高要求的项目级需求，视觉大模型加批量推理则为个人与小团队提供了可自建的第三条路。把版式约定、占位符策略、断点续跑与抽样校对这些工程细节做扎实，古籍数字化的质量完全可以稳定在可用水平，并为后续的翻译、检索或RAG应用打好数据底座。