不受欢迎的观点-数据科学家应该更加端到端

最近，我偶然看到Reddit上有一条关于数据科学和机器学习中不同角色的帖子，比如数据科学家、决策科学家、产品数据科学家、数据工程师、机器学习工程师、机器学习工具工程师、AI架构师等。

我觉得这令人担忧。当数据科学过程(问题框架、数据工程、ML、部署/维护)分散在不同的人之间时，很难有效。这会导致协调开销，分散责任，缺乏大局眼光。

IMHO，我相信数据科学家可以通过端到端的方式更有效率。在这里，我将讨论Stitch Fix和Netflix的好处和反驳，如何做到端到端，以及Stitch Fix和Netflix的经验。

我发现这些定义比我喜欢的更具规定性。相反，我有一个简单(和实用)的定义：端到端的数据科学家可以识别和解决数据问题，从而提供价值。为了实现这一目标，他们将根据需要戴上尽可能多(或尽可能少)的帽子。他们还将学习和应用任何可行的技术、方法和流程。在整个过程中，他们会问如下问题：

定义端到端数据科学的另一种方式是通过流程。这些过程通常很复杂，我把它们排除在主要讨论之外。不过，如果你很好奇，这里有几个：

如果这些过程看起来既繁重又不堪重负，请不要担心。你不必全盘采用它们--从一点一滴开始，保留有效的，然后调整其余的。

对于大多数数据科学角色来说，更多的端到端可以提高您产生有意义影响的能力。(尽管如此，还是有一些角色专注于机器学习。)。

端到端的工作提供了更多的环境。虽然专门的角色可以提高效率，但它减少了上下文(对于数据科学家来说)，并导致次优的解决方案。

忘记大局的诀窍是近距离观察每一件事。--查克·帕拉尼克(Chuck Palahniuk)。

如果没有上游问题的全面背景，就很难设计出整体解决方案。假设转换率降低了，一位PM提出了改进我们的搜索算法的请求。然而，首先是什么导致了下降呢？原因可能有多种：

通常情况下，问题和解决方案都在机器学习之外。改进算法的解决方案将遗漏根本原因。

同样，在没有意识到下游工程和产品约束的情况下开发解决方案也是有风险的。这是没有意义的：

如果不适合我们的产品和应用程序，则构建无限滚动推荐器。

通过端到端的工作，数据科学家将拥有识别正确问题和开发可用解决方案的完整背景。它还可以产生创新的想法，而专家们的背景狭窄，可能会错过这些想法。总体而言，它提高了交付价值的能力。

减少了通信和协调开销。多个角色会带来额外的开销。让我们看一个示例，其中数据工程师(DE)清理数据并创建特性，数据科学家(DS)分析数据并训练模型，而机器学习工程师(MLE)部署和维护数据。

一个程序员一个月能做的事，两个程序员两个月就能做。--弗雷德里克·P·布鲁克斯

DE和DS需要就哪些数据可用(和不可用)、如何清除数据(例如，异常值、归一化)以及应该创建哪些特征进行沟通。同样，DS和MLE必须讨论如何部署、监视和维护模型，以及应该多久刷新一次。当问题出现时，我们需要三个人(可能是PM)在房间里对根本原因进行分类，并采取下一步措施进行修复。

它还会带来额外的协调，在以顺序方式执行和传递工作时，需要调整计划。如果DS想要试验额外的数据和特性，我们需要等待DE接收数据并创建特性。如果新模型已经为A/B测试做好了准备，我们将需要等待MLE(将其转换为生产代码)并部署它。

虽然实际的开发工作可能需要几天的时间，但来回的沟通和协调可能需要数周时间，如果不是更长的话。有了端到端的数据科学家，我们可以最大限度地减少这一开销，并防止技术细节在转换过程中丢失。

(但是，端到端的DS真的能做到所有这些吗？我也这么想。虽然DS在某些任务上可能不如DE或MLE熟练，但他们将能够有效地执行大多数任务。如果他们在缩放或加固方面需要帮助，他们总是可以从DES和MLES专家那里获得帮助。)。

哈佛大学心理学家理查德·哈克曼(Richard Hackman)表示，一个团队中的关系数量是N(N-1)/2，其中N是人数。这导致链路呈指数级增长，其中：

在我们的简单示例中，我们只有三个角色(即六个链接)。但是，如果将PM、BA和其他成员包括在内，这将导致沟通和协调成本的线性增长。因此，虽然每增加一名成员都会提高团队的总生产力，但增加的管理费用意味着生产力的增长速度在下降。(亚马逊的两个披萨团队是解决这一问题的一个可能方案。)。

提高了迭代和学习率。有了更多的上下文和更少的开销，我们现在可以更快地迭代、失败(读取：学习)并交付价值。

这对于开发数据和算法产品尤其重要。与软件工程(一门成熟得多的手艺)不同，我们不能在开始构建之前完成所有的学习和设计-我们的蓝图、架构和设计模式还不够成熟。因此，快速迭代对于设计-构建-学习循环至关重要。

