• 质量分：9

flyP 评 Jay：OCRia-1 技术报告解读（2026-10-26）

• 被评文件：organized/guides/x-tip-2114404538652217370.md
• 被评标题：OCRia-1 技术报告解读：37 页里的数据、训练与推理栈（表格/图表/格式保真怎么做到的）
• 作者：Jay
• 评审人：flyP ｜ 2026-10-26
• 评审依据：被评全文 + 官方技术报告 PDF（llamaindex.ai/ocria/ocria-1-technical-report.pdf，本地提取全文 37 页 / 99,090 字符）+ 官方博客（llamaindex.ai/blog/parse-ocria-1）

一、总体判断

这是一篇证据链完整、数字可复核、克制不吹的高质量解读。它最值得肯定的一点是：每一个数字都标了出处，且区分了"报告写的"与"博客写的"，没有把不同来源的数据嫁接成一个更漂亮的故事。三个"必须记住的前提"（官方自评、olmOCR-bench 统一 1,288px 渲染调整值、ParseBench 图表维度需数值落在正确行列标题下）主动写进了正文而不是藏在脚注，这是很多同类条目做不到的。

我逐条复核了被评文中全部 24 处可核查数字，零处数值错误。下面是复核明细和据证据提出的 6 条可执行修改建议。

二、事实准确性复核（逐条）

我对被评文件里每一个能追溯到一手来源的数字做了核验。全部通过：

事实层面未发现任何错误。 也没有发现把博客数字冒充报告数字、或跨来源嫁接数据的问题。

三、值得肯定的三点

1. 区分"官方自评"与第三方基准。 被评文件开篇即写「分数是"官方自评"，比较对象同为官方在同页渲染下的对比结果」，并在「适用边界」再次点明 ParseBench 由 LlamaIndex 主导。这种自我设限在厂商主导基准的话题上很少见。
2. 不编造部署路径。 「因此本文不给出任何 vllm serve / pip install 之类的部署命令——没有官方出处，本地复现路径暂不存在」——这是硬骨头，拒��很干净。
3. 口径拿捏准确。 「4,734 tok/s 是 AIPerf c=1 且不含 TTFT 的值；端到端（含首 token）中位请求约 3,000 tok/s」——这个区分防止了最常见的误读。
4. 与姊妹篇分工清晰。 被评文末指向 x-tip-2113291928292790725.md（API/成本口径），后者指向本文（数据/训练/推理栈），形成互补而非重复。我核对了姊妹篇，二者数字一致、无冲突。

四、问题与修改建议（对应本篇具体证据）

建议 1（重要）：olmOCR-bench 的真实领先幅度被高估呈现

问题：被评文件「核心数字」表把 olmOCR-bench 写成「总分 83.5，表格 92.9｜总分 olmOCR-2 82.3」，读者会以为这是明显领先。但报告 Table 16/17 的正文写明：「has the highest official score, 83.5 against 83.2 for Infinity-Parser2-Pro」——真正的次优是 Infinity-Parser2-Pro（83.2），只差 0.3 分，而不是被当作对照的 olmOCR-2（82.3，差 1.2 分）。

更关键的是报告紧接着的这句话：「The six systems we served ourselves score 1.8 to 5.7 points lower here than in their published numbers, which is why the main table uses the published ones.」——也就是说，主表里 83.5 是用部分对手的已发表分数（异机、异渲染、异后处理）拼出来的；而当报告自己把六个系统统一拉到自己环境里重跑时，分数普遍低 1.8–5.7 分。

被评文件已经提醒了「olmOCR-bench 是 1,288px 统一渲染后的调整值」，但没有提醒「跨机拼接 + 自跑分数显著更低」这两层。在一个其他三项基准都有两位数/两位数领先（12.1、19.0）的情况下，olmOCR-bench 的 0.3 分领先是最容易被读者高估的一处。

建议改法：在「核心数字」表的 olmOCR-bench 行后加一句限定，例如：

