Datalab、文書解析向けオープンベンチマーク「OmniParseBench」を公開

Datalabは、OCRと文書解析のためのオープンベンチマーク「OmniParseBench」を公開した。同社によれば、このベンチマークは1万6,288件のテストを中心に設計されている。PyPIのプロジェクトページとDatalabのブログ記事によると、OmniParseBenchは、単一の参照出力との編集距離を測る方式ではなく、単ページごとに二値のチェックを積み重ねて評価する。実際の各テストでは、ある要素がプロバイダーの出力に含まれているか、正しい順序で現れているか、特定の表セルに入っているか、あるいは特定種類のレイアウトブロック内に存在するかを問う。Datalabはこの方法を、単に一つの好ましい出力様式に一致したかではなく、システムが正しい内容を抽出できたかどうかに評価の焦点を当てるための設計だと説明している。

ユニットテスト型で構成されたベンチマーク

PyPIで説明されている評価プロトコルは、ページ単位の「はい／いいえ」形式のアサーションを中心にしている。1件のテストでは、1つまたは複数の引数を確認でき、それぞれがページ上の特定位置にある内容に対応する。ベンチマークの結果は、「テキスト」「表」「レイアウト」という3つのファミリーにまとめられる。見出しとして提示される総合スコアは、この3系列のスコア平均である。つまり、全体の点数は単純な一枚岩の数値ではなく、少なくとも設計上は、文書のどの側面をどの程度うまく扱えたかを3区分で観察し、その平均を最終値として示す構成になっている。

この設計が重要だと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に基づく言語タグが含まれる。これらのタグ自体が合否を決めるわけではない。むしろ利用者がベンチマークを切り分け、データ部分集合ごとの点数を見るために使われる。1件のテストに複数タグを付けられるため、タグ別スコアは互いに重なり合い、タグ単位の平均を取っても見出しの総合スコアにそのまま戻るわけではない。診断には便利だが、解釈には少し注意を要する設計だと言える。

スコアリングと実行の仕組み

PyPIの説明によると、このベンチマークはHugging Face上で公開されているDatalabのデータセットに対して実行することも、利用者自身のデータセットに対して実行することもできる。また、より低水準のスコアリング機能や予測処理のプリミティブも公開されており、各チームが自前の評価パイプラインに組み込めるようになっている。実行は再開可能であり、各プロバイダー設定はそれぞれ独立した実行として扱われる。プロジェクトの説明では、各実行は1テストにつき1行を持つscores.jsonlファイルを書き出し、集計結果はsummary.jsonから読み取れるとしている。したがって、単発の総合点だけでなく、テストごとの明細に降りて確認する運用が想定されている。

スコアリングは、すべての結果を単純に合格か不合格へ還元するわけではない。PyPIには4種類の判定が挙げられている。

• pass（合格）
• fail（不合格）
• unsupported（プロバイダーが要求された出力を生成できない場合）
• error（プロバイダーの失敗ではなく、採点処理そのものに問題が起きた場合）

方法論上の目立つ選択として、unsupportedとerrorの判定は、失敗として数えるのではなく、すべてのスコア計算から除外される。PyPIによれば、これはプロバイダーがそもそも生成できない出力や、採点側のバグによってベンダーを不当に罰しないための措置だという。他方で、この設計は、システム間比較が各プロバイダーの対応可能な出力タイプに部分的に左右されうることも意味する。ある表現形式を出力できないシステムは、そのテストで0点になるのではなく、対象外として外される可能性があるからだ。したがって、得点の高さが必ずしも対応範囲の広さを示すとは限らず、対応している範囲内での品質をより強く反映する構造になっている。

プロジェクト説明ではさらに、各プロバイダー用アダプターは1回の呼び出しごとに同一のタイムアウトを用い、既定では各プロバイダーのもっとも高精度な設定を使うとしている。Datalabのツール群はベンダーのAPIを呼び出せるが、それらの呼び出しには費用が発生するため、実行前に確認を求める仕組みになっている。パッケージの動作にはPython 3.11以降が必要で、コードはApache 2.0ライセンスで配布される一方、データとテストには出所に応じて混在したライセンスが適用される。つまり、技術的な導入ハードルだけでなく、費用面やライセンス面も実務上の検討事項として残る。

公開されているものと、まだ見えないもの

