首先也需要有学习的过程，需要事先知道一批水果是苹果或者梨；然后把这批水果分成两部分，第一部分用来训练我们的识别模型（即学习的过程），另一部分用来验证（可以认为是考试）；当我们验证的效果高于某个值，比如准确率达到99%，我们就可以认为这个模型有效，这个模型就可以后续用来识别苹果或者梨这两种水果了，监督学习的特征在于我们事先知道了一些水果的分类；上述的产品基本都属于监督学习。

无监督学习：无监督学习以聚类为主，比如有两棵树，一棵苹果树和一棵梨树，工人采集完水果之后就随便扔到了树下，这时候要对树下的水果进行分类；由于工人是随便扔的，那么苹果肯定离苹果树比较近，梨离梨树比较近；我们不需要知道水果长什么样子，也不需要知道他们长什么样子，只要算一下水果之间的距离，就可以把水果分成两堆；对于无监督学习，我们并不知道他们的特征，而是依靠他们之间的关系来判定的。

增强学习：阿尔法狗（就是打败柯洁的那个）就是用这种算法的，但是具体比较复杂，有兴趣可以自行了解一下。

为什么人工智能要用这些技术，我们以人脸识别为例，你为什么能识别出一个人？首先你肯定要见过，并且留下过比较深的印象；然后再次遇到的时候，你就会将遇到的人和脑海里的人进行比较，然后达到一定相似度的时候，你就会认出这个人是谁谁谁。

这个过程分为：认识-记忆-遇到-比对-识别，那么对应过来，监督学习的样本可以认为是认识的过程，训练模型就是记忆的过程，为了防止记忆有问题，我们还加了一个验证的过程；最后就是遇到，然后比对和识别，整个流程是类似的；人尚且会认错人，那么模拟人的识别而仿造出来的系统会出错自然也就不意外了。

回到我负责的产品，是一款NLU产品，NLU全称叫自然语言理解，“自然语言”就是指我们说的话；每个人习惯不同，知识水平不同，说出来的话也不同；比如说表达喜欢的话，普通人就一句“我喜欢你”，夏目漱石就会说“今晚月色真好”。

这种表达不同带给产品的就是：对于单独的一句话，可以确定它的意思。但是对于表达同样意思的所有话，不敢保证所有的话都能被识别出来，因为无法穷举或者明确定义，所以会带来不确定性。

二、产品定义的确定性

智能产品的不确定性是天生的，产品经理有义务从自身的系统搭建去尽量减少这种不确定；这种在产品上能做的，首先就是要通过明确产品的定义，从根源上尽量减少不确定性。

以上面的例子来说，“今晚月色真美”这种例子会被杜绝在外，首先是受众上而言，大部分人不会用这种表达方式。

其次，存在歧义，这句话明面上就是夸奖月色的，深层次才是表达喜欢的；所以这种有歧义的，在定义上的就需要杜绝。

那么回到普通的喜欢，通过研究可以发现，句式一般是“人名（包括代词）+喜欢（或者爱，或者养）+人名（包括代词）”；这个就是对于喜欢的定义，这个定义可以指导后续的样本的选择，样本的选择和标注对于后续模型的训练是非常至关重要的一步，直接决定了模型的成败。

智能产品有时候可以找到官方的定义，这时候就可以直接应用，比如说火车号，火车号是有准确定义的，参考如下：

高铁：G1-G9998、C1-C9998、D1-C9998、Z1-Z9998、T1-T9998、K1-K9998

普通火车：1001-5998、6001-7598、7601-8998、Y1-Y998

高铁：G1-G9998、C1-C9998、D1-C9998、Z1-Z9998、T1-T9998、K1-K9998

普通火车：1001-5998、6001-7598、7601-8998、Y1-Y998

如果没有明确的定义，那么就需要自己抽象出产品的定义，用于指导后续的流程，有以下几种方法：规则法、范围法、枚举法，下面一一叙述。