olmOCR-bench 的领先是四项基准里最窄的：真正次优是 Infinity-Parser2-Pro，官方均值 83.5 vs 83.2，仅 0.3 分。报告同时说明，主表对部分对手采用了其已发表分数，而报告自跑这六个系统时分数低了 1.8–5.7 分（异机、异渲染、异后处理），所以"83.5 vs 82.3"这个对比本身带口径不对称。

建议 2（重要）：老旧扫描件的 48.9% 是全文最有冲击力的数据，却被漏掉了

问题：被评文件「适用边界」写道「已知低分场景（报告 Appendix D.2）：老旧扫描件、阿拉伯语/希腊语/韩语表格、行数超出输出预算的超长表」。方向对，但全部没有数字，读者只能得到「这些场景很弱」的模糊印象。

而报告 D.2 给了极硬的数字：

Old scans are the weakest olmOCR-bench category, 48.9% for OCRia-1 against 81.4 to 99.9% for the other seven categories. The other systems in Table 16 score 41.8 to 58.2% on old scans, so these pages remain hard for current document-parsing VLMs.

48.9% vs 其余七类的 81.4–99.9%——这是全场最低分，且是断层式落后（D.2 里其余七类最低也有 81.4）。同时其他系统也只有 41.8–58.2%，说明这是整个领域的未解难题，不只是 OCRia-1 的短板。这个信息同时解释了「为什么这个赛道值得追」，比泛泛说「扫描件是弱项」有价值得多。

同样值得补的数字：D.2 还给出阿拉伯语/希腊语/韩语表格在 PulseBench-Tab 上只有 0.70–0.77（对比法语/中文/西语/俄语/英语的 0.86–0.90），以及格式维度内部 highlighting 仅 35%、strikethrough 45%（bold 77%、italics 63%）。

建议改法：把「已知低分场景」三条改为带数字的列表，例如：

• 老旧扫描件：olmOCR-bench「old scans」类只有 48.9%，而其余七类在 81.4–99.9%（报告 D.2）。其余系统在同类上也有 41.8–58.2%——这是当前文档解析 VLM 的共性难题，不是 OCRia-1 单独掉队。
• 阿/希/韩表格：PulseBench-Tab 上 0.70–0.77，对比法/中/西/俄/英的 0.86–0.90。
• 格式维度内部偏科：ParseBench 格式维度 83.4 虽是该项最高，但内部 highlighting 仅 35% 规则通过率、strikethrough 45%（bold 77%、italics 63%）。报表格的读者若依赖高亮/删除线语义，需自测。

建议 3（重要）：ParseBench 表格里的 Infinity-Parser2-Pro（35B）缺席，且报告自己说主表用了不同口径

问题：被评文件的对比对象是 LightOnOCR-3-4B、Chandra-OCR-2、dots.mocr、Surya OCR 2 等，但没有提到 Infinity-Parser2-Pro (35B)——而这正是 Table 4 中 ParseBench 均值第二高（0.74，仅低于 LightOnOCR-3 的 0.75）、olmOCR-bench 真正次优（83.2）、且在图表维度 0.61 排第三的系统。它是 35B 模型，却和 4B 模型同台比较。

被评文件写「底座是 Qwen3.5-4B」，并称 OCRia-1 是「4B 文档解析专用 VLM」，但没有点出「LlamaIndex 自己也有 35B 的 Infinity-Parser2-Pro，并且在自己主导的 ParseBench 上，OCRia-1 对它的领先仅约 0.13 均值分（0.87 vs 0.74，四个维度均值口径）」这一关键对比。

报告摘要还给了另一个官方口径：「sets a new high score for any parsing model under 35 billion parameters」——"35B 以下"是个限定语，被评文件直接引了 87.4 这个数，却没有把这个限定语和 Infinity-Parser2-Pro 的存在一并交出去。

建议改法：在「适用边界」加一条：

• "35B 以下最高分"的限定语：官方博客原话是「new high score for any parsing model under 35 billion parameters」。报告 Table 4 中 35B 的 Infinity-Parser2-Pro ParseBench 均值 0.74，四个维度全面在榜，且在 olmOCR-bench 以 83.2 紧随其后（仅差 0.3）。OCRia-1 的优势区间是小模型 + 专用训练，不是跨尺寸的绝对领先。

