文档解析怎么选?这个1.3B的开源模型,三榜第一、单卡24G就能跑

💡 福利：关注本公众号并私信发送【智能体学习】，即可获得智能体系统性学习资料，先到先得！

做 RAG 和 Agent 落地的人，迟早会在同一个地方卡住：文档解析。

不是模型不够聪明，是喂进去的东西本身就是脏的。多栏论文左右串读、跨页表格行列错位、公式被识别成一堆乱码、化学结构式干脆被当成杂乱线条丢掉。下游的 RAG 检索和 Agent 工具调用，全都建立在“文档已经被正确解析”这个假设上——这个假设一旦不成立，后面每一步都在顺着错误数据往下滚。

2026 年 10 月，上海一支深耕文档智能的初创团队 SoMark，开源了一个叫 OXR 的模型。全称是 Optical Everything Recognition——从 OCR 到 OXR，它要处理的远不止文字。主模型只有 1.3B 参数，却在 OmniDocBench、olmOCR-Bench、DocParsingBench 三项基准上全部登顶，解析速度也快过同场参测的 PaddleOCR-VL-1.6 和 MinerU2.5-Pro。

但比“三榜第一”更值得拆的，是它做到这件事的方式：在后训练阶段引入了一套递归自我改进（RSI）循环，让模型自己找出读错和拿不准的样本，自动生成针对性训练数据，不需要人工标注。据团队说法，这是文档解析领域第一次把 RSI 用在 post-training 上。

GitHub 地址：https://github.com/SoMarkAI/OXRStars / Forks：约 3.7K Stars / 240 Forks。不同数据源抓取时间不同会存在波动，以 GitHub 实时口径为准。

📌 本文建议先收藏

这是一篇“架构拆解 + 训练机制分析 + 冷静评估”型文章。如果你在做 RAG 数据管道、文档智能，或者在关注“小模型 + 自进化训练”这条路线，这篇文章帮你搞清楚 OXR 到底在架构上做对了什么、RSI 循环怎么转、以及它离“生产级文档底座”还有多远。

📌 读完你将获得

✅ OXR 真正解决的问题——不是“认字更准”，是“让下游 Agent 拿到能用的数据”

✅ 两处架构减法——阅读顺序并入识别、版面分析可插拔，分别省掉了什么

✅ RSI 三阶段循环——分类、归因、生成，以及这个循环的可靠性边界

✅ 数据怎么读——三榜分数、101 秒解析 100 页，以及这些数字的边界

✅ 冷静评估——1.3B 的工程优势与“RSI 复利”尚未被验证的部分

一、先理解它要解决的不是“OCR 精度”，而是“数据可用性”

传统 OCR 的叙事是“识别准确率”。但文档解析的难点从来不在单个字符的识别，而在结构。

一张跨行跨列的表格，每个字都认对了，行列关系一旦错位，数字就会对应到错误的项目；一篇多栏论文，左右栏如果串读，即便每个区域都识别正确，原文的含义也会被破坏；科研文档里的公式有上下标和嵌套结构，化学内容还有反应式和分子结构图——这些东西如果只被“认成字”，对下游的 RAG 和 Agent 来说等于没解析。

OXR 的定位，是把 PDF 和文档图片转成 Agent-Friendly 的数据：输出 Markdown / JSON，保留版面坐标，覆盖 13 类文档元素——表格输出 HTML，公式输出 LaTeX，化学方程式用 mhchem，化学结构式用 SMILES。它交付的不是“文字”，是一份下游可以直接消费的结构化资产。

二、架构：两处“减法”，换来了精度和速度同时在线

OXR 在架构上最值得看的，不是加了什么，而是减了什么。而且这两处减法，都不是为了“设计优雅”，而是从“下游需要什么”反推出来的。

第一处减法：把阅读顺序判断并入识别底座。 传统文档解析通常是三步串行——版面分析、排阅读顺序、文字识别。OXR 把阅读顺序判断和内容识别共享同一个多模态识别底座（SigLIP2-NaViT 视觉编码器 + Qwen3-0.6B 语言解码器），识别文字的同时顺带理解上下文语序，一次前向推理出结果。省掉的是串行等待，换来的是端到端速度——下游要的是一份能直接读的 Markdown，不是“识别结果 + 一份单独的阅读顺序标注文件”，把这两步合并，输出本身就是可用的。

第二处减法：版面分析模块解耦，做成可插拔。 OXR 把“框选区域”剥离成一个独立的轻量模型，它只判断“这块是表格还是段落”，不管阅读先后。企业如果版式特殊，单独微调这个轻量模块就行，不需要重训整个底座。据团队说法，OXR 是第一个把版面分析做成独立可插拔模块的文档解析模型。这个选择同样是从下游反推的：不同企业的文档版式差异极大，但“识别”这件事是通用的——把变化的部分隔离出来，下游适配的成本才可控。

