当您向风险资本募筹投资时，它就是人工智能；而你在招聘时它就是ML；在实施时，它是线性回归；当您调试时，它是printf()。” — 史瓦兹男爵
2019年7月的一项研究发现，有 87％的数据科学项目没有投入生产。有许多原因；缺乏领导力的支持、孤立的数据源以及缺乏协作。除了这些问题之外，还有一些固有方面使数据科学和机器学习项目与其他软件开发有所不同。
首先，数据科学，尤其是机器学习，存在于概率和不确定性的世界中。基于机器学习的支付欺诈模型的典型输出如下：“此订单被欺诈的概率为73％+/- 5％，置信区间为95％”。 而我们在业务方面的同行同事却生活在确定性世界中，他们“希望阻止所有欺诈性订单”。在这两个世界之间进行转换并非易事。
此外，数据科学项目中存在一种非线性在“传统”软件开发中不会发生。在开始构建模型之前，我们不知道模型的性能如何。可能需要一周，三个月的时间，或者可能无法获得可接受的性能水平。这使得很难将一个好的项目计划与企业希望看到的时间表和可交付成果同步地放在一起。
最后，在将模型发布到生产环境时，模型信任的重要性很难被重视。传统软件与企业合作以实现模型进入生产时，我们正在进入一个业务领域，这里有业务领域专家，如果希望使手动流程自动化或替换一组精心设计的业务规则（尽管这些规则并不完美）很容易被信任地实现，因为这些流程和业务规则是由对业务有深刻理解的人建立的(banq注：由DDD构建的)。但是，当你交付一个类似黑盒子的机器学习算法软件时，需要说服企业，这些软件将取代他们目前的工作方式，这是一项多么艰巨的任务（因为你都没有理由说服他们，你对黑盒子的可解释性都可能不正确）。这个艰难尴尬过程是：让拥有模型的业务人员承担这种风险未知的切换带来的盈亏，而作为数据科学家，我们需要说服他们将他们赖以生存的生计交到我们的模型中，这是何等艰难！(banq注：难度：手工作业->半自动的电脑作业 ->完全自动的电脑作业)
根据我们的经验，可以通过以下因素成功实现广泛领域的生产模型化：
- 用例选择
- 业务调整
- 敏捷（数据科学）开发
用例选择
机器学习可以解决的问题很多。您在客户成功，供应链，分销，财务等方面拥有无数用例。
那么，您将如何决定选择哪种用例？
- 具有最大业务价值的一个？
- “低垂的果实”能带来快速的胜利？
- 符合公司战略目标的一个？
但关键的决定因素归结为一件事：
我们对机器学习是解决此问题的最佳方法的信心有多大？
我们要确保最有效地利用数据科学家的时间。假设存在一个可以产生巨大价值的引人注目的问题，但是一些精心设计的业务规则可以为我们带来80％的价值。让数据科学团队花费几个月的时间来尝试获得额外的10％，这是对资源的最佳利用吗？可能不会。
使用我们 的数据科学Zen 原则指导我们，我们可以将用例选择标准分解为以下几个部分：
- 我们是否有足够的干净，高质量的数据来对问题进行建模？
- 我们是否要优化一个明确的客观标准（或损失函数）？
- 企业是否准备好将此流程自动化？
- 它如何适应生产系统？该产品团队有实施该产品的带宽吗？
- 是否有成功的机器学习实现案例研究，研究论文或其他资源来解决此类问题？
- 我们需要解决任何偏见或道德问题吗？
如果对这些问题有任何疑问，我们将重新考虑这是否是我们团队可以选择的最佳项目。
无论您要投入什么资源解决问题，如果没有正确的用例，成功的机会就很少。
业务组合
确保与项目目标保持一致看起来既简单又显而易见。企业希望获得更准确的预测。您有信心可以击败现有系统。
假设您建立了一个出色的模型并设置了一项日常工作来执行它。好吧，事实证明，企业需要能够全天更新其预测。突然之间，您需要实时服务。
机器学习项目需要业务部门对系统如何工作有一定程度的了解。他们需要知道机器学习模型的固有优势和劣势，如何处理边缘情况以及使用了哪些功能。
最重要的是，您需要知道如何使用模型。什么是预期的输出？预测将如何使用？如果模型不运行会发生什么，是否需要回退机制？当您在开始开发之前就知道这些问题的答案时，它可以省去许多头痛，紧张的讨论和深夜的工作。
模型信任的问题再次出现。如果企业不信任您的模型输出会怎样？
您可以呈现所需的所有ROC曲线，F1分数和测试集性能，但是如果您的模型做出的前几个预测不正确，是否有机会进行恢复？以前制定的基本业务规则并不完善，但是企业知道在哪些情况下效果很好，什么时候效果不好，则可以相应地进行干预。您的模型（希望）会对运营产生影响，如果企业不信任它们，那么它们将不会被使用。就那么简单。
关于模型信任的讨论起来确实很不舒服，但必不可少。您需要预先了解业务才能在生产中使用您的模型。至少，需要由双方决定并签署带有绩效指标的评估期。
数据科学家和企业之间的期望差异导致许多数据科学项目的结束。 在花了几个月的时间进行开发之前，需要进行对话 。模型的寿命可能取决于它。
敏捷数据科学发展或...
敏捷开发已成为软件开发的事实上的标准，但尚未进入数据科学界（尚未）。
数据科学家会就此问题与企业会面，确定要优化的指标，并询问他们如何获得数据访问权限。然后，他们花了几个月的时间来建立美观，坚固的模型，并展示成品。
有效的方法是跳过概念验证（POC），而这种验证往往永远不会离开数据科学家的笔记本电脑，而专注于创建最小可行产品（MVP）。
对于MVP，目标是尽快建立一个端到端的解决方案。您建立数据管道，从基本基线模型（也称为线性回归或逻辑回归）开始，然后将预测提供给最终用户。我们可以使用机器学习找到最佳下降时间的真实示例 。
核心原则 ：
专注于工作软件
- 不要花时间微调可能永远不会使用的模型。将其用于建立可行的， 可行的
客户合作
- 大大缩短了上市时间，因此您的“客户”将看到来自更复杂系统的输出。您可以从那里进行迭代和改进。
应对变化
- 最好在第二周比第二季度找出有效的方法。也许您打算与之集成的内部构建系统无法公开所需的数据。灵活地适应需求，并尽早并经常发送工作代码。
数据科学项目的难点不是建模，通过关注MVP，您可以使工作系统投入生产，并更快地输出预测。您将更快发现问题，并在数周而不是数月内为您的客户提供崭新的闪亮模型。
最后，我们的目标不是为了建立模型而建立模型。我们正在构建一个组件为模型的产品。我们可以从数十年的产品开发中吸取教训，使我们到达那里。