一、先看全景：OCR 是一条多阶段流水线

很多人以为“文字识别”是单个模型一步到位，实际上工业级 OCR 系统几乎都是一条多阶段流水线：输入图像 → 预处理 → 文本检测 → 文本识别 → 版面分析与结构还原 → 后处理。每个阶段的算法选型，共同决定了最终的准确率与速度。

原始图像 / 扫描件 / PDF 页面渲染图
   │
   ▼
预处理（灰度化、二值化、去噪、纠偏、缩放）
   │
   ▼
文本检测 → 得到一个个文本框坐标
   │
   ▼
方向分类 + 文本识别 → 每个框内的字符串
   │
   ▼
版面分析（区域分类 + 阅读顺序）→ 表格/标题/正文结构还原
   │
   ▼
后处理（置信度过滤、纠错、归一化）→ 结构化文本输出

因此，“OCR 用什么算法”并不存在唯一答案，而是检测、识别、结构化三类算法的组合。下面逐段拆解。

二、图像预处理：被低估的第一道关卡

深度学习时代，预处理常被忽视，但它直接决定模型看到的输入分布，处理不好会让后续所有环节“带病运行”。

• 灰度化与二值化：全局阈值（如大津法）在光照均匀时表现尚可，但对阴影、背光场景容易丢字。自适应阈值按局部窗口计算阈值，对复杂背景更稳健。
• 去噪与增强：扫描件常见的噪点、摩尔纹可用中值滤波、形态学操作处理；对低对比度图像可做直方图均衡或对比度拉伸。
• 倾斜与透视校正：通过霍夫变换检测文本基线估计倾斜角，再做旋转矫正；拍照文档则可先检测文档四边，用透视变换把页面“拉平”。
• 分辨率归一化：文本行高度过小会导致识别率骤降，通常限制图像最长边并保证小字号文本有足够的像素高度；过长边也会拖慢检测阶段，需在精度与速度间取平衡。

一段示意性的预处理伪代码：

# OCR 预处理流程（伪代码）
img     = load_image(path)
gray    = rgb_to_gray(img)
binary  = adaptive_threshold(gray, block=31, c=15)
angle   = estimate_skew_by_hough(binary)
upright = rotate(img, -angle)          # 纠偏
resized = resize_limit(upright, max_side=1280)  # 归一化

三、文本检测算法：解决“字在哪里”

文本检测的目标是在图像中框出所有文本区域，是自然场景与文档场景都绕不开的一步。

1. 传统方法。 早期方案依赖手工特征：滑动窗口配合边缘、纹理特征逐窗分类；或利用连通域分析（如最大稳定极值区域的思路）找出字符候选，再用规则合并成行。这类方法在简单印刷场景可用，但面对复杂背景、多方向、弯曲文本几乎无能为力，这也是深度学习接管该领域的原因。

2. 基于候选框的两阶段思路。 以 CTPN 为代表：在卷积特征图上用一组竖向细长的 anchor 检测“文本片段”，再用双向循环网络把水平方向相邻的片段关联成完整文本行。它显式建模了行内上下文，对长文本行很友好，但主要面向水平文本。

3. 单阶段直接回归思路。 以 EAST 为代表：网络直接回归每个文本区域的四顶点坐标（或旋转矩形参数），配合简单的非极大值抑制即可输出结果，省去繁琐的候选框流程，速度快，且天然支持带角度的文本。

4. 基于分割的思路。 以 DBNet 为代表：预测每个像素属于文本的概率图，再把概率图还原成文本框。其关键创新是把二值化这一不可导的后处理步骤改写为可微分近似，让网络能学到更贴近文本真实边界的概率图，对小文本、密集文本都更稳健。在此基础上，PSENet 一类算法通过渐进式收缩生成不同尺度的“文本核”再逐步扩张合并，能分离紧挨着的文本行，适配任意形状（包括弯曲文本）。

选型建议：纯文档、水平排版场景，分割类方案（DBNet 思路）是目前最通用的默认选择；倾斜票据、自然场景则优先考虑支持任意形状与角度的方案。

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

检测出文本框后，识别算法负责把框内的图像“翻译”成字符串。

1. CRNN + CTC：最经典的工业范式。 流程是“卷积网络提特征 → 双向 LSTM 建模上下文 → CTC 解码”。卷积网络把文本行图像压缩成沿宽度方向的特征序列；双向循环网络让每个时刻既能看到左边又能看到右边的上下文；CTC（联结主义时序分类）则解决“输入帧数与输出字符数不对齐”的核心难题——它引入一个空白符号，把输出展开到与输入帧数等长，训练时用动态规划对所有可能的对齐路径求和，因此不需要逐字符标注位置；推理时按“合并重复、删空白”规则得到最终文本。这套方案结构简单、推理高效，长期是各类通用识别引擎的主力。

2. 注意力编解码（Seq2Seq + Attention）。 解码器每一步对编码器输出的各帧特征计算注意力权重，加权求和得到上下文向量，再预测当前字符。它不要求严格对齐，对弯曲、透视等不规则文本的适应性更好，缺点是长文本可能出现“越写越偏”、重复或漏字。

3. 视觉—语言预训练模型。 近年来的重要方向是把 Transformer 引入 OCR：先在海量无标注图文数据上做预训练，再在具体任务上微调。由于同时利用了视觉特征与语言先验，这类模型在手写体、模糊图像、复杂版式上的泛化能力明显更强，也推动检测与识别走向端到端的统一建模。

