2025 年 10 月 22 日，Allen Institute for AI 把 olmOCR 2 放了出来。

这不是那种“识别一下图片里的字”的 OCR 小工具。它瞄准的是一个更麻烦的问题：PDF 里的内容，怎样变成大模型真正能吃、能检索、能训练的干净文本。

很多人对 OCR 的印象还停在扫描件识字。但只要处理过论文、合同、财报、旧书扫描件，就知道真正折磨人的不是字认不出来，而是顺序乱、表格碎、公式丢、页眉页脚混进正文。最后塞进知识库，看起来有文本，其实像把一盘菜倒进搅拌机。

olmOCR 的野心就在这里：用一个 7B 视觉语言模型 ，把 PDF、PNG、JPEG 转成自然阅读顺序的 Markdown，公式、表格、列表、多栏版式这些最容易翻车的结构也尽量保住。

PDF 里的文本，不等于能用的知识

PDF 是互联网知识库里很尴尬的一种格式。

它看起来像文档，实际上更像“固定版面的打印物”。人眼读起来没问题，机器读起来就很别扭：两栏论文可能先读左边，再跳到右边；表格被拆成几段散字；页眉页脚每一页重复出现，最后污染检索结果。

这也是为什么很多 RAG 项目跑到最后，问题不在向量数据库，也不在大模型，而在第一步抽取。入口脏了，后面再高级的 Agent team 也只能在脏数据上努力。

olmOCR 的路线比较直接：别只做传统 OCR，把页面当成视觉问题交给 VLM 处理。模型看到的是渲染后的页面图像，然后输出更接近人类阅读顺序的文本。

这一步听起来简单，实际很要命。因为它决定了 PDF 是变成一堆字符，还是变成可以被下游系统消费的文档。

它把 OCR 做成了可跑流水线

olmOCR 不是只发一个模型权重。

项目里给了推理 pipeline、训练代码、benchmark、Docker、远程 vLLM 支持，还有面向 S3 的多节点批处理方式。换句话说，它更像一套文档转换工厂，而不是一个 demo。

几个数字可以快速感受一下它的定位：

• 模型是 7B VLM ，当前主推 olmOCR-2-7B-1025-FP8
• 基座来自 Qwen2.5-VL-7B-Instruct
• README 里给出的转换成本是 每百万页低于 200 美元
• v1 论文摘要里的估算是 每百万 PDF 页约 176 美元
• benchmark 覆盖 1,400 份文档 、 7,000+ 个测试用例

这几个数字放在一起，意思就很清楚了：它不是拿 GPT-4o 这种闭源强模型去“豪华 OCR”，而是把质量、成本和私有部署放在同一个工程约束里考虑。

对企业文档、学术论文库、历史档案这类场景，这个点很实际。很多 PDF 不能随便发给外部 API；就算能发，按百万页计费也会让人冷静得很快。

benchmark 的设计有点像给 OCR 出单元测试

olmOCR-Bench 比较有意思。

很多 OCR 评测会看编辑距离，也就是输出文本和参考答案差了多少字符。但这套方法在复杂文档上不太够用。

比如一页里有两篇短文，只要每篇内部顺序对，两个模块谁先谁后未必致命。反过来，一个公式里把 x 和 y 写反，编辑距离只差一个字符，但意思已经完全变了。

所以 olmOCR-Bench 采用了更像“单元测试”的方式。它会检查一些明确事实：某句话有没有出现，某个公式有没有正确，某段文本是否在另一段之前，页眉页脚是否被排除。

这比单纯算字符差异更贴近真实使用。下游模型不在乎你和参考答案每个空格是否一致，它在乎关键事实有没有被保留下来，阅读顺序有没有乱掉。

README 里给出的 v0.4.0 结果大概是这样：

这里要留个边界：部分竞品分数是作者报告，不是全部由 AI2 复现实测。olmOCR 自己的分数也主要反映英文数字化印刷文档场景，不能直接推到所有中文票据、复杂表单和低质拍照件上。

但这个榜单依然有参考价值。至少它说明，开源 7B OCR 模型已经不再只是“能用”，而是在复杂 PDF 线性化这个方向上逼近了一线系统。

RLVR 用在 OCR 上，思路挺顺

olmOCR 2 最值得展开的是训练方法。

它用了 RLVR，也就是 reinforcement learning with verifiable rewards。简单说，奖励不靠人凭感觉打分，而是靠可验证测试来判断。

AI2 的做法是生成大量合成文档。因为合成文档有原始 HTML，所以系统知道正确结构是什么，再从里面抽出测试用例。模型输出 Markdown 后，就可以用这些测试去打分：这个文本有没有出现？表格关系对不对？公式有没有保留？多栏顺序有没有乱？

这招适合 OCR，是因为 OCR 很多错误确实可以被写成测试。

表格第一列和第三列有没有串？页脚是否被误当正文？公式里的上标有没有丢？这些问题不需要玄学审美，能过就是能过，不能过就是不能过。

这也是 olmOCR 从早期版本到 v0.4.0 分数提升的关键之一。它的演进不是只靠换模型，而是把 prompting、训练数据、图像尺寸、空白页处理、合成数据和 RLVR 一层层补上去。

这条线比单次发榜更有信息量。它说明文档 OCR 正在从“模型看图回答”变成一套可迭代的工程系统。

不是所有人都能马上本地跑起来

冷静一点看，olmOCR 也不是零门槛工具。

README 里写得很明确：本地 GPU 推理至少需要 12GB 显存 ，测试过的硬件包括 RTX 4090、L40S、A100、H100。Docker 镜像带模型版本大约 30GB 。如果只是想在笔记本上随手转几份文件，它不一定是最轻的选择。

更现实的用法，可能是两种。

一种是把它接到远程 vLLM 服务，客户端只装轻量包，通过 OpenAI-compatible API 调用模型。另一种是把它部署成批处理流水线，配合 S3 workspace，多台机器一起跑大规模文档库。

这也解释了为什么 olmOCR 的 README 里有很多“工程味”的内容：workers、pages_per_group、workspace、S3、Docker、Beaker。它不是只为单页 OCR 准备的，而是为了把一批 PDF 稳定吞进去，再吐出可用文本。

如果目标是做企业知识库、学术资料清洗、档案数字化，这种设计比一个漂亮网页 demo 更重要。

OCR 这件旧事，又被大模型翻出来重做了一遍

OCR 本来是很老的技术。但大模型时代，PDF 反而重新变成一个入口问题。

训练语料、RAG、长文档问答、Agent 自动阅读报告，全都绕不开文档抽取。以前大家容易把它当成前处理脚本，出了问题再去调 chunk、embedding、rerank。现在看，很多质量问题其实早在第一页 PDF 解析时就埋下了。

olmOCR 的价值不在于宣布“传统 OCR 结束了”。这话太满，也不准确。

它更像是在提醒大家：文档理解不是把字抠出来就完事。顺序、结构、噪声、公式、表格，这些看起来琐碎的东西，最后都会变成下游模型的上下文质量。

如果 PDF 是知识进入大模型系统的一扇门，那么 olmOCR 做的事，就是把这扇门从“能打开”修到“进来以后不摔跤”。

感兴趣可以看原始链接：

• GitHub：https://github.com/allenai/olmocr
• v1 论文：https://arxiv.org/abs/2502.18443
• v2 论文：https://arxiv.org/abs/2510.19817
• Demo：https://olmocr.allenai.org/