12款开源OCR引擎横评：按场景选型与落地避坑

1. 测评缘起与整体设计思路

先说结论：OCR 这活儿，看着是"图片进、文字出"的黑盒，实际上不同引擎在不同场景下的差距能有天壤之别。同一张发票，A 引擎能给你连表头带税额框完整还原，B 引擎可能把"¥"认成"Y"、把"0"认成"O"，还得你手工再校一遍。所以这次我干脆把手上能跑通的十二款开源 OCR 引擎拉到一个台面上，用统一的测试集、统一的评分标准做一次横评，把每款的脾气摸清楚。

这个测评解决的核心问题很直接：当你手上有一批扫描件、截图、拍照文档、票据或者带公式的 PDF，到底该选哪一款开源 OCR 引擎？是选识别精度最高的，还是选部署最省事的？是选中文强项的老牌项目，还是选近几年冒出来的深度学习新秀？很多人选型时只看 GitHub 星数或者某篇博客的一句"效果不错"，结果落地后发现要么中文标点全丢，要么表格结构全乱，要么 GPU 跑不动只能退回 CPU 然后慢到不可用。这篇内容就是要把这些坑提前摊开。

适合谁来读：做文档数字化、票据信息提取、知识库构建、RAG 前置解析、批量扫描件归档的开发者；负责企业内部系统选型的技术负责人；以及单纯想给自己小工具加个图片转文字能力、又不想调云服务接口的独立开发者。无论你是刚接触 OCR 的新手，还是已经踩过几轮坑的老手，下面的拆解应该都能给你一些可以直接抄的配置和判断依据。

整体的测评设计思路是这样的：先分类，再统一，最后分场景打分。所谓分类，是把十二款引擎按技术路线和定位分成几组——传统图像处理派的、深度学习检测识别派的、以及端到端文档解析派的。不同派系的强项本来就不同，硬拉一个总分排名没有意义，必须按场景分维度评价。所谓统一，是让所有引擎吃同一批测试样本、输出同一种格式，避免因为预处理差异导致的不公平。所谓分场景打分，是分别针对印刷体中文、英文混排、表格结构还原、票据字段、低质量拍照件、公式与特殊符号这几类真实需求打权重分，最后给出"什么场景选谁"的结论。

我特意没有把"安装难度"单独作为扣分项混进精度里，而是把它拆成独立的一列。原因很简单：精度是天花板，部署是地板。一个精度 95 分但只能跑在特定 CUDA 版本上的引擎，对一个只有 CPU 服务器的团队来说实际价值可能还不如精度 85 分但一条命令就能跑起来的。把这两件事混在一起算总分，是最容易误导选型的做法，我在早期给别人做咨询时就犯过这个错，后来被现实教育了好几次。

测评样本的构成也要说清楚，因为这直接决定结论的适用范围。我一共准备了六组、合计约 1200 张样本，全部是自有或合成的合法素材，覆盖：清晰印刷体中文（书籍扫描、合同打印件）、中英混排技术文档、有线表格（财务报表样式）、无线表格（名单、清单）、手机拍摄的倾斜带阴影文档、以及含上下标和简单公式的学术排版件。每组 200 张左右，人工标注基准文本，作为精度评分的对照答案。这个规模不算大，但足够暴露各引擎的系统性偏差，比只拿三五张图"感觉一下"要靠谱得多。

顺带提一句评测环境，避免有人复现时环境不一致导致结论打架。主力机器是一台带单张消费级显卡的 Linux 工作站，另有台纯 CPU 的机器用来测无 GPU 场景的可用性。所有引擎统一在容器里跑，Python 依赖尽量隔离，避免版本互相污染。这一步非常重要，OCR 类项目的依赖冲突是出了名的，尤其是深度学习框架版本和图像处理库版本，混装之后报的错往往和真实问题毫无关系，会让你误以为是引擎本身不行。

2. 十二款引擎的分类与技术路线拆解

2.1 按技术路线分成三派

十二款引擎如果一个个平铺介绍，读者看完还是记不住。我按内部技术路线把它们归成三派，这样理解起来有骨架：

