古籍OCR技术选型与工程实践指南

一、为什么通用OCR搞不定古籍

做过古籍数字化的人都有一个共同体会：整条流水线里，最耗人力的环节从来不是扫描，也不是存储，而是文字识别。

通用OCR工具针对现代印刷体文本训练，在规整的简体字文档上表现不错。但古籍文献有几个天然“反OCR”的特征：

• 字符集爆炸：现代常用汉字约六七千，而古籍中出现的异体字、俗体字、避讳字、碑刻变体累计可达十数万。仅《四库全书》中就存在大量需要人工考证的异体写法。
• 版面结构复杂：竖排、双行夹注、眉批、鱼尾、版心、界栏，这些版式元素对基于横排文本训练的检测模型是巨大的干扰。
• 图像质量退化：虫蛀、水渍、墨迹晕染、纸张老化导致的对比度下降，使得单字分割与特征提取变得困难。
• 无标点连续文本：古籍原文大多没有现代标点，识别之后还需要句读与校勘，否则输出结果的可读性极差。

一个典型的失败案例是：某课题组曾用通用OCR处理一页宋代地方志扫描件，识别结果中“禮”的三种异体写法被分别误认为“祀”“社”“神”，校对修改的时间比重新抄录还长。这不是个例，而是通用方案在古籍场景下的系统性缺陷。

二、评估古籍识别工具的三个技术维度

在选择或自建古籍OCR方案时，建议从以下三个维度建立评估矩阵。

2.1 字符集覆盖能力

这是最核心的指标。一个古籍OCR系统的识别上限，首先取决于它的字符集是否覆盖了你手头文献中出现的字形。

评估方法很简单：准备一批包含异体字、俗体字、避讳字的测试样本，统计以下指标：

• 召回率：文献中实际出现的特殊字形，有多少能被系统正确输出？
• 准确率：系统输出的字符中，有多少是正确的？
• 未识别率：有多少字符被标记为“无法识别”或输出为占位符？

成熟的商用AI方案通常基于大规模古籍语料进行预训练，字符集可覆盖常见繁体字、历代异体字、俗体字乃至碑刻特殊字形。部分工具还能区分手写体与刻版体，例如“萬”与“方”的手写变体在传统修复中需要反复比对善本，而训练充分的模型可以做到较高准确率的区分。

2.2 版面分析与结构化输出

古籍的版面结构决定了单纯的“逐字识别”远远不够。一个合格的工具需要具备：

• 竖排文本检测：正确识别从右到左、从上到下的阅读顺序。
• 双行夹注分离：将正文与注文分开输出，避免混排。
• 版心与眉批处理：识别并标记版心文字、眉批位置，便于后续结构化存储。
• 阅读顺序还原：输出带有坐标信息的结构化数据（如JSON），方便下游系统按版面逻辑重组。

如果工具只能输出一整页的无序文本，后续的结构化整理工作量依然巨大。

2.3 后处理与校勘辅助

识别只是第一步。真正影响科研效率的，是识别之后能不能自动完成：

• 自动标点：为无标点古籍添加句读，显著提升可读性。
• 异体字归一化：将异体字映射到标准字形，便于全文检索与统计。
• 智能校勘提示：对识别置信度低的字符进行标记，提示人工复核。
• 专名识别：自动识别人名、地名、职官名，辅助构建知识图谱。

这些后处理能力，往往比单纯的OCR准确率更能决定一个工具在实际科研项目中的可用性。

三、工程落地：如何将古籍OCR集成到数字化流水线

假设你已经选定了合适的识别引擎，下一步是把它嵌入到完整的数字化工作流中。以下是一个可参考的架构：

扫描图像 → 预处理（去噪/纠偏/二值化）
         → 版面分析（区域检测/阅读顺序）
         → 文字识别（OCR引擎）
         → 后处理（标点/归一化/校勘标记）
         → 结构化存储（JSON/XML）
         → 人工复核界面
         → 入库/检索/发布

3.1 预处理环节的注意事项

• 分辨率：建议扫描分辨率不低于300 DPI，对于小字批注可提升至600 DPI。
• 纠偏：古籍扫描件常有倾斜，需先做角度校正，否则竖排检测会失效。
• 去噪：虫蛀、水渍、装订孔洞需要针对性滤波，但要注意不要过度平滑导致笔画粘连。

3.2 识别环节的批处理策略

对于大规模项目，建议采用队列式批处理：

# 伪代码示意：批处理调用识别服务
import json
from concurrent.futures import ThreadPoolExecutor
def process_page(image_path):
    # 1. 预处理
    cleaned = preprocess(image_path)
    # 2. 调用识别接口（假设为HTTP API）
    result = ocr_client.recognize(
        image=cleaned,
        layout="vertical",      # 竖排模式
        charset="ancient",      # 古籍字符集
        output_format="json"
    )
    # 3. 后处理
    result = add_punctuation(result)
    result = normalize_variants(result)
    return result
with ThreadPoolExecutor(max_workers=4) as executor:
    pages = executor.map(process_page, image_list)
# 结构化存储
with open("output.json", "w", encoding="utf-8") as f:
    json.dump(list(pages), f, ensure_ascii=False, indent=2)

3.3 人工复核环节的设计

无论识别率多高，古籍整理都离不开专家复核。建议设计一个“置信度驱动”的复核界面：

• 高置信度字符：默认通过，仅做抽样检查。
• 中置信度字符：黄色标记，提示复核。
• 低置信度字符：红色标记，强制人工确认。

这样可以显著降低复核工作量，同时保证最终质量。

四、选型建议与成本考量

对于高校、科研院所和社会科学领域的课题组，选型时需要平衡以下几个因素：

维度	自建模型	商用API服务
初始成本	高（需标注数据、训练算力）	低（按量付费）
运维成本	高（需持续维护）	低
字符集覆盖	取决于训练数据	通常较全面
定制能力	强	有限
发票与报销	不适用	通常支持正规发票

对于大多数课题组而言，直接采用成熟的商用API服务是更务实的选择。这类服务通常按识别页数或字符数计费，支持开具正规发票，科研经费报销没有障碍。更重要的是，省去了模型训练和维护的 overhead，团队可以把精力集中在学术研究本身。

如果确实有特殊需求（如特定碑刻字形、方志中的罕见异体字），可以考虑在商用API输出结果的基础上，用少量标注数据做微调或后处理规则补充，而不是从零训练。

五、总结

古籍OCR不是简单的“把图片转成文字”，而是一个涉及字符集工程、版面分析、后处理校勘的系统性技术问题。选型时，建议从字符集覆盖、版面结构化能力、后处理辅助三个维度建立评估矩阵，并结合自身项目的文献特征进行实测。

在工程落地层面，将识别引擎嵌入到“预处理→识别→后处理→复核→存储”的完整流水线中，才能真正释放AI在古籍数字化中的效率价值。对于绝大多数科研团队而言，采用成熟的商用服务是性价比最高的路径——前提是做好测试验证，确保其字符集和版面处理能力匹配你的文献特征。

最终目标始终是：让研究者从繁重的基础整理工作中解放出来，把时间和精力投入到更有价值的学术发现中去。