LLM【スケール則：最適配分戦略C-6】

前回の C5 では、どの環境でモデルを運用するかを整理しました。C6 では、その前提を受けて、「そのモデルが実際のタスクでどれだけ効くのか」を見ます。

同じ事前学習モデルでも、MMLU で強いモデルと GSM8K で伸びやすいモデルは必ずしも一致しません。この記事では、タスクごとの Scaling Law の違い、ファインチューニングの選び方、複数タスクへの広げ方を、実務で判断しやすい順番で整理します。

1. なぜダウンストリームタスク性能を扱うのか？

前回までで、データ、アーキテクチャ、環境の前提は整いました。しかし実務では、最後に必ず次の問いが残ります。

• このモデルは、知識問題と推論問題のどちらで強いのか？
• タスクごとに、どのくらいデータやパラメータが効くのか？
• Full Fine-Tuning と LoRA、Prompt Tuning のどれが現実的なのか？

この章の役割は、事前学習で作ったモデルを、実際の業務タスクへ接続することです。ここを曖昧にすると、学習損失は下がっていても、現場で欲しい性能が出ないということが起きます。

言い換えると、Scaling Law は「モデルを大きくすれば良い」で終わる話ではありません。どのタスクに、どのアプローチが効きやすいかを見ないと、配分戦略は完成しません。

2. ダウンストリームタスクで何が変わるのか？

ダウンストリームタスクとは、事前学習済みモデルを、特定の用途に合わせて使う段階のことです。ここでは、単純な言語理解だけでなく、推論、コード生成、誠実性の評価など、タスクの性質が結果に強く影響します。

2-1. タスクごとに α は変わる

Scaling Law は、タスクによって異なる α を示します。つまり、同じモデルサイズの増やし方でも、効き方は一律ではありません。

この表で見たいのは、ベンチマークの順位だけではありません。タスクの種類によって、スケーリングの効き方が違うことです。

2-2. 直感的にはどう理解すればよいのか？

たとえば GSM8K のような推論タスクは、モデルが大きくなるほど思考の段階を分けやすくなり、改善が見えやすい傾向があります。一方で HellaSwag のような常識推論は、ある程度のサイズに達すると伸びが鈍くなりやすいです。

つまり、同じ「性能向上」でも、タスクによって伸びやすい領域が異なります。ここを理解しておくと、事前学習の設計だけでなく、後続の微調整の方針も決めやすくなります。

3. タスク別に見ると、どんな配分が現実的なのか？

タスクの違いが見えたら、次はモデルサイズとデータ量の配分です。ここでは、あくまで目安として見ます。

ここで重要なのは、タスクごとに「ちょうどよい大きさ」が違うことです。すべてを同じ比率で扱うと、あるタスクでは過剰になり、別のタスクでは不足します。

4. どういうファインチューニング戦略を選べばよいのか？

ダウンストリームタスクに合わせるとき、最初に迷うのが Full Fine-Tuning と LoRA、Prompt Tuning の選択です。ここは、性能だけでなく、メモリと運用負荷で見るほうが実務的です。

4-1. Full Fine-Tuning は何が強いのか？

Full Fine-Tuning は、モデル全体を再学習する方法です。性能面では最も強くなりやすい一方で、GPU メモリと計算時間の負担が大きくなります。

向いているのは次のような場面です。

• 重要タスクで性能差をしっかり取りたい
• リソースに余裕がある
• 1 つのタスクに長く使う前提がある

4-2. LoRA はどこで効くのか？

LoRA は、重み本体を大きく動かさず、低ランクの追加層だけを学習する方法です。複数タスクを並行して回したいときや、限られたリソースで試したいときに扱いやすいです。

4-3. Prompt Tuning はどこまで割り切るのか？

Prompt Tuning は、パラメータ更新を最小限にして、入力側の工夫で適応する方法です。性能向上は控えめですが、試行回数を多く回したいときには便利です。

4-4. 比較するとどう見えるのか？

結論としては、まず LoRA で当たりを付け、必要なら Full Fine-Tuning に進む、という流れが扱いやすいです。

5. どうやって性能を見積もればよいのか？

タスク性能を考えるときは、感覚だけでなく、ざっくりした予測モデルを持っておくと判断しやすくなります。

たとえば、パラメータ数とタスク種別から、未達率（100% までのエラー率）がべき乗則（Power Law）に従って減衰するという標準的なアプローチに基づき、おおよその性能を見積もる関数は次のように書けます。

def predict_task_performance(n_params, task_name):
    # タスクごとのべき指数（α）
    alpha_map = {
        "mmlu": 0.076,
        "gsm8k": 0.105,
        "code": 0.098,
        "commonsense": 0.067,
    }

    # 基点となる1Bモデル時点での想定正解率（%）
    baseline_performance = {
        "mmlu": 42,
        "gsm8k": 15,
        "code": 18,
        "commonsense": 58,
    }

    alpha = alpha_map.get(task_name, 0.076)
    base_perf = baseline_performance.get(task_name, 50)

    # 1B（1e9）からのスケール倍率を算出
    scale_ratio = n_params / 1e9

    # べき乗則に従い、エラー（不正解）の割合が減衰するとモデル化
    # P(N) = 100 - (100 - P_base) * (scale_ratio ** -alpha)
    predicted = 100 - (100 - base_perf) * (scale_ratio**-alpha)

    return min(predicted, 99)