传统派里那几款老项目，很多是十几年前就成熟的方案，代码干净、依赖极少，扔到一台老服务器上编译一下就能跑，处理规整的印刷体扫描件依然很能打。它们的价值在于"确定性"——你大概能预判它在什么情况下会失败，因为它没有黑盒模型。深度学习派是当下的主流，检测网络负责找文字框，识别网络负责把框里的内容转成字符，中间还有方向分类、去畸变等环节，整体精度比传统派高一个档次，但对显存和算力有要求。端到端文档解析派是最近两年最热的方向，它不只给你文字，还给你"这段文字属于哪个单元格、属于第几段、阅读顺序是什么"，对做结构化提取的人来说是刚需。

这里要解释一个关键的设计取舍：为什么两阶段（检测+识别）会成为主流，而不是一个大模型直接端到端出文字？因为检测和识别的失败模式完全不同。检测失败是"框没找对"，识别失败是"框找对了但字认错了"，两者分开训练、分开调优，出了问题能定位到具体环节。端到端模型一旦出错，你很难判断到底是定位错了还是分类错了，调试成本高得多。当然端到端在版面结构还原上有天然优势，所以现在很多项目是"两阶段做文字 + 额外一个版面模型做结构"，混合路线。

2.2 精度之外的四个隐藏维度

很多测评只看字符准确率，这是不够的。我在测评里额外记录了四个维度，它们在实际落地时经常成为决定性因素：

第一是标点与全半角处理。中文 OCR 最容易翻车的地方之一就是标点。有的引擎会把中文句号认成英文句点，把全角括号认成半角，把中文引号认成直引号。单看字符准确率影响很小，但对下游做文本分析、做检索、做正则匹配的人来说是灾难——你按中文标点写的规则全部失效。我在统计时单独拉了一列"标点一致性"，结果差异比想象中大。

第二是阅读顺序与换行还原。多栏排版、图文混排的文档，引擎输出的文字顺序如果乱了，后面做段落切分、做 RAG 分块就全乱。有的引擎按检测框坐标从上到下排，遇到双栏文档就会左右横跳；有的引擎做了版面分析，能识别栏结构，输出顺序就正常。这一项对做知识库的人比纯准确率还重要。

第三是坐标信息的可用性。引擎除了给文字，还给不给每个字或每行的边界框坐标？坐标的粒度是字级、行级还是块级？这对于需要做"点击定位原文""高亮匹配"的应用是硬需求。有些引擎只吐纯文本，有些吐带坐标的 JSON，这个差别直接决定你能不能做上层交互。

第四是长图与大图的稳定性。处理一张分辨率很高的长截图或者大幅面扫描件时，有的引擎会因为检测网络输入尺寸限制而漏检边缘内容，或者内存暴涨直接崩掉。我专门用几张大尺寸样本做了压力测试，记录是否 OOM、是否漏检、是否需要手动切图。

提示：选型时不要只跑官方 demo 的那几张漂亮样例图，那都是挑过的。一定拿你自己业务里最脏、最歪、最糊的那批图去试，能跑通再谈其他。

2.3 十二款引擎的定位概览

为了不让篇幅变成产品说明书，我只按定位给个速览，具体能力在后面章节结合实测展开。十二款大致分布是：三款传统图像处理路线（其中一款偏轻量嵌入式场景）、六款深度学习检测识别路线（覆盖中英文强项、多语言强项、轻量移动端强项几种取向）、三款端到端文档解析路线（主打表格与版面结构）。

这个分布本身反映了当下的行业格局：纯传统方案在通用场景已经基本退出主流，但在特定垂直场景（比如固定版式的单据、资源极度受限的嵌入式设备）仍有生命力；深度学习两阶段方案是当前的性价比主力；端到端文档解析方案是结构化提取的未来方向，但部署成本还偏高。我测评完之后最大的感受是，没有一款能通吃，选型的本质是"用你的场景去匹配它的强项"，而不是找一个全能冠军。

