分享进行真实世界数据科学项目的经验教训

编者按：Deliveroo数据科学家Jonny Brooks-Bartlett分享了进行真实世界数据科学项目的经验教训。

引言

大多数关于如何“完成”数据科学任务的文章通常讨论的是如何编写解决问题的算法。例如，如何分类文本文档或预测财经数据。然而，这样的任务仅仅是完成一个数据科学项目这一过程中的一小部分。即使你能完美写出求解多类文本分类问题的算法，你仍将面临很多问题：它在商业上有实际价值吗？这一问题当前有什么解决方案，你做了什么样的评测能说服用户信任你编写的算法的输出？算法部署到生产环境后，你能持续获取反馈以了解算法输出是否仍然有用吗？

我将在这篇文章中讨论一些开发维护高效、可持续的数据科学项目的指导意见。这篇指南基于我在自己的数据科学项目中得到的教训，还结合了我看到的其他人进行数据科学项目所犯的错误。其中一些经验未必适用于所有数据科学家，因为不同的数据科学家工作范围不同。我所处的团队没有专门的商业分析师、产品经理、数据科学经理。这意味着我本人需要承担这些角色的部分职责，我经常在这方面做得不好。不过，对我而言，这是很有价值的学习体验，我将在后文介绍我学到的一些东西。

特别提示： 不管你是否同意我的胡扯，你应该看下Warby Parker数据科学主管Max Shron的视频Stakeholder-Driven Data Science at Warby Parker（利益相关者驱动的数据科学）。这是一个很棒的视频，介绍了很多真实世界数据科学项目的情况。

成功项目应该满足哪些条件？

我发现，在解决一个问题前，首先厘清怎样才算成功是很有用的。（这里我们假定已经清楚问题是什么，但请不要低估辨识出需要解决的问题的难度。）这有助于我制定达到最终目标的策略。

你为何进行这个项目？例如，这个项目带来了什么价值，它为数据团队更大的目标做了什么贡献？

谁是这个项目的主要利益相关者？

这一问题的当前解决方案是什么？

是否存在可以快速实施的简单高效的解决方案？

你是否努力获取相关人员的注意和信息？

你是否找人评估过你的方案的合理性？

你是否努力确保代码的鲁棒性？

你是否努力确保项目容易理解，方便移交给别人维护？

如何在生产环境中验证你的模型？

如何收集解决方案的反馈？

就我的经验而言，如果这些问题都能找到合适的答案，那么这个项目基本上就成了。当然，取决于项目的具体情况，这并不是确凿无疑的，上面的列表也远远没有穷尽成功的条件。但不管怎么说，上面的列表是一个良好的开始。

如果你瞧不上我列出的问题，可以参考Kate Strachnyi的20个问题：https://towardsdatascience.com/20-questions-to-ask-prior-to-starting-data-analysis-6ec11d6a504b

下面介绍的步骤有助于应对这些问题。

数据科学项目的五步方针

第一步：初步评估项目的潜在价值

为什么进行这一步？ 这个问题有助于你设定项目的优先级。你应该能够恰当地回答为什么一个项目应该在另一个项目之前完成。这个问题也让我们更好地理解项目和团队、公司的目标的一致性。此外，也为我们应该优化模型的哪些测度提供了指引。

这一步涉及什么？ 大致评估下收益，例如，节省的资金，增加的收益，节省的人力。有人不主张进行这项评估，因为做这个评估很难，而且收益并不总是能够量化。对此，我的回应是：如果你或者利益相关者弄不清楚项目的价值，那么为什么要浪费你或者利益相关者的时间呢？评估的数值不必完美，大概估计下就行。这一步也包括判定谁是主要的利益相关者。

