ウェブからファインチューニングデータセットを構築する: URLsからJSONLへ

良いファインチューニングの90%はデータセットです。これは生のURLsからクリーンなJSONLへのパイプラインです。大規模なソーシング、重複除去、ライセンスフィルター、そしてトレーナーが実際に期待するチャット形式について説明します。

ファインチューニングは投入するデータの質で決まります。ファインチューニングで最も難しい部分はトレーニング実行ではなく、クリーンなデータセットを構築することです。ウェブはそのデータの最も豊富なソースですが、生のページは乱雑で、重複し、ラベルがなく、法的に不均一です。このガイドは、URLsからトレーニング準備が整ったJSONLへのパイプラインです。実際に必要なデータ量、大規模にソースする方法、クリーニングと重複除去の方法、ライセンスの扱い方、トレーナーが期待するチャット構造でのフォーマット方法について説明します。これは公共のウェブコンテンツから指示またはチャットファインチューニングを構築することを前提としています。

実際にどれくらいのデータが必要ですか？

現実的な目標を立てて、過剰または不足しないようにしましょう。合理的な結果を出すためのファインチューニングの実用的な最低限は約100行です。しっかりしたパフォーマンスを得るには、通常1,000行以上が望ましいです。より多くのデータは通常助けになりますが、それはクリーンである場合のみです。1,000のよくラベル付けされた例は、10,000のノイズの多いものよりも優れています。スケールの参考として、クラシックなAlpacaデータセットは52,000の指示/出力ペアで、より強力なモデルをプロンプトして生成されました。合成例を生成するために大きなモデルを使用する場合は、少なくとも10の手書きの例でシードし、望む正確な構造とトーンを学習させてから、さらに生成させましょう。

ソーシング: クリーンなmarkdownへのクロール

ソーシング段階での目標は、生のHTMLではなくクリーンなテキストです。ファインチューニングの行はページの実質的な内容を求めており、ナビゲーションバー、クッキーバナー、広告のマークアップなど、ナイーブなスクレイプを汚染するものは不要です。ターゲットページをクロールし、取り込み時にmarkdownに変換して、ボイラープレートを取り除きつつ、見出しやリストなどの構造を保持します。実際のボリュームではレート制限やIPブロックに直面するため、回転プールを通じてクロールをルートします。Scraper APIは、クリーンな出力とブロック抵抗を一度の呼び出しで実現するため、LLMに新鮮なウェブデータを供給するガイドで取り上げています。

# Sketch: crawl target URLs to clean markdown, ready for shaping into rows.
import requests

API = "https://api.quantumproxies.io/scrape"   # returns markdown, handles rotation

def fetch_markdown(url):
    r = requests.get(API, params={"url": url, "format": "markdown"},
                     headers={"Authorization": "Bearer YOUR_KEY"}, timeout=60)
    return r.json()["markdown"]

docs = [fetch_markdown(u) for u in seed_urls]   # clean text, no boilerplate

URLsからファインチューニングデータセットへのパイプライン図: ソースからクリーンなmarkdown、クリーニングと重複除去、JSONLメッセージとしてフォーマット、そしてデータセットカードとトレーニング/評価分割 — モデルはあなたのデータセットしか見ないので、ジャンクを取り除く各段階がファインチューニングを直接改善します。

トレーナーが期待するJSONL形式

ほとんどの現代のファインチューニングツールは会話形式のJSONLをデフォルトとしています: 1行に1つのJSONオブジェクト、それぞれがmessages配列を持ち、役割/コンテンツのペアで構成され、役割はsystem、user、assistantであり、user/assistantのターンが交互に続きます。これはHugging FaceやOpenAIスタイルのトレーナーが取り込むチャット形式です。古い指示データセットは3フィールドの形（instruction、input、output）を使用していますが、単一ターンの監督付きチューニングには適しており、マルチターンの会話形式も存在しますが、これらはメッセージ形式にクリーンに変換されます。1つのターゲット形式を選び、すべてをそれに標準化しましょう。

// One training example per line (.jsonl). Chat / messages format:
{"messages":[
  {"role":"system","content":"You classify support tickets by urgency."},
  {"role":"user","content":"My payment failed three times and the event is tomorrow."},
  {"role":"assistant","content":"high"}
]}
{"messages":[
  {"role":"system","content":"You classify support tickets by urgency."},
  {"role":"user","content":"How do I change my avatar?"},
  {"role":"assistant","content":"low"}
]}

トレーニング目標にフォーマットを合わせましょう: 継続的な事前トレーニングには生のテキスト、指示プラス出力やマルチターンチャットには監督付きファインチューニング、ランキングされた応答には好みベースの方法です。推論ファインチューニングを構築する場合は、質問と回答を保持しつつ、回答をモデルに学習させたい思考過程を含むように書き直しましょう。

クリーニング: 品質が決まる場所

これは結果を決定する段階であり、ほとんどが地味なフィルタリングです。ウェブソースまたはモデル生成の行が正しいと仮定しないでください — 検査しましょう。再発する失敗モードは具体的であり、名前でチェックする価値があります:

