Datalab 發布 OmniParseBench：面向文件解析的開放式基準測試

Datalab 已公開 OmniParseBench。依該公司說明，這是一套用於 OCR 與文件解析的開放式基準測試，整體設計圍繞 16,288 項測試展開。根據 PyPI 專案頁面與 Datalab 部落格文章，這套基準不是把單頁輸出與某一份唯一參考答案做編輯距離比對，而是透過二元檢查來評估單一頁面的結果。實際上，每一個測試都會詢問某個特定元素是否出現在供應商輸出中、是否位於正確順序、是否落在指定表格儲存格內，或是否被放進某一類型的版面區塊中。Datalab 將這種做法描述為：重點放在系統是否擷取到正確內容，而不是是否剛好符合某一種偏好的輸出格式。

以單元測試概念打造的基準

PyPI 上描述的評測流程，核心是頁面層級的「是或否」斷言。一項測試可以檢查一個或多個參數，而每個參數都對應到頁面上某個位置的內容。這套基準把結果分成三大家族：文字、表格與版面配置。對外呈現的主分數，則是這三個家族分數的平均值。

這樣的設計之所以重要，是因為依 Datalab 的說法，較舊的基準測試如今更容易透過格式調整，或針對特定基準進行後處理最佳化來取得較高分。該公司在部落格中主張，一些廣泛使用的替代方案，可能獎勵的是對預期輸出慣例的遵循程度，而不一定真正反映模型底層品質。必須指出，這些批評來自 Datalab 本身，而非本次提供來源中的獨立研究結論；不過，這些說法確實有助於理解該公司為何建立 OmniParseBench，以及為何計畫把它用於自家產品發布時的成績報告。

在涵蓋範圍方面，PyPI 表示每一項測試都會沿著多個維度加上標籤。這些標籤包括結構類型，例如 table、math、form 與 multi_column；呈現條件，例如 handwriting、tiny、rotated 與 degraded；角色類別，例如 heading、caption、footnote、list、code、figure 與 header_footer；另外還有依 ISO 15924 劃分的文字系統標籤，以及依 ISO 639-3 劃分的語言標籤。這些標籤本身不決定某項測試是否通過，而是讓使用者可以切分基準資料、針對子集計分。由於一項測試可以同時具有多個標籤，因此標籤層級的分數彼此會重疊，無法再平均回主分數。

計分方式與執行流程

根據 PyPI 的說明，這套基準可以在 Datalab 放在 Hugging Face 的資料集上執行，也可以套用到使用者自己的資料集上。它也提供較低層級的計分與預測元件，讓團隊能將其接入自身的評估流程。一次執行可以中斷後續跑，而且每一種供應商設定都會被視為獨立的一次 run。專案說明指出，每次 run 都會產生一個 scores.jsonl 檔案，其中每一列對應一項測試；而彙總結果則可由 summary.json 讀取。

計分並非把所有結果都簡化成通過或失敗兩種。PyPI 列出四種判定結果：

• pass
• fail
• unsupported，當供應商無法產生被要求的輸出時
• error，當評分程序本身發生問題，而不是供應商輸出失敗時

其中一項相當值得注意的方法論選擇是：unsupported 與 error 不會被算成失敗，而是直接從所有分數計算中排除。PyPI 表示，這樣做是為了避免因供應商無法產出的輸出形式，或評分器本身的錯誤，而讓供應商被不公平扣分。與此同時，這也代表跨系統比較的結果，可能部分取決於某一供應商支援哪些輸出型態。若某個系統無法輸出某種特定表示形式，相關測試可能會被排除在其分數之外，而不是以零分處理。

專案也表示，供應商轉接器對每次呼叫採用相同的逾時設定，而且預設會使用各供應商最準確的設定。Datalab 的工具可以呼叫各家廠商 API，但在真正送出請求前會要求使用者確認，因為這些呼叫會產生成本。此套件要求 Python 3.11 或更新版本。程式碼以 Apache 2.0 授權發布，而資料與測試則依來源不同採混合授權方式。