如果不做这一步会怎么样？我们可能花费大量时间进行一个无人获益的项目。我曾经见过一个项目，需要数据科学团队识别值得营销团队联系的最能带来收益的客户列表。创建模型之后，我们决定花几个月的时间改进这一模型。尽管新模型给出了更好的结果，但营销团队调整了阈值，因为他们不在乎为每个客户生成的评分，只打算联系固定数目的客户。所以，花在改进模型上的时间很可能毫无意义。（当然，可能联系的固定数目的客户实际上能带来更多收益，因为模型更好了，但因为没有测量这方面的数据，所以我们并不知道这点是否成立。）

这一步的输出是什么？ 项目价值的大概估计和简短的项目总结。注意，取决于公司和项目的情况，可能只需说明数据模型能够带来可以观测到的收益，而无需估计具体数值。不过这很大程度上取决于公司政治。

有用资源： A Simple way to Model ROI of any new Feature（建模新特性ROI的简单方法）给出了一个简单的公式：期望ROI = (惠及用户 × 新使用量/增加的使用量 × 商业价值) - 开发成本。Prioritizing data science work（为数据科学工作设定优先级）和Product and Prioritisation（产品和优先级指定）这两篇文章也值得一读。

第二步：判定现有方法/创建基线模型

图片来源：Rama Ramakrishnan

为什么进行这一步？ 当前的解决方法提供了一个评测的目标。如果当前存在解决方法，所有有用的模型都应该胜过当前方法。如果面临的问题当前尚无解决方案，那么你应该开发一个基线模型。基本上，基线模型就是不用机器学习的方案。复杂方案很可能只能提供一点增值，所以你需要评估下创建更复杂的模型是否值得。

这一步涉及什么？ 找利益相关者谈下，他们当前是怎么做的，取得了哪些成功。很可能他们并未测量成功程度，所以有时你需要自行估计/计算。创建基线模型不应该设计任何复杂、需要大费周折的方法。基线模型应该是相当迅速、原始的，甚至可能直接使用计数这样简单的方法。

这一步的输出是什么？ 基于基线量化评估成功模型（对利益相关者有用）需要达到什么样的表现。评估是否值得创建复杂模型。

如果不做这一步会怎么样？ 你可能浪费时间创建了一个复杂的模型，结果发现不值得投入这些时间提高这点精确度，甚至不能战胜当前方法。我们创建自己的推荐引擎的时候就忽略了这一点。我们没有检查算法是否优于实用的基线（推荐最流行的内容）。很可能推荐算法没有提供对得起投入的开发成本的价值。

有用资源 Create a Common-Sense Baseline First（首先创建常识基线模型）和总是从蠢模型开始，强调了这一点。

第三步：“团队”讨论

为什么进行这一步？ 目前为止，我们已经得出结论，项目值得进行（第一步），有可行性（第二步），所以，是时候和相关人员谈谈了，比如工程师和其他数据科学家。应该编写什么代码，需要什么数据，应该做哪些测试，使用哪些测度评估表现，尝试哪些模型方法，这些你现在应该比较清楚了。你自己可能觉得需要做什么一清二楚，但是和别人讨论一下常常有助于找到你遗漏的东西或者可以改进的地方。不要低估让不同视角的人参与讨论的重要性。

这一步涉及什么？ 至少和另一个数据科学家聊一下，展示你已经取得的结果。也许他们能告诉你如何改进你的想法。开始开发模型前的讨论必不可少，因为写好模型后通常就不怎么方便大改了。同时，和你讨论的数据科学家也许会评审你的代码，事先讨论一下有助于他们了解上下文。和项目工程师聊下，他们负责产品化你的工作。他们可能需要知道可以期待什么，也可能提一些有助于产品化代码的建议。

这一步的输出是什么？ 没有什么具体的输出。这一步不过是在第一时间保证项目质量。确保相关人员了解项目。

如果不做这一步会怎么样？ 最好的情况，你独自想出了怎么做这个项目，并避开了所有的坑。然而，更可能的情况是你没有考虑到所有事情，漏掉了一些重要的事情。会碰到的典型问题包括将模型转移到生产环境时，难以迁移、处理存储文件。模型输出缺乏标记，没有给出最有用的格式。这是我开发一个模型时碰到的情况。我编写的代码中，有很多API调用是不必要。在本地的小数据集上，模型运行得很好，但在生产环境中，加载数据很吃力。直到我求助一个工程师后才解决了问题（这个工程师帮助我查明了问题）。

