💻 computer science

Socio-Technical Anti-Patterns in Building ML-Enabled Software: Insights from Leaders on the Forefront

本文通过分析 66 小时的 MLOps 社区演讲，呈现了关于机器学习模型生产化过程中社会技术挑战的最大规模定性实证研究，旨在识别出 17 种根植于组织问题的反模式，并为克服这些问题提供具有操作性的建议。

原作者： Alina Mailach, Norbert Siegmund

发布于 2026-07-07

📖 1 分钟阅读☕ 轻松阅读

原作者： Alina Mailach, Norbert Siegmund

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一家试图制造一辆高科技自动驾驶汽车的公司。他们拥有能够设计引擎（机器学习模型）的顶尖工程师，但由于这辆车从未真正驶上公路，它只能停在车库里，落满灰尘。

这篇论文就像是一部侦探小说，调查了为什么这些“智能”汽车总是无法成功发布。作者 Alina Mailach 和 Norbert Siegmund 不仅仅观察了引擎部件（代码），他们还观察了人员、管理和办公室政治。他们听取了来自“MLOps 社区”（一个拥有超过 11,000 名专业人士的庞大群体）专家超过 66 小时的演讲，以查明究竟出了什么问题。

他们发现，问题通常不在于技术本身。相反，它是由一系列 17 个“反模式”（Anti-Patterns）——即坏习惯和组织错误——组成的，这些模式就像是通往成功之路上的坑洼。

以下是他们研究结果的简单拆解，使用了日常类比：

1. “两队之间的拔河”（组织孤岛）

想象一支厨师（数据科学家）团队正在创造一种美味的新汤配方（模型），以及一支服务员（软件工程师）团队，他们必须将汤端给顾客。

问题： 厨师用一种秘密代码、在餐巾纸上记录配方，没有任何计量单位。服务员听不懂这种语言。当厨师试图递出汤时，服务员说：“我没法端这碗汤；它太乱了！”厨师说：“这很完美；只是你们不懂而已！”
结果： 汤永远无法被端上桌。厨师被迫学习如何端盘子，而服务员则被迫从头开始重写配方。
解决办法： 他们需要一份菜单（模型注册表）将配方翻译成清晰的指令，或者他们需要把厨师和服务员放在同一个厨房里（跨职能团队），以便他们在工作时能进行沟通。

2. “囤积数据”（生产者 vs 消费者）

想象一个农民（数据生产者）正在种植玉米，以及一个需要这些玉米来做面包的面包师（数据消费者）。

问题： 农民想：“我为什么要给你我的玉米？帮你在烘焙方面提供帮助不是我的职责。”面包师不得不乞求玉米，而且有时农民在不告知的情况下更换了玉米品种。结果，面包师做出的面包味道很差，因为原料变了。
结果： 面包师做出了难吃的面包，而农民并不知道为什么他们的玉米被浪费了。
解决办法： 他们需要一个社区市场（中央数据平台），在那里农民列出带有清晰标签的玉米，且面包师确切知道自己会得到什么。

3. “重复造轮子”（冗余开发）

想象一家公司，A 队建造了一把梯子，而三层楼下的 B 队为了同样的目的建造了另一把不同的梯子。

问题： 没有人知道另一支队伍已经造了一把梯子。因此，每个人都在浪费时间和金精力气去建造已经存在的梯子。更糟的是，如果 A 队修好了他们梯子的一个横档，B 队的梯子依然是坏的。
结果： 混乱、浪费资金，以及“影子 IT”（团队构建自己的秘密、不安全的工具）。
解决办法： 一个中央工具库，让所有人都能看到有哪些梯子存在，并可以借用它们而不是重新建造。

4. “盲目的老板”（领导力真空）

想象一位并不懂航海的船长（管理层），正试图为一次新的航行招聘船员。

问题： 船长看到了“数据科学家”这个职位名称，于是雇佣了 10 个人，认为这能解决一切问题。但他雇佣的人擅长数学却不会修理引擎。或者，他雇佣某人去做特定的工作，然后船长忘记了那项工作是什么，导致员工无事可做。
结果： 船上挤满了不会航行的人，而船长对船为什么不动而感到困惑。
解决办法： 船长需要学习航海的基础知识（教育），并根据技能（你会修引擎吗？）而非仅仅根据花哨的职位名称来招聘。

5. “简历竞赛”与“炒作热潮”

简历驱动开发： 想象一位建筑师坚持使用金钉子，仅仅因为它们看起来很酷，即便房子需要的是钢钉。房子在瞬间看起来很华丽，但因为它不适合这项工作，最终会崩塌。
炒作驱动创造： 想象一位餐厅老板决定供应龙肉，仅仅因为大家都在谈论它，尽管他并没有龙，而顾客其实只想吃汉堡。他们把所有的钱都花在了寻找龙上面，最后才发现他们本该做更好的汉堡。
结果： 项目陷入“概念验证地狱”——无止尽的实验，却从未变成真正的产品。

核心启示

作者发现，技术很少是真正的反派。真正的反派是：

孤岛： 彼此互不沟通的团队。
混乱： 不理解工作的管理者，以及不理解业务目标的员工。
错误的招聘： 出于错误的原因雇佣了错误的人。

解决方案是什么？ 这不仅仅是购买更好的软件。这关乎更好的组织。公司需要：

打破团队之间的围墙。
教导管理者什么是机器学习。
根据实际技能而非职位名称来招聘人才。
在开始构建之前，确保每个人都对“为什么要构建某物”达成共识。

简而言之：你可以拥有世界上最好的引擎，但如果驾驶员不知道如何转向，而乘客们正在为地图争吵不休，那么这辆车哪儿也去不了。