AI模型训练调优的实战血泪史
上周五晚上十一点，我坐在工位上盯着屏幕上跳动的loss曲线，手边的咖啡已经凉透。入职新公司两个月，这是我第一次独立负责一个AI模型训练项目——给短视频推荐系统加一个实时兴趣预测模块。说真的，虽然在快手干了六年架构，从0到1搭过推荐、风控、直播推流这些核心系统，但面对AI这块，还是有点心虚。
毕竟，以前更多是搭管道、搞调度、做高可用，现在突然要调参、选模型、搞数据清洗，感觉像是让一个老司机去造发动机。不过也好，趁这个机会把AI这块短板补一补，不然以后跟算法同学开会都插不上话。
为什么这次调优这么难？
我们的业务场景其实挺典型：用户刷短视频，系统要在500ms内预测他接下来可能感兴趣的内容类别。数据量不大，每天大概200万条用户行为日志，但特征维度高，而且实时性要求高。最初团队直接套了个GPT-4o的微调方案，结果线上效果一塌糊涂，CTR（点击率）反而降了3%。
产品经理一脸无辜地问：“不是说GPT-4o很强吗？怎么越调越差？”
我只能苦笑：“大哥，GPT-4o是通用大模型，咱们这是垂直场景，得精调，不是直接搬。”
后来复盘发现，问题出在几个地方：
- 数据没做有效采样，冷启动用户占了30%，但模型根本学不到他们的行为模式
- 特征工程太粗糙，把用户历史点击序列直接喂进去，没做时间衰减
- 超参全靠猜，batch size、learning rate、dropout rate 都是默认值
这哪是AI训练，简直是“玄学炼丹”。
综合策略：别只盯着模型，先看数据和流程
在快手那几年，我学到最重要的一点就是：系统性思维。AI模型不是孤立的，它依赖数据管道、特征存储、在线服务整个链条。所以我决定先不急着换模型，而是从头梳理整个训练流程。
第一步，用 OpenCode 搭了个轻量级实验平台。OpenCode 是我们内部开源的一套ML工程框架，支持自动记录实验配置、指标、代码版本。好处是，每次跑实验，参数、数据切片、模型结构都会自动存档，再也不用靠脑子记“上次是不是改了learning rate”。
# experiment_config.yaml
model: transformer_interest_predictor
data:
train_path: /data/interest_20240601_20240615.parquet
val_path: /data/interest_20240616_20240620.parquet
negative_sampling_ratio: 5
hyperparams:
batch_size: 256
learning_rate: 0.0003
dropout: 0.3
max_seq_len: 50
features:
user_id: categorical
item_category: categorical
click_time: temporal (with decay)
dwell_time: numerical (log normalized)
第二步，重新做特征工程。我们引入了时间衰减权重，最近7天的行为权重设为1.0，7-30天设为0.5，30天以上直接丢弃。同时，对冷启动用户，用群体兴趣均值做填充，而不是留空。
第三步，搞了个综合评估体系。不再只看AUC或Accuracy，而是结合业务指标：线上CTR、人均观看时长、负反馈率（比如快速划走）。毕竟，模型再漂亮，用户不买账也是白搭。
模型选择：GPT-4o 真的适合你吗？
说到 GPT-4o，它确实强，但强≠合适。我们试过两种路径：
- 直接微调 GPT-4o：输入用户行为序列，输出下一个兴趣标签。结果显存炸了，推理延迟飙到1.2s，完全没法上线。
- 蒸馏小模型：用 GPT-4o 作为 teacher model，生成软标签，再训练一个轻量级 Transformer。这才靠谱。
最终我们选了一个两层的 Transformer + MLP 结构，参数量不到1M，推理时间压到300ms以内。关键代码如下：
class InterestPredictor(nn.Module):
def __init__(self, vocab_size, embed_dim=128, num_heads=4, dropout=0.3):
super().__init__()
self.embedding = nn.Embedding(vocab_size, embed_dim)
self.pos_encoding = PositionalEncoding(embed_dim)
self.transformer = nn.TransformerEncoder(
nn.TransformerEncoderLayer(
d_model=embed_dim,
nhead=num_heads,
dropout=dropout,
batch_first=True
),
num_layers=2
)
self.classifier = nn.Sequential(
nn.Linear(embed_dim, 64),
nn.ReLU(),
nn.Dropout(dropout),
nn.Linear(64, num_classes)
)
def forward(self, x, mask=None):
x = self.embedding(x) # [B, L, D]
x = self.pos_encoding(x)
x = self.transformer(x, src_key_padding_mask=mask)
# 取最后一个非padding token的输出
last_hidden = x[torch.arange(x.size(0)), (~mask).sum(1) - 1]
return self.classifier(last_hidden)
这里有个坑：Transformer 对 padding 敏感。我们一开始没处理好 mask，导致模型把大量 padding token 当作有效信号，loss 下不去。后来加了 src_key_padding_mask，才稳住。
Trae：我的调参新宠
说到调参，以前我都是手动改 config，跑一次等半天，效率低到想哭。这次我试了 Trae —— 一个基于贝叶斯优化的自动化超参搜索工具（内部版，类似 Optuna 但更贴合我们infra）。
Trae 的优势在于：
- 支持早停（early stopping），如果某个 trial 的验证集 loss 连续3轮不降，自动 kill
- 能和 OpenCode 无缝集成，实验结果自动归档
- 支持分布式搜索，10台机器并行跑，一天能试200+组参数
我们设了搜索空间：
| 参数 | 范围 |
|---|---|
| learning_rate | [1e-5, 1e-3] log-uniform |
| batch_size | [128, 512] step=64 |
| dropout | [0.1, 0.5] uniform |
| num_heads | [2, 8] categorical |
跑了两天，Trae 找到的最佳组合是：lr=2.1e-4, batch=384, dropout=0.25, heads=6。比我们手动调的 baseline 提升了 4.2% AUC。
最爽的是，我不用再半夜爬起来看训练日志了。Trae 自动发钉钉消息：“【Trae】实验 interest_pred_v3 已完成，AUC=0.872，优于当前最优 0.831”。
安全意识：别让模型变成“后门”
最后说个容易被忽略但极其重要的点：模型安全。
在快手时，我们吃过亏。有次上线一个推荐模型，结果被黑产利用，通过伪造用户行为，把低质内容推到热门。所以这次，我特意加了三道防线：
- 输入校验：所有用户行为必须经过风控系统打标，异常流量直接过滤
- 特征扰动测试：对关键特征（如点击时间）加随机噪声，看模型输出是否剧烈波动
- 对抗样本检测：用 FGSM 生成对抗样本，测试模型鲁棒性
代码里也加了监控：
# 在训练循环中加入异常检测
if torch.isnan(loss) or loss > 10.0:
logger.warning(f"Abnormal loss detected: {loss.item()}")
# 自动暂停训练，通知值班
alert_oncall("Model training unstable!")
毕竟，一个不安全的AI模型，比不用还危险。
成果与反思
上线两周后，新模型带来：
- CTR 提升 5.8%
- 人均观看时长 +12秒
- 冷启动用户留存率 +7%
虽然数字不算爆炸，但稳扎稳打，没出事故。最重要的是，整个流程跑通了：从数据采集 → 特征工程 → 模型训练 → 自动调参 → 安全验证 → 灰度发布。
回想起来，这次经历让我明白：AI工程化，核心不是模型多 fancy，而是流程多可靠。GPT-4o 再强，也得适配业务；Trae 再智能，也得有人定边界；OpenCode 再好用，也得配合规范。
对了，我现在还是 Vim 党，写 PyTorch 代码照样用 vim + coc.nvim，虽然同事笑我“复古”，但手指肌肉记忆改不了啊。上周还因为误按 dd 删了半截 config，差点重训……
总之，如果你也在折腾AI模型，别光盯着论文和SOTA，先把数据管道、实验管理、安全监控这些“脏活”做好。毕竟，我们不是在参加Kaggle比赛，而是在做能扛住双11流量的生产系统。
共勉。
评论 0