ファインチューニングすべきとき、すべきでないとき

多くの人が初めて自分の AI アプリを作ろうと考えたとき、最初に思いつくのはこうです。「会社の資料でモデルをファインチューニングしよう」。

この考えは、たいてい間違っています。この課ではファインチューニングに何ができて何ができないのか、そして手をつける前にまず何を試すべきかをはっきり説明します。この後の課ではファインチューニングを実際にやってみますが、「本当に必要か」という判断を持って学んでください。

三つの方法はそれぞれ何を変えるか

ここまでで、モデルを自分の要件に合わせる方法を三つ学びました。

            改变的是             代价                      改起来
提示词      这一次对话的指令      几乎为零，但每次都占词元     改一行字，马上生效
RAG         模型能看到的资料      要建检索系统，要维护        更新文档，马上生效
微调        模型本身的参数        要准备数据、训练、评估      重新训练，重新部署

それぞれが解決する問題は違います。

• プロンプトはモデルに「今回はどうするか」を伝えます。モジュール 02 では、これで出力の形式、口調、手順を制御しました。
• RAG はモデルに「必要な資料はここにある」と伝えます。モジュール 04 の Q&A アシスタントは、これに頼って httpx のドキュメントの質問に答え、しかも引用を示せました。
• ファインチューニングはモデルの「ふだんの習慣」を変えます。パラメータに刻み込まれているので、毎回念を押す必要はありません。

よくある誤解：ファインチューニングで知識を注ぎ込む

「会社のドキュメントでファインチューニングすれば、モデルがそれを知るようになる」。これが最もよくある誤解です。

ファインチューニングでモデルにある程度の内容を覚えさせることはできますが、知識ベースとしてはとても出来が悪いのです。

• 正確に覚えられない。モデルは学んだ内容と元の知識を混ぜてしまい、相変わらず細部をでっち上げます。回答があなたのドキュメントから来たのか、モデル自身の想像から来たのか、知る方法がありません。
• 出典がない。RAG は答えがどのドキュメントのどの一節から来たかを示せますが（モジュール 04 第 5 課）、ファインチューニングにはできません。
• 更新が面倒。ドキュメントを一文字変えても、RAG ならインデックスを作り直すだけですが、ファインチューニングは学習し直し、評価し直し、デプロイし直す必要があります。
• 副作用がある。第 3 課で目の当たりにするとおり、モデルの自己紹介を変えるよう教えただけで、普通の質問への答え方まで変わり、それまでなかった誤りが一つ増えました。

ですから、モデルにある資料を「知って」いてほしいときは、まず RAG を使いましょう。

ファインチューニングは何に向いているか

ファインチューニングが得意なのはふるまいを変えることで、特にプロンプトの数行でははっきり説明しにくいもの、あるいは毎回説明するのが無駄なものです。

• 安定した形式とスタイル。たとえば、いつも会社の形式で報告書を書く、いつもある口調を使う。第 2 課で小さな GPT を LoRA でファインチューニングすると、「どんな詩でも書く」からほぼ五言絶句だけを書くようになりましたが、詩を書く「腕前」（損失）はほとんど変わらず、変わったのは習慣でした。
• 特定のタスク。たとえばユーザーの発言を決まった数十個のカテゴリに分ける、契約書から決まったフィールドを抜き出す。ラベル付きの例が数千件あれば、小さなモデルをファインチューニングするだけで LLM とほぼ同じくらいうまくでき、しかもずっと安く速いことがよくあります。
• LLM の能力を小さなモデルに「蒸留」する。LLM で質の高い回答を大量に生成し、それで小さなモデルをファインチューニングして、この種のタスクで LLM に近い水準にします。推論のコストを大きく下げられます。
• プロンプトを短くする。毎回のリクエストに長い決まった指示と例を付ける必要があるなら、ファインチューニングの後はそれを省けて、毎回のトークンと遅延を減らせます。

判断の順番

1. 先把提示词写好（第 02 模块），并准备评估集（第 06 模块）
      ↓ 效果还是不够？
2. 是缺资料吗？→ 用 RAG（第 04 模块）
      ↓ 不缺资料，是行为、格式、风格不稳定？
3. 在提示词里加几个例子（少样本）
      ↓ 还不行，或者例子太长、太贵？
4. 考虑微调。先准备几百到几千条高质量的数据

いくつか説明を加えます。

