中文OCR识别率提升：模型选择与工程实践

一、中文 OCR 为什么难：先理解问题，再谈方案

很多人把识别率问题简化成“选哪款软件”，但中文 OCR 的实际效果从来不是单点能力决定的。先看中文场景的四个天然难点：

1. 字符集庞大。英文印刷体只需覆盖几十个字母数字，而中文仅 GB2312 一级字库就收录 3755 个常用汉字，加上生僻字与繁体字，模型需要区分的类别数量级更高，分类边界更密。
2. 形近字密集。“己/已/巳”“土/士”“日/曰”“末/未”这类字形差异极小的字符大量存在，在低分辨率、模糊或倾斜输入下，哪怕只错一两个形近字，也会让整行结果失去可信度。
3. 版面复杂。多栏排版、表格、图文混排在中文文档中极为常见；古籍、书法、竖排印刷品的文字流向与横排完全不同，切行逻辑需要单独处理。
4. 中英混排普遍。技术文档、票据中中文、英文、数字、符号交错出现，对字符集覆盖与后处理都提出更高要求。

因此更可靠的思考框架是：识别率 ≈ 模型能力 × 输入质量 × 工程链路。三个因子中任何一个为零，整体效果就为零。下面依次展开。

二、评估先行：没有基准就没有“识别率”

在没有量化评估之前，一切“识别率高”的说法都只是主观印象。动手选型或调优前，先做三件事：

1. 构建贴近业务的测试集。从真实数据中采样两三百页，覆盖扫描件、手机拍照、屏幕截图等不同来源，人工标注标准答案。测试集分布越贴近线上，结论越可靠；只用清晰的印刷体做演示图，得到的结论往往会误导决策。
2. 统一指标。中文 OCR 常用字符错误率 CER（Character Error Rate）：基于编辑距离，统计识别结果相对标准答案的替换、删除、插入字符总数，再除以答案长度。除字符级指标外，建议同时关注行级与整页级的完全匹配率，后者更能反映“可不可直接用”。
3. 横向跑分。把候选引擎或服务封装成统一调用接口，在同一测试集上记录 CER、平均耗时与失败页比例，用数据而非印象做决策。

CER 用标准动态规划即可实现，几十行代码足够：

def cer(ground_truth: str, pred: str) -> float:
    """基于编辑距离的字符错误率"""
    m, n = len(ground_truth), len(pred)
    dp = [[0] * (n + 1) for _ in range(m + 1)]
    for i in range(m + 1):
        dp[i][0] = i
    for j in range(n + 1):
        dp[0][j] = j
    for i in range(1, m + 1):
        for j in range(1, n + 1):
            if ground_truth[i - 1] == pred[j - 1]:
                dp[i][j] = dp[i - 1][j - 1]
            else:
                dp[i][j] = min(dp[i - 1][j], dp[i][j - 1], dp[i - 1][j - 1]) + 1
    return dp[m][n] / max(m, 1)

三、模型准备：语言资源的选择决定效果上限

主流开源 OCR 引擎都以“预训练模型 + 语言资源”的形式发布能力，语言资源库通常覆盖上百种语言，且大多可以免费获取。执行识别之前把这一步做对，能避免大量无谓调优。

1. 高精度档与轻量档的权衡。不少引擎会同时提供两档语言模型：轻量/快速版体积小、推理快，适合移动端、端侧设备与大批量初筛；高精度版网络更深、训练更充分，识别率更高，但耗时与资源占用也更大。实践建议是：先用高精度版建立效果基线，再压测轻量版能否满足延迟与成本约束；若达标则用轻量版上线，不达标时优先考虑量化、裁剪、降低输入分辨率等手段，而不是直接牺牲精度。

2. 语言代码与变体。语言资源普遍按“语言代码[+方向/变体]”的规则组织，例如以标准语言代码区分中文（zh）、日文（ja）、韩文（ko）、俄文（ru）、阿拉伯文（ar）、德文（de）、法文（fr）、西班牙文（es）等。中文场景特别要注意简体与繁体必须分开选择：用简体模型识别繁体文本，繁体字会被大量“猜”成简体字形，识别率会断崖式下跌，反之亦然。

