百度 Unlimited OCR 2 發布：長文件跨頁辨識怎麼做？從架構、部署到繁中驗收

一份掃描合約有上百頁時，讓電腦辨識每頁的字，只是整理文件的第一步。表格可能從上一頁接到下一頁，頁尾有註解，章節標題也可能離內容隔了好幾張紙。

如果系統只把每頁當成互不相關的圖片，即使每個字看起來都讀對了，後續整理出的表格和閱讀順序也可能出錯。人工仍得翻回原始檔，確認哪一筆資料屬於哪個段落。

百度在 2026 年 10 月 27 日發布 Unlimited OCR 2，聚焦多頁與長文件解析，並同步公布用來測試長文件的 MarathonDocBench。官方模型卡標示 MIT 授權，專案也提供程式範例與模型權重。

模型權重是訓練完成後保存的核心參數，部署時需要下載或由服務提供者載入，才能讓模型處理輸入資料。

這次的重點是讓模型處理一組有順序的頁面，並利用跨頁資訊產生結果。它試圖解決的不只是「圖片裡寫了什麼」，還包括長文件資訊如何銜接。

官方稱，新設計會把部分文字與影像之間的注意力資訊濃縮成固定大小的工作參照，讓文件變長時，每一步解碼所需的時間與記憶體趨於穩定。這是公司的技術說明，不能直接解讀成整份文件的總處理時間固定。

對台灣團隊而言，更實際的問題是：繁體中文、直式文字、跨頁表格和掃描瑕疵能否在自己的文件中正確處理？下面先從長文件的困難開始，再看模型設計、部署和驗收。

為什麼長文件 OCR 不能只看單頁辨識率？

OCR 通常指將圖片中的文字轉成可處理文字。文件解析還要處理標題、段落、欄位、表格與閱讀順序。兩者有關，但不能因為文字被轉出來，就認為完整文件的結構也已經正確。

想像一份採購清單跨越兩頁：第一頁留下品項與數量，第二頁才出現小計與備註。如果辨識系統沒有保留上下文，下一頁的數字可能被當成新的表格，原本的列與欄就會錯位。

法律文件也有類似問題。第十二條可能在一頁最下方開始，例外條件卻接在下一頁最上方。單頁結果即使都能閱讀，把兩頁拆開存檔後，也可能讓查詢系統把條文和限制分離。

這不表示每一種跨頁問題都能交由模型自動解決。模型仍可能漏字、重複或誤判層級。輸入順序、掃描品質與輸出格式也都會影響最後結果。設計驗收時，應同時檢查文字、頁碼與結構。

把文件看成有順序的整體

傳統逐頁流程有一個優點：每頁出錯時容易定位，也比較容易重新處理單一頁面。缺點是跨頁關係要另外靠規則、標題比對或人工重新接回來。

Unlimited OCR 2 的多頁方式，則讓一個請求接收多張依順序排列的頁面影像。官方文件表示，模型可以利用跨頁內容，並在輸出中保留對應每一頁的標記。這提供了另一種處理方式，但輸出仍需要比對原始頁面。

實務上可以先把文件分類：單頁收據、數頁表單和數百頁報告的需求不一樣。短文件不一定要用最複雜的流程。真正值得測試跨頁能力的是表格、註腳和條款經常延續的資料。

Unlimited OCR 2 的 SR-SWA 解決什麼問題？

多模態模型讀取文件時，要同時處理頁面影像和產生的文字。頁數增加後，系統需要保留和查找更多資訊，執行時間與資源壓力可能隨之上升。

百度將新方法稱為 Sparse Reference Sliding Window Attention，簡稱 SR-SWA。官方模型卡說明，它會把超長序列中部分文字與影像的注意力互動壓縮成固定大小的工作參照，舉例為 512 個 token。

可以把工作參照想成處理文件時留下的一組精簡提示，而不是把所有已看過的資訊都原封不動地放在手邊。模型以這些資訊輔助後續步驟，目的是控制長序列造成的運算負擔。

這個比喻只幫助理解，並不代表模型真的像人一樣理解文件，也不能據此推定它一定保留了每個頁面細節。當原文有精密數字、罕見專有名詞或跨很遠頁面的引用，是否足夠保留要由測試回答。

每一步趨於穩定，不等於總時間不變

