手上有一批扫描件，四十七页，是十年前的一份合同。要的不是图片，是能搜索、能复制的文字。
这时候搜「OCR 工具」，会得到一堆推荐，每条都说自己准确率 99%。准确率是个几乎没用的指标，因为它的分母是你不知道的测试集。真正决定成败的是另外几件事：版式是单栏还是表格、是印刷体还是手写、要不要离线、一次处理几张。
一、先把问题拆成三种
OCR 不是一个任务，是三种差别很大的任务。第一种是「干净单栏印刷体」，扫描件平整、无倾斜、无表格。第二种是「有结构的版面」，表格、双栏、页眉页脚、印章。第三种是「非标准书写」，手写、艺术字、竖排。
同一个工具在前两种之间的表现差距，往往比两个工具之间的差距更大。所以选型的第一步不是比较工具，是给自己的材料归类。
下面四个工具，按「装起来的重量」从重到轻排，不按好坏排。
二、Tesseract 5.4：能离线跑，也只在特定条件下好用
它是最老的开源 OCR 之一，也是被集成得最广的一个。命令行一句话就能出结果，不需要 GPU，一台十年前的笔记本也能跑。
tesseract scan-01.png out -l chi_sim --psm 6`–psm 6` 的意思是「假定整页是一块均匀的文本」。这个参数比语言包更影响结果：默认的 psm 3 会自动做版面分析，遇到表格和页眉容易切碎；对单栏正文，直接告诉它「别分析了」反而更准。多数人抱怨 Tesseract 中文差，问题出在 psm 没调，不在模型。
它的边界也很清楚：竖排中文基本不行；表格会退化成一行行按位置拼起来的文本，列关系丢失；手写体识别率很低。它擅长的是「一整页干净的印刷汉字」，仅此一项，但做得足够稳。
三、PaddleOCR 3.x：中文和表格的主场，代价是依赖
国产方案里部署量最大的一个。它的检测模型对中文排版的适应性明显更好，斜置、轻微弯曲、字间距不均的扫描件都能框住。3.x 之后还带了表格结构识别和版面分析，能把一份年报拆成标题、正文、表格三类区域。
代价是环境。它依赖飞桨框架，装 CPU 版大约几百兆，装 GPU 版要匹配 CUDA 与驱动版本，这一步劝退过不少人。它的准确率优势是用「装得上」换来的，装不上就等于零。
如果你的材料里有表格，这个交换通常是值的。表格识别不是把字认出来就完了，还要还原行列结构，而这一层能力在别的开源工具里要么没有，要么要自己拼。识别文字是通行能力，还原结构才是分水岭。
四、RapidOCR：把模型塞进几十兆的那种方案
它的定位很务实：把 PaddleOCR 的模型转成 ONNX，用 ONNXRuntime 跑，不依赖飞桨。pip 装完就能用，模型文件几十兆，Windows 上不需要编译器，也不需要显卡。
pip install rapidocr_onnxruntime
# 另存为 run_ocr.py，与图片放在同一目录
from rapidocr_onnxruntime import RapidOCR
engine = RapidOCR()
result, _ = engine("scan-01.png")
# result 是列表，每一项形如 [框坐标, 文本, 置信度]
# 文本在每一项的第 2 个位置，取 row[1] 即可准确率比原版略低，尤其在小字号和低对比度上，但差距在多数场景里不构成问题。它是「不想为一个功能搭一整套深度学习环境」时的默认答案。
适合的场景很具体：要打进桌面程序、要在客户内网跑、要在一台 4GB 内存的旧机器上跑。不适合的场景同样具体：一次要处理两万页、或者材料里全是表格。
五、系统自带的那个，很多人忘了它存在
Windows 的截图工具和 PowerToys 文本提取（默认 Win+Shift+T），macOS 的实况文本，都能直接在屏幕上框一块区域把字取出来。它们不支持批量，不能指定输出格式，也不便脚本调用。
但它们的准确率不低，因为背后是商业模型，而且零安装、零配置。对「一天五次、每次一段话」的需求，装 Tesseract 是过度工程。
这类工具的真正问题不是能力，是不可审计：你无法知道它把哪一段漏了，也没有中间结果可以查。偶发使用看便利，批量处理看可追溯，这是两条不同的评价标准。
六、四个维度上的对照
| 维度 | Tesseract 5.4 | PaddleOCR 3.x | RapidOCR | 系统自带 |
|---|---|---|---|---|
| 中文印刷体 | 好，需调 psm | 好 | 较好 | 好 |
| 表格结构 | 不支持 | 支持 | 弱 | 不支持 |
| 竖排与手写 | 弱 | 弱到中 | 弱 | 中 |
| 批量与脚本 | 强 | 强 | 强 | 几乎不可 |
注意「中文印刷体」这一格：四个工具都写「好」，但「好」的前提不同。Tesseract 的好要配参数，PaddleOCR 的好要配环境，系统自带的好要配人手。表格里同一格的结果，成本可以差一个数量级。
七、三套组合，对应三种活
第一套，单据与合同归档：PaddleOCR 做主体，加一个脚本按目录批量跑，输出 txt 与 JSON 各一份。JSON 留着，将来换工具时还能比对。归档场景的关键不是这一次认得多准，是三年后还能验证当初认了什么。
第二套，书页扫描：Tesseract 配 psm 6，先把图片统一转灰度、纠偏、二值化，再逐页跑。书页版式简单，用它成本最低，而且结果稳定可复现。版式越简单，越应该选最笨的工具。
第三套，桌面随手用：系统自带加一个快捷键习惯。不需要装任何东西，也不需要维护。把工具成本压到零，是这类需求唯一正确的解法。
八、三种「选错了」的信号
信号一：为一天五张图去装 CUDA。当你开始查显卡驱动版本、开始纠结 cuDNN 匹配，而你手上的活是几十张截图，这个选择已经错了。环境成本一旦超过任务量，工具就从帮手变成了项目。
信号二：把带表格的材料交给 Tesseract。表现是识别出来的文字都在，但每一行的顺序乱了，你开始手写规则去拼列。当你开始为工具补它没有的能力，说明该换工具了。
信号三：用系统 OCR 处理五千张。表现是做得完，但做完之后你不知道哪几张漏了字，也没法重跑。不可复现的批处理，等于没有批处理。
写在最后
OCR 这件事有一个很容易被忽略的性质：它的错误不是均匀分布的。数字、标点、金额、日期，恰恰是最容易错的部分，也恰恰是最不能错的部分。
所以任何 OCR 流程的最后一步都该是同一件事：把关键字段单独校验一遍。合同里的金额、病历里的剂量、发票上的税号，都要有人或规则再看一次。识别率 99% 放在一万字上，就是一百个错字，而其中一个可能在金额上。
工具选型的尽头不是找到最强的那个，是知道它会在哪里出错，并且在那里留一道检查。不是让机器更准，是让错的那一处有人接住。
你上一次用 OCR，最后是逐字校对了一遍，还是直接复制走了？
评论 (0)