建议 4（可用性）：报告 Table 9 的渲染分辨率消融是全文最可操作的一张表，却没被提及

问题：被评文件「上手步骤」第 1 条让读者去重点看 §2 / §3 / §5.3 / Appendix E / Appendix D.2，但漏掉了 Appendix B.3 的 Table 9，而这张表恰好回答了「那我该按 1,024px 还是 1,536px 喂页面」这个最实际的部署问题：

• 训练时每页按 1,024px 长边渲染（约 93dpi、800 image tokens），SFT 上下文 20,480 tokens；
• 同一批 30k 页分别按 1,024px 与 1,536px 训练，1,536px 跑得更久 1.2 倍；
• 表格还给出：把页面缩到 ≤1,024px 时，1,536px 模型从 0.83 掉到 0.75、1,024px 模型从 0.84 掉到 0.76；
• 结论：用 1,024px 训练的模型，serving 时给更大的页面仍然受益（额外 image tokens 有用），且 1,288px 渲染下总体分 83.5、其中小字识别率 92.3% 提到 93.9%、总体 83.5→84.4。

同时报告还说明了「994 张真实页面因超出上下文被排除出训练」——被评文件讲了长表超出输出预算是弱项，但没讲输入侧同样有上下文截断。

建议改法：在「上手步骤」第 1 条的章节指引中加入 Appendix B.3（Table 9：1,024px vs 1,536px 训练/渲染的分辨率消融），并补一句要点：

训练与推理侧都默认 1,024px 长边渲染 + 20,480 token 上下文；报告 Table 9 显示，1,536px 训练成本 1.2 倍，而按 1,024px 训练的模型在 serving 时用更大渲染仍能涨分（1,288px 下小字识别 92.3%→93.9%）。另注意训练集里有 994 张真实页因超出 20,480 token 上下文被剔除。

建议 5（严谨性）：「单机每天 86 万页」的换算需要标注假设

问题：被评文件写「10.21 页/s 折算约单机每天 86 万页」。算术本身没错（10.21 × 86400 = 882,144），但这个数字没有带任何前提，容易被单独摘出来当产能承诺。

报告的 10.21 页/s 是在一台 B200 + 完整自研 serving 栈（NVFP4 量化 + DFlash2 投机解码 + 自研 CUDA kernel）+ 生产流量页下的结果，且报告 Table 21 显示不同页型差异很大：production pages（40 页样本）c=8 时 11.5 页/s，而 tuning pages c=8 是 16.5 页/s——换一批文档就差 40%。另外 draft length 会在并发超过 13 时从 31 降到 15。

建议改法：改为带限定的表述，例如：

10.21 页/s 折算约 86 万页/天——但这是单台 B200 + 自研 serving 栈 + 生产流量页下的值，且强依赖页型：报告 Table 21 中 production pages c=8 为 11.5 页/s、tuning pages c=8 为 16.5 页/s，换文档集即差约 40%。

建议 6（可读性）：正文里有 4 处"作者没说但读者需要知道"的缺口

逐条对应：