举个具体例子说明这种匹配思路。如果你要做的是"把一批规整的书籍扫描 PDF 转成可检索文本"，那传统派或者轻量深度学习派完全够用，追求高精度端到端方案纯属浪费算力；如果你要做的是"从合同照片里抽出甲方乙方、金额、日期这些字段"，那就必须选带版面分析、能给出结构化结果的方案，哪怕它重一点、慢一点；如果你要做的是"移动端离线识别名片"，那模型体积和 CPU 推理速度就是第一约束，精度稍微让一点完全可以接受。带着这个匹配思维往下看，会比记一堆参数有用得多。

3. 测评环境搭建与实操过程

3.1 环境隔离与依赖管理的具体做法

这一节讲实操，因为环境搭建本身就是 OCR 测评里最耗时的部分，也是很多人放弃横评的原因。我的做法是每款引擎一个独立容器，基础镜像统一用同一个精简的 Linux 发行版，Python 版本统一在 3.10，然后各自装依赖。为什么不共用一套环境？因为深度学习框架的版本冲突几乎是必然的——某款引擎要求较新的框架版本，另一款只能在旧版本上跑，硬凑在一起就是无尽的报错。

容器化的具体收益在测评场景下特别明显：跑完一款，把容器删掉，不留任何残留；换一款，从干净镜像重来，结果可复现。我建议任何做引擎对比的人都走这条路，成本是多花半小时写 Dockerfile，收益是省下几天和依赖冲突搏斗的时间。

依赖安装里有几个通用的坑，我提前列出来：

• 图像处理库版本：某几款引擎对图像处理库的版本很敏感，新版改了某些插值或色彩转换的默认行为，会导致预处理结果轻微偏移，进而影响识别。锁版本，别用"最新"。
• 深度学习框架的 CPU/GPU 变体：装错变体会导致明明有显卡却只用 CPU 跑，速度差十几倍，而且不会报错，只是慢，很容易被误判为"这引擎性能不行"。
• 模型权重下载：多数深度学习引擎首次运行会自动下载权重，如果网络环境不稳，会出现下载一半失败但程序不报明确错误的情况。建议提前手动下载好权重放到指定目录，或者至少在首次运行后确认权重文件大小正常。

3.2 统一测试集与评分口径

评分口径不统一，横评就是耍流氓。我定的口径是这样的：

字符准确率用编辑距离计算，即 1 减去（替换+删除+插入次数）除以基准字符数。这是 OCR 领域最通用的指标，好处是能反映插入和遗漏，坏处是对长文档里少量错误不敏感，所以我又补了一个整行完全正确率，也就是一行里一个字都没错才算对。这两个指标一起看，能区分"整体不错但总有零星错误"和"某些行整行崩掉"两种不同的问题模式。

表格还原单独评分，按单元格内容正确率和结构正确率两项算。结构正确指的是行列数对得上、合并单元格没丢。这一项我用手工核对的方式做，因为自动比对表格结构的工具可靠性一般，样本量控制在每组几十张，人工可承受。

票据字段抽取按字段级准确率算，也就是金额、日期、编号这类关键字段抽对了才算数，字段里有一个字符错就算整个字段错。这个口径比字符准确率严格得多，更贴近真实业务要求。

低质量拍照件额外记录"是否需要人工干预"，比如是否需要先做透视校正、是否需要调对比度才能出结果。这一项是主观判断，但很实用，因为它直接对应你落地时的工程成本。

注意：所有样本在送入引擎前都不做额外预处理，除了统一转成 RGB 和必要的缩放。这是为了测引擎自身的鲁棒性。如果你在实际业务里会做预处理，那各引擎的差距可能会缩小，但"谁更依赖预处理"本身就是重要的选型信息。

3.3 批量测试脚本的骨架

手工一张张测不现实，我写了一个统一的批量跑批脚本，核心逻辑是"遍历样本目录 → 调对应引擎的适配函数 → 收集输出 → 和基准比对 → 写结果表"。适配层是关键，每个引擎包一个函数，输入图片路径、输出统一格式（文本 + 可选坐标）。这样上层评分逻辑完全复用，新增引擎只要加一个适配函数。

