AI 项目落地应用指南 --4. 产品经理的工作挑战（上）

正如 There are a thousand Hamlets in a thousand people’s eyes.一样，对于“产品经理”的职责与定义依然有多种版本的解释，我们来看一下：

在英文 wikipedia 中：

A product manager is a professional role which is responsible for the development of products for an organization, known as the practice of product management. Product managers own the business strategy behind a product (both physical and digital products), specify its functional requirements and generally manage the launch of features. They coordinate work done by many other functions (like software engineers, data scientists and product designers) and are ultimately responsible for the business success of the product.

Definition：A product manager considers numerous factors such as intended customer or user of a product, the products offered by the competition, and how well the product fits with the company’s business model. The scope of a product manager varies greatly, some may manage one or more product lines and others (especially in large companies) may manage small components or features of a product.

在中文 wikipedia 中：

产品经理（英文：Product manager，缩写：PM）也称产品企划，是指在公司中针对某一项或是某一类的产品进行规划和管理的人员，主要负责产品的研发、制造、营销、渠道等工作。产品经理是很难定义的一个角色，如果非要一句话定义，那么产品经理是为终端用户服务，负责产品整个生命周期的人。

产品经理需要考虑目标用户特征、竞争产品、产品是否符合公司的业务模式等等诸多因素。一般而言，产品经理管理的是一个或者多个有形产品。但是，产品经理也可以用于描述管理无形产品如音乐、信息和服务的人。有形产品行业产品经理的角色与服务业中项目总监类似。

产品经理的职责描述目前仍然分歧很多，因人、因公司而异。即使是在相对较为一致的高科技行业，不同公司中的职位描述也是很不同的。但通常认为产品经理的职责主要包括：产品经理负责调查并根据用户的需求,确定开发何种产品, 选择何种技术、商业模式等。并推动相应产品的开发组织, 她或他还要根据产品的生命周期,协调研发、营销、运营等,确定和组织实施相应的产品策略,以及其他⼀系列相关的产品管理活动。

在百度百科中：

产品经理（Product Owner）是企业中专门负责产品管理的职位，产品经理负责市场调查并根据产品、市场及用户等的需求，确定开发何种产品，选择何种业务模式、商业模式等。并推动相应产品的开发组织，他还要根据产品的生命周期，协调研发、营销、运营等，确定和组织实施相应的产品策略，以及其他一系列相关的产品管理活动。

定义的百家争鸣与无法取得共识也从侧面印证了产品经理是一个极具挑战的岗位，虽然“人人都是产品经理”，但优秀的产品经理实际上凤毛麟角。本文并不打算全面的讨论产品经理工作内容与职责，仅从 AI 产品落地这个视角来探讨产品经理的工作难度与需要面临的挑战。此外，对以下两种产品经理对工作模式，也不在本文讨论范围内：

• “对标”友商产品，做像素级功能“复制设计原型”的产品经理

• “老大”提要求，就按要求做产品设计；老大没要求就不知道怎么做产品设计的产品经理

注：构思本章的内容安排，卡了两天。一方面觉得有关产品经理的工作内容和思考方法可以说的太多，很难在较短篇幅内做取舍；另一方面，“产品思维”是一个很大的话题，从逻辑思辨到人性把握到商业伦理这些“高深”的知识都与产品经理的思想高度与产品思维体系建立相关，很难用简单的文字体系化的说清楚到底什么是“产品思维”；第三，事实上大多数公司对于“产品经理”的认识与要求还是较“低”的，而建立成熟培训体系的则更少。所以，纠结于写的太深，会引起“故弄玄虚”的效果，写的太浅，于事无益，对于大家可能并不会有多大帮助。最后的决定是：为了整体进度，先阐述本人的关键认识完成本章，根据反馈（如果有的话）后期再重构本章的内容。

开胃菜

在正式开始之前，我们来看两个简单的 DL 产品的例子。

用户现有系统是在居民身份证数据库中检索某人的身份证信息：

query(‘姓名’)，高概率有重名，结果不唯一；

可以 query(‘姓名’&‘身份证号’)，有小概率结果不唯一；

进一步 query(‘姓名’&‘身份证号’&‘户籍地’)，那么只有极小概率结果不唯一;

上述的这种结果不唯一，可以通过增加查询条件过滤，实现精准查询，且结果不唯一的原因是“可解释”的，如果出现查询返回结果错误，那么我们可以很快定位其原因：查询条件输入错误还是数据库信息错误。