有了更大的所有权和责任感。将数据科学过程分散到多个人身上可能会导致责任分散，更糟糕的是，会导致社会懈怠。

观察到的一种常见的反模式是“翻墙”。例如，DE创建特性并将数据库表抛给DS，DS训练模型并将R代码抛给MLE，MLE将其转换为Java进行生产。

如果翻译过程中出了问题，或者结果出乎意料，该由谁负责呢？拥有强大的所有权文化，每个人都会站出来为各自的角色做出贡献。但如果没有它，当问题持续存在，客户和业务受到影响时，工作可能会退化为掩耳盗铃和相互指责。

让端到端的数据科学家承担整个流程的所有权和责任可以缓解这种情况。他们应该被授权从头到尾采取行动，从客户问题和输入(即原始数据)到输出(即部署的模型)和可测量的结果。

责任分散：当有其他人在场时，我们不太可能承担责任并采取行动。如果我们知道其他人也在关注情况，个人就会觉得没有那么大的责任和紧迫性去帮助他们。

其中一种形式是旁观者效应，基蒂·热诺维斯(Kitty Genovese)在她居住的街道对面的公寓楼外被刺伤。虽然有38名目击者目睹或听到了袭击，但没有人报警或帮助她。

社交游手好闲：与单独工作相比，我们在团队中工作时付出的努力更少。在19世纪90年代，林格尔曼让人们既可以单独拉绳子，也可以成群结队地拉绳子。他测量了他们拉绳子的力度，发现一组成员在拉绳子时往往比单独拉绳子的人付出的努力要少。

对于(一些)数据科学家来说，它可以增加动力和工作满意度，这与自主性、掌握和目标密切相关。

自主性：能够独立解决问题。端到端数据科学家能够识别和定义问题，构建自己的数据管道，并部署和验证解决方案，而不是等待和依赖他人。

掌握：在问题、解决方案、结果中端到端。他们还可以根据需要获取域名和技术。

目的：通过深入参与整个过程，他们与工作和结果有更直接的联系，从而增加使命感。

想要专攻机器学习，或者可能是机器学习的特定领域，比如神经文本生成(阅读：GPT-3Primer)。虽然端到端是有价值的，但我们也需要这样世界级的研究和行业专家，他们会突破极限。我们在ML拥有的大部分东西都来自学术界和纯粹的研究努力。

没有人通过成为多面手来成就伟大。你不会通过淡化对技能发展的关注来磨练一项技能。进入下一阶段的唯一方法就是专注。--约翰·C·麦克斯韦尔。

缺乏兴趣。并不是每个人都热衷于与客户和企业接触来定义问题、收集需求和编写设计文档。同样，并不是每个人都对软件工程、产品代码、单元测试和CI/CD管道感兴趣。

在大型、高杠杆系统上工作，其中0.01%的改进会产生巨大的影响。例如，算法交易和广告。在这种情况下，需要超专业化来勉强实现这些改进。

其他人也提出了为什么数据科学家应该专业化(而不是端到端)的论点。以下是几篇文章，以提供平衡和反驳：

如果您仍然热衷于变得更加端到端，我们现在将讨论如何做到这一点。在此之前，在不涉及具体技术的情况下，以下是端到端数据科学家通常使用的技能：

(此列表既不是强制性的，也不是详尽的。大多数项目并不需要所有这些组件。)。

学习合适的书籍和课程。(好的，这不是边做边学，但我们都需要从某个地方开始)。我会把重点放在涵盖隐性知识的课程上，而不是具体的工具上。虽然我还没有看过这样的材料，但我听说过关于Full Stack Deep Learning的好评。

端到端地做你自己的项目，以获得整个过程的第一手经验。冒着过于简单化的风险，以下是我将对它们的相关技能采取的一些步骤。

我听见了，但我忘了。我看到了，我记得。我知道，我也理解。--孔子。

从确定要解决的问题和确定成功指标(产品)开始。然后，找到一些原始数据(即不是Kaggle竞争数据)；这使您可以清理和准备数据并创建特性(数据工程)。接下来，尝试各种ML模型，检查学习曲线、错误分布和评估指标(数据科学)。

评估每个模型的性能(例如，查询延迟、内存占用)，然后选择一个模型，并围绕它编写一个基本的推论类用于生产(软件工程)。(您可能还想构建一个简单的用户界面)。然后，将其打包并在线部署，以供他人通过您首选的云提供商(Dev Ops)使用。

一旦完成，就多做一件事来分享你的工作。你可以为你的网站写一篇文章，或者在一次会议(交流)中谈论它。通过有意义的视觉效果和表格(数据分析)显示您在数据中发现的内容。在GitHub上分享您的工作。在公共场合学习和工作是获得反馈和寻找潜在合作者的一种很好的方式。

通过像DataKind这样的团体做志愿者。DataKind与社会组织(例如，非政府组织)和数据专业人员合作解决人道主义问题。通过与这些非政府组织合作，你有机会成为团队的一员，用真实(非常混乱)的数据来解决真正的问题。

