ファインチューニング

概要

ファインチューニングは、すでに学習を終えたモデルに対して、目的に特化した追加データで再訓練を施し、特定の口調・出力形式・専門領域へ適応させる手法です。汎用のLLMを「自社サポートの応対スタイルで答えるモデル」「医療文書の分類に特化したモデル」のように仕立て直す、いわばモデルの仕上げ調整（fine tune = 微調整）にあたります。

土台となるのは、膨大なデータで一般的な言語能力を獲得済みの「事前学習済みモデル」です。そこに数百〜数万件程度の目的特化データを追加で学習させることで、ゼロから作るのとは比べものにならない小さなコストで専用モデルが得られます。プロンプトの工夫やRAGと並ぶ、LLMを実務に適応させる主要な選択肢のひとつです。

なぜ生まれたか

ニューラルネットワークをゼロから訓練するには、膨大なデータと計算資源が必要です。現代のLLMの事前学習には数兆語規模のテキストと、数千台のGPUを数か月動かす計算が投じられており、これを個々の企業やタスクごとに繰り返すのは非現実的です。一方で、汎用モデルをそのまま使うと、専門用語の扱い・出力形式・応対の流儀が目的に合わない、という問題が残ります。

そこで機械学習の世界で発展したのが「転移学習」という考え方です。大規模データで獲得された汎用的な能力は、別のタスクにもそのまま活きる — だから高価な事前学習は一度だけ行い、各タスクへの適応は軽い追加学習で済ませればよい、という分業です。ファインチューニングはこの転移学習をLLM時代に引き継いだもので、「巨大な汎用モデル + 小さな適応」という現在のAI活用の基本構図を支えています。ChatGPTのような対話モデル自体も、事前学習済みモデルに指示応答データでファインチューニング（instruction tuning）を施して作られています。

詳細

全パラメータ更新とLoRA — どこまで書き換えるか

最も素朴な方法は、モデルの全パラメータ（重み）を追加データで更新する「フルファインチューニング」です。適応の自由度は最大ですが、Transformerベースの大規模モデルでは数十億〜数千億個の重みすべてに勾配計算とメモリが必要になり、訓練にも保存にも巨大なGPU資源を要します。タスクごとにモデルの完全なコピーを持つことになるのも重い負担です。

この重さを解決したのが、PEFT（Parameter-Efficient Fine-Tuning、パラメータ効率的ファインチューニング）と総称される軽量手法群で、代表格がLoRA（Low-Rank Adaptation）です。LoRAは元のモデルの重みを凍結したまま、各層に「低ランク行列」と呼ばれる小さな追加パラメータ（全体の1%未満）だけを差し込んで訓練します。性能はフルファインチューニングに迫りつつ、必要なGPUメモリは大幅に減り、タスクごとの成果物も小さなアダプタファイルだけで済みます。

何を学ばせるか — データがすべて

ファインチューニングの成否は、手法よりも訓練データの質で決まります。LLMの場合、典型的なデータは「入力（指示や質問）と理想の出力」のペアで、数百〜数万件を人手で整備します。ここで重要なのは、ファインチューニングが得意なのは「振る舞いの型」を教えることであって、「事実知識」を確実に覚えさせることではない、という点です。出力形式・口調・タスクの手順は少量のデータでよく定着しますが、個別の事実を注入しようとすると、覚え漏れや既存知識との混線が起きやすく、更新のたびに再訓練が必要になります。

RAG・プロンプトとの使い分け

LLMを目的に適応させる手段は、コストの軽い順に「プロンプトエンジニアリング → RAG → ファインチューニング」と並びます。まずプロンプトの指示と例示で解決できないかを試し、足りない知識は検索で注入し、それでも直らない振る舞いの癖 — 特殊な出力形式の厳守、ブランド固有の文体、プロンプトに書ききれない暗黙の作法 — をファインチューニングで焼き込む、というのが実務の定石です。知識はRAG、振る舞いはファインチューニング、と役割を分けて併用する構成もよく採られます。

落とし穴 — 破滅的忘却とコスト

代表的な落とし穴が「破滅的忘却（catastrophic forgetting）」です。特定タスクのデータに寄せて訓練しすぎると、モデルが事前学習で得た汎用能力を失い、ターゲット以外の入力への応答が壊れることがあります。学習率を抑える、汎用データを混ぜる、LoRAのように元の重みを凍結する、といった対策が採られます。また、少数のデータへの過学習で応答が不自然に画一化する問題や、訓練データの整備・品質評価にかかる人的コストも軽視できません。さらに、土台のモデルが更新されるたびにファインチューニングをやり直す必要があるため、基盤モデルの進化が速い領域では「プロンプトとRAGで粘るほうが結果的に安い」ケースも多い、という点は意思決定の際に押さえておきたいところです。