前Facebook产品经理：打造机器学习产品的黄金手册（中）

作者：前 Facebook，雅虎产品经理 yaelg

编译：珊珊

人工智能时代，每位产品经理、企业家以及商业领袖都应该了解机器学习。

即使你不是在设计一款chatbot或者无人车，但为了产品保持竞争力，你早晚都要把机器学习融入到你的产品中。

好消息是，你不需要发明新的技术，只需利用已有的技术。许多科技公司开放开源工具和平台（如Amazon AI，TensorFlow—最初由Google开发的）使得几乎所有公司都可以使用机器学习。

当我开始捣腾机器学习的时候，我什么都不晓得，然而在很短时间内，我便掌握了领导开发机器学习产品的核心要领。

我的目标是让你充分了解开发机器学习产品的技术和开发流程，使你能尽快开始。这将是一份循序渐进的教程，助你成为利用机器学习实现业务目标的PM（产品经理）。

手册共6部分：

1. 机器学习可以为你的业务带来什么

2. 你需要了解的机器学习算法以及为什么要了解

3. 机器学习模型开发的流程始末

4. 机器学习产品团队的角色分工，技能和组织结构

5. 机器学习差不多就是个UX（User Experience）问题

6. 产品经理应该了解的开发注意事项

▍第3部分

机器学习模型开发的流程始末

这是“打造基于机器学习的产品教程”的第3部分，相信你已经了解了所有的技术概念，现在我们可以进入下一步，去把一个想法变成一个实际的生产模型。

建模一览

总的来说，构建一个优秀的ML模型，和开发其它产品没什么区别：

从构思开始，你需要用户需求和一些潜在的解决方法进行配对。一旦有了明确的方向，你就可以对该解决方案进行原型化，然后测试它以确定它是否满足你的要求。

之后继续在构思、设计原型和测试之间进行迭代，直到你的解决方案足以投入市场，此时你已将它设计得更为通用。

现在我们来看看每个阶段的细节。

由于数据是ML的组成部分，因此我们需要将数据，放在本产品开发过程的上游，新流程如下：

• 构思能力：定义需要解决的关键问题，以及解决问题所需的输入数据／特定指标。

• 数据准备：收集数据并整理出有用的数据，以便模型进行投喂和训练。

• 原型和测试：建立一个或一组用来解决问题的原型模型，测试它们执行和迭代的程度，直到一个得到令人满意的模型。

• 产品化：打磨产品并扩展模型和采集数据，以在开发环境中得到有用的输出。

构思

这一阶段的目标是，将模型要解决的关键问题、目标函数和对模型的潜在投入整合一体。

• 找准问题：正如上文所讨论的，机器学习被用于解决一个真正的商业问题。确保你的团队和公司的所有利益相关者，都认同你要解决的问题以及如何使用该解决方案。

• 选择目标函数：根据这个问题，决定这个模型的目标是什么。

• 模型正在尝试预测的目标函数是什么类型的？是否有一些你试图得到的“真相”，你可以通过验证实际数据得出，例如房价、股价变动等？或者，你是否正在尝试查找数据中的模式？例如，将聚类函数分成具有共通点的组？

• 定义质量指标：你如何衡量模型的质量？在没有看到真实结果时，是很难预测可接受的模型是怎样的，但目标的方向性是很有帮助的。

• 头脑风暴：确定哪些数据可以帮助你解决问题/做出决策。

• 最有效的方法是：“这个领域的专家如何处理这个问题？”思考一下，专家的解决方案会用到哪些基础变量/数据片段。

了解商业运营的关键因素，这也是企业/产品人员在此阶段需要参与的重要原因之一。数据团队需要将这些潜在的输入数据，转化为模型特征。

数据准备

此阶段的目标是，收集原始数据并将其作为可插入原型模型的输入数据。

你可能需要对数据进行复杂的转换才能实现。例如，假设一个特征是消费者对品牌的认可度：你首先需要找到，消费者谈论品牌的相关来源。

如果品牌名称包括常用词（例如“苹果”），则需要将对品牌的谈论与日常的对话（关于水果）分开，并通过情绪分析模型运行，完成所有这些才可以开始构建原型。也不是构建所有特征都那么复杂，但有些可能需要大量准备工作。

让我们更详细地分解这个阶段：