虽然志愿者可能会被分配特定的角色(例如PM、DS)，但我们始终欢迎您加入并观察。您将看到(并学习)项目经理如何与非政府组织合作来框定问题、定义解决方案，并围绕问题组织团队。您将从其他志愿者那里学习如何使用数据来开发可行的解决方案。在类似黑客马拉松的DataDives和较长期的DataCorps中做志愿者是端到端为数据科学过程做出贡献的一种很好的方式。

加入一个类似创业公司的团队。注意：类似创业公司的团队并不等同于创业公司。有一些大组织以初创公司的方式运营团队(例如，两个披萨团队)，也有由专家组成的初创公司。找到一个精干的团队，在那里你会受到鼓励，并有机会进行端到端的工作。

Stitch Fix的埃里克·科尔森(Eric Colson)最初“被流程效率的吸引力引诱到了基于职能的分工”(即数据科学大头针工厂)。但经过反复试验，他发现端到端的数据科学家更有效。现在，Stitch Fix不是为了专业化和生产力而组织数据团队，而是为了学习和开发新的数据和算法产品而组织他们。

数据科学的目标不是执行。相反，目标是学习和开发新的业务能力。…。没有蓝图；这些是具有内在不确定性的新能力。…。您需要的所有元素都必须通过实验、试错和迭代来学习。--埃里克·科尔森。

他建议，数据科学的角色应该变得更加通用，具有广泛的职责，与技术功能无关，并针对学习进行优化。因此，他的团队雇佣并培养了能够概念化、建模、实现和测量的多面手。当然，这依赖于一个可靠的数据平台，该平台可以抽象化基础设施设置、分布式处理、监视、自动故障转移等的复杂性。

拥有端到端的数据科学家提高了Stitch Fix的学习和创新能力，使他们能够发现和构建更多的业务能力(相对于专家团队)。

Netflix Edge Engineering最初担任专门的角色。然而，这在整个产品生命周期中造成了效率低下。代码发布需要更多时间(几周而不是几天)，检测和解决部署问题需要更长时间，而生产问题需要多次来回交流。

为了解决这个问题，他们对被授权在整个软件生命周期中工作的全周期开发人员进行了试验。这需要转变思维方式--开发人员不仅要考虑设计和开发，还必须考虑部署和可靠性。

为了支持全周期开发，集中化团队构建了工具来自动化和简化公共开发流程(例如，构建和部署管道、监控、托管回滚)。这样的工具可以在多个团队中重用，充当力量倍增器，并帮助开发人员在整个周期内有效。

使用全周期开发人员方法，Edge Engineering能够更快地迭代(而不是跨团队协调)，实现更快、更例行化的部署。

在IBM，我所在的团队负责为员工创建工作推荐。运行整个管道花了很长时间。我认为我们可以通过将数据准备和功能工程管道移动到数据库中来将时间减半。但是，数据库专家没有时间对此进行测试。由于不耐烦，我运行了一些基准测试，并将总体运行时间减少了90%。这使我们的试验速度提高了10倍，并节省了生产中的计算成本。

在构建Lazada的排名系统时，我发现Spark对于数据管道是必要的(因为数据量很大)。然而，我们的集群只支持我不熟悉的Scala API。由于不想等待(数据工程支持)，我选择了一条更快但又痛苦的路线，即计算出Scala Spark并自己编写管道。这可能会将开发时间减半，并让我更好地理解数据以构建更好的模型。

在A/B测试成功后，我们发现业务利益相关者不信任该模型。因此，他们手动挑选要显示的顶级产品，从而降低在线指标(例如，CTR、转换率)。为了了解更多，我去了我们的市场(例如印度尼西亚、越南)。通过相互教育，我们能够解决他们的担忧，减少手动覆盖的数量，并收获收益。

在上面的例子中，走出常规的DS&；ML工作范围有助于更快地交付更多价值。在最后一个例子中，有必要解除我们在数据科学方面的努力。

你现在可能不是端到端的。没关系，很少有人是这样的。尽管如此，还是要考虑它的好处，并向它靠拢。

哪些方面会不成比例地提高您作为数据科学家的交付能力？增加与客户和利益相关者的接触，以设计更全面、更具创新性的解决方案？构建和编排您自己的数据管道？提高对工程和产品限制的认识，以实现更快的集成和部署？

挑一个，试一试。在你做得更好之后，试试其他的东西。请在下面的推文或评论中告诉我进展如何！

不受欢迎的观点：数据科学家应该更加端到端。虽然这是不受欢迎的(太多面手了！)，但我看到它带来了更多的背景，更快的迭代，更大的创新-更多的价值，更快。更多详细信息和缝合修复Netflix&；https://t.co/aOBjuBSsSz的👇体验。

-尤金·严(@eugene yan)2020年8月12日。

份额：

浏览相关标签：[]我写的是如何在数据科学、学习和职业中发挥作用。每周更新一次。

欢迎礼物：为期5天的电子邮件课程，介绍如何成为一名高效的数据科学家🚀