我经常被朋友问，OCR模型排行到底有啥用。说实话，我一开始也觉得排行榜就是图个热闹。后来自己做项目踩了坑，才明白排行能帮我们快速缩小选择范围。一个靠谱的排行会盯着几个核心问题：文字识别准不准、速度够不够快、模型占多大、部署花多少钱。这几个问题里，准确率永远是第一位的。可准确率又分很多种，印刷体准了，手写体可能一塌糊涂。所以排行不能只看一个数字。
另一个核心问题是场景适配。我见过一个榜单把某模型排到第一，结果拿去识别发票，错得离谱。那个模型在通用文本上确实强，但表格和版面理解很差。排行关注的核心问题还包括鲁棒性：模糊、旋转、光照不均、遮挡。这些真实世界里的麻烦，实验室数据集不一定覆盖。我作为开发者，看排行时会先问：这个榜评测的数据集跟我业务像不像。不像的话，排名再高我也得打个问号。
从企业用户角度，排行还关系到成本。一个模型准确率只高0.5%，但推理速度慢三倍，显存占用多两倍。这种排行第一，放到生产环境可能完全不划算。研究者看排行则更关注技术边界，比如多模态大模型在OCR任务上到底比传统模型强多少。不同角色读同一个排行，得到的结论可能完全不同。这就是为什么读懂排行，比记住排名更重要。
开源OCR模型和商业OCR模型的排行，差异特别大。我对比过好几个榜单，开源排行通常基于公开数据集，比如ICDAR、CTW这些。评测代码和模型权重都公开，谁都能复现。商业OCR模型不公开权重，排行往往来自厂商自己或者第三方有限测试。这种排行可信度参差不齐。开源排行里，PaddleOCR、EasyOCR、Tesseract经常被拿来比。商业排行里，百度、腾讯、阿里、Google的API各占一片天。
开源排行的好处是透明。我能看到模型在哪些数据上训练，评测脚本怎么写的。坏处是很多开源模型对中文支持一般，尤其是手写和竖排。商业排行呢，厂商会宣传自己在特定场景的准确率，比如身份证、银行卡。可这些数据你没法独立验证。我做过一个实验，同一张模糊发票，某商业API号称99%准确率，实际跑出来只有82%。开源模型里RapidOCR反而到了88%。商业模型在稳定性和服务支持上有优势，但排行数字要谨慎看待。
还有授权和成本差异。开源模型免费，但有些协议限制商用。商业模型按调用次数收费，量大以后成本很高。排行如果只比准确率，不比这些工程指标，对选型帮助有限。我习惯把开源和商业排行分开看。开源排行用来找技术基线，商业排行用来评估服务上限。两者混在一起比，容易误导人。比如一个商业模型排第一，你可能忽略了它每万次调用要花几百块。
中文识别场景下，排行的独特性太明显了。英文OCR字符集小，大小写加符号不到100个。中文常用字就3500个，加上生僻字、繁体、异体字，轻松过万。字符集大，模型容易混淆形近字。比如“未”和“末”，“日”和“曰”。通用OCR排行如果只用英文数据集，对中文参考价值很低。我见过一个模型在英文榜上排前三，中文识别率不到70%。这种排行在中文场景下就是废的。
中文还有竖排、手写、古籍、表格、印章这些特殊版式。竖排文本的阅读顺序和横排完全不同。手写中文的连笔、草书，连人都可能认错。表格识别要求模型理解行列结构，不只是识别文字。印章文字往往重叠、变形、颜色干扰。这些任务在通用排行里很少单独列出来。我评测过几个模型，通用文本准确率95%，一换到手写票据就掉到60%。所以中文OCR排行必须分场景看。简体、繁体、手写、竖排、表格，每个维度都要单独排名。
中文OCR的评测数据集也有特殊性。CTW、ReCTS、OCRBench这些榜单里，中文占比和难度设计不一样。有些数据集偏新闻文档，有些偏街景，有些偏手写。我在选模型时，会先找跟业务最接近的中文子榜单。比如做古籍数字化，就看竖排和繁体专项排行。做财务报销，就看票据和表格排行。没有一个中文排行能覆盖所有场景。读懂中文排行的第一课，就是承认“通用第一”在中文里几乎不存在。
这篇文章我打算用总分式结构来聊。总的部分就是现在这一章，讲清楚排行为什么重要、怎么读、开源和商业有啥区别、中文场景特殊在哪。分的部分我会先讲评测指标和数据来源。没有指标定义，排行就是数字游戏。我会把准确率、召回率、F1、编辑距离、字符准确率这些概念掰开说。中文专项指标像简体、繁体、手写、竖排、表格、版面理解，也会单独讲。工程落地指标比如推理速度、模型体积、显存占用、部署成本，同样不能少。
再往后我会给出开源OCR模型的中文准确率排行和主流模型解析。PaddleOCR系列、EasyOCR、Tesseract、MMOCR、RapidOCR、docTR，还有多模态大模型OCR像GOT-OCR、Qwen-VL、InternVL、MiniCPM-V。我会按通用文本、票据、证件、表格、手写体这些任务分别排。最后一部分是选型建议和趋势展望。我会分享自己的选型四步法，按高精度、高速度、轻量端侧、私有化、垂直场景来分类推荐。排行之外的坑，比如授权协议、维护活跃度、二次开发成本，我也会提醒。我的目标很简单：让排行帮你做初步筛选，但最终决策一定要靠你自己的业务数据实测。排行是地图，不是终点。
2.1 通用评测指标：准确率、召回率、F1、编辑距离与字符准确率
我刚开始看OCR排行榜时，经常被准确率、召回率、F1这几个词绕晕。准确率说的是模型认出来的字里有多少是对的，召回率说的是真实存在的字里有多少被认出来了。我举个自己的例子，一张图上有100个字，模型只认出了80个，其中75个正确。准确率就是75除以80，等于93.75%。召回率是75除以100，等于75%。一个模型可能只认出几个字，但全对，准确率100%，召回率却极低。F1把这两个数调和平均，避免只看一个指标走偏。
编辑距离和字符准确率是我更常用的两个指标。编辑距离指把识别结果变成真值，最少需要增删改多少个字符。比如真值是“你好世界”，识别成“你好世”，编辑距离就是1。字符准确率就是正确字符数除以真值总字符数。我做过一个发票识别实验，某模型字符准确率96%，但编辑距离算出来只有85%。原因是错了一个关键数字，整串金额就废了。这两个指标有时排名打架，得看业务能不能容忍单个错误。
从企业用户视角，指标要跟业务损失挂钩。识别错一个“0”和错一个“的”，后果完全不同。开发者更关注F1和编辑距离的平衡，研究者可能盯着字符准确率的小数点后两位。我自己选模型时，会先看字符准确率，再看编辑距离，最后用业务样本验证。指标只是筛子，不能替代真实场景的容忍度测试。
2.2 中文OCR专项指标：简体、繁体、手写、竖排、表格与版面理解
简体中文和繁体中文在OCR里几乎是两个任务。我测过同一个模型，简体新闻文本准确率98%，换成繁体古籍直接掉到71%。繁体字形复杂，异体字多，很多开源模型训练集里繁体占比极低。手写中文更让人头疼。连笔、草书、个人书写习惯，连人眼都可能认错。我做过一个手写地址识别，三个模型里最好的只有82%字符准确率，最差的不到60%。手写专项评测数据集很少，导致排行榜上这个维度经常缺失。
竖排文本的阅读顺序跟横排完全相反。模型不仅要认字，还要判断是从右往左还是从左往右。我见过一个模型把竖排古诗识别成乱序，每个字都对，连起来完全不通。表格识别要求理解行列结构，不是单纯输出文字。版面理解包括标题、段落、图片位置、阅读顺序。这些任务在通用排行榜里通常被平均掉，导致一个模型总分很高，实际做表格一塌糊涂。表格评测常用TEDS指标，版面理解常用mAP，跟字符准确率完全不是一回事。
我作为开发者，做财务报销系统时只看票据和表格专项排行。做古籍数字化时只看竖排和繁体排行。做证件识别时只看证件专项。没有一个中文排行榜能覆盖所有场景。我建议你列出业务里最常见的三种版式，然后去找对应的中文子榜单。找不到就自己标一个小测试集，哪怕只有一百张图，也比通用排行有参考价值。
2.3 工程落地指标：推理速度、模型体积、显存占用与部署成本
推理速度通常用FPS或者每张图耗时来衡量。我踩过一个坑：某模型在GPU上跑得飞快，换到CPU上慢得像蜗牛。排行榜如果不标注硬件环境，速度数字参考意义有限。模型体积决定能不能塞进手机或者边缘设备。我做过一个端侧OCR项目，模型超过50MB就很难接受，最后选了只有8MB的轻量模型，准确率降了3个百分点，但用户能接受。显存占用决定并发能力。一个模型显存要8GB，另一个只要2GB，在云服务器上成本差好几倍。
部署成本包括硬件采购、电费、云服务调用费、运维人力。商业OCR API按调用次数收费，量大了很吓人。我算过一笔账：某商业API每万次调用30元，一天100万次就是3000元。换成开源模型自己部署，GPU服务器一天成本可能只要几百元，但需要专人维护。开源模型版本更新快，有时候升级后旧接口不兼容，二次开发成本不低。商业模型有SLA保障，出问题能找客服。这些工程指标在纯准确率排行榜里经常被忽略。
从企业决策者角度，稳定性和维护成本有时比准确率更重要。一个模型准确率高0.5%，但需要双倍GPU，还经常崩溃，生产环境根本不能用。我习惯把工程指标做成加权表：准确率占40%，速度占20%，体积占15%，显存占15%，部署成本占10%。权重根据业务调整。实时视频OCR速度权重更高，离线文档处理准确率权重更高。排行榜如果不提供这些细项，我就自己补测。
2.4 常见评测数据集与榜单：ICDAR、CTW、ReCTS、OCRBench等
ICDAR是OCR领域的老牌竞赛，历史久，英文数据集偏多。CTW是中文街景文本数据集，图片来自真实街道，有大量繁体、倾斜、遮挡。ReCTS也是中文场景文本，包含招牌、菜单、路牌，背景复杂。OCRBench偏向多模态大模型的综合评测，里面包含手写、表格、数学公式、图表理解。我平时看Papers with Code的OCR排行，它会汇总各个数据集的结果。Hugging Face上也有模型卡附带评测分数。ICDAR竞赛的榜单权威性高，但提交次数有限，很多模型没法持续更新。
CTW和ReCTS有官方测试集，但测试集不公开，需要提交预测结果给官方评分。这种榜单不容易作弊，可信度较高。OCRBench是近期比较火的榜单，专门评测视觉语言模型的OCR能力。我注意到OCRBench上很多多模态大模型排名靠前，但传统OCR模型很少参与。原因是评测方式不同，多模态模型需要理解整张图，传统模型只做文字检测和识别。不同榜单的排名不能直接横向比较。我见过一个模型在CTW上排第一，在OCRBench上连前二十都进不去。
数据集偏差是个大问题。CTW主要是街景，对文档识别参考价值有限。ReCTS偏招牌，对票据识别帮助不大。ICDAR英文数据集对中文场景几乎没用。我选数据集时，会先看它的图片来源、标注规范、难度分布。如果业务是扫描文档，我就去找文档类数据集，比如SROIE、FUNSD。如果业务是手写笔记，我就去找手写数据集，比如IAM（英文）、CASIA-HWDB（中文）。排行榜上的数据集名字很响，但跟你的业务像不像，只有你自己知道。
2.5 排行可信度判断：数据污染、场景偏差与版本差异
数据污染是排行榜最大的坑。有些模型在训练时不小心见过测试集，导致排名虚高。我遇到过某模型在公开榜单上准确率99%，我自己拿业务数据测只有83%。检查方法很简单：看模型卡有没有说明训练数据来源。如果训练集和测试集有重叠，或者模型发布者就是榜单维护者，就要多留个心眼。有些榜单会定期更换测试集，或者采用盲测，这种可信度更高。我一般会找两三个独立榜单交叉验证，如果某个模型只在某一个榜单上表现突出，在其他榜单上平平，我就怀疑有污染。
场景偏差也很常见。排行榜数据集往往经过清洗，图片清晰、角度正、光照均匀。真实场景里的图片模糊、旋转、遮挡、反光。我做过一个实验，同一张发票，在排行榜测试集上模型准确率96%，用手机拍出来再识别只有78%。版本差异同样要命。模型v1和v2性能可能差很多，但排行榜上只写模型名字，不写版本号。我见过一个模型更新后准确率提升了5个百分点，但排行榜还是旧版本的分数。看排行时我会去查模型发布时间，尽量选近半年内更新的版本。
我判断排行可信度有一套自己的流程。先看评测代码是否开源，再看测试集是否公开，然后看是否多次运行取平均值。如果这三个都不满足，我就只把它当参考。研究者可以复现实验，企业用户最好自己标一个业务测试集，哪怕只有两百张图。排行榜是地图，不是终点。我见过太多人拿着排行榜第一的模型直接上线，结果被真实数据打脸。多花两天做实测，比省那点时间值得多。
3. 开源OCR模型中文识别准确率排行与主流模型解析
3.1 开源OCR模型中文准确率排行总览与梯队划分
我看中文OCR排行，会把它当成一张分层地图。榜首附近长期有 PaddleOCR 的 PP-OCRv5、PP-OCRv4，通用中文文本识别稳。多模态大模型 GOT-OCR2.0、Qwen2.5-VL、InternVL2.5、MiniCPM-V 2.6 在复杂版式、手写、表格问答上冲得很猛。传统开源 EasyOCR、Tesseract、MMOCR、RapidOCR、docTR 各自守着一块地盘。
我给它们分三档。头部档是通用中文高精度：PP-OCRv5、PP-OCRv4、GOT-OCR2.0、Qwen2.5-VL 大尺寸版本。中间档是够用且工程友好：RapidOCR、EasyOCR、MMOCR、docTR、MiniCPM-V 小尺寸。尾部档是特定场景或历史包袱：Tesseract 中文、部分老版 OCR。这个分档会随数据集变化，街景、票据、手写、竖排的排序经常换位。
开发者看梯队，会先看推理速度。企业用户看梯队，会先看部署成本。研究者看梯队，会先看榜单分数。我自己的习惯是拿业务样张跑一遍，梯队只用来缩小候选范围。排行榜上差 1 个百分点，真实场景可能差 10 个百分点。
3.2 PaddleOCR系列：PP-OCRv4与PP-OCRv5中文表现
PaddleOCR 是我做中文项目时绕不开的选项。PP-OCRv4 在通用简体中文上已经很强，检测和识别都有轻量版，CPU 也能跑。我拿它测过扫描合同、发票、快递单，字符准确率大多在 95% 以上。繁体、竖排、模糊文本上会掉，PP-OCRv5 在这些方向补了不少。PP-OCRv5 的识别模型对多语言、手写风格、复杂背景更稳，端到端速度也有优化。
我比较喜欢 PaddleOCR 的工程配套。它提供方向分类、版面分析、表格识别、PP-Structure，中文文档场景一条龙。模型体积从几 MB 到几十 MB 都有，端侧和服务器都能选。授权是 Apache 2.0，商用友好。社区活跃，文档中文，踩坑时容易搜到答案。缺点是多模态理解弱，遇到“这张图里金额是多少”这类问题，还是得自己写后处理。
从排行榜看，PP-OCRv5 在中文通用文本、证件、票据上常在前列。PP-OCRv4 仍然能打，很多旧项目还在用。我建议新项目直接上 v5，旧项目如果 v4 够用不必折腾。注意版本号：PP-OCRv4 和 PP-OCRv5 性能差距明显，排行榜如果不标版本，参考价值会打折。
3.3 传统开源OCR：EasyOCR、Tesseract、MMOCR、RapidOCR、docTR
EasyOCR 上手快，支持中文、英文、日文等几十种语言。我拿它做过快速原型，装完就能跑。中文准确率中等，印刷体清晰图片够用，手写和复杂版式吃力。它依赖 PyTorch，模型体积不小，CPU 推理偏慢。适合做 demo 或者对精度要求不高的内部工具。
Tesseract 是 OCR 老前辈，中文需要额外下载语言包。我测过简体印刷文档，字符准确率大概 80% 到 90%，具体看字体和清晰度。繁体、竖排、手写基本不能看。Tesseract 的优点是轻、免费、可离线、可训练。做简单票据号码提取、固定字体识别还能用。做中文通用识别，我不会把它放首选。
MMOCR 是 OpenMMLab 的 OCR 工具箱，检测、识别、关键信息抽取都有。它更像研究框架，配置灵活，可以换骨干网络、换损失函数。中文效果取决于你选的模型和训练数据。我见过有人用 MMOCR 微调出很强的票据模型，也见过默认配置下中文一般。RapidOCR 主打轻量，把 PaddleOCR 模型转成 ONNX，推理快，依赖少。我拿它部署过端侧证件识别，8MB 左右的模型，CPU 上每张图几十毫秒，准确率只比原版低一点点。docTR 文档理解做得好，英文文档、版面分析强，中文支持偏弱，社区中文资料少。
3.4 多模态大模型OCR：GOT-OCR、Qwen-VL、InternVL、MiniCPM-V
多模态大模型给 OCR 排行带来新变量。GOT-OCR2.0 专门为 OCR 设计，支持通用文本、格式化文本、数学公式、图表、乐谱。我拿它测过复杂表格和手写笔记，识别加理解能力比传统 OCR 强很多。缺点是模型大，推理慢，显存要求高。Qwen2.5-VL 在 OCRBench 上表现亮眼，中文场景理解好，能直接回答“这张发票的抬头是什么”。InternVL2.5 和 MiniCPM-V 2.6 也在榜单前列，小尺寸版本适合端侧。
这些模型不是纯 OCR 工具。它们会做推理、纠错、格式化输出，有时会“脑补”原文没有的字。我做过对比：传统 OCR 输出原文字，多模态模型输出一段总结。做票据字段抽取，多模态模型省了后处理。做法律文书逐字比对，多模态模型的风险更高。排行榜上多模态模型分数高，评测方式偏向问答和端到端任务，跟传统 OCR 的字符准确率不是同一个赛道。
我的用法是混合。通用文本用 PP-OCRv5，复杂版面用 GOT-OCR2.0，字段问答用 Qwen2.5-VL。显存不够就换 MiniCPM-V 小版本。多模态模型迭代快，三个月前的排名可能已经变了。看排行时我会查模型卡、评测集、推理成本，不会只看总分。
3.5 不同任务排行差异：通用文本、票据、证件、表格与手写体
通用文本识别，PaddleOCR 系列通常最稳。PP-OCRv5 在简体、繁体、中英混排上都有优势。EasyOCR 和 Tesseract 在清晰印刷体上能用，复杂背景掉得快。多模态模型在通用文本上不一定比专用 OCR 强，模型大、速度慢，字符级精度偶尔输给 PP-OCRv5。
票据和证件场景，PaddleOCR 的 PP-Structure 和微调流程很实用。我做过发票识别，用 PP-OCRv5 检测识别，加规则后处理，字段准确率能到 95% 左右。证件识别更看检测和方向分类，RapidOCR 轻量部署有优势。多模态模型在票据问答上强，直接问“总金额是多少”很方便，逐字输出稳定性不如专用模型。
表格识别看 TEDS 指标，PaddleOCR 的表格模型和 GOT-OCR2.0 都靠前。手写体是另一个世界。CASIA-HWDB 上传统模型分数一般，多模态大模型和专门手写模型更好。我测过手写地址，Qwen2.5-VL 比 EasyOCR 高十几个百分点。竖排古籍，PP-OCRv5 和部分多模态模型能处理，Tesseract 基本放弃。选型时我会先定任务，再看对应子榜单，通用排行只做初筛。
4. 基于OCR模型排行的选型建议与趋势展望
4.1 OCR模型排行榜评测指标与选型建议的关联
我见过太多人拿着排行榜第一名就去立项，结果跑了一周发现根本用不了。
排行榜上的指标是实验室里跑出来的，你的业务是泥地里滚出来的。这两件事之间隔着一条河。
拿准确率来说。榜单上 98% 的字符准确率很漂亮，可你的图片是手机拍的发票，有阴影、有折痕、有反光。同一个模型丢进去，掉到 85% 都有可能。榜单用的是干净扫描件，你用的是真实场景图，评测集和业务数据之间的分布差异，是选型时第一个要警惕的东西。
推理速度也是同一个道理。榜单标的是 GPU 上的吞吐量，你的部署环境可能是 CPU 服务器，甚至是树莓派。我拿 RapidOCR 在 CPU 上跑过证件识别，每张几十毫秒，换成一个多模态大模型，同样硬件上要好几秒。排行榜不会告诉你这些。
我的做法是把榜单指标翻译成业务语言。字符准确率对应的是“录入员要改多少字”，F1 对应的是“漏检和误检哪个更致命”，编辑距离对应的是“后处理规则好不好写”。翻译完再看排行，你会发现有些高分模型跟你没关系。
4.2 选型四步法：场景定义、指标权重、候选筛选与实测验证
我自己选 OCR 模型有一套固定的路子，四步走，每步都有坑。
第一步是场景定义。你要搞清楚输入长什么样、输出给谁用、容错空间多大。扫描合同、手机拍快递单、监控截图、手写笔记，这四个场景对模型的要求完全不同。我会列一张表：图片分辨率、光照条件、文字方向、字体类型、背景复杂度、语言种类。这张表写完，一半的候选模型已经被排除了。
第二步是给指标排权重。高精度场景，字符准确率权重拉到最高，速度可以让步。实时场景反过来。私有化部署要把模型体积和显存占用放前面。我一般会给每个指标打分，加权算总分，而不是只看一个维度。这一步做完，候选池从十几个缩到三四个。
第三步是拉候选模型跑实测。我会准备两百到五百张业务样张，覆盖容易和困难的case，让每个候选模型都跑一遍。记录字符准确率、单张耗时、显存峰值、失败案例。这一步最花时间，也最值得花时间。排行榜上差两名，实测可能差出两个档次。
第四步是验证后处理链路。OCR 输出的是原始文字，业务要的是结构化字段。检测框合并、正则提取、纠错词典、字段映射，这些环节对最终效果的影响不比模型本身小。我见过模型准确率 96%，加上后处理掉到 88% 的，也见过模型 92%，后处理拉回 97% 的。选型不能只选模型，要选整条链路。
4.3 按需求选型：高精度、高速度、轻量端侧、私有化与垂直场景
不同需求指向不同模型，我按自己踩过的坑来分。
追求高精度，通用中文场景我推 PP-OCRv5，复杂版式和手写可以上 GOT-OCR2.0 或者 Qwen2.5-VL 大尺寸。这类组合字符准确率能打，代价是推理成本高。法律文书、医疗报告、财务审计这类场景，精度优先级最高，速度慢一点能接受。
追求高速度，RapidOCR 是我的首选。ONNX 推理，依赖少，CPU 上跑得动，准确率比 PaddleOCR 原版低一点点，对多数业务够用。日志分析、批量文档入库、实时字幕这类场景，吞吐量比精度重要。
轻量端侧部署，模型体积和内存占用是硬约束。RapidOCR 的 8MB 模型、PP-OCRv5 的 mobile 版本、MiniCPM-V 的小尺寸，都在可选范围。我拿树莓派做过身份证识别，RapidOCR 跑得稳，换成大模型直接爆内存。
私有化部署要看授权协议和依赖复杂度。PaddleOCR 是 Apache 2.0，商用友好。EasyOCR 也是 Apache 2.0，但依赖 PyTorch，打包体积大。Tesseract 最轻，精度也最低。私有化场景我会优先选依赖少、协议清晰、社区活跃的模型。
垂直场景要单独找模型。票据看 PP-Structure，表格看 GOT-OCR2.0 和 PaddleOCR 表格模型，手写看多模态大模型，古籍竖排看 PP-OCRv5 和部分专门训练的模型。通用排行榜在垂直场景的参考价值有限，最好找对应子榜单或者自己标注数据微调。
4.4 排行之外的避坑指南：授权协议、维护活跃度与二次开发成本
排行榜不会告诉你这些事，但它们能让项目翻车。
授权协议要仔细看。有些模型标着开源，实际是研究用途，商用要单独授权。有些模型依赖的第三方库用的是 GPL，会传染。我吃过一次亏，选了个效果很好的模型，法务审核时发现协议不允许闭源商用，整个方案推倒重来。现在我选型第一步就是查协议，Apache 2.0、MIT、BSD 这类宽松协议优先。
维护活跃度决定长期成本。我会看 GitHub 的提交频率、issue 回复速度、版本发布节奏。一个半年没更新的模型，遇到 bug 没人修，遇到新需求没人加功能。PaddleOCR 和 MMOCR 维护活跃，RapidOCR 也稳定。有些研究型模型发完论文就停更，只适合短期验证，不适合长期项目。
二次开发成本容易被低估。微调需要标注数据、训练环境、调参经验。有些模型微调文档写得好，有些只有论文没有教程。我评估时会看：官方有没有微调脚本、社区有没有中文教程、模型结构好不好改。自定义词典、加新类别、调检测阈值，这些需求在真实项目里很常见，选型时要提前想清楚。
还有一个隐形坑是版本差异。PP-OCRv4 和 PP-OCRv5 性能差很多，有些排行榜不标版本号。你看到的第一名，可能用的是老版本。我会去模型卡里核对版本、训练数据、评测集，确认排行分数的来源。
4.5 OCR模型排行趋势：多模态融合、中文垂直榜单与评测标准化
这两年 OCR 排行的变化很快，我说说自己的观察。
多模态融合是最大的趋势。传统 OCR 只做检测识别，多模态模型直接做端到端理解。GOT-OCR2.0、Qwen2.5-VL、InternVL 这类模型在 OCRBench 上的分数一路往上。它们的评测方式也变了，从字符准确率转向问答准确率、结构化输出准确率。
未来 OCR 排行可能会分成两条线：一条是传统字符级识别，一条是文档理解问答。两条线的模型不能直接比分数。我在实际项目里也是两手准备，通用文本用专用 OCR，字段抽取用多模态。
中文垂直榜单在变多。通用榜单以英文为主，中文场景的评测一直不够细。CTW、ReCTS、OCRBench 中文版这些数据集推动了中文榜单的发展。票据、证件、手写、竖排这些细分场景，也开始有专门的评测集。我觉得这是好事，选型时能找到更贴近业务的参考。
评测标准化还在路上。不同榜单用的数据集、指标、预处理方式不一样，分数没法直接横比。数据污染也是个问题，有些模型在训练时见过评测集，分数虚高。我期待未来出现更透明的评测机制，公开测试集、公开推理脚本、公开版本信息，这样排行榜的参考价值才会真正提升。
4.6 总结：让排行服务业务，而非替代业务验证
排行榜是个好东西，它帮我快速缩小候选范围，了解技术趋势，避开明显不行的选项。但它不是决策工具。
我的经验是：排行榜用来初筛，业务样张用来终选。榜单上的分数是别人的场景，你的场景只有你自己知道。同样一个模型，在扫描件上 98%，在手机拍照上可能 82%。这个差距，只有拿你自己的数据跑一遍才能看到。
选型这件事，没有万能答案。高精度有高精度的模型，高速度有高速度的选择，端侧有端侧的方案。你要做的是先定义清楚自己的需求，再对着排行榜找候选，最后用实测数据做决定。
排行榜会一直变，模型会一直更新。今天的第一名，半年后可能掉出前三。把选型流程固化下来，比记住哪个模型第一更重要。场景定义、指标权重、候选筛选、实测验证，这四步走下来，换什么模型你都能选出合适的。
最后一句，排行服务业务，业务验证排行。别让榜单替你做决定。
