古籍繁体字识别：技术难点与工程实践指南

一、引言：古籍数字化的真正瓶颈在“识字”

古籍数字化项目通常包含扫描采集、图像预处理、文字识别、校对标点、结构化编目等环节。大量项目实践反复验证了一个结论：人力消耗最大、质量最难控制的环节，恰恰是最不起眼的“识字”。

现代简体文本的常用字总量不过六七千，通用 OCR 技术已能成熟处理；但古籍用字完全是另一个量级——正字之外，还叠加着异体字、俗体字、避讳字、碑刻别字等历史层积，历代文献中累积的不同字形以十万计。再叠加纸页老化、虫蛀水渍、竖排右起、双行夹注等客观条件，无论是纯人工录入，还是直接套用现代文本 OCR，都容易陷入“校对时间比重新誊录还长”的窘境。

正确的做法，是把古籍文字识别当作独立的领域技术问题，用“领域化识别 + 人机协同校对”重构整条流水线。

二、古籍识别的三层客观约束

2.1 字符集：一字多形、多字同形并存

• 一字多形：同一个字在刻本、抄本、碑刻中写法各异，例如“禮”在传世文献中存在多种异写，这些字形连有经验的修复师都需要反复比对善本才能确认；
• 多字同形：手写体“萬”与“方”笔形接近，脱离上下文几乎无法区分；
• 长尾严重：常用字识别再准，也无法弥补海量生僻异体字的缺口，字符准确率会沿字符频率长尾急剧下滑；
• 编码受限：大量古字位于 CJK 扩展区，录入、显示与检索都需要专门的字库支持。

2.2 载体：历史损伤与采集噪声叠加

古籍纸页常见老化发脆、虫蛀、水渍、霉斑、墨迹脱落；扫描过程又会引入歪斜、光照不均、装订处阴影。识别系统必须同时对抗两类退化，且历史损伤无法通过重新拍摄解决。

2.3 版式：竖排、无标点、多层级文本

古籍多为竖排右起、通篇无标点；刻本常含双行小注、眉批、圈点、朱墨套印。若版面分析按现代横排假设设计，切行就会出错，后续识别无从谈起。版面分析不是配角，而是古籍 OCR 的第一道门槛。

三、通用 OCR 在古籍场景失效的机理

• 训练分布偏移：通用模型的语料以现代印刷体为主，与刻本字体的笔画断连、风格差异巨大；
• 字符表覆盖不足：不在识别字典中的异体字，只能被漏识或映射为形近的错字；
• 版面假设不成立：面向横排版式的切行逻辑在竖排页面上完全失效；
• 语言模型兜底失灵：文言与现代白话语料差异大，通用后处理纠错对古籍几乎无效。

结论：不是通用 OCR 技术不行，而是“通用”与“领域”之间存在明显鸿沟。工程上应把通用服务（例如百度智能云等主流云厂商提供的通用文字识别类服务）用于现代文本环节建立流程基线，而古籍环节必须重点考察领域适配深度。

四、古籍 OCR 的技术解构

4.1 大字符表与异体字归一化

方案必须建立在覆盖完整的字符表之上，并区分两个输出层次：

• 字形层：保留原始字形的编码，服务文献学存真需求；
• 规范层：通过“异体 → 正字”映射字典输出规范正字，服务检索与语料分析。

工程上通常维护一张双向映射表并记录置信度，让校对者可以一眼看到系统判定的异体关系；避讳字还可结合朝代信息给出提示，辅助文献断代。

4.2 版面分析与行列切分

• 基础方法：对二值化图像做投影分析，按列间空白切分书列，再逐级切分文本行；
• 复杂版面：正文、双行夹注、眉批需用图像分割模型做区域分类；
• 层级原则：先列、后行、再字的层级切分，能最大限度保留上下文信息。

4.3 识别模型：从单字切割到端到端行识别

早期方案依赖“单字切割 + 单字分类”，切割错误与分类错误两段累积。当前主流做法是端到端行识别：

