数据科学项目的最后一步可以说也是最难的，即将有望实现其目的的原型作为概念验证（PoC）并最终部署它。部署数据产品意味着通过将数据科学项目的输出（例如机器学习算法或可视化仪表板）集成到相应的业务流程中，使其可供用户使用。这说起来容易做起来难。以下是一些技巧，希望可以帮助克服数据产品部署的障碍：

1. 配备数据工程师

数据科学工作被称为最受欢迎的工作。虽然数据和机器学习工程师对于数据科学项目的成功不可或缺，但他们的作用至少同样重要。数据科学家通常参与开发和原型设计阶段，以探索数据、进行实验、从中设计特征，最后开发机器学习和统计模型。然而，许多数据科学项目的真正瓶颈是部署——数据和机器学习工程师的工作。

(资料图片)

当部署原型（例如机器学习模型）时，“数据科学项目”就变成了“软件开发”项目。这是两件截然不同的事情。要了解其中的原因，请考虑新车的开发。在研发阶段，对汽车的许多调整都可以手动定制，例如以特定方式塑造车身以确保最佳的空气动力学特性。目标是测试和创建给定原型的最佳功能。然而，如果这样的原型车要投入批量生产，目标就会改变为生产尽可能多的廉价且高质量的汽车。为了确保廉价和高质量的生产，原型的某些功能可能必须妥协。这是一个全新的挑战，与研发阶段非常不同。不能将汽车交给生产主管并期望立即生产数千辆。数据科学项目也是如此。

在开发过程中，很多事情（例如纠正数据中的错误）可以由数据科学家手动完成。但如果最终的数据产品要投入生产，这本身通常是一个新项目，也是一个全新的挑战。

数据产品需要经过测试和设计，能够容错并满足性能要求。这需要时间和具有适当技能的工程师，最好具有软件开发和数据科学/机器学习知识的背景。因此，对于每个数据科学项目，肯定需要一名工程师。我们建议在组建数据科学团队时，目标应该是拥有更多的工程师和数据科学家。

2. 在业务部门、数据科学部门和IT运营部门的合作三角中运营数据项目

在孤立组织的公司中，数据科学团队通常很少或根本不与其他部门合作，特别是 IT 和业务部门。在数据科学项目的实施过程中，数据科学/工程-业务部门-IT 三角团队的合作对于促进最终产品的成功部署至关重要。业务部门，即数据产品的用户，应该定期沟通他们的需求，而数据科学团队和IT部门应该评估技术可行性，并尝试找到解决方案来解决需求和可行性之间的不匹配。这会阻止实施满足要求但从技术角度来看不可部署的项目，反之亦然。

例如，在生产机器的预测维护用例中，业务部门需要定义他们希望如何使用数据产品。应该提前多长时间预测故障？准确度需要达到多高才能获得有利的业务案例？这些要求必须由数据科学团队翻译并由 IT 部门评估：传感器数据的粒度是多少——毫秒、秒、分钟？是预先汇总的吗？这个频率是否足够高，足以提前这么长时间做出预测？实现该用例需要什么计算能力和工具（例如，是否有可以应对计算负载的分布式系统）？部署的目标环境是什么？它是否具有必要的工具？等等。

这些利益相关者的合作确保数据科学用例的设置不会因需求和可行性之间的不匹配而阻碍其部署。

3. 注意技术和组织债务的成本

技术债务的概念在软件开发中是众所周知的。它指的是人们选择一种在短期内易于实施的解决方案，但从长远来看不是最优的并且会付出代价的解决方案（即“快速而肮脏的解决方案”）。从长远来看，这些有害影响会随着债务的增加而增加，例如代码运行速度可能会变慢，或者维护和改进会更加困难。

数据科学项目也存在这种技术债务。像“现在让我们对数据转换进行硬编码，因为我们明天需要显示一些结果”之类的情况对于数据科学家来说肯定听起来很熟悉。他们还将知道，随着项目的继续，而不是重构（即清理），从长远来看，此类技术债务可能会带来高昂的成本。

就像经济理论中的“债务”不一定是坏事，但在数据科学项目中需要仔细考虑成本和收益。除了技术之外，还要考虑组织债务：

3.1 什么是技术债务

如上所述，这主要与开发人员和数据科学家相关：在编写代码时，总是倾向于寻求快速而肮脏的解决方案，特别是考虑到时间压力。但在部署数据科学项目时，此类解决方案会适得其反，因为它们可能会妨碍代码的可读性、可维护性和性能。数据环境中的技术债务示例包括：

●使用在开发中使用方便但性能不佳或难以部署的工具（例如，R 用于性能敏感的应用程序）

●硬编码和手动计算，而不是编写专为稳定性而设计的代码并针对极端情况进行测试（即开发测试）

●没有在代码文档上花费足够的时间

这些问题在软件工程学科中是众所周知的。然而，由于许多数据科学家来自计算机科学以外的背景，其中一些数据科学家不得不再次经历艰难的过程。

3.2 什么是组织债务

技术债务的基本机制适用于我们的组织层面，尤其与管理者和决策者相关。示例包括：

●创新实验室和核心 IT 之间不兼容的技术工具堆栈是决策者承担了将实验室建设为脱离企业 IT 游轮的“快艇”的组织债务的结果。

●在项目层面上，在 PoC 中，工具不兼容、缺乏定期数据访问、数据质量缺陷或其他可能的失败原因之一被广泛忽视，应被视为组织债务

产生这样的债务并不一定是坏事——它可能是有用的，甚至是必要的，例如，如果需要非常快速地交付 PoC。但如果发生了此类债务，人们需要意识到不断增加的成本，确保其值得带来的好处，并应该有一个偿还计划。