用户提出需求，录入查询信息太麻烦了，你们不是有人脸识别么，用人脸来查询多方便。

作为产品经理，评估这个需求，需要考虑哪些问题？

1. 返回的结果在 Top5，但不是 Top1，如何解释比较合理，交互和页面如何设计比较友好、直观；

2. 与“底图”年龄跨度大之后的精度是否满足；

3. 小孩的人脸识别准确度是否满足；

4. 现场摄像头怎么安装，光照条件有没有干扰；

5. 是不是可不去做“为了 AI 而 AI”的事情，建议用户装一个“二代身份证读卡器”解决输入问题；

上述“人脸”这个场景，算法出错的导致的“后果”可能没有太强的“感觉”，因为结果即使出错也没有较大“副作用”。那么我们把场景换一下，换到医疗的 X 光片或者 CT 的“AI 肿瘤识别”产品场景。

首先需要明确的是：这个场景下，DL 出错是要“死人的”，产品经理需要考虑什么？

1 - 理解算法指标的“查准”与“查全”；

2 - 理解“漏报”的代价；

3 - 理解这种“小负样本”数据集对于模型训练精度的影响；

或许有“机灵”的产品经理会说，我们的“AI 肿瘤识别”仅仅是辅助手段，还是建议专业医生对结果进行复核，这样就能规避算法错误后的法律风险。但是，如果算法不能做到“判断没有肯定没有，判断有不一定有”这个结果，不能协助医生筛选出一部分“肯定可以”不需要人工复核的数据，AI 的意义何在？

所以，这也是目前“人脸”能大规模落地“医疗”很少有听到落地的最核心的原因所在：对于误判“会死人”的场景，大家都是极其慎重的。所以某独角兽曾经有段时间在拿到一轮投资后高举 AI 医疗方向的大旗，然后落地做的还是智慧城市的事情就比较好理解了。

希望开胃菜有助于各位理解在产品层面引入了 DL 之后，给产品经理工作带来的挑战性这个话题。

挑战一：理解技术

一直在反复说这句话：AI 或者机器学习技术，是一门综合的边缘技术领域，涉及到多种技术的交叉，做为参与者如果对于相关技术基础没有概念，那会很难去顺利、准确的开展工作。一般情况下，对于产品经理的技术背景并没有“强烈”的要求，没有技术背景并不会是“硬伤”。当引入了深度学习之后，需要产品经理理解深度学习技术基本原理、了解不同任务领域的发展现状及 SOTA、理解制约深度学习发展的因素、理解数据集对于深度学习的重要性等。

过去产品经理设计产品 functions 只需要明确输入/输出/交互/UI 的要求，代码实现只要没 Bug，那么一个 function 在同样的输入情况下，运行多少遍，结果都是应该可预测和一致的（可以用“函数式编程”的思想来类比理解下），但是当输入/输出之间是 DL 算法时，严肃的新问题就来了：结果是一定概率下的准确，且对于结果的错误难以预估与解释。当然 Grad-CAM、Grad-CAM++给我们提供了更好的 CNN 模型预测的视觉解释性，但是我们依然无法解释“为什么会是这个结果”。

正是这样一个结果“不确定性”的因素的引入，就需要产品经理能够去在一定程度上去理解深度学习，最好能去动手做一些简单的分类任务，去理解机器学习、深度学习、CNN、RNN、LSTM、GAN 等常用的基础知识。只有在理解的基础上，才能对“不确定性”有一定的“定性”的理解，而这些理解，才能更有助于产品经理去判断需求的可实现性、对错误的容忍度以及如何去理解场景（尤其是 CV 类）与边界条件等等。接着“开胃菜”的“AI 肿瘤识别”产品来说，产品经理如何去理解这句话：“判断没有肯定没有，判断有不一定有”。

这句话的表达的意思是：如果模型判断没有恶性肿瘤，那么判断的准确性是 100%；如果模型判断有肿瘤，则不一定真的有。如果还觉得理解有困难，用大白话翻译就是：“宁可错杀一百，不可放过一个”。懂了么，要想深度学习“可信”的参与医疗领域落地，对模型的技术指标要求之一就是“可以错判，但不能漏判”。要理解这句话背后“隐藏”深度技术知识，就要从最基本分类评估的混淆矩阵开始。

“炼丹师”、“调参侠”对这个混淆矩阵的含义是非常清楚的，以防产品经理有不清楚的，简单解释下基本术语。假设我们的分类目标只有两类，计为正例（positive）和负例（negative）分别是：

