LLM トレーニングのためのプロキシ: トレース可能なウェブデータ収集パイプラインを構築する

要約

• プロキシは収集リクエストの経路を提供するだけであり、それ自体では学習に適したコーパスを作らない。 ソースの許諾、テキスト品質、データセット構成には、それぞれ個別のチェックが必要。
• 完了したリクエスト数ではなく、受理されたユニーク文書数を測定する。 チャレンジページ、重複、利用不適切な素材は、コーパスの有用なカバレッジを増やさずにリソースを消費する。
• 要求した地域情報は取得コンテキストであり、言語ラベルではない。 文書の言語や地域的な意味を割り当てる前に、返ってきた文書そのものを検査する。
• ソースと却下の証拠をパイプライン全体で保持する。 コンテンツハッシュは、重複素材の出自を消すのではなく、来歴追跡を支援すべき。

コーパス収集システムは、大量の HTML を取得しながら、学習に有用なテキストをほとんど追加しないことがある。ナビゲーション、重複記事、エラードキュメント、承認済みソース計画の範囲外の素材などが、バイト数だけを増やす。

LLM 学習向けのプロキシは、その収集システムの内部に置くべきである。プロキシは既存クライアントのためのネットワーク経路を提供するだけだ。クライアントと後段のパイプラインは依然として、要求したソースを特定し、意図したテキストを抽出し、その文書を計画中のデータセットに含めてよいかどうかを判断しなければならない。

本ガイドは、Scrapeless Proxies を中心としたトレーサブルなワークフローを構築する。アカウント依存の収集処理と決定論的な処理とを分離し、ラベル付きの例示レコードに対するローカル重複排除チェックを示す。ライブ環境におけるプロキシの成功率や、学習に即利用可能なコーパスを測定・主張するものではない。

パイプラインの概観

このパイプラインは、承認済みソース計画からバージョン管理されたデータセットリリースへと進む。各段階は、次の段階がその出力を解釈できるだけの証拠を記録する。

境界を明確に保つこと。コンテンツ検証に合格したページであっても、想定する学習用途には依然として不適格であり得る。それらを別個の状態として保存し、収集成功がそのまま利用許諾の決定にならないようにする。

ステージ 1: ソース・言語・想定用途を定義する

ソースマニフェストは、コレクタが何をリクエストしてよいか、データセットが何を含むことを意図しているかを記述する。プロキシ割り当てを選ぶ前に作成する。

ソースオーナー、URL スコープ、文書タイプ、収集期間、許可されたボリューム、許諾の証拠、想定用途を記録する。プロジェクトが不要とする個人情報やコンテンツクラスの除外条件も含める。

データセット文書化フレームワークは、データセットの動機・構成・収集・想定用途に関する問いを整理する。この枠組みを使うことで、クロールリストを完成されたデータセット計画として扱うのではなく、ソース選定をレビュー可能なものにできる。

言語ターゲットは、プロキシの地理情報とは独立して定義する。同一ホスト上で複数言語を公開している場合もあれば、翻訳されていない記事のまわりに翻訳済みナビゲーションを出す場合や、セッションごとにコンテンツを変化させる場合もある。要求した出口リージョンは取得に関する 1 つの観測情報にすぎず、文書言語の証拠ではない。

ステージ 2: 各ソースに対してプロキシ経路を選ぶ

Scrapeless Proxy Solutions は、あなた自身の収集クライアントのためのルーティングレイヤーを提供する。許諾されたターゲット集合のニーズに合わせて、割り当てられたプロダクトとエンドポイントを選択する。

その経路がソースに到達できるか、必要なセッション継続性を保持できるか、意図したエディションを返すかを比較検証する。プロキシのカテゴリだけでは、そのいずれも証明されない。ワークロードをスケールさせる前に、実際のアカウント設定をテストする。