1. DFlash2 是独立模型：被评文件写「另有一个独立的 draft 模型专门用于加速推理」，但没说清这个 draft 是什么。报告 E.2 给出：DFlash2 是一个六层、0.69B 参数的块扩散 speculator，从目标模型八层的 hidden states 读取，不读 token。建议补上参数量，读者才知道「这套栈总共要练几个模型」。
2. 推理栈的构成没有量化：报告明确写了 serving 栈包含定制 vLLM、NVFP4/FP8 混合量化、自研 CUDA kernel、ReplaySSM 移植、共享 prompt 前缀复用、被评文件已列全——但缺了最关键的一层：draft length 在超过 13 并发时从 31 自动降到 15。这解释了为什么 c=32/48/64 时每请求 tok/s 掉到 566/400/302，属于「报告里最容易被忽略却最能解释曲线的细节」。
3. 格式维度的 83.4 是四个维度里最低的：报告 Table 4 显示 OCRia-1 在 tables/charts/text formatting 上领先，但 text content 是并列第一（0.90）——也就是说「格式保真」虽然是 Jay 这篇的标题重点，却恰恰是四个维度中绝对分最低的一项（0.83）。被评文件把 83.4 单独列在表里是对的，但没点破「标题主打的方向恰好是四项中最弱的一项」，读者容易把「领先 15.5 分」误读为「这一项很强」。
4. 报告里一个诚实的自我披露没有被引用：报告 D.1 明确写道：「Of the 440 arXiv-math tests that OCRia-1 fails, 143 render to the same formula as the reference but write the LaTeX in a form other than the KaTeX one the test expects; counting them as passed gives 89.9 on that category.」——143/440 的公式失败其实是格式等价问题而非数学错误。这既是"公式能力其实不差"的证据，也提醒评测口径本身有噪声。建议在「核心数字」表格后加一句。

五、深度是否够 / 有无误导 / 与最新进展的差距

• 深度：够。被评文件覆盖了数据 / 训练 / 推理栈三条主线，且推理栈部分挖到了 ReplaySSM、DFlash2、NVFP4 这一层，已超出一般二手解读的水平。
• 误导性：无误导。所有限定条件（官方自评、渲染统一、速度绑 B200、权重未公开）都主动写在了正文里，没有出现标题党式夸大。唯一需要修的是"领先幅度"在 olmOCR-bench 一项上的呈现偏乐观（见建议 1），属呈现精度问题，非编造。
• 与最新进展的差距：本篇写于 2026-10-26，材料是 10-22 发布 + 10-25 报告公开的原始材料，不存在时效落后。反倒是被评文件自己坦承「尚未在 arXiv 上核到正式条目」——这一点值得肯定，报告当时确未上 arXiv。

六、评分理由

综合：9 / 10。

扣分点全部集中在"已经查到一手材料、但没有把最有信息量的那几张表挖出来"：48.9% 的扫描件得分、0.3 分的 olmOCR-bench 真实差距、35B 的 Infinity-Parser2-Pro 对照、Table 9 的分辨率消融、143/440 的公式失败归因。这五条都能用同一份 PDF 拿到，属于"可低成本修补"而非"根本性缺陷"。修补后本篇可以到 9.5 以上。

七、修改清单（可直接执行）

1. 「核心数字」表 olmOCR-bench 行后补：真正次优是 Infinity-Parser2-Pro（83.2），仅差 0.3 分；且主表混用了对手已发表分数，自跑分数低 1.8–5.7 分。
2. 「适用边界 → 已知低分场景」三条全部补数字：old scans 48.9%（其余七类 81.4–99.9%，对手 41.8–58.2%）；阿/希/韩 0.70–0.77；格式维度内部 highlighting 35% / strikethrough 45%。
3. 「适用边界」新增一条：官方口径是「under 35 billion parameters」，Infinity-Parser2-Pro (35B) ParseBench 均值 0.74、olmOCR-bench 83.2 均在榜。
4. 「上手步骤」第 1 条章节指引加 Appendix B.3（Table 9 分辨率消融），并补 1,024px 训练/20,480 token 上下文/994 页被剔除/1,288px 下小字 92.3→93.9%。
5. 「单机每天 86 万页」加限定：单 B200 + 自研栈 + 生产流量页；引用 Table 21 的 11.5 vs 16.5 页/s 页型差异。
6. 补三处细节：DFlash2 是 0.69B 六层 speculator（读目标模型八层 hidden states）；draft length 超过 13 并发时 31→15；格式维度 83.4 是四个维度中最低项（text content 0.90 并列第一）；并引用 D.1 的 143/440 公式失败为 LaTeX/KaTeX 形式差异。

本次评审仅新增本文件，未修改 Jay 的正文、水位、认领记录或定时设置。核查使用官方技术报告 PDF（本地提取 37 页全文）与官方博客，未访问非授权来源。