4. 在设计或更新数据生成流程时咨询数据科学家

大多数公司已经拥有大量数据，并且这样做已经很长时间了。然而，传统上收集的数据通常并不意味着用来创造价值。相反，它被保存用于报告或监管目的。因此，对于某些数据科学用例，许多组织只是没有所需的数据（质量）。不幸的是，有时可以在 PoC 环境中克服这个问题，很可能使用不适合在生产中应用的手动方法。尽管如此，对于战略用例公司可能希望在其数据基础上开展工作以实现这一目标。如果是这样，或者如果数据生成过程因其他目的而被重新设计，请记住在设计这些过程时咨询数据科学家和工程师！

例如，如果汽车、机器、物联网设备、电梯等中包含新传感器，以便收集用于记录目的的数据，精通数据的同事可能会对数据应该是什么样子有一个或两个想法（频率、测量等）以促进预测性维护用例。数据科学家的这些要求也将对业务案例产生影响。例如，如果需要为与数据科学无关的一个目的收集数据，但可用于三个数据科学用例，那么增加测量频率可能是可行的。

5. 像投资任何其他有价值的能力一样投资数据治理

每个曾经处理过数据的人都会知道，通常最大的障碍是数据质量（例如，大量 N/A 字段、难以置信的值等）和可用性（例如，从其他部门获取数据、很少观察、变量等）。部分原因是，当公司的数据生成流程到位时，它们并不是为了收集数据来实施数据科学用例而设计的。然而，更重要的是，这是由于缺乏或糟糕的数据治理，即主动管理数据以确保公司的可用性、可用性、质量和安全性。作为关键的推动者，而不是一个闪亮的流行词，数据治理所受到的关注和资金比探索“人工智能算法”要少得多——这是不幸的。

虽然在用例的原型设计阶段，由于缺乏数据治理而带来的一些问题仍然可以得到缓解，但这些问题通常在部署阶段变得非常紧迫，以至于危及用例进入生产。例如，在开发阶段，数据中的质量问题通常可以手动纠正（例如 N/A 值的插补），但自动化此类解决方案通常要困难得多，因为需要考虑所有意外情况。或者，一种数据产品可能在一个市场中完美运行，但由于缺乏必要的数据而无法推广到其他市场。

因此，糟糕的数据治理会导致数据科学用例的整个生命周期出现问题。

由于数据质量不佳，许多试点在开发阶段就会失败。但糟糕的数据治理带来的后果在部署阶段更为严重。

6.检查项目并将其嵌入总体数据策略中

暂时抛开所有复杂的技术和部署过程的细节：数据驱动型组织的基本资产是从数据中创造价值的清晰愿景和战略。其核心表现之一是领导者如何获取正确的数据以实现其战略目标。

谷歌通过街景程序收集世界上每条街道图像的努力就是一个生动的例子。街景作为该公司开发自动驾驶汽车的早期步骤的衍生产品而诞生。该公司很早就意识到，这种对数据收集的投资所带来的好处远远超出了为地图用户提供更好的定位。在 Google 创始人拉里·佩奇 (Larry Page) 和谢尔盖·布林 (Sergey Brin) 领导的一项倡议中，街景成为 GoogleX 部门内的第一个项目，该部门负责托管该组织的“登月项目”。与此同时，街景图像不仅被用来在自动驾驶汽车方面取得比任何竞争对手更快的进展，而且也大大改善了地图。

所有行业都存在相同的基本机制：为了从先进的数据科学和人工智能用例中受益，有必要对数据获取进行战略投资。例如，Vorwerk 将建立一个实时数据管道作为首要任务，该管道收集和聚合全球超过 150 万台相连的 Thermomix 设备产生的数据。此外，他们还投资了最先进的本地和云端基础设施。现在，他们可以通过各种高级用例来利用这些投资。

不幸的是，反之亦然：许多数据科学项目失败是因为可用数据使它们不可能实现。再加上频繁报道对人工智能潜力的高期望，这是通往失望的捷径。我们当然相信数据创造价值的潜力。与此同时，我们一次又一次地看到数字化必须先于数据科学。当数据基础还不存在时，尝试实现高级用例是没有意义的。相反，评估每个功能的数据准备情况并制定总体数据策略。首先关注容易实现的目标，然后将用例实施的倾向反馈回来以引导战略重点。通过同时为更高级的用例奠定基础并执行您的组织已准备好的用例来创建反馈循环。这样，您将能够保持高昂的士气，并逐步致力于每个人都在谈论的未来人工智能用例。

小结

我们研究了目前许多数据科学项目在部署阶段失败的原因。我们将部署定义为将数据科学 PoC 或试点结果转变为可操作的数据产品并集成到业务流程中的阶段。我们研究了数据科学用例的不同形式的技术部署，并确定了五个关键挑战：(1) 数据可访问性和/或质量不足以促进可持续价值创造。(2) 数据隐私和安全问题阻碍了扩展。(3) 没有足够的数据和机器学习工程师来帮助部署数据科学家的成果。(4) 在许多公司中，业务、数据科学和IT部门之间存在很大的组织鸿沟。(5) 技术格局正在快速发展，企业 IT 尚未准备好运行创新和数据实验室中使用的技术。

我们进一步分享了克服这些挑战的最佳实践，并使数据科学项目更接近创造真正的价值：（1）拥有数据工程师。(2)在跨学科团队中工作。(3)仔细权衡技术和组织债务的成本和收益。(4) 让数据科学家参与数据生成过程的设计。（5）实施良好的数据治理。(6) 确保项目有助于更大的数据战略，并尽早为高级用例奠定基础。