Qianfan-OCR：百度4B参数端到端模型，统一文档OCR与理解
深度解读 OCR 端到端 百度千帆
论文：arXiv:2603.13398 · 2026年3月 · 百度 AI Cloud
一句话：4B参数，OmniDocBench v1.5 端到端第一（93.12），KIE超越Gemini-3.1-Pro和Qwen3-VL-235B
📌 30秒看懂
Qianfan-OCR 是百度推出的 4B 参数端到端文档智能模型，把传统 OCR 流水线（版面检测 → 文字识别 → 语言理解）压缩成一个模型。核心创新是 Layout-as-Thought——用 <think> token 触发可选的版面推理阶段，让端到端模型也能输出 bounding box 和版面结构。在 OmniDocBench v1.5 上拿到 93.12 分（端到端模型第一），关键信息提取超越 Gemini-3.1-Pro 和 Qwen3-VL-235B。
一、OCR的三角困境
当前 OCR 系统面临一个三方矛盾：成本、精度、能力不可兼得。
- 传统 Pipeline（PaddleOCR、MinerU）：低成本高吞吐，但多阶段错误传播，丢失视觉上下文
- 两阶段大模型（PaddleOCR-VL、MonkeyOCR）：精度高，但部署复杂，阶段间误差累积
- 通用 VLM（Gemini、Qwen-VL）：能力全面，但推理成本高，结构化解析弱
工业界的文档处理通常是：检测模型 → OCR 模型 → 单独的 LLM 做理解。这种碎片化架构成本高、难优化、组件间信息丢失严重。Qianfan-OCR 用一个 4B 模型搞定全部。
二、模型架构
Qianfan-OCR 继承自 Qianfan-VL 的多模态桥接架构，三大组件：
🏗️ 架构三件套
① Qianfan-ViT（视觉编码器）：24层 Transformer，AnyResolution 设计动态切 448×448 tile，最多16块，支持 4K 输入。每个 tile 生成 256 个 visual token，单页最多 4096 个 token——这对文档中的小字、密排至关重要。
② MLP Adapter（跨模态桥）：两层 MLP + GELU，把 1024 维视觉特征投射到 2560 维语言空间。简单但够用。
③ Qwen3-4B（语言骨干）：36层，GQA（32 query heads / 8 KV heads），KV cache 减少 4×，32K 上下文窗口。够强（复杂推理）又够小（单 GPU 部署）。
三、核心创新：Layout-as-Thought
端到端 OCR 最大的痛点：丢失了显式版面分析。Pipeline 系统天然有检测模块输出 bounding box，但端到端模型直接输出文本，没有中间结构。
Layout-as-Thought 的工作方式：
- 用户在 prompt 后加
<think>token 触发 - 模型进入思考阶段：生成每个元素的 bounding box、类型标签（25类）、阅读顺序
- 基于这个结构化推理，生成最终 OCR 输出
💡 精妙之处：可选，不是强制
📄 简单文档（纯文本、单栏）→ 不开 think，直接输出，更快更好
📊 复杂文档（多栏、混排公式/表格/图片）→ 开 think，版面推理帮助解析
实验验证了这一直觉：按版面标签熵排序，高熵（复杂）文档用 think 提升明显，低熵（简单）文档不用 think 反而更好。这意味着用户可以根据文档类型智能选择。
🔢 坐标 Token 的效率优化
所有坐标用 <COORD_0> 到 <COORD_999> 的专用 token 表示，一个坐标只占一个 token（而不是 "779" 需要 3 个 token）。Think 输出长度减少约 50%，推理延迟显著降低。一个复杂页面可能有 60+ 个版面元素，这个优化非常关键。
四、训练方法：4阶段渐进训练
| 阶段 | Token 量 | 训练内容 | 可训练模块 |
|---|---|---|---|
| Stage 1 跨模态对齐 | 50B | 图文配对 + 简单 OCR | 仅 Adapter |
| Stage 2 基础 OCR | 2T | 文档 45% + 场景 25% + 描述 15% + 专项 15% | 全参数 |
| Stage 3 领域增强 | 800B | 复杂表格 22% + 公式 20% + 图表 18% + KIE 18% + 多语言 12% + 文档理解 10% | 全参数 |
| Stage 4 指令微调 | 百万级样本 | 全场景指令调优 + 推理增强 | 全参数 |
总训练量 2.85T tokens，在 1024 块百度昆仑 P800 芯片上完成，全流程一周以内。
⚡ Ablation 关键发现
- 跳过 Stage 2 直接做领域增强 → 性能大幅下降（80.07 vs 83.47），通用预训练不可替代
- Stage 3 混合通用数据比纯 OCR 数据好（80.07 vs 75.97），通用数据是正则化器
- 完整 4 阶段比只做 Stage 1+4 提升 +13.02%
6大数据合成流水线
Qianfan-OCR 的训练数据来自 6 条专门构建的数据流水线：
- 📄 文档解析：PaddleOCR-VL 标注，25类版面标签，自动过滤 + 图像增强
- 📊 图表理解：从 arXiv LaTeX 源码提取，TexLive 重新渲染，合成 30万+ 多模态指令样本
- 📋 复杂表格：程序化合成（3-20行列，50+ CSS 主题）+ 真实文档提取 + 双模型一致性校验
- 🔑 关键信息提取：多模型协作标注，硬规则过滤（如"单价×数量=总价"验证），难样本挖掘
- 🌍 多语言 OCR：覆盖 192 种语言，反向合成方法，自动 RTL 检测和字符重塑
- 📐 公式识别：LaTeX 渲染 + 专项增强
五、实验结果
OmniDocBench v1.5 — 端到端第一 🏆
| 模型 | 类型 | Overall ↑ | Text Edit ↓ | Formula CDM ↑ | Table TEDS ↑ |
|---|---|---|---|---|---|
| 🏆 Qianfan-OCR | E2E | 93.12 | 0.041 | 92.43 | 91.02 |
| DeepSeek-OCR-v2 | E2E | 91.09 | 0.048 | 90.31 | 87.75 |
| Gemini-3 Pro | E2E | 90.33 | 0.065 | 89.18 | 88.28 |
| Qwen3-VL-235B | E2E | 89.15 | 0.069 | 88.14 | 86.21 |
| Gemini-2.5 Pro | E2E | 88.03 | 0.075 | 85.82 | 85.71 |
| PaddleOCR-VL 1.5 | Pipeline | 94.50 | 0.035 | 94.21 | 92.76 |
4B 参数 → 超过 DeepSeek-OCR-v2、Gemini-3 Pro、Qwen3-VL-235B。跟顶级 Pipeline（PaddleOCR-VL 1.5）的差距只有 1.38 分。
文档理解 — 图表任务碾压级优势
| Benchmark | Qianfan-OCR (4B) | Qwen3-VL-4B | 最佳 Pipeline+LLM |
|---|---|---|---|
| CharXiv_DQ（学术图表问答） | 94.0 | 81.8 | 0.0 💀 |
| CharXiv_RQ（学术图表推理） | 85.2 | 48.5 | 0.0 💀 |
| ChartQA | 88.1 | 83.3 | 56.8 |
| ChartBench | 85.9 | 74.9 | 17.2 |
| DocVQA | 92.8 | 94.9 | 67.1 |
| ChartQAPro | 42.9 | 36.2 | 20.9 |
🔥 最震撼的结果
所有两阶段 OCR+LLM 系统在 CharXiv 上得分 0.0。因为图表的结构、坐标轴关系、数据点位置在 OCR 文字提取阶段就丢了——这些信息对回答问题至关重要。这直接证明了端到端架构保留视觉上下文的价值。
关键信息提取 — 4B 打赢 235B
| 模型 | 参数量 | Overall Mean | 中文 KIE |
|---|---|---|---|
| 🏆 Qianfan-OCR | 4B | 87.9 | 82.3 |
| Qwen3-VL-235B | 235B | 84.2 | 62.9 |
| Qwen3-VL-4B | 4B | 83.5 | 71.3 |
| Gemini-3.1-Pro | ? | 79.2 | 63.4 |
| Seed-2.0 | ? | 78.0 | 48.9 |
4B 模型打赢 235B 模型（超 3.7 分），打赢 Gemini-3.1-Pro（超 8.7 分）。中文 KIE 尤其突出：82.3 vs Qwen3-235B 的 62.9，差距近 20 分。
通用 OCR — OCRBench 第一
| 模型 | OCRBench | OCRBenchv2 (en/zh) | CCOCR 多语言 |
|---|---|---|---|
| Qianfan-OCR | 880 | 56.0 / 60.77 | 76.7 |
| Qwen3-VL-4B | 873 | 60.68 / 59.13 | 74.2 |
| PaddleOCR-VL | 549 | 18.15 / 40.86 | 45.5 |
六、对行业的启示
🤔 行业视角
Qianfan-OCR 的设计决策对整个文档智能行业都有启发：
- 统一 vs 流水线：传统方案是版面检测 + OCR + LLM 的多阶段组合。Qianfan-OCR 证明一个 4B 模型可以在精度上接近顶级 Pipeline（差 1.38 分），同时具备理解能力
- Layout-as-Thought 的启发：不是非此即彼——可选的版面推理阶段是个聪明的设计。简单文档跳过，复杂文档开启
- 4B 就够了：不需要几十B 甚至几百B 参数就能在文档 OCR 上达到 SOTA，部署友好
- 图表理解的鸿沟：Pipeline 系统在图表 QA 上完全崩溃（CharXiv 得 0 分），"先提取文字再交给LLM"的模式在图表场景有根本性缺陷
- KIE 能力内置：传统方案需要单独的信息提取模型，Qianfan-OCR 用 prompt 就能切换任务
七、局限性与展望
- 没有用 RL：目前全靠 SFT，论文自己说了"未来可以用 RL 增强"。olmOCR 2 已经在用 GRPO，这可能是下一步突破点
- DocVQA/TextVQA 略逊同尺寸通用 VLM：通用理解上牺牲了一点来换 OCR 专精（92.8 vs 94.9）
- 依赖百度自研芯片训练：1024 块昆仑 P800，非 NVIDIA 生态
- 模型未开源权重：只能通过百度 AI Cloud 千帆平台 API 使用，限制了社区研究和复现
八、总结
🎯 要点回顾
- 统一架构：一个 4B 模型 = 版面检测 + OCR + 文档理解 + KIE，消除 Pipeline 的误差传播
- Layout-as-Thought：可选的版面推理阶段，复杂文档开启、简单文档跳过，兼顾精度和效率
- SOTA 端到端：OmniDocBench v1.5 得分 93.12（端到端第一），KIE 超越 Gemini 和 235B 级模型
- 图表理解：端到端 vs Pipeline 的最大优势场景——Pipeline 在 CharXiv 上得分 0
- 4 阶段训练：通用预训练不可跳过，领域增强需要混合通用数据作正则化
论文链接：arXiv:2603.13398 | GitHub：github.com/baidubce/Qianfan-VL