Scrapelessを使用してLLMトレーニングのためにウェブサイトテキストをスクレイピングする方法

TL;DR:

• LLM対応のウェブテキストはデータ製品であり、単なるコピーされたページの集まりではありません。 信頼できるパイプラインはスコープを管理し、ソースURLを保持し、ナビゲーションノイズを除去し、テキストを正規化し、重複したコンテンツを排除し、ストレージの前にすべてのレコードを検証します。
• モデルタスクから始めてください。 情報検索に基づく生成は、リフレッシュ可能なソースリンク付きのチャンクが必要です；ファインチューニングには慎重にレビューされた例が必要です；事前トレーニングにははるかに広範なガバナンスと品質プログラムが求められます。
• 二重経路の取得設計を使用してください。 HTTPを介して単純な公開ページを取得し、その後JavaScriptやアクセス処理が必要なページをScrapeless Web Unlockerのような管理された取得レイヤーを通じてルーティングします。
• 生データと処理された表現を別々に保存します。 生のレスポンスは監査と再処理をサポートします。クリーンなMarkdownまたはテキストはチャンク化、検索、モデルの取り込みをサポートします。
• レコードレベルで品質を測定します。 空のページ、重複したテンプレート、予期しない言語、薄い抽出、出自のないレコードは、LLMデータセットに入る前に拒否します。

「LLMトレーニングのためにウェブサイトテキストをスクレイピングする」とは何を意味しますか？

ウェブサイトテキストをLLM作業のためにスクレイピングするとは、承認された公開ページを追跡可能で機械可読のレコードに変換することを意味します。役立つ結果は生のHTMLではなく、各テキストユニットにソースURL、キャプチャ時間、コンテンツタイプ、言語、および処理履歴があるデータセットです。

この違いは重要です。なぜなら、ウェブページは記事のコピーをメニュー、クッキーバナー、関連リンク、繰り返されるフッター、アプリケーション状態と混ぜ合わせるからです。すべての見えるテキストをモデルに送信すると、ノイズの多いコンテキストが作成され、後の修正が困難になります。生産パイプラインは、取得、抽出、正規化、品質管理、ストレージを分離する必要があります。

ウェブアクセス層は、出版社のルールと適用法を尊重する必要があります。 ロボット除外プロトコル は、クローラーがrobots.txtでルールを発見する方法を定義しています；これは、利用規約、プライバシー義務、または許可のチェックを置き換えるものではありません。

クロールの前にデータセットの目的を選択してください

同じページは、その目的地によって異なる処理が必要です。

モデル使用	最適ユニット	必要なメタデータ	リフレッシュパターン	主な品質リスク
RAGまたは検索	ソースリンク付きのパッセージ	URL、タイトル、見出しパス、キャプチャされた時間	増分	古くなったまたはコンテキストフリーのチャンク
ファインチューニング	レビューされた入力-出力例	ソース、ライセンスまたは許可の根拠、レビューア、バージョン	キュレーションされたリリース	弱いラベルまたは未承認の再利用
評価	凍結されたプロンプトと参照セット	データセットバージョン、期待結果、スコアリングルール	制御された	トレーニングデータへの漏洩
事前トレーニング	ドキュメントまたは大規模コーパスユニット	出自、言語、ポリシー決定、重複排除キー	大きな管理されたスナップショット	権利、重複、および低品質テキスト

RAGの場合、新鮮さと出自は通常、すべてのページを収集することよりも重要です。ファインチューニングでは、小さなレビューされたセットが、大きなフィルターなしのクロールよりも役立つことがよくあります。評価データはトレーニング入力から分離する必要があります。事前トレーニングは、取得開始前に専門的な法務、安全性、データガバナンスのレビューを必要とします。

LLMテキストパイプラインの概要

耐久性のある成果物を境界ごとに明示的なシーケンスを使用します：

