2026年6月24日15 個節點#tech#ai
OCR,重新成為研究課題
2026 年,文件 OCR 為何不再是一樁已解決的標配,小而專的模型、不切頁的長程解析,以及一道再也分不出高下的基準天花板。
完整簡報
多年來,OCR 一直被當作一樁了結的 API 呼叫。2026 年年中,三個版本在一天之內相繼落地,把它重新拉回活躍研究:問題不再是「我們能否讀出文字」,而是哪一種模型形態,小型專家、通用 VLM,還是長上下文解析器,契合某條特定的文件管線。
三種技術押注#
目標相同,架構分岔
Mistral OCR 4、PaddleOCR 的 PP-OCRv6,以及百度的 Unlimited-OCR,瞄準的是同一個結果,卻拉動了不同的槓桿:一個託管的多語言模型、一個參數量不足 3500 萬的端側家族,以及一個 KV 快取恆定的長程解析器。這一分岔,正是故事所在。
Mistral OCR 4#
託管、多語言、懂結構
Mistral OCR 4 以寬廣的語言覆蓋與文件結構化輸出立足,作為一個託管 API,把 OCR 定位為一項有價的服務,而非一個你自己執行的模型。它比拼的是便利,以及表格/版面的保真,而非生字元精度。
open_in_newmistral.ai/news/ocr-4PP-OCRv6#
3500 萬參數以下,覆蓋 50 種語言
PaddleOCR 的 PP-OCRv6 推出一個分級家族,小到足以在端側執行,卻仍覆蓋 50 種語言。它是託管 VLM 的反命題:把偵測與辨識做成一個可嵌入的微小元件,而非一次遠端呼叫。
open_in_newhuggingface.co/blog/PaddlePaddle/pp-ocrv6Unlimited-OCR#
一次成形、不切頁的解析
百度的 Unlimited-OCR 讓 KV 快取保持恆定,以一趟通行解析長文件,而非把頁面切片。它把 OCR 重構為一個長程解碼問題,上下文長度與顯記憶體,塑造著單次前向能讀下多少。
open_in_newgithub.com/baidu/Unlimited-OCR專家模型 對 通用 VLM#
權衡真正發威之處
純文件模型以廣度換取成本與延遲;前沿 VLM 什麼都能讀,卻按 token 計費,且在表格上飄移。這一選擇極少關乎峰值精度,它關乎每千頁的成本,以及輸出如何接入下游解析。
每頁成本#
真正的選擇之軸
通用 VLM 按整張算繪頁面的 token 計費;專家模型只收一筆極小的固定費用。在文件規模上,這一差距是數倍量級,這正是為什麼一個紙面上更遜色的專家,往往拿下生產線上的那個名額。
管線中的落位#
在 RAG/文件堆疊裡,誰該放在哪
OCR 坐落在分塊、嵌入與檢索的上游。在這裡選錯模型,誤差會向下游處處擴散,因此落位的抉擇,事先擷取,還是把 VLM 放進迴路,比單一基準上的一個點更要緊。
事先擷取 對 迴路之內#
兩種整合範式
要麼 OCR 在前端跑一次,把乾淨文字餵進索引;要麼讓 VLM 在智慧體迴路之內,按需讀取頁面。事先擷取更便宜、可快取;迴路之內更靈活,卻要在每次查詢時付出 VLM 的成本。
基準的天花板#
OmniDocBench 正在飽和
當多個模型在同一套件上擠在 90 分以上,排行榜便不再是訊號。有意思的差異轉移到別處:多語言覆蓋、表格與公式上的結構保真,以及每頁幾美元,而這些,單一的飽和分數一個都捕捉不到。
來源與相關
想把這張圖做成真正的系統
讀完簡報之後,下一個問題通常是「那我們該怎麼把它做出來」。Weple 是一家外包開發工作室,擅長把這樣的結構拆成小塊交付。諮詢時把本頁連結一併附上即可。
諮詢開發