現在の認証形式については、プロキシ認証とエンドポイント設定 を利用する。プロキシタイプのセグメントをでっち上げるのではなく、割り当てられたチャネルに紐づく完全なユーザー名を保持する。ゲートウェイの所在地と、要求するターゲット地域は別々の設定である。

コレクタのデプロイに関する判断には、VPS とプロキシの比較 が、コンピューティングホスティングとネットワークリーティングが果たす異なる役割を説明している。

ステージ3: 生ファイルと取得コンテキストの取得

生キャプチャは、選択した経路を通じてクライアントが実際に受信した内容を記録する。テキスト抽出や、プロジェクトの保持ポリシーに従って拒否されたドキュメントを破棄する前に保存しておくこと。

次のリクエストには、Python、requests、割り当て済みの Scrapeless プロキシエンドポイント、および有効なチャネル認証情報が必要である。必要に応じて承認済みロケーションまたはセッションオプションを含め、自分のアカウント設定からフルプロキシユーザー名を設定すること。TARGET_URL は、許可されたソースマニフェストに属していなければならない。

注: このプロキシリクエストには、実際に割り当てられた認証情報と認可されたターゲットが必要である。その設定は現行のプロキシドキュメントと照合済みだが、ここでライブのプロキシキャプチャや地域別結果を主張するものではない。

import json
import os
from datetime import datetime, timezone
from pathlib import Path
from urllib.parse import quote
import requests

target = os.environ["TARGET_URL"]
gateway = os.environ["SCRAPELESS_PROXY_GATEWAY"]
user = quote(os.environ["SCRAPELESS_PROXY_USER"], safe="")
password = quote(os.environ["SCRAPELESS_PROXY_PASSWORD"], safe="")
proxy_url = f"http://{user}:{password}@{gateway}"
response = requests.get(
    target, proxies={"http": proxy_url, "https": proxy_url},
    timeout=60, allow_redirects=True
)
response.raise_for_status()
Path("source.html").write_bytes(response.content)
record = {
    "requested_url": target,
    "final_url": response.url,
    "captured_at": datetime.now(timezone.utc).isoformat(),
    "http_status": response.status_code,
    "body_bytes": len(response.content),
    "content_type": response.headers.get("content-type"),
    "training_use_approved": False
}
Path("capture.json").write_text(json.dumps(record), encoding="utf-8")
print(json.dumps({"saved": "source.html", "body_bytes": len(response.content)}))

この記録は、意図的にプロキシ認証情報をログに残さない。トレーニング用途フラグは、プロジェクトのレビューが必要な証拠を提供するまでは false のままである。ダウンロードされたボディのバイト数は、他の転送またはサービス要素を含みうる総課金トラフィックとは同じではない。

キャプチャを受け入れる前に、ページの同一性と期待されるコンテンツを確認すること。ログインページやチャレンジページは、要求された記事 URL の下でコーパスに入れるべきではない。生の拒否コンテンツを削除しなければならない場合でも、拒否理由は保持すること。

ステージ4: 意味を失わずにテキストを抽出する

テキスト抽出では、承認されたドキュメントコンテンツを分離しつつ、想定されるタスクに重要な構造を保持する。ボイラープレートの削除はソース固有の変換である。

一般的な記事の場合、メインコンテンツコンテナを特定し、見出しと段落を保持する。コード、表、数式コンテンツについては、その内容を解釈するうえで必要な書式を残す。プローズ向けに機能する空白ポリシーが、コード例を損なうこともある。

出力には抽出ルールまたはパーサーのバージョンを記録する。ルール変更を同じ入力に対して評価できるように、生キャプチャの参照を保持する。抽出結果が空の場合は、ソースの実際のページと期待されるコンテンツを確認するまで未解決とみなす。

データセットプロヴナンスを通じて、ソースの同一性とキャプチャ活動を関連付ける。その関係は、後続の変換や重複除去を経ても生き残らなければならない。

Scrapeless でスクレイピングを始めよう

