第1章 图片文字识别模型对比的评测框架与准确率指标
1.1 对比任务边界与测试集构建
我做过好几轮OCR模型横评，踩过最大的坑不在模型本身，在于一开始就没把任务边界划清楚。同一个模型，拿来做整页文档识别和拿来做票据字段抽取，得出的结论能差出一个身位。有人拿着一份干净扫描件跑出99%的准确率就到处说这个模型最强，换到手写体上直接掉到60%出头，这种对比没有意义。所以我习惯先把场景切成几块：通用文档、中文印刷体、手写体、票据表格、低质图像、复杂版面，每一块单独建测试集，单独打分，最后再横向拼起来看。
测试集怎么建，我的做法是每个场景至少准备200到500张真实样本，不要只用公开数据集。公开数据集里的文档大多版式规整、光照均匀，跟企业实际收上来的图片完全不是一回事。我会特意混入手机翻拍的、带折痕的、倾斜的、盖章遮挡的、表格线模糊的样本，手写体还得区分工整书写和潦草连笔。票据这一类，增值税发票、出租车票、收据各来一点，字段位置和字体差异都挺大。
有个细节很多人忽略：测试集的标注要跟任务边界对齐。整页识别只需要文本行级别的标注，字段抽取就得标到键值对。我见过有人用整页标注的测试集去评估字段级准确率，纯属自欺欺人。测试集构建这一步偷懒，后面所有对比数字都站不住。
1.2 准确率核心评测指标：字符准确率、词准确率、编辑距离、字段级准确率与端到端全对率
聊指标这件事，我经常跟同行吵。字符准确率是大家最爱报的，算起来简单，预测字符和标注字符逐位比对。可它对长文本特别宽容，一篇一千字的文档错十几个字，字符准确率还能有98%以上，实际阅读体验已经很难受了。词准确率稍微好一点，按词切分后整词匹配，中文得分词，分词本身又引入误差，挺别扭的。
编辑距离我更愿意看，它直接反映要把识别结果改成正确结果得动多少刀。我会同时报归一化编辑距离和绝对编辑距离，前者衡量整体质量，后者告诉我人工校对的工作量。字段级准确率是票据和表单场景的生命线，一个字段里错一个字，整个字段就算错，标准严得多，也更贴近业务验收。
端到端全对率是我最看重的一个指标，整张图的所有文本一个字符都不能错才算通过。这个数字通常很难看，我测过几个主流开源模型在复杂版面上全对率只有三四成。有人觉得太苛刻，我的看法是，业务方最终关心的是这张图能不能直接入库，全对率就是最诚实的答案。
1.3 检测与识别联合评测：文本检测召回率、识别置信度、版面分析效果与阅读顺序还原
只评测识别结果，很多问题会被掩盖。我有一次发现某个模型识别出来的文字质量挺高，可整页内容少了一大块，查下去是文本检测阶段漏掉了低对比度的区域。检测召回率这个指标必须单独拎出来看，尤其是小字号、浅色字体、密集排版的场景，漏检比错识更致命，错识还能靠后处理纠，漏检是直接丢信息。
识别置信度也值得单独分析。我会看置信度分布，再看高置信度样本里的错误率。有些模型特别自信，错得离谱还给0.99的置信度，这种模型在业务里很危险，因为你没法用置信度阈值去筛人工复核的样本。好的模型应该做到置信度和实际正确率大致对齐，这样业务侧才能放心地只把低置信度结果丢给人工。
版面分析和阅读顺序还原是中文场景的老大难。多栏排版、表格嵌套、图文混排，识别出来的文本块顺序乱了，下游拿到的就是一堆碎片。我会拿一篇双栏学术论文和一份带合并单元格的报表去测，看模型能不能正确还原阅读顺序。这个环节目前很多模型做得不够好，尤其是纯识别模型，根本不管顺序，得靠版面分析模块来补。
1.4 鲁棒性与效率指标：光照倾斜、模糊遮挡、多语言混排、推理时延、吞吐量与资源占用
准确率好看不代表能落地。我习惯做一组扰动测试，把同一批干净图片做旋转、加噪、调暗、局部遮挡，看准确率掉多少。有的模型在干净数据上跟另一个模型打平，一加扰动就原形毕露，掉二三十个点。光照不均和透视倾斜是移动端拍照场景的常态，这组测试基本能预判模型在真实环境里的表现。
多语言混排也得测。中文文档里夹英文术语、夹数字、夹日文假名的情况太常见了，字典覆盖不全的模型遇到这些字符会直接输出乱码或者跳过。我测过一个模型，纯中文识别挺稳，一遇到中英混排的合同就大量丢字，原因是它的字符集压根没包含某些符号。
效率指标我一般测三个维度：单张图片的推理时延、批处理吞吐量、CPU和GPU下的内存显存占用。时延要区分预处理、检测、识别三段分别耗时，不然优化的时候找不到瓶颈。吞吐量我会用固定并发压测，看QPS随并发数的变化曲线。资源占用这块，边缘设备部署特别敏感，一个模型显存吃8G，很多场景直接就出局了，准确率再高也没用。
1.5 评测可复现性设计：标注规范、错误归因、置信区间与基准测试报告结构
评测结果如果别人复现不出来，说服力就大打折扣。我现在的做法是把标注规范写成文档，明确什么算一个文本行、标点符号怎么处理、空格保不保留、特殊符号怎么转义。这些细节不定死，不同人标出来的测试集就有偏差，模型对比的数字根本没法比。
错误归因我通常按几类拆：检测漏检、检测误检、字符替换、字符插入、字符删除、阅读顺序错误、后处理引入的错误。每一类单独统计占比，这样模型之间的差异能看得更清楚。有的模型整体准确率稍低，但错误集中在一两个可修复的类别，工程上补一补就能追上来，这种信息比一个总分有用得多。
置信区间这事被很多人忽略。测试集只有几百张图的时候，准确率差一两个点可能完全是采样波动。我会对关键指标算95%置信区间，两个模型区间重叠得厉害，我就不轻易下谁更强的结论。基准测试报告我固定包含这几块：测试环境、模型版本、测试集构成、各场景分项指标、错误类型分布、时延与资源数据、已知局限。结构固定下来，几次评测之间才能纵向比较，团队里换个人来做也能接得上。
第2章 开源OCR模型中文识别能力横向对比
2.1 主流开源OCR模型谱系与定位
我把现在能用的开源OCR按出身分成几支。飞桨系的PaddleOCR是绕不开的一支，PP-OCRv4、v5迭代下来，检测用DBNet，识别用SVTR-LCNet结构，中文训练数据喂得很足，配套还有PP-Structure做版面分析和表格还原。它的定位很清楚，就是奔着中文文档全流程去的，工程化程度高，模型也分服务端版和移动端版。我在好几个生产项目里用它打底，稳。
Tesseract是另一个极端，三十来年历史的老兵，4.x之后换成LSTM识别器，5.x继续维护。它的chi_sim中文包在规整的印刷扫描件上还能打，字距均匀、版面干净的时候正确率挺体面。碰上手写、竖排、表格嵌套，它的表现就明显掉档。这东西配置项多到让人头大，页面分割模式、字典、白名单黑名单，调它更像在调一门老式相机。
EasyOCR走的是开箱即用路线，PyTorch实现，CRAFT做检测加CRNN识别，八十多种语言一把梭，pip装完三行代码就能跑出结果。中文简繁都覆盖，适合快速验证和原型。速度不算快，模型偏大，中文精度属于中上水平。MMOCR是OpenMMLab那边的模块化工具箱，检测识别算法塞得最全，DBNet++、PSENet、CRNN、SAR、ABINet、MAERec都有，做研究和算法对比很舒服，环境依赖偏重，mmcv、mmengine版本对齐能折腾掉半天。
RapidOCR是个挺聪明的路子，把PaddleOCR的模型转成ONNX，用自研推理引擎跑，不依赖飞桨框架，体积小、跨平台，Windows上打个exe就能用。精度基本贴着PP-OCR走，CPU上经常还更快。TrOCR是微软的Transformer方案，编码器解码器端到端，主打行级和词级识别，英文手写效果出圈，中文得用中文微调过的权重，长行和密集版面是它的软肋。
还有一批值得提的：CnOCR中文专用、轻量；Umi-OCR是桌面工具，底下整合了Paddle和Rapid；Surya、GOT-OCR2.0、MinerU、dots.ocr这些新面孔在整页解析上各有想法；Qwen2.5-VL这类多模态大模型也能直接读图出Markdown。谱系摆开看，选型的第一步根本不是比谁分数高，是看它站在哪个位置上。
2.2 中文识别表现对比：印刷体、手写体、竖排文本、繁简混排、表格票据与长文本场景
我拿同一批测试集跑过一轮，印刷体这块PaddleOCR和RapidOCR基本并列，规整文档上字符准确率都在97%以上，个别干净样本能到99。EasyOCR落后两三个点，错的地方集中在标点和形近字。MMOCR用DBNet++配SVTR能追得很近，换成CRNN识别器就掉一档。Tesseract在字体标准、无倾斜的扫描件上能给到95左右，扫歪一点、字距一乱，直接掉到80出头。
手写体是分水岭。TrOCR在手写行上表现最好，工整书写能到90上下，潦草连笔也有70多。PaddleOCR原生手写权重一般，拿手写数据微调之后能追上来不少。EasyOCR手写大概60到70，MMOCR的MAERec在中文手写上表现不错。Tesseract手写基本没法用，我在一批手写登记表上测，它输出的大半是乱码，这个场景它不是选项。
竖排文本麻烦在阅读顺序和字符切分。PaddleOCR带方向分类器，竖排能识别，顺序也基本对，前提是版面不复杂。Tesseract用psm 5竖排模式能出字，顺序经常乱成一锅粥。EasyOCR竖排识别率尚可，长竖排容易断行。繁简混排考的是字典，我测过一份港台风格的合同，简繁夹杂还带几个异体字，字典覆盖全的模型丢字少，字典窄的模型直接跳过不认识的字符，输出看着通顺，实际少了半句话。
表格票据这块，单纯识别模型都吃力，得靠PP-Structure或者MMOCR的表格模块。表格线被识别成竖线字符、合并单元格文本串行、金额和税额错位，这些错误在票据场景特别常见。长文本上TrOCR吃亏明显，它按行处理，一行超过一定长度就截断或者精度骤降。整页文档识别，还是检测加识别的流水线更靠谱。
2.3 模型组合差异分析：文本检测+文本识别、端到端OCR、多模态大模型OCR方案
三种技术路线我都在项目里跑过，错误模式差别很大。检测加识别的两阶段方案，好处是错误能定位。整页识别错了，我能查是检测框没框住、框重复了，还是识别器把字认错了。检测器可以换DBNet、FCENet、CRAFT，识别器可以换CRNN、SVTR、ABINet，字典也能单独改，组合空间大，调优抓手多。坏处是链路长，检测的误差会顺着传到识别，检测漏一块，后面全白搭。
端到端方案省掉中间环节，TrOCR是行级端到端，GOT-OCR2.0这类是整页端到端，输入图片直接吐文本或者带格式的结果。链路短、部署简单，整页解析的排版还原往往比流水线自然。麻烦在归因，输出错了你很难说清是哪一步出的问题，调试像在黑箱上摸。整页端到端对小字、密集表格的召回也偏弱，漏行是常见毛病。
多模态大模型读图这条路，Qwen2.5-VL、InternVL这些拿提示词直接让模型输出结构化文本，遇到复杂版面、图表混排、需要理解语义的票据，效果确实亮眼，还能顺手做字段抽取和纠错。它的坑在幻觉和稳定性，我见过模型把不存在的金额补上、把行合并、把表格结构编出来，输出读着特别顺，一对原图就发现是编的。推理成本也高，一张A4页面在消费级显卡上要好几秒，批量场景不划算。
我的实际做法是分层组合。整页文档走检测识别流水线保底，表格票据用版面分析加字段后处理，手写和疑难页面单独路由给TrOCR或者大模型兜底。把不同方案当零件拼，比死磕一个全能模型现实得多。
2.4 开源生态与可维护性：许可证限制、社区活跃度、模型更新频率、预训练资源与二次训练难度
许可证我先看，商用项目踩过坑的都懂。PaddleOCR、EasyOCR、MMOCR、RapidOCR、Tesseract都是Apache-2.0，商用友好。TrOCR在unilm仓库下是MIT，也算宽松。真正要留心的是模型权重的训练数据来源，有些权重是拿公开数据集混着爬来的数据训的，许可证链条不一定干净，法务那边会问。这一点在选型早期就该确认，别做到上线才发现要换模型。
社区活跃度差别挺大。PaddleOCR的star数和issue响应速度在国内项目里算头部，版本迭代节奏快，文档中文齐全，遇到问题搜得到答案。MMOCR背靠OpenMMLab，更新也勤，代价是版本耦合紧，升级一次得连着mmcv一起动。EasyOCR更新偏慢，胜在接口稳定，几年下来API基本没变。Tesseract是老牌开源，核心维护还行，中文训练数据的更新靠社区贡献，节奏不好把握。RapidOCR追PP-OCR版本追得挺紧，新模型出来没多久就有ONNX版。
二次训练难度我按上手成本排过序。PaddleOCR给的是全套配置文件加训练脚本，改字典、换数据、调学习率都有现成路径，微调一版识别模型一两天能跑通。MMOCR配置体系灵活，学习曲线陡，熟手效率高，新手容易卡在环境上。TrOCR走HuggingFace那套，微调脚本标准，对熟悉transformers的人最省事。EasyOCR有训练代码但文档偏薄，得读源码。Tesseract最折腾，要准备box文件、跑makebox、训练工具链老旧，我一般不建议为中文场景去训它。
预训练资源这块，PaddleOCR放出的模型最全，检测、识别、方向分类、版面、表格、文档矫正一条龙。MMOCR模型库覆盖广，权重质量参差。EasyOCR打包在pip里，下载即用。选型时我把这块看得很重，省下来的不只是训练时间，还有后面每次迭代的边际成本。
2.5 中文场景适配能力：字典覆盖、分词与后处理、领域微调、小样本迁移与错误模式分析
字典覆盖是最容易被低估的一项。PP-OCR默认字典六千多字，另有繁体、日文、韩文等版本，覆盖常用汉字没问题。生僻字、异体字、人名地名里的怪字、粤语用字，默认字典就抓瞎，模型遇到不认识的字符会直接丢弃，输出看着连贯，实际悄悄少了字。Tesseract的chi_sim字典覆盖也不错，可它对未登录字符的处理更粗暴。我的做法是先拿业务语料统计字符集，跟模型字典做差集，差集大的话直接换字典重训识别头，这一步不做，后面怎么调后处理都补不回来。
中文没有词边界，识别出来的空格、全半角、标点形态全靠后处理。我一般会做几层清洗：全角半角归一、中英文标点映射、连续空格压缩、数字和字母的形近字纠正。领域字段再加规则校验，发票代码位数、身份证校验位、金额格式、日期合法性，这类规则能把字段级准确率拉上去好几个点。加一层领域词典做编辑距离纠错也管用，特别是公司名、商品名这类专有名词。
领域微调的门槛比想象中低。我通常合成一批数据打底，用字体渲染加背景、噪声、透视变换生成几万张，再混几百到几千张真实标注做精调，冻结检测只训识别，一两轮就能见效。小样本迁移在PaddleOCR和TrOCR上都试过，几百张样本就能把特定字体的错误率压下去一半。要注意的是别把模型训飘了，通用场景的准确率会跟着掉，我习惯留一份通用验证集盯着。
错误模式分析这块，我积累了一份自己的清单。形近字是头号问题，0和O、1和l、己已巳、未末、日和曰，中文OCR的老毛病。标点符号错得也凶，逗号句号引号经常互换。表格线、印章、下划线被当成字符识别进去，在票据上是高频错误。竖排和分栏的阅读顺序错乱，输出文本读起来像打乱的拼图。把这些错误分类统计，能看出一个模型是检测弱还是识别弱，是字典窄还是后处理缺，比看一个总分有用得多。有的模型总分低三分，可错误全集中在标点上，我加个正则就能救回来，这种模型照样能用。
第3章 图片文字识别模型的部署成本与工程可行性对比
3.1 部署形态与资源成本：本地CPU/GPU、边缘设备、容器化服务、云端API与混合部署
图片文字识别模型落到工程里，第一笔账不是模型精度，是它住在哪儿。我做过本地CPU跑、GPU服务、边缘盒子、容器集群、云端API，每种形态的成本结构完全不一样。本地CPU最省钱也最省心，一台普通服务器装个RapidOCR或者PaddleOCR的轻量模型，一天处理几万页文档没问题。代价是延迟不稳定，碰上复杂版面或者批量任务排队，CPU占用拉满，接口响应能飙到几秒。GPU服务是另一套账，一张T4或者A10跑PP-OCRv4服务端模型，吞吐能翻好几倍，显存占用大概两三个G，机器成本跟着上来。项目量小的时候，GPU卡的钱够买好几年的云端API调用量。
边缘设备这块我踩过坑。工业质检、门店票据、移动端OCR这些场景，模型得塞进算力有限的盒子或者手机里。PaddleOCR的移动端模型、RapidOCR的ONNX版本在这类场景更合适，模型体积压到几兆到几十兆，CPU推理几十毫秒一行。精度会掉一点，小字和模糊图像召回明显弱于服务端模型。我一般把边缘端当第一道过滤，识别置信度低的页面回传到云端做二次识别，混合部署能兼顾成本和效果。
容器化服务是我现在最常用的形态。模型打成镜像，挂上GPU或者纯CPU节点，K8s做弹性伸缩，流量低的时候缩到一两个副本，高峰期拉起来。好处是版本管理清楚，坏处是镜像体积和依赖。飞桨的镜像动辄几个G，拉取慢，节点磁盘压力大。ONNX Runtime或者OpenVINO的镜像能压到几百兆，启动快，扩容也利索。云端API适合快速验证和波峰流量，调用费按页或者按次算，量大之后账单很难看。我习惯把稳定流量放自建服务，突发流量走API兜底，账单和稳定性都能控住。
3.2 开源OCR模型部署成本拆解：模型体积、内存/显存占用、推理框架依赖、安装复杂度与运维负担
开源模型免费指的是授权免费，部署成本一分不少。我拿PaddleOCR服务端模型举例，检测模型加识别模型加方向分类器，权重加起来几十兆到一百多兆，看着不大。跑起来内存占用可不小，Python进程加飞桨框架，空载就吃几百兆到一G多，推理时峰值能到两三个G。GPU上显存占用相对克制，T4跑单实例大概两G出头，并发一上来显存和吞吐得一起算。MMOCR的模型库更重，mmcv、mmengine、各种算子依赖，环境装一遍能花掉半天，镜像体积轻松超过五个G。
推理框架依赖是隐形成本。PaddleOCR绑飞桨，版本和CUDA对齐要小心，驱动、cudnn、paddlepaddle-gpu版本错一个就报错。Tesseract依赖少，leptonica加训练数据，装起来轻，可它的中文识别精度撑不起复杂场景。RapidOCR在这块做得聪明，模型转ONNX，推理用onnxruntime，不依赖训练框架，Windows、Linux、ARM都能跑，安装复杂度低一大截。EasyOCR依赖PyTorch，装完一两个G，模型首次运行还要下载权重，离线环境得提前打包。
运维负担比安装更磨人。模型服务不是装完就完事，日志、监控、健康检查、版本回滚、模型热更新，每一样都要人管。我见过团队用Flask包了个PaddleOCR接口就上线，跑了半年，内存泄漏、模型加载超时、并发打架，问题一个一个冒出来。后来换成Triton或者ONNX Runtime Serving，批处理、并发、模型版本管理都有现成方案，运维压力小很多。开源模型省的是授权费，花的是人力和时间，这笔账得提前算清楚。
3.3 商业OCR与开源自部署TCO对比：调用费用、人力运维、带宽存储、扩容弹性与合规要求
商业OCR的报价我拿过几家的，通用文字识别按次计费，量大能谈到几分钱一页，票据、表格这类结构化识别贵一些，几毛到一块一页都有。月调用十万页以内，商业API的总成本往往低于自建，省了机器、省了人、省了折腾。调用量上到百万页级别，账单开始咬人，自建的成本优势慢慢显出来。这个拐点在哪，跟团队人力成本、机器价格、模型复杂度都有关系，我一般按十二个月做一张TCO表，把调用费、服务器、存储、带宽、运维人力全塞进去算。
开源自部署的TCO里，人力是大头。一个稳定的OCR服务，至少需要一个人负责模型部署、接口开发、监控告警、错误排查，半年之后还得有人跟进模型升级和效果优化。这部分成本在商业API里是隐形的，在自建里是实打实的工资。带宽和存储也别忽略，图片上传、结果回传、原图和识别结果留存，票据场景一页图片几百K到几兆，百万页就是几百G到几个T的存储。合规要求高的行业，数据不出内网，商业API直接用不了，私有化部署或者开源自建成了必选项，这时候比的不是价格，是能不能落地。
扩容弹性是商业API的强项。双十一、月末结算、报税季，流量突然翻几倍，API调多少付多少，不用提前备机器。自建服务扩容要提前规划，GPU机器采购周期长，容器扩容受限于集群资源，流量洪峰来了只能排队或者降级。我的做法是核心业务自建保底，波峰流量走商业API，混合架构把成本和弹性都照顾到。合规这块单独拎出来说，金融、医疗、政务的图片文字识别，数据出境和第三方处理的限制很硬，开源自部署或者私有化商业方案才有讨论空间。
3.4 性能与成本权衡策略：模型量化、剪枝蒸馏、批处理、缓存机制、异步任务与弹性伸缩
模型量化是我最先动的刀。FP32转FP16，显存占用和推理时延都能降一截，精度掉得很少，多数中文印刷体场景感知不到。再往INT8走，需要校准数据，精度损失开始显现，小字和低质图像上更明显。我一般拿业务测试集跑一遍量化前后对比，字符准确率掉两个点以内能接受，掉五个点以上就得重新考虑。PaddleOCR和ONNX Runtime都支持量化流程，RapidOCR直接提供量化模型，省了不少事。
剪枝和蒸馏适合对体积敏感的场景。移动端或者边缘设备上，把大模型的能力蒸馏到小模型，体积能压到几分之一，速度翻倍，精度损失控制在可接受范围。我试过用PP-OCR服务端模型蒸馏移动端模型，特定字体和票据场景上效果还行，通用场景掉得多一些。剪枝更粗暴，识别头的通道砍掉一部分，模型小了，泛化能力也跟着弱。这类操作我建议放在有明确业务边界的场景里做，别指望一个剪枝模型通吃所有文档。
批处理和缓存是性价比最高的优化。单张推理GPU利用率低，攒批之后吞吐能翻几倍，延迟换吞吐，离线任务特别划算。缓存机制看业务，模板固定的票据、格式一致的报表，相同版面的识别结果可以缓存字段位置和版面结构，下次只跑识别不跑检测，省一半算力。异步任务适合大批量文档数字化，前端上传完就返回任务ID，后台排队处理，用户体验和机器利用率都能兼顾。弹性伸缩放在容器层做，按队列长度或者CPU利用率触发扩容，闲时缩容，云上能省不少钱。
3.5 工程可行性评估：稳定性、可观测性、版本管理、故障降级与私有化交付能力
稳定性是工程可行性的底线。图片文字识别服务最怕内存泄漏和模型加载卡死，跑几天之后响应越来越慢，重启才能恢复。我现在习惯给服务加内存上限和定期重启策略，模型加载做成懒加载加健康检查，启动探针和存活探针分开配。并发高的时候限制单实例并发数，超出的请求排队或者拒绝，别让服务被压垮。这些手段不高级，管用。
可观测性决定了出问题之后能不能快速定位。我一般会记录每张图片的检测框数量、识别置信度分布、推理耗时、模型版本，按小时聚合。置信度突然整体下掉，可能是图片质量变了或者模型加载错了版本。某类版面错误率飙升，能顺着日志把样本捞出来做错误归因。没有这些指标，线上效果变差只能靠用户投诉发现，太被动。
版本管理和故障降级是私有化交付的必答题。模型版本、字典版本、后处理规则版本要能独立回滚，新模型上线先灰度一小部分流量，指标稳住再全量。故障降级路径得提前设计，主模型服务挂了切备用模型，GPU不可用切CPU轻量模型，识别服务整体不可用的时候走人工复核队列。私有化交付还要考虑离线安装、许可证校验、模型加密、客户环境差异，这些工程细节在PoC阶段不显眼，真到交付的时候能卡住项目。我的经验是选型阶段就把部署和运维方案拉进来一起评估，别等模型测完才发现装不上、跑不稳、维护不了。
第4章 面向业务场景的模型选型建议与对比结论
4.1 场景化选型矩阵：文档数字化、票据识别、工业质检、移动端OCR、隐私敏感与离线场景
做了这么多次对比评测，我越来越觉得模型选型没有唯一答案，只有场景答案。同一个PaddleOCR服务端模型，放在文档数字化项目里是首选，放到手机端就完全跑不动。我在几个项目里反复验证过一件事，先想清楚图片从哪来、结果给谁用、跑在什么机器上，再去翻模型榜单，效率高很多。
文档数字化场景，印刷体为主，版面复杂，表格和段落混排。这类需求我一般直接上PaddleOCR服务端模型或者MMOCR的检测识别组合，检测强、字典全、长文本表现稳。票据识别是另一个路数，字段级准确率比整页字符准确率重要得多，版面模板相对固定，适合做检测加字段后处理，甚至拿关键区域单独训识别模型。工业质检的图片文字往往是喷码、铭牌、包装批号，字体特殊、背景干扰大，通用模型的零样本效果一般，得准备几百张样本做微调，TrOCR这类基于Transformer的方案在小样本微调上有它的优势。
移动端OCR是我踩坑最多的场景。模型体积、内存占用、推理速度都得卡着指标走，PaddleOCR移动端模型和RapidOCR的量化版本是我常用的两个选择。精度上别抱太高期待，清晰印刷体够用，手写和低质图像就得靠端云协同兜底。隐私敏感和离线场景最容易做决定，数据不能出内网，商业API直接出局，开源自部署或者私有化商业方案二选一，剩下比的就是谁的部署更省心、谁的字典更全。
我习惯把这张矩阵画出来贴在项目墙上。横轴是场景，纵轴是模型候选，格子里填准确率、体积、部署方式、许可证四个信息。团队讨论选型的时候对着表吵，比对着论文吵有用得多。
4.2 准确率与部署成本联合决策：高精度优先、低成本优先、可私有化优先与实时性优先
模型选型最怕单维度决策。只看准确率，选出来一个跑不动的巨无霸。只看成本，上线三天被业务方追着骂识别错。我总结下来就四种决策倾向，项目一开始就得定好优先级，不然评测做完还在原地打转。
高精度优先的场景通常是后端批处理，比如合同归档、档案数字化、财务报表录入。这类业务对时延不敏感，错一个字要人工返工，成本比机器贵。我的做法是服务端大模型加批处理加人工抽检，GPU跑满，准确率往死里堆。低成本优先的场景反过来，日志截图、聊天记录、内部通知的识别，错几个字没人较真，用轻量模型甚至移动端模型就够了，CPU集群跑，单页成本压到最低。
可私有化优先的客户我遇到不少，金融、政务、医院。他们第一句话不是问准确率多少，是问能不能装在自己机房。这种项目商业API还没开始比就结束了，剩下开源自部署和私有化商业方案两条路，比的其实是交付能力和运维成本。实时性优先的场景集中在移动端和交互式产品，用户拍完照等结果，超过两秒体验就崩。这类场景模型必须小、推理必须快，精度靠端云协同和置信度兜底来找补。
这四种倾向经常打架。业务方既要高精度又要低延迟还要便宜，我只能拉他们一起做取舍。拿测试集跑三条曲线，准确率对时延、准确率对单页成本，摆在他们面前选。选型决策本质上是业务决策，技术只是把选项和代价算清楚。
4.3 评测指标到业务指标的映射：人工复核率、字段准确率、处理时效、单页成本与用户体验
技术指标和业务指标之间隔着一层翻译。字符准确率99%听起来漂亮，业务方关心的是这一万张票据里有多少张需要人工改。我做过一个票据项目，字符准确率97%，看着还行，字段级准确率只有82%，因为金额和日期错一位就整单退回，人工复核率飙到三成，项目差点黄掉。从那以后我评测报告第一页不放字符准确率，放人工复核率和字段准确率。
人工复核率的算法得跟业务对齐。整页全对才算通过，还是关键字段全对就算通过，两种口径差很多。我一般先跟业务方定字段优先级，金额、日期、编号这类关键字段单独统计，地址、备注这类次要字段放宽。处理时效也是业务敏感指标，单页平均耗时、P95耗时、批量任务完成时间，三个数都得报。用户不会看平均值，他们感受的是最慢的那一次。
单页成本要把所有东西摊进去算。机器折旧、电费、人力运维、存储带宽、人工复核工时，除出来一个数。这个数和商业API的报价放一起比，决策就有依据了。用户体验这块偏定性，我通常用两个代理指标，首字返回时间和识别结果可直接复制率。移动端产品尤其看首字返回，用户等的是第一个字出来，不是整页识别完。
我现在的评测报告结构是固定的。第一页业务指标汇总，第二页分场景准确率，第三页成本和时延，第四页错误样本归因。技术同学看后面，业务同学看前面，各取所需。
4.4 模型对比结论与落地路线：PoC设计、基准测试、灰度上线、错误回流与持续优化机制
说结论。通用中文印刷体文档，PaddleOCR服务端模型综合表现最均衡，精度、生态、部署方案都成熟。追求轻量部署和跨平台，RapidOCR是性价比之选，ONNX路线省心。特殊字体和小样本场景，TrOCR微调值得一试。Tesseract适合做基线对照和极简环境兜底，复杂中文场景别指望它。多模态大模型OCR在复杂版面和手写场景有惊喜，成本和时延还得再等等。
落地路线我走过很多遍，基本是四步。PoC阶段别贪多，挑两三个候选模型，拿真实业务样本两百到五百张跑一遍，重点看错误样本长什么样，错误模式比准确率数字更有信息量。基准测试阶段扩大样本，把时延、资源占用、部署复杂度一起测，出一份可复现的报告。
灰度上线是必须的。新模型先接百分之五到十的流量，盯人工复核率和置信度分布，指标稳住再逐步放量。错误回流机制提前设计好，人工复核修改过的样本自动沉淀成增量训练集和回归测试集。我见过团队做完PoC就全量切换，出了错连回滚方案都没有，教训很贵。
持续优化这件事没有终点。业务图片会漂移，扫描设备会换，票据模板会改版，模型效果三个月不跟进就开始下滑。我一般按季度做一次效果复盘，看错误分布有没有变化，该微调微调，该换模型换模型。选型是起点，不是终点。