哪些內容已公開，哪些尚未公開

從本次提供的來源來看，這次公開發布明確包含程式碼、文件，以及在 PyPI 上封裝好的基準工具。PyPI 也指出，儲存庫內含一種執行方式，可使用 Datalab 放在 Hugging Face 的資料集，或是使用者自己的資料。相同頁面也把使用者導向涵蓋 API、基準設計、測試建構、供應商與標籤系統的文件。此外，頁面還提到，如果使用者發現某項測試有誤，可以提交 issue；這表示該基準被設計成可檢視、也可修正。

然而，現有來源並未提供 16,288 項測試依家族、語言、文字系統或文件類型的完整拆分。來源中也沒有給出 OmniParseBench 本身的總體排行榜結果。因此，本文提到的 16,288 項測試，應理解為此基準自我定位與包裝的一部分；但就本次提供文字而言，並未進一步說明這個總數背後的精確分布。同樣地，來源材料中也沒有整體效能數字，可用來顯示哪些供應商在文字、表格或版面配置項目上領先。

圍繞其他基準提出的結果與主張

在本次提供的材料中，Datalab 並未發布 OmniParseBench 的排行榜結果；相對地，該公司部落格更著重說明它為何認為現有基準不足。公司表示，olmOCR 已經出現飽和現象，並舉例稱後處理就可能讓報告分數變動約 1 到 2 分。它也主張，ParseBench 可能會受到提示詞措辭、格式慣例，以及專用流程的強烈影響，特別是在圖表與視覺定位方面。這些都是 Datalab 提出的實質指控，但閱讀時仍應視為該公司的說法；本次提供的來源中並未附上獨立驗證。

即便如此，這些主張仍有助於理解 OmniParseBench 想優化的是什麼。這套基準的「是或否」檢查，被明確描述為比對參考答案的方式更不容易被鑽漏洞。Datalab 主張，這種結構應能產生更清楚的錯誤訊號，因為每一次失敗都對應到特定頁面上的某一個具體錯誤。對模型開發者與企業採購方而言，這可能使他們更容易看出某個系統究竟是在哪些面向有困難，例如旋轉文字、表單、手寫內容，或表格結構，而不只是看到一個混合後的單一分數。

從發布內容本身可見的限制

OmniParseBench 自身的設計，也同時帶來一些限制。第一，本次提供的來源沒有展示完整的基準級結果，因此外部讀者目前還無法判斷，這套基準產生的排名是否與較舊替代方案有實質差異。第二，由於 unsupported 輸出會從計分中排除，這套基準可能更獎勵供應商在其已支援輸出範圍內的品質，而不是獎勵輸出型態的廣度。第三，標籤切片依設計彼此重疊，這對診斷問題很有用，但也可能讓摘要結果的解讀變得較不直觀。

此外，實務上也存在若干約束。若要測試各家廠商，就需要 API 金鑰，且每次呼叫都可能產生費用。雖然這套基準支援續跑，也能跨多次 run 比較，但由於每一種供應商設定都被視為獨立 run，可重現性仍可能隨設定不同而出現差異。最後，資料集承襲了來源不一的混合授權，而 Datalab 也指出，上游資料集同樣應被引用。這並不必然削弱該基準的價值，但確實表示：若企業要把它導入正式的生產評估流程，可能仍需先完成法務與營運層面的審查。

對以英語為主的企業使用者而言，比較具體的變化在於：OmniParseBench 提供了一種更容易檢視的方式，可逐頁測試文件 AI 系統，並依表格、版面、文字系統與困難呈現條件等面向切分，而不是只得到一個不透明的總分。實務上，這可能有助於團隊比較不同供應商或內部模型在自己真正重視的文件特徵上的表現；但在使用時，仍應一併確認哪些輸出被標記為 unsupported、檢視基準的授權條款，並避免把任何單一主分數視為文件理解品質的完整衡量。