官方的說法是，每一步解碼的延遲與記憶體占用可隨文件長度保持近似穩定。解碼是模型逐步產生輸出的過程。一份文件若有更多內容，仍可能需要更多步驟才能完成。

因此，不能把「每一步較穩定」改寫成「一百頁與一頁的總時間相同」。整份文件還有影像載入、頁面處理、輸出長度、排程與儲存等成本，實際結果會因系統和設定而異。

比較速度時，可以固定同一批文件，記錄頁數、影像解析度、輸出長度、硬體、處理設定與總耗時，再和原本流程比較。若只引用單一最佳數字，卻沒有相同的文件和環境，團隊很難判斷自己的成本。

多頁文件如何輸入，又如何核對輸出？

官方範例的多頁介面稱為 infer_multi。使用時先把頁面轉成圖片，依原始順序交給模型。文件說明輸出會為每個輸入頁面提供一個 <PAGE> 標記，順序與輸入一致。

這個設計讓後續系統有機會將辨識結果對回原頁，但頁面標記本身不是正確性的保證。標記數量一致，只能協助檢查分頁對應，不能證明某一頁的文字或跨頁表格都沒有遺漏。

例如，一份十頁報價單輸出十個頁面標記後，仍應抽查每頁的供應商名稱、日期與總價。若某頁是空白頁或只有印章，也應確認流程沒有把它錯誤當成缺頁，或憑上下文補出不存在的內容。

官方文件區分單頁與多頁範例的影像處理方式：單頁範例預設使用動態切分，多頁範例則將每頁編碼為一個全頁視圖。圖片被縮放後，細小文字與複雜表格是否清楚，需要用實際影像確認。

團隊可以把原始檔、頁面圖片、模型輸出和校對紀錄關聯起來。發現錯字時，不必只看一段純文字，而能直接回到原頁位置。對需要追蹤修改的人來說，這通常比一次產出很長的 Markdown 更重要。

官方十頁視窗是什麼？會限制文件只能有十頁嗎？

在官方提供的 SGLang 部署文件中，長文件處理包含頁面視窗設定，範例將每個視窗設為十頁。視窗是處理流程的一個批次範圍，不等於整份文件只能包含十頁。

官方說明也提到跨視窗沿用前一段的部分快取。這能幫助系統把前面處理過的資訊帶入後續流程，但帶入什麼、在不同設定下能保留多少細節，不宜只憑「有快取」三個字做結論。

官方同時指出，縮小頁面視窗可降低峰值記憶體，代價是跨過視窗邊界的內容區塊可能失去上下文，影響跨頁合併。是否採用較小視窗，應把記憶體與跨頁正確性一起衡量。

例如，第十頁結尾開始一個表格，第十一頁繼續列出價格，剛好跨越預設視窗邊界。驗收時就應特別檢查欄位名稱是否仍能對上、合併儲存格是否正確，以及兩頁是否被錯接成同一筆。

文件也提供調整視窗和其他參數的方式。不同設定可能改變速度、記憶體與結果。在正式採用前，應記錄設定版本，並用相同樣本測試，而不是把官方範例值視為所有環境的最佳值。

如果需要調整，最好一次只改少量條件，先確認結果差異，再擴大測試。尤其是涉及帳務、契約或醫療資料的流程，能重新處理特定頁面與保留原始證據，比追求一次完全自動化更容易查錯。

MarathonDocBench 的成績代表什麼？

百度同步發布 MarathonDocBench，作為長文件解析的評測資料。官方模型卡也列出 MPDocBench 等測試，並表示 Unlimited OCR 2 在長文件基準取得領先表現。

這些是模型開發團隊公布的測試與主張。MarathonDocBench 由同一團隊發布，能提供研究者比較的方法，但不能直接當成與開發方無關的獨立驗證。測試資料、模型設定和計分方式都應一起閱讀。

評測集的平均分數也不會自動回答台灣企業最在意的問題。假設一個系統整體分數不錯，但報價單金額常出錯，或把直式繁體中文的順序讀反，對該工作來說仍可能不合適。

建立自己的測試集時，可以先按文件類型抽樣，再記錄文字正確性、表格結構、頁序和重要欄位。例如總價錯一個數字，影響可能比一般段落漏掉一個標點更大，兩者不應只用同一平均分數掩蓋。

