小模型的SFT故障模式 | AI生成和翻译
你的分析方向上是正确的。这实际上是对 小模型在 SFT 后常见失败模式 的一个很好的经验性观察。几点细化：
- “没办法做数学推理”
基本上正确，但根本原因并不仅仅是“模型小”。SFT 通常教会的是 模式，而不是提升底层的推理能力。
示例：
SFT 前：
Q: 如果 Alice 有 3 个苹果，又买了 2 个，一共有几个？
A:
基础模型可能从预训练中学到了一些算术模式。
SFT 后（糟糕的情况）：
Q: 如果 Alice 有 3 个苹果…
A: 我们需要仔细考虑这个情况。Alice 最初有…
模型学会了 回答的风格，但不一定学会了多步计算。
数学推理通常需要：
- 高质量的思维链 / 推理轨迹
- 强化学习 / 后训练优化
- 工具使用
- 更大的模型容量
- “循环 loops，车轱辘说”
对。非常常见。
小 SFT 模型经常出现：
用户: 解释 TCP
模型:
TCP 是一种协议…
它提供可靠通信…
可靠通信的意思是…
TCP 很重要因为可靠通信…
原因？
因为 SFT 优化的是：
[ \max_\theta \sum_t \log P(y_t|x,y_{<t}) ]
它学习的是局部 token 预测。如果数据集中包含重复的解释，模型就会学到重复的模式。
常见的修复方法：
- 更好的 SFT 数据过滤
- 去除重复样本
- 偏好优化（DPO / RLHF）
- 更强的基座模型
- 更长上下文训练
- “只会记住事实，参数越大的模型记住事实越好”
基本正确。
模型规模提升带来：
- 记忆容量
- 表示丰富度
- 泛化能力
一个 7B 模型和一个 70B 模型在相同语料上训练：
70B 通常：
- 记住更多稀有事实
- 处理更多抽象概念
- 更好地遵循指令
因为参数数量大致增加了模型的容量：
[ \text{capacity} \propto N_{params} ]
但事实并非像数据库那样简单存储，而是分布在权重中。
- “代码总体表现更好”
也正确。
代码的特殊之处在于：
- 语法是严格的
- 反馈是二元的（编译通过 / 失败）
- 训练数据量巨大
- 代码有内部结构
示例：
Python：
def add(a, b):
return a + b
这里有很强的统计约束。
自然语言：
经济形势是…
歧义性要高得多。
因此即使是小模型，在 SFT 后也常常能成为令人惊讶的好代码助手。
你的流程：
文本小模型
|
代码小模型
|
金融小模型
|
合并数据集
|
SFT
|
评估
有趣的观察是：
不同领域产生不同的表面行为，但 SFT 失败模式是共通的。
因为它们来自相同的优化机制：
数据集
|
v
有监督的 token 预测
|
v
学习答案的分布
而不一定是：
学习推理算法
学习世界模型
学习规划
你使用 Hermes 记录所有输入/输出对的想法，实际上是对的调试工作流：
提示
|
v
模型
|
v
回复
|
v
保存 jsonl/txt
|
v
人工检查
例如：
{
"instruction": "解这道数学题…",
"output": "……",
"failure": "循环"
}
然后对失败案例进行聚类：
数学：
- 算术错误
- 没有推理
代码：
- 语法错误
- 幻觉 API
金融：
- 过时事实
- 过度自信的回答
通用：
- 重复
- 拒绝回答
这基本上就是现代后训练团队调试 SFT 模型的方法。SFT 之后的一步通常不是“更多 SFT”，而是构建一个 偏好数据集：
提示
|
+-- 好的回答
|
+-- 差的回答
然后优化：
[ P_\theta(y_{good}) > P_\theta(y_{bad}) ]
使用 DPO / IPO / RL。
你的观察与许多团队在训练他们的第一个小型指令模型时的发现非常接近。
AI生成和翻译，但整理分享仍需精力。如果觉得有帮助，欢迎
捐助支持。
微信：@lzwjava
·
X: @lzwjava ·
打个招呼 👋