来自小红书超级智能团队的 FireRed-OCR，以仅 20 亿参数的轻量模型，在权威文档解析基准 OmniDocBench v1.5 上拿下端到端方案第一，综合得分 92.94%，超越 Gemini 3.0 Pro、DeepSeek-OCR 2 和 Qwen3-VL-235B。
模型已在ModelScope 开源，感兴趣可以直接体验 Demo 或下载权重本地部署，采用Apache 2.0协议，代码和权重均可商用，无需担心授权问题。
- Model: https://modelscope.cn/models/FireRedTeam/FireRed-OCR
- Demo: https://www.modelscope.cn/studios/FireRedTeam/FireRed-OCR
- GitHub: http://github.com/FireRedTeam/FireRed-OCR
- Technical report：https://github.com/FireRedTeam/FireRed-OCR/blob/main/assets/FireRed_OCR_Technical_Report.pdf
它解决了什么问题？
文档数字化是 AI 落地的重要一环——把 PDF、扫描件、学术论文转成结构化文本，才能喂给下游的 RAG、知识库、数据分析流程。
但通用大视觉语言模型（VLM）在处理复杂文档时，存在一个普遍痛点："结构幻觉"。
什么叫结构幻觉？举几个典型例子：
- 表格行列顺序被打乱，数据张冠李戴
- 数学公式被"创作"出来，凭空多出符号
- 多栏文档阅读顺序混乱，跨栏串行
这不是偶发 bug，而是通用 VLM 的天然缺陷——它们在训练的时候，更加擅长生成语义连贯的文字，但对文档的像素级空间结构缺乏精确约束。
FireRed-OCR 的思路是：把通用 VLM 改造成"结构工程师"，用系统化的训练框架，让模型对格式语法拥有强制约束能力。
核心技术：三阶段渐进式训练
FireRed-OCR 并非简单微调，而是设计了一套完整的三阶段训练流水线：
第一阶段：多任务预对齐
在视觉感知层面建立"空间基础"。模型先学会目标检测、区域识别、版面到 Markdown 的映射，打好空间定位的底子。
第二阶段：专项监督微调（SFT）
在高质量、规范化的 Markdown 数据集上精调，确保输出具备逻辑一致性和层级表达能力。这一步把模型的输出风格统一成标准化结构。
第三阶段：格式约束强化学习（Format-Constrained GRPO）
这是整个框架最核心的创新。GRPO（组相对策略优化）是一种强化学习方法，FireRed-OCR 在此基础上引入了专门的格式奖励信号，覆盖四个维度：
- 公式语法正确性（LaTeX 是否合法）
- 表格结构完整性（标签是否闭合）
- 层级标签闭合性（Markdown 嵌套是否正确）
- 文本准确率（字符级别的识别精度）
简单说：模型每输出一次结果，系统就从这四个维度打分，反馈给模型自我纠正。长期下来，模型"学会了"格式守规矩。
数据引擎同样是亮点
团队还开发了一套"几何 + 语义"数据工厂：用几何特征聚类和多维度标注，合成均衡的训练数据集，专门针对长尾版式（比如奇特的多栏、嵌套表格）做数据增强，解决了真实世界文档分布不均衡的问题。
模型效果
OmniDocBench v1.5（标准文档解析基准）
FireRed-OCR-2B 在端到端方案中排名第一：
要注意的是：PaddleOCR-VL-1.5（94.50%）和 GLM-OCR（94.60%）作为流水线方案（多个专用模型串联）得分更高，这是两类不同的技术路线，FireRed-OCR 是端到端单模型中的最优解。
在文字识别单项（OCRBench TextRec），FireRed-OCR-2B 以 93.5 分位居所有参测模型首位，超过 GPT-5.2（93.0）和 Gemini-3.0 Pro（91.9）。
FireRedBench（复杂版式）
这个是团队自建的"压力测试"基准，专门收录现实中非标准版式的文档（歪斜、复杂多栏、低质量扫描件等）。
FireRed-OCR-2B 以 74.62 分拿下端到端方案第一，同时超越了流水线方案 GLM-OCR（74.33），仅略低于 PaddleOCR-VL-1.5（76.47）。而基座模型 Qwen3-VL-2B-Instruct 只有 65.58 分，提升幅度相当显著。
快速上手
模型基于 Qwen3-VL 架构，接入方式非常标准，几行代码即可跑起来。
安装依赖：
pip install transformers qwen-vl-utils
推理示例：
from modelscope import Qwen3VLForConditionalGeneration, AutoProcessor from conv_for_infer import generate_conv import torch # 加载模型（推荐开启 flash_attention_2 提速） model = Qwen3VLForConditionalGeneration.from_pretrained( "FireRedTeam/FireRed-OCR-2B", torch_dtype=torch.bfloat16, device_map="auto", ) processor = AutoProcessor.from_pretrained("FireRedTeam/FireRed-OCR-2B") # 准备输入 image_path = "./examples/complex_table.png" messages = generate_conv(image_path) # 推理 inputs = processor.apply_chat_template( messages, tokenize=True, add_generation_prompt=True, return_dict=True, return_tensors="pt" ).to(model.device) generated_ids = model.generate(**inputs, max_new_tokens=8192) generated_ids_trimmed = [ out_ids[len(in_ids):] for in_ids, out_ids in zip(inputs.input_ids, generated_ids) ] output_text = processor.batch_decode(generated_ids_trimmed, skip_special_tokens=True) print(output_text)
输出即为标准 Markdown 格式，可直接用于下游处理。
实践和建议
适合的场景
FireRed-OCR 最擅长的是需要结构完整性的文档解析：学术论文（含公式）、财报表格、技术文档、多栏排版的书籍扫描件。如果你的下游任务对"表格不能乱行"、"公式不能出错"要求很高，它是目前端到端方案里最可靠的选择。
case1： 公式识别
Case 2: 手写体识别
硬件配置
2B 参数模型，bfloat16 精度下显存占用约 4-5GB，RTX 3090 / A10 单卡即可流畅推理。如果处理批量文档，强烈建议开启 flash_attention_2，可显著降低显存峰值并提升吞吐。
max_new_tokens 设置
官方示例使用 8192，对于密集型学术论文页面建议保持此值或更高。普通单页文档可以适当降低以加快推理速度。
图像质量影响较大
从 FireRedBench 的得分来看，即使是 FireRed-OCR，面对质量极差的扫描件也会有明显性能下滑（整体降至 74 分左右）。实际使用时，尽量提供 ≥150 DPI 的图像，效果会更稳定。
与流水线方案的取舍
如果对精度要求极致，且有工程资源维护多模型系统，PaddleOCR-VL-1.5 或 GLM-OCR 在标准基准上仍有约 1-2% 的优势。但如果追求部署简单、维护成本低、在复杂版式上表现稳健，FireRed-OCR 是更优解。
小结
FireRed-OCR 是一次漂亮的"专项优化"示范：不靠堆参数，而是靠精心设计的训练框架（三阶段渐进 + 格式约束强化学习 + 几何语义数据引擎），让 2B 小模型在专项任务上打赢 235B 的通用大模型。
这也给行业提了个醒：在垂直任务上，专项训练的效率高于扩大模型规模。
点击即可跳转模型链接