• CRNN + CTC：卷积特征 + 循环建模 + 无对齐解码，工程实现成熟稳定；
• Attention / Transformer 序列模型：在长行、形近字场景利用上下文消歧——“萬/方”这类字，靠整行语境比靠单字图像更容易判对；
• 领域微调：用刻本、写本语料微调，并配合数据增强（随机残缺、噪声、弹性形变），专门模拟破损页面。

4.4 后处理：语言模型、自动标点与置信度分流

• 文言语言模型纠错：用统计或神经语言模型对识别结果重打分，修正高频混淆字；
• 自动标点：将无标点文本转为带标点文本，直接压缩后续整理成本；
• 置信度分流：识别引擎输出逐字/逐行置信度，高置信自动通过，低置信进入人工队列，把人力精准投放到最需要复核的少部分文本上。

五、示意实现：置信度驱动的人机协同流水线

def process_page(image, engine, conf_threshold=0.85):
    # 1) 版面分析：竖排列切分与行提取
    columns = layout_detect(image)
    results = []
    for col in columns:
        for line in col.lines:
            # 2) 行级识别：返回字符序列与逐字置信度
            chars, confs = engine.recognize(line)
            if sum(confs) / len(confs) < conf_threshold:
                # 3) 低置信度行进入人工校对队列
                results.append({"type": "review", "line": line, "text": chars})
            else:
                # 4) 高置信度行走语言模型后处理（纠错 + 标点）
                results.append({"type": "auto", "text": lm_postprocess(chars)})
    # 5) 异体字归一化，保留"原字形-识别字-校改字"三层记录
    return normalize_variants(results, keep_trace=True)

配套的流水线架构可概括为：对象存储保存原图与识别结果 → 消息队列调度批量识别任务 → 置信度分流 → 人工校对界面（原图、识别文本与置信度并排展示）→ 校改差异留存用于模型迭代。这些环节均可通过对象存储、消息队列、日志监控等通用云产品类目搭建。

六、评测：把“识别率高”变成可度量的指标

6.1 指标定义

• 字符准确率（CAR）＝正确字符数 / 总字符数，是最核心指标；
• 行准确率：整行完全正确的比例，直接反映校对成本；
• 混淆字对分析：统计高频错字对（如“己/已/巳”），定位系统性缺陷；
• 分层统计：按刻本/抄本、完好/破损分别报告，避免平均数掩盖短板。

6.2 评测集构建

• 分层抽样：覆盖朝代、版本类型、破损程度等多个维度；
• 金标准：由双人独立录入、第三人仲裁生成，而非“机器结果人工改”；
• 规模建议：数百页即可获得有统计意义的结论，关键在分布代表性。

6.3 选型清单

• 字符能力：对异体字、俗体字的覆盖与归一能力；
• 工程能力：置信度输出、批量接口、并发上限、失败重试机制；
• 部署与安全：是否支持私有化部署，数据是否会被用于训练；
• 财务合规：能否开具正规发票——看似与技术无关，却是科研经费报销场景的硬性条件；
• 基线对比：先用通用文字识别服务跑现代文本基线，再量化领域方案的增益。

七、工程落地建议

• 小规模试点：先选几十页典型样本做盲测，验证后再决定放量节奏；
• 过程可追溯：保留“原字形—识别结果—人工校改”三层记录，既满足文献学溯源需求，也便于模型迭代分析；
• 人机配比：高置信度自动通过 + 低置信度人工复核的组合，可将整页校对工作量压缩到纯人工方案的一小部分；
• 结果沉淀：将校改数据回流为训练语料，形成“识别—校对—再训练”的正循环，这是古籍 OCR 项目长期价值所在。

八、结语

古籍繁体字识别的难点，本质上是“字符集长尾 × 载体退化 × 版式复杂”三重约束的叠加，任何单点优化都难以奏效。可靠的技术路径是：以大字符表与异体字归一化作地基，用端到端行识别借助上下文消歧，靠语言模型与自动标点压缩后续整理成本，最后以置信度驱动的人机协同把人力用在刀刃上。对古籍数字化团队而言，与其追逐“一步到位的全自动”，不如把评测体系与校对流水线建扎实——识别准确率会随模型迭代持续提升，而一套可度量、可追溯的工程框架，才是项目长期效率的真正保障。