すべてのページをVisionモデルに送るのはやめよ：Citigroup、EY、NVIDIAの研究者が明かす実践的教訓

エンジニアリングチームが検索拡張生成（RAG）向けのドキュメントパイプラインを構築する際、議論はほぼ決まって「どのモデルを採用すべきか」という比較対決になりがちです。Gemini 3.1 Proを呼び出すべきか？ ページをMistral OCR v3にルーティングすべきか？ それともGranite-Doclingのようなコンパクトなモデルを使うべきか？

Abbas Raza Ali（Citigroup）、Muhammad Ajmal Siddiqui（Ernst & Young）、Moona Zahid（NVIDIA）による論文Smart Content Ingestion for Generative AI Workloadsは、こうした議論に本番環境ならではの冷徹な現実を突きつけています。2026年10月5日にプレプリントとして公開された本論文は、現在MLSys 2027の査読中です。

計10,507ページに及ぶ180件の社内ドキュメントコーパスでの測定結果に基づき、著者らは取り込みアーキテクチャを設計する上で指針となる2つの数値を提示しています。

1. 最速の構成では、抽出の実時間（wall-clock time）の約77%が共通の前処理に費やされた。 画像補正とレイアウト解析に約2,062秒が費やされたのに対し、Mistral OCRの推論時間は611秒でした。最も遅い構成でも、Granite-Doclingの推論は約1,350秒かかり、前処理が抽出時間全体の約60%を占めていました。
2. 約92%のページがネイティブ抽出ルートを選択した。 10,507ページ中、ページ単位のOCRが必要となる画像面積の閾値を超えたのは853ページのみでした。残る9,654ページはモデルコストがほぼゼロのネイティブ抽出パスを通り、抽出された図表のみが必要に応じてVisionモデルによるキャプション生成に回されました。

あらゆるドキュメントを無差別にVision APIに送り込んでいるなら、本アーキテクチャは別のアプローチを示唆しています。直接アクセス可能なテキストコンテンツをまず抽出し、ページ単位のOCRは画像が支配的なページに限定するという手法です。ドキュメントの取り込みは単なるプロンプトエンジニアリングの課題ではありません。本論文では、上流のパースエラーが下流の検索に必要な情報を失わせかねない「4段階のシステムパイプライン」として捉えています。

エージェント型システムの認識層

従来の機械学習において、データ準備は狭い範囲に限定され、スキーマに縛られていました。タスク、データ表現、ラベル、モデルアーキテクチャが密結合していたのです。

生成AIはその関係性を変滅させました。基盤モデルは自然言語の指示とコンテキストを通じて、多様な下流タスクをこなします。モデル側が汎用化する一方で、データ側には独自の課題が生じました。企業のナレッジはPDF、スライド資料、スプレッドシート、スキャン文書、帳票、表、ダイアグラムなどに分散して存在しているのです。

これらのファイルには、テキスト、視覚情報、幾何学的配置、構造的情報が単一の成果物の中に詰め込まれています。もし取り込みパーサーが2段組のドキュメントを行ごとにインターリーブして平坦化してしまったり、財務諸表内の関係性を損なったりすれば、下流のコンポーネントには破損した表現が渡されることになります。ベクターリトリーバーはインデックスに存在しない情報を確実に復元することはできませんし、リランカーは抽出段階で失われた列の配置を修復することはできません。

著者らは、測定可能なコンテンツ抽出をエンタープライズ向けエージェントシステムの「認識層（perception layer）」と位置づけています。下流での推論は、この境界において元のソースを正確に表現できているかどうかにかかっている、というのが彼らの主張です。

本論文では、以下の4つの連続するフェーズに分割された本番アーキテクチャが提示されています。

