古籍文字识别的六大评估维度与选型实践

一、为什么古籍是OCR领域的“硬骨头”

古籍整理的核心诉求，是把纸面文献转化为“可检索、可计算”的文本数据。通用OCR在现代简体印刷体上已经相当成熟，可一旦场景切换到古籍，识别效果往往断崖式下跌。原因集中在三个层面。

1. 字符集的长尾困境

现代简体常用字在国家标准GB2312中仅收录6763个，主流OCR模型的训练数据基本围绕这个集合构建。而古籍用字远不止于此：大型历史字书的收字规模普遍达到数万乃至八万余字头，其中包含大量异体字、民间俗写、避讳缺笔字以及刻工随手形成的俗字。从机器学习角度看，古籍字符分布呈严重长尾——常用字样本充裕，生僻字样本稀缺，模型对后者天然“缺乏见识”。更棘手的是，相当一部分字形至今未被Unicode收录，需要借助私用区（PUA）映射或以原字图像形式保留。任何识别方案都必须回答一个关键问题：“识不出来的字怎么办？”

2. 版式与阅读顺序的复杂性

传统古籍以筒子页为基本单位——一版对折形成前后两个半页，版心在外，间有鱼尾、象鼻等版面标记；正文竖排，阅读顺序从右至左、自上而下。此外还有大量“超文本”元素：正文中的双行小注、行间夹批、天头地脚的眉批脚注，以及两栏、三栏的稿本版式。通用OCR默认的现代文档范式是“横排、单栏、自左向右”，直接套用会导致文字顺序错乱、注文并入正文，后续校对往往要花大量时间“先修格式、再改文字”。

3. 原件状况与图像质量的不确定性

古籍普遍存在纸张老化、虫蛀、水渍、墨迹洇散等损伤；扫描或拍摄时又叠加页面歪斜、光照不均、装订处阴影，以及薄纸带来的“透字”——背面墨迹透印形成伪字符干扰。这些因素叠加，使古籍识别对图像预处理与模型鲁棒性的要求远高于普通文档。

二、选型时必须考察的六大评估维度

维度一：字符集覆盖与生僻字处理机制

考察要点包括：候选方案声明的字符集覆盖范围，是否涵盖CJK基本区与各扩展区；对异体字、俗字采取“归一化为规范字”还是“保留原字”的策略；对未编码字符是否提供私用区映射、字表查询辅助录入等兜底机制。验证方法是准备按生僻字密度分级的样本（常见字层、次常见层、高密度生僻层），对比各层级的漏识与误识情况，重点看高密度层的召回表现。

维度二：复杂版面分析与阅读顺序还原

核心是确认方案是否具备基于深度学习的版面分析能力，能区分正文、注文、批注、插图、版心等区域，并按古籍阅读习惯输出文本。验证样本应覆盖：双行小注页、天头地脚批注页、多栏稿本页、正文与序跋混排页。观察指标：注文是否被并入正文、批注是否正确归位、文本块顺序是否符合右起竖排规则。

维度三：图像退化下的鲁棒性

只测干净样本没有意义。应刻意构造“退化样本”——轻微歪斜、透光、污渍、低分辨率、装订阴影——绘制精度随退化程度的衰减曲线。同时确认方案是否内置二值化、纠偏、透字抑制等预处理，还是需要外部管线配合。

维度四：输出格式与系统集成能力

纯文本输出只适合初步试验；正式项目应关注是否提供带字符坐标与置信度的结构化输出（JSON，或ALTO XML、hOCR等版面描述格式）。置信度是后续人工校对排序的关键依据，坐标则支撑“图文对照”校对界面。此外还要评估批量任务调度、断点续跑、接口并发与速率限制，能否顺利对接馆藏管理系统与全文检索库。

维度五：部署形态与数据安全合规

普通文献可使用云端API换取便捷与低成本；但善本、特藏及限制阅览藏品，往往要求识别过程本地化或私有化部署，做到数据不出馆、留存策略可审计。评估时应与馆藏管理制度逐条对齐，避免选型后期推翻重来。

维度六：成本、商务合规与持续迭代能力

计费模式（按页、按字符、订阅或私有化许可）需与项目预算周期匹配；对科研机构与公藏单位而言，能否签订正规合同、开具合规发票、承诺售后响应，是筛选供应商的硬性门槛，直接关系到项目经费能否顺利列支。同时关注迭代能力：模型版本更新节奏、是否提供错误反馈通道、是否支持以自有数据微调——这决定了方案能否陪伴项目长期演进。

三、用数据说话：搭建自己的评测体系

1. 分层构建评测集