以最快的速度收集原型所需数据：首先，确定你的缺失数据（missing data）。在某些情况下，你可能需要分解必要的输入内容，以获得“building blocks”级别的原始数据，或者是对你需要获得替代数据。

不可扩展的方法，如快速手动下载、编写初步爬虫程序或购买数据样本，虽然有点小贵，但也许是最实际可行的方法。

在这个阶段，投入太多精力进行数据采集通常没什么卵用，因为你还不了解数据的有用性，哪种类型是最好的。商业团队的同事应该参与其中——他们可以帮助集思广益找到不容易获得的数据或简单地获取团队的数据（相关业务功能需要依赖于数据需求和组织结构——合作伙伴关系，业务开发或市场营销在这里都可能有用）。

请注意，在使用监督学习算法时，你的数据不仅是为模型提供所需特征;还需要为模型的目标函数提供“实际数据”数据点，以便训练、验证和测试模型。回到房价的例子——为了建立一个预测房价的模型，你需要收集房屋的价格。

数据清理和归一化：在这个阶段，主要责任将转移到你的数据科学/工程团队。

这项重要的工作，需要将想法和原始数据集转化为实际模型输入。需要对数据集进行整理检查和清理，以避免使用不良数据，不相关的异常值等。

数据可能需要转换为不同比例，以使其能更好地和其他数据集一起使用或匹配。尤其是处理文字和图像时，通常需要预处理数据以提取相关信息。

例如，将大量高质量图像输入模型中会导致大量信息可能无法被处理，因此你可能需要降级质量，只使用图像的一部分或仅使用对象轮廓。

处理文本时，你可能需要在决定包含文本之前检测与文本相关的实体，执行情绪分析，查找常用的n-grams（经常使用的一定数量的单词）或进行其他变形。通常现有的数据库就能提供这些支持，不需要你的团队重建，但这也需要时间。

原型与测试

这个阶段的目标是产出模型的原型，测试并对它进行迭代，直到你得到一个能产出足够好的结果，并可以产品化的模型。

• 构建原型：当数据质量达标时，数据科学团队就可以用实际模型开始研究。请记住，在这个阶段中，科学里也有许多艺术。

  
  

  它涉及大量的实验和发现——选择最相关的特征值，测试多种算法等。执行任务并没有那么简单，因此何时能获得，可以投入产品的模型的时间表可能无法预测。有时候第一个算法的测试就能得到很好的结果，有时候你尝试过的所有算法都行不通。

• 验证和测试原型：在这个阶段，团队的数据科学家们，将采取措施以确保最终的模型能够像现在一样表现良好。他们将根据预定义的度量来评估模型的性能，并比较其各种算法的性能，调整影响模型性能的相关参数，并测试最终模型的性能。

  
  

  在监督学习下，需要确定：与实际数据相比，模型的预测是否足以用于你的业务中。

  
  

  在无监督学习下，根据实际问题，有各种评估性能的技术。也就是说，许多问题只要目测结果就够了。例如，在聚类的问题下，你可以轻松地绘制在多个维度上聚类的对象，甚至可以使用媒体形式，来查看聚类结果是否直观合理。

  
  

  如果你的算法是使用关键字标记文档，那么关键字是否说得过去？在标签失败或重要用例丢失的情况下，是否有明显的差距？这并不能代替更科学的方法，但实际上，有助于快速找出改进和提升的空间。这也是眼睛能帮的上忙的地方，所以不要把它（验证和测试原型）只交给你的数据科学团队。

• 迭代：在这一点上，你需要和团队一起决定，是否需要进一步迭代。该模型与你的期望有多大出入？它能否显着改善现有的业务情况？是否有特别薄弱的方面？是否需要更多的数据点？你能想到可以提高性能的其他方面吗？是否有可以提高模型表现的替代数据源？这时候经常需要大量的头脑风暴。

产品化

当你确定模型原型运行良好到足以解决业务问题，并可在生产中启用时，你将进入此阶段。请注意，如果你还没准备好进行完整的产品化，首先你需要确定要模型泛化的范围。

打个比方，如果你的产品是电影推荐工具：你可能只想对少数用户开放访问，但又要为全部用户提供完整的体验，在这种情况下，你的模型需要根据每个用户的相关性，对数据库中的每部电影进行排名。

这是一个完成不同缩放比例的需求，不只是提供仅针对动作电影的建议，而是对所有用户开放访问。