• フェーズ1：マルチモーダルコンテンツ抽出（Multimodal Content Extraction）：選択的OCRルーティングとヒューリスティックなネイティブ抽出を組み合わせる。
• フェーズ2：キュレーションと抽出評価（Curation and Extraction Evaluation）：マルチラベル・希少性優先サンプリングを用いて、グラウンドトゥルースに対するパーサーの精度を監査する。
• フェーズ3：構造を考慮した親子チャンキング（Structure-Aware Parent-Child Chunking）：検索単位と閲覧コンテキストを分離する。
• フェーズ4：読み取り専用の検索評価（Read-Only Retrieval Evaluation）：根拠に基づいた合成質問を生成し、検索性をテストする。

この設計は、「セマンティクスより先に構造を捉える（structure before semantics）」「測定対象を決して変更しない（never mutate what you measure）」「ラベルに予算枠を設ける（budget your labels）」という3つのエンジニアリング原則に基づいています。

選択的ルーティング：大半のトラフィックをPyMuPDFで処理する

フェーズ1における効率化の中核となる洞察はシンプルです。直接アクセス可能なコンテンツはOCRを使わずに抽出し、画像領域のヒューリスティックを用いて、画像主体のページのみをVisionモデルにルーティングするというものです。

入力される各PDFページ $p$ に対して、システムは画像面積のカバレッジ比率を計算します。

$$r(p) = \frac{A_{\text{img}}(p)}{A(p)}$$

埋め込み画像の総面積 $A_{\text{img}}(p)$ がページ総面積 $A(p)$ の80%（$\tau_{\text{cov}} = 0.8$）を超える場合、そのページはOCRにルーティングされます。それ以外の場合は、PyMuPDFによるネイティブ抽出パスにとどまります。

著者らによる180件のドキュメントからなるOrionデータセットでは、10,507ページ中853ページ（8.1%）がOCRルートに進み、残る91.9%がネイティブ抽出に従いました。これはOrion上で観測されたルーティング割合であり、一般的なエンタープライズ文書全体に対する推定値ではありません。

これとは別に、キュレーションエンジンはスキャンページをラベル付けする際に2つのシグナルを用いたテストを適用します。

$$s(p) = 1_{|T(p)| < \kappa ;\wedge; r(p) > \tau_{\text{cov}}}$$

$\kappa = 40$ の場合、スキャン済みラベルが付与されるには、高い画像カバレッジに加えて抽出可能な文字数が40文字未満である必要があります。これにより、大きな写真がありつつも十分なテキストレイヤーを持つページが、キュレーション時に誤ってスキャン文書とラベル付けされるのを防ぎます。なお、これは抽出ルーターの面積のみに基づくルールを変更するものではありません。

画像主体のページに対して、論文ではオプションの画質補正シーケンスを記載しています。枠線除去、ラプラシアン分散によるノイズ推定（Gaussian、バイラテラル、またはNon-Local Meansフィルタの選択）、コントラスト制限適応ヒストグラム平坦化（CLAHE）、アンシャープマスキング、および3次補間アップスケーリングです。ラスタライズされたページはOCRバックエンドに送られます。推論インフラには、429/5xx応答に対するリトライおよびバックオフ処理や、401応答時のOAuth2トークン更新機能が含まれています。

ディープラーニングを用いない決定論的レイアウト再構築

ネイティブテキストのページにおいて、構造再構築ステージでは学習済みモデルを使用しません。代わりに、以下のような決定論的ヒューリスティックに依存します。