1. True positives(TP): 真正例。被正确地划分为正例的个数，即实际为正例且被分类器划分为正例；

2. False positives(FP): 假正例。被错误地划分为正例的个数，即实际为负例但被分类器划分为正例；

3. False negatives(FN): 假负例。被错误地划分为负例的个数，即实际为正例但被分类器划分为负例；

4. True negatives(TN): 真负例。被正确地划分为负例的个数，即实际为负例且被分类器划分为负例。

对于分类准确性的度量指标常用的有以下几种：

1. 正确率（accuracy）

2. 最常用的评价指标，正确率是被分对的样本数在所有样本数中的占比，通常来说，正确率越高，分类器越好。accuracy = (TP+TN)/(P+N)，

3. 错误率（error rate)

4. 错误率则与正确率相反，描述被分类器错分的比例。error rate = (FP+FN)/(P+N)，分对与分错是互斥事件，所以：accuracy = 1 - error rate。

5. True 灵敏度（sensitivity）

6. sensitivity = TP/P，表示的是所有正例中被分对的比例，衡量了分类器对正例的识别能力。

7. 特异性（specificity)

8. specificity = TN/N，表示的是所有负例中被分对的比例，衡量了分类器对负例的识别能力。

9. 精度（precision）

10. precision=TP/(TP+FP)，精度是精确性的度量，表示被分为正例的样本中实际为正例的比例。

11. 召回率（recall）

12. 召回率是度量有多个正例被分为正例，recall=TP/(TP+FN)=TP/P=sensitivity，可以看到召回率与灵敏度是一样的。

13. F1-score

14. 也称为综合分类率，综合考虑查准率与查全率：

我比较喜欢用“话糙理不糙”的比较接近“人类”语言的方法去解释一些东西，上面这几个指标的含义可以这么理解。accuracy：预测和实际一致的水准；precision：预测是正例中真的是正例的水准；recall：实际的正例被准确预测出的水准，所以，precision 一般称之为“查准率”，recall 一般称之为“查全率”。如果还不理解，那么建议你去看看 Google 机器学习速成课程，有中文版，而且图文并茂解释的通俗易懂，确实是入门好课程。

说了这么多，就为一件事，假设我们有三个 models，其查准与查全指标如下表。

怎么选？“科学”的建议肯定是算 F1-score，哪个高用哪个,如果真是这样，我费力码字是为什么？回头再来看看之前提到的“AI 肿瘤识别”例子中的一句话“判断没有肯定没有，判断有不一定有”。如果我们把“有恶性肿瘤”定义为正例（Positive），那么这句话就可以翻译成：对 FN 的期望为 0 的基础上 Precision 越高越好，FN 如果为 0，那么 Recall=1。所以在这个场景下，我们选择模型的思路是 Recall 最高的情况下选择 Precision 高的，而不是去用 F1-score 求综合最佳。

理解了么？再用大白话解释一下。这个场景的分类任务，模型一旦预测错误，结果可能会“死人的”，所以，“漏报”是不可接受的，“漏报”在上面的混淆矩阵中就是出现了 FN（假负例），所以我们希望 FN 越小越好，理想值为 0 。所以在上面的三个模型中，显然我们应该考虑使用 Model 3，而不是 F1-score 最高的 Model 2。而且，后期我们优化方向应该是优先解决 FN 下降的问题。

一句话总结：F1-score 是学术界为了综合评估模型的一个指标，在我们实际业务场景中，产品经理一定要能判断对模型的需求是查准还是查全，千万不要教条主义。

有人可能会有疑惑，这些内容不应该是 ML Researcher、ML Engineer 去考虑的么，为什么需要产品经理去理解这些技术细节？

从工作分工来说，产品经理要确定业务场景以及对模型指标要求的大致范围，所以产品经理至少需要明白：

• 错误预测带来的风险有多大；

• 业务场景的需求是“准”还是“全”，其中哪一个是关键指标，可接受下限是多少；

• 如何去和用户沟通“准”和“全”之间的“跷跷板”关系，让用户理解这种“不完美”的结果已经是现阶段最佳；

• 模型训练阶段，通过误差分析，定位到数据集的问题，是否能够理解并与用户沟通“脏数据”的问题；

• 产品立项阶段，能否客观的预估出一个合理、可实现、可接受的性能指标；

