试用期踩坑实录：从“Hello World”到上线一个 ML 服务，我到底经历了什么？
大家好，我是小张，坐标深圳南山科技园，刚入职一家腾讯系背景的中型互联网公司（出于保密，名字不能说 😅），目前还在试用期。每天战战兢兢写代码，生怕哪天 PR 被 reviewer 喷得体无完肤，或者线上炸了被拉去复盘背锅。
之前一直在做前端，对动画和交互动效特别上头——CSS keyframes 写得比女朋友发的消息还流畅。但谁能想到，上周产品经理突然找我：“小张啊，我们想在用户点击按钮时，根据历史行为预测他下一步要做什么，搞个智能引导……你不是会 Python 吗？这个模型部署就交给你啦！”
我当时内心 OS：我会 Python 是因为爬过 B 站评论，不代表我能搞机器学习部署啊！
但试用期员工哪敢说不？只能硬着头皮上。于是，这篇博客诞生了——记录我从“算法是啥”到成功把一个基于 Python 的轻量级推荐模型部署上线的全过程。如果你也正处在“被业务需求推着走”的边缘，希望我的血泪经验能帮你少熬两个通宵。
需求背景：不是炫技，是为了活命
我们的产品是一个内容创作工具，用户会在编辑器里进行一系列操作（比如插入图片、调整字体、导出 PDF）。PM 想在用户完成某个操作后，动态预测他接下来最可能做的动作，然后在 UI 上高亮提示——这本质上是个多分类序列预测问题。
数据我们有：过去三个月的用户行为日志，每条记录包含 user_id, action_sequence（比如 ["open", "insert_image", "resize"]），以及时间戳。
目标很明确：训练一个模型，输入最近 3 个动作，输出下一个动作的概率分布。听起来简单？但部署才是真正的地狱。
踩坑 1：本地跑得欢，线上跑不动
我先用 sklearn + RandomForestClassifier 快速搭了个 baseline，准确率 78%，还不错！本地测试一切正常：
from sklearn.ensemble import RandomForestClassifier
import joblib
# 训练
clf = RandomForestClassifier(n_estimators=100)
clf.fit(X_train, y_train)
# 保存
joblib.dump(clf, 'next_action_model.pkl')
结果一交给后端同学集成，他就皱眉：“你这模型加载要 5 秒？我们接口 SLA 是 200ms 啊兄弟！”
我：？？？本地明明秒开！
后来才知道，线上容器内存只有 512MB，而我的模型文件 120MB，加载时直接 swap 到爆。那一刻我真想砸键盘。
踩坑 2：环境依赖像俄罗斯套娃
为了减小体积，我转战 scikit-learn 的轻量替代品——lightgbm。训练快、模型小、支持 categorical feature，完美！
但新问题来了：开发机是 macOS，测试环境是 Ubuntu 20.04，生产是 Alpine Linux。光是 pip install lightgbm 就在不同环境报了三种错：
- macOS：
clang: error: no such file or directory - Ubuntu：
g++ not found - Alpine：
musl libc 不兼容
最后靠 Docker 才搞定。这里强烈建议：ML 服务必须容器化，别信“在我机器上能跑”这种鬼话。
Dockerfile 关键片段：
FROM python:3.9-slim
RUN apt-get update && apt-get install -y \
build-essential \
libgomp1 \
&& rm -rf /var/lib/apt/lists/*
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . /app
WORKDIR /app
CMD ["uvicorn", "app:app", "--host", "0.0.0.0", "--port", "8000"]
注：用了
uvicorn而不是 Flask，因为 ASGI 对异步推理更友好（虽然我的模型是同步的，但未来可扩展）。
踩坑 3：算法选型不是越 fancy 越好
一开始我想上 LSTM，毕竟处理序列嘛！结果训练三天，调参到秃头，线上推理延迟 800ms，PM 直接摇头：“不如写个 if-else 规则。”
痛定思痛，回归朴素：用 n-gram + TF-IDF + LogisticRegression，不仅训练快（10 分钟搞定），模型才 8MB，推理 < 50ms！
| 模型方案 | 准确率 | 模型大小 | 推理延迟 (P95) | 开发耗时 |
|---|---|---|---|---|
| LSTM | 81% | 150MB | 780ms | 3 天 |
| LightGBM | 79% | 25MB | 120ms | 1 天 |
| TF-IDF + LR | 77% | 8MB | 45ms | 半天 |
有时候，业务容忍度 > 算法精度。只要效果“看起来聪明”，用户感知强，就够了。这点在试用期尤其重要——先上线，再迭代。
最终方案：FastAPI + 模型缓存 + 健康检查
为了快速交付，我用 FastAPI 写了个极简推理服务：
# app.py
from fastapi import FastAPI
import joblib
from pydantic import BaseModel
app = FastAPI()
model = None
@app.on_event("startup")
async def load_model():
global model
model = joblib.load("model.pkl") # 启动时加载一次，避免每次请求都读磁盘
class RequestBody(BaseModel):
actions: list[str] # e.g., ["open", "insert_image"]
@app.post("/predict")
def predict(req: RequestBody):
features = featurize(req.actions) # 自定义特征工程
probs = model.predict_proba([features])[0]
top_action = model.classes_[probs.argmax()]
return {"next_action": top_action, "confidence": float(probs.max())}
@app.get("/health")
def health():
return {"status": "ok", "model_loaded": model is not None}
关键点：
- 模型只在服务启动时加载一次，避免 I/O 瓶颈
- 加了
/health接口，方便 K8s 做 liveness probe - 特征工程函数
featurize要和训练时完全一致（我曾因大小写问题导致线上 NaN）
部署上线 & 效果
上周五晚上 10 点，在运维小哥的“亲切指导”下，终于把服务挂到了 K8s 集群。配置了 HPA（水平 Pod 自动扩缩容），QPS 从 0 到 200 都稳如老狗。
上线三天后看数据：
- 接口平均延迟 62ms
- 成功率 99.98%
- 用户点击“智能提示”的转化率提升 12%
PM 终于露出了慈祥的笑容，还请我喝了杯瑞幸（试用期员工的最高荣誉 🥲）。
写给和我一样的“被迫转型”程序员
如果你和我一样，原本是前端/后端，突然被塞了个 ML 任务，别慌。记住几点：
- 先跑通，再优化：别一上来就想搞 Transformer，线性模型往往够用。
- 部署成本 > 训练成本：模型再准，跑不起来等于零。
- 容器化是底线：别让运维半夜打电话骂你。
- 监控和日志不能省：加个
/metrics接口，用 Prometheus 抓一下 QPS 和延迟。 - 和 PM 对齐预期：77% 的准确率如果能带来业务价值，那就是 100 分。
最后，感谢公司给我这个“边学边干”的机会（虽然可能是试用期考核的一部分 😅）。也感谢开源社区，没有 FastAPI、LightGBM、Docker，我可能还在改 requirements.txt。
对了，听说下个月要搞 A/B Test，对比新旧引导策略……看来我的试用期还没结束，战斗仍将继续。
彩蛋：如果你在深圳，欢迎约 coffee 聊前端动画 or ML 部署踩坑。但别聊算法复杂度，我怕我哭出来。
评论 0