• フォントサイズのキャリブレーション（Font size calibration）：エクストラクターはドキュメント全体における最頻値のフォントサイズ $f^$ を算出し、それを標準の本文テキストとして扱います。$f \ge 1.12 f^$ を満たす異なるフォントサイズを見出し候補とし、これらを降順にソートして設定された階層の深さに応じたMarkdownの見出しを出力します。
• ヘッダー・フッターの抑制（Header and footer suppression）：ページマージン内のテキストブロックを検査し、「Page 4」と「Page 9」が同一キーを共有するように数字を正規化した上で、全ページの50%以上で繰り返し出現する一致したマージンコンテンツを除外します。
• 2段階の表検出（Two-tier table detection）：罫線のある表はPyMuPDFの lines_strict を用いて検出します。テーブル戦略が auto に設定されている場合、単語を行にクラスタリングし、X軸のアライメント許容値を用いて列をグループ化することで、罫線のない表も検出します。なお、ガード処理により、表のように見える横並びの散文が誤検出されるのを防ぎます。
• 行単位の重複調整（Line-granularity reconciliation）：検出された表と重複するテキストブロック全体を一括で破棄するのではなく、パイプラインは各行を個別にテストします。行の面積の50%以上が表の矩形内にある場合のみその行を抑制し、表の断片と同じテキストブロックを共有しているだけの近接した文章を保持します。
• ラスター画像の重複排除（Raster de-duplication）：$32 \times 32$ ピクセルを超える埋め込みラスター画像はMD5ハッシュを用いて重複排除され、## Figure-{page}.{n} のような図表プレースホルダーで表現されます。残ったプレースホルダーに対してVisionモデルによるキャプション生成がトリガーされます（アーキテクチャではGemma-3やLlama-4-Scoutなどのモデルが示されています）。

フェーズ1の出力は、明示的な ### Page: N や表、図のマーカーを保持したタグ付きMarkdownとなります。ネイティブな構造再構築とVisionモデルによるキャプション生成は、このプロセス内で明確に区別された別個の処理です。

希少性の罠：データの90%がテキストである場合の抽出監査

抽出されたMarkdownを埋め込みモデルに流し込む前に、エクストラクターが正しく機能したかどうかを知る必要があります。ここで登場するのがフェーズ2のデータキュレーションと抽出評価です。

エンタープライズのリポジトリ全体でドキュメント抽出を評価する際、厄介なサンプリング問題に直面します。大半のページがプレーンテキストである場合、ランダムサンプリングを行うとスキャンページやダイアグラム、インフォグラフィックのサンプル数が極端に少なくなり、抽出品質を評価できなくなってしまいます。出現頻度の低いモダリティを評価セットに意図的に含める必要があります。

著者らはこれを、1ページあたり複数のラベルを持つカバリング問題として定式化しています。分類体系（タキソノミー）には、Scanned（スキャン）、Text（テキスト）、Table（表）、Diagram（ダイアグラム）、Graph/Infographic（グラフ/インフォグラフィック）、Photo/Signature（写真/署名）のカテゴリが含まれます。

総予算 $N$ ページに対して各モダリティの目標割り当て数 $t_m = \lceil \phi_m N \rceil$ が与えられたとき、アルゴリズム1は希少性優先の貪欲ヒューリスティックを適用します。

1. 各モダリティを目標割り当て数の昇順でソートする。この順序は設定された目標値に基づくものであり、必ずしもコーパス内での実際の出現頻度とは一致しない。
2. 対象モダリティについて、候補ページを有用性スコア（helpfulness score：そのページが同時に満たす他の未達目標の数）によってランク付けする。
3. そのモダリティの目標が未達であり候補が残っている間ページを選択し、一致するすべてのラベルの不足数を更新する。
4. ページ予算に達するまで未選択ページで補充するか、有用性の低い選択を間引き、目標カバレッジと達成カバレッジを報告する。

この手法はヒューリスティックであり、すべての割り当てを完全に満たせることを保証するものではありません。選択されたページは、独立した単一ページPDFとして、またはコンテキストが重要な場合はソースドキュメント全体としてエクスポートできます。設定、選択結果、統計情報、達成された分布は6枚のシートからなるワークブックに記録されます。その後、抽出サンプルに対して正解（グラウンドトゥルース）のデジタル化と人手による検証が実施されます。

テキストと表の忠実度のスコアリング

評価ハーネスは、Unicode NFKC、ケースフォールディング（小文字化）、句読点および合字の統一、MarkdownとHTMLの除去、空白の圧縮によってテキストを正規化します。そして、レーベンシュタイン距離による文字誤り率（CER: Character Error Rate）および単語誤り率（WER: Word Error Rate）を計算するとともに、適合率（Precision）、再現率（Recall）、F1、Bag-of-Words F1、平滑化BLEU-4、および長さ比率 $(|\hat{c}| / |c|)$ を算出します。

