一、先看全局：OCR不是单一算法，而是一条流水线

很多人以为OCR就是“一个模型把图变成字”，实际上工业级OCR是一套多阶段协同的算法流水线，典型链路如下：

图像输入 → 预处理 → 文本检测 → 几何/方向矫正 → 文本识别 → 版面分析与结构化 → 后处理与输出

• 预处理负责把原图“整理干净”；
• 文本检测负责回答“字在哪儿”；
• 文本识别负责回答“字是什么”；
• 版面分析与结构化负责回答“这些字以什么组织方式还原文档”；
• 后处理负责纠错、格式化与置信度过滤。

理解了这条流水线，“OCR用的是什么算法”这个问题就可以拆解为：每个环节分别用了什么算法。

二、传统OCR算法：特征工程的时代

在深度学习普及之前，OCR主要依赖“手工特征 + 分类器”的组合：

1. 图像预处理

• 灰度化与二值化：常用Otsu等自适应阈值方法突出文字前景；
• 去噪与增强：中值滤波、形态学开闭运算去除噪点与笔画粘连；
• 倾斜矫正：通过Hough变换检测直线，或按行投影分析估计偏转角后旋转回正。

1. 文字定位

• 连通域分析：将相邻笔画像素聚合成块，按尺寸、位置规则筛出候选文字区域；
• MSER（最大稳定极值区域）：对光照变化更鲁棒的候选区域提取方法；
• 滑动窗口：以多尺度窗口扫描图像，配合分类器判断是否为文字。

1. 特征与分类

• 特征描述：HOG、Gabor、SIFT等刻画字符形状与纹理；
• 分类器：SVM、Adaboost、KNN等完成单字符分类，再按规则拼接成词。

传统方法的局限也很明显：对字体、背景、光照、分辨率高度敏感，规则需要逐场景定制，遇到复杂版面和不规则文本几乎无能为力，这正是它逐步被深度学习方案取代的根本原因。

三、深度学习时代的OCR：检测与识别两大核心

3.1 文本检测算法：解决“字在哪儿”

文本行是长宽比极端、方向任意的“细长目标”，与通用目标检测差异较大，因此衍生出两条主流路线：

• 回归式检测：借鉴通用检测思路直接回归文本框。代表思路有基于候选框按行检测的CTPN，以及单阶段直接回归边界与置信度的EAST。优点是速度快、后处理简单；缺点是对弯曲、倾斜严重的不规则文本表达力有限。
• 分割式检测：先预测每个像素属于文本的概率图，再后处理聚合成文本实例。代表是DBNet及其改进，核心创新是把二值化阈值变为可学习参数（可微分二值化），让前后处理联合优化；PSENet则通过多尺度核渐进扩展贴合任意形状文本。

目前文档场景的工业主流多为分割式检测，主要看中其对长文本、密集排版的稳定性。

3.2 文本识别算法：解决“字是什么”

识别模型的输入通常是检测裁出的单行文本图，输出是字符序列，主流方案有三类：

1. CRNN + CTC：经典高性价比方案
   CNN提取图像特征并将特征图沿宽度方向切成帧序列，双向LSTM建模字符上下文依赖，CTC（Connectionist Temporal Classification）解决“图像帧与字符无法一一对应”的对齐问题：引入空白符，训练时自动对齐，推理时折叠重复字符得到最终文本。其结构简洁、推理快、可端到端训练且无需字符级切分标注，至今仍是量产首选之一。

2. Attention / Seq2Seq 方案
   编码器提特征，解码器带注意力逐字符生成，隐式完成对齐。对弯曲、透视变形文本（票据、街景招牌）效果更好，但推理更慢且可能漏字、重复，工程上常用“CTC+Attention”多任务融合折中。

3. 基于Transformer的识别器
   以自注意力替代LSTM建模长距离依赖，配合大规模合成数据预训练，是当前学术界与工业界公认的主流演进方向，在复杂场景与生僻字符上表现更佳。

3.3 矫正模块：不规则文本的前置补救

对透视畸变、弯曲文本，常在识别器前接入基于TPS（薄板样条）的空间变换网络（STN），把不规则文本行“拉直”后再识别；方向分类器则判断整行是正向、180°旋转还是竖排，避免“识别对了但读反了”。

四、版面分析与结构化：从“认字”到“还原文档”

对于文档转Markdown、票据结构化提取这类需求，仅有检测识别还不够：

