如何开始一个数据科学项目？

AI 前线导读：

数据科学对初创公司有多重要？在初创公司中，数据科学项目流程有什么说道吗？作为在数据科学领域身经百战的老将 Shay Palachy，日前接受了一家名为 BigPanda 的初创公司的邀请，让他就该公司的数据科学项目发表自己的看法。作者在这篇文章中为那些想打造一直属于自己的数据科学团队的创始人提供了一些非常有价值的建议。

更多优质内容请关注微信公众号“AI 前线”（ID：ai-front）

最近，一家名为 BigPanda 的初创公司邀请我对数据科学项目的结构和流程发表自己的看法，这让我思考是什么让它们独一无二。初创公司的经理和不同团队可能会发现，数据科学项目和软件开发之间存在差异，这种差异并不那么直观，而且令人困惑。如果没有明确的说明和解释，这些根本差异可能会引起数据科学家和同事之间的误解和冲突。

分别来说，来自学术界（或高度研究型的行业研究小组）的研究人员在进入初创公司或小型公司时，可能会面临各自的挑战。他们可能会发现，将新类型的输入（如产品和业务需求、更紧密的基础设施和计算限制以及客户反馈）纳入他们的研究和开发过程中具有挑战性。

因此，本文写作目的就是介绍我和同事在近年来的工作中所发现的具有特色的项目流程。希望本文能够帮助数据科学家与他们一起工作的人，以反映他们独特性的方式来构建数据科学项目。

这个流程是基于小型初创公司的想法建立起来的：一个由数据科学家（通常是一到四个人）组成的小团队，一次只负责一个人领导的中小型项目。规模更大的团队或那些以机器学习为先的高科技初创公司的团队，可能会仍然认为这是一个有用的结构，但在许多情况下，流程会更长，结构也会有所不同。

图1：初创公司的数据科学项目流程

我将流程分为三个并行运行的方面：产品、数据科学和数据工程。在许多情况下（包括我工作过的大多数地方），可能并没有数据工程师来执行这些职责。在这种情况下，数据科学家通常负责与开发人员合作，帮助他解决这些方面的问题（如果他是全能大神：全栈数据科学家，那么他自己就可以凭一己之力解决所有的问题✨????✨）。因此，根据你的环境，每当提到数据工程师时，你都可以用数据科学家来取代之。

在时间轴上，我将这个流程分为四个不同的阶段：

1. 范围界定

2. 研究

3. （模型）开发

4. 部署

我试着按顺序把每一个阶段都讲一遍。

1. 范围界定阶段

定义数据科学项目的范围比任何其他类型的项目都重要。

1.1. 产品需求

项目应始终从产品需求开始（即使最初想法是技术或理论上的），需要在某种程度上通过产品 / 业务 / 客户成功人士进行验证。产品人员应该知晓这个特征大致最终应该是什么样子的，并且现有或新客户愿意为此付费（或者防止客户流失 / 推动订阅 / 推动其他产品的销售 / 等等）。

产品需求并非完整的项目定义，而应该作为一个问题或挑战。例如：“我们的客户需要一种方法来了解如何使用他们的预算”或 “我们没有设法让老年客户继续服药，这就增加了客户的流失率” 或“客户会为一种能够预测他们运营的机场高峰时段的产品支付更多的费用”。

1.2. 初步解决方案构想