この長さ比率は、コンテンツの過剰生成や欠落の可能性を検知します。ただし、それ単体では余分なテキストが重複によるものかハルシネーションによるものかまでは特定できません。

表に対しては、Tree Edit Distance-based Similarity（TEDS）を用いた構造比較が追加されます。パイプ区切りテーブルやHTMLテーブルは矩形グリッドにパースされ、ツリー（table -> row -> cell）としてモデル化されます。報告される類似度は次の形式を取ります。

$$\text{TEDS}(T_a, T_b) = 1 - \frac{\text{EditDist}(T_a, T_b)}{\max(|T_a|, |T_b|)}$$

これにより表の構造が測定され、説明されているコンテンツ依存モードではセル内の文字列の違いも評価されます。

最後に、複合スコア（$Q_m \in [0, 100]$）を用いてバックエンドがランク付けされます。

$$Q_m = 100 \cdot \frac{\sum_j w_j \mu_{j,m}}{\sum_j w_j} \cdot \text{cov}_m$$

各指標は精度重視に調整され、設定可能な重みを用いて統合されます。変数 $\text{cov}_m$ は、モデルが出力を生成した想定ファイル数の割合を表します。欠落したファイルはスコアを比例して低下させ、難解なドキュメントの処理をスキップするエンジンに対して明示的にペナルティを与えます。

得られる結果は設定可能な評価スコアであり、正しく抽出されたコンテンツの絶対的な割合ではありません。

親子チャンキング：大きなフォルダーの中に小さなカードを収める

フェーズ3ではチャンキングを扱います。論文では、互いにトレードオフの関係にある2つの失敗パターンが説明されています。

• 大きなチャンク：埋め込み表現において関連する箇所の寄与度を希釈してしまう可能性があります。論文の平均プーリング（mean-pooling）近似では、文の数が増えるほど関連する1文の寄与度が低下します。
• 小さなチャンク：回答が細切れのピースに分断され、個々のピースが検索マッチングで低いスコアしか取れなくなる恐れがあります。

本アーキテクチャでは、検索単位とコンテキスト単位を切り離すことでこのトレードオフに対処しています。

検索される単位は**子（Child）です。約320トークンをターゲットとし、通常の散文では512トークンを上限とするコンパクトなインデックスカードです。コンテキストの単位は親（Parent）**です。最大3,500トークンに設定された構造的なフォルダーです。なお、これらは絶対的な制限ではありません。長すぎる単一の文やアトミックな表・図は丸ごと保持され、巨大な表や図は親の上限を超えることもあります。

子はGTEによって埋め込みベクトル化され、L2正規化された上で、厳密内積インデックス（IndexFlatIP）を用いてFAISSにインデックスされます。親は parent_id から親テキストへのKey-Valueマップに保存されます。

クエリ時には、ベクトル検索によって子カードが取得されます。子を取得済みの親へと展開するには、1回の $O(1)$ ルックアップで済みます。なお、この計算量はコンテキストの取得に関するものであり、ベクトル検索全体やクエリ全体の計算量ではありません。

Document Markdown
       │
       ▼
[Parent Section Folder: configured maximum 3,500 tokens]
       │                                      (Key-Value Store)
       │
       ├──► Child Card 1: target ~320 tokens (FAISS Index)
       │      Optional prefix: "Doc > Section > Subsection (p.4)"
       │
       ├──► Child Card 2: target ~320 tokens (FAISS Index)
       │      Optional prefix: "Doc > Section > Subsection (p.4)"
       │
       └──► Child Card 3: whole atomic table (FAISS Index)

4つのパッキングルール

pack_sentences() 内での文のパッキングは、以下の4つのルールに従います。

