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

2026 年 2 月 28 日，F(xiàn)ireRedTeam 放出了FireRed-OCR-2B權重；2026 年 3 月 2 日，團隊又把技術報告掛到了 arXiv?？赐暾撐暮湍Ｐ涂ㄖ?，我的第一感覺是：這項目不是在拼“再做一個 OCR”，而是在認真解決通用 VLM 做文檔解析時最煩人的老毛?。?strong>結構幻覺。

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

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

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

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

還有一個我的專用測試圖（這張圖難點很多）

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

簡介

一句話講清楚：FireRed-OCR 是一個把通用視覺語言模型，專門訓成結構化文檔解析專家的框架。

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

但它做出來的結果很夸張：

• 在OmniDocBench v1.5上拿到92.94分

• 在端到端路線里排第一

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

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

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

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

FireRed-OCR 到底想解決什么

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

• 文字識別得八九不離十

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

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

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

這就是論文里說的Structural Hallucination。

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

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

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

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

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

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

論文里提了一個很重要的設計：Geometry + Semantics Data Factory。

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

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

第二件事，是訓練流程分三步走。

FireRed-OCR 不是一把梭微調，而是一個三階段漸進式訓練：

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

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

3. Format-Constrained GRPO：最后上強化學習，用格式約束獎勵去卡公式語法、表格閉合、層級閉合和文本準確性

這個設計非常像一個成熟工程團隊會做的事。先讓模型“看得準”，再讓模型“寫得穩(wěn)”，最后讓模型“別犯結構性低級錯誤”。

第三件事，是它真把“結構約束”當目標函數(shù)來優(yōu)化了。

這一點我覺得是 FireRed-OCR 最值錢的地方。

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

這張圖是官方給出的整體架構：

FireRed-OCR 三階段訓練架構 實驗結果怎么看

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

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

• 文字編輯距離 =0.032

• 公式分數(shù) =91.71

• 表格TEDS=90.31

• 表格TEDS_s=93.81

• 閱讀順序編輯距離 =0.041

如果只看端到端陣營，這個結果確實很強。

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

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

當然，真實生產是否穩(wěn)，還得看后續(xù)社區(qū)大規(guī)模實測。但至少從方法設計到指標結果，這個項目是自洽的。

安裝

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

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

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

使用

官方給的是基于transformers的推理方式，輸入文檔圖像，輸出結構化 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ī)模服務化部署，后續(xù)還得繼續(xù)看社區(qū)有沒有更成熟的 vLLM、SGLang 或 API server 方案。

我的判斷

如果你問我，這項目值不值得跟，我的答案是：值得，而且值得重點看它的方法，不只是看它的分數(shù)。

我比較看重它三個判斷：

• 判斷一：通用 VLM 不是不能做 OCR，但必須專項訓練。

• 判斷二：OCR 的核心不只是識字，而是結構完整性。

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

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

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

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

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

• 真正上生產，還得看社區(qū)對中文文檔、掃描件、票據(jù)、財報、超長 PDF 的實測反饋

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

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