Scrapeless でウェブスクレイピングと自動化ワークフローを強化しよう！
今すぐ登録して 5ドル分の無料クレジット を獲得 — クレジットカード不要。

今すぐ Scrapeless ダッシュボード で無料クレジットを請求しよう。

ステージ5: 受理テキストの重複排除と系譜の保持

重複排除は、定義された正規化ポリシーの下で繰り返し出現する資料を識別する。その際、どのソースが同じコンテンツを提供したかを保持する必要がある。

明確に範囲が定義されたドキュメントタイプについて、正規化テキストの完全一致ハッシュから始める。より高度な類似度手法には、別個のしきい値と評価が必要である。単にページの一部を共有しているという理由だけで、異なる改訂版や翻訳を削除することは避ける。

トレーニングデータの重複排除に関する研究は、重複とその言語モデル学習への影響を検証している。その計測結果は自分のコーパスを予測するものではないので、自前のソース構成に対して重複ポリシーを評価すること。

次の実行可能なチェックは、説明用のプローズレコードを用いる。これは、厳密な重複排除を実行し、重複ソースの URL を正準レコードに保持する。例はローカルで実行されたものであり、そのカウントは示されたフィクスチャにのみ対応する。

import hashlib
import json

# Illustrative prose records; these are not downloaded training documents.
rows = [
    {"url": "https://example.com/a", "text": "Permitted sample prose.",
     "training_use_approved": False},
    {"url": "https://example.com/b", "text": "Permitted  sample prose.",
     "training_use_approved": False},
    {"url": "https://example.com/c", "text": "",
     "training_use_approved": False}
]
unique = {}
duplicates = 0
rejected = 0
for row in rows:
    # This whitespace policy is scoped to the illustrative prose fixtures.
    text = " ".join(row["text"].split())
    if not text:
        rejected += 1
        continue
    digest = hashlib.sha256(text.encode("utf-8")).hexdigest()
    if digest in unique:
        duplicates += 1
        unique[digest]["source_urls"].append(row["url"])
        continue
    unique[digest] = {
        "text": text, "content_hash": digest,
        "source_urls": [row["url"]],
        "training_use_approved": row["training_use_approved"]
    }
print(json.dumps({
    "unique_documents": len(unique), "duplicates": duplicates,
    "rejected": rejected,
    "training_eligible": sum(r["training_use_approved"] for r in unique.values())
}))

これらのフィクスチャは、1つのユニークなドキュメント、1つの重複、1つの拒否、そしてトレーニング適格なドキュメントなし、という結果を生む。保持されたテキスト記録は、コンテンツチェックを通過したというだけでは適格にはならない。本番パイプラインでは、重複元が複数あってもそれらの許可を自動的に統合せず、各ソースごとに許可記録を保持すること。

ステージ6: 言語カバレッジと有用な歩留まりを測定する

有用な歩留まりは、パイプラインの受理とキュレーションの判断を経た後に残るものを測定する。ソース、言語、ドキュメントタイプ、取得経路ごとに比較する。

申告された言語、検出された言語、要求された地域属性は分けて保持する。すべての検出器出力を確実なものとして扱うのではなく、短文や多言語ドキュメントを見直す。コーパスはドキュメント数の目標を満たしていても、想定する言語の一つが過小代表されている可能性がある。

トークン歩留まりを測定する際には、モデルとデータセット処理で使用するトークナイザを使う。空白区切りの単語数や文字数は別種の測定であり、その名称も区別しておくこと。トークナイザとそのバージョンは、再現可能なリリースマニフェストとともに記録する。

ルートを比較する前に、それぞれの分母を定義すること。ダウンロードした本文バイト数と請求書の帯域幅値を、必ずしも同じトラフィックを測定しているかのように比較してはならない。

ステージ 7: コーパスの予算策定とリリース

コーパスの予算には、対象として保持される素材の取得、保管、処理、レビューのコストを含めるべきである。ソースがほとんど却下または重複ドキュメントしか生み出さない場合、ルート価格が低くても価値は限られる。