第四步：模型研发

为什么进行这一步？ 不用多说，最终解决问题靠的是模型。

这一步涉及什么？ 这取决于具体的项目。需要注意的是，模型研发并不等于创建模型。有太多关于如何编写机器学习算法解决特定问题的文章了，所以我这里就不多说了。我想强调一些有助于产生高质量产品代码的步骤。通常情况下你不是唯一一个看代码的人，所以代码审阅和文档对项目的寿命而言至关重要。在生产环境几乎一定会碰到bug和意料之外的输入，所以你可以通过代码测试来缓解这些问题，增强代码的鲁棒性。这包括单元测试，集成测试，系统测试，用户接受测试（UAT）。关于如何使代码便于产品化的规范，不同团队可能有所不同，不过有一些东西是相通的：在隔离环境下工作（虚拟环境或Docker容器），记录日志，使用配置文件。

这一步的输出是什么？ 一个共享的代码仓库，其中包含解决项目所定义的问题所需的文件和可以工作的模型。

如果不做这一步会怎么样？ 如果代码未经测试，逻辑上的错误可能直到部署到生产环境后才暴露出来。如果代码没有经过他人评审或者没有文档，你离职或者休年假的时候其他人很难接手。我之前做过的一些项目就不断出问题。我现在还需要给9个月前“完工”的一个项目修bug. 这占用了我做其他有价值的事情的时间，令所有项目相关人员沮丧。在开发阶段额外花一点时间保证代码的鲁棒性，长期来看，可以节省你很多时间。

资源 How to write a production-level code in Data Science?（如何编写生产环境级别的数据科学代码？）是一篇全面的指南，覆盖了我能想到的一切东西。如果你是一个编写生产环境级别的代码的数据科学家，你应该读一下这篇文章。另外推荐Code Reviewing Data Science Work（数据科学工作的代码审阅）和Doing Code Review Solo & Writing Good Code（自我审阅代码 & 写好代码）这两篇关于代码审阅的文章。后一篇文章介绍了如何通过自我审阅代码提高自己编写的代码的质量，这并不能代替实际的代码审阅。Code Documentation Guide（代码文档指南）介绍了如何恰当地编写文档。我个人很喜欢numpy风格的docstring。关于代码测试，我推荐How to unit test machine learning code（如何单元测试机器学习代码）这篇指南，还有semaphore的Testing Python Applications with Pytest（使用Pytest测试Python应用），我自己一个项目开始编写测试的时候参考了这篇教程。semaphore上还有一篇Getting Started with Mocking in Python（Python伪造数据入门），介绍了如何为测试伪造数据。Python unit testing with Pytest and Mock（使用Pytest和Mock进行Python单元测试）则是另一篇值得一读的指南。

第五步：模型监测和反馈

为什么进行这一步？ 这是为了确保产品在生产环境中的表现符合期望。解决方案的输出应该是稳定可靠的。如果出现了错误，我们应该是第一个知道的。模型的表现比期望的差吗？生产环境的数据和训练数据的格式不一样吗？数据不正确吗？自动化检测可以节省大量手工查看输出、追查代码以确保一切符合期望的时间。为公司提供价值是我们的职责，所以我们应该测量解决方案的影响力。是否良好运作？需要调整吗？创造了多少利润？使用有多频繁？我们可以向管理层报告这些，以显示数据科学的商业价值。

