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")

这样你至少能做到三件事：

1. 模型版本 ↔ 特征版本 强绑定
2. 线上问题能回溯
3. A/B 实验敢做，不怕翻车

五、三个我亲眼见过的“血泪级陷阱”

❌ 陷阱一：MLOps 只给算法用

如果：

• 数据同学不知道 Feast
• 运维同学没见过 MLflow
• 业务同学只看结果

那 90% 会失败。

MLOps 是跨角色协作工具，不是算法玩具。

❌ 陷阱二：一开始就追求“完美流程”

• 自动训练
• 自动评估
• 自动上线

现实是：

“80% 的系统，死在第一步没跑通。”

建议路径：

手动流程稳定 → 半自动 → 再自动

❌ 陷阱三：没人为“特征变化”负责

这是最要命的。

我见过最离谱的一次：

• 特征字段改了
• 模型没变
• 线上指标腰斩
• 查了两天

最后一句话总结：

“数据变了，没人知道。”

六、说点个人感受：MLOps 是工程，不是信仰

这些年我最大的体会是：

• 工具永远比人靠谱
• 但工具永远替代不了责任

MLflow、Feast 不是用来“显得专业”的，
是用来：

• 让你不背锅
• 让团队少吵架
• 让系统能活久一点

如果你现在还在：

• 模型版本靠 Excel
• 特征靠复制 SQL
• 上线靠祈祷

那真的可以试试 从 MLflow + Feast 这两个点开始，别一步登天，先把地基垫稳。

最后一句

MLOps 的本质不是自动化，是“可控”。
可控，才谈得上规模；
不可控，再高级的工具也只是装饰。