数据工程比 DS数据科学 更受欢迎。不幸的是，ML（过度）工程是造成这种情况的一个原因。
以前可以使用 crontab 和 15 行 shell 自动化模型；而现在，你需要在你的 XGBoost 模型后面有一大堆 Airflow、Kafka、Snowflake、Spark、Stitch、Grafana、Presto、Amazon Athena、Redshift 等。
我见过的90%以上的ML模型甚至都不足以证明任何一种复杂的自动化。最愚蠢的模型是聚类模型，同样的老式k-means拟合了30次，与客户的业务知识相匹配。2年后，这些模型就完全没用了。
我觉得这个行业将ML工程过度复杂化。
我知道很多公司不愿意做广泛的智能A/B测试来获得可操作的见解，但DS模型 "需要 "大量的DE数据工程工作。
今天的大多数模型比3-5年前好1%，但它们 "需要 "更多的用心、工具、自动化、维护和监控等等。
回答
1. 这是因为公司不具备正确使用机器学习的成熟度，因为你需要基础设施到位。
这就是数据工程（部署前）和MLOps（部署后）的意义所在。
不过，过度复杂化也不是真的，你可以用Databricks或azure ML或AWS/GCP的任何其他工具从A-Z做整个工作流程。
其实，谁会在乎你的模型是否在笔记本上，最后出现在power point演示中？你必须部署它，这意味着你需要自动化你的数据管道，有某种模型的版本，监测数据/剩余物，......
2. 如果一个模型需要在生产中运行，它就必须进行源码控制、测试、审查、部署和监控。
在某些时候，所有这些都会从自动化中受益。我们从几十年的软件工程学习中了解到这一点，一个模型到头来不亚于一个软件（但可以说更多，例如，你的典型后端系统不会漂移，可能不需要非常专业的硬件等）。
因此，你可能会有一个合法的情况，一个小的shell脚本和一个cron job就是你所需要的全部，就像网站管理员只需要在某个文件夹上ftp一个.php。但是，随着团队和它所管理的模型数量的增加，这种情况很快就不复存在了。
问题就在于此。
数据科学刚刚起步，对MLOps的需求更是如此，所以我们还没有做某些事情的典型方法，也没有真正了解我们所拥有的解决方案的利弊（以及它们的实际质量与广告质量）。
任何以任何身份接触代码的人都偏向于过度工程化，夸大了他们对自动化的需求，低估了整合和维护工具的成本。
决策者，甚至是技术决策者，仍然会因为某种令人费解的原因而被同样的 "即插即用 "的销售口号所迷惑（还记得2000年代/2010年初的 "整个公司的自助分析，只要把我的东西插到你的数据库里，让企业拥有数据就好了 "的浪潮吗）？