机器学习笔记这东西，我断断续续记了快五年。最早几本是上学时候的课堂摘抄，满页都是公式和推导，后来工作以后，笔记的风格就完全变了——不再是抄知识点，而是专门记录那些“看起来没问题，跑起来就出问题”的项目现场。这篇笔记算是从里面挑出来的一部分，适合已经会用常见库跑通样例、但总在真实数据上翻车的朋友，也适合准备把模型从离线实验搬上线的同学。我不会按教科书顺序讲机器学习，只想聊几个我亲自踩过、后来花很大力气才补上的坑。
如果你正处于刚入门到能调包之间的阶段，你可能会觉得这些东西离你很远；等你手上的模型开始被业务方天天追问“为什么不准”的时候，你会发现，真正值钱的恰恰是这些角落里的内容。
1. 数据卫生：预处理阶段最容易让人翻车的三件事
1.1 泄漏：训练集里混入了不该看到的信息
数据泄漏是我见过最隐蔽、后果也最严重的问题，没有之一。它的本质很简单：训练的时候，模型“偷看”了在真实预测时拿不到的信息，于是线下指标格外漂亮，一上线就原形毕露。
最常见的一种泄漏发生在标准化和缺失值填补上。很多人习惯先把整个数据集读进来，然后调用标准化工具对全部数据做拟合，再划分训练集和验证集。这个操作看上去没毛病，但标准化后的每一个样本都携带了全局均值和方差的信息，而验证集的信息已经通过这些统计量流进了训练过程。时间序列场景更离谱，有人直接用整个序列的均值去填充某一段的缺失值，相当于拿未来的数据去预测过去。
我印象很深的一次项目里，团队用全量数据的中位数填补了一个缺失率高达四成的字段，离线AUC做到了0.89，整个办公室都很兴奋。结果上线之后模型表现一塌糊涂，后来排查发现，那个字段本身是否缺失其实携带了很强的业务信号，全局中位数一填，等于把未来分布硬塞进了训练集。修复方式也很简单：把填补逻辑放进交叉验证流程里，每一折只用当前训练折的数据去估计填充值。改完之后线下指标降到0.82，但大家反而松了一口气，因为这次是真实水平。
想避开泄漏，最可靠的做法是把所有预处理步骤包进流水线，让“拟合”只发生在训练数据内部。特征筛选也一样：先用全量数据算特征重要性再去选特征，同样属于偷看标签行为。每次拿到高得离谱的指标，第一反应不应该是庆祝，而是检查有没有泄漏。
1.2 分布漂移：模型上线后为什么悄悄退化
很多模型在离线评测时稳稳当当，上线之后过了几周就开始变差，业务方来问“是不是模型坏了”，其实模型参数一个都没动，变的是数据分布。
这个问题在学术上叫分布漂移，具体又分成协变量漂移和概念漂移。协变量漂移指的是特征的边缘分布变了，比如用户年龄结构忽然年轻化；概念漂移指的是“特征和标签之间的关系”变了，比如同样的点击行为，过去代表感兴趣，现在可能只是随手乱点。线上问题往往是两者混在一起。
我自己的习惯是给核心特征做分布监控，最简单的做法是每周统计特征均值、分位数和缺失率，和训练集做对比。有一个工程上常用的指标叫PSI，全称是群体稳定性指数，简单理解就是衡量两个分布差异有多大。经验阈值通常是：小于0.1说明分布稳定，0.1到0.2之间需要关注，超过0.2就要认真排查原因。
但要提醒一句：不是看到分布变了就要马上重训。很多短期波动会自然恢复，比如大促、节假日、季节性天气。贸然用这几天的数据重训，反而会把模型带偏。先分清楚是短期波动还是长期变化，再做决策。
1.3 特征尺度和缺失值：看似简单实则暗坑
特征尺度对树模型来说确实不敏感，所以很多做树模型的朋友长期不标准化，倒也问题不大。但如果你的模型是线性回归、逻辑回归、神经网络或者任何基于距离的模型，尺度差异会让训练过程变得异常痛苦，大数值特征会主导梯度，小数值特征等于被忽略。
更隐蔽的是稀疏特征。比如某个特征大量取0，少量取几百甚至几千，直接用常规标准化会把稀疏结构破坏掉。之前做一个推荐项目，用户行为次数这种特征长尾特别严重，不加处理的标准化让模型在低活用户上几乎失效。后来改成对数变换再做标准化，效果才正常。
缺失值处理的坑则更多。很多教程喜欢直接说“用均值填补”，实际上均值填补只有在缺失完全随机时才是勉强可用的方案。如果高收入人群更倾向于不填写收入字段，那么均值填补会系统性低估收入水平；如果用户是因为没有某个行为才没有记录，那缺失本身就是一个强特征。
我现在遇到缺失率超过三成的字段，第一反应不再是想办法填，而是认真想一下：这个字段真的要进模型吗？有时候直接丢弃反而更干净。缺失率低的时候，也优先考虑加一个“是否缺失”的标志位，而不是闷头填一个数进去。
2. 训练过程里的“玄学”：随机种子、批次顺序与学习率
2.1 为什么同一份代码两次运行结果不一样
刚接触训练的同学很容易被一个问题搞崩溃：代码一行没改，重新跑一遍，指标怎么不一样了？这不是你操作错了，而是训练过程本身就有随机性。
数据加载顺序的随机打乱、多线程并行时的浮点数累加顺序、GPU卷积实现的非确定性，都会造成结果波动。设置随机种子能显著减少这种波动，但并不能完全消除。我见过最夸张的一次，同一组超参数连续跑三遍，F1在0.83到0.86之间浮动，如果只跑一遍就下结论说某个改动有效，很可能得出完全错误的判断。
所以后来我在每次实验记录里固定记几样东西：随机种子、框架版本、计算设备型号、数据打乱顺序、损失函数下降曲线。不要嫌麻烦，没有这些信息，两周之后你根本没法判断两次实验的差异是改动的真实效果还是随机噪声。
实操上还有一个技巧：关键比较至少跑三次取均值，并且尽量固定相同的随机种子序列。虽然不能保证绝对公平，但能把噪声压到可接受范围。机器学习实验本质上是在做有噪声的对比，忽略噪声的结论都是不可靠的。
2.2 学习率怎么设：从固定值到warmup和衰减
学习率是我眼里最重要的超参数。太高，损失函数会在最优值附近震荡甚至发散；太低，训练半天损失几乎不动，白白浪费算力。很多初学者喜欢直接用一个固定值，比如0.001，一路训练到底，这也不是不行，但远没有把学习率调度用起来效果好。
我的做法是先做一个小范围扫描，用一小批数据试几个学习率，观察损失下降的速度，找到“能下降但又不震荡”的范围，然后在这个基础上引入两段式调度：前几个epoch用一个较小的学习率线性升温到峰值，之后按余弦曲线衰减到很小的值。升温阶段叫warmup，目的是让模型先稳定下来，避免一开始就用大学习率把参数冲乱。
# 演示用伪代码：warmup + 余弦衰减 for epoch in range(total_epochs): if epoch < warmup_epochs: lr = base_lr * (epoch + 1) / warmup_epochs else: progress = (epoch - warmup_epochs) / (total_epochs - warmup_epochs) lr = min_lr + 0.5 * (base_lr - min_lr) * (1 + cos(pi * progress)) apply_lr(optimizer, lr)这个写法在很多开源代码里都能见到，但很多人只是复制粘贴，不清楚为什么。warmup的本质是避免训练初期梯度方向不稳定导致的大幅参数更新，余弦衰减则让模型在后期慢慢收敛到更平滑的谷底。我实测下来，这个组合虽然不能保证每项任务都是最优，但普遍比固定学习率更稳。
2.3 验证集上的“假提升”：过拟合并不好分辨
过拟合这个词大家都懂，但真正在训练过程中判断“什么时候开始过拟合”并不容易。最常见的做法是盯着验证集损失，如果验证损失连续若干个epoch不降反升，就触发早停。道理谁都明白，执行起来却有个隐蔽的问题：你会忍不住在一个验证集上反复调参。
每调一次参，你都会看一眼验证集结果，这其实已经让验证集参与到了模型选择里。调得多了，验证集本身也被“过拟合”了，它不再是独立的评估标准，而是变成了一套你暗中背下来的答案。我见过有人在某个验证集上把指标从0.80调到0.88，信心满满地准备上线，换了一个时间段的数据立刻打回原形。
正确的做法是留出一个你平时根本不看的最终测试集，只在全部调参结束之后用它做一次最终评估。条件允许的时候还可以做嵌套交叉验证，外层评估泛化能力，内层做参数选择。至于早停，不要只看验证损失，最好配合一个具体的业务指标，比如AUC或F1，并且连续多个epoch不改善才算真正停滞，避免单次波动造成的误判。
3. 模型评估的几种常见误读
3.1 准确率之外：PR曲线和ROC曲线怎么选
分类问题最常用的评估指标是准确率，但准确率是最容易被误导的指标。正负样本比例悬殊的时候，比如二分类里正样本只占1%，哪怕模型什么都不学，只要全预测成负样本，准确率也是99%。所以面对不平衡数据，我几乎不看准确率。
很多人会用ROC曲线和AUC值来替代，这当然比准确率好，但ROC曲线有另一个问题：它对不平衡不敏感，在正样本极少的场景里，ROC曲线看起来仍然很乐观，可你真正关心的其实是“从大量负样本里捞出了多少正样本”，这时候PR曲线更贴近现实。
我自己的选择逻辑很简单：如果任务更看重正样本的召回率，比如风控、故障检测、医疗筛查，就用PR曲线或直接看Recall@K、Lift这些指标；如果正负样本比例相对均衡，或者你关心的是整体排序能力，ROC和AUC也够用。
| 场景 | 推荐指标 |
|---|---|
| 正负样本均衡，关心整体排序 | AUC / ROC |
| 正样本极少，关心正样本召回 | PR曲线 / Recall@K |
| 业务只关心头部命中率 | Lift / Precision@K |
| 预测概率的校准质量 | Brier Score / 校准曲线 |
顺便说一句，很多团队把AUC当唯一真理，但业务方真正关心的是“这个模型能不能帮我多赚点钱”。离线指标只是参考，千万别把它当成了终点。
3.2 交叉验证的折叠划分：分层与分组
交叉验证是评估模型泛化能力最常用的方法，但折叠划分的细节能直接决定评估结果的真实性。最常见的错误是直接对全部数据做随机切分，样本类别不均衡的时候，有些折里可能几乎没有正样本，模型在这个折上什么都学不到，指标自然上下乱跳。解决办法是用分层抽样，保证每一折的正负比例都和整体大致一致。
更隐蔽的问题是数据本身存在分组结构。比如推荐系统里同一个用户有几十条行为记录，如果用随机切分，同一个用户的行为会同时出现在训练集和验证集里，模型等于见过“这个人”再去预测“这个人”，评估结果虚高。这种场景必须用分组交叉验证，保证同一个用户的所有记录只落在同一折里。
时间序列数据也一样，随机打乱后训练用未来预测过去，这种评估完全失真。正确做法是按时间顺序切分，或者使用专门处理时间序列的切分工具，让训练集始终在验证集之前。
我用过一个推荐场景的项目，随机切分的AUC是0.90，改成按用户分组切分后变成0.80，差距大得吓人。那0.1的虚高不是模型能力，就是数据泄漏。
3.3 线上和线下评估的差异：离线指标不等于业务收益
离线评估做得再严谨，和线上真实环境之间也永远隔着一道鸿沟。原因之一是样本选择偏差：你用来训练的离线数据，很大程度上是旧版本模型筛选后的结果，用户在页面上看到什么、点了什么，都已经被过去的逻辑塑造过了。新模型看到的分布，和真正上线后的分布不会完全一致。
更麻烦的是反馈循环。模型上线后会改变用户行为，用户的新行为又变成下一轮训练数据，如果模型对某个群体过度压榨，它推荐的东西越来越单一，用户行为数据也会慢慢扭曲，最后模型陷入自我强化的偏见里。这些在离线评估阶段几乎看不出来。
所以我对新模型上线的态度是：离线指标要提升，但更重要的是提升幅度要超过可测量的噪声水平，然后做小流量的在线实验，用真实业务指标验证。别急着全量上线，先在5%的流量上试几天，看看业务核心指标是不是真的涨了，有没有伤害其他相关指标，再决定要不要放量。
4. 超参数调优的实战记录
4.1 网格搜索、随机搜索和贝叶斯优化到底怎么选
超参数调优的方法很多，但很多人一开始只会用网格搜索，把所有参数的候选值排列组合一遍，简单粗暴。网格搜索的问题是维度爆炸：每多一个参数，试验次数就翻好几倍，参数稍微多一点就跑不动。
随机搜索的思路完全不同，它不是把所有组合都试一遍，而是从参数分布里随机采样。听起来不如网格搜索“全面”，但实际上效率高得多。原因很简单：不同超参数对模型效果的影响并不一样，有的参数存在明显的“好区间”，随机搜索能更快地撞进这些区间。我在一个树模型项目里用过网格搜索，跑了200组试验，后来用随机搜索只跑了80组就找到了几乎差不多的结果。
贝叶斯优化则更进一步，它会根据已经跑过的试验结果，估计哪个参数区域最有可能提升指标，然后有针对性地选择下一组参数。单次训练很贵、总预算有限的场景下，贝叶斯优化是更好的选择。但它也有自己的超参数要调，而且在小规模问题上未必比随机搜索快多少。
| 方法 | 适用场景 | 备注 |
|---|---|---|
| 网格搜索 | 参数少、候选值少 | 简单但昂贵，适合最后微调 |
| 随机搜索 | 参数较多、预算中等 | 效率高于网格搜索，推荐优先使用 |
| 贝叶斯优化 | 单次训练昂贵、预算有限 | 利用历史信息，但实现和维护成本更高 |
我的实际流程是：先用随机搜索粗筛，找到效果比较好的区域，再在附近用网格搜索细化。不要一上来就上最复杂的方法，很多时候随机搜索已经足够。
4.2 调参顺序：先调什么后调什么
调参最忌讳的就是同时改好几个变量，改完都不知道是谁起的作用。理想顺序应该是：先确认数据流程没问题，损失函数定义正确，然后才进入超参数搜索阶段。
对于树模型，我一般先调学习率和树的数量，这两个参数决定了模型的整体拟合能力，之后再调树深度、叶子节点最小样本数这些结构参数，最后才动正则化相关的参数。顺序很重要，因为结构参数和正则化参数的效果高度依赖前面的学习率设置，顺序反了会出现很多假象。
神经网络则略有不同：学习率永远优先，其次是批次大小，然后是网络宽度和深度，最后是Dropout这类正则化手段。原因在于学习率决定了整个训练过程的走向，批次大小影响梯度的稳定性，网络结构决定模型容量，正则化只是最后的约束。
我每次调参都会维护一张实验记录表，包含参数组合、验证指标、训练时间和随机种子。这张表看似简单，但能帮你避免重复试验，也能让你回头复盘的时候看清每一步的因果关系。
4.3 早停和模型保存：怎么避免白跑一晚
训练跑了整整一晚上，早上来看发现验证loss已经回升了很久，模型停留在过拟合状态——这种经历我相信很多人都有过。原因往往不是没做早停，而是只保存了最后一个epoch的模型，没有保存验证指标最优的那个时刻。
很多框架都提供了回调功能，可以在每个epoch结束时判断验证指标是否变好，如果是，就保存一份检查点，包含模型权重、优化器状态、当前epoch和最优指标值。训练结束后，直接加载那份最优检查点，而不是默认的最终权重。
我有个朋友在文本分类项目里遇到过一次惨痛教训：最佳epoch的F1是0.88，但因为只保存了最终模型，最后线上用的是0.85的那个版本。训练一天一夜，白跑了。后来他改成长久保存最优检查点，再也没有发生过类似问题。
检查点文件最好连优化器状态一起保存，这样如果你想从那个时刻继续训练，可以直接恢复，不用从头再来。磁盘占用多一点，换来的却是实打实的安心。
5. 模型上线后的监控与重训
5.1 监控指标怎么选：不只是准确率
模型上线之后，很多人就撒手不管了，直到业务方投诉才想起来看一眼。到那个时候，问题已经发生了好几周，定位成本非常高。我现在的习惯是上线第一天就把监控搭好，上线之后持续观察。
线上最麻烦的地方在于，你不能立刻拿到真实标签，离线指标像AUC根本算不出来。所以监控的重点要换成可以实时计算的代理指标：预测分数的分布、特征值的分布、特征缺失率、请求成功率、覆盖率，以及业务核心指标比如点击率、转化率、成交金额。预测分数分布是最敏感的报警器，因为它能第一时间反映输入特征的变化。
| 监控对象 | 常见报警信号 |
|---|---|
| 预测分数分布 | 均值、分位数明显偏移 |
| 特征分布 | 缺失率升高、某个特征取值集中 |
| 业务指标 | 点击率、转化率连续下跌 |
| 数据质量 | 字段类型变化、时间字段异常 |
我经历过一次风控模型上线后的故障，连续几天预测均值从0.3慢慢漂到0.5，业务反馈倒是延迟了两周才来。后来查明是上游某个特征口径变了，单位从“天”改成了“小时”。如果不是监控了预测分布，这个问题还会藏更久。
5.2 重训触发条件：定期重训还是按漂移触发
关于重训，分成两派：一派按照固定周期重训，比如每周或每月跑一次；另一派用漂移检测触发，发现异常再重训。我自己的经验是，单独用任何一种都不够稳妥。
固定周期重训的缺点在于，它不区分数据到底变没变，有时候明明数据还很稳定，重训只是浪费算力，甚至可能引入短期噪声。按漂移触发则容易反应过激，大促那几天数据当然会突变，可你要是在大促数据上重训，活动结束之后模型很可能就废了。
比较稳妥的组合是“定期检查+异常触发”：每天自动检查监控指标，一旦发现预测分布或特征分布超过阈值，就告警；每个固定周期自动重训一次，但重训前必须做离线验证，并且保留旧模型，新模型先灰度再全量。所谓灰度，就是让新模型只服务一小部分流量，对比一下真实业务指标，没问题再放开。
另外提醒一句：重训不是万能的。如果问题根源是特征口径错了、上游数据源断了，或者标签定义本身有问题，重训再多次也解决不了。先定位原因，再决定要不要重训。
5.3 一次线上事故的复盘：特征口径不一致
有一次做推荐模型的迭代，训练阶段用的是离线数仓里的“用户最近30天点击次数”，上线时实时特征工程师给的特征命名很接近，叫“用户当天点击次数”。两个字段名字就差一个词，代码也没有任何报错，模型就这么上线了。
结果是预测的点击率整体偏低，用户本来就爱点的内容被模型压到了后排。问题排查了很长时间，最后是靠预测分布监控发现输入特征均值比训练集差了十倍，才追查到特征口径。这种错误在离线评估阶段根本不会暴露，因为离线特征管道和线上特征管道是两套完全不同的代码。
这次事故之后，我养成了一个习惯：在项目里维护一份特征字典，把每个特征的含义、计算窗口、单位、来源表、更新频率全部写清楚，上线前逐个人工检查离线特征和线上特征的对应关系，再做一致性测试。听起来繁琐，但比起线上事故的代价，这点成本低得多。
6. 这份笔记怎么记，才不至于变成流水账
6.1 按问题记录，而不是按知识点
我见过很多人记笔记，喜欢把书里的公式和定义抄一遍，抄完就放在角落里吃灰。这种笔记不是没有价值，而是完全没有个人经验的沉淀，等于低效抄书。
后来我换了一种方式：每条笔记先写一个背景，一句话说清楚当时在做什么项目、遇到什么问题；然后是排查过程，一步一步列出试过的方法和现象；最后是结论，以及如果重来一次会怎么做。这种按问题组织的笔记，才真正能在下次遇到类似困境的时候派上用场。
比如“为什么验证集AUC很高但线上不行”这一条，记录的不只是结论，还有我和团队排查的每一个环节、踩过的每一个弯路。下次有人再遇到，我甚至可以直接把这篇笔记丢给他看。
6.2 把失败和无效尝试也留下来
大多数人记笔记只记成功的方案，失败的尝试一概不写。我反而觉得，失败记录往往更值钱。一次调参可能会试五组方案，其中四组无效，如果你只记录有效的那一组，下次你还会再试那四组无效的，白白浪费一个晚上。
所以我在笔记里专门有一个“无效尝试”分区，每条记录写清楚：试了什么方法、什么参数、结果如何、为什么无效。比如“加了L2正则化但验证集反而变差，可能是模型容量本就不够”，这种记录比教科书里的标准结论更有参考价值。
记笔记这件事本身也需要迭代。每隔一到两个月，我会把旧笔记重新翻一遍，把已经没用的删掉，把值得保留的重新整理。这个过程看起来很费时间，但实际上是在梳理自己的方法论，让下一次踩坑的概率变得更低。几年下来，这本机器学习笔记已经成了我最值钱的实战资产。
)