3. 竖排变体。古籍、字帖、日文杂志等大量使用竖排，其字序方向与切行逻辑和横排完全不同，直接用通用模型处理会出现行序错乱、上下文字粘连。应选择以方向标记区分的竖排变体模型，或在识别前做方向检测与旋转预处理。

4. 特殊场景资源。除常规语言模型外，还要关注三类资源：一是方向与语种检测（OSD，Orientation and Script Detection），先判断图像旋转角度与所属语系，再路由到对应模型，是流水线稳定性的第一道保障；二是数学公式识别模型，面向论文、试卷、教材等公式密集文档；三是历史字形模型，用于古籍数字化中的老式印刷体、德文花体字等特殊字形。票据、证件等强结构化场景，则建议走“版式定位 + 字段约束”的专用链路，而非裸的通用文本模型。

四、预处理：成本最低的提分手段

很多“识别率差”的锅其实在图片上。换模型之前，先检查并补全预处理链路：

1. 倾斜校正。一两度的倾斜就足以让整页行切分失败，检测主文字方向并旋转回正是第一步。
2. 分辨率控制。扫描建议不低于 300 DPI；拍照场景要保证小字号文字有足够像素，笔画粘连或断裂时模型再强也无能为力。
3. 去噪与背景处理。扫描阴影、装订线、水印、印章叠加是高频噪声源；自适应二值化通常优于全局阈值，但部分深度模型在灰度图上表现更稳，不要盲目二值化，先在自己的测试集上对比。
4. 版面分析。多栏、表格、图文混排应先做版面切分，将每个区域单独送识别，再按阅读顺序合并输出；整图直推会串行串列，后处理几乎无法挽回。

完整链路可以概括为：原图 → 倾斜校正 → 版面切分 → 区域识别 → 语言纠错 → 结构化输出。每一步都可用测试集验证增量收益。

五、后处理：用语言知识修复形近字错误

模型输出并不等于最终结果，形近字错误往往能在语义层面修复：

1. 词典与上下文纠错。把识别结果送入中文语言模型或分词、词典校验流程，“土/士”“干/千”这类错误经常能被上下文自动纠正。
2. 业务字典。维护领域术语表（人名、药名、型号编码等），对结果做受限替换与校验，对垂直场景收益显著。
3. 正则约束。证件号、日期、金额、电话等固定格式字段用正则校验，不匹配即触发重识别或转人工复核。
4. 置信度路由。对低置信度区域换高精度模型重识别，或提高分辨率重新切图；通用区域走轻量链路、疑难区域走高精度链路的混合策略，在成本与精度之间最灵活。

六、自建、开源还是云服务

三条路线的取舍逻辑很清晰：

1. 开源自建。适合数据不允许出内网、需要针对竖排古籍或行业票据做深度微调，且具备 GPU 与标注团队的情况。路径是开源引擎 + 领域数据微调，自由度最高但投入也最大。
2. 云服务。追求快速上线、缺乏模型运维经验、场景以通用印刷体、卡片证照、票据等常见类目为主时，调用云厂商的文字识别 API 是性价比最高的起点。以百度智能云为代表的云服务商提供了通用文字识别能力，开发者通过标准 API 即可完成识别，无需自行下载语言模型、搭建推理环境，还能持续获得模型迭代带来的收益。
3. 混合方案。通用内容走云端 API，长尾版式与强定制场景走自建模型，用置信度路由分流，兼顾效果与成本。

七、选型与落地清单

把全文收敛成可执行的检查项：

1. 是否已用真实业务测试集跑出 CER 基线，并有行级、页级指标？
2. 语言资源是否正确覆盖简体/繁体？是否存在竖排文本需要变体模型？
3. 是否包含数学公式、历史字形、多语混排等特殊场景？
4. 预处理是否覆盖倾斜校正、去噪、分辨率控制与版面切分？
5. 是否建立词典、正则、置信度重试等后处理链路？
6. 在延迟与成本预算内，高精度与轻量模型如何分工？是否需要微调？

识别率不是一次性的选型结果，而是“模型 + 数据 + 工程链路”持续迭代的过程。先建立可量化的评估基准，再选对语言资源，最后补全预处理与后处理，中文 OCR 的效果提升会比反复“换软件”实在得多。