这就是数据科学家与产品负责人、数据工程师和任何其他涉众一起，为可能的解决方案提出不同的草图的地方。这意味着通用方法 (例如，无监督聚类 vs 基于提升树的分类 vs 概率推理）和要使用的数据（如，我们数据库中的特定表，或者我们尚未监控或保存的某些特定用户行为，或外部数据源）。

这通常还涉及一定程度的数据探索。在这里你无法做到真正深入的研究，但是任何有前途的 “唾手可得的成果” 都可以帮助指导你的想法。

数据科学家应该领导这一过程，通常负责提供大多数解决方案的想法，但是，我会建议你使用所有参与构思解决方案过程的所有人。我有幸从后端开发人员、CTO 或产品负责人那儿得到了一个项目的最佳解决方案。不要认为不同的、不太注重理论的背景会使人们无法参与这一阶段，须知额外的想法和观点总是有价值的。

1.3. 数据准备和可访问性

团队现在应该对希望用于探索可能的解决方案（或至少是第一个这样的数据集或数据源）的数据有一个很好的了解。因此，在进行下一阶段的同时，应该已经开始提供数据访问并为探索和使用做好准备的过程。

如果在研究阶段中，时间可用性不是很关键的话，那么这有时可能需要将大型数据及从生产数据库转储到临时 / 探索的对应方，或者转储到较冷的存储（如对象存储）中。相反，它可能意味着将大型数据转储从非常冷的存储拉回到表或文档形式，以实现快速查询和复杂的计算。无论如何，这一阶段都需要在研究阶段开始，并且经常会耗费比预期更多的时间，因此，这是启动研究阶段的最佳时机。

1.4. 范围与 KPI

这一阶段是关于共同决定项目的范围和 KPI（Key Performance Indicators，关键绩效指标）。

KPI 应当首先从产品的角度来定义，但要比之前更详细；例如，就上述三种产品需求而言，它们可能会变成 “客户现在可以使用带有 CTR 统计数据和每个类别图像的仪表板”，或 “在未来两个季度内，65 岁以上的用户错过的服药天数至少减少 10%”，或 “客户都会收到每周的机场高峰时间的预测，预测的力度至少为一个小时，近似值至少为 ±50%”。

这些 KPI 应该转换为可衡量的模型指标。运气好的话，这些将是非常困难的指标，如 “预测广告的预期 CTR（点击率），在至少 Y% 的情况下，对于任何运行至少一周的广告，以及对于任何拥有两个月历史数据的客户来说，CTR 至少为 x%”。然而，在某些情况下，必须使用更柔和的指标，如 “与原始查询相比，使用生成的扩展查询进行主题探索所需的时间将缩短，和或与或结果的质量将得到改善”。当模型用于辅助某些复杂的人类功能时，这点尤为正确。

从技术上讲，即使这些指标也可以非常严格地定义（在学术研究中通常亦如此），但是根据资源和时间的限制，我们可能会通过人工反馈来近似地对它们进行定义。在这种情况下，每次反馈迭代可能需要花费更长的时间，因此，我们通常会试图寻找额外的硬指标来指导我们完成大部分即将进行的研究迭代，每隔几次迭代或者发生重大变化才会得到一次成本更高的反馈。

最后需要强调的是，范围在这里特别重要，因为研究项目有一种拖延的趋势，当研究过程中出现新的可能性时，或者当检查的方法仅部分满足需求时，研究项目的规模和范围会自然地扩大。

范围限制 1：我发现，明确限制范围会更为有效；例如，如果你认为基于 Multi-Armed Bandit 的模型是最有前途的方法，那么你可以从它开始，你可以将项目范围定义为模型开发的单个两 / 三周迭代，无论准确性如何都进行部署模型（如，只要它超过 60%）。然后，如果准确性方面的改进有价值（在某些情况下，结果可能不那么重要），那么开发第二个模型可能被认为是一个独立的项目。

范围限制 2：范围限制的另一个变体是使用越来越复杂的复杂性；例如，第一个项目的目标可能就是部署一个模型，这个模型只需为你自己的客户成功人士提供相当多的候选广告措辞和颜色变化，第二种方法可能会尝试构建一个模型，提供一组更少的建议，让客户能够看到自己；最终的项目可能会尝试突出显示单个选项的模型，低于它的数量，并为每个变化增加 CTR 预测和人口覆盖范围。

这已经与软件工程有了很大的不同，在软件工程中，组件通常是为了增加规模而不是增加复杂性而迭代的。

然而，metric-to-product-value 函数可能是一个阶跃函数，这意味着在某个 X 值下执行的任何模型对客户都没有用处；在这些情况下，我们宁愿选择迭代，直到该阈值被抑制。然而，虽然这个 X 在某些情况下可能非常高，但我认为产品 / 业务人员和数据科学家都倾向于高估这一步骤的高度；很容易说明，准确率低于 95%（例如）的任何东西都没有价值，不能出售。然而。在许多情况下，对产品假设的仔细检查和挑战可能会产生非常有价值的产品，这些产品在技术上可能没有那么苛刻的要求（至少在产品的第一次迭代中是这样）。

1.5. 范围和 KPI 的批准

最后，产品负责人需要批准范围并定义 KPI。数据科学家的工作就是确保每个人都了解范围的含义：包含哪些内容以及优先级，产品 KPI 和模型开发过程中指导他的更难指标之间的关系，包括字母接近前者的程度。明确地说明这一点可以防止出现模型的消费者（产品和业务人员）在模型开发期间或者之后才知道优化了错误的指标的局面。

关于范围的总论

这个阶段在很多地方都被忽略了，数据科学家急切地开始挖掘数据并探索关于可能解决方案的论文；然而根据我的经验，这几乎总是最槽糕的。跳过这一阶段可能会导致花费数周或数月的时间来开发很酷的模型，而这些模型最终无法满足实际需求；或者在一个非常特定的 KPI 中失败，而这个 KPI 本可以通过某些预先设想来明确定义。

2. 研究阶段

2.1. 数据探索

这就是乐趣的开始！在确定范围之后开始这一阶段的主要优势是，我们的探索现在可以由我们决定的实际硬 KPI 和模型指标来指导。

像往常一样，在探索和开发之间要取得平衡；即时有明确的 KPI，在某种程度上探索一些看似无关的途径也是有价值的。

到目前为止，数据工程应该可以得到所需的初始数据集。但是，在这一阶段中，经常会发现探索数据中的一些缺陷，并且可能会将其他数据源添加到工作集中。数据工程师应为此做好准备。

最后，虽然此处与文献和解决方案评审阶段分开，但它们通常是并行完成的，或者是交替进行。

2.2. 文献与解决方案评审

在这一阶段中，将回顾学术文献以及现有的代码和工具。平衡也很重要；在探索和开发之间，在深入研究错综复杂的材料之间，在快速提取有用信息和可能的用途之间。

就学术文献而言，选择在形式化证明和之前的文献等方面有多深入，在很大程度上取决于时间限制和项目背景：我们是在为公司的核心能力打下坚实的基础，还是在为一次性问题设计解决方案？我们打算在学术论文中发表关于这一主题的研究成果吗？你打算成为这个主题的团队专家吗？

例如，假设一个数据科学家着手一个项目，帮助销售部门更好地预测潜在产量或客户流失率，他觉得自己对随机过程理论的理解很肤浅，而这些问题的许多常见解决方案都是监理在这个理论的基础之上。对这种感觉的适当反应可能非常不同；如果他在一家算法交易公司工作，那么他肯定会深入研究这一理论，甚至可能会参加一门关于这个主题的在线课程，因为这与他的工作非常相关；另一方面，如果他在一家医学影像公司工作，该公司专注于肝脏 X 射线扫描中肿瘤自动检测，我认为他应该会尽快找到一个可行的解决方案，然后继续前进。

在代码和实现的情况下，要达到的理解深度取决于技术方面，其中一些可能在过程的后期才会被发现，但是，其中也有许多是可以提前预测的。

例如，如果生产环境仅支持为后端使用部署 Java 和 Scala 代码，那么解决方案预计会以 JVM 语言提供，即使在这个研究阶段，数据科学家也必须深入研究基于 Python 的实现，因为随着它们进入模型的开发阶段，需要将它们转换为 JVM 语言。

最后，在回顾文献时，请记住，不仅要向团队的其他成员展示选定的研究方向（或几个方向）。相反，应在作出选择的同时，对该领域和所有经过审查的解决办法作一次简短的审查，解释每一个方向的优点和缺点以及选择的理由。

2.3. 技术有效性检查

对于可能的解决方案，数据工程师和任何相关的开发人员都需要在数据科学家的帮助下，评估该解决方案在生产中的形式和复杂性。产品需求以及建议解决方案的结构和特征都应有助于确定适当的数据存储、处理（流 vs 批处理）、扩展能力（水平和垂直）以及成本的粗略估计。

这是在这一阶段执行的一个重要检查，因为一些数据和软件工程可以与模型开发的同时开始。此外，从工程角度来看，建议的解决方案可能存在不足或者成本太高，在这种情况下，应尽快确定并处理。在模型开发开始之前考虑技术问题时，在研究阶段获得的只是可以用来建议更适合技术约束的替代解决方案。这也是为什么在研究阶段还必须对解决方案前景进行一些概述，而不仅仅是在单个解决方案方向的另一个原因。

2.4. 范围和 KPI 的验证

同样，产品经理需要批准建议的解决方案，现在用更技术性的术语来表述，符合范围和定义的 KPI。通常具有容易检测到的产品含义的可能技术标准是相应时间（及其与计算时间的关系）、数据的新鲜度以及有时缓存的中间计算（与查询和批处理计算频率相关）、针对特定领域模型（域通常是客户，但也可以是行业、语言、国家等）和解决方案可组合型（如，数据和模型结构是否允许容易地将国别模型分解成区域模型，或者将几个这样的模型组合成大陆模型）的难度和成本，尽管还存在很多其他模型。

3. 开发阶段

3.1. 模型开发和实验框架的建立

开始模型开发所需设置的数量和复杂性，在很大程度上取决于数据科学家可用的基础设置和技术支持的数量。在较小的地方，以及尚未用于支持数据科学研究项目的地方，设置可能会为数据科学家打开一个新的代码存储库并启动本地 Jupyter Notebook 服务器，或者请求更强大的云机器来运行计算。

在其他情况下，可能需要为更复杂的功能编写定制代码（如数据和模型版本控制或实验跟踪和管理）。当这个功能被一些外部产品或服务替代时（现在这类产品或服务越来越多了），可能会出现以链接数据源、分配资源和设置自定义软件包的形式进行的一些设置。

3.2. 模型开发

有了所需的基础设施，实际的模型开发就可以真正开始了。这里所要开发的模型的范围因公司而异，取决于数据科学家要交付的模型与要部署在生产中的服务或特征之间的关系和差异。在某种程度上发现差异的各种方法，可以通过考虑范围来获得。

在这个范围的一端是一切都是模型的情况：从数据聚合和预处理，到模型训练（可能是周期性的），模型部署，服务（可能具备扩展性）和持续监控。另一方面，只考虑模型类型和超参数的选择，通常也考虑高级数据预处理和特征生成，才能被认为是模型。

公司在这一范围上的位置取决于很多因素：数据科学家的首选研究语言；相关库和开源可用性，支持公司的生产语言；有专门负责数据科学相关代码的数据工程师和开发人员；以及数据科学家的技术能力和工作方法。

如果公司有一个非常全栈的数据科学家，再加上专门的数据工程师和开发人员的足够支持，或者，有足够的现有技术设施，专门用于数据湖和聚合、模型服务、扩展和监控（以及可能还有版本控制）的操作和自动化。可以对模型进行更广泛的定义，并且在模型开发的大部分迭代中都可以使用端到端解决方案。

这通常意味着首先构建完整的管道，从数据源一直到可扩展的服务模型，并为数据预处理、特征生成和模型本身提供简单的占位符。然后对数据科学部分进行迭代，同时将范围限制在现有基础上可用和可部署的部分。

这种端到端方法可能需要更多的时间来设置，并且模型类型和参数的每次迭代都需要更长的时间来进行测试，但是它节省了以后在产品化阶段所花费的时间。

就我个人而言，我很喜欢它，但是它的实现和维护过于复杂，而且并不总是合适的。在这种情况下，管道开始和结束的某些部分会被留到产品化阶段中。

3.3. 模型测试

在开发模型时，应该根据预先确定的硬指标连续测试模型的不同版本（以及伴随模型的数据处理管道）。这样就得到了对进展的粗略估计，并允许数据科学家确定模型何时运行良好，足以保证进行全面的 KPI 检查。请注意，这可能具有误导性，例如，在许多情况下，准确度从 50% 提到到 70%，要比从 70% 提到到 90% 容易得多。

图2：模型失败需要迭代，但是方法失败可能会让你回到研究阶段重来

当测试表明模型不准确时，我们通常会研究它及其输出以指导改进。然而，有时候性能上的差距很大，所选的研究方向的不同变化都达不到预期的效果——这是一个接近失败的结果。这就可能需要改变研究方向，将项目送回研究阶段。这是数据科学项目最难以接受的方面：回溯的可能性。

接近失败的另一个可能结果就是目标的改变。幸运的是，这可能是产品方面的小问题，但在技术上以更简单的方式重申了这一目标。

例如，与其试图生成一篇文章的一句话摘要，不如选择文章中最能概括文章的句子。

最终可能的结果当然是项目取消；如果数据科学家确信已经探索了所有的研究途径，并且产品经理确信无法围绕现有绩效构建有效产品，那么可能是时候转向另一个项目了。不要低估了确定一个无法挽救的项目的能力和做出结束项目的决定的勇气；这是快速失败方法论的关键部分。

3.4. KPI 检查

如果预先确定的硬指标是唯一的 KPI，并且准确地补货了所有的产品需求，那么，当推出最终模型、宣告开发阶段结束时，这个阶段可以更正式一些。通常情况并非如此。

在更常见的情况下，硬指标很好地近似了实际的产品需求，但并不是完美的。因此，这一阶段是确保无法自动检查的软指标也能得到满足的机会，这是与产品和客户的成功一起完成的。如果你还可以直接检查客户的实际价值，例如，当你与设计伙伴一起工作时，这是你所能找到的迭代最佳指南。

例如，假设我们正在处理一项复杂的任务，比如，给定一个查询，从一个巨大的语料库中提取相关的文档。团队可能已经决定尝试提高结果集的质量，重点关注返回文档的内容和主题的差异，因为客户认为系统倾向于在顶级结果中局级非常相似的文档。

对于结果集中的内容差异，模型开发可能已经取得一些可衡量的指标，给定一组测试查询，每个模型根据它返回的前 20 个文档的变化程度来评分。也许你可以测量某些主题向量空间中文档主题之间的总距离，或者仅仅测量唯一主题的数量或重要单词分布的平整度。

即使数据科学家确定了一个能显著改进这一指标的模型，产品和客户的成功人士也一定要查看测试查询的重要样本的实际结果；他们可能会发现难以量化但有可能解决的问题，例如推高一些反复出现的非相关主题来增加结果差异的模型，或者通过包括来自不同来源的类似主题的结果（如，新闻文章 vs 推文，它们使用了非常不同的语言）。

当产品人员确信模型符合项目的既定目标（达到令人满意的程度）时，团队就可以继续将其进行产品化。

4. 部署阶段

4.1. 解决方案产品化和监控设置

如前所述，这一阶段取决于公司中数据科学研究和模型服务的方法，以及几个关键的技术因素。

产品化：在研究语言可用于生产环境的情况下，这一阶段可能需要调整模型代码，使其以可扩展的方式工作；这一过程有多简单或有多复杂，取决于模型语言的分布式计算支持，以及所使用的特定库和自定义代码。

当研究语言和生产语言不同时，这可能还涉及到将模型代码包装在生产语言包装器中，将其编译为低级二进制文件或用生产语言实现相同的逻辑（或找到这样的实现）。

还需要设置可扩展的数据接收和处理，在这种情况下（非常常见），这并非模型的一部分。这可能意味着，例如，将运行在单个核心上的 Python 函数转换为管道流数据，或者转换为周期性运行的批处理作业。在重要数据重用的情况下，有时候还会设置缓存层。

监控：最后，建立了一种持续监控模型性能的方法；在极少数情况下，当生产数据的源不变时，也许可以安全地跳过，但是我想说的是，在大多数情况下，你并不能确定源数据分布的稳定性。因此，设置这样的性能检查，不仅可以帮助我们发现模型中在开发和产品化过程中可能遗漏的问题，更重要的是，还可以发现源数据分布的变化，通常称为 “协变量变化”（covariate shift），可以及时降低完美模型的性能。

以我们的产品为例，我们的产品是一个检测皮肤斑点的 App，它会评估是否推荐用户去看皮肤科医生。当一款流行的新手机上市时，我们的数据可能会发生写向量变化，因为这款新手机配备的摄像头与我们数据中的摄像头有很大的不同。

4.2. 解决方案部署

如果一切设置都正确的话，那么这个阶段可以总结为，希望按下一个按钮，将新模型（以及为其服务的任何代码）部署到公司的生产环境中。

部分部署：但是，为了测试该模型的有效性（例如，减少客户流失或增加每个用户的平均月支出），可能会将模型部署到只有部分用户 / 客户的环境中。这样就可以能够直接比较用户群中的两个（或更多）组之间的任何可测量的 KPI 的影响。

你可能不希望将模型部署到每个人的另一个原因是，它是为了满足特定客户或一群客户的需求而开发的，或者它是高级功能或者特定计划的一部分。或者，该模型可能具有针对每个用户或客户的个性化元素；这有时可以通过实际考虑客户特征的单一模型来实现，但有时需要为每个客户实际训练和部署不同的模型。

无论如何，所有这些场景都增加了部署模型的复杂性，并且取决于公司现有的基础设施（例如，如果你已经将某些产品功能部署到客户子集中），那么就可能需要你的后端团队进行大量的额外开发。

当模型要部署在终端产品上时，如用户电话或可穿戴设备，这个阶段会变得更加复杂，在这种情况下，模型部署可能只会作为部署的下一个 App 或固件更新的一部分来进行。

产生偏差：最后，由于另一个原因，对于数据科学团队来说，所有部分部署的案例实际都是一个紧迫问题。这自然会在模型将开始积累的未来数据中引入偏差，模型将开始由具有可能独特特征的用户自己对数据进行操作。根据产品和特定的偏差特征，这可能会对模型在野外的性能产生很大的影响，也可能对未来模型在此期间积累的数据进行训练产生很大的影响。

例如，在设备更新方面上，较早更新 App / 固件的用户往往属于特定的人群（更年轻、更精通技术、更高收入等等）。

4.3. KPI 检查

我在此添加了另一个 KPI 检查，因为我认为在部署和实际使用后验证了解决方案的性能和对产品和客户需求的成功相应之前，不能将其标记为已交付。

这可能意味着在部署之后的几周内，对结果数据进行筛选和分析。然而，当真正客户实际参与进来时，这还必须涉及到产品或客户成功人士，与客户一起试图了解模型对他们使用产品的实际影响。

4.4. 解决方案交付

用户和客户皆大欢喜。产品人员已经成功围绕模型构建或调整了他们想要的产品。我们完成了目标，举杯庆贺，雀跃欢呼，结局圆满。

解决方案已经交付，我认为此时项目已经完成。然而，它确实以一种特殊的方式存在着——那就是 “维护”。

维护

在为模型设置健康检查和持续的性能监控之后，这些可以触发项目工作的短暂爆发。

当某些东西似乎看上去很可疑的时候，我们通常会首先查看数据（如协变量变化），并且还可能会模拟模型对我们怀疑引起问题的各种情况的反应。这些检查的结果可以让我们在几个小时的少量代码改动、模型的重新训练和完整的模型开发迭代之间做任何事情（如本文开头图中所示），严重的情况下，有时还需要回到研究阶段尝试完全不同的方向。

最后的话

这是对数据科学项目流程的建议。它也是非常具体的，为了简单起见，它的范围也是有限的，显然并不能涵盖实践中存在的这个流程的许多变化。这也是我的经验所得。

关于这一主题还有另一个卓越的观点，我建议读者阅读我朋友 Ori 撰写的关于数据科学的敏捷软件开发的文章！

请参阅：

https://towardsdatascience.com/data-science-agile-cycles-my-method-for-managing-data-science-projects-in-the-hi-tech-industry-b289e8a72818

原文链接：

https://towardsdatascience.com/data-science-project-flow-for-startups-282a93d4508d