现在，让我们讨论一下产品化模型的更多技术问题：

• 增加数据覆盖：在许多情况下，你的模型原型是基于，比实际作为产品时搜集到的更有限的数据集训练出来的。例如，你可以基于特定客户群，对模型进行原型设计，然后将其扩展到整个客户群。

• 数据收集：一旦你已验证哪些数据对模型有用，你需要构建一种可扩展的方式来收集和获取数据。在原型设计阶段，以手动方式收集数据是非常好的，但是对于实际产品化时，肯定是尽可能自动化的好。

• 更新数据：创建一个随时间更新数据的机制——更新现有值或添加新信息。除非出于某些原因，你不需要保留历史数据，否则系统将需要有“地方”，可以随着时间的推移来存储越来越多的数据。

  
  

  从数据科学的角度来看，如果你改变了基础数据，例如扩大了所包含的客户群数量，你就需要重新训练和重新测试你的模型。在特定数据集上工作良好的模型，并不总是适用于更广泛或其他不同的数据集。

  
  

  在架构上，该模型需要扩展到，在数据更频繁增长时也能良好运行。在电影推荐示例中，会是更多的用户，更多的电影以及随着时间推移，有关每个用户喜好的更多信息。
  

• 检查异常值：虽然模型整体可以很好地扩展，但也有可能存在少数而重要的用户，模型表现得不那么好。

例如，电影推荐可能对大多数用户的普遍推荐效果很好，但对于家长来说，可能显示更多的是儿童电影，因为他们用自己的帐号为小孩子选择电影。这是一个产品设计问题——你需要将给父母的推荐和给他们孩子的推荐分开，但模型并不会告诉你这些。

到目前为止我所描述的是一个概念性的流程。在实际操作中，界限是很模糊的，你需要经常在不同的阶段之间来回反复。你可能会从数据采集工作中，获得令人不满意的结果，然后考虑其他办法，或者将模型产品化时，发现这个模型这么不给力，你又要回到原型设计上去。

外包任务

模型构建，通常涉及到一些非常耗时的任务，比如生成标注数据和测试模型。

例如，将数百或数千个数据点，标注为正确的类别，作为分类算法的输入内容，然后测试分类模型的输出是否正确。设置一个按需的方式，来外包这些任务是非常有帮助的。

在我的经验中，如果你让几个人执行相同的简单任务，并采集更频繁出现的答案或某种平均值，可以从Mechanical Turk（https://www.mturk.com/mturk/welcome）获得不错的结果。

有像CrowdFlower（https://www.crowdflower.com/）这样的平台，可以提供更可靠的结果，但是它们也更贵些。甚至某些任务，需要对执行这些任务的人员进行更多培训（例如，如果任务需要特定领域和/或需要前沿知识），这种情况下，你可以尝试一下诸如Upwork（https://www.upwork.com/）之类的平台。

▍第4部分

机器学习产品团队的角色分工，技能和组织结构

我们讨论完如何从头到尾构建一个模型——现在我们来谈谈，实际上大家要做什么，以及团队的结构该如何运行。

一个快乐的Team

一个“传统”的产品团队，由设计师、工程师和产品经理组成，数据分析师有时会整合到团队里，但通常他们是多个团队共享的稀缺资源。

数据科学正逐渐成为一家公司DNA的一部分，使数据科学家成为产品团队的一个组成部分至关重要，而不是将其视为一个孤立的存在。开发具有业务影响力的模型，需要设计师、PM和工程师、数据科学家持续进行日常合作，就像之前设计师，PM和工程师在创造“传统”产品时一起工作那样。

模型开发中的角色和职责

我们在前面讨论过ML开发流程，现在我们将重点介绍，团队的组成和开发过程中各自的职责。

• 构思阶段：在这个阶段，你需要对问题所涉及领域有深入了解的专家，能阐明可能影响选择/结果的不同因素。例如，如果你正在建立房屋估值，你需要房地产专家，他们知道如何评估房屋价值，以及有哪些因素会对其产生影响。

  
  

  即使你的数据科学家碰巧在这个领域有经验，让来自组织其他部门的（通常是非技术性的）商业专家中，提供新的想法，来检查你的想法，是更好的做法。
  

• 数据准备：这项任务通常由数据科学家来领导，在工程师的帮助下收集数据，构建爬虫，整合API等。产品/业务人员必须高度参与，通过已知相关因素，帮助完成外部数据采集，数据提取等。

