MLflow / Feast 实战手记：MLOps 不是装工具，是治内伤
副标题：工具装上 5 分钟，坑踩三个月
这两年，MLOps 火得不行。
MLflow、Feast、Kubeflow、Airflow、Argo 一字排开，PPT 上一看，仿佛只要点几下鼠标，模型就能自动训练、自动上线、自动赚钱。
但现实是啥？
工具是装上了，模型还是“靠人肉”；
流程是画好了，问题还是“靠吼”。
今天咱就不吹概念，直接聊 MLflow / Feast 在真实项目里，哪些点真能救命，哪些地方最容易翻车。
一、先说一句掏心窝子的：MLOps 的敌人不是技术，是“将就”
我见过太多团队，一上来就说：
- “我们要标准 MLOps”
- “我们要模型全生命周期治理”
- “我们要对标大厂”
结果最后：
- 训练脚本在个人电脑
- 特征 SQL 到处复制
- 模型版本靠微信群同步
- 上线靠
scp
MLOps 工具不是灵丹妙药，它解决的是“已经混乱的地方”，不是“从零创造秩序”。
二、MLflow：不是日志工具，是“模型的户口本”
1️⃣ MLflow 真正该解决的问题
很多人用 MLflow，只干一件事：
👉 记录 loss、accuracy
说句实在的，这属于“买跑车拉白菜”。
MLflow 的核心价值是三件事：
- 实验可追溯
- 模型可复现
- 版本可回滚
一句话总结：
“这个模型是谁、什么时候、用什么数据、什么代码、跑出来的？”
2️⃣ 一个“像人话”的 MLflow 使用姿势
import mlflow
import mlflow.sklearn
with mlflow.start_run(run_name="lr_v1"):
mlflow.log_param("lr", 0.01)
mlflow.log_param("max_iter", 100)
mlflow.log_metric("auc", 0.82)
mlflow.sklearn.log_model(model, "model")
这段代码不稀奇，但真正拉开差距的是：你记不记录“上下文”。
我强烈建议额外记三类东西：
mlflow.set_tag("data_version", "ods_user_v202401")
mlflow.set_tag("feature_view", "user_profile_v3")
mlflow.set_tag("git_commit", "a9f3c2e")
否则半年后你只会问一句：
“这模型当年是怎么跑出来的？”
然后没人敢动它。
3️⃣ MLflow 的第一个大坑：本地文件模式
很多团队一开始图省事：
mlflow ui --backend-store-uri ./mlruns
后果只有一个：
“只要那台机器没了，历史就消失了。”
正确姿势：
- Backend Store：MySQL / Postgres
- Artifact Store：S3 / MinIO / OSS
MLflow 是“系统资产”，不是“开发者个人配置”。
三、Feast：特征工程不是 SQL，是“契约”
如果说 MLflow 管的是 模型，
那 Feast 管的就是 模型吃的饭。
1️⃣ 为什么你迟早会需要 Feast
常见的翻车现场：
- 离线训练用一套 SQL
- 在线服务又写一套
- 特征口径“看起来一样，其实不一样”
然后模型线上表现直接跳水。
这不是模型问题，是“特征口径漂移”。
Feast 的价值一句话说清楚：
“特征定义一次，离线在线用同一套逻辑。”
2️⃣ 一个最小可落地的 Feast 示例
from feast import FeatureView, Field
from feast.types import Float32
user_fv = FeatureView(
name="user_profile",
entities=["user_id"],
ttl=None,
schema=[
Field(name="age", dtype=Float32),
Field(name="ctr_7d", dtype=Float32),
],
source=user_source,
)
重点不在代码，而在 FeatureView 这个抽象：
- 它是 数据口径的“合同”
- 谁改了，谁负责
- 改不改，必须可追踪
3️⃣ Feast 的致命误区：当成“特征仓库”
很多团队一股脑把所有字段往 Feast 里塞：
- 明细字段
- 临时特征
- Debug 字段
结果：
- Repo 巨大
- 发布慢
- 没人敢删
我的建议很直白：
Feast 只放“跨模型、可复用、强语义”的特征。
临时特征？
👉 留在训练代码里，别污染全局。
四、MLflow + Feast 联动，才是真·MLOps
最舒服的状态应该是：
features = feast_client.get_online_features(
features=[
"user_profile:age",
"user_profile:ctr_7d",
],
entity_rows=[{
"user_id": uid}],
)
mlflow.set_tag("feature_view", "user_profile_v3")
这样你至少能做到三件事：
- 模型版本 ↔ 特征版本 强绑定
- 线上问题能回溯
- A/B 实验敢做，不怕翻车
五、三个我亲眼见过的“血泪级陷阱”
❌ 陷阱一：MLOps 只给算法用
如果：
- 数据同学不知道 Feast
- 运维同学没见过 MLflow
- 业务同学只看结果
那 90% 会失败。
MLOps 是跨角色协作工具，不是算法玩具。
❌ 陷阱二：一开始就追求“完美流程”
- 自动训练
- 自动评估
- 自动上线
现实是：
“80% 的系统，死在第一步没跑通。”
建议路径：
手动流程稳定 → 半自动 → 再自动
❌ 陷阱三：没人为“特征变化”负责
这是最要命的。
我见过最离谱的一次：
- 特征字段改了
- 模型没变
- 线上指标腰斩
- 查了两天
最后一句话总结：
“数据变了，没人知道。”
六、说点个人感受：MLOps 是工程，不是信仰
这些年我最大的体会是：
- 工具永远比人靠谱
- 但工具永远替代不了责任
MLflow、Feast 不是用来“显得专业”的，
是用来：
- 让你不背锅
- 让团队少吵架
- 让系统能活久一点
如果你现在还在：
- 模型版本靠 Excel
- 特征靠复制 SQL
- 上线靠祈祷
那真的可以试试 从 MLflow + Feast 这两个点开始，别一步登天，先把地基垫稳。
最后一句
MLOps 的本质不是自动化，是“可控”。
可控，才谈得上规模；
不可控，再高级的工具也只是装饰。