perf_7b = predict_task_performance(7e9, "gsm8k")
perf_70b = predict_task_performance(70e9, "gsm8k")
print(f"7B on GSM8K: {perf_7b:.1f}%")
print(f"70B on GSM8K: {perf_70b:.1f}%")

この種の見積もりで大事なのは、正確な予測値を出すことではありません。モデルサイズを変えたときの傾向を、タスク別に比較するための目安として使うことです。

6. 複数タスクを同時に扱うにはどうすればよいのか？

実務では、1 つのモデルで翻訳、要約、QA をまとめて扱いたい場面があります。その場合は、共有 backbone にタスク固有の適応層を載せる設計が現実的です。

6-1. タスク共有モデル + タスク固有 Adapter

共通の基盤モデルを持ちつつ、タスクごとに LoRA や Adapter を分けると、再学習のコストを抑えやすくなります。タスクが増えても、すべてを別モデルで持つより管理しやすいです。

6-2. Instruction Tuning

Instruction Tuning は、同じモデルに対して入力の指示を変えることで、複数タスクへ広げる方法です。要約、翻訳、質問応答を一つのモデルで扱いたいときに、最初の選択肢になりやすいです。

たとえば、次のような使い分けです。

• 要約したいときは「Summarize the following text: …」
• 翻訳したいときは「Translate to Japanese: …」
• 質問に答えたいときは「Answer the question based on the context: …」

この考え方の利点は、モデルを増やすよりも、運用の一本化を優先できることです。

7. 実務で起きやすい失敗は何か？

ダウンストリーム評価でよくある失敗は、だいたい次の 3 つです。

• ベンチマークの数字だけで、現場の使い勝手を判断する
• 1 つのタスクで強かった結果を、他のタスクにもそのまま当てはめる
• データ量が少なすぎるのに、大きなモデルだけを先に選ぶ

特に多いのは、MMLU が高いから実務でも強いはずだと考えてしまうケースです。実際には、知識問題に強くても、コード生成や推論タスクでは別の調整が必要になることがあります。

8. ファインチューニング前に何を確認すべきなのか？

本番の調整に入る前に、少なくとも次を確認したほうがよいです。

• ダウンストリームタスクの評価指標を定義したか？
• ベースラインとなる事前学習モデルを決めたか？
• タスクごとの必要データ量を見積もったか？
• Full Fine-Tuning、LoRA、Prompt Tuning の比較をしたか？
• 複数タスクを同時に扱う場合の設計を考えたか？
• C5 までの前提と整合する評価環境になっているか？

ここで大切なのは、最初から完璧な性能を狙わないことです。まずは少数のタスクで傾向を見て、そこから広げるほうが、後戻りしにくくなります。

この確認は、学習を止めるためではありません。次の D1 で扱う「創発的な変化」を読む前に、どの性能変化が再現可能で、どこからが質的変化なのかを見分けやすくするためのものです。

9. まとめ

C6 の重要な教訓は、事前学習モデルの良し悪しを、下流タスクの性質まで含めて見ることです。同じモデルでも、MMLU、GSM8K、HumanEval では効き方が違います。

今回の要点は次の通りです。

• タスクによって α は変わるため、Scaling Law は一律ではない
• タスク別に、適切な N/D 配分は少しずつ違う
  • N/D 配分とは？　
    • LLMの学習時における「モデルサイズ（N）」と「学習データ量（D）」の最適な投資配分（スケーリング則）
• Full Fine-Tuning は強いが重く、LoRA は軽く、Prompt Tuning はさらに軽い
• 複数タスクを扱うなら、共有 backbone とタスク固有 Adapter の組み合わせが現実的である
• ベンチマークの数字だけでなく、実務の使い勝手まで見るべきである

最適なダウンストリーム戦略とは、数字の高いモデルを探すことではありません。タスクごとの性質を見て、どの調整方法が最も再現しやすいかを選ぶことです。

10. 今回のブログの考察

C6 の本質は、配分戦略の最終確認です。C2 で計算資源を見て、C3 でデータを見て、C4 でアーキテクチャを見て、C5 で環境を見たあとに、最後は「そのモデルが実際のタスクで何を達成できるか」を見ないと、戦略は閉じません。

この章で見たように、ダウンストリーム評価は、単なる性能測定ではなく、モデル運用の出口設計です。どのタスクに強いのか、どの調整が効くのか、どこで妥協すべきかが見えると、次の改善が打ちやすくなります。

次の D1 では、この流れを受けて、LLM の能力がある閾値を超えたときに見える創発的な変化を見ていきます。

参考文献

1. Hu, E., et al. (2021). “LoRA: Low-Rank Adaptation of Large Language Models.”
2. Wei, J., et al. (2022). “Emergent Abilities of Large Language Models.”

このシリーズの案内

• C-5: 環境別デプロイメント戦略
• D-1: 創発性と能力の質的変化