为什么现在人工智能助理都像人工智障
FacebookM,真人和AI结合的服务
去年（2015）起来的这一波对话式服务在硅谷有多火？看看创业团队增长的数量就知道了：2015年的时候有129个类似的项目出现，而14年的时候才42个。
TracxnReport：ConversationalCommerce
在各类科技博客上，对ConversationalCommerce的讨论也非常热烈，尤其是在medium.com上有大量的探讨。基本的观点就是”对话式的交互将会成为下一个风口，大家赶紧上啊！“。截止到2016年6月的时候，在Producthunt上标记为对话式服务（ConvComm）的有一百多个创业项目。
除了智能助理以外，还有很多类似的概念如digitalagent，bot，servicebot,chatbot，P2P的电商。比如Operator现在用真人专家帮用户做消费决策，在过去尝试过用bot/AI但可惜达不到效果，或者magic模式，完全是靠”真人帮懒人用APP“驱动运营。本文主要讨论的是基于人工智能的智能助理——就像IBM提到的一样，只有如此才能真正规模化。
2）智能助理应该解决服务需求
巨头的人工智能助理基本都已亮相了：
FacebookMAmazonEchoGoogleAssistant,AlloAppleSiriIBMWatsonMicrosoftCortana以上智能助理的服务范围大都是在信息检索，帮助用户获得资讯。绝大多数的内容是不牵涉“推理”的查询类信息服务。比如：
明天的天气
找附近的星巴克
苹果的股票信息等等
明天的天气
找附近的星巴克
苹果的股票信息等等
如果用户问到在基础信息以上，一旦牵涉推理的问题，就无能为力了。比如：
明天这个天气状况会造成航班延误么？
附近的星巴克可以用支付宝么？
我什么时候该买苹果的股票？
明天这个天气状况会造成航班延误么？
附近的星巴克可以用支付宝么？
我什么时候该买苹果的股票？
使用体验方面，这些助理的服务范围覆盖面基本跟当前的所有引擎一样。在设计逻辑上，基本都是基于用命名实体识别来代替打字输入关键词然后返回检索结果SERP。而信息检索，离人们要完成的服务需求有很大的区别。就好像viv.ai的联合创始人DagKittlaus说的，当初他创建siri的时候，是想要重新挑战移动服务，而不是造一个chatbot。
DagKittlaus（中间）
除此以外，巨头的助理与其关联的生态产生操作的关联。比如SIRI对iOS和macOS的操作；Cortana对windows的操作；echo对关联着的智能家居设备的操作等等。此类操作的一个特点，是对结果非常的确定，出现个性化选择范围非常的少。
另一方面，对于创业项目而言，因为不具备类似的生态和硬件入口的条件，大都定位在资讯和服务上。我们选择Producthunt当中排在最前150位的项目进行分析，其中高达70%的项目定位都在2C的个人助理（agent）上，其中大部分都想做切入服务，包括垂直类的和多任务的。
这些助理服务当中有23.1%是专业类型的服务，主要是在医疗和理财方面。而剩下来的76.9%的助理干的最多的活儿是生活上的综合帮助，出行安排，日程管理，购物订餐厅等等——这一类是坑最大的地方——特别是那些试图把生活上的各种服务都打包进去的产品。
Producthunt上面69.7%的对话式服务都是智能助理产品（但并非所有都具备AI）。
对CUI的特点的理解决定产品价值
不可否认的，真正的CUI产品一定是基于人工智能的自然语言处理的。如何深入利用CUI的特点，是产品打造的关键。
1）CUI的不可延续GUI的特点
为了深入理解这个问题，我们可能要先分析一下，CUI和GUI究竟给用户体验带来什么影响？因为这绝不是现在主流的“把按钮变成语言操控”那么简单的事情。
当移动设备出现的时候，大家对如何在智能手机上开发产品还没有来得及有深入的了解。所以当时开发者基本都是从最明显的地方起步，也就是触摸代替键鼠操作。早期的大量应用，都是从“如何把web缩小到手机屏幕”的思路出发来设计APP的。——这是典型的延续上一代交互的思路。
随着开发者不断思考和挖掘移动端的潜力，慢慢有了对移动端真正的核心特质的理解——这些“圣杯属性”才是真正让移动端产品设计出众的要素。比如“碎片时间”、“个人身份绑定“、”LBS”等等，这些特质才是真正让移动产品体现价值的——这些是完全颠覆上一代交互的属性。而且我们发现这些属性几乎跟“触摸”这个明显的交互行为没有直接关系。
现在CUI出现的时候，产品经理也会面临类似的问题。当前大多数智能助理的设计思路都是“过去APP是怎么用的，我现在用语言来代替触摸操作”。好比是用语言来代替手指去触摸屏幕，或者是用说话来代替手指打字。而能让用户感觉真正智能的核心，我认为依然藏在CUI的“圣杯属性”里，有待大家发掘。
2）CUI的特点：高度个性化
举一个例子，根据实际研发和市场运作的经验，我们发现有一个算得上“圣杯属性”是特质是：“高度个性化”。
在GUI时代，用户使用产品时，有一个可视化的界面，比如找餐厅，我们打开点评看上去是这样：
这看上去是一个大家非常熟悉的界面，只是所有用户能做的选择范围，都明确的显示在界面上（所见即所选）。找美食，用户能做的选择基本就是：附近，类型，智能排序（不点开可能还不知道是什么意思）以及排序。当用户自己不知道该如何决策的时候，这些视觉化的框架，给了用户提示该从这些方面根据自己的需求来做筛选和匹配。
但是在智能助理的界面，用户看到的是这样的：
用户对可以做哪些选择一无所知——在没有可视化的参考下，面对如此开放的交互，当用户要找一个餐厅的时候，他们提出的要求，大都不在GUI设定的范围以内。
根据我们实际操作的经验，用户提出的问题是这样的：
只有“在外滩附近的”是之前GUI的查询范围当中的，其他的需求都是过去GUI的类型当中不存在的维度。但因为CUI的开放性，用户很容易给出上面这样的高度个性化（非结构化）的需求。
如果GUI的产品试图在个性化同样给用户那么多选择，就不得不面临用户使用成本的问题。一个界面可能会被大量的下拉列表，层级关系，各种填空和操作充满。如此是加深了个性化程度了，但是操作的成本会让用户放弃使用。
如果在智能助理的产品设计上，不尊重用户“高度个性化”的需求，只提供过去APP本身提供的个性化程度“在XX附近找个YY菜”，那么用户在实际提需求的时候得靠运气撞到既定的条件上，不然就是无法识别的范围，继而失望。另一方面，如果CUI只是在做GUI范围内的事情，会远不足以颠覆APP。
除此之外，CUI还有一些专属的特点。比如：
使用流程非线性：比如GUI是线性的流程，界面引导用户一步一步走到结果；而CUI则可以是完全无视先后顺序的，用户可以再最开始就提出本来到排在最后的条件当中。可避免信息过载：用户打开GUI的一个界面，比如点评上找一个餐厅，用户得在一个列表里去找寻自己最想要的选项（典型的案例是，GUI让用户选择国家的时候那一长排的列表）。而CUI则可以规避用户的信息过载，直接给出期望的结果。这个特点的另一面是，GUI因此是informative的，给不熟悉场景的用户更多的提示，或者比较结果的机会。复合动作：“明天后天，晚上最便宜的机票”——从用户的操作和实际体验来看，GUI无法一次给出结果，只能用户先查一次明天的机票，再查一次后天的机票，然后手动来对比。CUI完胜——可以直接给出相关条件的检索结果，前提是AI足够优秀。这里只是抛砖引玉，详细更多特质会不断被开发者发掘出来。在这里就不详细展开了。在另一篇《人工智能时代的产品经理》文章当中，会做更多关于CUI的分析。
什么样的AIAgent能满足C端的需求？
为什么现在的助理产品都是坑？很多团队不是底层的算法差，而是团队对产品的理解有问题。
要满足C端用户的需求，确实非常难。10次使用，有一次因为任意原因的失望，用户心理就会开始有疑虑。从体验上来看，在用户熟悉的场景下得全面理解用户提出的需求；在用户自身不清楚场景下，得自然的协助用户挖掘需求；获得需求后得帮助用户做决策，并最终呈现结果。以此来看，对话式的agent得至少满足以下功能：
具备基于上下文的对话能力（contextualconversation）;
具备理解口语中的逻辑（logicunderstanding）;
所有能理解的需求，都要有能力履行（full-fulfillment）;
具备基于上下文的对话能力（contextualconversation）;
具备理解口语中的逻辑（logicunderstanding）;
所有能理解的需求，都要有能力履行（full-fulfillment）;
1）基于上下文的对话能力（contextualconversation）
在当前，做助理的产品的底层技术基本都是围绕NLU（自然语言理解）打造的，很多还没有涉及到NLP。可是无论是大公司还是小公司的NLU都是让人失望的。举个简单的例子，在大公司的几个产品上提出需求：我下周五要去北京，帮我查一下航班。
需要识别意图：查机票
需要识别entities：时间（下周五），目的地（北京），出发地（无/当前地理位置）
需要识别意图：查机票
需要识别entities：时间（下周五），目的地（北京），出发地（无/当前地理位置）
我们看看结果，首先看三家的回复，从左到右分别是苹果的SIRI,微软的CORTANA,Google的ALLO。
没有一个能识别出来意图，全部用关键词来检索网页(SERP)。没有识别出意图，继而也就没有可能识别entity所在的场景。对于C端用户而言，这可能算是最基础的服务之一，而三大巨头提供的产品完全不能用。
不过当我们看到国内的创业公司，却能按照需求识别出意图，并且识别出对应的entity，组合查询出结果，看上去比几个巨头更强大。
我们继续测试上下文的对话。比如，我是国航的会员，agent给出上面的结果里没有国航的航班，我自然会问：”有没有国航的？“
结果并没有如期望那样，在给出的列表里找到国航的航班。而是开始了重新的一次查询。
换一句话来说，没有结合上下文的对话。我并不是为了黑，事实上这个产品在国内的创业公司中也算不错的技术了。但是不会结合上下文的对话，会造成的最严重的问题就是这个agent基本不能独立完成服务。因为用户不会在一个句子里把所有的条件都列出来。
以上是基本要素，就当前的产品形态来看，只有非常少的产品能真正做到第一点。大部分号称能做到的，都是滥竽充数，连续问问题而已。
不能真正理解上下文的对话（机票查询）：
AGENT：从哪里出发？
用户：上海虹桥机场
AGENT：到哪里？
用户：还是从浦东走吧
AGENT：好的，从虹桥出发到浦东的航班是......
AGENT：从哪里出发？
用户：上海虹桥机场
AGENT：到哪里？
用户：还是从浦东走吧
AGENT：好的，从虹桥出发到浦东的航班是......
在上面的对话，AIAgent在问第二个问题的时候，不能理解用户对前一个回答的修改（出发地从“虹桥”改为“浦东”），只是按照预先设计对话的顺序，填上命名实体识别得来的entity。继而查询不到结果，给用户的感觉就是笨。
真正理解上下文的对话（机票查询）：
AGENT：从哪里出发？
用户：上海虹桥机场
AGENT：到哪里？
用户：算了，从浦东走吧
AGENT：好的，出发改为浦东。那到达城市呢？
用户：北京
AGENT：好的，从浦东到北京的航班是...（给出正确的结果）
AGENT：从哪里出发？
用户：上海虹桥机场
AGENT：到哪里？
用户：算了，从浦东走吧
AGENT：好的，出发改为浦东。那到达城市呢？
用户：北京
AGENT：好的，从浦东到北京的航班是...（给出正确的结果）
而具备真正上下文理解的对话，agent可以正确理解用户第二个回答的内容（从浦东走），其实是在修改上一问题的回答（出发机场），而不是真的在回答第二个问题（到达地在哪里）。
这只是上下文的例子，而对于服务类agent而言，所有后续的NLP功能都基于上下文对话为前提。这些看上去其实都是非常简单的需求，但是当前没有任何一个2C的agent可以做到。
可能有人会问，大部分用户都应该在第一时间把需求表达出来吧，为什么还需要对话？实际上，真正操作过大量案例的同学就会发现，用户不可能如此”贴心“地按照开发者的设计来提出需求。
“帮我看看下个星期五去北京，下午3点多，从虹桥出发，国航的航班。”——这一类的表达方式在几乎从来没有出现过。哪怕是在用户最熟悉的场景，也很难确保一个句子的表达里包含了所有必须的检索条件。而且，用户还会不停的补充更多的个性化需求。
对于用户自己比较了解的场景，如：订机票需要提供到达地，用户提出的大多数需求，在最初都是非常简单，然后逐渐开始细化的。所以需要当用户提出不完整需求的时候，根据其意图，结合之前已经给过的条件，通过对话，向用户提出问题，再获得答案来补全剩下还需要的条件，最后再完成服务。
对于用户自己不熟悉的场景，用户根本就不知道自己该提出哪些方面的需求。如：不懂酒的用户，想买一瓶合适的威士忌。他就根本很难提出除了价格以外的需求，比如产地，年份，酿造原料，水源等等。因此，Agent得以合适的方式来提问，引导用户给出偏好，并且用对话提出推荐。
而且对于agent而言，很难判断哪些用户对服务的认知有多深。如果不做识别，就容易问“老手”一些“新手问题”，继而让老手觉得我还不如自己下单；而给新手又留下“你在说什么我都不懂”的印象，也是不聪明。
所以要有好的体验，这是非常困难的。而基于上下文的对话，只是最基础的用户需求之一。
2）理解口语中的逻辑(logicunderstanding)
在我们的实践中，我们发现对“逻辑”的理解直观重要。原因也是因为用户的正常对话，大部分都不是开发者预设那样的。
再做一个简单的测试，比如找餐厅，试试：帮我推荐一个附近的餐厅，不要日本菜。
这是一个简单逻辑，但是你看所有的服务，这次包括刚刚那个国内创业公司C一样，都会是一个结果：全部推荐日本菜。
也让朋友测试了亚马逊echo的alexa，结果也无法识别”不要“这个最简单的逻辑
这次其实比刚刚好多了，至少4家里面除了googleallo，都识别出来我的意图是找餐厅——但是，当我明确提出不要日本菜的时候，给出结果的三家全部都是日本菜......也就是说“不要”两个字被完全忽略了。
观察大量的用户案例表明，当用户越是个性化需求强烈的时候，对话中出现逻辑和指代关系的频次越高。
“有没有更便宜的？”
“除了大床房以外的房间有么？”
“后天会比今天更冷么？”
“就要刚刚的那个2千多的吧。”
“除了廉价航空，其他的航班都可以。”
“有没有更便宜的？”
“除了大床房以外的房间有么？”
“后天会比今天更冷么？”
“就要刚刚的那个2千多的吧。”
“除了廉价航空，其他的航班都可以。”
以上这些需求是提需求的时候，在对话中经常出现的表达方式，而且看似简单，但是目前没有任何一个NLU的系统或产品能够正确的理解。主要的阻碍就是对逻辑的理解，还有在基于上下文对话中的指代关系的理解失败。
3）NLP不是全部，还要有能力履行（API困境）
NLU并不是智能助理发展的瓶颈，供给端的数据才是。
我们假设如果有一个黑科技出现，使得NLP有了极大的进步，以至于两个条件：
1）基于上下文场景的对话；
2）口语逻辑，都能被理解了，甚至还能基于场景和上下文用NLG来生成各类问题——它能理解我们所有讲出来的需求。
1）基于上下文场景的对话；
2）口语逻辑，都能被理解了，甚至还能基于场景和上下文用NLG来生成各类问题——它能理解我们所有讲出来的需求。
在用户熟悉的范围内，它能结合所有的过去的对话，历史记录等等内部外部条件，帮助用户尽可能的实现“不用开口，就知道我在这个的需求”。比如当用户提出“推荐餐厅的需求”：
用户：“女朋友周日过生日，推荐一个餐厅，找有江景的，最好桌子旁边有一个大落地窗户，能看到外面的夜景。吃的不要太贵，环境好点，有现场音乐的最好是爵士，不要太吵的。”（btw，这是一个真实需求）
Agent：“菜系有偏好么？”
用户：“意大利餐和法餐都可以，对了不要离外滩太远了”
Agent：“菜系有偏好么？”
用户：“意大利餐和法餐都可以，对了不要离外滩太远了”
agent解析出以下选择餐厅的条件：
周日晚（营业）
适合女朋友过生日
有江景
有大落地窗
不要太贵
环境好
有现场音乐，爵士
不能太吵
意大利餐或者法餐
距离外滩不能太远
然后它去哪里找到这样的餐厅呢？在地图服务提供商，或者点评的API提供的信息里只有8，9，两项能找到数据。假设评论中有这样的数据，该用什么方式来传递呢？接口提供的都是结构化的数据，而“环境好”这样的非结构化数据，最多以标签的方式来做，但是这样的话，标签就会有无止境的多也不现实。
这就是我们所谓的“API困境”——当前基于API的数据传递方式，只能1）承载结构化数据；2）承载数量非常有限的结构化数据。当前基于GUI的产品，都是用API来传递结构化数据。但大量个性化数据往往是非结构化的，以当前API的方式很难被处理。这还是在使用场景或者服务比较简单的情况下。
在用户不熟悉的场景下，agent面对稍微专业一点的服务，就会遇到知识图谱的问题。简单来讲，agent要做推荐的前提是对推荐的内容得先有了解。好比，要向一位不懂酒的用户推荐一款威士忌，那就不能依赖这位用户自己提出的问题（很可能提不出要求），而得依赖“懂行”的自己对威士忌的理解的方方面面来引导用户做合适他的选择。一个助理显然无法拥有所有服务所需的知识图谱。
从知识图谱的结构来看，是相对可被结构化。一个服务可以以各种方式被拆解成很多个方面，但大量的方面在当前是没有结构化数据的（比如我们没有每家餐厅的“营业面积”的数据）；甚至很多方面无法用结构化数据来表达（比如每家餐厅有否“适合浪漫约会”的环境）。
因此，智能助理就算有了强大的NLP，还需要全面的知识图谱（结构化数据）和处理并传递非结构化数据的能力——而这两点，在目前是无解的。
总结
在"API困境"解决之前，再加上NLP本身还有很长的路要走，基于人工智能的多任务服务agent不大可能达到C端满意的水平。
创业团队各自最基础的认知计算的能力不会有太大的区别，都是踩在世界顶尖大牛的肩膀上——在这个领域创业团队想和大公司钢正面，不是很理性。
创业团队在垂直领域有些自己的技术突破可以创造一些阶段性的优势，但面对教育市场的大山而言，这点差异远不足以makeadifference。
在各自领域，开发者对人工智能相关技术的理解和其带来的交互层面的有效应用，可能会在垂直商业应用上创造更大的差异——比较起「95%VS98%的识别率」而言。返回搜狐，查看更多
零基础如何做一款人工智能（AI）产品
从外包模式进化为有产品的团队，人还是那拨人，但做的事情有了本质的区别。第一个阶段通过外包定制化开发，对目标客户和需求有了了解，但这个理解能否经得起市场检验，仍存在巨大的未知。
从理解到满足需求的产品巨大的跨越就是MVP（最小可行性产品），以最小的代价，将理解变成产品，并通过寻找种子用户使用，观察和了解真实场景下客户的反应，再将产品快速回炉，以此循环往复。MVP被纠偏和验证。这个阶段主要打磨AI产品的核心流程，将阻碍客户使用的点，以最简单易用的方式重新呈现。
MVP阶段，AI产品经理也更加清楚团队需要什么样的人，也要从线上和线下两路推动开始小范围推广，为产品研发争取时间和需求验证机会。
这个阶段并没有通用的结束时间，可以以AI产品可以大范围推广营销为准。通常AI公司理想的状态是将AI实现为自动化按需接入的SaaS系统。从产品角度来讲，可以以产品是否满足SaaS能力为准。
这是做人工智能产品第二重境界。
SaaSor企业服务
AI企业本身具有技术，但不具备数据和应用场景，这就决定了AI企业赋能的角色，通常的表现形式是AI+行业。头部企业有AI+安放、AI+金融、AI+医疗。小乐帝做的业务属于AI+媒体。赋能的角色会让很多互联网转型AI的产品经理不适应。
因为再也难看到指数级增长的业务，更多的是线性或者是水平线的慢增长常态。赋能的特点也决定了AI企业需要适应不同客户水准，产出的产品既要满足大客户需求，也要照顾到中小客户需求。因此最理想的状态就是做SaaS系统，产品具有一定的冗余，企业按需接入，这样就能一劳永逸。每年收个软件费用，岂不快哉。
越是中小企业需求相对越少越简单，有SaaS系统总比没有强，也能用起来，这种AI赋能很好推广和引入。但中小企业规模有限，营收能力有限，在激烈的竞品市场竞争中，很难挣到钱。大企业的好处是愿意花钱，但同时规模和阶段决定了其需求更加复杂和多元。AI产品化到一定阶段，会发现做的产品需求大多为大企业准备，中小企业基本用不上，AI产品80%功能乏人问津。
就这样为了节省开发成本，大企业客户始终免不了定制化开发，很多定制化开发需求又因需求量有限，没必要做产品化设计和开发。AI产品不再是产品，而是服务，有企业需求就做企业服务，产品价值更多是降低服务成本的手段。
AI企业大部分做到最后都是做的企业服务，这是AI企业赋能特性和攫取利润目标共同决定的。
AI产品既要做SaaS也要做企业服务，这便是AI产品第三重境界。
经历过这三重境界后，也基本经历了AI产品从零到一到一百的阶段，前路漫漫，愿AIPM同仁不忘入行初心，以赋能的角度，创造更大产品和服务价值。
关于作者：
小乐帝，一线AI产品经理、简书科技优秀作者、产品经理读书会创始人。返回搜狐，查看更多