今回与えられた資料から明確に確認できる公開範囲には、コード、ドキュメント、そしてPyPIでパッケージ化されたベンチマークが含まれる。PyPIはまた、リポジトリ内に、Hugging Face上のDatalabデータセットを使ってベンチマークを走らせる方法、または利用者自身のデータを使う方法が含まれていると説明している。同じページでは、API、ベンチマーク設計、テスト構築、プロバイダー、タグ付けを扱う文書にも利用者を案内している。さらに、誤ったテストを見つけた場合はissueを立てられると明記されており、このことから、ベンチマークは外部から内容を確認でき、必要に応じて修正提案も受け入れる前提で運用されるものだとうかがえる。

ただし、公開資料だけでは、1万6,288件のテストがファミリー別、言語別、文字体系別、あるいは文書種別ごとにどう内訳されているのかという完全な分解までは示されていない。OmniParseBench自体の集計済みリーダーボード結果も含まれていない。したがって、ここで言及される1万6,288件という数字は、ベンチマークの位置付けを示す枠組みの一部として報告できる一方、その合計に至る厳密な配分は、与えられた本文からは追えない。同様に、どのプロバイダーがテキスト、表、レイアウトで優位に立つのかを示す、ベンチマーク全体の性能数値も、今回の出典資料には載っていない。

他のベンチマークをめぐって示された主張

与えられた資料では、OmniParseBenchのリーダーボード結果を公表する代わりに、Datalabのブログは、なぜ同社が既存ベンチマークを不十分だと考えるのかに重点を置いている。同社は、olmOCRは飽和していると述べ、後処理によって報告スコアが1点前後から2点程度動く例を挙げている。また、ParseBenchについては、特にチャートや視覚的グラウンディングに関して、プロンプトの文言、書式の慣習、特殊化されたパイプラインの影響を強く受けうると主張する。これらは中身の重い問題提起ではあるが、あくまでDatalabによる説明として読む必要がある。今回提供された資料には、独立した検証や第三者による再現確認は含まれていない。

それでも、こうした主張は、OmniParseBenchが何を最適化対象にしているのかを理解する助けになる。二値のチェック群は、参照出力との一致度を見る方式よりも、意図的な最適化の対象になりにくいものとして明示的に提示されている。Datalabは、この構造によって、どのテストに失敗したのかが具体的なページ上の具体的な誤りとして対応付けられるため、より明瞭なエラーシグナルが得られるはずだと論じている。たとえば、あるシステムが回転した文字、帳票、手書き、あるいは表構造に弱いのかどうかを、単一の混合スコアだけを見るより把握しやすくなる、というのが同社の考え方である。モデル開発者にも、企業の買い手にも、その点が利点として訴求されている。

公開内容そのものから見える限界

もっとも、OmniParseBenchの設計自体も制約を生む。第一に、今回の資料にはベンチマーク全体の完全な結果が示されていないため、外部の読者は、このベンチマークが従来手法と比べて実質的に異なる順位付けを生むのかを、まだ評価できない。第二に、unsupportedな出力は採点から除外されるため、このベンチマークは、プロバイダーが対応している出力範囲の中での品質を評価しやすい一方で、出力タイプの広さそのものを直接は強く罰しない可能性がある。第三に、タグによる切り分けは設計上重複するため、診断には有用でも、全体要約としての読みやすさや直感的な理解はやや下がりうる。

実務面の制約もある。ベンダーを評価対象に含めるにはAPIキーと有料の呼び出しが必要になる。ベンチマークは再開可能で、実行間比較にも対応しているが、各設定が独立した実行として扱われる以上、再現性はなおプロバイダー設定の違いに左右される余地がある。さらに、データセットには複数の元データ由来の混在ライセンスが引き継がれており、Datalabは上流データセットの引用も必要だと注意している。これらはベンチマークの価値を否定するものではないが、本番の評価ワークフローに組み込む際には、法務面と運用面の確認が必要になることを意味する。

日本の企業や実務チームにとっての具体的な変化としては、OmniParseBenchが、文書AIシステムをページ単位で点検し、表、レイアウト、文字体系、厳しいレンダリング条件ごとに切り分けて確認できる、より検査しやすい評価手段を提供する点が挙げられる。実際には、これによって、各社はベンダー同士や社内モデル同士を、自分たちが本当に重視する文書特性に沿って比較しやすくなる可能性がある。ただし運用にあたっては、どの出力がunsupportedとして扱われているかを確認し、ベンチマークのライセンス条件を点検し、単一の総合スコアだけを文書理解品質の完全な尺度とみなさない姿勢を保つことが重要になる。