国产开源登顶全球第一，1.3B OXR 登顶三榜：RSI 闭环重塑文档解析

1.3B OXR 登顶三榜：RSI 闭环重塑文档解析

目录

• 一、它解决的真问题
• [二、概念澄清：OXR 不是又一款 OCR](#二、概念澄清：OXR 不是又一款 OCR)
• 三、架构拆解：一次前向完成识别与排序
• [四、RSI 闭环：文档解析首次自我进化](#四、RSI 闭环：文档解析首次自我进化)
• [五、与主流 OCR 方案的真实差距](#五、与主流 OCR 方案的真实差距)
• 六、现在就上手
• 七、冷静视角：哪些地方还没被验证
• 总结

2026年10月21日，国产团队 SoMark 开源了 1.3B 参数的文档解析模型 OXR（Optical Everything Recognition），在 OmniDocBench、olmOCR-Bench、DocParsingBench 三个基准上同时拿到第一。它最值得关注的不是参数规模，而是一套叫 RSI 的后训练闭环------让模型自己纠错、自己造数据，不再依赖人工标注。对做文档智能化、RAG 预处理、票据与论文解析的开发者来说，这意味着一条更便宜的落地路径。更重要的是，它的训练方式把"人工标注"这个长期瓶颈打开了缺口，值得单独拆开看。

一、它解决的真问题

把一份 PDF、扫描件或论文变成机器能吃的结构化数据，是很多系统的第一公里。RAG 在把文档喂给大模型之前，必须先做解析；解析质量直接决定召回质量，一份被错位的表格可能让检索召回完全跑偏。金融研报、法律卷宗、科研论文、药品说明书，这些文档的共同点是"版面复杂 + 信息密度高"，传统方案要么漏结构、要么把公式和图表拆散，喂进大模型后反而制造噪声。

为什么传统 OCR 管线在复杂版面下会崩？因为传统 OCR 只回答"字在哪、是什么字"，不回答"表格怎么还原成可编辑结构、公式怎么变成 LaTeX、多栏文章怎么排阅读顺序"。一旦遇到多栏论文、带公式的教材、跨页表格、化学结构式，规则拼接的管线就会错位、漏读或把结构打散。OXR 要解决的正是这一层，而不是再去卷"单字识别率"------后者在印刷体场景早已不是瓶颈。对企业来说，真正贵的从来不是识别几个字，而是把成堆的历史文档整理成能检索、能引用的结构化仓库。

举个具体场景：一份二十页的科研论文里夹着带编号的公式、跨页的对比表格和参考文献，传统三段式管线往往把公式识别成乱码、把表格拆成碎片，最终进 RAG 的是一堆无法对齐的文本块，检索时要么召回不到、要么召回错页。OXR 这类端到端解析的目标，就是让"丢进 PDF、拿出可引用结构"成为一条可靠链路，而不是每次都要人工补一遍。这也是为什么文档解析被视为 RAG 工程里最容易藏短板、却最值得先修好的一环。

二、概念澄清：OXR 不是又一款 OCR

先把两个常被混用的概念拆开。OCR（光学字符识别）的输出是"字符 + 坐标"；文档解析（Document Parsing）是在 OCR 之上还原结构：表格、公式、阅读顺序、版面语义。OXR 属于后者，且明确覆盖 13 类文档元素，包括文本、表格、公式、代码块、化学式、结构式等。一个常见的认知偏差是以为"OCR 精度够高就行"------精度高只解决"字对"，解决不了"结构对"，你能识别每一个字，却还原不出一张跨页表格的行列关系，下游还是用不了。

另一个误区是把它当成"又一个通用大模型"。它本质是文档解析专用模型，不是用来对话的基座模型，调用方式和能力边界都和聊天模型完全不同，拿它去写代码或闲聊是找错工具。还有一个容易被忽略的点：很多人把"文档解析"和"版面检测"画等号，其实版面检测只是其中一环，OXR 的卖点恰恰是检测之后的识别、排序、结构化一站式完成，省去了自己把多个模型串成流水线的工作量。换个角度理解：如果你今天用"检测器 + 表格识别模型 + 公式识别模型 + 排序规则"拼 pipeline，OXR 相当于把这套组合压缩成了一个可调用的模型。省下的不只是运维，还有各模块之间格式对齐的隐性成本------表格识别吐 HTML、公式识别吐 LaTeX、排序规则吐坐标，三个输出要再自己缝合，而这种缝合恰恰是线上最容易出 bug 的地方。

三、架构拆解：一次前向完成识别与排序

（图一：OXR 的流水线把版面分析、内容识别、阅读顺序与结构化输出串成一条端到端链路。）

OXR 的架构有两个值得记下的设计点。第一，版面分析（LA）是一个独立、可插拔的模块，用户可以换成 YOLO、Detectron 等任意检测器，和主模型解耦------换检测器不需要重新训练模型，这对已经在用某个检测器的团队很友好。第二，OXR 主模型在一次前向里同时完成"内容识别（Recognition）"和"阅读顺序（RO）"，省掉了容易错位的事后拼接后处理，这也是它比"检测器 + 识别模型 + 排序规则"三段式更稳的原因。

第三方实测对它的视觉编码器做了解构：视觉侧是 SigLIP2，语言侧是 Qwen3-0.6B，整体走视觉语言模型路线。识别出的 13 类元素会直接转成可用格式：表格转 HTML/LaTeX、公式转 LaTeX、化学式转 mhchem、结构式转 SMILES、代码块原样保留。这对科研、制药、票据这类"文档里混着公式和图表"的场景尤其有用------过去要接三四个独立模型才能拼出的结果，现在一次前向就拿到了，不仅省算力，也少了环节之间出错的机会。选视觉语言模型而非纯检测路线的原因，在于公式、化学式、结构式这类"语义型元素"靠坐标框不出来，必须理解内容才能正确转录------框出一块区域很容易，但把它转成合法的 LaTeX 或 SMILES 需要语义。SigLIP2 负责把图像编码成视觉表征，Qwen3-0.6B 负责把表征解码成结构化文本，两者配合让 1.3B 的小参数也能覆盖宽谱元素。阅读顺序这一步在论文和教材里尤为关键：多栏排版如果按坐标从上到下机械扫描，读出来的句子是乱序的，OXR 把它做成模型输出的一部分，比事后用规则重排更稳，也更能应对那些"看起来像单栏、实际嵌套多栏"的版式。

四、RSI 闭环：文档解析首次自我进化

（图二：RSI 三阶段闭环------预测与分类、归因聚类、数据生成与回流，滚动迭代。）

OXR 真正的差异化在训练侧，而不是推理侧。它用了一套 RSI（Recursive Self-Improvement，递归自我改进）的后训练闭环，分三个阶段：模型先对每类元素的识别结果自动分成"正确 / 错误 / 不确定"三类；再把错误和不确定样本按根因聚类，定位是标注缺失、分布偏移还是样本歧义；最后按根因自动合成针对性训练数据，回流再做一轮后训练。

RSI 真的能替代人工标注吗？在"数据自举"的意义上，它能显著减少人工重新标注的量------闭环滚得越多，模型自己产出的修正数据就越多。但"减少"不等于"清零"：根因定义、合成数据质量把关仍然需要人参与，否则错误可能在闭环里被自我强化。文档解析领域把 RSI 放进后训练闭环，据公开技术说明这是首次，价值在于把标注成本从线性变成递减，让小团队也能养出一个持续变好的解析模型，而不必每次都回头找标注公司。需要强调，RSI 不是"模型自己偷偷变强"的魔法。三阶段里每一步都有可观测的信号：哪些样本被标成不确定、根因聚类出了哪几类、合成数据的分布长什么样，这些都应该被记录下来用于审计。否则一旦闭环开始强化错误，问题会藏得很深。把 RSI 当作一个需要监控的训练流程，而不是一键增强按钮，才是稳妥的用法。

五、与主流 OCR 方案的真实差距

（图三：OXR 在三个独立基准上的得分，三项全部第一。）

先看基准。OXR 在 OmniDocBench 拿到 97.18、olmOCR-Bench 87.84、DocParsingBench 87.76，三项均居第一。速度上，官方基准里它解析 100 页用了 100.972 秒（单张 RTX PRO 6000，21 个模型中第一；第二是 OvisOCR2 的 134.778 秒）。第三方在 4090 24G 上的实测吞吐约 618 token/s，对比同场被拿来参照的 PaddleOCR-VL-1.6 约 527 token/s。

把同赛道几条路线摆在一起看会更清楚：

维度	OXR（SoMark）	PaddleOCR-VL 系列	百度 Unlimited OCR 2
参数量	1.3B（从零预训练）	多尺寸，社区成熟	3B 总参 / 500M 激活
代表基准	OmniDocBench 97.18 / olmOCR-Bench 87.84 / DocParsingBench 87.76	第三方实测约 527 token/s	MarathonDocBench 77.06 / MPDocBench 84.59
速度 / 吞吐	100 页 100.972s（RTX PRO 6000 第一）；4090 实测 618 token/s	4090 实测 527 token/s	同周发布，强调长文档一致性
授权	Apache 2.0 衍生，营收<200万美元免费	开源	开源
已知短板	生僻字、跨页表、竖版待提升	复杂结构一般	新发布，生态待观察

事实层面，OXR 在公布的三项基准和单次吞吐上都占优；我的判断是，这种优势能否平移到你的真实文档，取决于你的版面和语种分布，不能只看榜单数字。百度在 2026年10月27日（与 OXR 发布仅隔几天）开源了 Unlimited OCR 2，强调长文档与多页一致性，说明赛道正在快速升温，第一的位置可能不会坐太久。它的参数规模更大（3B 总参 / 500M 激活），在 MarathonDocBench 拿到 77.06、MPDocBench 84.59，定位偏向长文档场景，和 OXR 形成了"小而精"对"大而全"的错位。

它的速度和精度到底比 PaddleOCR 强多少？单看实测吞吐，OXR 约 618 对 527 token/s，领先约 17%；但 PaddleOCR 系列胜在生态成熟、工业部署案例多、中文场景沉淀久。选型时要把"榜单第一"和"我的场景稳不稳"分开看，榜单第一不代表你的竖版发票就一定能解析对，后者才是决定你接不接的关键。落到选型，我的建议是先按文档类型分：如果你的场景是论文、教材、研报这类"结构复杂但单页可控"的文档，OXR 的小而精路线更划算，推理成本和接入难度都低，三榜第一的成绩在这些场景里最能直接兑现；如果是动辄上千页的合同、卷宗、年报，百度 Unlimited OCR 2 主打的长文档与多页一致性可能更贴近需求，尽管它的公开基准分数还没追平 OXR。两条路线不一定二选一，很多团队会把 OXR 当默认解析器，只在遇到超长文档时切到长文档专用模型，用组合而不是押注来覆盖全场景。顺便说一下速度数字怎么读。OXR 的 100.972 秒解析 100 页，平均到每页约一秒出头，这对"上传一份文档、等几秒拿结果"的交互场景完全够用；但对"每晚批量解析十万页"的后台任务，单卡吞吐就要认真算账，必要时多卡并行。吞吐 618 token/s 这个数字要看清楚单位------它是视觉语言模型逐 token 生成结构化文本的速度，和纯 OCR 的"字符每秒"不是一回事，跨模型比较时口径要对齐，否则容易被表面的高数字误导，拿到生产里才发现瓶颈在别处。

六、现在就上手

OXR 同时给了候补制和本地两条入口，读者当下就有路可走。想先试效果，可以走官方免费 API（free-oxr.somark.cn/api/v1，申请 key 后调用，存在限流）；想自己掌控数据，直接拉开源仓库（GitHub 上的 SoMarkAI/OXR、HuggingFace 上的 SoMarkAI/OXR-1.0），用 vLLM 插件或官方 Docker 镜像本地起服务。对数据敏感的企业，本地部署这条路径几乎是必选项，省下的数据出域风险比算力成本更重要。

OXR 现在能直接用在我的项目里吗？对"文档进、结构化出"的 pipeline 来说，可以。下面是一个最小可跑的 API 调用示例：

# 调用 OXR 免费 API（需先到 free-oxr.somark.cn 申请 key）
import requests

resp = requests.post(
    "https://free-oxr.somark.cn/api/v1/parse",
    files={"file": open("paper.pdf", "rb")},
    data={"return_format": "html"},   # 也可选 latex / json
    headers={"Authorization": "Bearer <YOUR_KEY>"},
    timeout=120,
)
print(resp.json()["result"])   # 结构化 HTML / LaTeX 结果

本地起服务则更接近生产部署，适合做批量解析或接入自有系统：

# 用 vLLM 插件本地启动（需先装官方 oxr-vllm 插件与 NVIDIA 驱动）
python -m vllm.entrypoints.openai.api_server \
  --model SoMarkAI/OXR-1.0 --served-model-name oxr-1.3b

环境要求：NVIDIA 显卡与配套驱动；显存占用随模型规模而定，社区实测在 24G 显存（如 4090）上可以跑通推理。如果你的文档量很大，建议先用免费 API 跑一小批样本确认效果，再决定是否投入本地算力------避免一上来就买卡，结果发现你的文档类型刚好踩在它的短板上。批量解析时建议先把输出落盘成 JSON 再转业务格式，别在调用链里实时拼接，否则某一页解析异常就可能拖垮整批任务。免费 API 有额度限制，生产环境务必走本地部署，并把模型服务与业务服务分开扩容------解析是计算密集型的，和在线推理抢同一张显卡会互相拖慢。另外，第一次接入先拿一百页真实文档做回归，重点看表格还原率和公式准确率，这两个指标比综合榜单更能反映你业务的体感。

七、冷静视角：哪些地方还没被验证

讲完亮点，也要把边界摆清楚。第一，第三方实测明确指出，生僻字、跨页表格、竖版排版这几类仍是短板，复杂真实文档未必能复现榜单表现。第二，RSI 闭环滚到第三、第五轮之后会不会饱和甚至退化，目前没有公开的长周期数据，长期质量仍待观察，不能假定"越多轮越好"。第三，许可证是 Apache 2.0 的衍生版本，营收低于 200 万美元可免费商用，超出门槛需另行授权，商业项目要提前算清账，别等到营收过线才想起补授权。第四，"登顶三榜"是特定基准上的结果，不等于所有真实业务场景都第一；同周竞品发布也提示这个第一很可能被快速追平。第五，开源不等于零成本，本地部署要算上显卡、运维和后续微调的人力，小团队尤其要先把投入产出算明白。还有一个现实考量：OXR 开源时间尚短，社区示例、预置脚本和踩坑帖都还少，遇到部署问题多半要自己读源码，这和 PaddleOCR 那种"搜一下就有答案"的成熟度还有差距，排期紧的项目要预留这部分调试时间。

总结

OXR 的核心价值不在"1.3B 参数"这个标签，而在两件事：一是 RSI 后训练闭环第一次进入文档解析，把人工标注从线性成本变成递减成本；二是它开源、可本地部署、三榜第一，给文档智能化、RAG 预处理、科研与票据解析的开发者一个低门槛的新选项。如果你正在被复杂版面和公式表格折磨，现在就可以用免费 API 或本地镜像跑一份自己的文档验证；同时建议盯紧同周发布的 Unlimited OCR 2 等竞品，看这场文档解析的精度赛跑会怎么演化，再决定把哪条路线放进你的生产系统。需要提醒的是，文档解析这个细分赛道过去两年融资和开源都不少，OXR 的领先是阶段性的；真要进生产，建议把"可替换"当成架构原则，别把业务绑死在单一模型上，哪天基准被反超也能平滑切换。