前回の D2 では、Grokking のように「あとから急に立ち上がる」現象を見ました。D3 では、そのような現象を含めて、スケール則をどう実験で確かめ、どう測ればよいのかを整理します。
見た目の性能だけでは、創発や遅延サージが本当に起きているのか分かりません。この章の役割は、モデルサイズ、データ量、Loss、テスト性能を、同じ土台で比較できるようにすることです。
1. 実験設計について？
スケール則は理論だけで理解しても十分ではありません。実務では、どのサイズで、どのデータ量で、どの指標を見ればよいかを決めないと、議論が曖昧になりやすいからです。
特に D1 や D2 で見たような非直線的な現象は、観測の仕方によって見え方が変わります。だからこそ、先に実験設計を固めておく必要があります。
本章の目的：モデルサイズ、データ量、LOSS、テスト性能を「同じ土台」で比較するための測定プロトコルを確立する。
2. 何を測ればスケール則が見えてくるのか？
スケール則を見るときに大事なのは、単に最終精度だけを追わないことです。少なくとも次の 3 つを分けて見たほうが、変化の意味を追いやすくなります。
2-1. Loss を測る
Loss は、学習がどの程度進んだかを追うための基本指標です。ただし、訓練 Loss とテスト Loss を分けて記録しないと、過学習や遅延サージの有無が見えにくくなります。
2-2. テスト性能を測る
最終的に重要なのは、訓練ではなくテスト側でどれだけ性能が出るかです。翻訳、分類、情報抽出、推論など、タスクによって評価指標は変わります。
複数のベンチマークを組み合わせることで、特定の指標に対する過剰合（オーバーフィッティング）を排除する
2-3. 効率を測る
同じ性能でも、どれだけ計算資源を使ったかで意味は変わります。FLOPs や GPU 時間あたりの改善を見ておくと、単純な「高得点」だけでは判断しにくい効率差が分かります。
3つのレンズが重なる部分にのみ、真のスケール則が現れる。
3. どんな実験設計を組めばよいのか？
3-1. パラメータスケーリング
まずはモデルサイズを段階的に変えます。小さいモデルから大きいモデルまで、指数ステップで並べると、スケールの変化を追いやすくなります。
import numpy as np
class ScalingExperiment:
"""スケーリング実験の簡易例"""
def design_experiment(self):
model_sizes = [1e6, 10e6, 100e6, 1e9, 10e9, 100e9]
experiments = []
for n in model_sizes:
d = 20 * n
experiments.append({
"n_params": n,
"d_tokens": d,
"expected_loss": self.predict_loss(n, d),
})
return experiments
def predict_loss(self, n, d, alpha=0.076, beta=0.095):
# alpha: パラメータ数 N に対するスケーリング指数（Kaplan et al., 2020 では約0.076）
# beta : データ量 D に対するスケーリング指数（Kaplan et al., 2020 では約0.095）
e = 0.5
b = 50
c = 0.2
return e * np.power(n, -alpha) + b * np.power(d, -beta) + cこの設計で見たいのは、モデルを大きくしたときに Loss がどの程度滑らかに下がるかです。D1 の創発や D2 の Grokking が絡むと、単純な直線では見えない変化も出てきます。
3-2. データスケーリング
次に、モデルサイズを固定してデータ量を変えます。どの程度データを増やせば Loss が落ちるのかを確かめるための設計です。
class DataScalingExperiment:
"""データセット規模の影響を測る例"""
def design(self):
n_fixed = 7e9
d_ratios = [0.5, 1, 2, 5, 10, 20, 50, 100]
results = []
for ratio in d_ratios:
d = ratio * n_fixed
final_loss = self.measure_loss(n_fixed, d)
results.append({
"d/n_ratio": ratio,
"d_tokens": d,
"final_loss": final_loss,
})
return results
def measure_loss(self, n, d):
alpha_d = 0.095 # データ量 D に対するスケーリング指数（Kaplan et al., 2020）
return 1.0 * np.power(d, -alpha_d) + 0.2この実験は、D2 のような遅延現象がデータ不足に由来するのか、それともモデル側の性質に由来するのかを切り分ける助けになります。
4. どう測ると誤解しにくいのか？
4-1. Loss の記録を分ける
訓練 Loss とテスト Loss を同じものとして扱うと、解釈を誤りやすくなります。さらに、エポック数やイテレーション数だけでなく、FLOPs あたりで比較できるようにすると、実験間の差が見えやすくなります。
4-2. 反復性を確保する
1 回の結果だけで判断すると、偶然の揺らぎ（ノイズ）を拾いやすくなります。乱数シードを変えて複数回回し、平均とばらつきを見るほうが、スケール則の話としては筋が通ります。
4-3. テスト性能を複数のベンチマークで見る
タスクごとに評価の意味が違うため、単一指標では見落としが出ます。翻訳なら BLEU、分類なら Accuracy、情報抽出なら F1 のように、タスクに応じて指標を変える必要があります。
| タスク | よく使う指標 | 見たいこと |
|---|---|---|
| 翻訳 | BLEU | 言い換えや整合性 |
| 分類 | Accuracy | 正解率の伸び |
| 情報抽出 | F1 | 過不足のバランス |
| 推論 | 正答率 | 閾値を超えた伸び |
5. 効率はどう計算すればよいのか？
スケール則の実験では、性能そのものだけでなく、どれだけ効率よく改善したかも見ておきたいです。
def compute_efficiency_metrics(training_results):
"""効率指標の計算"""
total_flops = training_results["flops"]
initial_loss = training_results["initial_loss"]
final_loss = training_results["final_loss"]
loss_improvement = initial_loss - final_loss
efficiency = loss_improvement / (total_flops / 1e21)
gpu_hours = training_results["gpu_hours"]
accuracy_gain = training_results["test_accuracy_gain"]
throughput = accuracy_gain / gpu_hours
return {
"efficiency": efficiency,
"throughput": throughput,
}ここでのポイントは、Loss が下がったかどうかだけでなく、その改善がどれだけの計算資源で得られたかを見ることです。改善が大きくても、コストが過大なら実務では使いにくくなります。
6. どんなチェックを通しておくべきか？
スケール則の検証では、少なくとも次を押さえたほうがよいです。
| 項目 | 確認したいこと |
|---|---|
| モデルサイズ | 最低 5 段階以上で比較したか？ |
| データセット | D ≈ 20N 前後で複数測定したか？ |
| 反復性 | 異なるシードや環境で再現したか？ |
| 統計性 | エラーバーや有意性を確認したか？ |
| 外挿 | 観測範囲外への予測を試したか？ |
| ドメイン | 言語、コード、マルチモーダルをまたいで見たか？ |
このチェックは、実験を重くするためではなく、あとで「その結果は本当に再現可能なのか？」と迷わないためのものです。
7. よくある失敗は何か？
実験設計で多い失敗は、だいたい次の 3 つです。
- 1 回の実験だけで結論を出す
- 訓練 Loss だけを見て、テスト側を軽視する
- モデルサイズとデータ量の両方を同時に動かしてしまう
特に最後は分かりにくいですが、何が効いたのかが追えなくなります。パラメータスケーリングとデータスケーリングは、できるだけ分けて見るほうが安全です。
8. 次に進む前に何を確認すべきか？
本番の比較に入る前に、少なくとも次を確認したほうがよいです。
- 何を Loss として記録するか決めたか？
- 訓練 Loss とテスト Loss を分けているか？
- モデルサイズとデータ量を別々に変える設計になっているか？
- 複数シードで再現確認をしているか？
- 効率指標を FLOPs や GPU 時間で見ているか？
ここで大切なのは、測定を「あとから見るログ」ではなく、「結論の根拠」にすることです。
この確認を通しておくと、次の D4 で扱う「スケール則の限界」と「信頼性」を、より具体的に読みやすくなります。観測範囲を超えた議論がどこから危うくなるのかを見分けるためにも、D3 の測定設計は重要です。
9. まとめ
D3 の重要な教訓は、スケール則は理論式だけではなく、実験設計と測定方法まで含めて成立するという点です。どんなサイズを、どんなデータで、どの指標で測るかが曖昧だと、結果の解釈も曖昧になります。
今回の要点は次の通りです。
- スケール則は、Loss・テスト性能・効率の 3 方向で見ると整理しやすい
- パラメータスケーリングとデータスケーリングは分けて設計する
- 訓練 Loss だけでは不十分で、テスト側と反復性が重要である
- 効率は性能の高さだけでなく、計算資源あたりの改善で見るべきである
- 実験の設計と測定の仕方が、結論の信頼性を左右する
最適な測定とは、たくさん記録することではありません。何を比較し、どの条件を固定し、どこで変化が起きたのかを追えるようにすることです。
10. 今回のブログの考察
D3 の本質は、スケール則を「見えるようにする」ことです。D1 で創発を見て、D2 で遅延サージを見たあと、D3 ではそれらを支える測定の土台を整えます。
この章で見たように、実験設計が曖昧だと、あとでどれだけ立派な式を使っても結論がぶれます。逆に、モデルサイズ、データ量、Loss、テスト性能を丁寧に分けて追えれば、D4 で扱う限界や外挿の危うさも見えやすくなります。
次の D4 では、この流れを受けて、スケール則がどこまで信頼できるのか、そしてどこから慎重になるべきかを見ていきます。
参考文献
- Hoffmann, J., et al. (2022). “Training Compute-Optimal Large Language Models.” DeepMind.
- Kaplan, J., et al. (2020). “Scaling Laws for Neural Language Models.” OpenAI.
コメント