MLLM 時代，OCR 真的還有必要嗎？

你有沒有想過，現在的多模態大語言模型（MLLM）已經可以直接「看」文件圖片了，那我們為什麼還要先跑一遍 OCR 再丟給 LLM？這個問題在做文件資訊抽取（Document IE）的工程師心裡大概都閃過。SAP 和 Stanford 的研究團隊決定認真回答這個問題，做了一個大規模 benchmark，結論可能會讓你重新思考現有的 pipeline 設計。

🔍 OCR 一直都是痛點

做過文件處理的人都知道，OCR 這一層帶來的問題不少。掃描品質差、表格排版亂、手寫體辨識不穩定，每一個都是工程上的坑。傳統做法是 OCR 先把圖片轉成文字，再丟給 NLP 模型去抽取欄位。這個兩階段的 pipeline 很直覺，但 OCR 的錯誤會直接傳遞到下游，而且維護兩套模型的成本不低。

現在 GPT-4o、Gemini、Claude 這些 MLLM 都能直接吃圖片輸入，理論上可以跳過 OCR 直接做抽取。但「理論上可以」跟「實際上夠好」是兩回事。到底差多少？在什麼情境下會翻車？這篇論文就是要回答這個。

🛠️ 大規模實測 + 自動化錯誤分析

研究團隊做了幾件重要的事：

第一，他們用的是「真實商業文件」，不是學術界常見的乾淨 benchmark。發票、採購單、收據這些實際場景的文件，排版複雜度和 noise 都比學術資料集高很多。這點很關鍵，因為很多 MLLM 在乾淨資料上表現好，一碰到真實世界就掉鏈子。

第二，他們比較了兩種 pipeline：純圖片輸入（image-only）vs. OCR 文字加圖片（OCR+MLLM）。測了多個主流 MLLM，包括開源和閉源的。結果發現，對於能力夠強的 MLLM 來說，純圖片輸入的表現跟 OCR 增強版「幾乎一樣好」。換句話說，OCR 那一層帶來的增益已經小到可以忽略。

第三，也是我覺得最有價值的部分：他們提出了一個「自動化階層式錯誤分析框架」。這個框架用 LLM 自己去診斷錯誤模式，把失敗案例分門別類。這比人工看 bad case 有效率太多了。分析結果顯示，MLLM 的主要失敗模式集中在幾個特定類型：

• 多值欄位的遺漏
• 格式不一致
• 少數極端排版的誤讀

另外一個有趣的發現：精心設計的 schema 定義、few-shot exemplar 和指令格式，對結果的影響比加不加 OCR 還大。也就是說，prompt engineering 的投資報酬率比維護 OCR pipeline 高。

💡 這對工程實務意味著什麼

我覺得這篇論文的價值不在於「OCR 已死」這種聳動結論，而是幫我們釐清了決策邊界。

如果你用的是 GPT-4o 或同等級的 MLLM，而且文件品質還可以 → 可以認真考慮拿掉 OCR，簡化 pipeline。省下的不只是 OCR 的 API 費用，還有錯誤處理、格式轉換、座標對齊這些工程負擔。

但如果你的場景是低解析度掃描件、或是需要處理大量歷史文件 → OCR 還是有保險的價值。MLLM 在極端情況下的表現仍然不穩定。

坦白說，我比較擔心的是成本問題。純圖片輸入意味著每次都要傳完整圖片給 MLLM，token 用量會比純文字高很多。如果你一天要處理幾萬份文件，這個成本差異不能忽略。論文沒有深入討論這一塊，但在生產環境這絕對是關鍵考量。

還有一點值得注意：「schema 和 prompt 設計比 OCR 更重要」這個發現，其實在暗示 Document AI 的競爭力正在從「誰的 OCR 引擎好」轉向「誰的 prompt 和 schema 設計好」。這對整個產業的能力需求是一個結構性的轉變。

不確定這在所有語言都成立。商業文件的英文表現好，不代表中文、日文、阿拉伯文也有同樣結論。CJK 字元的密度和排版複雜度跟拉丁語系差很多，這方面還需要更多驗證。

你的 Document AI pipeline 現在還在跑 OCR 嗎？也許是時候做個 A/B test 了。

📎 論文連結