伪代码骨架大致是这样：

# 统一适配层示意，非可直接运行代码 def run_engine(name, img_path): if name == "engine_a": return adapter_a(img_path) # 返回 {"text": ..., "boxes": [...]} elif name == "engine_b": return adapter_b(img_path) # ... def batch_eval(engine_names, sample_dir, gt_dir): results = [] for eng in engine_names: for img in list_images(sample_dir): pred = run_engine(eng, img) gt = load_gt(gt_dir, img) cer = compute_cer(pred["text"], gt) line_acc = compute_line_acc(pred["text"], gt) results.append({"engine": eng, "img": img, "cer": cer, "line_acc": line_acc}) save_csv(results)

这个骨架的价值在于把"引擎差异"和"评分逻辑"彻底解耦。我见过不少人测到一半发现评分脚本写错了，前面几款得重跑，如果脚本是耦合的就非常痛苦。另外记得给每个引擎的调用加超时和异常捕获，某款引擎在特定图片上卡死或者崩溃是常事，不能让一张坏图毁掉整轮测试。

实测下来，一轮全量测试（十二款 × 1200 张）在带显卡的机器上跑了大约一天多，主要时间花在几款端到端大模型上。CPU 环境下我只跑了抽样，因为全量跑完估计要一周，没有意义。这个时间成本也提醒各位：如果你的业务是离线批处理，慢一点无所谓；如果是实时接口，端到端大模型基本可以排除，得往轻量方案走。

4. 分场景实测结果与核心发现

4.1 清晰印刷体中文：传统派并未出局

这组样本是最"友好"的，规整扫描件、字体标准、无倾斜无阴影。结果很有意思：三款传统派引擎里，有两款的字符准确率追到了深度学习派的九成以上，整行完全正确率的差距更小。其中一款在纯中文、无标点混排的样本上甚至反超了部分深度学习引擎。

为什么？因为清晰印刷体的识别本质上是"字形匹配"，传统方案在训练充分、字体规整时表现非常好，而深度学习模型的优势主要体现在抗干扰和泛化上，在这种"没干扰"的场景里优势发挥不出来。这给了我一个很实际的启示：如果你要处理的文档质量很稳定、版式很固定，别迷信大模型，轻量方案可能又快又准还省资源。

但传统派在这组里也暴露了一个短板：标点一致性。三款传统引擎里有两款对中文标点的处理比较粗糙，全角半角混用明显，句号逗号的判断依赖启发式规则，遇到中英混排就更容易错。深度学习派在这一项上普遍更好，因为它们是从数据里学的，训练集里标点模式更接近真实文本。

4.2 中英混排技术文档：深度学习派的优势区间

中英混排是最能拉开差距的场景之一。技术文档里一段话可能包含中文、英文术语、数字、代码片段、单位符号，还有各种括号和连字符。这组测试里，传统派的准确率明显下滑，主要错在三个地方：英文单词被拆成单个字母、数字和字母混淆（0/O、1/l/I）、以及中英文之间的空格该保留还是该删判断不一致。深度学习派整体稳得多，尤其那两款明确针对中英混排优化过的引擎，表现接近可用。

这一组里还有个细节值得说：中英文之间的空格处理，各家策略不同。有的引擎会自动在中文和英文之间插空格，有的不会，有的时有时无。如果你的下游要做文本比对或者检索，这种不一致会带来麻烦，建议在选型时专门测一下，然后在上层做统一规整。我自己是在后处理层写了个简单的规则，按需统一处理，比指望引擎自己处理好更可靠。

另一款定位轻量、面向多语言的引擎在这组里表现中规中矩，准确率不及头部，但胜在速度快、模型小，适合对延迟敏感的场景。它的错误模式也比较可预测，主要是生僻字和复杂符号，常见字词基本不出错。这种"可预测的弱"其实是可以接受的，因为你可以在后处理里针对性地补。

