パーサーの評価に使用する文書は、組織で日常的に扱われる文書タイプから選ぶ必要があります。テストセットには最低限、以下のものを含めてください。
- スキャン文書： スキャン品質、傾き、ノイズにばらつきのある紙の画像。ここで光学式文字認識（OCR）品質の差が現れ、商用グレードのパーサーとTesseractのようなオープンソースツールの違いが明確になります。
- 複数カラムのレイアウト： テキストを並列カラムで表示する財務レポート、学術論文、ニュースレターなど。カラムの境界を検出できないパーサーは、隣接するカラムのコンテンツを混在させ、事実として整合性のないチャンクを生成します。
- 複雑な表： 罫線なしの表、結合されたセル、複数ページにまたがる表。表をフラット化した出力は、本番環境で最もよく見られるサイレント障害モードのひとつです。
- 多言語コンテンツ： 複数の言語が混在する文書、またはアラビア語、中国語、日本語、韓国語などの非ラテン文字を使用する文書。対応範囲はパーサーによって大きく異なります。ABBYYは208言語をサポートしており、多くのオープンソースツールはこの水準に遠く及びません。
- 長い複数ページの文書： セクション階層が数十ページから数百ページにわたる契約書、技術マニュアル、レポート。改ページをまたいだ読み取り順序と構造的な連続性は、よくある障害ポイントです。
- 不規則な構造： 実際の文書は一貫していません。見出しが予期しない場所に現れます。脚注が本文に割り込んできます。一見構造的に見える文書でも、クリーンな形式でトレーニングされたパーサーを混乱させるような不規則性が頻繁に存在します。
明確で一貫したフォーマットの文書だけでなく、パーサーが構造的な曖昧さをどのように処理するかも評価してください。これらの文書タイプを含む現実的なテストセットがなければ、評価はデモ条件を測定しているに過ぎず、本番の実態を反映していません。
文字レベルの精度、つまり正確に抽出された文字の割合は、パーサーが信頼性の高いRAG検索をサポートできるかどうかをほとんど教えてくれません。文字精度が高くても、下流システムが必要とする情報構造を完全に破壊してしまうパーサーも存在します。
以下の各項目についてテストしてください。
- 構造の保持： 見出し、セクション、文書の階層構造は正確に識別され、ラベル付けされているか。実際の文書構造に沿ったチャンキングは、境界を推測するチャンキングよりも優れた検索結果を生み出します。
- 読み取り順序： 抽出されたテキストは、人間の読者が辿る順序になっているか。複数カラムの文書や複雑なレイアウトは、パーサーが誤った順序でテキストを生成する原因になります。
- 表の忠実度： 行と列の関係が出力に保持されているか。テキスト文字列にフラット化された表は、下流モデルにとって意味をなすための関係性を失ってしまいます。
- フィールドとラベルの関係： フォームや構造化文書において、パーサーはフィールドの値を正しいラベルに紐付けているか。値とラベルの関連付けの誤りは、RAG出力における事実誤認の一般的な原因です。
- 出力フォーマットの有用性： 出力フォーマットは、チャンキングと検索が正確に機能するのに十分なセマンティック情報を持っているか。プレーンテキストは、検索精度を支えるコンテキストを取り除いてしまいます。
ABBYYがIBM、Nvidia、Red Hat、Linux Foundationと共同で策定したオープンなAIネイティブ文書マークアップ標準である
DocLangのような構造化フォーマットは、見出し、段落、表のセル、脚注、フォームフィールドに対してセマンティックラベルを付与します。その構造こそが、出力を真にAI対応のものにします。 /p>
ラボパフォーマンスとは、精選されたベンチマークでパーサーが出すスコアです。実運用パフォーマンスとは、実際の文書に対して、実際の処理量で、実際の制約のもとでどう動くかです。
最も効果的なパーサーとは、多様な文書タイプにわたって効率的かつ予測可能なデータ構造を生成するものです。その評価においては、セマンティック理解を測るために、単純なOCR精度を超えた視点が必要です。
実際に問題を引き起こす評価結果のカテゴリがあります。「ほとんどの文書では十分に機能する」というものです。
問うべきは、パーサーがクリーンな文書を適切に処理できるかどうかではありません。パイプラインの下流に伝播するエラーを生じさせることなく、コーパス全体を確実に処理できるかどうかです。
「十分に良い」は部分的なエラーの複合効果を見落とします。文書コンテンツの98%を正確に抽出しながら、すべての表を常にフラット化してしまうパーサーは、ほとんどのクエリに対して使用可能な出力を生成しつつ、表データを必要とするクエリに対しては完全に失敗する可能性があります。98%という総合精度の数字は、表に依存するクエリにおける100%の失敗率を捉えていません。
そのエラーが重要な財務用語、日付、または免責条項に関わる場合、下流への影響は決して抽象的なものではありません。
だからこそ、ユースケースにとって最も重要な文書タイプと構造的特徴に絞って評価することが重要です。パイプラインが表の抽出に依存しているなら、表の忠実度を特定的に評価してください。多言語文書を処理するなら、言語ごとの精度を評価してください。チャンキングにセクション階層を利用するなら、セクションの境界が正確に識別されているかを評価してください。
難しい文書こそが、パーサーの限界を明らかにします。
直接比較が最も実用的な判断材料を提供します。同じ文書セットを現在のパーサーと評価対象のパーサーの両方で処理し、パイプラインにとって重要な観点から出力を並べて比較してください。
具体的な手順は以下のとおりです。
- ステップ1：50〜100件の文書でベンチマークセットを作成します。 実際のコーパスから、簡単なものではなく複雑で難しい文書を優先してください。
- ステップ2：両方のツールで各文書をパースします。 詳細な評価のために完全な出力を保存してください。
- ステップ3：10〜20件の文書サンプルを選び、構造、読み取り順序、表の忠実度を手動で確認します。 パフォーマンスに最も影響する構造的な障害を明らかにできないため、文字レベルの指標だけに依存することは避けてください。
- ステップ4：文書内に答えが存在する質問セットを用意して検索テストを実施します。 各ツールのパース出力をインデックス化し、検索が正しいパッセージを抽出できるかを評価してください。
- ステップ5：現在のパーサーの出力フォーマットに、チャンキングロジックが正しく機能するのに十分なセマンティック構造が含まれているかを判断するために、出力フォーマットを比較します。 不十分であれば、セマンティックラベリングを持つDocLangのようなフォーマットを検討してください。チャンキングと検索の結果を測定可能なかたちで改善できます。
目標は、リーダーボードで高スコアを出すパーサーを見つけることではありません。特定のパイプラインで、特定の文書に対して、より良い結果を生み出すパーサーを見つけることです。
パーサーの本番環境での限界を理解する最速の方法は、最も困難な文書から試すことです。現在パイプラインで問題を引き起こしているもの。ハルシネーション、破損した表、または乱れた読み取り順序を生じさせているものです。
ABBYYが提供するFineParserを使えば、Dockerコンテナを取得し、すでに問題を引き起こしている文書で実行して、構造化された出力を現在のパーサーの出力と比較することができます。
現在のパーサーが返す結果と、構造を保持するパーサーが返す結果の差異は、どんなベンチマークスコアよりも、パイプラインの信頼性の限界について多くを語ってくれます。
実際の文書でABBYYをテストしてください。アーリーアクセスを受付中です。