• ルール1（トークン予算）：GPT-2トークナイザーを用いて約320トークンをターゲットとし、通常の散文パッキングでは512トークンを上限とする。
• ルール2（文の保持）：文の途中で決して分割しない。末尾の引用符や括弧を保持しながら句読点で分割する。1つの文が上限を超える場合は、切り詰めるのではなく独立したチャンクとして出力する。
• ルール3（端数の排除）：パッキングされたグループが最小トークン閾値を下回る場合、合算サイズが上限内に収まるなら前のチャンクの重複しない文へとマージする。
• ルール4（アトミックな表と図）：パッカーが表や図に遭遇した際、保留中の散文をフラッシュし、通常のトークン予算を超える場合であっても構造単位全体を1つの子として出力する。

次の文を含めると上限を超えてしまうためにチャンクを終了する場合、システムは末尾の完全な文から最大48トークンを次のチャンクへと引き継ぎます。

LLMによる書き換えを行わずに位置コンテキストを付加するため、オプションのパンくずリスト（breadcrumbs）が各子の埋め込みテキストの先頭に Document > Title > Section > Subsection (p.N) という構造アドレスを付与します。プレフィックスのない元のテキストは、表示用として別途保持されます。

検索精度の監査：読み取り専用評価器による25,050問の質問テスト

フェーズ4では RetrievalEvaluator によってパイプラインの検証を完結させます。「測定対象を決して変更しない（never mutate what you measure）」という原則に従い、ハーネスは faiss.IO_FLAG_READ_ONLY を使用してインデックスを開きます。インデックス作成時に使用されたものと全く同一のGTE埋め込みフィンガープリントおよびページタグ構文が再利用されます。

評価器は、設定された最小トークン数以上を含むページに対して、Mistral-Mediumを用いて根拠に基づいた合成質問を生成します。そのプロンプトは、特定の事実レベルの質問と、ページ全体のコンテンツを要約する広範な質問を要求し、生のJSON形式を指定し、外部知識の混入を禁止しています。これらの指示は生成を制約するものですが、生成されたすべての質問が妥当であるかを個別に証明するものではありません。

各質問はGTEを用いて埋め込みベクトル化され、FAISSの IDSelectorBatch を用いて元のソースドキュメント内を検索されます（セレクターがサポートされていない場合は網羅的フィルタリングへのフォールバックが適用されます）。取得された子は parent_id ごとに重複排除され、親ごとに最もスコアの高い子が保持されます。検索では重複しない異なる親を返せるように、候補を余分にフェッチ（over-fetch）します。

候補となる子がコサイン類似度の閾値 $s(q, c) \ge \theta$ をクリアし、そのソースページが質問の発生元から1ページ以内（$\delta = 1$）に収まっている場合に「ヒット（hit）」として記録されます。

$$\text{hit}(q, c) = 1_{s(q, c) \ge \theta ;\wedge; |\pi(c) - \pi(q)| \le \delta}$$

Orionコーパスにおいて、評価器は180件のドキュメントにわたり25,050問の質問を生成・評価しました。

• hit@1: 68.58%
• hit@3: 82.30%
• hit@5: 87.66%
• hit@10: 92.77%
• 平均逆順位（MRR: Mean Reciprocal Rank）: 0.7745
• 順位中央値（Median Rank）: 1.0（平均順位: 1.81）
• 評価対象の全順位でヒットしなかった質問数: 1,810件（7.2%）
• クエリごとの平均レイテンシ: 0.81秒（リモート埋め込み呼び出しが大半を占めると報告されている）

3分の2以上の質問が、最初に返された親の段階で評価器のヒット基準を満たしました。10個の異なる親まで広げると、その割合は92.77%に達しました。

これらは検索の代替指標による結果です。この基準は類似度とページの近接性をチェックするものであり、個別にラベル付けされた正確な対象セクションや生成された回答の正しさを検証しているわけではありません。また、検索はソースドキュメント内に限定されているため、これらの数値はコーパス全体から適切なドキュメントを見つけ出す能力を測定したものでもありません。

抽出ベンチマーク：大規模バックエンド対コンパクトモデル