4.3 表格结构还原：端到端派的主场

表格是 OCR 落地里最硬的骨头，也是这次测评里差距最大的一项。传统派基本不具备表格结构还原能力，给你的是按行排的文本，行列关系全丢；深度学习派里有一部分做了简单的表格处理，但多数只能处理有线表格，遇到无线表格（靠留白和对齐暗示列关系）就抓瞎；三款端到端文档解析派在这一组优势明显，能输出带行列结构的 JSON，无线表格也能靠版面分析还原出较好的结构。

但要说明的是，端到端派在表格上的"优"也不是无条件的。样本里表格线特别淡、或者单元格里有换行文字、或者表头是多层合并的复杂表格，它们的结构还原也会出错。而且这些引擎普遍对图片分辨率和清晰度要求更高，稍微糊一点，结构就散。我的经验是：表格提取做到八成就得靠人工校对兜底，别指望全自动一步到位，工程上更现实的做法是"自动提取 + 可视化校对界面"，把人的精力集中在机器没把握的部分。

表格这一项还有个成本考虑：端到端大模型的推理速度明显慢，处理大批量表格文件的时间成本是深度学习派的数倍。如果你的表格量很大、结构又比较简单（比如都是规整的有线表格），用中等方案加规则后处理可能比上大模型更划算。这是典型的"精度 vs 成本"权衡，没有标准答案，得按你的量级和容忍度算。

4.4 票据字段抽取：严格口径下的真实水平

票据是我个人认为最难、也最能体现引擎真实水平的场景，因为票据的文字密集、字号小、有背景底纹、有各种框线和印章干扰，而且业务上对准确率要求极高——金额错一位就是事故。这组我用严格口径，字段里错一个字符就算整字段错。

结果是：没有一款做到让人完全放心。端到端派在字段定位上更好，能明确给出"这个值是金额字段"，但字符层面的识别在底纹和小字号上仍会出错；深度学习派里针对票据优化过的引擎字符识别更稳，但字段定位要自己写后处理规则去切。传统派在这个场景基本退出竞争。

这一组让我印象最深的是一个反直觉现象：加了图像预处理（去底纹、增强对比度）之后，各引擎的整体排名变化不大，但绝对准确率都有提升，而且提升幅度不同。这说明头部引擎的优势主要来自模型本身，而不是对预处理的依赖。反过来说，如果你拿到的图片质量差，做预处理是普惠性的收益，值得投入。

4.5 低质量拍照件：鲁棒性差距被放大

手机拍摄的倾斜、带阴影、有透视变形的文档，是真实业务里最常见的输入形态。这组的结果差距非常大。传统派几乎全军覆没，主要原因是倾斜和透视会让字符切分完全错乱；深度学习派靠检测网络能扛住一定程度的倾斜，但角度大了、阴影重了，检测框会偏移甚至漏检；端到端派因为内置了版面分析和方向校正，整体更稳，但也不是万能，严重透视变形仍然需要先做几何校正。

这组测试让我形成了一个固定的工程习惯：不管用哪款引擎，先上一个轻量的预处理流水线——自动检测文档边缘、做透视校正、做自适应二值化或对比度增强。这条流水线把各引擎的起点拉平了，剩下的差距才是引擎本身的能力。实测下来，预处理对低质量图片的收益远大于换更贵的引擎，性价比极高。

提示：透视校正这类预处理，OpenCV 里几个函数组合就能做，不需要上模型。别小看这几十行代码，它能让你的识别准确率上一个明显的台阶，很多"引擎不行"的抱怨其实是"图没处理好"。

4.6 公式与特殊符号：普遍是短板

含上下标和简单公式的学术排版件，是所有引擎的集体软肋。十二款里没有一款能完整正确还原公式结构，最多做到把上下标当普通字符输出（丢掉层级关系），遇到分式、根号就基本无解。特殊符号（数学符号、希腊字母、特殊单位）的识别准确率也普遍偏低。