1. 許可されたドメイン、パス、言語、ページタイプを定義します。
2. サイトマップと承認されたナビゲーションから標準的なURLを発見します。
3. 必要なコンテンツを返す最も軽い方法で各ページを取得します。
4. 見出し、リスト、およびテーブルを保持しながらメインドキュメントを抽出します。
5. ホワイトスペース、URL、Unicode、およびボイラープレートの決定を正規化します。
6. ページと繰り返しコンテンツ領域を重複排除します。
7. ターゲットモデルタスク用にソースリンク付きのチャンクにドキュメントを分割します。
8. スキーマ、出自、言語、コンテンツ密度、およびポリシーステータスを検証します。
9. 生のキャプチャ、クリーンドキュメント、および処理メタデータを別々に保存します。

このアーキテクチャにより、チームはソースを再度クロールすることなく抽出やチャンク化を改善できます。また、任意のモデルレスポンスからそのコンテキストを供給したページおよび処理バージョンへの監査パスを作成します。

ステップ 1: スコープとアクセスルールを定義する

スコープはデータとして書き、非公式なメモとしてではなく記述します。役立つクロールポリシーには、許可されたホスト、許可されるパスプレフィックス、拒否されたパス、最大深度、受け入れられるメディアタイプ、言語ルール、およびホストごとのリクエスト予算が含まれます。ソースを承認した人と、どのような使用が許可されているかを記録します。

リンクを自動的にすべてを収集するための許可として扱わないでください。アカウント専用エリア、個人データ、有料コンテンツ、制限付きエンドポイントは、プロジェクトに文書化された根拠と適切な管理がない限りスコープから除外してください。技術的なアクセス制御を回避しようとしないでください。
HTTP ステータス コード、リダイレクト、キャッシング指示、および表現メタデータは、HTTP セマンティクス仕様 に従って解釈されるべきです。これは、エラーページ、ログインリダイレクト、およびサポートされていないファイルが成功したテキストドキュメントとして誤ってラベル付けされるのを防ぎます。

ステップ 2: 境界を失うことなく URL を発見する

サイトマップは、通常、クリーンな出発点です。なぜなら、それらはクローラーがすべてのナビゲーションバリアントを移動することを強いることなく、標準コンテンツ URL を公開するからです。サイトマップから欠けているセクションに対して承認されたシードページを追加し、その後、スケジュールする前に各候補を正規化します。

正規化は、フラグメントを削除し、相対 URL を解決し、ホストの大文字と小文字を標準化し、トラッキングパラメータのプロジェクトルールを適用する必要があります。コンテンツを変更するパラメータは保持し、プロジェクトが非コンテンツバリアントとして分類したパラメータのみを削除します。

二つの重複排除キーを使用します：

• 正規化された URL キーは、同じルートが繰り返しスケジュールされるのを防ぎます。
• コンテンツフィンガープリントは、異なる URL の下で公開された同一またはほぼ同一のページをキャッチします。

発見と取得は別のキューであるべきです。これにより、コンテンツを取得する前に計画された範囲を検査し、カレンダー、ファセット検索ページ、または制限のないページネーションにわたる偶発的な拡張を停止することが可能になります。

ステップ 3: 正しいレンダリングパスでページを取得する

必要な記事テキストが返された HTML に現れる場合、直接の HTTP 応答で十分です。それは運用コストが低く、デバッグが容易です。クライアントサイドの JavaScript がコンテンツを構築する場合、ナビゲーションを展開する必要がある場合、または正当なパブリックレスポンスが管理されたアクセス処理を必要とする場合、ブラウザまたはレンダリングパスが必要です。

Scrapeless Web Unlocker は、JavaScript のレンダリングやアクセス管理を必要とする公開ページのための取得層を提供します。取得契約は狭く保ちます：承認された URL を提出し、期待される結果として HTML を要求し、抽出前に最終 URL、ステータス、およびメディアタイプを検証します。

デフォルトで各ページをブラウザを通して送信しないでください。まず、各テンプレートから代表的な URL を検査します。静的テンプレートを HTTP 経由でルーティングし、動的テンプレートをレンダリングを通してルーティングします。これにより、パイプラインを理解可能に保ち、各テンプレートに明確な取得ルールを与えます。

