单篇 · 无期号ARTICLE
OCReS v0.1：当我们谈论 OCR 质量时，我们在谈论什么
本期要点POINTS
本期要点
关键实测数据DATA
关键实测数据
| 被测项 | 指标 | 值 | 实测日期 | 原始记录 |
|---|---|---|---|---|
| MPS Unlimited-OCR（云 RTX 4090） | 核心 4 图平均每页处理速度 | 7.54 s | 2026-07-26 | 原始记录 ↗ |
| MPS Unlimited-OCR（云 RTX 4090） | 峰值显存 | 9.65 GB | 2026-07-26 | 原始记录 ↗ |
口径：本地与云不混评（每条读数标了运行环境，两边数字不放在一起比）； 一行 = 一条可核读数；论文与第三方数字不进本表（见上方来源表）。 「原始记录」指向公开仓 cnopens/ruiowl-evidence 的固定链接（带 commit SHA，防漂移）；标「未收录」者为本地从未留存原始数据文件，不补造。
锐Owl 发布了第一套公开的 OCR 评价标准。这不是一篇对比评测，而是一次"制定度量衡"的尝试——方法论先行，案例验证跟随。
一、为什么需要一套标准？
OCR 选型是每个文档处理系统的第一道选择题。但当前的"比较"几乎全是错位的：
- 用单个 CER 打全场 — 表格的 HTML 结构 vs 纯文本，CER 根本不可比
- 混淆速度和精度 — 在 MacBook 上测出来 2s/页的引擎，不代表在服务器上也快
- 缺乏场景权重 — 对金融发票来说，字段提取准确率远比速度重要；对流水线来说，反过来
这不是谁的错——现有的 OCR 评测都是针对特定模型的单项展示，不是帮选型者做决策的框架。
所以我们做了 OCReS——Owl OCR Evaluation Standard。一套可复用的四维评价框架，让不同的 OCR 引擎可以在同一个坐标系下比较。
二、方法论：OCReS v0.1 四维框架
核心公式
OCR 质量 = f(S, F, L, E)
| 变量 | 维度 | 权重 |
|---|---|---|
| S | 字符准确率 (Symbol Accuracy) | 30% |
| F | 结构还原度 (Format Fidelity) | 25% |
| L | 版面理解 (Layout Understanding) | 20% |
| E | 综合效率 (Efficiency) | 25% |
← 表格可左右滑动查看
四个维度覆盖了 OCR 选型的全部核心变量：能识别什么、能还原什么、能理解什么、要花多少代价。
S — 字符准确率（30%）
测量方式：CER（编辑距离 / 总字数），仅在同格式输出间可比。
| 层级 | 定义 | 示例场景 |
|---|---|---|
| S1 | 纯文本逐字匹配 | 合同条款、书信 |
| S2 | 结构化字段提取 | 发票号码、金额、日期 |
| S3 | 多页跨页一致性 | PDF 前后页信息串联 |
← 表格可左右滑动查看
F — 结构还原度（25%）
这是最容易被忽视的维度。文字对了不代表文档被正确理解了——表格结构、标题层次、阅读顺序的还原质量，直接决定了下游处理的可用性。
| 层级 | 定义 | 响应值 |
|---|---|---|
| F1 | 表格行列对应关系完整 | 结构化输出（HTML table, JSON） |
| F2 | 标题/正文/页脚层次分明 | 标签准确率 |
| F3 | 逻辑阅读顺序正确 | 跨栏/跨页排序 |
← 表格可左右滑动查看
L — 版面理解（20%）
OCR 不仅是"读出文字"，还要"知道文字在哪、是什么"。bbox 精度和内容类型标签决定了后处理的能力边界。
| 层级 | 定义 | 关键能力 |
|---|---|---|
| L1 | 文本区域定位 | 边界框精度 |
| L2 | 内容类型分类 | title/text/table/figure/header/footer |
| L3 | 版面语义理解 | 表格→数字，标题→层级，批注→原文 |
← 表格可左右滑动查看
E — 综合效率（25%）
精度之外的硬约束。权重结构反映了我们的判断：单页速度是效率的核心指标，但部署成本和资源占用在实际选型中经常成为否决项。
| 子项 | 权重 | 测量方式 |
|---|---|---|
| 单页处理速度 | 60% | 秒/页（同硬件基线对比） |
| 资源占用 | 25% | 峰值 VRAM（GB） |
| 部署/启动时间 | 15% | 从开始到跑通第一页（分钟） |
← 表格可左右滑动查看
成本作为参考字段标注，不计入加权分——效率是引擎固有属性，成本依附部署环境，两者应分开考量。
元标准：跨域扩展
OCReS 的设计从一开始就不是只针对 OCR。四维公式固定，维度定义表随 domain 切换：
| 维度 | OCR（v0.1） | Agent 框架（规划中） |
|---|---|---|
| S | 字符准确率 (CER) | 任务完成率 (Success Rate) |
| F | 结构还原度 | 流程协调度 (Workflow Fidelity) |
| L | 版面理解 | 上下文理解深度 (Context Awareness) |
| E | 综合效率 | 延迟/成本/吞吐 |
← 表格可左右滑动查看
这不是理论空谈——我们已经在规划 Agent 框架评测方向。
三、案例评价：MPS Unlimited-OCR vs PaddleOCR
拿真实数据走一遍 OCReS 评分流程。
测试环境
| 项目 | MPS (本地) | MPS (云) | PaddleOCR (本地) |
|---|---|---|---|
| 硬件 | MacBook Pro M5 Pro (48GB) | RTX 4090 (25.4GB) | MacBook Pro M5 Pro |
| 引擎 | Unlimited-OCR (3B-A0.5B) | Unlimited-OCR (3B-A0.5B) | PaddleOCR |
| 测试图 | 12 张（含简单文本、表格、论文、发票等 6 类场景） | ||
| 基准脚本 | ocr_benchmark.py（统一流程，--backend 切换硬件） |
← 表格可左右滑动查看
逐维评分
S — 字符准确率
MPS 在简单中文和英文上均达到 CER≈0（10/10 字正确，40/40 英文无误）。PaddleOCR 在同类场景下 CER≈0.023，误差主要集中在中日韩混合字符和特殊符号。在结构化字段提取（发票号码、金额）上两者差距缩小，MPS 略优。
评分：MPS = 9.5 / Paddle = 6.0
Paddle 的 S 分偏低主要受限于输出格式——同为非结构化纯文本时差距约 3 分（MPS 9.5 vs Paddle 6.5+），但 Paddle 在某些场景下的 OCR 能力（如小字体、复杂版面）确实不如 MPS。我们采用了保守评估。
F — 结构还原度
这是差距最大的维度：
| 场景 | MPS 输出 | Paddle 输出 |
|---|---|---|
| 金融表格 (B1) | <table><tr><td>代码</td><td>名称</td>... — 完整 HTML table |
纯文本丢失行列对应 |
| 发票 (D2) | 字段+bbox 标签（header/text/table 分类） | 纯文本 |
| 中英混排报告 (D5) | <table> 含系统配置表完整还原 |
纯文本 |
← 表格可左右滑动查看
MPS 的 Unlimited-OCR 原生支持结构化输出（HTML table + bbox 标签），这是架构层面（attention over visual tokens + R-SWA）带来的能力。PaddleOCR 在结构输出上需要额外后处理 pipeline。
评分：MPS = 9.0 / Paddle = 4.0
L — 版面理解
MPS 的输出包含完整的 bbox 坐标和内容类型标签：
title [33, 64, 801, 158] —> Unlimited OCR Benchmark Test
text [33, 172, 999, 252] —> This is a simple printed text...
header [62, 12, 588, 22] —> OCR Benchmark Test Document
table [30, 133, 554, 410] —> <table>...</table>
每个识别区域都被精确定位并分类（title/text/header/table/header）。PaddleOCR 在标准模式下输出不含 bbox 标签的结构化信息。
评分：MPS = 8.5 / Paddle = 3.0
E — 综合效率
| 指标 | MPS (M5本地) | MPS (4090云) | Paddle (M5本地) |
|---|---|---|---|
| 核心4图平均 | 11.12s/页 | 7.54s/页 | ~2.5s/页 |
| 加速比 | — | 1.47x | ~4.5x |
| 峰值VRAM | ~8GB | 9.65GB | ~2GB |
| 首次部署 | 10min（模型下载） | ~14min（首次） | pip install 即用 |
| 成本参考 | M5 Pro 电量 | ¥3/h (RTX 4090) | 免费开源 |
← 表格可左右滑动查看
PaddleOCR 在效率维度全面胜出——轻量、启动快、资源占用低。
评分：Paddle = 9.0 / MPS 本地 = 5.0 / MPS 云 = 5.5
综合评分
同一引擎的不同部署形态作为独立评分行，S/F/L 共享，E 独立评分。
| 引擎 | 部署 | S | F | L | E | 总分 | 适用场景 | |:----:|:----:|::|::|::|::|:----:|---------| | MPS Unlimited-OCR | 本地 M5 Pro | 9.5 | 9.0 | 8.5 | 5.0 | 8.0 | 高精度文档、结构化输出 | | MPS Unlimited-OCR | Cloud RTX 4090 | 9.5 | 9.0 | 8.5 | 5.5 | 8.1 | 云端高负载、精度优先 | | PaddleOCR | 本地 M5 Pro | 6.0 | 4.0 | 3.0 | 9.0 | 5.5 | 大批量简单文档、快速部署 |
评分规则：每项 0-10，总分 = 0.3S + 0.25F + 0.2L + 0.25E
云端 4090 实测（2026-07-26）：核心 4 图平均 7.54s/页（M5 本地 11.12s），加速比 1.47x；峰值显存 9.65GB；首次部署
14min（含模型下载），缓存后11s。
选型建议
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 一次性高精度文档提取 | MPS 本地 | S+F+L 全面碾压，单页 11s 可接受 |
| 流水线大批量文档 | PaddleOCR | 2.5s/页、低资源、即装即用 |
| 精度要求+弹性负载 | MPS 云 4090 | S+F+L 不损，E 提升 0.5，弹性扩缩 |
| 需结构化表格输出 | MPS（任意部署） | 仅它原生支持 HTML table |
← 表格可左右滑动查看
数据完整性声明
以上评分中 S 维度的 CER 数据、E 维度的速度/显存/部署时间数据均为锐Owl 在统一基准脚本下实测获得[^1][^2]。F 和 L 维度评分基于人工归类评估，评分规则和权重结构公开透明，欢迎复现。
四、这不只是一篇评测
OCReS 的价值不在"谁赢了"，而在坐标系本身。
- 选型者拿它做决策矩阵——不用再被单个指标牵着走
- 开发者用它定位优化方向——S 不够还是 F 拖后腿，一目了然
- 我们用它作为锐Owl 评价体系的第一个 domain——下周的 Agent 框架评测将会是 OCReS 元标准的第一次跨域实践
这不是终点。这是度量衡本身。
参考文献
[^1]: 锐Owl 基准测试脚本. ocr_benchmark.py — GitHub. https://github.com/cnopens/ruiowl-benchmark (统一流程，--backend 切换 CUDA/MPS/CPU)
[^2]: 锐Owl Cloud CUDA 实测数据. results_mps_cloud.json, 2026-07-26. 12 图全通过，核心 4 图加速 1.47x，峰值 VRAM 9.65GB, 首次部署 ~14min, 总花费 ~¥2.
[^3]: OCReS v0.1 标准定稿. 四维框架 (S30%+F25%+L20%+E25%)，元标准扩展路线. 发布于 2026-07-24, 更新于 2026-07-26.
发布于 2026-07-28 | 锐Owl · AI 观察者 · 解构者 · 传播者