クロールはコーパスではない。数十億ページを取得することはインフラの問題であり、これはAIとLLM学習のためのWebデータ収集で扱われている。それらのページをモデルを改善する学習データに変えることは別の問題であり、独自の段階があり、最終的なデータセットの品質の大部分はそこで決まる。
このガイドはそれらの段階を順に説明する。何を収集するかを決めること、オプトアウトを尊重すること、テキストを抽出すること、フィルタリングすること、重複を排除すること、評価汚染を取り除くこと、そして結果を文書化することだ。より小規模での一般的なスクレイピングデータセットのパイプラインは、Webスクレイピングでデータセットを構築する方法にある。
クローラーではなく、混合比から始める
何をクロールするかを決める前に、モデルが何を必要としているかを決める。学習用コーパスは混合物であり、言語、ドメイン、フォーマット、期間の割合を、それぞれのトークン予算として表現したものだ。
このターゲットが下流のすべてを決める。どの地域から収集すべきか、各ソースにどれだけのクロール予算を割くべきか、そしていつあるドメインが十分に貢献したかを教えてくれる。これがなければ、クロールは取得しやすいもの、つまり通常は大規模で英語中心で被リンクの多いサイトへと偏り、モデルはその不均衡を引き継ぐことになる。この問題のサンプリング側の側面は、レジデンシャルプロキシのプールはサンプルであり、インターネットそのものではないで扱われている。
クロールフロンティア
フロンティアとは、取得を待つURLのキューであり、これをどう管理するかによって、Webのどの部分が最終的にコーパスに含まれるかが決まる。
シード。 混合比に合致するソースから始める。言語やトピックごとに精選されたドメインリスト、サイトマップ、高品質なページからのリンクなどだ。
優先順位付け。 期待値によってURLを順位付けする。ソースの品質事前分布、既に保有しているものに対する新規性、そして直近性が重要な場合の新しさなどだ。
正規化。 キューに入れる前にURLを正規化し、トラッキングパラメータ、セッション識別子、重複パスを取り除く。これにより、同じページが異なるアドレスの下で何度も取得されることを防ぐ。
礻儀正しさの予算。 全体としてだけでなく、ホストごとに並行数とリクエストレートの上限を設ける。小さなサイトを叩き続けるフロンティアは無責任であるだけでなく、ブロックされることで自己破壊的でもある。その仕組みについてはレート制限とリクエストスロットリングにある。
再クロール方針。 各ソースをどのくらいの頻度で再訪問するかを、それがどのくらいの頻度で変化するか、そして混合比が新しいコンテンツをどれだけ必要とするかに基づいて決める。
取得時にオプトアウトを尊重する
オプトアウトの信号は、ページを取得する時点で確認し、それと一緒に記録しなければならない。なぜなら、それらは時間とともに変化し、あとでその状態を証明する必要があるかもしれないからだ。
- robots.txt。AI専用のクローラー名に向けられたルールも含む。
- ページレベルの信号。robotsメタタグやレスポンスヘッダーなど。
- 機械読み取り可能な権利留保。 EUでは、権利者はテキスト・データマイニング権を機械読み取り可能な形式で留保することができ、汎用AIモデルの提供者はそれらの留保を尊重し、学習コンテンツを文書化することが求められている。
- サイト利用規約。 自動収集や再利用を禁止しているもの。
オプトアウトの状態を各文書とともに保存し、あるソースが許可を撤回した場合に後で文書を削除できる能力を保持する。より広い枠組みについてはAIデータ収集のための倫理的なレジデンシャルプロキシにある。
抽出:HTMLからテキストへ
生のHTMLの大部分はコンテンツではない。ナビゲーション、フッター、クッキーバナー、関連記事ウィジェット、広告などが、ページ内の実際のテキストより多い場合もある。
- 本文コンテンツを抽出し、定型部分を捨てる。
- 意味を伝える構造を保持する。 見出し、リスト、表、コードブロックなど。
- レンダリングされたページを処理する。 一部のコンテンツはJavaScriptが実行された後にしか存在しない。Webスクレイピング用APIが必要な場合を参照。
- 言語を識別する。 文書ごと、多言語混在ページでは段落ごとに識別し、混合比のターゲットを実際に測定できるようにする。
生のレスポンスは再現ウィンドウの間、保存しておく。抽出ロジックは改善されていくものであり、保存済みのレスポンスから再抽出する方が再クロールよりはるかに安価だ。その受け入れパターンについてはWebスクレイピングAPIデータをSQLに移すにある。
品質フィルタリング
クロールが返すもののほとんどは学習に値しない。フィルタリングは通常、段階的に、最も安価なものから実行される。
ヒューリスティックフィルタは明らかなゴミを取り除く。非常に短い文書、記号や数字が支配的なページ、多数回繰り返される行、通常の機能語を含まないテキスト、そしてほとんどがリンクのリストであるページなどだ。
モデルベースの品質フィルタは、望ましいテキストの例に対して文書をスコア付けする。これらは強力だが、品質の定義をエンコードするものなので、それらが体系的に何を除外しているかを確認する必要がある。
生成コンテンツのフィルタリングは年々重要になっている。詳細はWebデータセット内のAI生成コンテンツを検出・フィルタリングする方法にある。
安全性フィルタは、モデルが要求するコンテンツポリシーを適用する。
すべてのフィルタを言語ごとに調整する。英語で調整されたしきい値は、ある言語に対しては削除しすぎ、別の言語に対しては削除しすぎない、といった結果になる。そして各段階が何を削除しているかを言語とドメインごとに測定し、あるフィルタがひそかにある地域全体の文章を削除していないかを見つける。
コーパス規模での重複排除
重複したテキストはWebのあらゆる所にある。配信記事、ミラーサイト、テンプレート化されたページ、ドメイン全体で繰り返される定型文などだ。放置すれば、たまたま最もコピーされたものが過度に重み付けされる。
- 完全重複は、正規化されたテキストをハッシュ化することで取り除かれる。
- 近似重複は、シングル化されたテキストに対するMinHashと局所性保存ハッシュ法によって見つけられる。これは非常に大規模なコーパスにも対応できる。
- ドメイン内の繰り返し段落。 免責事項や署名など。これらは段落レベルで取り除かれる。
- 時間をまたぐ重複。 同じページが複数のクロールスナップショットに現れる場合、1つのバージョンにまとめられる。
個人データ
Webクロールは、望むかどうかにかかわらず個人データを収集する。名前、メールアドレス、電話番号、時には識別番号などだ。ログインの背後からは収集しないこと、処理中に一般的な識別子パターンを除去すること、そしてパイプラインが何を取り除くかを文書化すること。法的な枠組みについてはレジデンシャルプロキシとGDPR準拠にある。
汚染除去
評価用ベンチマークが学習データに含まれてしまうと、評価は何も測定しなくなる。ベンチマークの問題と回答はWeb上でコピーされ広がっているため、汚染はデフォルトで発生する。
使用予定のすべての評価セットとの重複をコーパスで確認する。通常は長いn-gramマッチングを使用し、一致したものを取り除くか、フラグを立てる。どのベンチマークが確認されたかを記録し、後の結果を正しく解釈できるようにする。
すべてを文書化し、バージョン管理する
学習用コーパスは何百もの決定の産物であり、それらを知らなければ責任を持って利用することはできない。
- 文書ごとの出所情報。 ソースURL、取得時刻、観測された視点、オプトアウトの状態、通過したフィルタのバージョンなど。
- データセットカード。 ソース、期間、言語、フィルタとそのバージョン、既知の欠落、既知のバイアスを含む。
- 再現可能なパイプライン。 これにより、あるソースが許可を撤回した際に、コーパスのバージョンを再構築または修正できる。
各観測がどこで、いつ行われたかを記録することの根拠については、視点(vantage-point)標準にまとめられている。
規模に応じた収集層
大規模な収集には、地域のソースに到達するためだけでなく、ホストごとのリクエストレートを妥当な範囲に保つためにも、分散した地理的に適切な出口が必要となる。Shifterゲートウェイでは、市場はp.shifter.io:443に対する認証情報の中で設定され、セッション識別子を省略すると、リクエストごとに出口がローテーションする。これは、多数の独立したページを取得するフロンティアに適している。
customer-USERNAME-country-jp:PASSWORD
プロキシ層が学習データに特有に重要な理由については、AI学習データのためのレジデンシャルプロキシで扱われている。
コーパスの健全性を保つための指標
| 指標 | それが示すもの |
|---|---|
| 目標に対する言語別・ドメイン別のトークン数 | 混合比が達成されているかどうか |
| フィルタ段階ごとの言語別除去率 | あるフィルタがどこかで過剰に削除していないかどうか |
| 重複率 | クロールのどれだけが繰り返しだったか |
| オプトアウトのカバレッジ | オプトアウト確認が記録された文書の割合 |
| ベンチマークごとの汚染ヒット数 | 評価が信頼できるかどうか |
FAQ
独自にクロールする代わりに、公開されているWebクロールから始めることはできるか?
公開クロールは強力な出発点になる。ただし、それらはライブなWebに対して遅れをとっており、カバレッジの欠落もあるため、ほとんどのチームは自分たちに重要な言語やドメインのために、より的を絞った、より新しい収集を追加する。
品質フィルタリングはどれくらい積極的にすべきか?
ゴミを取り除くには十分積極的でありながら、他に何を取り除いているかを注意深く測定できる程度であるべきだ。しきい値を確定する前に、言語や地域別に削除内容を監査すること。
学習データにもrobots.txtを従う必要があるか?
はい、AI専用のルールも含めて従う必要があり、取得時点での状態を記録する。オプトアウトは一部の法域では法的な期待事項にもなりつつある。
これはグラウンディングデータとどう違うのか?
学習データはモデルの重みを形成する。グラウンディングデータは回答時に取得され、引用される。後者についてはライブWebデータでLLMエージェントをグラウンディングするで扱われている。
結論
大規模な学習用コーパスは、クロールの後の段階で構築される。何を収集するかを決める混合比のターゲット、礻儀正しさを保つフロンティア、取得時に確認され記録されるオプトアウト、クリーンな抽出、言語別に調整された段階的フィルタリング、あらゆるレベルでの重複排除、評価に対する汚染除去、そして誰もが決定事項を再構築できるようにする文書化だ。
混合比が必要とする地域から収集し、再現のために生のレスポンスを保存し、各段階が何を取り除くかを測定すること。プロダクトの詳細はAIおよびMLのためのレジデンシャルプロキシページにあり、料金については料金ページにある。