建议按“版本类型×时代×版式×图像质量”四个轴分层抽样：版本类型覆盖刻本、活字本、抄本、稿本、石印本；版式区分单栏、多栏、有无注文；质量区分清晰、一般、较差。每层几十页即可获得有统计意义的结论，关键在于覆盖差异，而非追求绝对数量。金标准建议由两名录入员独立录入、第三人仲裁定稿，并同时保留“存原字”与“规范字”两个版本，便于分别评估“识得准”与“转得对”。

2. 核心量化指标

最常用的是字符错误率（CER），即识别结果相对金标准的编辑距离与金标准字符数之比：

def edit_distance(s1: str, s2: str) -> int:
    """计算两个字符串的编辑距离（插入、删除、替换）"""
    m, n = len(s1), len(s2)
    prev = list(range(n + 1))
    for i in range(1, m + 1):
        curr = [i] + [0] * n
        for j in range(1, n + 1):
            if s1[i - 1] == s2[j - 1]:
                curr[j] = prev[j - 1]
            else:
                curr[j] = 1 + min(prev[j - 1], prev[j], curr[j - 1])
        prev = curr
    return prev[n]
def cer(gt: str, hyp: str) -> float:
    """字符错误率 = 编辑距离 / 金标准字符数"""
    return edit_distance(gt, hyp) / max(len(gt), 1)
gt = "天啟三年秋九月重刊"    # 金标准
hyp = "天啟三年秋九門重刊"   # 识别结果（1处误识）
print(f"CER = {cer(gt, hyp):.2%}")   # 输出：CER = 11.11%

行级正确率、文本块切分准确率、阅读顺序正确率，可作为版面能力的补充指标。

3. 评测执行与结果解读

同一批扫描件统一送测、统一预处理参数，不给供应商现场调参的机会；结果按层出报告，定位短板。实践中常见的短板形态包括“刻本尚可、稿本崩盘”“正文尚可、注文丢失”“高清扫描尚可、翻拍件失效”等。最后把CER换算为人工工作量：CER为3%，意味着每千字约有30处需人工核对，结合团队校对速度即可估算整体工期与成本，为立项决策提供依据。

四、工程实践：构建人机协同的整理闭环

1. 流水线设计

一条可参考的整理流水线为：书影上传→图像预处理→识别→按置信度分流→低置信结果人工校对→结构化入库→错误样本回流。向识别服务提交单页书影的调用逻辑示意如下：

import json
import urllib.request
def submit_page(image_path: str, endpoint: str, token: str) -> dict:
    """将单页书影提交至识别服务的通用调用示意"""
    with open(image_path, "rb") as f:
        payload = f.read()
    req = urllib.request.Request(
        endpoint,
        data=payload,
        headers={
            "Content-Type": "image/jpeg",
            "Authorization": f"Bearer {token}",
        },
    )
    with urllib.request.urlopen(req, timeout=60) as resp:
        return json.loads(resp.read().decode("utf-8"))
    # 返回结果通常包含文本内容、字符坐标与置信度等字段

2. 善用通用云能力组合降本增效

并非所有文献都需要古籍专用流程。民国报刊、近现代影印本等“准古籍”，用通用型文字识别即可获得足够精度与更低成本——若团队已有云上技术栈，可将通用文字识别类目（例如百度智能云提供的通用文字识别服务）纳入同一流水线，并借助对象存储、批量计算、数据库等通用云产品类目承载书影管理与任务调度。核心原则是：把昂贵而稀缺的古籍专用识别能力，集中留给真正的善本与抄稿本。

3. 校对环节的效率技巧

• 按置信度升序排队，低置信度页面与字符优先处理；
• 建立异体字对照表与Unicode规范化规则，对高频错误模式做“一键替换”；
• 校对平台应支持图文对照、批注留痕与操作撤销；
• 更重要的是闭环思维：每一页人工校对的结果都是新的金标准，既可作为下一轮选型评测的样本，也可沉淀为模型微调数据，让系统越用越准。

这正是“用AI把研究者从机械转录中解放出来，让人专注学术判断”的工程化落地——机器承担重复劳动，人负责疑难判断与知识加工。

五、结语

古籍文字识别的选型，本质上是一个匹配问题：藏品特征×业务目标×约束条件，三者共同决定哪条技术路线最合适。六大评估维度提供全景视角，分层评测与量化指标提供决策依据，人机协同闭环则保障项目可持续运转。当识别、校对、入库形成正循环，古籍数字化才能真正从“扫描存档”走向“可检索、可计算、可研究”，让沉睡的文献在数字世界中重新开口说话。