这两处减法合在一起的效果，落在数据上是：在单张 RTX PRO 6000 Blackwell（96GB） 上解析从 OmniDocBench 随机抽取的 100 页文档，OXR 平均用时约 101 秒，PaddleOCR-VL-1.6 约 145 秒，MinerU2.5-Pro 约 255 秒。精度榜首和速度榜首，落在了同一个 1.3B 的模型上。

三、RSI 循环：把“错题”变成训练数据——但它有一个可靠性边界

架构决定了 OXR“怎么跑得快”，RSI 决定了它“为什么准”。

文档解析的标注成本是一个无底洞：每一张表格的每个单元格、每一个公式的每个上下标、每一页的阅读顺序决策，都需要人标；而最有价值的样本，恰恰是最难标注的那些“怪页面”。SoMark 的解法是：不靠人标，让模型自己找错题，自己出题。

RSI 循环分三个阶段，一轮一轮重复：

第一阶段：预测与分类。 OXR 解析无标注文档，一个更强的通用视觉语言模型（General VLM）对照原始页面和评判标准，把每个样本分成 正确、错误、不确定 三类。不确定类的信号有两个来源：General VLM 的犹豫，以及 OXR 自己对同一份样本多次解析的结果分歧——分歧越大，越说明模型“拿不准”。

第二阶段：归因与训练规划。 对每一个错误或不确定的样本，General VLM 写下可能的原因，一个样本可以对应多个原因；这些原因被编码、聚类，相似的原因归入同一个 reason cluster。这些簇，就是下一轮训练的计划。

第三阶段：数据生成。 General VLM 写代码，画并渲染出针对每个原因簇的新文档，版式和视觉风格从真实样本中借用，避免生成的数据坍缩成单一模板。只有通过规则校验和过滤的数据才进入训练，全程不需要人工标注。然后循环重来：重训后的 OXR 再解析真实文档，新一轮的错题成为下一轮的起点。

“错误”在这个循环里不是要被隐藏的东西，而是下一轮训练的原材料——这也是 SoMark 技术博客标题 “Errors as Data” 的本意。

需要特别说清楚一点：这里的 General VLM 是一个独立于 OXR 底座的外部裁判模型，不是 OXR 自己使用的 Qwen3-0.6B 解码器。 OXR 负责“做题”，General VLM 负责“判卷”和“出针对性的练习题”，两个角色是分开的。

但这个循环有一个可靠性边界，需要在一开始就点明：整个循环的“裁判”就是那个 General VLM。分类、归因、生成数据，全部依赖它的判断。如果裁判本身在某些文档类型上有偏差，RSI 循环会把这种偏差系统性地放大。 有分析已经提到过“裁判偏差可能被放大”的风险；我想往前推一步的是——偏差和“复利证据缺失”叠加在一起，意味着什么：如果多轮迭代的 repair rate 曲线没有公开，在没有多轮数据的情况下，我们就无法区分“循环在持续产生复利”和“循环只是在把裁判的偏好固化进模型”。这两件事在单次榜单提升里看起来是一样的。

四、数据：三榜第一，但数字有它的边界

根据团队公布的评测结果：

三项均位列第一，且团队表示整套评测流程和代码全量开源可复现。

但读这些数字时，有三件事需要放在心里：

第一，这是团队公布的评测结果，不是完全独立的第三方复现。 有分析明确指出，“三榜第一”和“速度快”目前都来自 SoMark 团队自行公布的评测。这些数字能支持“在该团队设定的测试条件下表现领先”，不足以直接推广为对所有文档、所有硬件配置都成立。

第二，基准分数有覆盖范围。 OmniDocBench 覆盖 10 类复杂文档，olmOCR-Bench 侧重单元测试级硬题，DocParsingBench 覆盖 5 大行业——它们衡量的是这些基准所定义的文档类型和任务，不等于在任意文档、任意语言、任意版面上的可靠程度。

第三，101 秒 vs 145 秒 vs 255 秒的对比，是在同一张 RTX PRO 6000 上的同条件完整解析，这个条件本身是清晰的；但如果换到消费级显卡、或者换一种文档分布，相对速度关系可能变化。

五、冷静评估：1.3B 的工程优势是真实的，RSI 的“复利”还没有被充分证明

它真正做对的事情

它把“文档解析”的目标从“识别精度”重新定义成了“数据可用性”。 13 类元素的结构化输出、阅读顺序与识别合并、版面分析可插拔——这些设计指向的是 Agent 和 RAG 真正需要的东西，而不是 OCR 榜单上的一个小数点。