• 原型与测试：这主要是数据科学家的工作。产品/商务人士必须密切关注这一阶段，查看结果，并帮助判断模型是否具有商业意义，或是否需要进一步迭代。

• 产品化：这需要结合数据科学与编程。基于对数据的要求和来源不同，数据收集的工作会有很大的差别。如果使用外部数据，你可能需要通过构建爬虫来收集数据，这些数据需要前端知识，调用各种API或从各种反馈和合作伙伴（后者主要是后端任务）中获取数据。

  
  

  还需要扩展数据清理，这很大程度上也是后端任务。工程师还要和数据科学家合作，以确保模型规模化，并验证实际工作中的结果质量符合要求。

• 整体系统架构：确保你的数据和模型的整体系统，支持你的业务需求，需要具有架构和扩展复杂分布式系统经验的工程师，至于复杂程度则取决于你要完成的任务。

数据科学家团队的构成

数据科学是一个相对较新的领域——它以新的方式将各种现有领域融合在一起。直到最近，还没有一个“数据科学”学位（即使它现在还不普遍），所以人们倾向于有着各种相关学科和领域的背景。

比较重要的学科有统计学、计算机科学（有或没有侧重人工智能都行），经济学或计量经济学。

复合的背景和技能，对于一个团队来说非常有用——他们每个人都会为团队带来不同的东西。尤其是如果你处于需要大量新思维的新兴领域，结合不同背景往往会产生不同的解决方案，就同一问题产生更多创新的解决方案。

数据科学家对不同工程师的依赖程度有所不同。以前工程师通常能够完成端到端的工作，从原型到部署生产中，无需其他支持，而其他人则需要工程师团队的更多帮助。

根据你们工程师团队的可用性和组成，你可能需要或多或少更独当一面的数据科学家。另一个考虑因素是领域问题——例如，计量经济学背景对于自动驾驶汽车而言，还没有对智能选股软件更对口有用。

一个实际有用的数据科学从属组织架构

工程师、产品和数据科学之间有密切的联系。传统上，倾向于让数据科学向开发工程师汇报，然而随着数据科学在组织中作用的提升，新的组织架构正在成形。

我知道有三种不错的主流组织架构，每种组织架构都有自己的优缺点。

• 第一种——数据科学向开发工程汇报

让数据科学向工程开发汇报，使各学科之间实现完全一致，并不需要在数据科学和工程技术之间划分明确界限。

许多与数据科学家合作的工程师，对这门学科变得非常好奇，并想要进一步提高他们的能力——我看到工程师们对像自然语言处理（NLP）领域十分感兴趣，而其他人，则为了有一天能成为成熟的数据科学家而选择了ML课程。

团队之间的边界越少，可以帮助增加团队中能够完成端到端工作的数据科学家/工程师数量——构建模型并完成代码。有利于职业发展、绩效评估等问题，直到人们涉足不同的领域，决定是否要转型是很容易的。

这种组织架构还有助于简化整个系统，从数据科学用于原型设计的ML框架，到工程师团队完成的产品化系统和架构。它还有助于确保，ML框架和系统架构得到应有的重视。

• 第二种——数据科学从属于产品

由于产品需是数据科学项目的决定性因素，因此将数据科学从属于产品部门可以保障业务目标和可交付成果的一致性。基本上，产品主管对所有数据科学项目和活动都有高级别能见度，并可以帮助他们确定优先级，来确保其推动业务成果。

这也有助于促进产品和数据科学之间的紧密合作，这至关重要。这个先决条件是，了解数据科学和产品如何共同合作，并不仅仅致力于开发产品，这需要具备开发北京，又懂数据科学基础的产品人。

• 第三种——与产品和工程分离的数据科学

这有利于提高数据科学团队的影响力，并使整个组织更易运作。允许数据科学团队负责人，直接了解组织中的高层战略决策，并确保考虑所有业务利益相关者的意见和需求。

这不是唯一“正确的答案”——一切都取决于你的组织，你的目标和你的团队和团队领导力。根据经验，联合汇报通常会使团队之间形成更好的一致性，在团队层级最高处留一个决策者。

想想你的组织中哪些方面，更容易产生沟通和协作障碍，让这些团队向同一位执行官报告。

接下来，请期待黄金手册（下）：机器学习产品的用户体验。

★推荐阅读★