这个结论对做学术文档处理的人很重要：如果你的核心需求是公式，通用 OCR 引擎都不够用，得找专门的公式识别方案，或者接受"公式部分保留原图、正文部分 OCR"的混合策略。我在实际项目里就是这么干的——正文走通用 OCR，公式区域裁出来单独处理或直接嵌原图，比硬啃公式要实际得多。

5. 工具选型与资源配置的实操判断

5.1 按场景匹配引擎的决策路径

测评数据摆完之后，落地时最需要的其实是一张决策路径，而不是一堆分数。我把自己实际的判断逻辑整理成这样：

第一步问：我的输入图质量稳不稳？如果稳（都是规整扫描或截图），优先考虑轻量方案，传统派或轻量深度学习派都能打，省算力省时间。如果不稳（拍照、多来源、质量参差），那预处理必须上，引擎侧优先选抗干扰强的深度学习派或端到端派。

第二步问：我需要纯文本还是结构化结果？只要文字，不要结构，深度学习两阶段方案性价比最高。要表格、要段落、要阅读顺序，那就得端到端文档解析方案，没有捷径。

第三步问：我有多少算力？只有 CPU 的话，端到端大模型基本可以划掉，除非你的批处理任务对时间完全没要求。有显卡的话，端到端方案才进入候选。

第四步问：我的业务量级多大？每天几万张的批量任务，推理速度就是成本，得选吞吐高的；每天几十张的轻量任务，可以容忍慢一点但精度高的方案。

我见过最常见的选型错误是一上来就选最先进、最重的方案，觉得"新的肯定比旧的好"。结果部署卡了一周，跑起来发现速度慢到无法上线，最后灰溜溜退回轻量方案。先定约束（算力、延迟、成本），再在约束内选精度最高的，这才是正确的顺序。

5.2 资源占用的实测参考

为了给配置决策一个参考，我记录了几类方案的资源画像（数值是相对量级，不追求绝对值）：

这个表最直接的用途是算成本。假设你要处理十万张图，单图耗时差 10 倍，那就是几小时和几十小时的差别，对应的服务器成本差好几倍。很多人在做方案对比时只看准确率差那两三个点，忽略了成本差一个数量级，这在业务上是不可接受的。

还有一点：端到端方案的显存占用波动很大，取决于图片分辨率。处理大尺寸扫描件时，显存峰值可能比处理普通截图高好几倍，配置显存时一定要按最坏情况留余量，否则生产环境偶发 OOM，排查起来非常折磨。我在测试时就遇到过一张大图直接把显存吃满导致进程被杀的情况，后来加了尺寸上限和自动切图逻辑才稳住。

6. 常见问题排查与避坑实录

6.1 那些"看起来像引擎不行"其实是配置问题

这一节是我最想写的，因为实际踩的坑大量集中在这里，而且这些坑不会写在任何官方文档里。

问题一：深度学习引擎在显卡机器上速度却和 CPU 一样。九成是装成了 CPU 版本的框架，或者显卡驱动与框架版本不匹配导致静默回退。排查方法是跑一句环境检测代码，确认框架能否看到设备。这个坑的阴险之处在于不报错，只变慢，新手很容易直接给引擎判死刑。

问题二：识别结果里中文全是乱码或问号。通常是字体文件缺失（部分引擎依赖字体渲染）或者编码参数没设对。还有一种是模型权重下错了版本，比如用了不包含中文的模型。排查顺序：先确认权重文件正确，再确认输出编码，最后查字体依赖。

问题三：同一张图两次运行结果不一样。深度学习推理如果开了非确定性模式或者预处理里用了随机增强，结果会有细微波动。生产环境建议关掉所有随机性，保证可复现。测试环境则要意识到这种波动的存在，别因为零点几个百分点的差异就纠结。

问题四：某款引擎在特定图片上直接崩溃。常见原因是大图导致内存溢出、图片色彩空间不符合预期（比如 CMYK、带透明通道）、或者图片本身损坏。在适配层加异常捕获和图片规整（统一转 RGB、限制最大尺寸）能解决绝大部分。