1.3B 的参数量是一个被低估的工程优势。 据官方部署说明，单卡 24GB 显存可以支撑低并发测试；长文档或更高并发场景，建议 48GB 以上。对于需要私有化部署、数据不出内网的文档场景，这个门槛比“百亿参数、必须上云”要现实得多。

RSI 的方向是成立的。 把错误样本和弱样本作为下一轮训练的依据、用生成数据替代人工标注，这个闭环在逻辑上是自洽的。如果它能在多轮迭代中持续爬升，文档解析的训练成本结构会被实质性改变。

需要警惕的地方

第一，“RSI 复利”的证据仍然停留在设计描述层面。 文章和博客详细描述了循环的三个阶段，但公开材料没有披露各轮迭代的量化提升——一次后训练带来榜单提升，和“循环持续产生复利”是两件事，后者需要多轮数据来证明。

第二，General VLM 作为“裁判”的可靠性，是整个循环的上限。 如第三节所述，如果裁判本身在某些文档类型上判断有偏差，循环会把这种偏差系统性地放大——“自己找错题”的前提是“找错题的人本身足够可靠”，而这个前提没有被独立评估。

第三，可插拔版面分析是灵活性，也是调参成本。 企业可以单独微调版面模型，这降低了适配门槛；但**“微调到一个什么程度算够用、不同版式之间的阈值怎么定”**，仍然依赖工程判断。OXR 提供的是工具，不是自动调好的默认值。

第四，它不是“通用文档智能”的终局。 OXR 的强项在版面复杂、结构密集的文档上；对于纯文本、简单排版的场景，1.3B 的模型和更轻的方案相比是否仍然划算，需要按场景算账。把“三榜第一”读成“所有文档场景都最优”，是一种过度延伸。

六、写在最后

OXR 的真正贡献，不是“1.3B 打赢了更大的模型”，而是把文档解析的训练逻辑从“堆标注、堆参数”，推进到了“让模型自己找错题、自己出针对性的题”。

两处架构减法让它在精度和速度上同时站住，RSI 循环让它在标注成本上找到了一条不同的路。1.3B、单卡 24G 起步、一秒一页、三榜第一——这几个数字放在一起，说明文档解析这个赛道里，“小模型 + 自进化训练”是一条值得被认真对待的路线。

但“自己找错题”能不能持续产生复利，裁判的偏差会不会被循环放大，可插拔的灵活性会不会变成调参负担——这些问题，不在榜单分数里，也不在架构图的箭头上。 OXR 给了一个可运行、可复现的起点，接下来的答案要靠更多人在自己的文档分布上去跑。

如果你身边有人在搭 RAG 管道、被多栏论文和跨页表格坑过，把这篇转给他——不是推荐 OXR，而是帮他看到一个 1.3B 的轻量方案已经走到哪一步了。

💡 文档解析的价值，从来不是“把图变成字”，而是“让下游的 Agent 拿到一份能直接用的数据”。OXR 用 1.3B 和一套 RSI 循环，把这件事的门槛往下压了一截——但“自己教自己”这条路能走多远，取决于它找错题的眼力，能不能经得起别人的文档检验。

🔥 留言区聊两句

我最关心的不是三榜第一，是它那个“自己找错题”的 RSI 循环——如果裁判的偏差被循环放大了，三轮之后错题类型会不会变得单一？有没有人跑过多轮 repair rate 的数据？

• A. 还在用传统 OCR，复杂版面基本靠人工兜底
• B. 已经在用 PaddleOCR / MinerU 这类方案，但速度和精度总有一头不满意
• C. 想试试 OXR 这种“解析 + 结构化输出”的模型，但在等更多独立验证
• D. 还没搭起来，先看看

🔗 参考资料：

• GitHub：https://github.com/SoMarkAI/OXR（Apache-2.0，约 3.7K Stars / 240 Forks，模型权重同步发布于 Hugging Face / ModelScope）
• SoMark Docs《OXR Overview》
• Towards AI《Errors as Data: How RSI Helps OXR Achieve SOTA Accuracy and Speed in Document Parsing》，2026-10-28
• 量子位《OXR强势开源！1.3B横扫全球三榜第一，速度快过Paddle、MinerU，RSI让它卷出新高度》，2026-10-27
• 量子位《RSI立大功！国产开源登顶全球第一，1.3B OXR重塑OCR》，2026-10-30
• Pandaily《SoMark Open-Sources OXR-1.0, a 1.3B Document Parser That Leads Three Public Benchmarks》，2026-10-28
• 奇绩创坛《OXR：1.3B 文档解析模型，全球三榜第一》，2026-10

如果这篇帮你理清了 OXR 在架构和训练上的取舍、以及它那条“小模型 + 自进化”路线的边界——欢迎转发给你正在做文档解析或 RAG 数据管道的同事。