又一個 OCR 新模型開源了

繼續(xù)聊 OCR，不過這次我覺得重點(diǎn)不只是“識別準(zhǔn)不準(zhǔn)”，而是另一個更容易被忽視、但更影響真實(shí)落地的問題：結(jié)構(gòu)到底對不對。

2026 年 2 月 28 日，F(xiàn)ireRedTeam 放出了FireRed-OCR-2B權(quán)重；2026 年 3 月 2 日，團(tuán)隊(duì)又把技術(shù)報(bào)告掛到了 arXiv。看完論文和模型卡之后，我的第一感覺是：這項(xiàng)目不是在拼“再做一個 OCR”，而是在認(rèn)真解決通用 VLM 做文檔解析時(shí)最煩人的老毛病：結(jié)構(gòu)幻覺。

但是說實(shí)話，識別一些有難度的表格，它還是差點(diǎn)意思，底座2B，不能要求太高。

比如下圖是我隨手截取的招股說明書中一張表格

其中難點(diǎn)：表格無線（不連續(xù)）、表頭嵌套、括號、省略號、縮進(jìn)、空白、繁體字、小字、黑色下劃線，帶換行的合并單元格等各種干擾因素。

表格后半部分的識別就完全垮掉了

還有一個我的專用測試圖（這張圖難點(diǎn)很多）

就單說表格部分也算還行吧，跟 DeepSeek、GLM、混元、Paddle 這幾個 OCR 還是有點(diǎn)差距的。

簡介

一句話講清楚：FireRed-OCR 是一個把通用視覺語言模型，專門訓(xùn)成結(jié)構(gòu)化文檔解析專家的框架。

它的底座是Qwen/Qwen3-VL-2B-Instruct。

但它做出來的結(jié)果很夸張：

• 在OmniDocBench v1.5上拿到92.94分

• 在端到端路線里排第一

• 超過了DeepSeek-OCR 2（91.09）和OCRVerse（88.56）

• 相比原始底座Qwen3-VL-2B（81.87），直接拉開了一個明顯身位

這里我要專門說一句，別被標(biāo)題黨帶偏了。FireRed-OCR 不是當(dāng)前 OmniDocBench 全榜第一。論文和模型卡里給出的數(shù)據(jù)很清楚：如果把 pipeline 方案也算進(jìn)來，GLM-OCR是 94.60，PaddleOCR-VL-1.5是 94.50。FireRed-OCR 真正厲害的地方，是它在end-to-end路線里做到第一，而且只用了一個 2B 級別底座。

現(xiàn)在 OCR 賽道最有意思的事，不再是“誰能看懂文檔”，而是“誰能在小模型、端到端、結(jié)構(gòu)穩(wěn)定這三個約束下，把結(jié)果做漂亮”。

FireRed-OCR 到底想解決什么

如果你這兩年用過通用多模態(tài)模型做 PDF 轉(zhuǎn) Markdown，大概率都有過類似體驗(yàn)：

• 文字識別得八九不離十

• 一到表格就開始錯行錯列

• 一到公式就開始漏括號、少花括號

• 一到復(fù)雜排版，閱讀順序直接亂掉

這就是論文里說的Structural Hallucination。

通俗點(diǎn)說，模型“看懂了個大概”，但它生成出來的不是一個可以直接拿去用的結(jié)構(gòu)化結(jié)果。對于聊天演示，這可能問題不大；但對 RAG、知識庫清洗、PDF 轉(zhuǎn) Markdown、財(cái)報(bào)解析、論文數(shù)據(jù)抽取這些真實(shí)場景來說，這問題很致命。

FireRed-OCR 的思路我很喜歡，它不是繼續(xù)讓模型“憑感覺寫”，而是把方向從“印象派生成”往“結(jié)構(gòu)工程”上硬拉。

下圖就是官方給出的基準(zhǔn)測試結(jié)果，F(xiàn)ireRed-OCR 在端到端方案里確實(shí)很能打：

FireRed-OCR 在 OmniDocBench v1.5 上的性能對比 它做對了哪三件事

我把論文和模型卡里的技術(shù)路線壓縮一下，最值得看的其實(shí)就三件事。

第一件事，是數(shù)據(jù)工廠不是亂采樣。

論文里提了一個很重要的設(shè)計(jì)：Geometry + Semantics Data Factory。

什么意思？以前很多 OCR 數(shù)據(jù)構(gòu)建思路，更多是“多收點(diǎn)數(shù)據(jù)，多做點(diǎn)增強(qiáng)”。FireRed-OCR 不是這么干的。它強(qiáng)調(diào)幾何特征聚類和多維標(biāo)簽，用來合成長尾布局、稀有文檔類型，并且把數(shù)據(jù)分布盡量做平衡。

這件事特別關(guān)鍵。因?yàn)槲臋n解析真正難的，往往不是普通段落，而是那些稀奇古怪的版式：多欄、嵌套表格、公式和文本混排、圖注交錯、掃描噪聲、非標(biāo)準(zhǔn)閱讀順序。這些東西不靠數(shù)據(jù)分布設(shè)計(jì)，光靠模型參數(shù)堆，很難真解決。

第二件事，是訓(xùn)練流程分三步走。

FireRed-OCR 不是一把梭微調(diào)，而是一個三階段漸進(jìn)式訓(xùn)練：

1. Multi-task Pre-alignment：先做檢測、區(qū)域識別、layout-to-markdown 等任務(wù)，讓模型建立空間 grounding

2. Specialized SFT：再用高質(zhì)量標(biāo)準(zhǔn)化 Markdown 數(shù)據(jù)做監(jiān)督微調(diào)，把“完整輸出一頁結(jié)構(gòu)化結(jié)果”的格式穩(wěn)定下來

