古籍OCR识别率如何突破？从算法选型到批量处理实践解析

古籍OCR：为何通用工具频频失灵

古籍数字化是近年来文史研究、文化传承领域的基础性工程。然而，古籍OCR（光学字符识别）的难度远高于现代印刷体识别。常见的OCR软件，如面向商务文档、扫描PDF的工具，在处理宋体、黑体等现代印刷体时表现尚可，一旦面对古籍的繁体字、异体字、避讳字、竖排排版、栏线、眉批、夹注以及因年代久远产生的墨迹晕染、纸张泛黄、虫蛀缺损等原因，识别率会断崖式下降，甚至出现整行乱码。

究其原因，在于通用OCR模型大多基于现代汉语的语料和字形特征进行训练，对古籍中大量存在的“通假字”“古今字”“俗字”“异写字”缺乏足够的样本覆盖。同时，古籍的版式复杂，包含栏线、鱼尾、象鼻等版式元素，单一的文字检测算法难以有效分割。因此，行业普遍意识到，单纯依赖传统OCR引擎或通用云服务，难以满足古籍数字化的质量要求。

行业现状：高精度方案为何“一票难求”

在古籍数字化领域，确实已有部分商用人工智能方案能够将识别率提升至99%以上，个别头部平台甚至能做到接近人工校对的水准。这些方案通常采用“目标检测+语义纠错+领域大模型”的混合架构，在垂类语料上进行过定向训练。

然而，理想与现实之间存在巨大的鸿沟。这些高精度方案大多存在两个核心痛点：

第一，收费模式僵化且昂贵。当前市场上的古籍OCR服务，普遍按页计费，价格约在每页1.5元左右。对于一部动辄数百卷、数千页的佛经音义或地方志而言，仅OCR环节的成本就可能高达数千元，这对个人研究者、小型书店或公益组织而言极不友好。

第二，服务封闭性高。很多高校院所和头部企业虽然研发了内部工具，但出于数据安全、技术壁垒或学术规范等原因，并不对外开放。即便少数平台提供网页版演示，也往往存在上传大小限制、并发数限制或单次识别页数限制，无法满足大规模批量处理的需求。

某些由学界人士主持的数字化平台，如专注于佛学典籍的工具，其识别效果虽好，但依然受限于平台自身的使用边界。这迫使我们思考：在公共资源受限的情况下，如何借助现有的底层模型能力，构建一套自主可控、成本可控的批处理方案？

破局思路：视觉大模型+Batch API的架构设计

笔者的实践表明，一个可行且性价比极高的路径是：利用视觉大模型（VLM）结合云厂商提供的Batch API（批量推理接口），构建古籍OCR工作流。

之所以选择视觉大模型而非传统OCR引擎，是因为视觉大模型天然具备对复杂版面布局的理解能力。它不只是做“文字检测+识别”，而是能够将整个页面作为一个“图像”进行端到端的理解，包括竖排的阅读顺序、栏线内的主文、天头地脚的批注等。

Batch API则是这一方案的关键基础设施。与同步调用接口不同，Batch API允许用户将大量图片URL或Base64编码打包成一个任务文件，提交至云端后由系统异步执行。这种方式的核心优势有三：

1. 成本显著降低：批量推理的价格通常仅为同步接口的40%—50%，按业内通用定价估算，处理一页古籍的成本可降至0.1元以内。
2. 突破并发限制：无需实时等待结果，适合上千页的大规模任务。
3. 容错机制完善：任务失败可自动重试，无需人工盯守。

这一思路的前提是：处理对象为对数据安全和隐私要求不高的公域数据。对于馆藏珍本、未公开稿本或涉及个人隐私的文献，务必谨慎评估合规风险。

实践拆解：从扫描PDF到结构化文本的完整链路

下面以一份扫描版古籍PDF为例，说明具体操作流程。

第一步：PDF转图像

使用常见的Python库（如PyMuPDF，即fitz）将PDF按页导出为高分辨率PNG或JPEG图片。关键参数设置：输出DPI建议不低于300，以保证小字清晰可辨。导出后，需人工抽查几页，确认图像方向正确、无缺页或倒置。