• 版面分析：用检测/分割模型把页面划分为标题、正文、表格、图片、页眉页脚等语义区域；
• 阅读顺序还原：多栏、跨栏排版下，按几何规则或图结构推理出符合阅读习惯的输出顺序；
• 表格结构还原：不仅识别单元格文字，还要还原行列层级，常见思路包括行列分割线检测，或把表格结构当作序列直接解码输出HTML/JSON；
• 公式识别：数学公式需专门模型，输出LaTeX类标记语言。

这一层决定OCR结果能否直接进入下游：知识库构建、检索增强、数据入库等场景中，结构化质量往往比单纯字符准确率更影响最终效果。

五、后处理：容易被低估的最后一公里

• 语言模型纠错：用N-gram或预训练语言模型校验结果合理性，纠正形近字（如“己/已”）；
• 词典与业务约束：证照、表单字段有固定格式（日期、金额、证件号），可用正则与校验位规则兜底；
• 置信度过滤与人机协同：低于阈值的字段转人工复核，避免错误数据静默入库。

六、工程实践：让OCR又快又稳

算法选对只是第一步，生产环境更需关注推理工程。

1. CPU还是GPU？
以典型的文档识别模型为例，模型加载后常驻显存约2~3GB，处理复杂版面（大表格、密集排版）时峰值可能达6GB左右；GPU吞吐通常是纯CPU的5~10倍。经验法则：

• 轻量、偶发、单文件场景：CPU足够，部署门槛低；
• 批量、在线服务、复杂版面：优先GPU，并把批处理（batch）打满才能吃满算力；
• 显存偏小（低于4GB）的设备批量跑大模型，易触发OOM（显存溢出），应降低并发数、限制批大小或回退CPU。

2. 推理优化三板斧

• 模型量化：FP16/INT8在精度损失可控的前提下显著提速、降显存；
• 剪枝与蒸馏：用轻量学生模型逼近大模型精度，适合端侧与边缘部署；
• 静态图与推理引擎优化：算子融合、内存复用，减少框架开销。

3. 服务化与稳定性

• 流水线并行：检测、识别分阶段执行，避免GPU空转等待；
• 队列削峰与并发控制：突发流量进入消息队列，推理服务按最大安全并发消费；
• 预热与懒加载：首次请求前完成模型加载与预热推理，避免首个请求超时；
• 降级策略：GPU异常时自动回退CPU模式，保障可用性。

示意性伪代码（流水线编排）：

# OCR流水线示意（伪代码）
def ocr_pipeline(image, det, cls, rec, layout):
    image = preprocess(image)              # 去噪、缩放、归一化
    boxes  = det(image)                    # 文本检测：得到文本框
    lines  = []
    for box in sort_by_reading_order(boxes):
        patch = crop_and_rotate(image, box)
        if cls(patch) != 0:                # 方向矫正
            patch = rotate_180(patch)
        text, score = rec(patch)           # 文本识别
        if score >= THRESHOLD:
            lines.append((box, text))
    doc = layout(lines)                    # 版面分析与结构化
    return postprocess(doc)                # 纠错、格式化输出

七、选型建议：自研还是用云服务？

• 场景标准（证件、票据、通用印刷体文档）：直接集成成熟的云端OCR能力即可快速上线。业界主流云厂商（如百度智能云）普遍提供通用文字识别、表格识别、文档版面还原等通用能力类目，按量计费、免运维，适合绝大多数业务快速落地；
• 场景特殊（工业质检、手写混排、行业术语密集）：可基于开源深度学习框架自行训练或微调检测/识别模型，私有化部署更利于数据合规；
• 折中路线：通用字段走云端接口，敏感字段走私有化模型，按数据分级路由。

八、总结

回到最初的问题——“OCR文字识别用的是什么算法？”答案是分层叠加的：

• 检测层：以DBNet为代表的分割式检测是主流，EAST等回归式方案补充速度敏感场景；
• 识别层：CRNN+CTC是高性价比的经典组合，Attention与Transformer方案代表能力上限；
• 文档层：版面分析+表格结构还原决定输出能否被业务直接消费；
• 工程层：量化、批处理、并发控制与降级策略决定能否稳定承载生产流量。

算法原理决定识别准确率的上限，工程优化决定它在真实业务中的下限。理解整条流水线，才能在面对具体场景时做出正确的技术选型。