过拟合与泛化
直觉
过拟合像背答案：训练题几乎全对，换一种问法就失败。泛化则是学到能迁移到新样本的规律。常见信号是训练分数持续上升，而验证分数停滞或下降。
为什么会过拟合
- 样本少、特征多，模型有机会记住偶然细节。
- 重复或近重复样本使训练表现看起来很好。
- 模型容量相对任务过大。
- 反复针对同一验证集调整，团队也会“过拟合验证集”。
- 标签含噪声，模型开始拟合错误或不一致的答案。
常用控制手段
- 更可靠的数据：增加覆盖、去重、修正规则冲突，通常比换模型更根本。
- 正则化：对过大的权重或复杂结构施加代价。
- 降低容量：减少树深、特征、参数或训练轮数。
- 早停：验证表现不再改善时停止。
- 严格评估：按用户/文档/时间分组，保留真正未见测试集。
偏差-方差是一个思考框架：模型太简单时系统性错误较大（高偏差）；模型对训练数据的小变化过度敏感时不稳定（高方差）。现实中还要考虑数据漂移和不可约标签歧义。
Agent/RAG 场景里的特殊形式
- 同一文档的不同 chunk 同时进入训练与测试。
- 评测问题由模型根据答案生成，问题中带出答案措辞。
- 调提示词时长期盯着一组固定样题，最终只对样题有效。
- 路由模型把客户名称当成意图捷径，换客户后性能崩溃。
错误排查顺序
- 先检查重复、泄漏和划分单位。
- 比较训练与验证分数，并按子群拆分。
- 查看错误样本是否标签不一致。
- 再尝试正则、特征或模型复杂度变化。
- 用独立测试集和时间外数据确认。
上线后仍要重新确认泛化
训练/验证/测试边界只回答某个历史快照上的问题。上线后，输入特征分布、类别比例、标签定义、人工流程或可用字段都可能变化；这些变化会让旧分数失去代表性。可以按时间窗口、来源、业务场景和错误代价监测输入、预测、延迟到达的真实结果与人工升级率，但告警只是排查起点，不自动说明“模型变差”或“应立即重训”。先排查数据质量、规则/标签变化、产品流程与人群变化，再决定补数据、调整流程、重新评测或训练新版本。
练习
为“固定 100 道 Agent 评测题反复调提示词”写一套防过拟合方案，至少包含开发集、封存测试集、版本记录和新增失败样本策略。
再完成两项对照：
- 画出训练/验证分数随模型复杂度变化的示意图，标出欠拟合、合适区间和过拟合。
- 分别说明“增加高质量独立样本”“复制已有样本”“增加正则”会改变什么，不能把三者当成等价操作。
掌握检查
- 我能从训练/验证差距识别过拟合候选，但不会只凭一条曲线下结论。
- 我会先排查重复、泄漏、分组单位和标签噪声，再换模型。
- 我知道正则化、早停和降低容量各自改变什么。
- 我会保护封存测试集，避免团队层面对固定验证集过拟合。
下一步：指标基线与误差分析。
参考资料
核验日期：2026-07-22。