7,682 文字
みなさん、こちらをご覧ください。Llama 3.1モデルが、oLamaに関する単純な質問に答えようとしているところです。このモデルはoLamaについて全く理解していません。では、同じ質問を、oLamaのドキュメントでファインチューニングされた同じモデルにしてみたらどうなるか見てみましょう。違いに注目してください。これがファインチューニングで得られた結果です。今日は、ファインチューニングとは何か、いつ使うべきか、そしてどう準備すべきかを詳しくお話しします。
まず、ファインチューニングに関する最大の誤解を解消しましょう。通常、これはモデルに新しい情報を教えることではありません。その目的にはRAG（検索拡張生成）の方がずっと適しています。なぜなら、モデルは既に膨大な知識を持っているからです。ファインチューニングが通常行うのは、既存の知識をより焦点を絞って、より効果的に活用できるようにすることです。
こう考えてみてください。ベースモデルは、すべての医学の教科書を読んだ一般開業医のようなものですが、一般的な言葉で話します。ファインチューニングは、その医師に特定の詳細に焦点を当て、特定の症状についてより正確にコミュニケーションを取れるように教えるようなものです。新しい医学知識を追加しているわけではありません。多少は入り込むかもしれませんが、既存の専門知識の使い方を洗練させているのです。
しかし、ちょっと待ってください。「デモで見せたのはまさに新しい情報を追加することじゃないの？」と思われるかもしれません。はい、その通りです。私は、oLamaについて何も知らないモデルを、oLamaのドキュメントから抽出した2500の質問と回答でファインチューニングしました。そして結局、私が示せた信頼できる例は、お見せしたものだけでした。ファインチューニングは新しい情報を追加するには最悪の方法ですが、既存の知識の共有方法を調整するには優れた方法です。
この区別は重要です。なぜなら、それによってファインチューニングが適している場合と適していない場合を理解できるからです。ベースモデルにない知識が必要な場合、ファインチューニングはほんの少ししか役立ちません。しかし、モデルが既存の知識をより焦点を絞って明確に表現する必要がある場合、それこそがファインチューニングが真価を発揮する場面です。
詳しく説明する前に、チャンネル登録と通知をオンにしてください。Axel、UNSSloth、MLXなど、異なるツールを使ってファインチューニングを実装する方法を紹介するシリーズを予定しています。それぞれに利点があり、すべてを探っていきます。最初にどのツールについて学びたいか、コメントで教えてください。
ファインチューニングが新しい知識を追加することではないと理解したところで、実際にどのように機能するのか説明しましょう。プロンプトを書くとき、基本的にはモデルに実行時の指示を与えています。誰かに従ってもらうためのメモを残すようなものです。一方、ファインチューニングは、モデルの内部のコンパスを調整するようなもので、特定のパターンやレスポンスのスタイルに自然に傾くように教えます。
ファインチューニングの主なアプローチを分解して説明しましょう。まず、完全なファインチューニングがあります。これはモデルのすべてのパラメータを調整します。モデルを完全な再トレーニングのために学校に送り返すようなものです。非常に強力ですが、欠点があります。深刻な計算リソースが必要です。複数のGPUと、場合によっては数日から数週間のトレーニング時間が必要になります。ほとんどの人はそのようなハードウェアを持っていません。
そこでLoRAの出番です。Low-Rank Adaptation（低ランク適応）は、すべてを調整する代わりに、より小さなパラメータセットを修正します。完全な見直しではなく、特定の分野で的を絞ったトレーニングをモデルに与えるようなものです。結果は完全なファインチューニングとほぼ同じですが、計算コストは大幅に少なくて済みます。これは、ほとんどの人がファインチューニングプロジェクトで使用すべき方法です。
そして、QLoRA（Quantized LoRA）があります。これはプロセスをさらに効率的にします。賢明な数学的トリックを使って、品質を維持しながらメモリ要件を削減します。低スペックのGPUや優れたCPUで作業している場合、これが最適な選択肢かもしれません。
しかし、これらすべての方法について重要なことがあります。それらは新しい事実をモデルに教えることではありません。代わりに、情報がどのように提示されるべきかのパターンを認識するようにモデルを訓練することです。複数の言語を知っている人に、特定の言語と特定のスタイルを一貫して使うように教えるようなものです。
具体的な例を挙げましょう。APIドキュメント用にモデルをファインチューニングするとします。モデルは既にAPIやHTTPメソッド、ドキュメントの書き方について知っています。ファインチューニングが行うのは、この情報を好みのスタイルで一貫してフォーマットし、特定の用語を使用し、ユーザーにとって最も重要な側面に焦点を当てるように教えることです。これが、トレーニングデータの品質が非常に重要な理由ですが、それについては後で説明します。
先に進む前に、すべてのファインチューニングプロジェクトで遭遇するパラメータについて簡単に説明しましょう。これらは、どのツールを選んでも理解する必要がある普遍的なコントロールと考えてください。
学習率は、モデルが学習中に取るステップの大きさのようなものです。大きすぎると、60マイルで縦列駐車を試みるように、最適な解決策を行き過ぎてしまう可能性があります。小さすぎると、トレーニングに永遠に時間がかかります。適切な学習率を見つけることは、ファインチューニングを成功させる上で重要です。
バッチサイズは、モデルが知識を更新する前に見る例の数を決定します。大きなバッチはより安定した学習を提供しますが、より多くのメモリが必要です。一口で味を見て料理を調整するのと、プレート全体を一度に試すような違いです。
エポック数は、モデルがデータセット全体を見る回数です。少なすぎるとパターンを学習できない可能性があり、多すぎるとオーバーフィッティングのリスクがあります。スターウォーズの引用例を使って、それが実際に何を意味するのか説明します。適切なポイントを見つける必要があります。
そして、オプティマイザーの選択があります。これは異なる教授法を選ぶようなものです。AdamWのようなオプティマイザーは優れたオールラウンダーですが、特定のユースケースではほかのものがより適している場合があります。
ファインチューニングがボンネットの下でどのように機能するかを理解したところで、最も重要な質問に取り組みましょう。実際にいつ使用すべきでしょうか？ファインチューニングは強力ですが、必ずしも正しいツールとは限りません。ファインチューニングが本当に輝く場面と、完全に避けるべき場面を見ていきましょう。
最初の完璧なユースケースはドメイン適応です。Kubernetesを扱っているとします。ベースモデルは既にKubernetesについて知っています。ポッド、デプロイメント、サービスを理解しています。しかし、説明が一般的すぎたり、チームが好む用語を一貫して使用していない可能性があります。ファインチューニングは、より正確になり、常に公式のKubernetesパターンを参照し、実世界のシナリオで実際に意味のある例を提供するように教えることができます。
2番目の主要なユースケースはスタイルマッチングです。これはドキュメントやカスタマーサポート全体の一貫性を維持する上で非常に重要です。APIドキュメントを特定の方法で書くとします。パラメータを特定の順序で説明したり、コード例に特定のフォーマットを使用したいかもしれません。ファインチューニングは、すべてのプロンプトで詳しく説明しなくても、モデルが自然にこれらのパターンに従うようにできます。
しかし、ここで人々がファインチューニングを無駄に試みる場面があります。最初のシナリオは、モデルに特定の方法で時々応答してほしい場合です。それはプロンプトエンジニアリングの仕事です。シャベルが必要なときにブルドーザーを持ち出す必要はありません。
2番目の罠は、モデルに新しい最新の情報を教えようとすることです。先ほど述べたように、ファインチューニングは新しい知識を追加できません。先月リリースされたフレームワークについてモデルに知ってもらう必要がある場合、ファインチューニングは確実には役立ちません。新しいベースモデルを待つか、別の動画で説明した検索拡張生成を使用する必要があります。
私がよく目にする3番目の間違いは、データが少なすぎる状態でファインチューニングを試みることです。10や20の例しかない場合、オーバーフィッティングと呼ばれる危険なことが起こります。こう考えてください。スターウォーズの引用文だけを使って誰かに英語を教えるようなものです。その特定の引用文は完璧に学習するかもしれませんが、一般的な英語は理解できないでしょう。実際、意味がない場合でも、すべての会話にスターウォーズの参照を無理やり入れようとするかもしれません。
これは、データが少なすぎる状態でファインチューニングを行うと、まさにそうなります。モデルはあなたの少数の例に特化しすぎて、一般化する能力を失います。トレーニングデータと全く同じ状況では完璧な応答を提供するかもしれませんが、それ以外のすべてが悪化します。パターンを暗記するのではなく、パターンを教えるには、十分な多様な例が必要です。その過度の特殊化がオーバーフィッティングと呼ばれます。
ボーナスステップとして、これらのアプローチを組み合わせるのが最適なユースケースの場合もあります。技術文書のドメイン専門知識とスタイルの両方についてファインチューニングする場合などです。それは完全に問題ありません。
しかし、これは任意のファインチューニングプロジェクトで最も重要な部分であるトレーニングデータの話につながります。ファインチューンされたモデルは、トレーニングに使用したデータと同じくらいの品質しか持てません。これは、ほとんどのプロジェクトが見事に成功するか、悲惨に失敗するかの分かれ目です。
モデルはトレーニングデータと同じくらいの品質しか持てないので、品質と量の適切なバランスを見つける話をしましょう。データが少なすぎるとオーバーフィッティングの問題が起こることは先ほど話しました。それは依然として現実の懸念です。暗記ではなくパターンを教えるには、十分な例が必要です。私の経験では、良い結果を見始めるには少なくとも数百の例が必要です。
しかし、ここで興味深いことがあります。より多くのデータが必ずしも良いとは限りません。実際、100から500の高品質な例の方が、10,000の平凡な例よりも良い結果を生み出すのを見てきました。なぜなら、一貫性が生の数字よりも重要だからです。データは優れた教師のようである必要があります。明確で、一貫性があり、モデルに実際に学んでほしいことに焦点を当てています。
よく見かける間違いがあります。人々は文書データベース全体をトレーニングセットにダンプします。より多くのデータが良いと考え、持っているものすべてをモデルに投げ込みます。これはやめましょう。これは、今まで書かれたすべての料理本を読ませることで誰かに料理を教えようとするようなものです。代わりに、モデルに学んでほしいことを正確に表す例を慎重に選択してください。
トレーニングデータの高品質さを構成する要素について説明しましょう。まず、フォーマットとスタイルが一貫している必要があります。例の半分が正式な言葉を使用し、半分がカジュアルな場合、モデルを混乱させるだけです。次に、エラーや矛盾がないことが必要です。モデルは良い実践と同じくらい簡単にあなたの間違いを学習します。そして3つ目に、すべての例があなたの特定のユースケースに関連している必要があります。
フォーマットも重要です。実装チュートリアルで具体的なフォーマットについて詳しく説明しますが、知っておく必要があることは以下の通りです。すべてのトレーニング例には、モデルに尋ねる明確な入力、応答してほしい方法を示す明確な出力、そしてオプションでステージを設定するためのコンテキストやシステムプロンプトが必要です。
多くの人が見落としていることがあります。トレーニングデータにエッジケースと失敗シナリオを含めることです。コードを扱うモデルをトレーニングする場合、エラーを適切に処理する方法の例を含めます。カスタマーサポートのトレーニングを行う場合、不明確または不可能な要求への対処方法の例を含めます。これはモデルがその境界と制限を理解するのに役立ちます。
トレーニングデータを新入社員の教育のように考えてください。一般的なケース、エッジケース、そしてその間のすべてをカバーするのに十分な例が必要です。しかし、間違った基盤で始めると、最高のトレーニングデータでも役に立ちません。
これは、もう一つの重要な決定、ベースモデルの選択につながります。異なる生徒が異なる方法で学ぶように、各ベースモデルには独自の特徴と要件があります。プロジェクトに適したものを選ぶ方法について説明しましょう。
家の基礎を選ぶようなものです。世界最高の建材を持っていても、基礎が正しくなければ何も意味がありません。まず、モデルのサイズについて説明しましょう。Llama 3の370億パラメータのような大きなモデルは非常に強力です。コンテキストをより良く理解し、ミスが少なく、一般的により微妙なニュアンスのある応答を提供します。
しかし、欠点があります。それらはリソースを大量に消費する怪物です。実行するだけでも、ファインチューニングはなおさら、深刻なGPUパワーが必要です。複数の高性能GPUと、潜在的には数千ドルのクラウドコンピューティングコストが必要になります。
ここで、Llama 3.2 3Bのような小さなモデルが真価を発揮します。確かに、大きな兄弟ほど洗練されていないかもしれません。しかし、ここで重要なことは、ほとんどのファインチューニングプロジェクトにとって、それらは十分に適切だということです。トレーニングが速く、実行コストが安く、実世界のアプリケーションにより実用的です。こう考えてください。ピザを配達するのにセミトレーラーは必要ありません。
次に、多くの人が見落としている重要な側面について説明しましょう。ライセンスです。これは単なる法的な官僚主義ではありません。プロジェクトの成否を分けることができます。一部のモデルには厳格な商業的制限があり、他のものは帰属表示が必要で、完全にオープンソースのものもあります。商業的なものを構築している場合は、特に注意が必要です。法的に使用できないモデルのファインチューニングに何週間も何ヶ月も費やすことは避けたいはずです。
oLamaを使用している大多数の方々に、実用的な推奨をお伝えします。Llama 3 18Bのようなものから始めてください。言語モデルのトヨタカローラのようなもので、信頼性が高く、効率的で、仕事をこなします。ファインチューニングのパイプラインが機能するようになったら、Qwen 2.5 14BやXo1 32Bなどの他のモデルを試すことができます。モデルは後で切り替えることができます。ハードウェアに対して大きすぎるモデルのファインチューニングに行き詰まるよりも、管理可能なものから始めてプロセスを学ぶ方が良いです。
これで、ファインチューニングとは何か、いつ使用するか、データの準備方法、どのモデルから始めるかを理解しました。でも、「わかった、でも実際にはどうやるの？」と思っているかもしれません。それこそが、これから始まるシリーズで扱う内容です。
ファインチューニングを身近にする3つの強力なツールを見ていきます。まず最初はAxelAOです。ファインチューニングツールのスイスアーミーナイフのようなもので、プロセスに対する驚くべきコントロールを提供し、実質的にすべての最新のファインチューニング技術をサポートします。ボンネットの下で何が起こっているのかを本当に理解したい場合は、ここから始めます。
次にUNSSlothを見ていきます。名前がそのまま機能を表しています。ファインチューニングを本当に高速にします。限られた計算リソースで作業している場合や、モデルのトレーニングに数日待ちたくない場合は、これを気に入るはずです。欠点は、複数のGPUがある場合、UNSSlothは最初の1つしか使用しないことです。
Macユーザー、特にApple Siliconを使用している方々のために、MLXを再び取り上げます。前回のMLXの動画をご覧になった方もいるかもしれません。実際、これまでで最も人気のある動画の1つになっています。しかし、このシリーズでは新しいアプローチを取ります。AppleのMachine Learningフレームワークは、Macハードウェアで信じられないほど効率的で、Apple Silicon Mac以外に何も必要とせずにファインチューニングに活用する方法をお見せします。
これらのツールにはそれぞれ独自のスーパーパワーがあり、このシリーズの最後には、どれがあなたのニーズに合っているかを正確に知ることができます。さらに、私たちが作成するものはすべてoLamaと互換性があるので、ファインチューンしたモデルを簡単にデプロイできます。
最後に、チャンネル登録ボタンを押し、Discordコミュニティに参加することを忘れないでください。あなたの経験を共有し、必要なときにヘルプを得ることができます。最初にどのツールを見たいか、Axel、UNSSloth、MLX、あるいは知りたい他のツールがあれば、コメントで教えてください。あなたのフィードバックは、今後のチュートリアルの優先順位付けに役立ちます。
覚えておいてください。ファインチューニングは魔法ではありません。正しく使用すれば、モデルが既存の知識をより良く活用できるようにする強力なツールです。良いデータから始め、適切なベースモデルを選択し、今日学んだことすべてを実践に移す実用的なチュートリアルをお楽しみに。ご視聴ありがとうございました。次回でお会いしましょう。
コメント