你在选 OCR 多模态模型时大概率碰到过这种情况：榜单上排前面的，拿来扫自己的票据、表格、手写件却各种漏字；或者单张图效果好，一上批量就跑不动。这篇不排座次、不给结论数字，而是把评测拆成可操作的几层——评什么能力、用什么数据评、按什么口径判对错、评完怎么落到选型上。适合要出选型报告的工程师和采购评估的人照着走一遍。
你在选 OCR 多模态模型时大概率碰到过这种情况：榜单上排前面的，拿来扫自己的票据、表格、手写件却各种漏字；或者单张图效果好，一上批量就跑不动。原因通常不是模型不行，而是评测这件事本身没拆开做。
这篇不排座次、不给结论数字，而是把评测拆成可操作的几层——评什么能力、用什么数据评、按什么口径判对错、评完怎么落到选型上。适合要出选型报告的工程师和负责采购评估的人照着走一遍，全程只需要一台能跑脚本的机器加一份标注表。
先分清要评的是哪几种「OCR 能力」
最容易犯的错是把所有 OCR 任务当成一件事评。印刷体票据和手写笔记对模型的要求几乎不重叠，混在一个总分里，最后得到的排名没有任何指导意义。动手前先拿一张纸，把业务里真实出现过的输入各写一行。
- 纯文字识别
- 印刷体、手写、低质扫描件，只看字符对不对
- 版面结构还原
- 表格、多栏、票据字段，关注阅读顺序和字段归属
- 图文混合理解
- 图表问答、截图推理，输出的是结论不是文字
- 跨页跨文档串联
- 多页合并、同一份材料分散在多个文件里
每类还要再切一刀：识别准不准，和输出能不能直接用，是两回事。很多模型字符识别没问题，但坐标错位、表格结构全乱，直接喂给下游系统还得人工重排。所以每类能力至少留两个观测点：内容准确度、结构化输出可用度。
测试集怎么造：从采样到标注的落地步骤
公开数据集可以用来看模型大致水位，但不能当选型依据，因为它的分布和你业务里的输入分布往往差得很远。测试集要自己造，造的过程本身就是一次业务梳理。
- 按业务来源分层采样分层维度建议用文档类型 × 图像质量 × 语言字体 × 版面复杂度，每层留够样本量，别让某一类样本因为好找就被过量采样。
- 标注两层信息第一层是文字内容，用于算识别指标；第二层是结构标签，包括字段名、表格行列、阅读顺序。只标文字的测试集，评不出结构化输出的好坏。
- 额外留一批为难样本倾斜、反光、遮挡、水印、超长表格各留几张。这批不计入主分，单独记录，用来找模型的失效边界。
- 固化成版本号给测试集打版本号，模型换代或提示词改动后重跑同一套。没有版本号，前后两次结果就没法比。
样本量不用追求很大，但要覆盖到你真实遇到的每种情况。一个小团队做完这一步通常几十到上百张就够起步，重点是分层清楚、标签一致，而不是堆数量。
判定口径：怎么算对、怎么算错、谁来判
判定口径不统一，是评测结果吵不出结论的主要原因。同一份输出，两个人用不同的归一化规则，能得出完全相反的判断。所以规则要在跑测试之前就写下来，写进评测文档。
| 评测层 | 比对方式 | 常见坑 |
|---|---|---|
| 文字内容 | 字符级或字段级比对 | 全半角、空格、标点、日期格式没归一化 |
| 版面结构 | 字段抽取命中率、表格结构还原率 | 整体相似度看着高，具体字段却全错位 |
| 主观项 | 人工抽检、多人交叉打分 | 一个人判完全部，标准随心情漂移 |
把「部分正确」单独计一档很重要。OCR 场景里错一个字和整行丢失，严重程度差得远，只有对错两档会把真实差距抹平。可以按错字比例或字段命中比例分档，档位自己定，但要前后一致。
把成本与吞吐一起评，别只评准确率
只比准确率的评测，在选型会上很容易被一句「那它跑一百页要多久、要多少成本」问住。所以同一批测试集上，至少要同时记录三项：单页平均耗时、批量并发下的耗时变化、按你实际用量折算出的调用成本。
- 图片预处理流程要固定：怎么缩放、长边限制设多少，会同时影响准确率和成本，写进评测记录
- 自建还是调用，按你自己的页数算，具体折算口径到 /compute/tco 和 /compute/sizing 核对
- 高峰时段单独测一轮，很多模型平均延迟好看，但并发一上来就排队
- 记录失败重试和超时的情况，这部分在平均耗时里体现不出来
有个容易被忽略的变量是分辨率。上传前缩得太狠，小字和表格线就糊了；不缩，成本和延迟又上去了。评测时固定一套预处理流程，把参数写进记录，否则换个人重跑结果对不上。
评完之后怎么落到选型结论
评完一堆数据，最后要收敛成一份能签字的东西。做法是按业务权重给四类能力加权出总分，而不是简单取平均。权重写进报告，别人才能复核你的结论，也能在业务变化时快速调权重重算。
同时定两条线。及格线是能上线的下限，达不到就不考虑；淘汰线针对单项能力，比如手写件识别差到没法接受，哪怕总分高也淘汰，因为那块短板会拖垮整条流程。
再准备一个回退方案：主模型加备用模型，触发条件写清楚，比如准确率掉到什么程度、延迟超到什么程度就切。切之前用小样本集先验证一遍备用模型，别等出事才试。
对外引用数据时统一指向站内的模型库和测评榜单，避免引用外部口径不一致的数字。各家官方 API 的价格与模型资料在 /models 有整理，价格变动看 /price-watch，模型实测对比看 /rankings，速度相关的实测在 /tools/speed-test。
下一步把上面四类能力按你的业务权重列一张表，然后到站内模型库和测评榜单对照当时的数字，先圈出三到五个候选，再跑自己的测试集。站内数字会更新，所以看的时候以页面当下显示为准，别记成固定结论。→常见问题
我自己造测试集，样本量多少才够用？
没有固定数字，取决于你要区分的差距有多小。经验做法是：先按文档类型和质量分层，每层至少几十页起步，跑一轮看两个模型的差距是否稳定；如果换个样本顺序结论就翻，说明量不够，继续加。样本少的时候别下强结论，只把它当排查线索，具体口径可对照 /benchmarks/registry 里的公开测评集构造方式。
公开榜单能不能直接拿来选 OCR 模型？
可以当筛选入口，不能当结论。公开榜单的测试集和你的业务文档在版式、字体、扫描质量上往往差得远，而且很多榜单只算文字内容、不看结构输出。正确顺序是：先用榜单把候选缩到几个，再用自己那套分层测试集跑一遍，两者结论不一致时以自测为准。
OCR 场景该选通用多模态大模型还是专用 OCR 模型？
看任务里有没有「理解」成分。只做文字提取和字段抽取，专用 OCR 链路通常更省更稳；一旦要回答和图表内容有关的问题、要跨页归纳、要按指令输出特定格式，多模态大模型优势明显。混合场景可以拆成两段——专用模型做抽取，大模型做后处理和问答，成本往往更低。
