古籍OCR实践：从单张验证到批量落盘的工程化路径

一、问题的提出：当OCR遇上古籍

古籍数字化是一个典型的长尾场景：需求真实存在，但单个项目的商业价值有限，长期缺乏针对性优化。以明代刻本影印本为例，这类文本往往没有现成的全文电子版，手工录入的成本极高——一部数十万字的通俗演义，逐字敲录可能需要数月，且极易在中途因枯燥而放弃。于是很多人的第一反应是求助OCR。

但现实往往不如预期。把一张古籍影印页丢给通用OCR工具，返回的结果经常是残缺、错位、串行的。原因并不神秘：现代OCR模型的训练数据以现代印刷体和屏幕文本为主，而古籍影印件面临的是另一套完全不同的分布——竖排右起、繁体异体字混杂、无标点或仅有句读、版框与正文交叠、纸张老化带来的噪点与透印。更关键的是版面结构：古籍的一页往往同时包含正文、双行小注、眉批、版心、鱼尾等元素，它们的排布规则与现代文档截然不同。

近期有开源OCR模型在版面元素定位上做了针对性改进，提出了对不规则四边形边界框的支持，这对处理版式自由、文字区域形状不规则的文档是一个有价值的思路。本文不评估具体产品的优劣，而是从一次真实的古籍数字化尝试出发，讨论”识别效果”与”工程可用性”之间的距离，以及如何把一次成功的单张识别，转化为可复用的批处理流水线。

二、素材差异：同一部书，两种影印质量

本次实践的对象是一部明代刊本的影印本。手头有两个来源的PDF，它们的差异非常具有代表性：

第一种：原版影印，开本较大、清晰度高。 每页均为刻本原件的直接影印，字口清晰，墨色层次保留较好。这类素材理论上是最理想的OCR输入，但实际测试中识别效果并不理想——模型能够检出部分文字，但误识率高，尤其是笔画粘连处和异体字，经常出现整句崩坏。

第二种：上半影印、下半排印。 同一部书的另一个版本，页面上半部分仍是原件影印（清晰度还略逊于第一种），下半部分则是经过校订整理的现代汉字排印文本。这个设计的初衷是方便对照阅读，却无意中为OCR提供了一条捷径：下半部分的排印文本，字形规范、横排、有标点，几乎就是为OCR量身定制的输入。

这里得到一个重要结论：OCR效果的上限，很大程度上由输入素材的”分布接近度”决定，而非模型本身的能力上限。 同一套模型，在排印文本上的表现远优于影印文本，这不是模型”不行”，而是任务难度本就不同。对于古籍项目而言，如果存在任何形式的排印转写本（哪怕是部分），优先利用它，往往比死磕影印件更划算。

三、从单张验证到批量处理：被低估的工程环节

在第二种素材的下半部分上做单张测试，效果令人满意。于是自然的想法是：写个循环，遍历所有页面图片，把每页的识别结果写入本地文件即可。1380张图片，程序跑一晚上就能完成——问题似乎只剩下”整理”。

但这个”天真”的想法恰恰是大多数OCR项目翻车的地方。单张识别成功，只证明了模型能力；批量落盘，考验的是工程能力。两者之间隔着若干必须显式处理的问题：

1. 页面切分与区域裁剪。 前述素材需要先把每页的下半部分裁出来。裁剪规则若依赖固定比例，遇到版式微调或扫描偏移就会错位；更稳妥的做法是基于版面检测动态定位排印区域，或至少加入人工抽检环节。

2. 阅读顺序还原。 古籍是竖排右起，模型输出的文本块顺序未必符合阅读逻辑。若直接按检测框坐标排序，容易在多栏、双行小注处出现串读。需要在后处理阶段依据栏位与行序重建顺序，而不是信任模型的默认输出。

3. 批处理的健壮性。 1380张图片的循环里，任何一张因文件损坏、尺寸异常或接口超时而失败，都可能中断整个任务。必须为每张图片设计独立的失败重试与错误记录机制，保证单点故障不影响整体进度。

4. 结果落盘的结构化。 把识别文本按页码存成纯文本是最低要求，但后续整理需要更多元信息：原图路径、识别置信度、检测框坐标、处理时间戳。建议以每页一个JSON记录的形式落盘，文本内容作为字段之一，便于后续检索与回溯。

一个简化的批处理骨架如下：

import json, os, time
def process_page(image_path, ocr_client, out_dir, max_retry=3):
    record = {"image": image_path, "status": "pending"}
    for attempt in range(max_retry):
        try:
            result = ocr_client.recognize(image_path)   # 通用识别调用
            record.update({
                "status": "ok",
                "text": result.text,
                "boxes": result.boxes,                  # 保留版面坐标
                "confidence": result.mean_confidence,
                "timestamp": time.time(),
            })
            break
        except Exception as e:
            record.update({"status": "retry", "error": str(e)})
            time.sleep(2 ** attempt)                    # 指数退避
    page_id = os.path.splitext(os.path.basename(image_path))[0]
    with open(os.path.join(out_dir, f"{page_id}.json"), "w", encoding="utf-8") as f:
        json.dump(record, f, ensure_ascii=False, indent=2)
    return record["status"]

这段代码的重点不在识别本身，而在失败隔离、重试退避、结构化落盘三件事。它们决定了流水线能否在千级规模上稳定跑完。

四、接口入口的设计反思

实践中还遇到一个细节值得单独讨论：在网页端点击”API”入口时，并没有跳转到完整的接口文档，而是以弹层形式展示了一段示例代码。对于熟悉该生态的开发者，这或许足够；但对于第一次上手的用户，缺少文档入口会带来明显的认知摩擦——示例代码能告诉你”怎么调一次”，却不会告诉你鉴权方式、请求限额、返回字段含义、错误码体系。

这折射出一个更普遍的产品设计问题：面向开发者的能力开放，示例代码与完整文档应当是并列入口，而非替代关系。 示例降低首次调用门槛，文档支撑长期集成与异常处理。两者缺一，都会把成本转移给使用者。对做批处理的场景而言，缺少文档意味着无法准确判断限流策略，也就无法合理设计并发度与重试节奏——这恰恰是批处理稳定性的关键参数。

五、结论与建议

回到最初的目标——为一部没有电子版的古籍建立可检索的文本。这次实践给出的经验可以归纳为几条：

1. 先评估素材，再评估模型。 排印转写本的存在，往往比任何模型调优都更能提升端到端效果。影印件的识别难度是结构性的，不应简单归因于模型能力。
2. 单张验证不等于批量可用。 批处理必须显式处理切分、顺序还原、失败重试与结构化落盘，这部分的工程量常被低估。
3. 保留版面元信息。 只存纯文本会丢失后处理的余地；坐标与置信度是重建阅读顺序、定位低质量页面的必要依据。
4. 把文档当作一等公民。 在选型阶段就确认接口文档、限流规则与错误码是否完备，这直接决定流水线的设计参数。

不规则边界框定位这类能力的价值，在于它让版面分析更贴合真实文档的形态——古籍的版框、批注、双行小注本就不是规整矩形。但能力只是起点，真正决定项目成败的，是围绕它构建的那套可观测、可重试、可回溯的工程流程。