3. Format-Constrained GRPO：最后上強(qiáng)化學(xué)習(xí)，用格式約束獎勵去卡公式語法、表格閉合、層級閉合和文本準(zhǔn)確性

這個設(shè)計(jì)非常像一個成熟工程團(tuán)隊(duì)會做的事。先讓模型“看得準(zhǔn)”，再讓模型“寫得穩(wěn)”，最后讓模型“別犯結(jié)構(gòu)性低級錯誤”。

第三件事，是它真把“結(jié)構(gòu)約束”當(dāng)目標(biāo)函數(shù)來優(yōu)化了。

這一點(diǎn)我覺得是 FireRed-OCR 最值錢的地方。

很多模型在 OCR 任務(wù)上看起來文字準(zhǔn)確率不錯，但一落到 Markdown 或 LaTeX 輸出，結(jié)構(gòu)錯一點(diǎn)，后續(xù)鏈路就全廢了。FireRed-OCR 直接用Format-Constrained GRPO去獎勵公式語法正確、表格完整、層級閉合，這就等于把“能不能被程序繼續(xù)消費(fèi)”作為訓(xùn)練目標(biāo)，而不是只看表面文本像不像。

這張圖是官方給出的整體架構(gòu)：

FireRed-OCR 三階段訓(xùn)練架構(gòu) 實(shí)驗(yàn)結(jié)果怎么看

論文和模型卡里最亮眼的一組數(shù)據(jù)是：

• OmniDocBench v1.5：FireRed-OCR-2B =92.94

• 文字編輯距離 =0.032

• 公式分?jǐn)?shù) =91.71

• 表格TEDS=90.31

• 表格TEDS_s=93.81

• 閱讀順序編輯距離 =0.041

如果只看端到端陣營，這個結(jié)果確實(shí)很強(qiáng)。

另外還有一個我很在意的點(diǎn)：FireRedBench。這是更偏“野外復(fù)雜文檔”的測試集。FireRed-OCR-2B 在這里拿到74.62，同一個底座Qwen3-VL-2B-Instruct是65.58，DeepSeek-OCR 2是61.61。

這說明它不是只會做 benchmark 特化，至少從官方數(shù)據(jù)看，它在復(fù)雜、不標(biāo)準(zhǔn)版式上也有明顯提升。

當(dāng)然，真實(shí)生產(chǎn)是否穩(wěn)，還得看后續(xù)社區(qū)大規(guī)模實(shí)測。但至少從方法設(shè)計(jì)到指標(biāo)結(jié)果，這個項(xiàng)目是自洽的。

安裝

官方給的安裝方式很直接：

pip install transformers
pip install qwen-vl-utils
git clone https://github.com/FireRedTeam/FireRed-OCR.git
cd FireRed-OCR

模型目前托管在 Hugging Face，模型卡標(biāo)注的 license 是Apache-2.0，底座是Qwen/Qwen3-VL-2B-Instruct。

使用

官方給的是基于transformers的推理方式，輸入文檔圖像，輸出結(jié)構(gòu)化 Markdown。

from transformers import Qwen3VLForConditionalGeneration, AutoProcessor
from conv_for_infer import generate_conv

 model = Qwen3VLForConditionalGeneration.from_pretrained(
    "FireRedTeam/FireRed-OCR",
    torch_dtype=torch.bfloat16,
    device_map="auto",
)

 processor = AutoProcessor.from_pretrained("FireRedTeam/FireRed-OCR")

 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"
)
inputs = inputs.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,
    clean_up_tokenization_spaces=False
)
print(output_text)

官方還特別提到，如果場景里有多圖或者視頻，建議開flash_attention_2，這樣速度和顯存表現(xiàn)會更好。

不過這里也順手提個邊界：目前公開材料里，官方主推的還是 transformers 推理示例。如果你打算直接做大規(guī)模服務(wù)化部署，后續(xù)還得繼續(xù)看社區(qū)有沒有更成熟的 vLLM、SGLang 或 API server 方案。

我的判斷

如果你問我，這項(xiàng)目值不值得跟，我的答案是：值得，而且值得重點(diǎn)看它的方法，不只是看它的分?jǐn)?shù)。

我比較看重它三個判斷：

• 判斷一：通用 VLM 不是不能做 OCR，但必須專項(xiàng)訓(xùn)練。

• 判斷二：OCR 的核心不只是識字，而是結(jié)構(gòu)完整性。

• 判斷三：小模型也能打，前提是數(shù)據(jù)工廠和訓(xùn)練目標(biāo)設(shè)計(jì)得足夠狠。

這其實(shí)也解釋了為什么 FireRed-OCR 會讓我眼前一亮。它不是在講一個“參數(shù)更大所以更強(qiáng)”的故事，而是在講一個更靠譜的工程故事：把任務(wù)定義清楚，把數(shù)據(jù)分布做對，把獎勵函數(shù)卡在真正影響落地的地方。

當(dāng)然，它現(xiàn)在也不是完美答案。

• 從榜單看，它還不是全賽道絕對第一

• 當(dāng)前公開版本主要是 2B 權(quán)重，生態(tài)還在早期

• 真正上生產(chǎn)，還得看社區(qū)對中文文檔、掃描件、票據(jù)、財(cái)報(bào)、超長 PDF 的實(shí)測反饋

但即便如此，我還是覺得這個方向非常對。

制作不易，如果這篇文章覺得對你有用，可否點(diǎn)個關(guān)注。給我個三連擊：點(diǎn)贊、轉(zhuǎn)發(fā)和在看。若可以再給我加個，謝謝你看我的文章，我們下篇再見！