若要和現有供應商比較，應給各系統相同的來源文件、相同的輸出要求及相同的成功標準。也要保留處理失敗、逾時與人工修正時間，避免只統計成功案例而低估真正成本。

Unlimited OCR 2 如何部署？硬體與授權先看這些

官方程式範例列出 Python、相關套件版本，並指出測試環境使用 NVIDIA A800 80GB。這是官方測試條件，不代表所有文件都必須使用這張卡，也不能反過來保證任意消費級電腦都能順利執行。

官方 Transformers 範例要求載入遠端自訂程式碼，SGLang 範例使用客製化套件。部署前應檢視來源、固定版本並在受控環境測試，才知道實際執行了哪些程式。

模型權重大小只是系統需求的一部分。影像載入、暫存資料、輸出長度、同時處理的文件數及部署框架都會影響資源使用。計畫本機部署時，應先用目標文件量測峰值記憶體與處理時間。

官方也列出 Hugging Face、ModelScope、示範空間與百度雲服務。各入口的帳號條件、可用地區、方案和費用可能不同，使用前應查當時頁面。模型可下載，不代表所有雲端服務永久免費。

模型卡標示 MIT 授權，但實際使用仍應核對當前權重、程式碼與相依元件的條款。官方發布的圖片或影片是另一種素材，不能只因模型卡標示 MIT，就假設全部宣傳媒體都可自由轉載。

處理客戶合約或內部文件前，還要確認資料會送到哪裡、誰能存取、結果保存多久。選擇本機部署可以改變資料流向，但權限控管、備份和刪除流程仍要由使用者建立。

繁體中文與表格怎麼驗收？先做一輪小樣本

第一步，選能代表日常工作的文件，而不只選畫質最好的範例。可以包含清楚的電腦列印稿、傾斜掃描、低解析度照片、雙欄排版與跨頁表格，並先取得有權使用的樣本。

第二步，將原文與人工確認結果配對。繁體中文文件可特別檢查相似字、姓名、公司名稱、地址及日期。直式文字要確認閱讀順序。模型卡沒有提供本文所需的台灣繁中實測結果，因此這些都是建議測試項目，不是已驗證能力。

第三步，對照每一頁的輸入與輸出。除了檢查頁碼和標記，也要抽查圖片中的小字、印章附近文字、頁首與頁尾，避免系統把看不清的部分當成已經確認的內容。

第四步，把跨頁資料作為獨立測試。選幾個跨頁表格、延續條款與遠距引用，確認標題、數字與備註是否保留關係。如果模型把資料寫成可讀的 Markdown，仍要檢查列和欄的對應，而不能只看表格是否漂亮。

第五步，量測後續人工修正。把一份文件處理得很快，若校對人員必須花更多時間重新核對，就未必能降低總工作量。應記錄處理耗時、錯誤類型、修正時間與無法判定的項目。

最後，為重要欄位保留人工覆核。尤其是金額、身分資訊或契約條款，文字辨識可以加快整理，但不應單獨取代原始文件。真正可用的流程，是發現問題後能追溯、修正並重新驗證。

延伸閱讀：Indra OCR 百萬參數模型解析：每秒 49 頁，中文掃描與手寫能用嗎？

延伸閱讀：OpenDocRouter 上線：一個介面切換文件 AI，便宜解析與可信資料怎麼取捨？

常見問題

Unlimited OCR 2 可以處理繁體中文嗎？

本文尚未取得針對台灣繁體中文、直式排版與手寫的獨立測試結果。若這些是主要用途，應以實際文件建立測試集，逐頁檢查辨識與閱讀順序。

官方十頁視窗代表只能辨識十頁嗎？

不是。十頁是官方部署範例中每個處理視窗的設定。長文件可跨視窗處理，但視窗銜接處的表格和條款仍應驗證。

開放權重就代表可以免費使用雲端 API 嗎？

不能這樣推論。API 是讓程式呼叫服務的介面。模型卡標示 MIT 授權，雲端服務的方案、價格、地區及條款則應以使用時的服務頁面為準。

資料來源

• 百度 Unlimited OCR 官方專案
• Unlimited OCR 2 官方模型卡
• MarathonDocBench 官方資料集
• 百度官方 X 發布貼文