1. 规则法

上面描述的“我喜欢你”的定义，就是规则法的应用。规则法有两步：收集样本、归纳规则。

再举一个例子，比如说什么是地址，这个乍一看，大家可能都比较好识别，但是怎么描述地址呢？我找了一圈也没有找到官方的定义；所以我就跑到出现地址的地方，比如地图、美团等应用，收集了周围的地址，然后可以总结出来规则的一般形式有以下几种：

1）长地址由以下的组成：

• 可以有 xx省、xx自治区、xx特别行政区或者没有；
• 需要有 xx 市；
• 可以有xx区、xx县、xx市或者没有；
• 可以有xx镇、xx街道或者没有；
• 可以有xx村、xx乡或者没有；
• 需要有xx街 或 xx路 或 xx道 或 xx巷 或 xx弄 或 xx园；
• 需要有xx号；
• 可以有 与xxx（比如与海德二路交汇处） 或 xx号；

2）特殊位置（工厂、工业园、产业园、科技园、科学园、公园、写字楼、小区）。

注意有一点，规则法的重点在于定义的范围是准确的，求准不求全；规则法得来的定义，通常都是不完整的，不过没关系，这个定义在后续的执行过程中，都可以随时更新的。

2. 范围法

范围法的运用在智能产品的定义可能比规则还要宽泛，规则的难点在于怎么抽象，而范围法在在于怎么划定最终的范围。

举个简单的例子，我们要识别餐馆，这个东西的定义就感觉完全找不到头脑；“小炳胜”可以是一个餐馆（当然也可能是人名），“张三饺子”也可以是一个餐馆，这个完全没有规律可言，这时候可以从整个流程的末端入手。

识别是我们最开始的目的，我们最终的目的其实是为了提供给用户对应的内容或者服务；对于餐馆，我们提供内容其实是餐馆的详情，比如餐馆的评分啦，地址之类的。这些评分从哪里来呢？美团，大众点评都可以。

那么现在问题就比较简单了，我们直接将前后两个环节串起来，“餐馆”的定义就可以定义成“大众点评下美食类目下的店铺”，定义简单明了；后续需要验证也比较简单，直接去大众点评搜索一下就可以了。

3. 枚举法

枚举的意思是，针对有限的个数的类别，可以把这个类别的所有个体一一列举出来，这个叫枚举；比如，请枚举10以内的自然数，那么答案就是：0/1/2/3/4/5/6/7/8/9。

枚举法在智能产品里用到得比较少，不过我也用过；我们有一次遇到的情况是要识别我们内部自定义的一个新品牌，这时候我们就直接把品牌名称当成特征给到模型，定义也很简单，就是包含品牌名字时，我们都认为符合产品定义，然后就突出对应的百科介绍。

枚举出来的当然非常识别率非常高，不过相对应的适用范围也比较少。

三、样本标注的确定性

产品定义完了，和开发测试进行评审，大家达成一致，就可以开始继续往下的工作了。前面讲了，很多智能产品都是监督学习，依赖已经知道了分类的样本。

那么怎么才能知道这些分类呢？

答案就是人工去标注，然后把标注完的结果给机器，相当于给机器一个受教育学习的过程；所以人工标注得好不好，决定了模型学习得好不好；就好比，你如果告诉学生“烧杀抢掠”是美德，那么他们就很大可能会变成流氓恶霸；如果告诉他们要做“谦谦君子”，那么他们就会变成另外一副模样。

下面讲讲怎么保证样本标注的准确性。

1）产品定义

样本的标注，通常会有一个标注团队，这是智能产品团队的标配；如果没有专门的标注团队，那么通常是由测试兼任。

由于产品定义和标注不是同一个人，所以就要求产品定义要非常清晰，准确，可以用于指导标注工作的进行。

产品定义的时候，可以和团队的其他成员充分讨论，特别是之前有过相关经验的同事，可以查漏补缺。具体可以参考前面【产品定义的准确性】的相关内容。

