文章发布于公号【数智物语】 （ID：decision_engine），关注公号不错过每一篇干货。
转自 | AI前线
作者 | Shay Palachy
译者 | Sambodhi
编辑 | Vincent
导读：数据科学对初创公司有多重要？在初创公司中，数据科学项目流程有什么说道吗？作为在数据科学领域身经百战的老将 Shay Palachy，日前接受了一家名为 BigPanda 的初创公司的邀请，让他就该公司的数据科学项目发表自己的看法。作者在这篇文章中为那些想打造一直属于自己的数据科学团队的创始人提供了一些非常有价值的建议。
最近，一家名为 BigPanda 的初创公司邀请我对数据科学项目的结构和流程发表自己的看法，这让我思考是什么让它们独一无二。初创公司的经理和不同团队可能会发现，数据科学项目和软件开发之间存在差异，这种差异并不那么直观，而且令人困惑。如果没有明确的说明和解释，这些根本差异可能会引起数据科学家和同事之间的误解和冲突。
分别来说，来自学术界（或高度研究型的行业研究小组）的研究人员在进入初创公司或小型公司时，可能会面临各自的挑战。他们可能会发现，将新类型的输入（如产品和业务需求、更紧密的基础设施和计算限制以及客户反馈）纳入他们的研究和开发过程中具有挑战性。
这篇文章的目的是介绍我近年来在同事和我自己的工作过程中可识别的特殊项目流程。希望这可以帮助数据科学家和他的同伴们用发挥出他们独特性的方式来构建数据科学项目。
这个流程是建立在小型初创公司的基础之上的，一小组数据科学家（通常是一到四位）一次由一个人负责管理短期中型项目。较大的团队或机器学习优先的深度科技创业公司可能也会觉得这一结构有用，但大部分时候他们的流程会更长，结构也不尽相同。
图 1：初创公司的数据科学项目流程
我将纵向的流程分为三个部分：产品，数据科学和数据工程。在许多情况下（包括我工作过的大多数地方），可能并没有数据工程师来执行这些职责。在这种情况下，数据科学家通常负责与开发人员合作，帮助他解决这些方面的问题（如果他是全能大神：全栈数据科学家，那么他自己就可以凭一己之力解决所有的问题）。因此，根据你的环境，每当提到数据工程师时，你都可以用数据科学家来取代之。
在横向的时间轴上，我将这个过程分为四个不同的阶段：
范围界定
研究
（模型）开发
部署
我试着按顺序把每一个阶段都讲一遍。
01
范围界定阶段
定义数据科学项目的范围比任何其他类型的项目都重要。
1.1
产品需求
项目应始终从产品需求开始（即使最初想法是技术或理论上的），需要在某种程度上通过产品 / 业务 / 客户成功人士进行验证。产品人员应该知晓这个特征大致最终应该是什么样子的，并且现有或新客户愿意为此付费（防止客户流失 / 推动订阅 / 推动其他产品的销售 / 等等）。
产品需求并非完整的项目定义，而应该作为一个问题或挑战。例如：“我们的客户需要一种方法来了解如何使用他们的预算”或 “我们没有设法让老年客户继续服药，这就增加了客户的流失率” 或“客户会为一种能够预测他们运营的机场高峰时段的产品支付更多的费用”。
1.2
初步解决方案构想
这就是数据科学家与产品负责人、数据工程师和任何其他相关者一起，为可能的解决方案提出不同的草图的地方。这意味着通用方法 (例如，无监督聚类 vs 基于提升树的分类 vs 概率推理）和要使用的数据（如，我们数据库中的特定表，或者我们尚未监控或保存的某些特定用户行为，或外部数据源）。
这通常还涉及一定程度的数据探索。但在这步你不能深入研究，但任何有希望的“唾手可得的成果”都可以帮助打开思路和想法。
数据科学家应该领导这个进程，并且通常负责提供解决方案的思路，但我强烈建议你在构思解决方案时动员所有对该解决方案产生影响的人; 我有幸从后端开发人员、CTO 或产品负责人那儿得到了一个项目的最佳解决方案。不要认为不同的、不太注重理论的背景会使人们无法参与这一阶段，须知额外的想法和观点总是有价值的。
1.3
数据准备和可访问性
团队现在应该很了解解决问题需要哪些数据了（或者至少是初始数据集或数据来源）。因此，在进行下一阶段的同时我们应当已经开始准备数据访问权限以及数据的使用探索了。
如果在研究阶段中，时间可用性不是很关键的话，那么这有时可能需要将大型数据及从生产数据库转储到临时 / 探索的对应方，或者转储到较冷的存储（如对象存储）中。相反，它可能意味着将大型数据转储从非常冷的存储拉回到表或文档形式，以实现快速查询和复杂的计算。无论如何，这一阶段都需要在研究阶段开始，并且经常会耗费比预期更多的时间，因此，这是启动研究阶段的最佳时机。
1.4
范围与 KPI
这一阶段是关于共同决定项目的范围和 KPI（Key Performance Indicators，关键绩效指标）。
KPI 应当首先从产品的角度来定义，但要比之前更详细；例如，就上述三种产品需求而言，它们可能会变成 “客户现在可以使用带有 CTR 统计数据和每个类别图像的仪表板”，或 “在未来两个季度内，65 岁以上的用户错过的服药天数至少减少 10%”，或 “客户都会收到每周的机场高峰时间的预测，预测的力度至少为一个小时，近似值至少为 ±50%”。
然后应将这些KPI转换为可衡量的模型指标。如果顺利的话，这些将是非常量化的指标，例如“对于任何至少运行一周的广告，以及任何有超过两个月历史数据的广告客户，预测其广告在至少Y％的情况下点击率至少为X％“。但是，在某些情况下，必须使用不那么精确量化的指标，例如“与原始查询相比，用生成扩展查询进行主题探索所需的时间将被缩短，并且/或着结果将得到改善”。当模型旨在辅助一些复杂的人体功能时，情况尤其如此。
从技术上讲，即使这些指标也可以非常严格地定义（在学术研究中通常亦如此），但是根据资源和时间的限制，我们可能会通过人工反馈来近似地对它们进行定义。在这种情况下，每次反馈迭代可能需要花费更长的时间，因此，我们通常会试图寻找额外的硬指标来指导我们完成大部分即将进行的研究迭代，往往是几次迭代或者需要重大改变时才进行一次比较大规模的反馈收集。
最后，范围界定在这里特别重要。因为当研究过程中出现新的可能性或者当下研究的方法只能解决一部分的问题时，研究项目就会容易拖延，并且自然而然地会扩大规模和范围。
范围界定 1：我发现明确地界定范围更有成效。例如，如果已经确定基于多臂老虎机问题（Multi-Armed Bandit）的模型是最有效的方法，那么您可以将项目范围定义为一个两周或三周的模型开发及迭代，无论其准确性如何都要部署模型（例如只要它超过了60％）。如果提高准确性是有价值的（在某些情况下它可能没那么重要），那么接下来就可以把开发第二个模型作为一个单独的项目。
范围界定 2：范围限制的另一个变体是使用越来越复杂的复杂性；例如，第一个项目的目标可能就是部署一个模型，这个模型只需为你自己的客户成功人士提供相当多的候选广告措辞和颜色变化，第二种方法可能会尝试构建一个模型，提供一组更少的建议，让客户能够看到自己；最终的项目可能会尝试突出显示单个选项的模型，低于它的数量，并为每个变化增加 CTR 预测和人口覆盖范围。
这已经与软件工程有很大不同，软件工程通常只会迭代组件以扩大规模，而不是增加其复杂度。
然而，产品价值度量函数可能是一个阶梯函数，这意味着任何指标未达到X值的模型对客户来说都没用；在这些情况下，我们更倾向于使用迭代，直到收敛到最佳阈值。然而，虽然在某些情况下这个X值可能非常高，但我相信无论是产品人还是业务员，亦或是数据科学家都倾向于高估这一要求，就像很容易得出如下结论：任何准确度低于95％（95%只是举例）的东西就没有任何价值且卖不出去。然而，在许多情况下，虽然对产品假设的严格审核和挑战有益于打造出有价值的产品，但这些产品在技术指标上要求可能没那么苛刻（至少对于产品的第一次迭代而言是如此）。
1.5
范围和 KPI 的批准
最后，产品负责人需要批准界定的范围和KPI。数据科学家的工作是确保每个人都了解范围的内容和优先级顺序，以及产品KPI与指导模型开发的指标之间的关系，包括指标与KPI的接近程度。明确说明这一点可以预防出现模型的使用者（包括产品人员和业务人员）在模型已经进入开发或者开发完成后才发现，开发的东西不是自己想要的。
1.6
关于范围的总论
这个阶段在很多地方都被忽略了，数据科学家往往开始挖掘数据并探索关于可能解决方案的论文；然而根据我的经验，这几乎总是最槽糕的。跳过这一阶段可能会导致花费数周或数月的时间来开发很酷的模型，而这些模型最终无法满足实际需求；或者在一个非常特定的 KPI 中失败，而这个 KPI 本可以通过某些预先设想来明确定义。
01
研究阶段
2.1
数据探索
有趣的部分开始了！在确定范围之后开始这一阶段的主要优势在于，我们可以通过实际的KPI和模型性能度量指标的指导，来进行数据探索了。
像往常一样，在探索和开发之间要取得平衡；即时有明确的 KPI，在某种程度上探索一些看似无关的途径也是有价值的。
到目前为止，数据工程应该可以得到所需的初始数据集。但是，在这一阶段中，经常会发现探索数据中的一些缺陷，并且可能会将其他数据源添加到工作集中。数据工程师应为此做好准备。
最后，虽然此处与文献和解决方案评审阶段分开，但它们通常是并行完成的，或者是交替进行。
2.2
文献与解决方案评审
这一阶段回顾了学术文献和现有的代码和工具。在探索和开发之间，以及对材料研究深入和快速地有所收获、分析其使用的可能性之间，平衡同样重要
就学术文献而言，选择在形式化证明和之前的文献等方面有多深入，在很大程度上取决于时间限制和项目背景：我们是在为公司的核心能力打下坚实的基础，还是在为一次性问题设计解决方案？我们打算在学术论文中发表关于这一主题的研究成果吗？你打算成为这个主题的团队专家吗？
例如，假设一个数据科学家着手一个项目，帮助销售部门更好地预测潜在产量或客户流失率，他觉得自己对随机过程理论的理解很肤浅，而这些问题的许多常见解决方案都是监理在这个理论的基础之上。对这种感觉的适当反应可能非常不同；如果他在一家算法交易公司工作，那么他肯定会深入研究这一理论，甚至可能会参加一门关于这个主题的在线课程，因为这与他的工作非常相关；另一方面，如果他在一家医学影像公司工作，该公司专注于肝脏 X 射线扫描中肿瘤自动检测，我认为他应该会尽快找到一个可行的解决方案，然后继续前进。
在代码和实现的情况下，要达到的理解深度取决于技术方面，其中一些可能在过程的后期才会被发现，但是，其中也有许多是可以提前预测的。
例如，如果生产环境仅支持为后端使用部署 Java 和 Scala 代码，那么解决方案预计会以 JVM 语言提供，即使在这个研究阶段，数据科学家也必须深入研究基于 Python 的实现，因为随着它们进入模型的开发阶段，需要将它们转换为 JVM 语言。
最后，在回顾文献时，请记住，不仅要向团队的其他成员展示选定的研究方向（或几个方向）。相反，应在作出选择的同时，对该领域和所有经过审查的解决办法作一次简短的审查，解释每一个方向的优点和缺点以及选择的理由。
2.3
技术有效性检查
根据可行性解决方案的建议，数据工程师和与之相关的开发人员需要在数据科学家的帮助下，估计该解决方案在生产中的形式和复杂性。产品需求以及建议解决方案的结构和特征，都应有助于确定恰当的数据存储空间、处理方式（流与批处理）、扩展能力（水平扩展和垂直扩展），以及粗略地估算成本。
这是在这一阶段执行的一个重要检查，因为一些数据和软件工程可以与模型开发的同时开始。此外，从工程角度来看，建议的解决方案可能存在不足或者成本太高，在这种情况下，应尽快确定并处理。在模型开发开始之前考虑技术问题时，在研究阶段获得的只是可以用来建议更适合技术约束的替代解决方案。这也是为什么在研究阶段还必须对解决方案前景进行一些概述，而不仅仅是在单个解决方案方向的另一个原因。
2.4
范围和 KPI 的验证
再次强调，产品经理需要对用技术语言所表述的建议解决方案是否满足项目范围及所定KPI进行审核。易监测的产品表现指标可作为待选的技术标准，包括：响应时间（以及它与计算时间的关系）、数据及偶发中间运算新鲜度（与请求和批计算频率相关）、特定域模型的域适应难度及成本（成本包括数据成本；多数情况下领域是指客户域，但也可以是行业、语言、国家等等）、解决方案可模块化性（例如：数据结构和模型结构的特性能够让国家级模型分解为其下一层区域模型，或者是指将国家级模型整合为大陆级模型），以及其他各种指标。
02
开发阶段
3.1
模型开发和实验框架的建立
开始模型开发时所做设置的量级和复杂程度都严重依赖于基础设施与数据科学家所能获取的技术支持。在规模较小的情况下，或者在之前没有支持过数据科学研究项目的公司，需要做的设置包括数据科学家新建代码存储库、建立本地Jupyter Notebook服务器，或者申请更强大的云机器以供运算。
在别的情况下，设置工作可能从自定义代码开始，以供更复杂的功能实现，例如数据和模型版本迭代，或者实验跟踪及管理。当一些外部产品或者服务能够提供这类功能时（这样的供应商越来越多了），一些设置工作随其后而至：连接数据源、分配资源以及设置自定义软件包。
3.2
模型开发
所需要的基础设施到位后，万众期待的数据模型开发就可以开始了。模型的开发程度随公司而异，并且依赖于数据科学家交付模型与产品实际部署的功能或服务之间的关系或区别。发现这些区别的方法有很多种，比如说谱分析。
频谱分析的一个极端是指万物皆模型：从数据整合和预处理，经过模型训练（也许是周期性的）、模型部署、实际服务（可能将规模化）到持续的监督。另一个极端，就是指模型类型和超参数的选择，常常还有后期数据预加工、特征生成，这些都被视为模型的一部分。
一个公司在谱分析上的位置取决于很多因素：数据科学家偏好的研究语言、相关的工具库和开源资源的可获取性、公司内的生产语言、专门为数据科学家提供相关代码支持的数据工程师和开发人员是否存在、数据科学家的技术水平和工作方法。
如果公司有一个非常全栈的数据科学家，再加上专门的数据工程师和开发人员的足够支持，或者，有足够的现有技术设施，专门用于数据湖和聚合、模型服务、扩展和监控（以及可能还有版本控制）的操作和自动化。可以对模型进行更广泛的定义，并且在模型开发的大部分迭代中都可以使用端到端解决方案。
这常常意味着首先需要建立完善的工作通道，从数据源到可规模化的模型，在整个规划中给数据预加工、特征生成以及模型本身留着位置。随后在数据科学这部分进行迭代，同时保证整体范围与现有基础设施的承载能力和部署能力契合。
这样端到端的方法需要花费更长的时间设置，并且每次模型类型和参数的迭代都需要更长的时间测试，但是在后来的生产阶段将大大节约时间，赚回成本。
我个人偏向于这种端到端的解决方案，但它在实施和维护的时候的确比较复杂，且并不总是适用。这种情况下，开始和结束阶段的一些工作可以放到生产阶段去做。
3.3
模型测试
开发模型时，需要使用预先决定的标准对其不同版本不断进行测试（数据处理工作同步进行），这能够对模型改善提供一个大致的估计，并且为数据科学家决定何时这个模型能够满足整体KPI检查提供有效输入。但是需要注意，这个检测结果会有一些误导性，比如说在大多数情况下，模型的准确性从50%上升到70%，比从70%上升到90%容易得到。
图 2：模型失败需要迭代，但是方法失败可能会让你回到研究阶段重来
当测试结果显示模型开发已经脱离轨道，我们常常需要深入调查其内部以及其结果，以找到改进的方案。但有时，表现之间的差距实在太大，所选择的研究方向中不同的变化都达不到要求——一个方法的错误。这也许需要对研究方法做出修正，整个项目将从头再来。这是数据科学项目最难接受的：推到重来的可能性
另一个方法论错误的后果就是目标的改变。如果足够幸运，那么也许只是在产品层面的微小变动，只需要把目标更简单的表述出来就好。
例如，舍弃掉生成文章的一句话总结功能，而是从文章中找出最能够总结内容的句子。
最终可能的结果当然是项目取消，如果数据科学家确信已经探索了所有的研究途径，并且产品经理确信无法围绕现有绩效构建有效产品，那么可能是时候转向另一个项目了。不要低估了确定一个无法挽救的项目的能力和做出结束项目的决定的勇气，这是快速失败方法论的关键部分。
3.4
KPI 检查
如果事前决定的指标是唯一的KPI，并且在过程中也获取了所有产品所需要的数据，那么这一个环节形式大于实质，最终模型将呈现在大家面前，开发阶段也宣告结束。但事实上并不总是如此。
大多数情况下，事前确定的只是对真实产品需求的近似推理，但并不是最佳选项。因此，这个阶段将是一个很好的机会，使用一些无法自动检测的软性指标来看产品是否满足要求。如果这一步通过，那么产品和客户满意都能够达到。如果你能另外直接检测产品对于一个用户产生的实际价值 ——例如，和一个设计合伙人共同工作——那么测试结果将是你对模型迭代最好的输入。
比如，我们正在试图解决一个复杂的任务，包括从一个巨大的语料库中提取相关文档、发起请求。项目组也许将决定尝试着增加结果集的质量，集中注意力在返回文档的内容和话题的不同之处上，因为客户可能会觉得这个系统总是倾向于在最优结果中集中极其相似的文档。
模型开发进程中，将逐渐在结果中增加一些可量化内容变化的测试标准，每个模型以前20个返回文档之间的不同程度打分，然后发出一系列测试请求。也许你会测量在一些话题向量空间下文档话题之间的整体差别，或者仅仅只是特殊话题出现的次数，或者显著组成分布的平坦度。
即使数据科学家确定了一个能显著改进这一指标的模型，产品和客户的成功人士也一定要查看测试查询的重要样本的实际结果；他们可能会发现难以量化但有可能解决的问题，例如推高一些反复出现的非相关主题来增加结果差异的模型，或者通过包括来自不同来源的类似主题的结果（如，新闻文章 vs 推文，它们使用了非常不同的语言）。
当产品负责人确定模型已经达到了这个项目的所有目标（到达令人满意的地步），那么项目组可以继续推进，开始产品化了。
03
部署阶段
4.1
解决方案产品化和监控设置
正如前面提到的，这个阶段与各公司数据科学的研究方法、模型服务，以及几个关键的技术因素密切相关。
产品化：在研究语言可用于生产环境的情况下，这一阶段可能需要调整模型代码，使其以可扩展的方式工作；这一过程有多简单或有多复杂，取决于模型语言的分布式计算支持，以及所使用的特定库和自定义代码。
当研发语言和生产语言不同时，这可能还要涉及在生产语言包装器中将模型代码打包，并编译为二进制文件，或是在生产语言中重现相同的逻辑（或者找到这样的重现方式）。
如果模型中不包含可伸缩数据的提取和处理方案（这是非常普遍的情况），那么就需要进行额外设置。这意味着，例如，将运行在单核上的python函数转换为管道流数据，或者将其转换为定期运行的批量处理作业。在需要多次重复使用数据的情况下，有时需要设置缓存层。
监控机制：最后，需要建立一种持续监控模型性能的机制；在极少数情况下，如果生产数据源稳定，这个步骤可以被跳过，也不会造成大麻烦，但我要说的是，在大多数情况下，并不能十分确定源数据分布的稳定性。那么，设置这样的性能检查不仅可以帮助我们发现在开发和生产过程中可能遗漏的模型问题，更重要的是，在已经运行的模型的源数据分布中的任何变化- -通常被称为协变变化-可以随时降低一个完美的模型的性能。
以我们的产品为例，那是一个通过检测皮肤斑点来评估是否推荐用户去看皮肤科医生的app。当一款流行的新手机上市时，如果它配备的摄像头与我们原有数据中的摄像头参数有很大的不同，协变变化就有可能发生。
4.2
解决方案部署
如果一切都设置得正确，那么这个阶段就是一句话，按下按钮，新模型(以及它的任何代码)被部署到公司的生产环境中。
部分部署：然而，有时为了测试模型的有效性（例如，减少用户流失，或者是增加每个用户每月的平均支出），可能只需要对部分用户/客户进行部署。这样就可以用可测量的KPI，直接对两个（或多个）用户库之间的影响进行比较。
您可能不想将模型部署到每个人身上的另一个原因是，该模型的开发是为了满足特定客户或一组客户的需求，或者它是高级功能或特定计划的一部分。或者，模型可能对每个用户或客户都有附加一些个性化元素；这些可以通过一个考虑了客户特征的单一模型来实现，但有时也需要为每个客户训练和部署不同的模型。
无论是以上哪个场景，都会增加部署模型的复杂性，复杂程度取决于公司的现有情况（例如，您是否已经将一些产品特性部署到客户的子集中），它们可能需要后端团队进行大量的额外开发。
当模型要部署到终端产品，如用户电话或可穿戴设备上时，这个任务将变得更加复杂，在这种情况下，模型部署可能要放到下一个应用程序中进行或者是作为固件更新的一部分。
产生偏见：对于数据科学团队来说，部分部署是一个棘手的问题，因为这种部署必然会带来偏差，而且模型会持续积累这种偏差，终有一天原来的模型会依据这些具有特性的用户数据进行工作。不同的产品类型和偏差的特征，有可能会对模型的性能产生很大的、未知的影响，而且可能对那些用了在此期间积累的数据训练出来的未来模型产生很大的影响。
例如，在设备更新方面，那些较早更新应用程序/固件的用户往往属于特定的人群（更年轻、更懂技术、收入更高等等）。
4.3
KPI 检查
我在这里又添加了一个KPI检查，因为我认为在一个解决方案被认定为性能达标、已解决产品设计之初的问题、满足客户需求之前，不能被认定为已交付。
这个步骤是指，在部署之后的几周内对数据结果进行筛选和分析。然而，当涉及到实际的客户时，还必须要请产品或销售人员，让他们与客户坐在一起，试图了解模型在实际使用中的效果。
4.4
解决方案交付
用户和客户皆大欢喜。产品人员已经成功围绕模型构建或调整了他们想要的产品。我们完成了目标，举杯庆贺，雀跃欢呼，结局圆满。
解决方案已经交付，我认为此时项目已经完成。然而，它确实以一种特殊的方式存在着——那就是 “维护”。
维护
为模型设置了的健康检查和持续的性能监控，可能会将我们带回到项目中。
当某些东西看起来可疑时，通常我们首先查看数据（例如协变变化），并根据我们所怀疑的能引起问题的各种情况，来模拟模型的反应。根据这些检查的结果，我们可能需要花几个小时修改代码、或者重新训练模型、或者重新进入模型开发流程（如本文开头的图所示），在一些严重的情况下，我们需要返回到研究阶段，尝试完全不同的方向。
01
最后的话
这是对数据科学项目流程的建议。它本身是非常具体的，这篇为了简单起见，限定了它的范围，它显然并不能涵盖实践中存在的这个流程的许多变化。仅仅是我的经验所得，如有不足，还请见谅。
网友评论