这一步涉及什么？ 在模型部署到生产环境后的一段时间内（也许是两三周），主动地手工检查所有一切运作良好。然后自动化检测过程，也许可以创建一个控制面板和一套邮件预警系统，和/或一个异常检测系统。也许利益相关者也需要进行监测，所以可能需要调整监测方案，使其对非技术同事更友好。至于反馈方面，可能涉及和利益相关者讨论如何接受反馈？定量反馈还是定性反馈？你可以在产品中编写记录使用数据的代码，这样不用明确要求利益相关者报告使用习惯。

这一步的输出是什么？ 确保模型恰当工作、提供解决方案使用量和价值的定性或定量反馈的方法和产品。可能也包括出错时的通知/预警系统。

如果不做这一步会怎么样？ 如果没有恰当地监测我们的产品，我们将承担产品出错时商业利益相关者丧失信任的风险，同时也可能导致商业损失，团队尝试修复问题也可能花掉大量时间。我曾经碰到过的一个情况是，我们创建的数据分析工具给出了离谱的图表。结果发现是原始数据提供商搞砸了数据。但是，利益相关者在团队之前发现了问题。之前模型研发阶段描述过的鲁棒性测试和自动预警系统本应该侦测到这个问题，但我们并没有配备这些。当数据最终回归正常之后，利益相关者以为数据还是错的。我们数据团队花了2周时间检查数据，最后得出结论数据没有出错！我们损失了2周的时间。自动化监测系统本可以将2周降至2分钟！此外，如果我们不收集反馈，那我们就会对项目是否有用，甚至项目是否还在使用一无所知。我们曾在和市场团队的一次会议中询问“你们在使用这个模型吗？”我们本不应该提出这个问题，因为 1) 在第一步和第二步，我们应该确保模型具有价值，并且超过了当前解决方案/基线模型的表现 2) 我们应该将监测系统作为项目的一部分，而不是在一次不相关的会议中询问利益相关者是否使用我们的项目。这显示了我们并没有测量模型的影响力。

没提到的步骤

我的好朋友Michael Barber提醒我遗漏了一个重要步骤：评估。模型评估是一个极为重要的部分，不恰当的评估可能导致模型在生产环境中发生意料之外的退化。这方面，Fast.ai的Rachel Thomas写过一篇出色的文章How (and why) to create a good validation set（如何/为何创建良好的验证集）。

此外，我完全忽略了试验。判定你的数据科学方案是否具备预想的影响力的最好方法之一是进行试验，A/B测试。Julia Silge写过一篇出色的文章From Power Calculations to P-Values: A/B Testing at Stack Overflow（从功效计算到P值：StackOverflow的A/B测试）。

这里我不会深入这两方面的细节，因为这篇文章已经太长了。第三步和利益相关者讨论的环节应当讨论如何进行模型评估和A/B测试。

结语

上面介绍了我觉得进行一个成功的数据科学项目需要遵循的五大步骤。需要注意的是，数据科学家不一定要完全施行这5个步骤，因为有些团队有专门的成员负责其中一些任务。例如，商业分析师或产品经理可能负责和利益相关者沟通，以决定一个项目是否有价值，需求是什么。同时，不是所有的项目都需要这些步骤。如果项目是一次性分析，那么创建持续检测输出的面板就毫无必要。

现实一点，你不需要遵循所有这些步骤以创建一个成功的数据科学项目。在大多数情形下，编写一整套测试和文档，同时为利益相关者配置监测面板，一旦出现异常报警，不太实际。更可能的情况是，你需要权衡这些事情中哪些值得做，以便在（可能不合理）的截止日期前完成项目。我承认，我没有一个项目完成了所有这些步骤，不过我当时意识到了自己在做什么，以及为何在特定时刻这么做是一个实用的决策。

我还想指出的另一件重要的事是这些步骤仅仅是一些有助于项目成功的指导原则。而想要成为一个成功的数据科学家，还需要具备一些品质，掌握一些技能。我推荐阅读My two cents on what makes a good data scientist nowadays?（今时今日的优秀数据科学家需要具备什么条件，我的一点看法）和4 Must Have Skills Every Data Scientist Should Learn（数据科学家必备的4项技能）这两篇文章。