テクニカル・サマリー：文書数を数えることはテキストを数えることではない：Web-PDFコーパス統計におけるユニット・バイアス

問題提起

本論文は、大規模言語モデルの事前学習に使用されるWeb-PDFコーパスの統計報告における、決定的な方法論的欠陥を指摘している。これらのコーパス（FinePDFs、CCpdf、PDFAなど）は、その規模をトークン数で宣伝している一方で、カバレッジ、OCRルーティング、再取得によるリカバリー率、言語構成などのすべてのパフォーマンス指標を文書単位で計算し、報告している。

著者は、文書は互換性のある単位ではないと主張する。PDFは極端な長さの偏り（スキュー）を示すためである。したがって、文書単位で報告される統計は、モデルが利用可能な実際の「テキスト量（text mass）」を代表していない。さらに、本論文は、Common Crawlのペイロード・トランケーション（切り詰め）制限（歴史的には1 MiB、最近は5 MiBに引き上げられた）が、PDFにおいて最も深刻な影響を受ける形式であるにもかかわらず、失われたテキスト量として定量化されることがほとんどないという点を強調している。

方法論

本研究では、CC-MAIN-2021-31-PDF-UNTRUNCATED コーパスを使用している。これには793万個のユニークなWeb PDFと325.7億個のトークンが含まれている。このデータセットは、Common Crawlによって保存された切り詰められたレコードと、ソースから再取得された完全なオリジナルファイルをペアにしているため、切り詰められたファイルと完全なファイルを直接比較できるという点でユニークである。

著者は、二重の単位分析を採用している：

1. 文書数（Document Count）： ファイルの標準的なカウント。
2. トークン数（Token Count）： テキスト量を測定するために tika_eval_num_tokens（Apache Tika 2.8.0、空白/ICUベース）を使用。

主な分析ステップは以下の通り：

• 分布分析： 文書間の不平等や偏りを測定するために、トークンとページに関するジニ係数を算出する。
• トランケーション（切り詰め）のシミュレーション： 旧来の1 MiB制限と新しい5 MiB制限の下でのコーパスの状態を再構築し、失われた文書およびトークンの割合を決定する。
• 抽出リカバリー： 180万個の切り詰められた文書に対し、切り詰められたバージョンと完全なバージョンの両方に対して、2つの独立した抽出エンジン（PyMuPDFとPDFium）を実行する。これにより、部分的なファイルからどの程度のテキストが回収可能か、またリカバリー率がエンジン間で異なるかどうかを測定する。
• ツールチェーン分類： プロデューサー／クリエイター文字列（例：TEX、PowerPoint、Microsoft Word）によって文書を分類し、特定のツールチェーンにおける文書数とトークン数を比較する。

主な貢献

本論文は、主に4つの貢献を行っている：

1. 初のトークン加重による特性評価： ヘッドラインとなるコーパス統計（カバレッジ、ルーティング、リカバリー）が、文書単位とトークン単位でどのように異なるかを直接比較した最初の研究である。
2. 集中性の結果： Web PDFにおけるテキスト量は、文書数から示唆されるよりもはるかに偏っていることを実証した（トークンのジニ係数は0.807）。
3. トランケーション・コストの定量化： Common Crawlのトランケーション制限によって引き起こされる具体的なテキスト損失を測定した初の研究であり、23%の文書が切り詰められていた一方で、63%のテキストが失われていたことを明らかにした。
4. リカバリー分析： 切り詰められたテキストの回収可能性を評価し、リカバリー率が抽出エンジンおよびファイル構造（線形化されているか非線形化されているかなど）に強く依存することを示した。

主な結果

1. テキスト分布における極端な偏り

コーパスは文書数で見ると代表性を欠いている。

• 長い文書： 50ページを超える文書は、文書数ではわずか**5.00%であるが、全テキストの53.53%**を保持している。
• 短い文書： 2〜3ページの文書は、文書数の**21.20%を占めるが、テキストへの寄与はわずか3.76%**である。
• 不平等： テキストを多く持つ上位3.02%の文書が、全トークンの半分を保持している。トークンのジニ係数は0.807である。
• ツールチェーンのバイアス： TEXツールチェーンの文書は、文書数では**1.66%であるが、トークン数では4.05%**である（2.43倍の差）。逆に、PowerPointの文書は文書数の2.24%を占めるが、トークン数ではわずか0.82%である。

2. トランケーション（切り詰め）のコスト

Common Crawlの1 MiB制限は、テキスト量に対して不釣り合いな影響を与えた：

• 露出（Exposure）： 23.06%の文書が切り詰められていたが、これらはコーパスの全テキストの**63.08%**を含んでいた。
• リカバリーの限界： 完全なファイルを再取得したとしても、1 MiBの断片からの抽出は極めて困難である。
  • PyMuPDFは、切り詰められたファイルから**11.4%**のトークンを回収する。
  • PDFiumは、わずか**1.4%**しか回収できない。
  • 極めて重要なことに、PyMuPDFでは72.4%の切り詰められたファイルがゼロのテキストしか生成しない（ファイルは開けるが、コンテンツストリームが存在しない）。PDFiumではこれが**96.8%**に達する。
• 純損失： 使用する抽出エンジンに応じて、コーパスの全テキストの約**55〜62%**が事実上破壊されている。

3. 5 MiB制限の影響（2025年3月）

制限を5 MiBに引き上げることは、露出を減少させるが、テキスト損失の問題を解決するものではない：

• 残留する露出： 5 MiB制限下でも、依然として30.19%のトークンが切り詰められることになる（63.08%から減少）。
• 収穫逓減： 残りの切り詰められた文書に対するリカバリー率は、わずか3.3%から13.2%へと上昇するのみである（PyMuPDF）。
• 恩恵の集中： 「救済された」文書の74%は5〜10 MiBの範囲にある。より大きなファイル（例：100 MiB）の場合、5 MiBのプレフィックスが捉えるテキストの割合は無視できるほど小さい。
• ポリシーに関する結論： 制限の引き上げは露出を半分にするが、残りの30%のトークンは依然としてほとんど読み取り不能である。著者は、単に制限をさらに引き上げるのではなく、大きなPDFに対するサイズを考慮したフェッチ・ポリシーが必要であると主張している。

重要性と主張

本論文は、コーパスの統計を文書数のみで報告する現在の慣行が、利用可能なデータについて誤解を招く状況を作り出していると主張している。

• ユニット・バイアス： 文書数で見れば「チラシやフォームが中心」とされるコーパスも、テキスト量で見れば実際には「長い文書」のコーパスである。
• メトリクスの歪み： OCRルーティングやフィルタによるドロップ率などが文書単位で報告されると、言語モデルが消費するトークンストリームへの実際の影響を反映しない。
• 推奨事項： 著者は、すべてのコーパス統計を**両方の単位（文書数とトークン数）**で報告することを推奨している。彼らは、サイズベースのフィルター（他のコーパスで使用されている100 MBや500 msのレンダリング制限など）は、「テキスト量として価格付け（織り込み）」されなければならないと断言している。サイズこそがテキストの塊が存在する場所だからである。

本研究は、二重の単位による視点がなければ、インフラの制限（Common Crawlの制限など）によるデータ損失の真の規模や、トレーニングデータの真の構成が不明なままとなる、と結論づけている。