著者らは4つの商用/本番向けバックエンドの抽出スコアを報告しています。これらの測定値は社内コーパスに対するシステム独自の評価器によるものであり、独立した公開リーダーボードではありません。

Model	Composite Score ($Q_m$)	Character Error Rate (CER)	Word Error Rate (WER)	Table Similarity (TEDS)	Inference Time on Orion	Total Wall-Clock Time on Orion
Gemini 3.1 Pro	97.37	0.13%	0.13%	0.9952	Not separately reported	Not separately reported
Mistral OCR v3	95.98	1.39%	1.55%	0.9737	~611 s	2,672.67 s
Granite-Docling (258M)	92.92	2.60%	2.90%	0.9599	~1,350 s	3,411.86 s
SmolDocling (256M)	90.70	4.43%	4.82%	0.9274	Not separately reported	Not separately reported

Note: Extraction wall-clock totals include approximately 2,062 seconds of shared preprocessing, described as image enhancement and layout parsing. The paper places the other two back-ends between the reported timing extremes without giving their individual times.

Gemini 3.1 Proは報告された精度ランキングで首位となり、CER 0.13%、TEDSスコア 0.9952を記録しました。

Mistral OCR v3は複合スコア95.98で2位となりました。CERは1.39%とGeminiより約1桁高かったものの、報告された抽出時間の中では最速を記録しました。そのモデル推論部分は約611秒であり、Granite-Doclingの約1,350秒と対照的です。

コンパクトモデルであるGranite-DoclingとSmolDoclingは、複合スコアでGeminiにそれぞれ約4.5ポイント、6.7ポイント及びませんでした。報告されたCERはそれぞれ2.60%と4.43%、TEDSスコアは0.9599と0.9274でした。これらは全体の統合ベンチマーク結果であり、平易な本文テキストや特定の難易度の表を個別に測定したものではありません。

論文では、画像テーブルにおいて85%の単語精度を報告した従来のCNN表検出およびEncoder-Dual-Decoderセル抽出の研究も引用されています。これは歴史的なコンテキストを提供するものですが、提示された結果は同一条件のデータセット比較に基づくものではなく、その従来システムに対する厳密な改善度合いを算出できるわけではありません。

なぜ重要なのか：本番ドキュメントパイプラインにおける現実的なトレードオフ

企業向け検索やエージェント型ワークフローのためのドキュメント取り込みパイプラインを構築しているエンジニアリングリードやプロダクトマネージャーにとって、本論文は運用上の実践的な教訓をいくつかもたらしてくれます。なお、本論文の評価は主に英語文書を対象としており、多くのOCR/VLMモデルにとって最大の難所となる漢字・かな混じり文や縦書きレイアウトといった日本語特有の課題は検証範囲外である点には留意が必要です。

1. 最も安価なOCR呼び出しとは、「行わない」呼び出しである

選択的ルーティングにより、Orionのページの91.9%がページ単位のOCRパスを回避できました。これは自社のドキュメントでも検証してみる価値のある具体的な成果です。

これは総コストが91.9%削減されたという意味ではありません。ネイティブ抽出にも処理コストはかかりますし、図表のキャプション生成でVisionモデルが呼び出されることもあります。論文ではページあたりの料金や導入前後の請求額比較までは示されていません。得られる教訓はより限定的です。すなわち、「直接アクセス可能なテキストに対して、自動的にページ単位のOCRを適用する必要はない」ということです。

2. 共通前処理はレイテンシ予算において考慮に値する

図4は抽出時間の内訳を明確に示しています。Mistral OCRの推論時間611秒に対し、共通の画像補正とレイアウト解析には約2,062秒が費やされました。

これにより、前処理は最速の構成で抽出実時間の約77%、最も遅い構成でも約60%を占めることになります。著者らはこれを次の最適化ターゲットとして位置づけています。