顺着这个思路，做智慧城市、公安图侦的产品经理，琢磨下 ReID（行人重识别）这个刚需和不同场景的人脸呗。

如果产品经理对于机器学习的技术难度、原理与 SOTA 没有一定认识，那么对于和 ML 结合的需求评估和分析，如何才能保证准确、无偏差并且没有“不当承诺”？

比如，你是“人脸独角兽”之一的产品经理，去做用户需求调研，用户说“你们公司人脸那么厉害，给我们做个 ReID 吧。”你一听这东西公司有小组在做啊，肯定没问题，果断答复没问题，可以做。用户说，人脸你们准确度都 99%不止了，这个准确度做到 98%没问题吧。怎么回答？

说，没问题。那你就是“真傻”，不当承诺的后果，就是回公司之后，给“科学家”们一顿“怒怼”。

说，不知道能做到多少，让客户等下，你出去打个电话问问。

说，估计 98%有点悬，目前主流的 ReID 数据集是 DukeMTMC-reID 和清华大学的 Market-1501 数据集，数据集都不算太大，而且也没有实战中需要考虑的“换衣重识别”等场景，在这个上面先在最好的 mAP 是……，top1 是……，top5 是……，这已经是实验室的最佳水平了，我理解的 ReID 这个事情比人脸识别难度大在于以下几个方面“……”，考虑到实际现场场景肯定比校园校园复杂，指标肯定会下降，但是具体能到多少我也说不好，要回去请教科学家们，要不给我拷点咱们的视频，我回去安排做个测试，结果出来给您个准确数字。

哪一个答复最好？显然是最后一个，一方面体现了专业性，一方面体现了严谨性，运气好还能给公司带回去一批数据，即使你给不出用户想要的数据，用户也是会相信你不是在“忽悠”。有关此部分需求沟通对内容，会在第五章再补充。

软件部分对需求，不管多离谱，理论上都是时间和成本对问题，不能实现的可能性并不高；但是机器学习领域的需求，在现阶段，确实还存在“给多少钱也搞不定”的情况。所以，产品经理要能够比较得心应手的做好需求管理工作，一定要有一些相关技术背景知识。

有关为什么需要 ML 产品经理具有一定的技术的背景的原因，暂且到此，不再继续展开。

挑战二：场景理解、业务抽象

在讨论场景理解之前，先说一个工程领域的 Fail-Safe 机制。Wikipedia 的解释为： In engineering, a fail-safe is a design feature or practice that in the event of a specific type of failure, inherently responds in a way that will cause no or minimal harm to other equipment, the environment or to people.简单来说就是：故障不可避免，重要的是故障之后保证安全。Fail-Safe 的机制放在机器学习的落地应用设计中，应该会这样考虑：预测错误不可避免，重要的是预测错误后代价可接受。

考虑到 ML 领域大多都是计算机、CS、自动化等专业技术背景居多，对于工程的概念可能不多，举一个可能天天都在接触的场景的例子来加强理解。大多数公司的玻璃大门都用的“电磁锁”，可以很方便的和刷卡、指纹等门禁系统集成。有没有人考虑过一个问题：如果停电了，这个电磁锁是什么状态，开锁还是锁止？按照消防要求，这种电磁锁一般都是失电开启。你想啊，大楼有火警、同时也停电了，你公司的大门打不开了……这多可怕，所以“Fail-Safe”机制一定是失电开启才安全。那么对于非火灾等意外状态下的失电情况下，这种锁岂不是就没有安全性了？所以“Fail-Safe“机制是，在安装的时候配一个小 UPS 电源来应对意外的停电情况，保证门是锁止的。如果长时间停电，UPS 还是会没电的，这种情况怎么办？答案很简单：“铁将军”上场，回忆下是不是每次放长假的时候，行政小姐姐是不是都会最后走，给大门挂上“铁将军”（或者给加班的小哥哥卖个萌，让他走的时候一定帮忙锁好门）。

这种设计，就是典型的 Fail-Safe 机制：失电 --> UPS 后备供电 --> UPS 失效 --> 门锁开启。

正是因为这种 Fail-Safe 机制的设定，考虑的是故障后门可以打开保证人身安全，所以不能考虑财产安全，这种门锁也只能应用于写字楼的办公场所，因为写字楼有物业和保安，故障失效后的安全保证还有这一道防护。