評価セットが前提。評価セットがなければ、ファインチューニングでモデルがよくなったのか悪くなったのかわかりません。第 3 課の実験では、いくつかの例を見ただけで、元は正解していたのにファインチューニング後に間違えるようになった質問が一つ見つかります。体系的な評価がなければ、この種の問題はこっそり製品に紛れ込んでしまいます。

データが最大のコスト。学習そのものは安く、第 3 課では CPU で十数秒しかかかりませんでした。難しいのは、質がよく網羅的なデータを数百から数千件用意することです。データの誤りや偏りを、モデルはそのまま学んでしまいます。

モデルは更新される。今日 1 か月かけてモデルをファインチューニングしても、3 か月後に出る新しい汎用モデルは、ファインチューニングしなくてもそれより優れているかもしれません。プロンプトと RAG は新しいモデルにそのまま移せますが、ファインチューニングは最初からやり直しです。

まずサービス提供者に聞く。2026 年 9 月時点で、オンラインのファインチューニングサービスを提供している API 提供者もあれば、していないところもあり、料金や対応モデルもよく変わります。オープンソースモデルを自分でデプロイしてファインチューニングするなら、第 4、5 課で扱う運用コストも考える必要があります。

RepoBot の選択を振り返る

このコースの第 1 部で作った RepoBot は、要件のたびに実はこの判断をしていて、しかも一度もファインチューニングを使っていません。

• httpx のドキュメントの質問に答えさせたい：足りなかったのは資料なので、モジュール 04 で RAG を加えました。ドキュメントが更新されたらインデックスを作り直せばよく、回答には出典も付けられます。
• 先にソースコードを調べてから答えさせたい：これは複数ステップの操作というふるまいで、プロンプトとツールで実現できるので、モジュール 05 でエージェントにしました。
• 無関係な質問や悪意のある質問を止めさせたい：モジュール 06 では、よく書けた分類のプロンプトと評価セットでガードレールを作り、分類モデルを専用に学習させることはしませんでした。まずプロンプトで「十分」な水準にし、評価セットでその正答率を示してから、学習させる手間をかける価値があるかを決めるのです。

第 3 課で RepoBot を一度ファインチューニングしますが、変えるのは自己紹介だけです。それはファインチューニングのやり方と、どんな副作用が出るかを示すためで、RepoBot に本当にそれが必要だからではありません。

どうしてもファインチューニングするなら

たいていの場合、モデルのすべてのパラメータを学習させる必要はありません。第 2 課で LoRA を扱います。元のパラメータを凍結し、新しく加えたごく一部のパラメータだけを学習させる方法です。私たちの実験では、小さな GPT はパラメータの 1.5% だけ、Qwen2.5-0.5B は 0.22% だけを学習させて、目的を達しました。GPU メモリを節約でき、学習が速く、保存するファイルも小さいので、現在最もよく使われているファインチューニングの方法です。

練習問題

1. モジュール 03～06 の RepoBot を思い出してください。次の要件を、プロンプト、RAG、ファインチューニングのどれで実現しますか。なぜでしょうか。
   • httpx の新しいバージョンの新機能について答えさせる。
   • どの回答も「出典：」で終わり、引用したドキュメントを並べるようにさせる。
   • ユーザーの質問を「インストール」「使い方」「エラー」「その他」の四つに分類させ、1 日に 10 万件処理する。
2. AI で解決したい実際の問題を一つ見つけ、この課の「判断の順番」に沿って考え、各ステップの結論を書き留めてください。

確認テスト

1. ファインチューニングでモデルに会社のドキュメントを「覚えさせる」ことが勧められないのはなぜですか？

ファインチューニングしたモデルは正確に覚えられず、学んだ内容と元の知識を混ぜて、でっち上げを続けます。回答に出典がなく確認できません。ドキュメントが更新されるたびに学習し直す必要があります。さらに副作用が出ることもあります。モデルに資料を使わせる必要があるときは、RAG のほうが向いています。

2. ファインチューニングはどんな種類の問題の解決に最も向いていますか？

モデルのふるまいを変えることです。安定した形式とスタイル、ラベル付きデータが大量にある特定のタスク、LLM の能力を安い小さなモデルに蒸留すること、毎回付ける必要のある長いプロンプトを省くこと。

3. ファインチューニングを決める前に、必ず評価セットを用意しておく必要があるのはなぜですか？

評価セットがなければ、ファインチューニングで本当に改善したのかを判断できず、ファインチューニングがもたらす副作用、たとえば元は正解していた質問を間違えるようになったことにも気づけません。評価セットは、プロンプト、RAG、ファインチューニングといういくつかの案を比べるための共通の基準でもあります。