第 1 章: 大規模言語モデル時代のデータ変換¶
章の概要¶
大規模言語モデル (LLM) の台頭により、人工知能のパラダイムが再形成されました。ただし、モデル アーキテクチャの革新は収束しており、モデルの機能の上限を真に決定するのは データ品質 です。この章では、スケーリング則の観点から「コア資産としてのデータ」という概念を確立し、LLM データのライフサイクル全体を体系的に紹介し、異種マルチモーダル データ、著作権コンプライアンス、コンピューティング コストなどの実際的な課題を検討します。
シナリオの紹介¶
あなたは AI スタートアップ企業のデータ リードです。チームは、公開 Web から 50TB の中国語テキストをクロールするのに 3 か月を費やし、自信を持って 7B パラメーターの基本モデルの事前トレーニングを開始しています。
しかし、トレーニングを開始して 2 週間が経過すると、ある時点で損失曲線が突然「平坦」になり、モデルの出力は広告コピー、反復的な SEO のジャンクで埋め尽くされ、特定の Web サイトのユーザー同意書さえも引用されるようになります。事後会議で、上級エンジニアが鋭い質問をしました。「トレーニング用のコンピューティングに 100 万ドルを費やした後、私たちは言語モデルを構築するのでしょうか、それともインターネットのゴミの圧縮されたインデックスを構築するのでしょうか?」
このシナリオは捏造されたものではありません。 OpenAI、Google、Meta、その他のトップラボはすでにコンセンサスに達しています。モデル アーキテクチャが収束する時代においては、データ品質がモデルのインテリジェンスの上限を決定する中心的な変数です。
1.1 スケーリングの法則の影響: 「ビッグデータ」から「高品質データ」へのパラダイムシフト¶
1.1.1 スケーリング則とは何ですか?¶
2020 年、OpenAI は画期的な論文 神経言語モデルのスケーリング則 を発表し、単純だが奥深い規則性を明らかにしました。つまり、モデルのパフォーマンス (損失で測定) は、モデル パラメーター数 \(N\)、データセット サイズ \(D\)、および計算 \(C\) という 3 つの核となる要素とのべき乗則の関係に従います。
ここで、\(L\) はモデルのクロスエントロピー損失、\(N_c、D_c、C_c\) は定数、\(\alpha\) はべき乗則指数です。簡単に言うと、モデルをよりスマートにするには、モデルのスケールを増やすか、より多くのデータを追加するか、より多くのコンピューティングに投資するかのいずれかになります。これら 3 つの要素が相互に制約し、LLM 時代の「不可能な三角形」を形成します。
この発見は学界と産業界に衝撃を与えました。これ以前は、深層学習の開発は「錬金術」に似ており、研究者は直感と経験に頼ってモデル アーキテクチャを調整し、偶然のブレークスルーを期待していました。スケーリング則の出現により、大規模モデルのトレーニングが芸術から工学科学に初めて移行し、企業は正確な数学モデルに基づいてリソースの投資と期待される成果を計画できるようになりました。
1.1.2 データ品質の「隠れた変数」¶
しかし、元のスケーリング法には重大な盲点がありました。それは、すべてのデータの「品質」が均一であることを前提としていたからです。この仮定は明らかに現実には当てはまりません。インターネット上のテキストの品質は、注意深く書かれた学術論文からタイプミスだらけのコメントまで多岐にわたり、データ間の価値の違いは桁違いに及ぶ場合があります。
2022 年、DeepMind のチンチラ論文はこの仮定を打ち破りました。研究チームは大規模な実験を実施しました。同じコンピューティング予算の下で、異なるモデル サイズとデータ量比率の効果を比較しました。この結果は業界に衝撃を与えました。Gopher のパラメータのわずか 4 分の 1 であるチンチラ (70B パラメータ) は、4 倍の高品質トレーニング データ (1.4T トークン) を使用することで、ほぼすべての評価タスクで 280B パラメータ Gopher を上回りました。
| モデル | パラメータ | トレーニングトークン | 最終パフォーマンス |
|---|---|---|---|
| ホリネズミ | 280B | 300B トークン | ベースライン |
| チンチラ | 70B | 1.4T トークン | Gopher を上回るパフォーマンス |
この調査により、長年無視されてきた事実が明らかになりました。つまり、業界はこれまで、データ量を過小評価しながらモデル規模で過剰適合していたということです。 Chinchilla の論文では、追加パラメータごとに、トレーニング データの約 20 トークンを割り当てる必要があるという「最適な比率」を推奨しています。これは、7B モデルのトレーニングには理論的には約 140B トークンの高品質コーパスが必要であることを意味します。これは、多くのチームが当初予想していた数をはるかに超えています。
1.1.3 質と量: Phi シリーズの極端な実験¶
Chinchilla が「データ量が過小評価されていた」ことを証明したとすれば、Microsoft の Phi シリーズはさらに過激な見解を示しました。つまり、データの品質がスケーリングの法則を無効にする可能性があるということです。
2023 年に、Microsoft Research は Phi-1 モデルをリリースしました。これは、わずか 13 億のパラメーターを備えた「小規模」モデルで、わずか 70 億のトークンでトレーニングされています。これは、数千億、さらには数兆のトークンを使用する当時の主流のアプローチとはまったく対照的です。しかし、一見「栄養失調」に見えるこのモデルは、コード生成タスクにおいて 10 倍のパラメータで競合他社を上回りました。
Phi-1 の秘密兵器は、クロールされた大量のデータではなく、教育的価値のある慎重に設計された合成データでした。研究者らは GPT-4 を使用して、基本的な構文から高度なアルゴリズムに至るまで、大量の構造化された段階的なプログラミング チュートリアルを生成し、完全な「人工教科書」を形成しました。これらの合成データには、ノイズがなく、エラーがなく、論理が明確で、難易度が段階的に上がるという、実際の Web データにはほとんど匹敵しない利点がありました。これらの「人工教科書」で訓練された小さなモデルは、実際のプログラミング問題を解決する際に驚くべき能力を示しました。
図 1-1: データ品質とモデルのパフォーマンスの関係 — クレンジング後の低品質データ (40% ノイズ) は高品質データ (5% ノイズ) になります
Phi シリーズの成功により、業界では「合成データ」に関する激しい議論が巻き起こりました。慎重に設計された合成データがこれほど優れた結果を生み出すことができるのであれば、従来の「クロール - クリーン トレイン」パラダイムを覆す必要があるでしょうか?第 7 章では、合成データの方法論とベスト プラクティスについて詳しく説明します。
1.1.4 データ エンジニアの中核となる使命¶
上記の調査を総合すると、LLM 時代のデータ エンジニアの中核となる使命が抽出できます。従来の通念では、「データは多いほど良い」と考えられていました。新しいパラダイムでは、データ品質がパフォーマンスの上限を決定し、ノイズの多いデータは役に立たないだけでなく有害であることが強調されています。以前は、「モデル アーキテクチャが競争上の優位性の中核である」と信じられていました。現在、アーキテクチャは統合されており、データが主要な差別化要因となっています。 「クリーニングは小さな前処理ステップである」という古い見方は時代遅れであり、データ クリーニングは現在、成功するモデル トレーニングの基礎とみなされています。同様に、「人間によるアノテーションはかけがえのないものである」という伝統的な信念は崩れました。高品質の合成データは、特定のシナリオでは実際のデータを超えることがあります。
「量より質」を「質のみで量は含まない」と誤解してはならないことを強調することが重要です。スケーリングの法則は依然として有効であり、同じコンピューティング予算の下での優先事項はデータ品質への投資であるべきです。極端な例: 100 個の完全なデータ ポイントでトレーニングされたモデルは、1T の高品質データ ポイントでトレーニングされたモデルを超えることはできません。質と量は対立するものではありません。実際の制約の下で最適なバランスを見つける必要があります。
1.2 LLM データの全ライフサイクル¶
「誕生」から「展開」まで、大規模な言語モデルは複数のトレーニング段階を経ますが、それぞれの段階で明確に異なるデータ要件があります。このライフサイクル全体を理解することが、資格のあるデータ エンジニアになるための第一歩です。
1.2.1 4 段階パラダイム: プレトレーニング → SFT → RLHF → RAG¶
図 1-2: LLM トレーニング データ パイプライン — TB レベルの事前トレーニングから KB レベルの RAG まで、データ量は減少しますが、品質要件は増加します
事前トレーニングは、大型モデルの人生の開始点です。この段階で、モデルは大量のラベルのないテキストから、文法構造、常識知識、世界の仕組みなど、言語の本質を学習します。事前トレーニング データのスケールは通常、TB レベルであり、Web ページ、書籍、コード、学術論文、その他のテキスト タイプからのソースを含む数兆のトークンが含まれます。この段階における主な課題は、重複排除、ノイズ除去、品質フィルタリング、および多様性のバランスです。一般的な事前トレーニング データセットには、Common Crawl、The Pile、RefinedWeb などがあります。
教師あり微調整 (SFT) は、モデルが「指示に従う」ことを学習する重要な期間です。事前トレーニングされたモデルは強力な言語理解能力を持っていますが、人間と効果的に対話する方法を知りません。 SFT ステージでは、命令と応答のペアのデータを使用して、ユーザーの意図を理解し、役立つ応答を提供するようにモデルを学習します。この段階でのデータ規模は GB レベルにまで低下し、慎重に作成された数十万から数百万の対話サンプルが含まれます。主な課題には、指示の多様性、応答の質、フォーマットの標準化の確保などが含まれます。 Alpaca、ShareGPT、および OpenAssistant は、この段階で一般的に使用されるデータセットです。
人間のフィードバックからの強化学習 (RLHF/DPO) は、モデルの出力を人間の好みに合わせてより「調整」することを目的としています。調整とは、モデルをより安全にする (有害なコンテンツを生成しない)、より役立つ (実際にユーザーの問題を解決する)、より正直にする (事実を捏造しない) ことを意味します。この段階では、ヒューマン・アノテーターが 2 つの応答候補のうちより良いものを選択する嗜好比較データが使用されます。データの規模はさらに数万から数十万サンプルに縮小しますが、アノテーションの品質要件は非常に高くなります。アノテーター間の合意、好みシグナルの精度、サンプル分布の範囲はすべて、慎重に制御する必要がある要素です。
RAG (RAG) は、モデルの知識の更新と幻覚に対処します。事前トレーニングがどれほど徹底されていても、モデルの知識には期限があり、「ナンセンスを話しながらも権威があるように聞こえる」ことを完全に避けることはできません。 RAG は、モデルに「外部ソースを参照」させることにより、エンタープライズ ナレッジ ベースや最新のドキュメントなどの外部情報を生成プロセスに挿入します。この段階のデータ ソースは通常、PDF ドキュメント、データベース レコード、Web コンテンツ、その他の構造化データまたは半構造化データを含む企業プライベートです。主な課題には、ドキュメントの解析、セマンティック Chunking、ベクトル化、検索精度の最適化などがあります。
1.2.2 データフローの「ファネルモデル」¶
データのライフサイクルを理解するためのもう 1 つの視点は、「ファネル モデル」です。生の Web データからトレーニングに使用できる最終的な高品質コーパスに至るまで、データ量が大幅に削減されます。
図 1-3: データ濾過ファネル — 100PB の生データから 10GB SFT データまで、保持率はわずか 0.00001%
一般的なトレーニング前のデータ処理ワークフローの場合: Common Crawl から 100PB の生の Web データを取得すると仮定します。 URL 重複排除と正確なコンテンツ重複排除の後、データ量は 30PB (保持率 30%) に低下する可能性があります。次に、言語識別と品質フィルタリング (対象外の言語、ポルノ/暴力コンテンツ、極端に短いテキスト、文字化けテキストを削除) により、データがさらに 5PB (保持率 5%) に削減されます。次に、複雑さ、繰り返し率、情報密度、その他の指標を使用したより詳細な品質評価により、おそらくわずか 1PB (保持率 1%) の最終的な事前トレーニング コーパスが得られます。そして、そこから SFT データを抽出または構築する必要がある場合、最終的な出力はわずか 10GB になる可能性があり、生データと比較して、保持率は 10 万分の 1 にまで低くなります。
実際のエンジニアリングでは、この比率を理解することが重要です。これは、クロール スケールの計画、ストレージ コストの予算編成、および処理パイプラインの設計に直接影響します。多くのチームはプロジェクト開始時にこの「消耗率」を過小評価しており、データの確保が不十分になり、プロジェクトの途中でやり直しが発生しました。
1.3 課題と機会: 異種マルチモーダルのゲーム、著作権コンプライアンス、および計算コスト¶
1.3.1 課題 1: 異種マルチモーダル データの処理の複雑さ¶
GPT-4V、Gemini、Sora などのマルチモーダル モデルの出現により、データ エンジニアリングの複雑さは飛躍的に増大しました。純粋なテキストの時代では、すべてのデータは UTF-8 でエンコードされた文字列でした。処理ツールチェーンは成熟し、標準化されました。マルチモーダル時代では、データ形式が爆発的に増加しました。画像には JPEG、PNG、WebP があります。ビデオには MP4、AVI、MKV があります。オーディオには WAV、MP3、FLAC があります。ドキュメントには PDF、Word、HTML があります。各形式には独自の解析方法と品質評価基準があります。
| 寸法 | 純粋なテキストの時代 | マルチモーダル時代 |
|---|---|---|
| データ形式 | 統一された UTF-8 テキスト | 複数のフォーマット: 画像、ビデオ、オーディオ、ドキュメント、Web ページ |
| ストレージ要件 | 結核レベル | PB レベル (画像/ビデオが優勢) |
| 位置合わせの難しさ | なし (純粋なテキストは位置合わせを必要としません) | 非常に高い (画像とテキストの配置、オーディオとビデオの同期、クロスモーダルのセマンティック一貫性) |
| ツールチェーンのクリーニング | 成熟した (FastText、KenLM) | 断片化 (各モダリティには独立したツールチェーンがあります) |
| 品質評価 | 複雑さ、重複排除率 | 美的スコア、CLIP-Score、OCR精度、ASRエラー率など |
さらに困難なのは、クロスモーダル調整の問題です。画像とキャプションを組み合わせる - テキストが画像の内容を正確に説明していることを確認するにはどうすればよいでしょうか?ビデオ内の音声とビジュアルはどのようにして正確に同期されているのでしょうか?これらの位置合わせの問題は純粋なテキストの時代には存在しませんでしたが、マルチモーダル データ エンジニアリングにおける中心的な課題です。
図 1-4: マルチモーダル データ処理の複雑さ — 線の太さは処理の難しさを示し、ビデオ (5/5) と PDF (4/5) が最も複雑です
エンジニアリング実践の観点から見ると、マルチモーダル データ処理にはモジュラー設計が必要です。各モダリティは、クロスモーダル調整の前に個別に処理されます。同時に、下流の処理の複雑さを軽減するために、WebDataset、TFDS などの統一データ形式標準を優先する必要があります。モダリティを意識した品質評価システムを確立することも重要です。画像には美的スコアと CLIP の類似性が必要で、音声には ASR の精度と話者分離品質が必要で、PDF には OCR の精度とレイアウト分析の精度が必要です。
1.3.2 課題 2: 著作権コンプライアンスのグレーゾーン¶
大規模なモデルのトレーニング データに関する著作権の問題は、技術的な議論から法的な戦場へと発展しました。 2023年、ゲッティイメージズは、Stable Diffusionのトレーニングに数百万枚の著作権で保護された画像を不正使用したとして、Stability AIを訴えた。 2024 年、ニューヨーク タイムズ は、GPT モデルが著作権を侵害しているとして OpenAI と Microsoft を訴えました。複数の国の規制当局は、AI 企業にトレーニング データ ソースの開示を要求し始めています。
これらの訴訟の結果は、AI 業界の発展の方向性に重大な影響を与えることになりますが、データ エンジニアにとって、問題の解決を待つのは明らかに賢明ではありません。現在のコンプライアンス戦略は、いくつかの側面から進めることができます。まず、ソースのトレーサビリティ - URL、クロール時間、元の著作権宣言などを含む、各トレーニング データ ポイントの完全なソース メタデータを記録します。 2 番目に、ライセンス フィルタリング - CC0、CC-BY、その他のオープン ライセンス コンテンツなど、AI トレーニングの使用に対する明示的な許可を持つデータを優先します。第三に、robots.txt プロトコルを尊重し、Web サイト所有者のクローラー制限宣言を尊重します。 4 番目に、データの機密保護を解除します。個人のプライバシーに関わるコンテンツを匿名化または削除します。
AI トレーニング シナリオにおける「フェアユース」の境界は依然として明確ではなく、適用される法的基準は国によって異なることに注意してください。したがって、法的環境が明確になったらデータ処理戦略を迅速に調整できるように、データ パイプラインに著作権フィルタリング インターフェイスを予約しておくことをお勧めします。
1.3.3 課題 3: コンピューティング コストの「隠れたキラー」¶
データ処理のコンピューティング コストは、多くの場合大幅に過小評価されます。多くのチームは、モデルのトレーニング コストの予算を立てるときに GPU トレーニング時間を計算するだけですが、データの前処理で同等以上のリソースが消費される可能性があることを無視しています。
10TB の生の Web データを処理するという実際的なシナリオを考えてみましょう。各データ ポイントには、HTML 解析、テキスト抽出、言語識別、品質スコアリング、重複排除チェックという平均 5 つのステップが必要であると仮定します。各ステップには項目ごとに 100 ミリ秒かかります (すでにかなり高速です)。合計処理時間はおよそ次のようになります: 10TB ÷ 10KB/アイテム × 0.5 秒/アイテム ≈ 150 万 GPU 時間。クラウド プロバイダーの価格では、これは数十万ドルを意味する可能性があり、モデルのトレーニング費用自体に匹敵します。
| シナリオ | トレーニング データの量 | トレーニング費用 (A100 時間) | モデルのパフォーマンス |
|---|---|---|---|
| 重複排除なし、直接トレーニング | 10Tトークン | 10,000時間 | ベースライン (繰り返しによる「リピーター」の問題を含む) |
| 重複排除後のトレーニング | 7Tトークン | 7,000時間 | ベースラインよりも優れています (データが繰り返されると学習効率が低下します) |
| 純利益 | - | 3,000 時間の節約 + より優れたモデル | - |
ただし、別の観点から見ると、データ エンジニアリングの投資収益率は非常に高くなる可能性があります。上の表は単純化したケースを示しています。データ重複排除にリソースを投資することで、トレーニング コストの 30% が節約されるだけでなく、モデルのパフォーマンスも向上します。これはデータ エンジニアリングの「レバレッジ効果」です。現在のコンピューティング価格 (A100 ～ 2 ドル/時間) では、1 時間のデータ処理作業で 10 時間の非効率なトレーニングを削減でき、20 倍の ROI が得られます。
図 1-5: データ品質とトレーニング効率の関係 — 緑色の曲線 (厳選されたデータ) が最も効率的で、30 ～ 70% の品質範囲で最大の ROI が得られます
1.3.4 機会: 障壁を下げる 3 つのトレンド¶
課題はあるものの、データ エンジニアにとっては今が絶好の参入時期です。 3 つの主要なトレンドにより、大規模モデルのデータ エンジニアリングへの障壁が大幅に下がります。
1 つ目のトレンドは、オープンソースの高品質データセットの出現です。初期の非公開の商用データとは異なり、近年では高品質のオープンソースの事前トレーニング データセットが数多く登場しています。 HuggingFace の FineWeb は、慎重にクリーニングされた 15T トークンの英語 Web データを提供します。 RedPajama は、LLaMA トレーニング データの完全な複製をオープンソース化しました。 DCLM は、ドメインに最適化されたデータセットを提供します。これらのオープンソース データセットにより、中小規模のチームが事前トレーニング コーパスを構築するコストが大幅に削減され、以前は大企業のみがアクセスできたリソースが手の届くところにできるようになります。
2 番目のトレンドは、AI ネイティブのデータ ツールの成熟です。従来のビッグ データ ツール (Hadoop、Spark など) は成熟していますが、AI トレーニング シナリオ向けに設計されていません。近年、LLM データ エンジニアリング用に設計された一連のツールが成熟してきました。 Alibaba の Data-Juicer は、すぐに使える数十のクリーニング オペレーターを備えたモジュール式のデータ処理パイプラインを提供します。 Dolma は、事前トレーニング データの最適化のために Allen AI が開発した大規模なテキスト処理ツールキットです。これらのツールを使用すると、データ エンジニアはゼロから構築することなく、巨人の肩の上に立つことができます。
3 番目のトレンドは、合成データの主流化です。前述したように、Microsoft Phi シリーズの成功は、合成データの巨大な可能性を実証しました。現在、GPT-4 などの強力なモデルを使用して、クロードがトレーニング データを生成することが業界標準になっています。この「強-先行-弱」戦略により、高品質のデータ取得が人間の注釈に完全に依存することがなくなり、データ準備の効率が大幅に向上します。ただし、合成データは新たな課題ももたらします。それは、モデルの崩壊をどのように回避するかということです。データの多様性を確保するにはどうすればよいでしょうか?これらの質問については、後続の章で詳しく説明します。
1.4 よくある誤解と落とし穴ガイド¶
特定の技術的な実践に入る前に、いくつかのよくある誤解を明確にする必要があります。こうした誤解は、良くてもリソースの無駄につながり、最悪の場合はプロジェクトの失敗につながる可能性があります。
誤解 1: 「データは多ければ多いほど良い」¶
これは最も一般的で最も有害な誤解です。プロジェクトを開始するときの多くのチームの最初の反応は、「できるだけ多くのデータをクロールする」ことです。ただし、前述したように、生データの保持率は通常、わずか 5 ～ 20% です。データ量をやみくもに追求すると、クロール、ストレージ、初期処理コストの 80% 以上が無駄になります。さらに悪いことに、後続の品質フィルタリングが十分に厳密でなく、低品質のデータがトレーニング セットに混入した場合、モデルのパフォーマンスに悪影響を及ぼす可能性があります。
正しいアプローチ: 最初に小規模データを使用して処理パイプライン全体の有効性を検証し、品質基準とフィルタリング戦略を確認してから、大規模なデータ収集に進みます。 「品質が第一、量が二番目」はデータ エンジニアリングの基本原則である必要があります。
誤解 2: 「すべてのデータを一度処理する」¶
データ処理は、1 回限りのタスクではなく、反復的なプロセスです。モデルのトレーニングによりデータの問題が明らかになり (例: 特定の種類の過剰なサンプルが偏りにつながる)、評価結果がデータ フィルタリング戦略の指針となる (例: 特定のドメインのデータを増強する必要がある)、法的コンプライアンス要件が変更される可能性があります (例: 特定のソースからデータを削除する必要がある)。
したがって、データ処理パイプラインは、再現可能な実行、増分更新、バージョンのロールバックを考慮して設計する必要があります。第 2 章では、データのバージョン管理に DVC、LakeFS などのツールを使用する方法について詳しく説明します。
誤解 3: 「トレーニング前のデータのみに注目する」¶
確かにトレーニング前のデータは LLM の基礎ですが、後続の段階のデータを無視することも同様に危険です。大規模なコーパスで十分に事前トレーニングされた基本モデルは、SFT データの品質が低い場合、平凡な対話モデルを生成する可能性があります。同様に、RLHF 設定データに一貫性のない注釈がある場合、モデルは不安定な動作を示す可能性があります。
ライフサイクル全体のデータ品質管理も同様に重要です。事前トレーニング、SFT、RLHF、および RAG データには、それぞれ独自の品質基準と評価システムが必要です。
誤解 4: 「オープンソース データはすぐに使用できる」¶
オープンソース データセットは参入障壁を大幅に下げますが、二次レビューなしでオープンソース データを直接使用するのは危険です。オープンソース データセットには、古いデータ (以前にクロールされた、最新の知識が欠けている)、バイアス (不均一なデータ分布)、ノイズ (一部のサンプルが品質基準を満たしていない)、著作権リスク (不明確なライセンス) がある可能性があります。
正しいアプローチは、オープンソース データを「完成品」ではなく「原材料」として扱うことです。オープンソース データの価値を最大化するには、独自のタスク要件に基づいた二次的なフィルタリング、拡張、およびバランシングが必要です。
1.5 章の概要¶
この章では、LLM 時代のデータ エンジニアリングの中核概念をスケーリング則の観点から体系的に説明しました。私たちはまず、チンチラの最適比率からファイ シリーズの極端な実験まで、「量より質」のパラダイム シフトを調査し、モデルのパフォーマンスにおける高品質データの決定的な役割を実証しました。
次に、LLM データ ライフサイクルの 4 つの段階 (事前トレーニング、SFT、RLHF、RAG) を導入しました。各ステージには、TB レベルのラベルなしテキストから数万のプリファレンス比較データ ポイントに至るまで、明確に異なるデータ要件があります。データ量は減少しますが、品質要件は増加します。この「ファネル モデル」を理解することが、データ リソースを計画するための基礎となります。
課題と機会のセクションでは、マルチモーダルな複雑さ、著作権コンプライアンス、コンピューティング コストという 3 つの実際的な問題を分析するとともに、オープンソース データセット、AI ネイティブ ツール、合成データという 3 つのトレンドからの機会も確認しました。
最後に、4 つのよくある誤解を明確にすることで、量よりも質、1 回限りではなく反復、フルサイクル管理、オープンソース データの二次処理という、データ エンジニアリングの正しい考え方を読者に確立しました。
図 1-6: 第 1 章 知識構造 — 4 つの主要テーマをカバー: スケーリングの法則、データ ライフサイクル、課題と機会
さらに読む¶
コアペーパー
神経言語モデルのスケーリング則、Kaplan et al. (2020) は、大規模モデルのリソース割り当てを理解するための基礎的な研究です。この OpenAI の論文では、モデルのスケール、データ量、コンピューティングの間のべき乗則の関係が初めて体系的に明らかにされ、その後の大規模モデル開発に理論的な指針が提供されました。
Training Compute-Optimal Large Language Models (Chinchilla 論文)、Hoffmann et al. DeepMind の (2022) は、業界に広く蔓延している「過剰パラメータ化」問題を指摘し、コンピューティングに最適なモデルとデータの比率に関する推奨事項を提供しました。
必要なのは教科書だけ (Gunasekar 他著) Microsoft Research の (2023) は、Phi シリーズの先駆的な研究であり、高品質の合成データによって小型モデルが大型モデルのパフォーマンスに匹敵することを可能にすることを証明しています。
オープンソース データセット
PenedoらによってリリースされたFineWeb HuggingFace のオープンソースの大規模で高品質な英語 Web データセットで、約 15T のトークンが含まれており、事前トレーニングのベース コーパスとして適しています。 Together AI によってリリースされた RedPajama は、LLaMA トレーニング データのオープンソースの複製であり、LLaMA トレーニング プロセスを再現したいチームにとって貴重です。
次の章のプレビュー¶
次の章 データ インフラストラクチャの選択 では、概念レベルからエンジニアリング レベルに移行します。適切なストレージ ソリューション (S3 対 MinIO)、コンピューティング フレームワーク (Spark 対 Ray)、データ形式 (Parquet 対 JSONL 対 WebDataset)、およびバージョン管理ツール (DVC 対 LakeFS) を選択する方法を学びます。
この質問を次の章に取り入れてください。リソースが限られている中で、スムーズに拡張しながら現在のニーズをサポートできるデータ インフラストラクチャをどのように設計しますか?