承認済みの小さなコレクション期間について測定されたワークロード値を使用する。支出額と、有用な素材として保持された量を分けて管理する。予測に一律の目標成功率や、想定のページあたりバイト数を挿入することは避ける。

リリースされたソースマニフェスト、抽出ルール、重複ポリシー、言語に関する判断、および利用レビューの証拠にはバージョンを付けること。レコードが除外される場合でも系譜情報を保持し、次回のリリース時に構成がどのように変化したか説明できるようにする。

学習データを責任を持って扱う

公開アクセス可能であることは、収集に関する観測結果であり、そのドキュメントが意図した学習用途に承認されている証拠ではない。ソースレビューでは、権限とプロジェクトに適用される要件を必ず検討しなければならない。

利用規約、権限の証拠、および robots exclusion protocol を確認する。不必要な個人情報を最小限に抑え、ソースの除外指定を尊重し、広範なコレクションジョブを構築する前に、保持および削除手順を定義すること。

不適切または未解決の素材は学習用リリースから除外する。プロキシでは、そのようなガバナンス上の決定を代替することはできない。許可された利用が不明な場合は、責任あるソースオーナーまたは資格を備えたレビュアーとともに解決する。

結論

LLM 学習のためのプロキシは、承認された収集に対して適切なルートを提供する場合に有用である。学習データのパイプラインは、得られたドキュメントが意味を持ち、一意であり、意図するデータセットに適格かどうかを判断する。

ソースマニフェストから始め、取得の証拠を保持し、コンテンツレビューと利用レビューの後に収率を測定する。ワークフローが有用なコーパスカバレッジを追加していることをそれらの記録が示すときに、ルーティングのフットプリントを拡大する。

トレース可能なコレクションパイプラインを構築する準備はできましたか?

Scrapeless を使って境界を定めたソースコレクションを計画し、観測された収率を現在の料金と比較する。Telegram でパイプライン設計に関する質問を共有することもできる。

FAQ

Q: プロキシを使えばウェブページは LLM 学習に適したものになりますか?

プロキシはネットワークルートを提供するだけであり、ドキュメントの品質や学習利用の許可を確立するものではない。これらの判断はコーパスパイプラインとソースレビューに属する。

Q: リクエストしたプロキシの国設定で、そのドキュメントの言語が決まりますか?

リクエストした国はドキュメントの言語を決定しない。返却されたコンテンツを確認し、地理情報、宣言された言語、レビュー済み言語を別々の観測結果として保持すること。

Q: チャレンジページやアクセス拒否ページに遭遇した場合、収集側はどう扱うべきですか?

収集側は、その不適切なレスポンスを却下または検疫し、取得理由を記録するべきである。そのテキストを成功した学習用ドキュメントとして扱ってはならない。

Q: 抽出セレクタが変更された場合、どうすればよいですか?

ソースを再検査し、保存済みキャプチャに対して抽出ルールを更新する。パーサのバージョンと最終ページの識別情報を保持し、出力が空になった場合に診断できるようにする。

Q: コーパスのパイロットでは、どの程度の並行実行数を使うべきですか?

上限を設けたパイロットと、ホストあたり保守的な上限（この例のポリシーでは、ワーカー 3 つなど）を使用する。ソースの許可、収集ルール、および測定されたオペレーションが拡張を制御する。

Q: このコレクションパイプラインには AI エージェントが必要ですか?

キャプチャ、抽出、重複排除、リリースの判断は、決定論的なソフトウェアとして実行できる。AI エージェントは、そのパイプラインの周辺にいる任意のコンシューマーまたは監督付きヘルパーにすぎない。

Q: 完了したリクエスト数から、学習トークン収率を推定できますか?

完了したリクエスト数だけでは、有用な学習トークンを推定できない。ドキュメントの受理、重複排除、利用適格性のチェック後に、想定するトークナイザでトークンを測定すること。