2）澄清评审

和其他需求一样，定义完之后也需要有一次正式的澄清，或者叫评审；澄清的目的是为了给大家讲清楚产品的定义，在讲的过程中，相关的成员会比单纯的看感受更深，更能激发讨论；澄清的时候，可能还有引起一波新的讨论，讨论越多，对于产品的定义就会更加清晰，团队也更加能达成共识。

3）样本采集

明确了标准之后，还缺失一个东西，样本的采集。

通常来讲，一个品类至少要有50个以上的样本，才能用于训练；当然更好的是可以达到100个以及以上，视不同的情况而定，这个通常会由算法工程师给出来。

那么这些样本从哪里来呢？

一个是研究机构公开的样本库，通常是国外机构官网可能会有，可以谷歌一下；不过学术领域和工程领域的差别有点大，不一定适用。

第二个是其他机构的售卖，这种可以走商务关系进行联系。

第三种就是自行爬虫爬取，通常是工程师根据产品的定义去爬取，然后清洗，最后形成可用的样本。

4）预标注

标准有了，样本有了，还需要先进行一轮预标注的过程；预标注可以先每种类别选取10个左右的样本，先进行标注，用于讨论用；这个环节的作用在于，有时候我们觉得我们已经知道了，但是真正开始上手的时候，才知道自己的无知，这个就是为了预防这种情况的出现；先标注一部分，然后和团队讨论，防止标注团队在错误的道路上越走越远，最后一发不可收拾，这个就是这个环节最大的作用。

5）充分讨论

针对预标注的结果进行讨论，首先产品肯定需要校验是否符合自己的定义，其次，开发也可以从第三方视野给予建议和意见；还有就是前面说了，除开官方的规则定义，其他规则都是保准而不保全，那么就有可能有一些漏掉的，或者模棱两可的地方；这个时候就可以统一讨论清楚，大家明确了共识之后，该更新定义就更新定义，该继续标注就继续标注。

6）二次标注

为了节约时间成本，第二次标注就可以进行全量标注了；有了预标注和讨论之后，第二次的标注普遍会更快更准。

7）抽样验证

针对全量标注的结果，产品经理还是需要进行抽样检查，如果发现抽样的结果，比如抽查了10个，发现很多都标注不准确，这时候就需要打回去重新标注；如果标注结果没什么大问题，就可以给算法工程师进行模型训练了。

8）样本充足

最后需要注意的一点是，前面讲的50~100是一次训练的样本量，如果模型需要经过几次的迭代的话，每次都需要这么多样本量；因为如果每次都逮着一批样本的话，可能会造成一种“过拟合”的现象，就是说模型针对这一批样本，效果非常好，但是却丧失了普遍性，导致对于其他样本结果很差。

就类似如果对学生过分强调数学的重要性，有可能就会造成学生偏科一样；所以样本的数量要充足到可以支撑整个模型训练的全过程，保证最后的模型具备普适性。

四、模型指标的确定性

智能产品没正式上线之前，谁都不知道具体的效果会怎么样。唯一知道的就是模型的指标如何，模型指标和上线标准是必要但不充分的关系；也就是说，模型指标好，上线效果大概率好，但是也可能不好；但是如果模型指标不好，那么上线效果一定会差。

智能产品的模型一般有几个指标：精确率（precision）、召回率（recall）和F1值（F1-Measure）【1】。

• 精确率可以定义为查准率，比如想要预测景点，那么就需要拿预测为景点并且真的是景点的样本数量，除以预测为景点的样本数量。
• 召回率（真的好想吐槽这个翻译，直译过来，非常抽象，导致一直都记不住）可以定义为查全率；同样以景点为例，分子是预测为景点并且真的是景点的样本数量，分母是所有景点的样本数量。
• F1值是这两个值的加权，有兴趣可以戳最后的链接了解【1】。