ラベルの不一致: 同じカテゴリがある行では「Positive」、別の行では「positive」と書かれている — 大文字小文字とスペリングを正規化しましょう。
ターゲット外の回答: アシスタントが正確なラベルやフォーマットの代わりに文やフォローアップの質問を返す。
誤ったラベルの行: 曖昧な入力に誤った出力が割り当てられる — 最も有害なノイズの一種。
ボイラープレートの残留物: ナビゲーションテキスト、クッキーノーティス、またはmarkdown変換を生き延びた「続きを読む」フラグメント。
重複: 同一またはほぼ同一の例が行数を膨らませ、モデルを繰り返しコンテンツに偏らせる。

良い習慣は、クリーニング前とクリーニング後のJSONLを両方保持し、削除したものを測定できるようにすることです。そして、カテゴリ間のバランスを保ちましょう — 過剰に代表されるクラスは、モデルにそれを過剰に予測させます。

重複除去とライセンス

ウェブデータは繰り返しが多いです — シンジケート記事、ミラードキュメント、ボイラープレートの段落 — 重複は静かにファインチューニングを傷つけ、繰り返されるものを過剰に重み付けします。2回のパスを行いましょう: 正規化されたテキストをハッシュして同一行をキャッチする正確な重複除去、次に類似またはシングリング技術（MinHashなど）を使用して、正確なハッシュが見逃すリワードされたコピーをキャッチする近似重複検出です。ライセンスについては、意図的に行動しましょう: 公開されているものすべてが自由に再利用できるわけではありません。各ドキュメントのソースとライセンスを追跡し、トレーニング使用を禁止する条件のコンテンツをフィルタリングし、再利用許可が明確なソースを優先しましょう。クロール中に出所を記録する方が、すべてを混ぜた後に再構築するよりもはるかに安価です。

LLM用のクリーンなウェブデータをソースする

結合、カード、分割

複数のソースから引き出す場合、すべてを1つの形式に標準化し、トレーニング前に単一の統一データセットにマージしましょう — 結合セットでの1回のクリーンなファインチューニングは、各ソースで順次ファインチューニングするよりも優れています。後者は、モデルが以前に学習したものを侵食する傾向があります。その後、データセットカードを書きましょう: データの出所、クリーニング方法、サイズとラベルの分布、ライセンス、既知の制限を記録した短い記録です。これにより、数ヶ月後にデータセットを再現可能で監査可能にします。最後に、トレーニングに使用しない評価分割を保持し、データを記憶したものではなく、正直にファインチューニングを測定できるようにしましょう。ファインチューニングではなく、検索システムにデータを供給する場合、RAGパイプラインガイドが同じ問題のリフレッシュ側をカバーしています。

ファインチューニングデータセットのサイズを示す統計パネル: 最低100行、最適には1000以上、合成生成には10のシード例、52000のAlpaca行 — 約100行未満ではファインチューニングはほとんど学習しません。1,000のクリーンな行を超えると、質が量を上回ります。

よくある質問

LLMをファインチューニングするには何行必要ですか？

合理的な結果を得るための実用的な最低限は約100行で、しっかりしたパフォーマンスを得るには1,000行以上が良い目標です。より多くのデータは通常助けになりますが、データがクリーンである場合のみです — 小さくてもよくラベル付けされたセットは、大きくてもノイズの多いものよりも優れています。合成生成には、少なくとも10の手書きの例でジェネレーターをシードし、最初に正確なフォーマットを学習させましょう。

ファインチューニングデータはどの形式にすべきですか？

JSONL — 1行に1つのJSONオブジェクト。ほとんどの現代のトレーナーは、messages配列を持つシステム/ユーザー/アシスタントの役割-コンテンツペアの会話形式をデフォルトとしています。古い指示データセットは指示/入力/出力フィールドを使用しています。トレーニング目標に基づいて1つのターゲット形式を選び、トレーニング前にすべてのソースをそれに標準化しましょう。

ファインチューニング用にスクレイプされたデータセットをどのようにクリーニングしますか？

ページをmarkdownに変換してボイラープレートを取り除き、次に手作業で一般的な失敗をフィルタリングします: ラベルの不一致、ターゲット外の回答、誤ったラベルの行、残ったナビゲーションやクッキーテキスト。正確なハッシュと近似重複パスで重複を除去し、カテゴリをバランスさせ、削除したものを測定できるように生のバージョンとクリーニングされたバージョンの両方を保持しましょう。

モデルをトレーニングするために任意のウェブコンテンツを使用できますか？

自動的にはできません — 公開されているからといって自由に再利用できるわけではありません。一部のコンテンツにはトレーニング使用を禁止する条件があり、個人データには独自のルールがあります。収集時に各ドキュメントのソースとライセンスを追跡し、トレーニングを許可しない条件のものをフィルタリングし、明確に許可されたソースを優先しましょう。これは一般的な情報であり、商業データセットには法的助言を求めてください。

ウェブからファインチューニングデータセットを構築することはフィルタリングパイプラインです: クリーンなmarkdownをソースし、トレーナーが期待するメッセージ形式に整形し、徹底的に重複除去とラベルチェックを行い、ライセンスをフィルタリングし、結果をカード化します。約1,000のクリーンな行を取得し、正直な評価分割を保持すれば、トレーニング予算をノイズではなく信号に費やすことができます。

QuantumProxiesのウェブデータでデータセットを構築する