第4章模型容量选择

第4章：模型容量选择：小模型 vs 大模型

做奖励模型训练，第一个绕不开的问题就是：选多大的模型？

我见过不少团队，一上来就上7B、13B的大模型，结果训了几天发现reward分数一路飙升，但下游任务效果反而变差了。说白了，这就是典型的过拟合——模型把训练集里的噪声都记住了，根本没学到真正的偏好。

反过来，也有人为了求稳，选了个特别小的模型。结果呢？表达能力不够，连训练集都拟合不好，更别说泛化了。

所以这一章，我们就来聊聊模型容量选择的那些事。

4.1 小模型 vs 大模型：各自的优劣势

先给个直观的对比。我个人习惯把奖励模型的选择分成三个档次：

模型规模	参数量范围	典型代表	适用场景
小模型	< 1B	BERT-base、GPT-2 small	数据量少、任务简单、推理速度要求高
中等模型	1B ~ 7B	LLaMA-7B、Mistral-7B	大部分通用场景，数据量在10万~100万级别
大模型	> 7B	LLaMA-13B、70B	数据量极大、任务复杂、需要高精度

你想想看，小模型的好处很明显：训练快、推理快、显存占用小。我在一个早期项目里，用300M的模型做奖励模型，单卡V100就能跑，迭代速度飞快。但问题也来了——它的表征能力有限，对于复杂的偏好判断，比如「这段代码写得好不好」，小模型往往力不从心。

大模型呢？表达能力确实强，但代价也大。我记得有一次用13B的模型做奖励模型，光是加载权重就占了26G显存，训练时还得用上模型并行。更关键的是，大模型更容易过拟合——你想想，参数量比训练样本还多，它当然能把每个样本的细节都背下来。

核心观点：模型容量不是越大越好，关键看你的数据量和任务复杂度。数据量少的时候，大模型就是灾难。

4.2 参数量与过拟合的关系

为什么会这样？我们来拆解一下。

奖励模型的训练，本质上是在学习一个从「输入」到「偏好分数」的映射。模型参数量越大，它的假设空间就越大——说白了，它能拟合的函数形状就越复杂。

当你的训练数据足够多、足够多样时，大模型能学到真正的规律。但问题是，奖励模型的训练数据往往很有限。你想想，人工标注偏好数据多贵啊？一个pair就要几块钱，能标个10万条就算不错了。

这时候，大模型就会开始「钻空子」：它发现记住训练数据比学习泛化规律更容易。于是，reward分数蹭蹭往上涨，但一遇到新数据就露馅了。

我给大家画个图，直观感受一下：

看到没？训练损失一直在下降，但验证损失先降后升。那个拐点，就是你的最佳模型容量。过了这个点，模型就开始「死记硬背」了。

避坑指南：我曾经在一个项目里，用7B模型训了20万条偏好数据，验证集上的准确率从72%掉到了65%。后来一查，模型把标注员的个人偏好都学进去了——比如某个标注员特别喜欢「详细」的回答，模型就学会了给长回答打高分，不管内容质量如何。

4.3 经验法则：怎么选？

说了这么多理论，来点实际的。我总结了几条经验法则，都是踩过坑之后才悟出来的：

数据量法则：训练样本数 > 模型参数量的10倍，这是底线。比如你选了7B的模型，至少要有70万条偏好数据。少于这个数，过拟合风险极高。
任务复杂度法则：任务越主观，模型可以越小。比如「判断回答是否安全」这种二分类任务，1B模型就够了。但「判断代码质量」这种需要深层理解的任务，建议上7B以上。
从简原则：拿不准的时候，先选小模型。我习惯先用1B模型跑一轮，看看训练集和验证集的差距。如果差距很小，说明容量够用；如果差距大，再换大模型。
监控验证集：训练过程中，时刻盯着验证集上的reward分布。如果验证集上的reward方差突然变大，或者均值开始下降，那就是过拟合的信号。

实用技巧：我建议你做一个「容量扫描」实验。固定其他超参数，分别用300M、1B、3B、7B的模型训一遍，画一条验证集性能曲线。这个实验虽然费点时间，但能帮你找到最适合当前任务的模型容量。我在好几个项目里都这么干，效果很好。

4.4 一个具体的选型流程

最后，给一个我常用的选型流程，你可以直接拿来用：

# 伪代码：模型容量选择流程
def select_model_size(train_data_size, task_complexity):
    # 1. 根据数据量估算
    if train_data_size < 100_000:
        recommended = "< 1B"
    elif train_data_size < 500_000:
        recommended = "1B ~ 3B"
    else:
        recommended = "3B ~ 7B"
    
    # 2. 根据任务复杂度调整
    if task_complexity == "high":  # 比如代码质量、逻辑推理
        recommended = upgrade(recommended)
    
    # 3. 考虑推理成本
    if latency_sensitive:
        recommended = downgrade(recommended)
    
    return recommended

嗯，这个流程虽然简单，但很实用。你想想看，选模型容量就像选鞋子——不是越大越好，合脚最重要。

最后说一句：别迷信大模型。我见过太多团队，一上来就上13B、70B，结果训出来的奖励模型还不如一个精心调过的1B模型。模型容量选择，本质上是在「表达能力」和「泛化能力」之间找平衡。找到那个平衡点，你的奖励模型就成功了一半。

📚 课程目录