精确率和召回率是互斥的，如果想要提高精确率，那么就可能对召回率有点影响；反过来也一样，举个极端的例子，如果我把所有的预测结果都预测成景点，那么召回率就是100%，但是精确率就会很惨。

对于产品模型的指标，精确率和召回率通常表现出来就是两个百分数，一般来讲，双80%我们觉得比较适合的上线标准，双90%是比较优秀的标准，当然具体数值还是需要和团队内部达成一致来确定；这个数值是非常确定的，确定完标准之后，整个团队都需要按照目标一直迭代进步；指标达不到，最好不要上线，否则效果很差，这个是需要产品经理把关好的。

还有一点要注意的是，模型的指标还依赖模型的维护，上线之后，充分吸收真实环境下的结果反馈，有利于提升模型的指标；如果长时间不维护，那么大部分的模型都会越来越不准确。

五、产品指标的确定性

前面讲了，对于智能产品而言，模型的数据不等同于真实上线的数据，他们是必要不充分的关系。模型的指标数据可以当做是开发给你交付的结果的衡量；但是对于产品而言，更加重要的是要制定自己给公司的交付物以及对应衡量的指标。

产品指标需要是确定的并且是正确的，可以指导产品朝着指定的方向前进。

产品指标在不同阶段可能不同，比如在启动期或者爆发期，可能以活跃量作为指标，用户量大的才能存活下去。

产品成熟期，一般会以营收作为指标，营收才是产品能给公司提供的价值；衰减期的时候，要更加注重留存，尽量延长产品的生命周期，多给公司增加营收。

在特定阶段，一个产品的指标有很多，但是核心指标一般不会很多，这几个核心指标可以指引产品前进的方向。

通用指标：

• 营收相关指标：我能挣多少钱，这个对于公司来讲尤为重要，比如说GMV、收入、CPM等；
• 活跃相关指标：虽然我现在不能挣钱，但是我可以把盘子做大，然后再考虑挣钱或者给其他业务导流，比如说：活跃、留存等；

领域指标：

• 电商类产品通常用到的核心数据指标有：「首单率」、「客单价」、「复购率」、「退款率」等；
• 社区类产品通常用到的核心数据指标有：「活跃用户数」、「帖子发布数」、「互动用户数」、「用户对话数」、「留存率」等；
• 内容类产品通常用到的核心数据指标有：「用户停留时长」、「跳出率」、「用户互动比率」、「留存率」等；
• 工具类产品通常用到的核心数据指标有：「打开率」、「使用频次」、「目标达成率」、「分享率」等；
• 游戏类产品通常用到的核心数据指标有：「活跃用户数」、「用户在线时长」、「付费用户比率」、「留存率」等；

我的产品的指标：

转化率：从产品的工具属性出发，这个指标能证明提供的服务是契合用户需求的，是产品最核心的指标，同时也是可以牵引整个团队前进的指标，转化率越高，说明我们预估的越准；

活跃量：从产品的内容属性出发，如果活跃量达不到一定值，那么就无法吸引更多的CP来接入，就无法提供更多的服务；这个和转化率存在矛盾性，比如活跃多了，转化可能下降，所以要求团队要在活跃量增长的情况下，维持转化率不变或者稍微只降低一点点。

当然，还要保证【活跃量*转化率】的不断提升，才能预示着产品在不断向好发展。

六、预测反馈的确定性

数据指标有利于牵引整体产品向既定方向去前进，但是这种牵引只给了方向，没有给确切的方法，所以实操起来还需要有一些辅助。

模型的优化，虽然很大程度上依赖于算法工程师的努力；之前讲了，算法工程师也需要依赖样本的准确性，而依靠标注而来的样本始终是有限的，所以可以把这个标注融入到产品中，这就是结果的反馈系统。

没有反馈系统的流程

有反馈系统的流程

通过上面的图可以看到，反馈系统增加了一个自下而上的渠道，通过将用户的反馈加入到整个流程，可以帮助算法工程师优化识别算法，以提升下一次识别结果的准确率；同时，如果用户还可以提供更加具体的产品意见的话，也可以帮助提升产品。

