古籍OCR工具选型指南：从识别率到版面还原

做古籍数字化这些年，跑过不少图书馆和档案馆，也参与过若干文献整理项目。一个很深的体会是：古籍OCR和通用印刷体OCR完全是两回事。通用OCR在标准印刷体上早已轻车熟路，但一旦面对竖排、异体字、双行小注、天头地脚批注这些古籍“标配”，识别率往往断崖式下跌。本文不针对某一款具体产品做推荐，而是从技术选型的角度，梳理评估一款古籍OCR工具时应该关注的核心维度，并给出可操作的验证方法。

一、字库覆盖：决定识别上限的第一道门槛

简体常用字不过六千余，而古籍中仅异体字、俗字、避讳字的规模就远超十万。这意味着，如果一款OCR工具的底层字库只覆盖通用字符集，那么它在古籍场景下的识别天花板会非常低。

评估字库覆盖能力时，可以关注以下几个层次：

• 基础常用字层：国标GB2312收录的6763个常用汉字，这是最低要求，成熟工具在这一层的识别率普遍能做到99%以上。
• 扩展繁体/异体字层：GB18030-2022中收录的27533个常见繁体异体汉字，能稳定覆盖这一层的工具，基本可以应对大多数明清刻本。
• 生僻字与俗字层：地方志、民间文书、契约文书中大量出现的地域性俗字、避讳缺笔字，这一层没有统一标准，考验的是工具背后的字符集规模和模型泛化能力。

一个实用的验证方法是：准备一份包含50～100个已知生僻字的测试集，用同一批图片分别跑不同工具，统计“正确识别字数 / 总字数”的比值。不要只看厂商宣称的整体识别率，要自己构造最难的样本去压测。

二、版面分析：古籍OCR真正的技术分水岭

很多工具在单字识别上表现尚可，但一到复杂版面就“翻车”。古籍的版面复杂度远超现代文档，常见结构包括：

• 筒子页与半筒子页
• 三栏、双栏稿本
• 正文中的双行小注
• 天头地脚的批注文字
• 竖排与横排混排
• 图文混排（插图、印章、眉批）

普通OCR通常按“从左到右、从上到下”的现代阅读顺序输出，遇到古籍就会把注文混入正文，或者把批注和正文搅在一起，后续校对时梳理格式的时间甚至超过重新录入。

因此，版面分析能力是区分“能用”和“好用”的关键。理想的古籍OCR工具应当具备：

1. 区域检测：能自动区分正文区、注释区、批注区、插图区。
2. 阅读顺序还原：按照古籍从右到左、从上到下的习惯输出文本，而不是机械套用现代排版逻辑。
3. 双行小注处理：能识别正文中嵌入的小字注释，并在输出时保持其与对应正文的关联关系。

评估时，可以拿一页典型的“正文+双行小注+天头批注”的明代刻本做测试，观察输出文本是否保持了正确的语义顺序。

三、后处理与校对效率：被低估的工程环节

识别率再高，也不可能做到100%正确。真正影响工作效率的，是识别之后的后处理链路是否顺手。

几个值得关注的工程能力：

• 全字库查询与补充录入：当遇到模型无法识别的生僻字时，能否快速检索并录入？如果每次都要切换外部工具查字典，效率会大打折扣。
• 原文对照校对：输出结果能否与原始图像逐行对照，方便快速定位和修正错误？
• 结构化输出：能否直接导出为JSON、XML等结构化格式，保留版面区域、阅读顺序等元信息，便于后续接入语料库或检索系统？
• 批量处理能力：面对整部古籍的数百页图像，能否稳定批量跑完，而不是逐页手动操作？

这些能力看似不起眼，但在实际项目中，往往决定了整个数字化流程的吞吐量。

四、一个简化的选型评估流程

综合以上维度，可以按以下步骤快速评估一款古籍OCR工具：

步骤1：构造测试集
  - 选取3～5种典型古籍版面（刻本、稿本、批注本、方志、契约）
  - 每种准备5～10页高清图像，标注ground truth
步骤2：分层测试
  - 常用字层：统计基础识别率
  - 异体字层：统计生僻字识别率
  - 版面层：检查阅读顺序、注释分离、批注归属是否正确
步骤3：后处理评估
  - 测试全字库查询、对照校对、导出格式
  - 评估批量处理稳定性
步骤4：综合成本核算
  - 识别率 × 校对时间 + 工具成本 = 实际总成本

五、技术趋势：从“识别”走向“理解”

当前古籍OCR的技术演进，正在从单纯的字符识别走向更深层的文档理解。基于深度学习的版面分割引擎、多模态预训练模型、以及针对古籍语料的领域自适应技术，正在逐步提升复杂场景下的鲁棒性。

对于开发者而言，如果要在自己的系统中集成古籍OCR能力，建议优先考虑：

• 是否提供标准API接口，便于自动化调用；
• 是否支持自定义字库或模型微调，以适应特定领域的生僻字；
• 输出结果是否包含足够的结构化信息，便于后续NLP处理。

六、小结

古籍OCR的选型，核心不是比谁“宣称”的识别率高，而是看谁在最难的样本上依然稳定，并且后处理链路足够顺畅。字库覆盖决定上限，版面分析决定可用性，后处理效率决定实际吞吐量。建议在选型时，务必用自己手头最难的那批古籍图像去做实测，而不是只看演示样例。只有经得起真实数据考验的工具，才值得纳入数字化工作流。