如何设计和管理AI产品?

什么是AI和ML？为什么AI产品管理比一般软件更困难？

在《AI 开发指南：机器学习产品是什么？》文章当中，我们讨论了管理AI产品所需要的基础认识和挑战。

对产品经理(PM)来说，AI或ML(机器学习)产品管理比一般软件更具挑战性，因为它涉及更多的不确定性。不仅需要技术上的改变，还需要组织上的改变。

简单举例说明，如果你想教机器识别猫。

透过软件工程，你可能会列出像是「一只猫有四条腿和两个尖尖的耳朵」这样的规则。规则越明确，越完整越好，因为机器必须依赖这些规则来做出判断。

相反，如果你使用深度学习，要做的就不是提供明确的规则。而是要为机器提供一堆照片（事先标记好哪些是猫，哪些不是），然后建立ML模型或神经网络，让机器自行学习，摸索出规则。

（source: IBM Research Blog）

你和你的团队要做的是：定义问题，准备数据，建立机器学习模型，反复测试和调整，直到你拥有可以提供所需结果的模型为止。

正因为开发ML产品需要更多的反复试验，作为一个PM，你需要给工程师和数据科学家更多的空间和时间去探索。

但是你如何帮助你的团队应对不确定性？如何在明确定义问题和衡量成功标准的同时，又给团队足够弹性进行实验探索？

以下这几件事很重要：

一、规划：从明确定义问题开始

ML是一种工具，是达到目标的方法之一。如果你要解决的问题不需要ML，就不应该使用ML。

我们要从确定问题开始：找到有市场需求，技术上可行的客户痛点。先进行市场评估，找出客户需求，接下来则是判断ML是否可以帮助我们解决用户的问题。

机器学习有许多可能的应用，但原则上，机器学习最适合用来进行决策或预测。

我们可以将ML应用分为几种类型：

检测/检查（detection/inspection）：帮助用户识别缺陷或异常，例如银行或保险的欺诈检测，或生产在线的产品缺陷检测。
模式识别（pattern recognition）：帮助用户筛选大量数据。包括推荐，排序，个人化，分类，预测维护，以及人机互动；例如针对Alexa或Google Home等智能音箱进行自然语言处理（NLP）。
高维认知（high dimension cognition）：帮助用户筛选，处理大量高维感官数据。例如：人工智能机器人、自动驾驶汽车。

在以下情况下，你应该避免在产品中使用机器学习：

可以用更简单的规则解决问题。
正在构建的解决方案不需要因应新数据而改变。
无法取得训练ML模型所需的数据。
产品要求高精度，不能容许任何一点出错。
产品需要信息完全透明。

找到正确的问题后，下一个重要任务就是明确定义需求。

开发ML产品是一个需要迅速迭代（iterative）的过程，常会听到有人说「我们先建一个ML模型，再看看结果如何」。但如果跳过了「事前计划」和「定义问题」的步骤，最后可能反而会浪费整个团队大量的时间，而得不到具体结果。

二、定义「目标函数」和「指针」，保留更多空间和弹性

ML产品不需要我们事先编写规则，而是由机器自动从大量的数据中分析规则。

与一般的软件工程相比，它更具实验性及不确定性，所以很难预测哪些方法有效、哪些无效。这就是为什么在决定最终解决方案之前，必须给工程师和数据科学家更多的空间和时间去探索。

作为产品经理，你可以藉由以下方法，帮助团队在广泛的探索过程中保持专注：

1. 定义一个目标函数（objective function）

你的ML模型试图预测的期望结果是什么？或者你还在尝试辨识出数据中的固定模式？有什么「已知事实」（ground truth）可以用来比较模型的结果、并判断准确性？

例如，你设计了一个模型来预测天气，就可以比较预测结果与实际天气数据，来验证模型的性能。

2. 定义性能指针（performance metrics）

如何衡量产品的成败？设置验收标准并不总是那么容易。你会如何比较「翻译模型」和「人工翻译」的准确度？

有时需要先查看模型的初步结果，才能确定标准为何；但最重要的，是尽早开始思考测试标准、并且不断测试模型，直到找出预测结果令人满意的ML模型为止。

3. 尽早并频繁地测试ＭＬ模型（end to end testing）

你可以将ML模型看作一个黑盒子；定义模型的输入和输出，但不一定了解盒子里的神经网络如何运作，这就是为什么尽早、并且尽可能频繁测试很重要。

从简单的原型（prototype）开始测试关键功能，然后进行修改。重点是尽量避免在验证好模型的关键功能前，就试图建构太复杂的解决方案。

但需要注意的是，模型本身的准确性通常并不是最好的衡量标准。

我们必须同时考虑测量精确度Precision（true positives/all positive predictions）和召回率Recall（positive predictions/all true positives）；精确度是「多少个选定项目的相关性」，而召回率则是「选定多少个相关项目的相关性」。

这没有适用于所有情况的经验法则，所以你需要根据用户的案例来决定权衡。

三、从第一天就开始规划你的数据策略