Web Unlocker の導入 は、サービスの境界を文書化しています。静的解析とブラウザ実行について詳しくは、JavaScript スクレイピングガイド をお読みください。

Scrapeless でスクレイピングを開始する

Scrapeless でWeb スクレイピングと自動化のワークフローを強化しましょう！
今日はサインアップして $5の無料クレジット を獲得しましょう — クレジットカードは不要です。

Scrapeless ダッシュボード で今すぐ無料クレジットを請求してください。

ステップ 4: メインドキュメントを抽出する

メインコンテンツの抽出は、サイトの外観を取り除きながらドキュメント構造を保持するべきです。見出しを順序どおりに保ち、リスト項目をそのセクションに添付し、意味のあるテーブル行を保持し、文に寄与する場合はリンクテキストを保持します。ナビゲーション、繰り返しのプロモーションパネル、クッキーコントロール、および無関係な推奨事項は削除します。

DOM 標準 によって説明されるブラウザドキュメントモデルは木構造を提供しますが、その木構造は自動的にメイン記事を特定しません。抽出にはまだテンプレートルール、セマンティック要素、またはテスト済みのコンテンツ抽出器が必要です。

結果を二つのビューで確認します：

• 構造ビュー: 見出し、段落、リスト、テーブル、およびコードが予想される順序で表示されます。
• 読み取りビュー: 人が元のレイアウトを見ずにドキュメントを理解できるようになります。

各テンプレートに対して短い抽出レポートを保持します。それは選択したルート、削除された領域、最小限の許容テキスト長、および存在しなければならないフィールドを名前付けする必要があります。

ステップ 5: 意味を消さずに正規化する

正規化は、事実を保持しながら同等のテキストを一貫性のあるものにする必要があります。行末を変換し、Unicode を正規化し、レイアウトのホワイトスペースを圧縮し、Markdown 表現を標準化します。句読点、単位、否定、コードフォーマット、およびセクション境界をそのまま保持します。

ステップ6: チャンク化する前に重複を排除する

正確な重複排除は、同一のドキュメントを削除します。近似重複検出は、印刷ページ、地域ミラー、および小さなブロックのみが変更されるテンプレートを捉えます。ボイラープレート分析は、同じテンプレートからの多くのページを通じて行われるべきであり、繰り返しのナビゲーションとフッターのテキストが安全に特定できるようにする必要があります。

チャンク化する前に重複を排除してください。さもなければ、同じ段落がいくつかのチャンクIDを受け取り、検索結果を支配する可能性があります。削除された重複を保持された正規のレコードにマッピングしておき、アナリストがなぜURLが新しいドキュメントを生成しなかったのかを説明できるようにします。

ステップ7: 利便性ではなく検索のためにチャンク化する

チャンクは、見出しのセクション、リストグループ、またはテーブルユニットなどの意味的な境界に従うべきです。固定文字ウィンドウは、条件から定義を分割し、列ラベルから値を分離できます。各チャンクにおいて見出しパスとソースURLを保持してください。

境界コンテキストが失われていることを評価が示す場合にのみ、オーバーラップを使用してください。大きなオーバーラップはストレージを増加させ、リトリーバーが同じパッセージのいくつかのコピーを返す原因になる可能性があります。トークンカウント統計だけでなく、アプリケーションからの実際の質問を使ってチャンク化をテストしてください。

ステップ8: すべての出力レコードを検証する

検証は、ストレージの前、およびモデルの取り込みの前に行うべきです。以下の場合はレコードを拒否または隔離してください：

• 最終URLが承認された範囲外である場合；
• 応答が予期されるテキストの表現でない場合；
• 抽出が空、異常に薄い、またはほとんどナビゲーションのみの場合；
• 言語が宣言されたデータセットの言語と異なる場合；
• ドキュメントにソースURLまたはキャプチャ時間がない場合；
• コンテンツハッシュが承認されたバージョン変更なしで既に存在する場合；
• ページにレビューを必要とする制限またはポリシー状態が含まれている場合。