最后，反馈系统还是一个负向情绪的宣泄入口，用户可以有地方宣泄自己的不满，不至于觉得心里憋屈。

综上，我觉得不仅是智能产品，所有产品都应该考虑嵌入一个反馈系统。

反馈系统需要考虑用户的接受程度：浅层反馈系统就是好评和差评；中层反馈系统就是好评，+选择差评原因；深层反馈系统就是：好评+填写差评原因。

1. 浅层反馈系统

浅层反馈系统

举一个简单的例子，上述是知乎的一个回答，上面的“赞同”和“反对”就是一个最浅层的反馈系统，用户可以表达自己对于回答的正向或者负向的情绪。

知乎收到用户的反馈之后呢，如果赞同数很多，反对数很少，那么会认为这是一个好的回答，下次有可能就会推荐给更多的用户。

这个系统同样也适用于我的产品，如果用户赞同了我们推荐的服务，那么可能是我们识别对了用户的意图，那么算法就可以做对应的调整；反之，如果是反馈了我们的服务，那么算法同学就要分析错误的原因，下次做修正。

2. 中层反馈系统

浅层反馈系统有个缺点，举个例子，如果我们识别到用户想去餐馆，然后推荐了了美团对应的服务；然后此时用户给了反对，那么有可能有如下几个原因：a.我们识别错了用户意图；b.我们识别对了，但是用户想看大众点评的结果；c.流程没问题，但是用户觉得响应太慢了。

诸如此类的原因分解可以有很多个，那么简单的反对就没办法完整传达用户的意思，也可能造成误解；这时候，可以把可能的原因列出来，注意不能多，大概3~5个，多了你就列为“其他”就可以了。

上图就是一个典型的中层反馈系统，只列了3个原因，可以有效区分问题类型，把算法问题（内容错误或者不合理）筛选出来，帮助算法提升。

3. 深层反馈系统

在中层反馈系统中，用户只有“选择权”，但是“表达权”还缺少了一些，用户无法畅所欲言，所以从用户哪里获取的信息就只会局限于实现限定的几类。

深层反馈系统可以让用户畅所欲言，比如以下，一般还是有两个步骤：

• 筛选反馈类型：这个还是需要做得，方便后期的筛选工作；
• 填写用户反馈语言，用户分析用户的意图；

可以参考下面微信的例子，不过微信体量大，做到这么复杂都还是有比较多的反馈量，一般产品还是掂量一下自己的分量再学习。

4. 反馈报告

上述反馈系统都是用户层面的，说点业务层面的。用户反馈的时候，可以附带一个叫“错误报告”之类的东西，这个可是一个宝藏。

错误报告可以上传一些信息，帮助分析用户状态，比如：

• 系统版本号
• 客户端版本号
• 用户所在的场景（比如哪个APP）
• 所触发的文字
• 预测的结果

这些可以有效还原用户的场景，帮助分析用户的意图，结合用户的反馈，可以达到更好的分析效果；当前需要注意，一切用户的数据获取都需要合法合规。

总结一下，预测反馈的确定性：明确用户的意图、明确用户的场景；这两点越明确越好，越能助力产品提升准确率。

七、尾声

智能产品的不确定性或许一开始会让人感到痛苦，不过仔细分析下来，玩法还是比普通产品多很多的；不过智能产品也有一个特点，就是见效慢，算法周期动辄几个月，所以还需要有足够的耐心去和自己负责的产品一起成长。

#专栏作家#

妖叶秋，交互设计师，人人都是产品经理专栏作家。做过ToC产品的交互设计，现在在尝试ToB的业务。主攻交互，也懂点用研、视觉和产品的知识。爱生活、爱设计、爱读书、爱总结，头像下方是我的联系方式，欢迎志同道合者与我交流。

题图来自Unsplash，基于CC0协议