训练ML模型需要大量高质量的数据，在使用大量数据进行训练时，深度学习的性能会优于旧的算法。因此，从第一天就开始计划取得数据的策略和途径就非常重要。

数据可以来自购买、与其他公司合作、从客户那里收集、在内部生成、或是雇用第三方来生成或标记数据。同时，你也需要考虑竞争对手在做什么、客户和监管机构在想什么、以及每种策略的相应可行性和成本。

拟定数据策略的责任不在于数据科学家，而在于产品经理，而且公司高层也需要经过清楚定义的竞争策略。

如果你是一家新创公司，更需要三思而后行：你想进入的市场，是否有产业巨头掌握了大多数数据？

你可能不想在电子商务上与Amazon竞争、或是在位置数据方面与Google地图匹敌。所以，你必须找到目前还没有一家公司能主导客户数据的蓝海市场。

你是否能够建立可防御且可持续的数据管道（data pipeline)？如何遵守用户的隐私政策？如果你的公司在欧盟和其他数据保护法规范围内营运，则必须熟悉GDPR（通用数据保护法规）的规定。

例如，根据GDPR，公司需要确保个人资料不仅是合法收集的，而且要防止他人滥用。因此，作为PM，你需要从产品开发的早期阶段就考虑数据保护措施。

PM必须与ML团队讨论，以确定未来需要什么数据、需要多少数据；同时，也必须让法务和营运部门等其他相关单位参与。

为机器人和自动驾驶汽车等现实世界应用开发ML产品，带来了更大的挑战；所以必须充分利用仿真（simulation）方法、并且注意相关研究领域，包括转移学习（Transfer Learning）和元学习（Meta Learning），以降低对大量数据的需求、并加快模型训练过程。

四、不能只考虑ML

构建ML产品的过程，其实是跨领域的；而且在大多数情况下，我们开发的并不只是ML模型而已。

为了做出完整、可立即投入生产的产品，我们还需要用户接口（UI）、执行模型预测的软件、以及硬件的搭配组合。

如果过度专注于ML模型上，而忽略了用户体验（UX），产品就不会成功。你需要一个不仅包括ML工程师和数据科学家，还包括数据工程师、软件工程师、UI/UX设计专家和硬件工程师的跨领域的团队。此外，还需要与后端工程师合作，以打造出支持ML产品的基础结构。

作为PM，必须尽量减少不同职能或团队之间的相互依赖和冲突。如前所述，ML的性质与一般软件开发完全不同，因此在组织上也应该有所改变。

例如，虽然每日的站立会议（stand-up meetings）可能有助于保持软件工程团队的生产力，但对于ML团队而言，这可能不是最好的时间利用方式。

所以，ML开发不仅仅是技术上的改变，还牵涉到组织变革。

作为产品经理，你可以帮助其他团队了解ML产品在本质上的不同、并协助解决潜在的冲突。

PM与内部团队和客户的沟通也很重要。ML产品的性能，会随着时间的推移而提高。

但这也代表着，客户可能无法在一开始就获得最好的结果——用户可以接受这一点吗？

如何减轻用户的风险、并保证可接受的最低性能？如何设计产品，以降低不确定性、并获得最好的使用体验？

五、投资ML产品的理由

1. 改善用户体验或产品功能

ML可以用来让产品更个人化、或是客制化；例如让用户更容易找到最相关的结果，或是应用ML来提高预测的准确性。这些都是对公司内部或外部用户（客户）潜在需求应用的考虑。

2. 将流程或重复性任务自动化

公司同仁或客户是否需要重复执行一些可以自动化的流程？透过自动执行重复性工作，可以节省时间、成本、资源，甚至创造更好的使用体验。如果流程太复杂，是否可以将部分流程自动化、或帮助用户更有效率地完成工作？Gmail的「Smart Compose」（字句建议）是一个很好的例子：现在，Gmail可以自动帮用户完成句子，不需要每次都手动输入「你好」这类重复的单词或句子。

3. 开创新的商机

是否有新的商机或用户问题，是以往无法解决、但现在可以用ML完成的？例如在仓库中，货物分拣通常需要人工完成，因为很难帮机器手臂编写程序，让它们识别和处理数百万种产品。但是有了ML，机器人可以在最少的人工帮助下，自行学会识别各种物体。ML与人工智能的这种能力，为仓库机器人打开了庞大的商机。

六、有些好的PM直觉反而不适用于ML产品

有时管理软件产品的方法不一定适用于ML产品。

我常会提醒自己以下几点：

必须清楚认知开发ML和软件产品之间的区别，要让单一组织流程适用于所有产品，是不太可能的；必要的时候，你必须调整产品计划流程（sprint planning）、产品蓝图、甚至整个组织。
不需要太详细列出产品需求书（Product Requirement Document）上的所有需求，而要着重于定义目标功能和衡量标准，让ML团队有更多探索和试验的空间。
与其在开发过程开始时向ML团队询问可能结果，不如与团队密切合作，尽早开发和测试产品原型。
ML只是方法之一，并不一定非用不可。