译者 | 崔皓
审校 | 孙淑娟
开篇
一般而言，企业不会主动构建自有的云计算基础设施是有原因的。过去十年，IT 基础架构团队试图构建自己的私有云，因为他们认为与公共云相比，私有云会以性价比更高的方式支撑他们的业务。但事与愿违，最终花费在私有云上的的时间和成本都超过了预期，建成私有云以后反而需要更多的资源来对其进行维护，并且在安全和扩展方面都比公共云略逊一筹。这导致那些自建私有云的企业最终没有更多的资源投资于核心业务，而是将大量的时间和人员投入到无法扩展业务需求的基础设施上。
现在，许多企业通过各种开源工具（如 Apache Spark）生成解决方案，但对于 MLOps 的大多数行为都需要进行重复地手动操作。
这会导致模型部署需要数周甚至数月的时间、低效的运行时间（通过计算和所需时间运行的推理来衡量），同时还缺乏对模型测试和监控的观察。并且，所用方法过于定制化，无法为企业的不同部门的多个用例提供可扩展、可复用的业务流程。
误诊问题的案例
此外，通过与业务线负责人、首席数据分析官的对话得出这样的结论，虽然组织雇用了很多的数据科学家，但并没有看到任何回报。随着研究的深入，他们会不断提出各种问题，通过这些问题去识别人工智能面临的困难和障碍。他们很快意识到关键问题在“最后一英里”——部署模型并应用于实时数据，有效地执行它们，这样一来才能使收益大于成本，从而更好地衡量其性能。
为了解决业务问题和制定业务决策，数据科学家将数据转化为模型。这一过程需要两类技能的支持，其一是，构建出色模型所需的专业知识和技能；其二是，使用代码在现实世界中推动模型，同时监控和更新模型的技能。然而这两类技能却完全不同。
正因为这种差异就有了ML 工程师的用武之地。ML 工程师负责将工具和框架进行集成，以确保数据、管道和基础设施协同工作，在此前提下大规模生产 ML 模型。
那么，现在怎么办？雇用更多的机器学习工程师？
即使拥有最好的 ML 工程师，企业在扩展 AI 时仍面临两个主要问题：
- 无法快速雇用 ML 工程师：对 ML 工程师的需求变得非常强烈，ML 工程师的职位空缺增长速度比 IT 服务增长的速度快了 30 倍。有时需要等待数月甚至数年来填补岗位空缺，由此MLOps 团队需要找到一种高效的方式支持更多的 ML 模型和用例，而无需通过增加 ML 工程师的人数来满足对ML应用的需求。但这一措施又会带来了第二个瓶颈……
- 无论在何处以及如何构建模型，都缺乏部署模型的可重复、可扩展的最佳实践：现代企业数据生态系统的现状是，不同的业务部门根据数据和技术的要求会使用不同的数据平台（例如，产品团队可能需要支持流数据，而财务需要为非技术用户提供简单的查询界面）。此外，数据科学还需要将应用分散到各个业务部门而不是集中应用。换句话说，不同的数据科学团队中针对他们关注的用例（领域）都有一套特有的模型训练框架，这意味着一刀切的训练框架针对整个企业（包含多个部门/领域）而言是无法成立的。
如何从人工智能中获得最大价值
为了提高自动化能力；为了提供大规模的用户个性化体验；为了兑现更准确、更精细、可预测的用户承诺，企业已经向人工智能投入了数十亿美元。但到目前为止，人工智能的承诺和结果之间存在巨大差距，只有大约 10%的人工智能投资产生了可观的投资回报率。
最后，为了解决 MLOps 问题，首席数据分析官需要围绕业务核心的数据科学构建自己的能力，同时也要投资其他的与 MLOps自动化相关的技术。这是常见的“构建与购买”困境，不仅从运营的角度（成本收益）去考量，更多地需要考虑人工智能投资在整个企业中渗透的速度和效率，以及是否通过更好的方式产生新的收入产品和客户群，或通过提高自动化程度和减少浪费来削减成本。
译者介绍
崔皓，51CTO社区编辑，资深架构师，拥有18年的软件开发和架构经验，10年分布式架构经验。曾任惠普技术专家。乐于分享，撰写了很多热门技术文章，阅读量超过60万。《分布式架构原理与实践》作者。
原文标题：MLOps | Is the Enterprise Repeating the Same DIY Mistakes?