4. 端到端方案。 把检测和识别放进一个网络联合训练，减少级联误差，适合版式简单、追求低时延的场景；但复杂文档场景中，显式分开的两阶段方案通常更可控、更易调试。

文本行图像 H×W
   │  CNN 主干提取视觉特征
   ▼
特征序列 T×C（沿宽度切成 T 帧）
   │  双向 LSTM / Transformer 建模上下文
   ▼
CTC 解码 或 Attention 逐步生成
   ▼
输出示例："发票号码：12345678"

五、版面分析与结构还原：从“认字”到“读懂文档”

如果只是输出一堆碎字符串，OCR 只完成了一半。要把一页 PDF 或图片转成 Markdown 这类结构化文档，还需要版面分析：

• 区域分类：用目标检测或语义分割模型区分正文、标题、表格、图片、页眉页脚等区域类型，各自走不同的解析策略——正文走识别，表格走表格结构还原，图片只保留位置信息。
• 阅读顺序还原：多栏排版、跨栏标题、侧边批注都会打乱天然顺序，需要结合几何位置与排版规则对文本块排序，否则输出内容会“串行”。
• 表格结构还原：这是公认难点。有线表可借助线条检测划分单元格；无线表、合并单元格则更多依赖视觉模型预测行列结构，再结合单元格文字拼装成 HTML 或 Markdown 表格。
• 多模态信息融合：字号、加粗、居中等排版属性可辅助判断标题层级，让 Markdown 输出的层级结构更准确。

六、后处理与纠错：最后一公里

模型输出并非终点，工程上通常还有一层后处理：

1. 置信度过滤：低置信度的文本框可标记待人工复核，避免错误结果污染下游数据。
2. 归一化：全角/半角统一、大小写规范、多余空白剔除。
3. 词典与语言模型纠错：利用领域词典或轻量语言模型修正“形近字”错误（如“己/已/巳”）。
4. 业务规则校验：金额、日期、证件号的格式与校验位检查，能拦下大部分硬错误。

七、部署与加速：CPU 与 GPU 如何取舍

算法之外，部署方式直接决定使用体验。通用规律如下：

• CPU 推理：门槛低、环境要求简单，适合轻量体验与小批量任务；瓶颈在算力，批量处理或复杂版式（大量表格、高分辨率扫描件）时耗时会明显上升。
• GPU 推理：卷积与矩阵运算高度并行，天然适合 GPU，典型加速可达数倍。但要注意三件事：其一，模型加载常驻显存通常在 GB 级，处理高分辨率复杂文档时峰值会显著升高，显存偏小的设备批量处理容易触发 OOM（显存溢出）；其二，新发布的显卡型号可能存在驱动与算子兼容性验证周期，生产环境建议使用经过验证的稳定配置；其三，GPU 需要配套的驱动与运行时环境，部署门槛高于 CPU。

维度	CPU 推理	GPU 推理
部署门槛	低，开箱即用	需驱动与运行时配套
单页时延	秒级～十秒级	毫秒级～秒级
吞吐能力	低，适合小批量	高，适合批量与并发
主要风险	速度瓶颈	显存溢出、兼容性

（具体耗时因模型大小、图像复杂度而异，上表为量级参考。）

通用优化清单：

• 半精度/低比特量化：FP16 通常几乎无损精度，INT8 需要做量化校准，可显著降低显存占用并提速；
• 算子融合与推理引擎优化：合并小算子、优化内存布局，减少冗余开销；
• 批处理与动态分辨率：把多张图打包成 batch 提升 GPU 利用率，同时按输入复杂度动态调整分辨率；
• 服务化要点：请求排队与并发控制、显存水位监控、启动预热（先跑一次空请求避免首次请求超时）、端口冲突检测，以及“显存不足自动降级到 CPU”的兜底策略。

八、常见问题排查清单

1. 首次启动很慢：模型权重常驻加载加计算图预热所致，属正常现象，建议服务就绪后先做一次预热调用。
2. 服务无响应：先检查端口是否被其他进程占用，更换端口或结束占用进程即可。
3. 处理大文件闪退：多为显存/内存溢出，可限制图像最长边、降低并发数，或切换到 CPU 模式。
4. 识别率偏低：依次排查图像分辨率是否足够、文本方向是否正确、所用模型是否匹配目标语种与文体（印刷/手写）。
5. 表格与结构错乱：优先加强版面分析与阅读顺序排序，必要时更换表格结构还原策略，而非一味调识别模型。

九、自建还是用云服务？

• 自建/自部署：数据不出域、可深度定制模型与后处理规则，适合对数据合规要求高、有算法团队的场景，代价是部署、调优与运维成本。
• 调用云服务：以百度智能云为代表的厂商提供了通用文字识别、表格识别、票据证照识别等标准化 API 能力，开箱即用、免运维，适合快速集成与流量波动较大的业务。评估维度建议覆盖识别准确率、响应时延、并发配额、调用成本与数据安全条款。
• 混合策略：敏感数据自建处理，通用场景走云 API，兼顾合规与效率。

十、小结

OCR 从来不是“一个算法”，而是检测 + 识别 + 版面分析 + 后处理的系统性工程：检测端从手工特征演进到基于分割的任意形状检测，识别端从 CRNN+CTC 演进到注意力与视觉—语言预训练模型，工程端则要在 CPU/GPU、量化、并发与显存之间做精细取舍。理解每个环节的算法思想与适用边界，再结合自身的数据特点与算力条件选型，才能既“认得准”，又“跑得快”。