从618大促到AI编程：一个后端老鸟的机器学习入门实战
去年双11凌晨三点，我正坐在工位上盯着一堆报警邮件，突然收到一条来自新老板的钉钉消息：“下个季度我们要搞智能推荐，你先研究下机器学习。”当时我内心OS：我是写Java的，不是算法工程师啊！但转念一想，跳槽面试时好几个公司都问了ML基础，这波不学不行了。
入职新公司两个月，团队氛围倒是比京东轻松不少——至少不用半夜爬起来处理流量洪峰。但技术债也不少，老系统还在用规则引擎做商品推荐，转化率感人。领导说：“既然你有大促经验，那这块就交给你了。”得，又被赶鸭子上架。
为什么后端要懂点机器学习？
说实话，一开始我对“AI”这个词有点PTSD。在京东那几年，每次大促前算法团队都会甩过来一堆“黑盒模型”，我们后端只负责API对接和扛流量。结果有一次模型输出异常，导致首页推荐全是拖把和马桶刷（用户搜了“清洁”），被产品经理追着骂了一周。
现在自己要动手，才发现理解基础算法逻辑有多重要。不是要你手推梯度下降，而是知道什么场景该用什么模型、数据预处理要注意什么、怎么评估效果。这样和算法同事沟通时才不会被当“工具人”。
我的入门路径：从Claude聊起
别笑，我重度依赖Claude已经成了团队公开的秘密。上周五晚上加班调特征工程，Claude直接帮我写了个pandas数据清洗脚本，比我自己写的还规范。它甚至能解释“为什么用StandardScaler而不是MinMaxScaler”——这种即时反馈对新手太友好了。
但光靠AI可不行。我给自己定了个实战目标：用真实业务数据训练一个点击率预测模型。数据源是公司脱敏后的用户行为日志，包含用户ID、商品ID、曝光时间、是否点击等字段。
踩的第一个坑：数据比代码难搞
原以为拿数据跑sklearn就行，结果发现：
- 30%的用户没有历史行为（冷启动问题）
- 商品ID是字符串，需要编码
- 时间戳没处理，直接喂给模型会过拟合
这时候Claude的作用就体现出来了。我问它：“用户行为数据稀疏怎么办？”，它建议：
- 用Item2Vec生成商品Embedding
- 对新用户用热门商品兜底
- 加入时间窗口特征（比如最近1小时点击数）
虽然最后我没用Item2Vec（太重了），但思路打开了。最终方案是：
# 用LabelEncoder处理商品ID（简单粗暴但有效）
from sklearn.preprocessing import LabelEncoder
le = LabelEncoder()
df['item_id_encoded'] = le.fit_transform(df['item_id'])
# 构造滑动窗口特征
df['click_last_1h'] = df.groupby('user_id')['is_click'].rolling('1h').sum().values
算法选型：别一上来就搞Transformer
很多新人（包括曾经的我）总想直接上深度学习。但现实是：简单模型+好特征 > 复杂模型+烂特征。我试了三种方案：
| 模型 | AUC | 训练时间 | 部署难度 | 适合场景 |
|---|---|---|---|---|
| 逻辑回归 | 0.72 | 2分钟 | ⭐ | 特征明确，需快速验证 |
| 随机森林 | 0.78 | 15分钟 | ⭐⭐ | 特征非线性，有交互 |
| XGBoost | 0.81 | 8分钟 | ⭐⭐ | 结构化数据，追求精度 |
最后选了XGBoost——AUC提升明显，而且支持增量训练（大促期间数据源源不断）。特别感谢Claude提醒我调参：max_depth=6比默认值效果好，subsample=0.8能防过拟合。
开发心得：后端视角的ML工程化
作为后端，我最关心的不是准确率，而是如何把模型塞进现有系统。这里分享几个血泪经验：
1. 特征一致性比模型精度更重要
线上和线下用的特征必须完全一致！有次测试环境用了最新7天数据，线上却用30天，导致模型效果暴跌。现在我们用Feature Store统一管理，虽然小公司没必要上Feast，但至少要保证特征计算逻辑复用。
2. 别信离线指标
AUC高≠线上效果好。我们在测试集群做了AB测试：对照组用规则引擎，实验组用XGBoost。结果CTR提升了12%，但GMV只涨了3%——因为模型过度推荐高点击低客单价商品。后来加了多目标优化（点击率+转化率加权），才解决这个问题。
3. 监控！监控！监控！
模型上线后第三天，报警显示预测分布突变。排查发现是某个商品类目ID变更，导致特征编码错乱。现在我们监控：
- 输入特征分布（PSI<0.1）
- 预测分数分布
- 推荐多样性（避免信息茧房）
Rust彩蛋：未来可能用它重写推理服务？
最近沉迷Rust，发现它的内存安全特性特别适合做推理服务。虽然Python生态无敌，但高并发场景下GIL是硬伤。用Rust+WASM写了个简单的LR推理模块，QPS比Flask高5倍（当然，没考虑复杂特征处理）。
不过老板说：“先把Python版跑稳了再折腾。” 唉，理想很丰满，deadline很骨感。
给同行的建议
如果你也像我一样被“赶鸭子上架”，记住：
- 从具体业务问题出发，别为了AI而AI
- 善用AI工具但保持怀疑，Claude给的代码一定要自己跑一遍
- 重视数据质量，垃圾进=垃圾出
- 小步快跑，先上线简单模型再迭代
现在回头看，机器学习没那么玄乎。它就是一套解决问题的工具，和我们写缓存、搞分库分表没本质区别。关键是要动手做——哪怕只是用sklearn跑通第一个例子。
上周产品又来找我：“能不能加个实时兴趣更新？” 我笑了笑：“行啊，不过得先给我加两个服务器。” （手动狗头）
后记：写完这篇已经是凌晨一点，突然想起明天还要review推荐系统的K8s配置。果然，程序员的世界里，没有真正的“下班”。但看到自己搞的模型真的带来业务增长，那种成就感，比双11零点清空购物车还爽。
评论 0