一个「买了全套工具，但还是搞砸了」的故事

2026年，某AI公司买了全套MLOps工具——MLflow用于实验管理、Feast用于特征存储、Kubeflow用于管道编排、Evidently用于模型监控、Seldon用于模型部署。工具投入超过100万美元。

6个月后，公司的MLOps状况是：

  • 数据科学家仍然在Jupyter Notebook里手动训练模型
  • 模型版本管理仍然靠「model_v1_final_final_final.pkl」
  • 模型部署仍然靠「手动ssh到服务器，然后docker run」
  • 模型监控——「什么是模型监控？」

为什么买了最好的工具，但MLOps还是做不好？因为MLOps不是「工具问题」，而是「人的问题」。

MLOps的「三大人的问题」

问题一：数据科学家「不愿意」用MLOps工具。 数据科学家的工作方式是「探索性」的——他们在Jupyter Notebook中「实验」，尝试不同的模型、不同的超参数、不同的特征。MLOps工具要求他们「规范化」——使用MLflow记录实验，使用Feast管理特征，使用Kubeflow编排管道。但「规范化」是「约束」，数据科学家「不喜欢」约束。他们习惯了「自由」的工作方式——「model_v1_final_final.pkl」虽然不规范，但「快」。

解决方案： MLOps工具需要「融入」数据科学家的「工作流」，而不是「强加」新的工作流。MLflow可以「自动」记录Jupyter Notebook中的实验——数据科学家不需要「额外操作」，MLflow就「自动」记录了。工具应该「不可见」——数据科学家「感觉不到」工具的存在，但工具「已经在工作」。

问题二：工程团队「不信任」数据科学家的模型。 数据科学家交付了一个「离线训练」的模型——AUC 0.95，看起来很完美。工程团队需要「部署」这个模型——但他们「不信任」这个模型。他们担心：这个模型在生产环境中「表现如何」？这个模型的「推理性能」如何？这个模型的「依赖」是否「安全」？工程团队和数据科学家之间的「信任鸿沟」是MLOps的「核心障碍」。

解决方案： 建立「模型交付」的「标准化流程」——数据科学家交付模型时，必须提供「模型卡片」（Model Card）：模型性能、推理延迟、依赖列表、安全审查、回滚计划。工程团队「信任」标准化流程，不信任「口头承诺」。

问题三：管理层「不愿意」投入MLOps。 MLOps需要「持续投入」——工具、基础设施、人力。但管理层「看不到」MLOps的「直接价值」——MLOps不是「新功能」，不是「新产品」，不是「新收入」。MLOps是「基础设施」——它的「价值」是「避免灾难」，而不是「创造价值」。管理层「不愿意」投入「避免灾难」——直到「灾难发生」。

解决方案： 用「灾难的成本」来「证明」MLOps的「价值」。一次模型部署故障导致推荐系统宕机6小时，直接损失50万——这个「灾难」可以让管理层「理解」MLOps的「价值」。MLOps的「ROI」是「灾难的避免」，而不是「收入的增长」。

金句：MLOps不是「工具问题」，而是「人的问题」。 工具可以买，但「数据科学家的工作习惯」「工程团队的信任」「管理层的投入」——这些「人的问题」比工具「难解决100倍」。2026年，MLOps的「成熟度」取决于「人的成熟度」，而不是「工具的成熟度」。

结语

2026年，MLOps的「工具」已经「成熟」了——MLflow、Feast、Kubeflow、Evidently……这些工具已经「足够好」。但MLOps的「人」还不够「成熟」——数据科学家、工程团队、管理层之间的「协作」还需要「进化」。

MLOps 2026的「核心挑战」是：让「数据科学家」「工程团队」「管理层」在MLOps的「价值」和「实践」上「对齐」。 工具是「手段」，人是「目的」。MLOps的「成功」取决于「人」，而不是「工具」。