现在是不是对于工程领域的 Fail-Safe 机制有点概念了？有人或许会疑惑，难道没有机器学习的时候，软件系统就不需要关注这个问题么？当然需要，但是没有深度学习的时候，Bug 除外，程序本身的运行是鲜有故障的（比如内存泄露，爆掉了，所以 C/C++难啊）。故障一般都出现在操作系统、网络、服务器、存储层面，所以我们会有负载均衡、主从、集群、高可用、故障自动转移、RAID、多链路、冗余、两地三中心等等这些耳熟能详的“容灾”策略。当然，这些都不在本文的讨论范围内，本文仅关注“机器学习推理错误”之后的处理策略。

回到“开胃菜”的两个简单应用场景讨论，来分析下“理解场景”有哪些难度。

对于“人脸识别”技术来说，不论是 SDK 还是 Serving 系统提供 APIs，对于业务系统来说“看起来”就是一个需求确定之后的调用问题，并没有什么特别之处。回顾下在第一章中引用的一张图片。

这个场景的需求，可以用一句话描述：行人闯红灯抓拍后，通过人脸图片查询身份信息，分别推送人脸图片、全景图片与身份信息（部分隐藏）到大屏显示，起到警示教育作用。

图片的“人工智障”效果就是“按照需求”设计产品，并没有对场景进行分析与推敲，更没有对边界条件与推理错误的后果进行评估与处理。从结果看，技术没问题：要人脸检测，检测到并且推送了；错在产品对场景理解不足，事后诸葛亮的详细分析下。

1. 指标选择。这个场景就是人脸检测任务，SOTA 精度足以满足这种场景使用，检测结果也不需要做为输入去触发其余业务系统，所以在算法层面，选择 F1-score 最高的检测算法足矣。

2. Fail-Safe 机制。由于此系统的使用是公众场合，产品经理“应该”预计到误报之后的结果有可能变成新闻热点，进而影响公司技术形象。为了避免“误报”，应该要求后端业务系统设置一个较高的“置信阈值”。

3. 异常分析。场景需求是对“行人在斑马线闯红灯”抓拍，那么检测区域是“斑马线”，检测目标是“闯红灯行人”。检测区域可以通过代码来控制，能够规避异常状况。如图，公交车身广告的“人脸”在红灯时段出现在“检测区域”，所以检测到后做了展示推送，这属于一种异常，产品经理首先要预估到这种异常可能，另外要给出这种异常的处理方案。同理，可以“预测”某人拿一个有人脸广告易拉宝之类的东西闯红灯，显然也是会误报一张人脸的。去研究这些肯能存在的“误报”情况，可以提取出一个共性：非活体人脸的误报。

4. 边界分析。基于对异常对分析，那么似乎把检测边界设定为：斑马线、闯红灯、活体、人脸更为合理。

5. 技术方案。在这种非约束场景下，如何做活体验证？支付宝之类的眨眨眼、扭扭头，显然不可能了。那么加一个目标检测呢？如果检测到有汽车，然后人脸坐标落在汽车对 Box，则认为是异常。这样是可以屏蔽上图的错误，但，如果恰好有人闯红灯，身后通过一辆公交车，这就要漏报了。有没有更好但方案呢？应该有。行人闯红灯过马路，这是一个连续的动作，而非静态动作，而且这个时间长度是几秒以上，我们可以从这里下手。一是可以考虑增加“姿态估计”的联合判断，找到“人体”，通过姿态估计判断是在行走，再去检测人脸；二是可以考虑“轨迹”，检测到第一张人脸后不做推送，而是继续检测，如果连续检测到同一张脸（1:1 的识别，计算量也不大，边缘设备也能搞定），而且，计算坐标后可以判断是“过马路”行为，那么再去推送（公交车是横向移动，并非纵向移动），但这种处理，是无法解决“易拉宝上但人脸问题”，所以最优解应该还是考虑姿态估计。还有一种可考虑的方案就是引入深度信息，进行多模态方向的人脸识别。

6. 考虑到还需要检索身份信息，这个 1:N 的人脸任务并不难，但是产品经理需要明确的是底库的库容多大，是百万级还是千万级还是亿级。另外就是要和用户约定好查询返回为空的时候，显示的占位信息是什么。这种小细节最容易忽视，都不提，程序猿小哥哥顺手给你返回个“未检索到记录”怎么办？

所以，通过场景分析，对于这个“行人闯红灯抓拍”项目，我更倾向于将这个项目需求定义为一个“姿态估计+人脸检测/多模态人脸识别”任务。