问题五：输出文字顺序错乱，双栏文档被读成交错。这是版面分析缺失导致的，属于引擎能力限制而非 bug。解决办法要么换带版面分析的引擎，要么自己在后处理里按坐标做聚类重排。后者是可行的，按 x 坐标把检测框分左右两栏，分别按 y 排序，再拼接，效果不错。

6.2 问题速查表

6.3 我踩过的最贵的三个坑

第一个坑：用官方 demo 效果做选型决策。早期我拿几款引擎的官方在线 demo 试了试，觉得都不错，就选了个文档最漂亮的。结果上线处理真实扫描件时，准确率断崖式下跌。教训是 demo 用的都是精选样本，一定要用自己业务里最脏的数据测。从那以后我选型第一件事就是收集"魔鬼样本集"——最难的那批图，谁能过谁留下。

第二个坑：忽略后处理的价值。有一段时间我执着于找"开箱即用准确率最高"的引擎，后来发现把精力花在后处理上收益更大。比如针对数字和字母混淆做规则纠正、针对标点做统一、针对特定业务词典做纠错，这些后处理往往能把可用性从八成提到九成以上，成本却比换更重的引擎低得多。OCR 落地从来不是"选个引擎就完事"，引擎是起点，后处理才是把准确率推到业务可用线的关键。

第三个坑：低估了批量处理的工程复杂度。单张图测试很顺利，一到批量就出问题——内存泄漏（某些引擎反复调用不释放资源）、并发冲突、失败重试缺失导致一张坏图卡住整批。后来我加了任务队列、失败隔离、断点续跑，才算稳定。如果你的场景是持续批量处理，这些工程细节的投入不比选引擎少。

提示：在批量流水线里，务必做到"单张失败不影响整批"，把失败的图单独记录下来二次处理。我见过太多因为一张异常图导致整个跑批任务中断、从头再来的惨案。

7. 落地建议与后续可扩展方向

7.1 给不同团队的选型建议

基于这次的实测，我给几条可以直接参考的建议，按团队情况分：

资源紧张、需求简单的团队（只有 CPU、处理规整文档、只要文字）：从传统派或轻量深度学习派里挑一款部署最省事的，配一套简单的预处理和标点规整后处理，足够支撑大部分文档数字化需求。别去碰端到端大模型，投入产出比不划算。

有显卡、需求中等偏上的团队（要处理多来源文档、需要一定结构化能力）：深度学习两阶段方案是主力，选一款中文强、社区活跃、文档齐全的，把预处理流水线和后处理规则做扎实。这一档的性价比最高，也是我最常推荐的配置。

做结构化提取、有明确表格和版面需求的团队：端到端文档解析方案是绕不过去的，但要接受"自动提取 + 人工校对"的工作模式，做好校对界面和反馈闭环。同时准备好足够的算力预算，这一档的资源消耗确实高。

对延迟极敏感的实时场景：往轻量方向走，模型越小越好，甚至考虑传统方案，精度上让一点换速度，然后用业务词典和后处理补。实时场景里，慢就是不可用，这一点没有商量余地。

7.2 后续可以继续深挖的方向

这次测评覆盖了通用能力，但还有几个方向我打算继续做，也供你参考：一是垂直领域的微调，通用模型在特定领域（比如某类专业文档）上微调后准确率往往有明显提升，成本比换引擎低；二是多引擎结果融合，把两三款引擎的输出做投票或编辑距离对齐融合，实测能降低单引擎的系统性错误；三是端到端流水线的工程化，把预处理、识别、后处理、校对串成一条稳定可运维的链路，这才是落地的真正形态。

最后分享一个我自己一直在用的小技巧：给你的 OCR 流水线加一个置信度过滤。多数引擎会输出每个识别结果的置信度分数，把低置信度的结果单独挑出来交给人工或更强力的方案二次处理，高置信度的直接放行。这个小设计能让整体准确率提升明显，人工成本却只增加很少，比全量人工校对或全量追求高精度引擎都更务实。实测下来，这个策略是我做 OCR 项目里投入产出比最高的一招，没有之一。