你有沒有想過，現在的多模態大語言模型（MLLM）已經可以直接「看」文件圖片了，那我們為什麼還要先跑一遍 OCR 再丟給 LLM？這個問題在做文件資訊抽取（Document IE）的工程師心裡大概都閃過。SAP 和 Stanford 的研究團隊決定認真回答這個問題，做了一個大規模 benchmark，結論可能會讓你重新思考現有的 pipeline 設計。

🔍 OCR 一直都是痛點

做過文件處理的人都知道，OCR 這一層帶來的問題不少。掃描品質差、表格排版亂、手寫體辨識不穩定，每一個都是工程上的坑。傳統做法是 OCR 先把圖片轉成文字，再丟給 NLP 模型去抽取欄位。這個兩階段的 pipeline 很直覺，但 OCR 的錯誤會直接傳遞到下游，而且維護兩套模型的成本不低。

現在 GPT-4o、Gemini、Claude 這些 MLLM 都能直接吃圖片輸入，理論上可以跳過 OCR 直接做抽取。但「理論上可以」跟「實際上夠好」是兩回事。到底差多少？在什麼情境下會翻車？這篇論文就是要回答這個。

🛠️ 大規模實測 + 自動化錯誤分析

研究團隊做了幾件重要的事：

第一，他們用的是「真實商業文件」，不是學術界常見的乾淨 benchmark。發票、採購單、收據這些實際場景的文件，排版複雜度和 noise 都比學術資料集高很多。這點很關鍵，因為很多 MLLM 在乾淨資料上表現好，一碰到真實世界就掉鏈子。

第二，他們比較了兩種 pipeline：純圖片輸入（image-only）vs. OCR 文字加圖片（OCR+MLLM）。測了多個主流 MLLM，包括開源和閉源的。結果發現，對於能力夠強的 MLLM 來說，純圖片輸入的表現跟 OCR 增強版「幾乎一樣好」。換句話說，OCR 那一層帶來的增益已經小到可以忽略。

第三，也是我覺得最有價值的部分：他們提出了一個「自動化階層式錯誤分析框架」。這個框架用 LLM 自己去診斷錯誤模式，把失敗案例分門別類。這比人工看 bad case 有效率太多了。分析結果顯示，MLLM 的主要失敗模式集中在幾個特定類型：多值欄位的遺漏、格式不一致、以及少數極端排版的誤讀。

另外一個有趣的發現：精心設計的 schema 定義、few-shot exemplar 和指令格式，對結果的影響比加不加 OCR 還大。也就是說，prompt engineering 的投資報酬率比維護 OCR pipeline 高。

💡 這對工程實務意味著什麼

我覺得這篇論文的價值不在於「OCR 已死」這種聳動結論，而是幫我們釐清了決策邊界。

如果你用的是 GPT-4o 或同等級的 MLLM，而且文件品質還可以 → 可以認真考慮拿掉 OCR，簡化 pipeline。省下的不只是 OCR 的 API 費用，還有錯誤處理、格式轉換、座標對齊這些工程負擔。

但如果你的場景是低解析度掃描件、或是需要處理大量歷史文件 → OCR 還是有保險的價值。MLLM 在極端情況下的表現仍然不穩定。

坦白說，我比較擔心的是成本問題。純圖片輸入意味著每次都要傳完整圖片給 MLLM，token 用量會比純文字高很多。如果你一天要處理幾萬份文件，這個成本差異不能忽略。論文沒有深入討論這一塊，但在生產環境這絕對是關鍵考量。

還有一點值得注意：「schema 和 prompt 設計比 OCR 更重要」這個發現，其實在暗示 Document AI 的競爭力正在從「誰的 OCR 引擎好」轉向「誰的 prompt 和 schema 設計好」。這對整個產業的能力需求是一個結構性的轉變。

不確定這在所有語言都成立。商業文件的英文表現好，不代表中文、日文、阿拉伯文也有同樣結論。CJK 字元的密度和排版複雜度跟拉丁語系差很多，這方面還需要更多驗證。

你的 Document AI pipeline 現在還在跑 OCR 嗎？也許是時候做個 A/B test 了。

📎 論文連結：https://arxiv.org/abs/2603.02789

#DocumentAI #OCR #MLLM #GenAI #LLM #MultimodalAI