NIST AIリスク管理フレームワークは、AIシステムに関連するリスクをマッピング、計測、および管理するための有用なガバナンス用語集を提供します。これらのアイデアをソース承認、データセット文書、評価、および変更管理に適用し、スクレイピングを孤立したエンジニアリングステップとして扱わないようにします。

生データ、クリーンデータ、インデックスデータを別々に保存する

3つのレイヤーを保持してください：

1. 生キャプチャ: 監査に必要なレスポンスボディ、ヘッダー、最終URL、およびタイムスタンプ。
2. クリーンドキュメント: 正規化されたMarkdownまたはテキストおよび抽出メタデータ。
3. アプリケーションインデックス: チャンク、埋め込み、検索フィールド、およびインデックスバージョン。

抽出の更新は、保持された生キャプチャからレイヤー2と3を再構築するべきです。チャンクの更新はインデックスのみを再構築するべきです。この分離により、引用が間違っている場合やテンプレートが変更された場合の調査時間が短縮されます。

結論: ボリュームの前にトレーサビリティを構築する

LLMテキストパイプラインは、すべてのクリーンなパッセージが承認されたソースにトレース可能であり、既知のキャプチャから再現できるときに成功します。狭いページテンプレートのセットから始め、取得パスを確認し、抽出されたドキュメントをレビューし、クローリングボリュームを増やす前にレコードレベルの品質ゲートを確立してください。

最も有用な最初のマイルストーンは、大規模なコーパスではありません。それは、別のエンジニアが監査できるように、その範囲、由来、変換、および失敗ルールが明確な小さなデータセットです。

ソースリンクされたウェブテキストパイプラインを構築する

Scrapelessの価格を比較し、Web Unlockerを探索するか、Scrapeless DiscordコミュニティやTelegramコミュニティに参加してください。

よくある質問

Q: 生のHTMLはLLMトレーニングに適していますか？

生のHTMLは監査および再処理アーティファクトとして有用ですが、通常はナビゲーション、スクリプト、繰り返しのテンプレート、変更されずにモデル入力に入るべきではないレイアウトマークアップを含んでいます。別のクリーンな表現を作成し、生キャプチャへのリンクを保持してください。

Q: すべてのウェブサイトはブラウザでレンダリングされるべきですか？
いいえ。必要なテキストが応答に存在する場合は、直接HTTP取得を使用します。JavaScriptやインタラクションが必要で承認された公開コンテンツを表示するテンプレートのみ、ブラウザレンダリングを追加します。

Q: LLM対応のテキストに最適な形式は何ですか？

見出し、リスト、表、コード構造が重要な場合にはMarkdownが便利です。JSONLは、ドキュメントやチャンクとメタデータのコンテナとして有用です。スキーマと出所フィールドはファイル拡張子よりも重要です。

Q: 重複するウェブページはどのように処理すべきですか？

スケジューリングには正規化されたURLを使用し、正確な重複にはコンテンツハッシュを使用し、ミラーやテンプレートのバリエーションにはテスト済みの近似重複法を使用します。除外した重複を保持されたドキュメントにマッピングする記録を保持してください。

Q: ウェブテキストデータセットはどれくらいの頻度で更新すべきですか？

ソースの変動性とアプリケーションのニーズに基づいて更新ルールを設定します。製品ドキュメントは頻繁にチェックが必要な場合がありますが、アーカイブされた参照はまれにしか変化しないことがあります。取得タイムスタンプを保存し、コンテンツハッシュを比較して、変更されていないページが新しいバージョンを作成しないようにします。

Q: スクレイピングしたテキストはあらゆるモデルプロジェクトに使用できますか？

いいえ。アクセス、著作権、プライバシー、契約、データ保護要件は、ソース、管轄、および意図された使用に依存します。適切なレビューを取得し、プロジェクトが文書化された法的根拠と管理を持たない限り、制限されたデータまたは個人データをパイプラインの外に保持してください。