※本記事は、Stanford CS336 Language Modeling from Scratch（Spring 2025）の講義動画内容を基に作成されています。講義の詳細情報は https://stanford-cs336.github.io/spri... でご覧いただけます。スタンフォード大学のオンライン人工知能プログラムについての詳細は https://stanford.io/ai で、このコースへの登録方法については https://online.stanford.edu/courses/c... でご確認いただけます。本記事では、講義の内容を要約・整理しております。なお、本記事の内容は講義の内容を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講義動画をご視聴いただくことをお勧めいたします。
講師紹介： Percy Liang（パーシー・リャン）：スタンフォード大学コンピュータサイエンス准教授、基盤モデル研究センター（CRFM）ディレクター
この講義はStanford School of Engineeringのグローバル・オンライン教育センター（CGOE）によって運営・管理されています。CGOEはスタンフォード大学の教育と研究へのアクセスを拡大し、工学部全体および大学全体の教員と協力して、グローバルな視聴者向けに幅広いグローバル、オンライン、および企業教育をデザインし提供しています。
1. コース概要とモチベーション
1.1 AI研究者が基盤技術から切り離されつつある危機
Percy: 私たちはなぜこのコースを作り、その苦労を耐え忍ぶことにしたのでしょうか。GPT-4に「なぜゼロから言語モデルを構築するコースを教えるのか」と尋ねると、「コースを教えることで技術の基礎的理解を提供し、イノベーションを促進する」といった一般的な回答が返ってきます。しかし実際の理由はこうです。我々は危機に直面しています。研究者たちは基盤技術からますます切り離されつつあります。8年前、AI研究者は自分自身でモデルを実装し訓練していました。6年前でさえ、BERTのようなモデルをダウンロードして微調整することはまだ一般的でした。しかし今や、多くの人々は単にプロプライエタリなモデルをプロンプトするだけで済ませています。
これは必ずしも悪いことではありません。抽象化のレイヤーを導入することで、私たち全員がより多くのことを達成できるようになります。言語モデルをプロンプトできるようになったことで、多くの研究が可能になりました。私自身も相当量のプロンプティングを行っています。ですから問題はありません。しかし、これらの抽象化は「漏れやすい」ということを忘れないでください。プログラミング言語やオペレーティングシステムとは異なり、この抽象化が何であるかを本当には理解していません。それは入力と出力の文字列だけです。私は、データ、システム、モデルの異なる側面を共同設計することを必要とする基礎的な研究がまだ多く残っていると考えています。この技術の完全な理解は基礎的な研究に不可欠です。それがこのクラスが存在する理由です。私たちは基礎的な研究を継続できるようにしたいと考えており、私たちの哲学は「理解するには構築しなければならない」というものです。
1.2 言語モデルの産業化による大規模モデルへのアクセス制限
ここで一つ小さな問題があります。それは言語モデルの産業化によるものです。GPT-4は1.8兆パラメータで、訓練コストは1億ドルと噂されています。XAIは20万台のH100を持つクラスターを構築しており、4年間で5000億ドル以上の投資が行われるとされています。これらはかなり大きな数字です。さらに、これらのモデルがどのように構築されているかについての公開情報はありません。GPT-4からの引用ですが、2年前でさえ「競争環境と安全上の制限により、詳細は一切開示しない」と非常に正直に述べています。
これが現在の世界の状況です。ある意味では、フロンティアモデルは私たちの手の届かないところにあります。このクラスに参加して自分のGPT-4を訓練できると思ったなら、申し訳ありませんが、それは違います。私たちは小さな言語モデルを構築することになりますが、問題はこれらが代表的でない可能性があることです。
2つの例を挙げてその理由を説明します。簡単な例として、トランスフォーマーのアテンションレイヤーとMLPで使用されるフロップの割合を見てみると、これはかなり変化します。これはスティーブン・フラーからの数年前のツイートですが、今でも当てはまります。小さなモデルを見ると、アテンションとMLPレイヤーのフロップ数はほぼ同等に見えます。しかし、1750億パラメータに拡大すると、MLPが本当に支配的になります。なぜこれが重要なのでしょうか？小規模でアテンションを最適化することに多くの時間を費やすと、間違ったものを最適化している可能性があります。なぜなら、大規模では単にその影響が薄まってしまうからです。
これは計算なしでもグラフ化できる簡単な例です。もう少し難しい例として、創発的な振る舞いがあります。2022年のジェイソン・ウェイからの論文で、訓練フロップを増やして様々なタスクの精度を見ると、しばらくは精度に何も起こらないように見え、突然様々な創発現象（文脈内学習など）が現れることがわかります。この段階で止まっていると、言語モデルは本当に機能していないと結論づけてしまうでしょう。実際には、その振る舞いを得るためにはスケールアップする必要があったのです。
1.3 小規模モデルと大規模モデルの違い（注意機構とMLPのフロップ比率の変化など）
絶望しないでください。このクラスでも何かを学ぶことはできますが、何を学んでいるのかを正確に理解する必要があります。知識には3つのタイプがあります。まず、物事がどのように機能するかというメカニクスです。これは教えることができます。トランスフォーマーとは何かを教えることができ、実際にトランスフォーマーを実装することになります。モデル並列処理がGPUを効率的に活用する方法を教えることができます。これらは基本的な要素、つまりメカニクスです。それは問題ありません。
また、マインドセットも教えることができます。これはもう少し微妙で、少し曖昧に聞こえるかもしれませんが、ある意味ではより重要だと思います。私たちが採用するマインドセットは、ハードウェアから可能な限り多くを引き出し、スケーリングを真剣に考えるというものです。なぜなら、ある意味では、これらの要素はすべて長い間存在していましたが、OpenAIが先駆的に取り組んだスケーリングマインドセットこそが、次世代のAIモデルにつながったのです。マインドセットは、皆さんに特定の考え方を根付かせることができると思います。
第三に、どのようなデータやモデリングの決定が良いモデルにつながるかという直感です。これは残念ながら部分的にしか教えることができません。なぜなら、小規模で機能するアーキテクチャやデータセットが大規模で機能するものと同じとは限らないからです。しかし、3つのうち2.5を得られれば、それはかなり良いことではないでしょうか。
直感に関して言えば、トランスフォーマーの特定の要素がなぜそのようになっているのかについて多くの説明ができますが、時には単に実験をして実験結果が語るだけのこともあります。例えば、このSwiGLUを導入したNomの論文では、結果は非常に良く、これは採用されました。しかし結論では「これは神の恵みです」という正直な記述があります。これが私たちの理解の限界です。
1.4 学べる3種類の知識：メカニクス、マインドセット、直感
既に述べたように、このコースでは3種類の知識を学ぶことができます。1つ目はメカニクス、つまり物事がどのように機能するかという基本的な仕組みです。これには、トランスフォーマーの仕組み、モデル並列処理の仕組み、データ処理パイプラインなどが含まれます。これらは基本的な「材料」であり、技術的な基盤を形成します。
2つ目はマインドセットです。これは少し抽象的に聞こえるかもしれませんが、実際には非常に重要です。このマインドセットとは、ハードウェアから可能な限り多くを引き出し、スケーリングを真剣に考えるという考え方です。多くの技術的要素は長い間存在していましたが、OpenAIが先駆的に取り組んだスケーリングマインドセットこそが、今日の進化したAIモデルにつながりました。
3つ目は直感です。これは、どのようなデータやモデリングの決定が良いモデルにつながるかについての感覚です。これは残念ながら完全には教えられません。小規模で機能するアーキテクチャやデータセットが、大規模でも同様に機能するとは限らないためです。しかし、メカニクスとマインドセットを習得することで、この直感を養う基盤を構築することができます。
1.5 効率性の重要性とアルゴリズムの進化
「苦い教訓」（bitter lesson）について聞いたことがある人も多いと思います。苦い教訓とは「スケールだけが重要で、アルゴリズムは重要ではない。モデル構築により多くの資本を投入すれば良い」という誤解があるようです。これは真実とはほど遠いものです。正しい解釈は、スケールにおけるアルゴリズムこそが重要だということです。
最終的に、モデルの精度は効率性とリソース投入量の積です。実際、効率性はより大規模になるほど重要になります。数億ドルを費やす場合、ローカルクラスタでジョブを実行する場合のように無駄にすることはできません。失敗したら、デバッグして再実行するかもしれませんが、利用率を見れば、おそらくOpenAIは私たち全員よりもはるかに効率的です。
効率性は本当に重要です。さらに、スケーリングのレトリックではあまり理解されていないかもしれない点として、効率性（ハードウェアとアルゴリズムの組み合わせ）を見ると、2020年のOpenAIの優れた論文があります。この論文は、2012年から2019年の間に、ImageNetをある精度レベルで訓練するのにかかる時間において44倍のアルゴリズム効率の向上があったことを示しています。これは膨大な数字です。この効率性がなければ、44倍のコストを支払うことになります。これは画像モデルについてですが、言語についても同様の結果があります。
以上のことから、正しい枠組みやマインドセットは、「特定の計算とデータ予算が与えられた場合、構築できる最高のモデルは何か」ということです。この問いは、どのようなスケールでも意味を持ちます。なぜなら、リソースあたりの精度を考えているからです。もちろん、資本を投じてより多くのリソースを得ることができれば、より良いモデルが得られます。しかし研究者として、私たちの目標はアルゴリズムの効率性を向上させることです。効率性を最大化すること—これが何度も聞くことになるでしょう。
2. 言語モデルの歴史と現状
2.1 初期の言語モデルからの進化（シャノンから現代まで）
現在の状況について少し話しましょう。そして少し歴史を振り返ります。言語モデルはシャノンにまで遡り、英語のエントロピーを推定する方法として言語モデルを検討しました。AI分野では、言語モデルは機械翻訳や音声認識などの大きなシステムのコンポーネントとして、NLPで本当に顕著でした。
現在ではあまり認識されていないかもしれませんが、2007年にGoogleはかなり大規模なn-gramモデルを訓練していました。2兆トークンを超える5-gramモデルで、これはGPT-3よりもはるかに多いトークン数です。GPT-3が超える規模になったのはここ2年のことです。しかしそれらはn-gramモデルであったため、現在の言語モデルが示すような興味深い現象は示しませんでした。
2.2 2010年代の深層学習革命とトランスフォーマーの登場
2010年代には、多くの要素が揃い始めたと考えられます。最初のニューラル言語モデルは2003年にJoshua Bengioのグループによるものでした。seq2seqモデルはIlyaとGoogleの人々による、基本的にシーケンスをモデル化する方法についての研究でした。Adamオプティマイザーは、10年以上前に開発されたにもかかわらず、現在でも大多数の人々に使用されています。
アテンションメカニズムは機械翻訳の文脈で開発され、その後2017年に有名な「Attention is All You Need」、別名トランスフォーマー論文につながりました。人々はエキスパートのミクスチャをスケールする方法を研究していました。2010年代後半には、基本的にモデル並列処理を行う方法についての多くの研究がありました。実際に1000億パラメータのモデルをどのように訓練できるかを理解していました。これらはシステム関連の研究だったため長期間訓練することはなかったものの、2020年までには全ての要素が揃っていました。
NLPにおけるもう一つのトレンドは、大量のテキストで訓練され、幅広いダウンストリームタスクに適応できる基盤モデルという考え方でした。Elmo、BERT、T5などは、当時非常に刺激的だったモデルでした。BERTについて人々がどれほど興奮していたかは忘れがちですが、それは大きな進歩でした。
2.3 オープンAIの大規模化アプローチとGPT系列
歴史を簡潔に振り返ると、パズルの中でも重要な部分は、OpenAIがこれらの要素を取り入れ、非常に優れたエンジニアリングを適用し、スケーリング法則を本当に受け入れたことです。これがマインドセットの部分であり、GPT-2とGPT-3につながりました。
Googleはもちろんゲームに参加し、競争しようとしていました。しかし、これが別の研究の道を開いたと思います。これらはすべて非公開モデルでした。APIを通じてのみアクセスでき、リリースされていないモデルです。しかし、GPT-3が登場した直後のEleutherの初期の研究に始まり、うまく機能しなかったかもしれないMetaの初期の試みなど、オープンモデルもありました。そして、Meta、Alibaba、DeepSeek、AI2、そして他にもリストアップしていない数社が、重みがリリースされているこれらのオープンモデルを作成しています。
オープン性について重要な点は、オープン性には多くのレベルがあることです。GPT-4のような非公開モデルがあります。重みが利用可能でありながら、データセットについての詳細がない論文があるオープンウェイトモデルがあります。そして、重みとデータの両方が利用可能で、可能な限り説明しようとしている論文がある真のオープンソースモデルがあります。もちろん、論文では本当にすべてを把握することはできませんし、自分で構築する以外に技術を学ぶ代替手段はありません。
2.4 オープンモデルと非公開モデルの違い
オープン性について重要な点は、オープン性には多くのレベルがあることです。GPT-4のような非公開モデルがあります。これらは公開されておらず、APIでのみアクセス可能です。次に、重みが利用可能であり、アーキテクチャに関する詳細が記載された優れた論文があるけれども、データセットについての詳細がないオープンウェイトモデルがあります。
そして、すべての重みとデータが利用可能で、論文で正直にできる限り多くを説明しようとしているオープンソースモデルがあります。もちろん、論文では実際にはすべてを捉えることはできません。自分で構築することによって学ぶことに代わるものはありません。
2.5 現在のフロンティアモデルの状況
それでは現在の状況に話を進めましょう。現在、OpenAI、Anthropic、xAI、Google、Meta、DeepSeek、Alibaba、Tencentなど、おそらく他にもいくつかの企業から、多数のフロンティアモデルが提供されています。これらが現在の状況を支配しています。
私たちは興味深い時代にいます。すでに述べたように、多くの要素が開発されてきました。これは良いことです。なぜなら、これからそれらの技術がどのように機能するかを検討し、辿ることになるからです。そして、基本的にオープンコミュニティからの情報と、非公開モデルについて私たちが知っていることから読み取れることを使用して、フロンティアモデルのベストプラクティスにできるだけ近づくよう努めます。
3. コースの構成と課題
3.1 5つの授業単位と高い作業量
ウェブサイトはすべてオンラインにあります。これは5単位のクラスですが、おそらくこれは作業量のレベルを十分に表現していないかもしれません。コース評価から引用した言葉をご紹介します：「最初の課題全体が、CS224Nの5つの課題と最終プロジェクトを合わせたのとほぼ同じ量の作業でした」。最初の課題だけでそうなのです。皆さんを怖がらせるつもりはありませんが、ここではデータを提供しているだけです。
では、なぜそのような苦労に耐えるべきなのでしょうか？なぜそれをすべきなのか？このクラスは、物事がどのように機能するかをその原子のレベルまで理解したいという強迫観念を持つ人々のためのものです。このクラスを終えると、研究、エンジニアリング、そして大規模なMLシステムを構築する際の快適さのレベルが本当に向上していると思います。
また、このクラスを取るべきではない理由もあります。例えば、今学期に研究を進めたいなら、おそらくこのクラスは向いていません。最新の技術について学ぶことだけに興味があるなら、おそらく他のクラスの方がより適しています。BPEのデバッグに多くの時間を費やすのではなく、最新の技術を紹介できるクラスがあります。
これは本当に原始的なものから学ぶクラスであり、最新のものについてではありません。また、言語モデルやAPIを構築することに興味があるなら、これはおそらく最初に取るべきクラスではありません。実用的には、プロンプティングは素晴らしいし、ファインチューニングも素晴らしいです。それでうまくいくなら、それは絶対に始めるべきことです。
このクラスを受講して「どんな問題でも最初のステップは言語モデルをゼロから訓練することだ」と考えるようになってほしくありません。それは考え方として正しくありません。
3.2 基礎課題：トークン化、モデルアーキテクチャ、トレーニング
基礎的なユニットの目標は、完全なパイプラインの基本バージョンを動作させることです。ここで、トークナイザー、モデルアーキテクチャ、トレーニングを実装します。これらのコンポーネントについてもう少し詳しく説明しましょう。
トークナイザーは、文字列と整数のシーケンスの間を変換するものです。直感的には、整数は文字列をセグメントに分割し、各セグメントを整数にマッピングすることに対応すると考えることができます。これは、実際のモデルに入力される整数のシーケンスであり、固定した次元にする必要があります。このコースでは、比較的シンプルで、現在も使用されているByte Pair Encoding（BPE）トークナイザーについて説明します。
トークナイザーフリーのアプローチに関する有望な研究もあります。これらは生のバイトから始め、トークン化を行わず、特定のアーキテクチャを開発して生のバイトを処理する方法です。この研究は有望ですが、まだフロンティアまでスケールされていないので、今のところBPEを使用します。
文字列をトークン化して整数のシーケンスにしたら、次にこれらのシーケンスに対するモデルアーキテクチャを定義します。ここでの出発点は元のトランスフォーマーです。これは基本的にすべてのフロンティアモデルのバックボーンです。アーキテクチャ図を見ると、アテンションの部分とMLPレイヤーがあります。
2017年以降、多くの変化がありました。「トランスフォーマーが発明され、誰もがトランスフォーマーを使用している」という感覚があるかもしれませんが、それは大まかには正しいです。しかし、全体として大きな違いを生む小さな改良がいくつかありました。例えば、活性化関数であるSwiGLU、位置埋め込み、特にRotary Position Embedding（RoPE）、正規化（レイヤー正規化の代わりに似ているがよりシンプルなRMS正規化）、正規化の配置（オリジナルのトランスフォーマーから変更されています）などです。
MLPは従来の密なMLPですが、エキスパートのミクスチャーに置き換えることができます。アテンションは実際に多くの注目を集めています。フルアテンション、スライディングウィンドウアテンション、線形アテンションなどがあり、これらはすべて二次的な計算量の爆発を防ぐためのものです。GQAやMLAなどの低次元バージョンもあります。そして最も根本的なものとしては、ハイエナのような空間モデルなど、トランスフォーマーへの代替案もあります。これらはアテンションを使用せず、他の操作を行います。時にはこれらとトランスフォーマーを混合したハイブリッドモデルを作成することで、最良の両方を得ることができます。
アーキテクチャを定義したら、トレーニングが必要です。設計の決定には、オプティマイザーが含まれます。AdamWは基本的にAdamの修正版であり、現在も非常に広く使用されています。ただし、最近のMuanやSOPなどのオプティマイザーも有望なことは言及する価値があります。学習率スケジュール、バッチサイズ、正則化を行うかどうかなど、他にも多くの決定事項があります。詳細は重要です。適切に調整されたアーキテクチャと単純なトランスフォーマーの間には、容易に桁違いの差が出る可能性があります。
課題1では、基本的にBPEトークナイザーを実装します。これは実際に多くの作業が必要となるようで、皆さんに警告しておきます。また、トランスフォーマー、クロスエントロピー損失、AdamWオプティマイザー、トレーニングループも実装します。つまり、スタック全体です。PyTorchをゼロから実装する必要はありませんが、PyTorchのトランスフォーマー実装などは使用できません。使用できる関数の小さなリストがあり、それらだけを使用できます。
3.3 システム課題：カーネル、並列処理、推論
システム部分は、さらに最適化する方法について掘り下げます。ハードウェアからどのように最大限の性能を引き出すか？これには、ハードウェアとそれをどのように活用できるかをより詳しく見る必要があります。
このユニットには、カーネル、並列処理、推論という3つのコンポーネントがあります。まずカーネルについて話しましょう。GPUがどのように見えるか少し説明します。GPUは基本的に、浮動小数点演算を行うこれらの小さなユニットの巨大な配列です。注目すべき点の1つは、これがGPUチップであり、ここにはオフチップのメモリがあることです。また、L2キャッシュやL1キャッシュなどの他のメモリもチップ上にあります。
基本的な考え方は、計算はここで行われなければならず、データは別の場所にある可能性があり、計算を最も効率的にするためにどのように編成するかということです。簡単な例えをすると、メモリはデータやモデルパラメータを保存できる倉庫のようなものであり、計算は工場のようなものです。大きなボトルネックとなるのはデータ移動のコストです。GPUの利用率を最大化し、データ移動を最小化するために計算（行列乗算など）をどのように編成するか、これが重要です。フュージョンやタイリングなど、それを可能にする多くの技術があります。
詳細にすべて触れますが、カーネルを実装し活用するために、Tritonを使用します。これはOpenAIによって開発され、カーネルを構築するための人気のある方法です。他にもさまざまなレベルの洗練された方法がありますが、Tritonを使用します。いくつかのカーネルを作成します。
これは1つのGPUに対するものですが、一般的に、これらの大規模な実行には、数万台のGPUが必要です。8台でも興味深くなってきます。多くのGPUがあり、それらはCPUノードに接続され、NVMスイッチ、NVLinkを介して直接接続されています。同じ考え方です。GPU間のデータ移動はさらに遅いため、モデルパラメータ、活性化、勾配をGPUに配置し、計算を行い、移動量を最小化する方法を考える必要があります。データ並列処理やテンソル並列処理などの異なる技術を探索します。
最後に推論ですが、これは昨年のクラスでは実際には行いませんでしたが、ゲスト講義はありました。これは重要です。推論は、訓練されたモデルを使ってプロンプトから実際にトークンを生成するタスクです。また、強化学習、テスト時の計算、モデル評価など、他の多くのことにも役立ちます。
実際、推論に使われるグローバルなコストは、モデルを訓練するのに使われるコストを上回ると考えています。訓練は非常に集中的ですが、最終的に一度だけのコストです。推論はあなたのモデルを使用するたびにコストがかかり、より多くの人があなたのモデルを使用するほど、推論を効率的にする必要があります。
推論には、プリフィルとデコードの2つのフェーズがあります。プリフィルはプロンプトを取り、モデルを通して実行し、いくつかの活性化を得ます。デコードは自己回帰的に1つずつトークンを生成します。プリフィルでは、すべてのトークンが与えられるので、すべてを一度に処理できます。これはトレーニング時に見るものと全く同じであり、自然に並列化され、主に計算がボトルネックとなります。
推論を特別で難しくしているのは、この自己回帰的デコードです。1回に1つのトークンを生成する必要があり、すべてのGPUを飽和させるのが難しくなります。常にデータを移動しているため、メモリがボトルネックになります。推論を高速化するいくつかの方法について説明します。より安価なモデルを使うこともできますし、投機的デコードという本当にクールな技術もあります。これは、より安価なモデルを使って先に進み、複数のトークンを生成し、それらのトークンが何らかの定義で良いものであれば、フルモデルですべてを一度に並列でスコア付けして受け入れることができます。また、多くのシステム最適化も行うことができます。
課題2では、カーネルを実装し、並列処理も実装します。データ並列処理は非常に自然なので、それを行います。FSDPのような一部のモデル並列処理は、ゼロから実装するのがかなり複雑なので、その「赤ちゃんバージョン」を行います。クラスでは完全なバージョンを説明しますが、ゼロからの実装は少し難しいかもしれません。また、常にベンチマークとプロファイリングを行う習慣をつけることが重要です。これは実際におそらく最も重要なことです。物事を実装できますが、実装がどれだけうまくいっているか、ボトルネックがどこにあるかについてのフィードバックがなければ、盲目的に飛行しているようなものです。
3.4 スケーリング法則：小規模実験から大規模予測
スケーリング法則のユニットでは、小規模で実験を行い、物事を理解し、大規模でのハイパーパラメータと損失を予測することが目標です。基本的な疑問はこうです。フロップス予算が与えられた場合、どのモデルサイズを使用すべきでしょうか？より大きなモデルを使用すれば、より少ないデータで訓練できます。より小さなモデルを使用すれば、より多くのデータで訓練できます。では、適切なバランスはどこにあるのでしょうか？
これはOpenAIとDeepMindの一連の論文によって広範囲に研究され、解明されています。「チンチラ最適」という用語を耳にすることがあるかもしれませんが、これはこれを指しています。基本的な考え方は、計算予算（フロップス数）ごとに、モデルのパラメータ数を変化させることができるということです。そして、そのモデルがどれだけ良いかを測定します。
計算予算のレベルごとに、最適なパラメータ数を得ることができます。そして、カーブをフィットさせて外挿し、例えば1E22フロップスがあった場合のパラメータサイズを見ることができます。これらの最小値をプロットすると、実際に驚くほど線形であることがわかります。これにより、非常にシンプルだが有用な経験則が導き出されました。サイズnのモデルがある場合、それに20を掛けるとトレーニングすべきトークン数になります。つまり、14億パラメータのモデルは280億トークンで訓練すべきということです。
しかし、これは推論コストを考慮していません。これは文字通り、モデルの大きさに関係なく、最高のモデルをどのように訓練できるかということです。ここにはいくつかの制限がありますが、それでもモデル開発において非常に有用です。
この課題では、特定のハイパーパラメータセットでクエリできる「トレーニングAPI」を定義します。アーキテクチャ、バッチサイズなどを指定すると、その決定によって得られる損失が返されます。皆さんの仕事は、フロップス予算が与えられた中で、一連のモデルを訓練する方法を見つけることです。収集したデータにスケーリング法則をフィットさせ、より大きなスケールで選択するであろうハイパーパラメータ、モデルサイズなどについての予測を提出します。
これは、実際に賭け金がある状況に皆さんを置きたいと考えているケースです。これは実際の計算リソースを消費するわけではありませんが、フロップス予算を使い果たすと、それで終わりです。実験の優先順位をどのようにつけるかについて非常に注意深くなければなりません。これはフロンティアラボが常に行わなければならないことであり、フロップス予算内で損失を最小化するためのリーダーボードもあります。
3.5 データ課題：評価、データキュレーション
ここまでで、スケーリング法則を持ち、システムを構築し、トランスフォーマーを実装できるようになりました。実際のところ、もう完成したと言えるかもしれません。でも、データという本当に重要な要素がまだあります。ここで根本的な質問は「このモデルに何をしてほしいのか」です。モデルが何をするかは、主にデータによって決まります。多言語データで訓練すれば、多言語の能力を持ちます。コードで訓練すれば、コードの能力を持ちます。これは非常に自然なことです。
通常、データセットは多くの異なる部分の集合体です。これは「The Pile」からのものですが、これは4年前のもので、同じ考え方が今でも当てはまります。ウェブからのデータ（Common Crawl）、Stack Exchange、Wikipedia、GitHubなど、キュレーションされた異なるソースがあります。
データセクションでは、まず評価について話します。モデルがあるとき、それが良いかどうかをどのように評価するのか？パープレキシティ、MMULのような標準化されたテスト、指示に従うモデルが発話を生成する場合の評価方法、テスト時に推論やchain-of-thoughtを使用する場合の評価への影響、そしてシステム全体の評価（単なる言語モデルではなく、エージェントシステムなど）について話していきます。
評価を確立した後、データキュレーションを見ていきます。これは重要な点だと思います。人々は「インターネット上でモデルを訓練している」と言うのをよく聞きますが、これは意味をなしません。データは空から降ってくるわけではなく、インターネットから直接モデルにパイプできるわけでもありません。データは常に能動的に取得する必要があります。
例として、Common Crawlのデータを見てみましょう。10のドキュメントを取り、これが表示されます。これはCommon Crawlのランダムサンプルです。これはおそらく実際のテキストですが、ほとんどのCommon Crawlはスパムサイトであることがわかります。これは異なる言語かもしれませんが、ウェブの多くが単なる「ゴミ」であることもわかるでしょう。これは驚くべきことではないかもしれませんが、皆さんが予想するよりもはるかに多くのゴミがあります。
私が言いたいのは、データには多くの作業が必要だということです。インターネットをクロールしたり、書籍、アーカイブ、論文、GitHubを取得したりできますが、多くの処理が必要です。どのデータで訓練できるかという法的な問題もあります。
最近では、フロンティアモデルの多くが実際にデータを購入しなければならないことがあります。なぜなら、公にアクセス可能なインターネット上のデータは、フロンティアのパフォーマンスにとっては実際にやや限られているからです。また、スクレイピングされたこのデータは実際にはテキストではないことを覚えておくことが重要です。まず第一に、それはHTMLやPDF、コードの場合はディレクトリです。このデータを取得してテキストに変換する明示的なプロセスが必要です。
HTMLからテキストへの変換について話していきます。これは損失の多いプロセスになります。トリックは、コンテンツと構造の一部を、基本的にHTMLを持つことなく、どのように保持するかです。フィルタリングは、高品質なデータを取得するだけでなく、有害なコンテンツを削除するためにも非常に重要です。一般的に、人々はこれを行うために分類器を訓練します。重複除去も重要なステップです。
課題4はデータに関するものです。生のCommon Crawlダンプを提供しますので、その悪さを実際に見ることができます。分類器を訓練し、重複を除去します。そして、トークン予算内でパープレキシティを最小化するリーダーボードがあります。
3.6 アライメント課題：教師付き微調整、フィードバックからの学習
データを取得し、素晴らしいカーネルを構築し、訓練を行った今、実際にモデルを訓練することができます。この時点で得られるのは、次のトークンを予測できるモデルです。これは「ベースモデル」と呼ばれます。私はこれを、大きな潜在能力を持っているがアライメントや何らかの修正が必要なモデルと考えています。アライメントは、それを有用にするプロセスです。
アライメントには多くの異なる側面がありますが、主に3つのことを捉えています。1つは、言語モデルに指示に従わせることです。単に次のトークンを予測するだけでは、必ずしも指示に従うわけではありません。単に指示を完成させたり、指示の後に何が続くと思われるかを完成させたりするだけです。また、生成の文体を指定することもできます。長いか短いか、箇条書きにするか、機知に富んだものにするか、皮肉を含めるかなどです。ChatGPTとGrockを比較すると、異なるアライメントが行われていることがわかります。そして、安全性も重要です。これらのモデルが有害な可能性のある回答を拒否できることが重要です。ここでもアライメントが役立ちます。
一般に、アライメントには2つのフェーズがあります。まず「教師付き微調整」（SFT）です。ここでの目標は非常にシンプルです。基本的に、ユーザーとアシスタントのペア、つまりプロンプトと応答のペアのセットを収集し、教師付き学習を行います。ベースモデルはすでに基本的な能力を持っているので、いくつかの例だけで微調整するだけで十分です。もちろん、例が多ければ多いほど結果は良くなりますが、良いベースモデルからでも1000の例だけで指示に従う能力を与えるのに十分だという論文もあります。
この部分は実際にはとても簡単で、事前訓練とそれほど変わりません。テキストが与えられ、そのテキストの確率を最大化するだけです。
2つ目の部分はアルゴリズムの観点からはより興味深いです。SFTフェーズでも、かなり良いモデルが得られます。ではどのように改善するのでしょうか？より多くのSFTデータを得ることもできますが、それはかなり高価になる可能性があります。誰かが座ってデータに注釈を付ける必要があるからです。そこで、フィードバックからの学習の目標は、より軽いフォームの注釈を活用し、アルゴリズムにより多くの作業をさせることです。
利用できるデータ型の1つは選好データです。特定のプロンプトに対してモデルから複数の応答（AやB）を生成し、ユーザーがAとBのどちらが良いかを評価します。データは、「言語モデルを訓練する最良の方法は何ですか？大きなデータセットを使用するか、小さなデータセットを使用するか」といった形で、もちろん回答は前者であるべきです。これが選好を表現するためのデータの単位です。
持つことができる別のタイプの教師は検証器です。数学やコードなど、一部のドメインでは公式の検証器を持つ幸運な場合があります。あるいは、学習した検証器を使用することもできます。実際に言語モデルを訓練して、応答を評価させることもできます。これは評価にも関連しています。
アルゴリズムについては、強化学習の範囲に入ります。指示チューニングモデルに適用された最初のアルゴリズムの1つは、近接方策最適化（PPO）でした。選好データだけがある場合、直接選好最適化（DPO）と呼ばれるはるかにシンプルなアルゴリズムがあり、これは非常にうまく機能します。しかし一般に、検証器データから学習したい場合、完全に強化学習を採用する必要があります。このクラスで行うグループ相対選好最適化（GRPO）と呼ばれる手法があります。これはPPOを単純化し、値関数を削除することでより効率的にしたものです。DeepSeekによって開発され、かなりうまく機能しているようです。
課題5では、教師付き微調整、DPO、GRPOを実装し、もちろん評価も行います。
4. トークン化
4.1 トークン化の目的と原理（文字列から整数列への変換）
トークン化の基本概念
トークン化に関して、Andre Karpathyはトークン化について本当に素晴らしいビデオを作っています。一般的に、彼はゼロから物事を構築する方法についての多くのビデオを作っており、それがこのクラスの多くにインスピレーションを与えました。
既に述べたように、トークン化は基本的にユニコード文字列として表現される生のテキストを一連の整数に変換するプロセスです。各整数はトークンを表しています。文字列をトークンにエンコードし、それを文字列に戻すデコードする手順が必要です。語彙サイズは、トークンが取りうる値の数、つまり整数の範囲の数です。
トークナイザーの実例
トークナイザーがどのように機能するかの例を示すために、異なるトークナイザーを見ることができる本当に素晴らしいウェブサイトを使ってみましょう。例えば「hello」と入力すると、トークナイザーの出力である整数のリストが表示されます。また、元の文字列がどのように複数のセグメントに分解されるかも表示されます。
トークナイザーの特徴と注意点
いくつか注目すべき点があります。まず、スペースはトークンの一部です。古典的なNLPとは異なり、スペースは消えるのではなく、すべてが考慮されます。これらの操作は可逆的であることを意図しています。そして慣例として、スペースは通常トークンの前に来ます。
また、「hello」と「空白+hello」は完全に異なるトークンであることに注意してください。これは少し不快に感じるかもしれませんが、そういうものです。数字を見ると、それらは異なる部分に分割されていることがわかります。左から右への分割であり、セマンティックに千単位や他の何かでグループ化しているわけではありません。
トークン化の圧縮効率
GPT-2のトークナイザーを参照として使用すると、文字列を取り、GPT-2トークナイザーを適用し、インデックスを取得します。これは文字列からインデックスへのマッピングです。そして、それを再度デコードして文字列を取得することができます。これは単なるサニティチェックであり、実際に往復することを確認するためのものです。
もう一つ見ることが興味深いのは、圧縮率です。バイト数をトークン数で割ったものです。1トークンが何バイトのデータを表すかを示します。ここでは1.6です。つまり、各トークンは1.6バイトのデータを表しています。これがOpenAIが訓練したGPT-2トークナイザーです。
4.2 文字ベース、バイトベース、単語ベーストークン化の限界
BPEを動機付けるために、いくつかの試行を順番に見ていきたいと思います。トークン化をしたいとしたら、最も単純な方法は何でしょうか？恐らく最も単純なのは文字ベースのトークン化でしょう。ユニコード文字列はユニコード文字のシーケンスであり、各文字はコードポイントと呼ばれる整数に変換できます。例えば、「a」は97に、地球の絵文字は127,757にマッピングされ、それを戻すこともできます。各文字をコードポイントにマッピングするトークナイザーを定義できます。
これの問題点は何でしょうか？圧縮率が1です。つまり、あまり良くありません。実際には、文字はバイトではないので、圧縮率は厳密には1ではありませんが、期待するほど良くはありません。いくつかのコードポイントは本当に大きいという問題もあります。基本的に、すべての文字に対して語彙の中の1つのスロットを均一に割り当てていますが、一部の文字は他よりもはるかに頻繁に出現します。これは語彙の予算の非常に効果的な使用ではありません。
語彙サイズが巨大であるという問題もあります。語彙サイズが127というのは実際には大きな問題ですが、より大きな問題は、一部の文字が稀であり、これが語彙の非効率的な使用になるということです。この場合の圧縮率は1.5です。これはトークンあたりのバイト数であり、1文字が複数のバイトになることがあるためです。
これは非常にナイーブなアプローチでした。一方、バイトベースのトークン化も行うことができます。ユニコード文字列はバイトのシーケンスとして表現できます。すべての文字列はバイトに変換できるからです。「a」は既に1バイトですが、一部の文字はUTF-8エンコーディングを使用すると最大4バイトを占めることがあります。UTF-8はユニコードの最も一般的な動的エンコーディングです。
すべてをバイトに変換して、何が起こるか見てみましょう。バイトに変換すると、すべてのインデックスは0から256の間になります。なぜなら、バイトが取りうる値は定義上256種類しかないからです。語彙は非常に小さく、すべてのバイトが均等に使用されるわけではありませんが、あまり多くのスパースさの問題はありません。
しかし、バイトベースのエンコーディングの問題は何でしょうか？シーケンスが長くなります。ある意味では、バイトコーディングが機能することを本当に望んでいます。それは最も優雅なものですが、長いシーケンスになり、圧縮率は1です。1トークンあたり1バイトです。これは恐ろしいことです。圧縮率が1だと、シーケンスが本当に長くなります。アテンションはシーケンス長に関して二次的なので、効率性の観点から本当に悪い時間を過ごすことになります。
では、ここで考えられるのは、適応的である必要があるということです。すべてのトークンに文字やバイトを割り当てることはできませんが、一部のトークンは多くのバイトを表し、一部のトークンは少ないバイトを表すことができます。
これを行う一つの方法は単語ベースのトークン化であり、これはNLPでは非常に古典的なものでした。ここに文字列があり、それを一連のセグメントに分割できます。各セグメントをトークンと呼ぶことができます。正規表現を使用してこれを行います。GPT-2が事前トークン化に使用する異なる正規表現があり、これは単に文字列を一連の文字列に分割します。そして各セグメントに整数を割り当て、それで完了です。
これの問題点は何でしょうか？語彙サイズが基本的に無限ではないにしても、非常に大きくなる可能性があることです。新しい入力に対して、以前に見たことがないセグメントを得るかもしれません。これは本当に大きな問題です。単語ベースは実際には本当に厄介です。一部の実際の単語は稀であり、新しい単語には「UNK」トークンを割り当てる必要があります。パープレキシティの計算方法に注意しないと、単に間違った結果になる可能性があります。単語ベースは適応性の正しい直感を持っていますが、私たちが望むものではありません。
4.3 Byte Pair Encoding（BPE）の歴史と原理
ここで、ついにBPE（Byte Pair Encoding）について話します。これは実際には1994年にPhilip Gageによってデータ圧縮のために開発された非常に古いアルゴリズムでした。そして、これがニューラル機械翻訳のためにNLPに初めて導入されました。この論文の前、機械翻訳や基本的にすべてのNLPは単語ベースのトークン化を使用していました。単語ベースは問題があったので、この論文は1994年の素晴らしいアルゴリズムを使用できる、つまりトークン化を往復させることができ、UNKなどを扱う必要がない、というアイデアを先駆けました。
最終的にGPT-2を通じて、これが言語モデリングの時代に入りました。基本的な考え方は、分割方法についての事前に決められた概念を定義する代わりに、生のテキストでトークナイザーを訓練するというものです。これが基本的な洞察です。そして有機的に、複数の文字にまたがる一般的なシーケンスを1つのトークンで表現し、稀なシーケンスを複数のトークンで表現しようとします。
効率性のために、GPT-2の論文では、セグメントに分割するためのプリプロセッシングとして単語ベースのトークナイザーを使用し、その後各セグメントにBPEを実行します。これもこのクラスで行うことになります。
BPEアルゴリズムは実際には非常にシンプルです。まず、文字列をバイトのシーケンスに変換します。これはバイトベースのトークン化の部分で既に行いました。そして、隣接するトークンの中で最も一般的なペアを次々と統合していきます。直感的には、頻繁に出現するトークンのペアがある場合、それを1つのトークンに圧縮し、そのためのスペースを確保します。
4.4 BPEアルゴリズムの段階的解説と実装例
このアルゴリズムがどのように見えるか見ていきましょう。「cat and hat」を例として使用し、これを一連の整数に変換します。これらはバイトです。そして、統合したものを追跡します。マージは、バイトや他の既存のトークンを表す2つの整数から新しいトークンへのマッピングであり、語彙はインデックスからバイトへの便利な表現方法です。
BPEアルゴリズムは非常にシンプルです。コードを実行していきます。この回数だけ実行します。この場合は3回です。まず、バイトのペアの出現回数をカウントします。このシーケンスを順番に見ていき、「116 104」が出現したらそのカウントを増やし、「104 101」が出現したらそのカウントを増やすというように進めます。
カウントを取った後、最も頻繁に出現するペアを見つけます。複数ある場合はタイブレークを行い、「116 104」を選びます。これは2回出現しました。そして、そのペアを統合します。語彙に新しいスロットを作成します。これまで0から255ですが、今度は256に拡張します。そして、「116 104」が出現するたびに、それを256に置き換えます。
その後、その統合をトレーニングセットに適用します。その結果、「116 104」は256になり、この256は2回出現します。そして、このアルゴリズムを繰り返します。2回目は、「256 101」を統合することにしました。そして、インデックスのそれを置き換えます。インデックスは縮小していることに注目してください。これは、語彙を拡大するにつれて圧縮率が向上しているためです。もう一度実行します。次の統合は「257 3」です。これはさらに縮小します。そして完了です。
このトークナイザーを試してみましょう。「the quick brown fox」という文字列があり、これを一連のインデックスにエンコードします。そして、BPEトークナイザーを使用してデコードします。エンコードのプロセスを見ていきましょう。エンコードでは、文字列を取り、インデックスに変換し、発生した順序で統合を再生します。これらの統合を再生し、そしてインデックスを取得します。これが機能することを確認します。
それだけです。シンプルだからこそ非常に非効率的です。例えば、エンコードは統合の上でループします。実際には関連する統合のみをループするべきです。他にもベルやホイッスル、特殊トークン、事前トークン化などがあります。
あなたの課題では、基本的にこれを出発点として取り、または自分でゼロから実装し、実装を高速にすることが目標です。並列化したい場合もできます。楽しんでください。
4.5 効率的なトークン化の重要性と今後の展望
トークン化のまとめです。トークナイザーは文字列と整数のシーケンスの間をマッピングします。文字ベース、バイトベース、単語ベースのトークン化を見ましたが、これらは様々な理由で最適ではありません。BPEは1994年からの非常に古いアルゴリズムですが、今でも効果的なヒューリスティックであることが証明されています。重要なのは、コーパスの統計を見て、文字のシーケンスをどのように最もよく表現するかについて賢明な決定を行うということです。
いつか、このレクチャーをする必要がなくなり、単にバイトからマッピングするアーキテクチャを持つことができればと思いますが、それまでは、トークン化に対処する必要があります。
トークナイザーフリーのアプローチに関する有望な研究もありますが、これらはまだフロンティアまでスケールされていないので、今のところBPEを使用します。ただし、将来的には直接バイトから処理できるモデルアーキテクチャへの期待もあります。
効率的なトークン化は、言語モデルのパフォーマンスだけでなく、計算効率にも大きな影響を与えます。適切なトークン化により、シーケンス長を短縮し、アテンション計算の二次的な計算量を削減することができます。また、語彙サイズとトークンの割り当てを最適化することで、モデルの表現能力を向上させることができます。
今後、より効率的で言語に依存しないトークン化手法や、バイトレベルで直接処理できるアーキテクチャの発展が期待されています。しかし、現時点ではBPEが実用的かつ効果的な解決策であり続けています。
5. 効率性の重要性
5.1 コンピュートとデータ予算内での最適化
様々な部分についてのまとめとして、効率性がこの原動力となる原則であることを覚えておいてください。多くの異なる設計決定があり、すべてを効率性のレンズを通して見れば、多くのことが理解できると思います。
重要なのは、このクラスや比較的GPUリソースが少ない多くの人々は、現在計算制約のある状況にあるということです。データはたくさんありますが、それほど多くの計算リソースはありません。そのため、これらの設計決定はハードウェアから最大限の性能を引き出すことを反映しています。
例えば、データ処理では、貴重な計算リソースを悪質または無関係なデータに無駄にしたくないため、かなり積極的にフィルタリングを行います。トークン化については、バイト上のモデルを持つことは非常に優雅ですが、今日のモデルアーキテクチャでは計算効率が非常に悪いです。そのため、効率性を向上させるためにトークン化を行う必要があります。
モデルアーキテクチャには、基本的に効率性によって動機付けられた多くの設計決定があります。トレーニングに関しては、私たちがしていることのほとんどは単一のエポックだけです。これは明らかに急いでいることを示しています。任意のデータポイントに多くの時間を費やすのではなく、より多くのデータを見る必要があります。
スケーリング法則は完全に効率性に関するものです。ハイパーパラメータを見つけるために少ない計算リソースを使用します。アライメントは少し異なるかもしれませんが、効率性との関連は、アライメントにリソースを投入できれば、実際には基本モデルが小さくて済むということです。
2つの道があります。ユースケースが比較的狭い場合、おそらくより小さなモデルを使用し、それをアライメントまたは微調整して、うまく機能させることができます。しかし、ユースケースが非常に広範であれば、大きなモデルを訓練する代わりはないかもしれません。
現在はそうですが、フロンティアラボはますますデータ制約を受けるようになっています。これは興味深いことです。計算は常に重要ですが、設計決定は完全に変わるでしょう。例えば、データの1エポックを取ることは、より多くの計算リソースがある場合には意味がありません。なぜもっとエポックを取らないのか、あるいはもっと賢いことをしないのでしょうか？あるいは、トランスフォーマーは計算効率によって動機付けられたので、異なるアーキテクチャもあるかもしれません。
これについて考えるべきことですが、まだそれは効率性についてです。ただし、設計決定はあなたがどのような状況にあるかを反映しています。
5.2 ハードウェア効率の最大化
システム部分について詳しく見てみましょう。ハードウェアからどのように最大限の性能を引き出すのでしょうか？これについて理解するには、ハードウェアとその活用方法をより詳しく見る必要があります。
GPUがどのように見えるのか少し話しましょう。GPUは基本的に、浮動小数点演算を行うこれらの小さなユニットの巨大な配列です。注目すべき点の1つは、これがGPUチップであり、メモリは実際にはオフチップであるということです。また、L2キャッシュやL1キャッシュなどの他のメモリもチップ上にあります。
基本的な考え方は、計算はここで行われなければなりませんが、データは別の場所にある可能性があります。どのように計算を最も効率的に編成するかということが重要です。
簡単な例えをすると、メモリはデータやモデルパラメータを保存できる倉庫のようなものであり、計算は工場のようなものです。大きなボトルネックとなるのはデータ移動のコストです。GPUの利用率を最大化し、データ移動を最小化するためにどのように計算（例えば行列乗算）を編成するかが重要です。フュージョンやタイリングなど、それを可能にする多くの技術があります。
カーネルを実装し活用するために、Tritonを使用します。これはOpenAIによって開発され、カーネルを構築するための人気のある方法です。他にもさまざまなレベルの洗練された方法がありますが、Tritonを使用します。
これは1つのGPUに対するものですが、一般的に、大規模な実行には数万台のGPUが必要です。8台でも興味深くなってきます。多くのGPUがあり、それらはCPUノードに接続され、NVMスイッチ、NVLinkを介して直接接続されています。同じ考え方です。GPU間のデータ移動はさらに遅いため、モデルパラメータ、活性化、勾配をGPUに配置し、計算を行い、移動量を最小化する方法を考える必要があります。
データ並列処理やテンソル並列処理などの異なる技術を探索します。これらはすべて、GPUからできるだけ多くのパフォーマンスを引き出し、データ移動を最小限に抑えるためのものです。
推論についても考える必要があります。推論は、訓練されたモデルでプロンプトからトークンを生成するタスクです。推論のグローバルコストはモデル訓練のコストを超えていると考えられます。訓練は非常に集中的ですが、最終的に一度だけのコストです。推論はあなたのモデルを使用するたびにコストがかかり、より多くの人があなたのモデルを使用するほど、推論を効率的にする必要があります。
推論には、プリフィルとデコードの2つのフェーズがあります。プリフィルはプロンプトを取り、モデルを通して実行し、いくつかの活性化を得ます。デコードは自己回帰的に1つずつトークンを生成します。プリフィルでは、すべてのトークンが与えられるので、すべてを一度に処理できます。これはトレーニング時に見るものと全く同じであり、自然に並列化され、主に計算がボトルネックとなります。
推論を特別で難しくしているのは、この自己回帰的デコードです。1回に1つのトークンを生成する必要があり、すべてのGPUを飽和させるのが難しくなります。常にデータを移動しているため、メモリがボトルネックになります。
常にベンチマークとプロファイリングを行う習慣をつけることが重要です。これは実際におそらく最も重要なことです。物事を実装できますが、実装がどれだけうまくいっているか、ボトルネックがどこにあるかについてのフィードバックがなければ、盲目的に飛行しているようなものです。
5.3 データ処理とトークン化の効率化
データに関しては、多くの作業が必要であることを認識することが重要です。人々は「インターネット上でモデルを訓練している」と言うのをよく聞きますが、これは意味をなしません。データは空から降ってくるわけではなく、インターネットから直接モデルにパイプできるわけでもありません。データは常に能動的に取得する必要があります。
Common Crawlのデータを見ると、ほとんどがスパムサイトや「ゴミ」であることがわかります。これは驚くべきことではないかもしれませんが、皆さんが予想するよりもはるかに多くのゴミがあります。インターネットをクロールしたり、書籍、アーカイブ、論文、GitHubを取得したりできますが、多くの処理が必要です。
実際、私たちは現在、計算制約のある状況にあります。データはたくさんありますが、それほど多くの計算リソースはありません。そのため、私たちの設計決定はハードウェアから最大限の性能を引き出すことを反映しています。例えば、データ処理では貴重な計算リソースを悪質または無関係なデータに無駄にしたくないため、かなり積極的にフィルタリングを行います。
また、スクレイピングされたデータは実際にはテキストではないことを覚えておくことが重要です。それはHTMLやPDF、コードの場合はディレクトリです。このデータを取得してテキストに変換する明示的なプロセスが必要です。HTMLからテキストへの変換は損失の多いプロセスになります。トリックは、コンテンツと構造の一部を、基本的にHTMLを持つことなく、どのように保持するかです。
フィルタリングは、高品質なデータを取得するだけでなく、有害なコンテンツを削除するためにも非常に重要です。一般的に、人々はこれを行うために分類器を訓練します。重複除去も重要なステップです。同じコンテンツが繰り返し現れることを防ぎ、データの多様性を確保します。
トークン化に関しては、バイト上のモデルを持つことは非常に優雅ですが、今日のモデルアーキテクチャでは計算効率が非常に悪いです。そのため、効率性を向上させるためにトークン化を行う必要があります。BPEは計算効率の観点から現在の最良の妥協点です。それにより、シーケンス長を短縮し、アテンション計算の二次的な計算量を削減することができます。
データとトークン化の効率化は、単に理論的な関心事ではなく、実用的な必要性です。特に大規模な言語モデルを訓練する際には、これらの効率化がなければ、訓練コストが法外に高くなるか、あるいは不可能になるでしょう。データ処理パイプラインを注意深く設計し、適切なトークン化戦略を選択することで、同じ計算予算でより良いモデルを構築することができます。
5.4 スケーリング法則を用いた効率的なハイパーパラメータ選択
スケーリング法則のユニットでは、小規模で実験を行い、物事を理解し、大規模でのハイパーパラメータと損失を予測することが目標です。基本的な疑問はこうです。フロップス予算が与えられた場合、どのモデルサイズを使用すべきでしょうか？より大きなモデルを使用すれば、より少ないデータで訓練できます。より小さなモデルを使用すれば、より多くのデータで訓練できます。では、適切なバランスはどこにあるのでしょうか？
これはOpenAIとDeepMindの一連の論文によって広範囲に研究され、解明されています。「チンチラ最適」という用語を耳にすることがあるかもしれませんが、これはこれを指しています。基本的な考え方は、計算予算（フロップス数）ごとに、モデルのパラメータ数を変化させることができるということです。そして、そのモデルがどれだけ良いかを測定します。
計算予算のレベルごとに、最適なパラメータ数を得ることができます。そして、カーブをフィットさせて外挿し、例えば1E22フロップスがあった場合のパラメータサイズを見ることができます。これらの最小値をプロットすると、実際に驚くほど線形であることがわかります。これにより、非常にシンプルだが有用な経験則が導き出されました。サイズnのモデルがある場合、それに20を掛けるとトレーニングすべきトークン数になります。つまり、14億パラメータのモデルは280億トークンで訓練すべきということです。
しかし、これは推論コストを考慮していません。これは文字通り、モデルの大きさに関係なく、最高のモデルをどのように訓練できるかということです。ここにはいくつかの制限がありますが、それでもモデル開発において非常に有用です。
フロップス予算が与えられた中で、一連のモデルを訓練する方法を見つけることが重要です。収集したデータにスケーリング法則をフィットさせ、より大きなスケールで選択するであろうハイパーパラメータ、モデルサイズなどについての予測を提出します。
これは、実際に賭け金がある状況に皆さんを置きたいと考えているケースです。フロップス予算を使い果たすと、それで終わりです。実験の優先順位をどのようにつけるかについて非常に注意深くなければなりません。これはフロンティアラボが常に行わなければならないことです。
スケーリング法則は完全に効率性に関するものです。ハイパーパラメータを見つけるために少ない計算リソースを使用します。これにより、大規模実験に進む前に、小規模な実験からより良い設計決定を行うことができます。これは、限られたリソースを最大限に活用するための重要な戦略です。
5.5 アライメントによる効率的なモデル活用
アライメントは少し異なるかもしれませんが、効率性との関連は、アライメントにリソースを投入できれば、実際には基本モデルが小さくて済むということです。
ここには2つの道があります。ユースケースが比較的狭い場合、おそらくより小さなモデルを使用し、それをアライメントまたは微調整して、うまく機能させることができます。しかし、ユースケースが非常に広範であれば、大きなモデルを訓練する代わりはないかもしれません。
ベースモデルを訓練した後、アライメントの第一段階である教師付き微調整（SFT）を行います。ここでの目標は非常にシンプルです。基本的に、ユーザーとアシスタントのペア、つまりプロンプトと応答のペアのセットを収集し、教師付き学習を行います。ベースモデルはすでに基本的な能力を持っているので、いくつかの例だけで微調整するだけで十分です。もちろん、例が多ければ多いほど結果は良くなりますが、良いベースモデルからでも1000の例だけで指示に従う能力を与えるのに十分だという論文もあります。
SFTフェーズでも、かなり良いモデルが得られます。その後、DPO（Direct Preference Optimization）やGRPO（Group Relative Preference Optimization）などの手法を使用して、より軽いフォームの注釈を活用し、モデルをさらに改善することができます。これにより、より少ないリソースでより良いパフォーマンスを得ることができます。
アライメントの効率性は、特定のタスクやドメインに特化したモデルを構築する際に特に顕著です。例えば、コード生成や医療応用など、特定の分野に焦点を当てたモデルは、同じサイズの汎用モデルよりも優れたパフォーマンスを発揮することがあります。これは、利用可能な計算リソースを最大限に活用する上で重要な考慮事項です。
アライメントを効率的に行うことで、モデルサイズとトレーニングコストを削減しながら、特定のユースケースに対して高品質な結果を得ることができます。これは、計算リソースが限られている環境で特に重要です。アライメントは、単にモデルを「より良く」するだけでなく、「より効率的に」するための手段でもあるのです。
