编辑导语：随着科技的不断发展，更多智能产品开始深入到我们的生活工作中去，但智能产品很多都会存在一个不确定性，与用户表达的意思不相符合；本文作者分享了关于智能产品的思考以及未来的发展，我们一起来了解一下。
最近半年负责了一款智能领域相关的产品，主要是通过NLU（自然语言理解）技术，识别用户提供的文本，然后推荐对应的功能或者内容。
在负责期间，体验最深的一点就是智能产品的不确定性。有句玩笑话说得好：什么叫智能，就是有时候出现，有时候不出现，就叫智能。这个玩笑话，一方面是对智能产品的总结，智能产品就是在“猜”，猜测用户的意图。至于为什么要猜，因为用户不会真实告诉你想要什么，用户甚至都不知道自己想要什么，所以只能靠“猜”。
当然，另一方面其实也是对于智能产品现状的讽刺，目前受限于人工智能的技术限制，现在确实没办法做到非常智能的表现，很多时候我们会戏称为“人工智障”。
作为产品经理，这时候不能仅仅是无奈，首先就需要拥抱这种不确定性，因为这种不确定性将会贯穿产品的生命周期；其次，产品需要想方设法通过一些策略来规避不确定性对产品表现带来的影响。
一、为什么智能产品会存在不确定性
简单聊聊智能产品为什么会存在不确定性，先来看看现在能接触到的智能产品以及背后的技术都有哪些：
支付宝的指纹识别、人脸识别：图像识别
手机的语音助手：语音语义识别
淘宝、今日头条的信息流：推荐系统
以图像识别为例，说说人工智能技术的逻辑：
这些产品采用的技术可以分为以下几种：
监督学习：以水果分类为例子，在我们婴儿时期，我们并不知道什么是苹果什么是梨，是随着我们慢慢学习，然后才认识这两种水果。那么APP怎么识别呢？
首先也需要有学习的过程，需要事先知道一批水果是苹果或者梨；然后把这批水果分成两部分，第一部分用来训练我们的识别模型（即学习的过程），另一部分用来验证（可以认为是考试）；当我们验证的效果高于某个值，比如准确率达到99%，我们就可以认为这个模型有效，这个模型就可以后续用来识别苹果或者梨这两种水果了，监督学习的特征在于我们事先知道了一些水果的分类；上述的产品基本都属于监督学习。
无监督学习：无监督学习以聚类为主，比如有两棵树，一棵苹果树和一棵梨树，工人采集完水果之后就随便扔到了树下，这时候要对树下的水果进行分类；由于工人是随便扔的，那么苹果肯定离苹果树比较近，梨离梨树比较近；我们不需要知道水果长什么样子，也不需要知道他们长什么样子，只要算一下水果之间的距离，就可以把水果分成两堆；对于无监督学习，我们并不知道他们的特征，而是依靠他们之间的关系来判定的。
增强学习：阿尔法狗（就是打败柯洁的那个）就是用这种算法的，但是具体比较复杂，有兴趣可以自行了解一下。
为什么人工智能要用这些技术，我们以人脸识别为例，你为什么能识别出一个人？首先你肯定要见过，并且留下过比较深的印象；然后再次遇到的时候，你就会将遇到的人和脑海里的人进行比较，然后达到一定相似度的时候，你就会认出这个人是谁谁谁。
这个过程分为：认识-记忆-遇到-比对-识别，那么对应过来，监督学习的样本可以认为是认识的过程，训练模型就是记忆的过程，为了防止记忆有问题，我们还加了一个验证的过程；最后就是遇到，然后比对和识别，整个流程是类似的；人尚且会认错人，那么模拟人的识别而仿造出来的系统会出错自然也就不意外了。
回到我负责的产品，是一款NLU产品，NLU全称叫自然语言理解，“自然语言”就是指我们说的话；每个人习惯不同，知识水平不同，说出来的话也不同；比如说表达喜欢的话，普通人就一句“我喜欢你”，夏目漱石就会说“今晚月色真好”。
这种表达不同带给产品的就是：对於单独的一句话，可以确定它的意思。但是对于表达同样意思的所有话，不敢保证所有的话都能被识别出来，因为无法穷举或者明确定义，所以会带来不确定性。
二、产品定义的确定性
智能产品的不确定性是天生的，产品经理有义务从自身的系统搭建去尽量减少这种不确定；这种在产品上能做的，首先就是要通过明确产品的定义，从根源上尽量减少不确定性。
以上面的例子来说，“今晚月色真美”这种例子会被杜绝在外，首先是受众上而言，大部分人不会用这种表达方式。
其次，存在歧义，这句话明面上就是夸奖月色的，深层次才是表达喜欢的；所以这种有歧义的，在定义上的就需要杜绝。
那么回到普通的喜欢，通过研究可以发现，句式一般是“人名（包括代词）+喜欢（或者爱，或者养）+人名（包括代词）”；这个就是对于喜欢的定义，这个定义可以指导后续的样本的选择，样本的选择和标注对于后续模型的训练是非常至关重要的一步，直接决定了模型的成败。
智能产品有时候可以找到官方的定义，这时候就可以直接应用，比如说火车号，火车号是有准确定义的，参考如下：
高铁：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协议
转载请超链接注明：头条资讯 » 关于智能产品的不确定性
免责声明
：非本网注明原创的信息，皆为程序自动获取互联网，目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责；如此页面有侵犯到您的权益，请给站长发送邮件，并提供相关证明(版权证明、身份证正反面、侵权链接)，站长将在收到邮件24小时内删除。