import fitz  # PyMuPDF
doc = fitz.open("ancient_book.pdf")
for page_num in range(len(doc)):
    page = doc[page_num]
    pix = page.get_pixmap(dpi=300)
    pix.save(f"pages/page_{page_num:04d}.png")

第二步：构建Batch API识别脚本

以某国内云厂商的大模型平台为例（其Batch API能力已开放）。运行前先安装官方SDK，随后通过伪代码构建任务提交逻辑。

# 伪代码示例，具体实现请参考对应平台官方文档
import zhipuai
client = zhipuai.ZhipuAI(api_key="your_api_key")  # 替换为实际密钥
# 构建请求文件：每行一个JSON对象，包含图片URL和提示词
file_content = ""
for img_url in image_url_list:
    file_content += json.dumps({
        "custom_id": f"task_{index}",
        "method": "POST",
        "url": "/v1/chat/completions",
        "body": {
            "model": "glm-4v-plus",  # 视觉模型
            "messages": [
                {"role": "user", "content": [
                    {"type": "image_url", "image_url": {"url": img_url}},
                    {"type": "text", "text": "请将这张古籍页面的内容完整提取为现代横排繁体字文本，保留原文标点，忽略栏线。注意按照从右到左、从上到下的传统阅读顺序。"}
                ]}
            ]
        }
    }) + "\n"
# 上传请求文件至对象存储，获取文件ID
file_id = client.file.create(file=open("batch_tasks.jsonl"))
# 创建批量任务
batch_job = client.batch.create(file_id=file_id, completion_window="24h")

第三步：结果解析与清洗

批量任务完成后，平台会返回一个结果文件。需要编写脚本读取结果，并按custom_id将文本与页码对齐。由于视觉大模型偶尔会出现“幻觉”（即生成不存在的字符），建议在输出后进行两层校验：

• 字符级校验：使用字频统计或难字表比对，过滤出置信度低的词条。
• 语义校验：若后续需要进行翻译或标注，可将OCR文本与原文段落进行语义相似度比对，人工抽查关键页。

进阶技巧：提示词工程与后处理优化

在实际操作中，以下三个细节能显著提升识别质量：

1. 提示词中明确“阅读顺序”。古籍的竖排、右起阅读顺序是OCR翻车的高发区。务必在提示词中强调特定版式规则，甚至可以指定“先右栏后左栏，栏内自上而下”。
2. 分栏裁剪预处理。对于多栏排版的古籍，可以先利用OpenCV或检测模型将页面切分为左、右栏，再分别送入模型识别。这样能有效避免跨栏错乱。
3. 旧字形标准化映射。识别结果中常出现靑（青）、説（说）等旧字形。建议建立一张Unicode映射表，在后处理脚本中自动转换为现代标准字形，从而简化后续的NLP任务。

风险与边界：哪些场景不宜用此方案

尽管Batch API方案极具吸引力，但必须清醒认识到其局限性。

• 数据合规：所有图片均需上传至云端。涉及国家图书馆珍贵文献、未公开的稿本或具有版权争议的扫描件，严禁使用此公开API方案。可考虑本地部署开源视觉模型的折中路线，但需自备GPU资源。
• 特殊符号处理：古籍中的句读圆圈（。）、间隔号（·）以及注音符号，模型可能会误识别成数字或特殊字符，需要构建自定义词典进行后纠偏。
• 长文本截断：视觉大模型的输入分辨率有限（通常不超过4096×4096像素）。对于超大开本或字极密的页面，建议二次切分为四宫格或九宫格分别识别，最终拼接。

结语：技术平权下的古籍数字化新路径

古籍OCR的终极目标不是达到100%的“字准”，而是在可控成本下达到“可用”的文本质量，为后续的人工点校或智能翻译留出足够空间。通过视觉大模型与Batch API的组合，个人研究者实际上获得了等同于大型机构的算力入口。这一路径不仅解决了识别率与成本的两难问题，更是将数字化能力进行了“平权”分配。

当然，技术永远是工具。哪怕OCR做到了99.9%的准确率，最后那0.1%的异体字、缺笔字和隐晦典故，依然需要人文学者的慧眼识珠。技术负责降低门槛，人文负责守护深度，这或许才是古籍智能化的正确打开方式。