この測定結果は、CPU使用率、シリアル実行の有無、あるいは特定のマルチプロセッシングや画像フィルタの変更がもたらす高速化効果までを特定しているわけではありません。しかし、最速のOCRバックエンドを選択したとしても、抽出処理時間のかなりの部分がそのまま手付かずで残ってしまう理由を浮き彫りにしています。

3. 文字誤り率は抽出品質の一側面に過ぎない

テキストのスコアだけでは、表の忠実度を完全に説明することはできません。論文では、文字および単語レベルの指標と、表構造やセルに関する指標を組み合わせて両方を評価しています。

抽出エンジンを比較する際は、この区別を維持してください。TEDSはCERやWERと並んで構造的な根拠を提供します。複合スコアはこれらのシグナルを統合しますが、個別の評価を覆い隠すべきではありません。

4. 検索カードとコンテキストウィンドウを分離する

論文の親子アーキテクチャは、小さな文章パッセージで検索マッチングを行いながら、より広いコンテキストを返す具体的な手法を提供します。構造タグによって表や図を損なわずに保持し、オプションのパンくずリストが埋め込まれるテキストにドキュメント内の位置情報を付加します。

Orionでの実行結果は、この設計が大規模に評価可能であることを実証しています。ただし、同一コーパス上で親子チャンキングが固定長チャンキングやセマンティックチャンキングなどの代替手法を上回ることを証明する、厳密にコントロールされた検索比較までは含まれていません。

本システムの限界と課題

著者らは本システムを本番環境対応（production-ready）と説明していますが、示された根拠からはその結果の解釈にいくつかの限界があることが分かります。

• 合成質問への依存（Synthetic question dependence）：検索測定はMistral-Mediumによって生成された質問を使用しています。論文でも、この代替指標の有効性がジェネレーターの品質に依存することが明記されています。実際のユーザーのクエリセットに対する検証は報告されていません。
• ドキュメント内に限定されたページ基準のヒット（Document-scoped, page-based hits）：検索は質問の発生元ドキュメント内で行われ、成功の判定は類似度とページの近接性に依存しています。これらの結果は、コーパス全体からのドキュメント選定能力や、生成された回答の正しさを保証するものではありません。
• 社内評価と限定的な比較（Internal evaluation and limited comparisons）：報告されたスコアは社内コーパスに対する自己測定結果です。本論文では、チャンキングのアブレーション実験や、言及されている他の代替戦略とのコントロールされた検索比較は報告されていません。
• 設定可能なルーティングヒューリスティック（Configurable routing heuristics）：80%の画像面積閾値はOrion上でのルーティング割合をもたらしたものです。他のドキュメント母集団におけるルーティング精度は確立されておらず、より厳格なスキャンページ判定ルールは抽出ルーティングではなくキュレーション段階のものです。
• モニタリングは依然として一部が提案段階（Monitoring remains partly a proposal）：リファレンスベースのCERおよびWERにはグラウンドトゥルースが必要です。論文ではリファレンスフリーのシグナルやキャリブレーション戦略について論じられていますが、モニタリングの理論的根拠は実装済みのキャリブレーションコードというよりは仮説や今後の方向性として位置づけられています。そうしたシグナル単体では真のエラー率を報告することはできません。

まとめ

ドキュメントの取り込み処理は、一度組んだら忘れ去られるような単なるユーティリティスクリプト以上の関心を払うに値します。著者らの表現を借りれば、それは生成AIシステムの「認識層」なのです。

選択的ルーティング、決定論的レイアウト再構築、構造を考慮した親子チャンキング、そして読み取り専用の評価器を組み合わせることで、本論文は取り込みに関する意思決定を明示的かつ測定可能にする具体的な手法を提示しています。その最大の貢献は、これらのコンポーネントと、それら自身が生み出す評価の根拠とを結びつけた点にあります。

プロンプトの微調整やリランキングモデルのテストにもう1週間費やす前に、自社の取り込み層をじっくり見直してみてください。パーサーがページ上の情報を失ってしまえば、下流の検索システムは修復不能な問題を抱えた状態でスタートすることになるのです。