多年来,理解人类一直都是人工智能的最重要任务之一。人们不仅希望机器能够理解他们在说些什么,还希望它们能够理解他们所要表达的意思,并基于这些信息采取特定的行动。而这一目标正是对话式人工智能(AI)的精髓。
什么是对话式人工智能
我们在市面上看到的智能助理相关的产品是对话式人工智能系统的最常见的表现形式之一,人机交互的方式由图形化交互(GUI-Graphical User Interface)变为以对话作为交互方式(CUI-Conversational User Interface ),人类与机器通过语音或文本实现扁平化、简单的交互,届时机器会理解人类并给人类提供需要的信息和服务。
一个完整的对话式人工智能系统由语音识别(ASR)、自然语言理解(NLP)、对话状态维护(DST)、动作候选系列(Policy)、自然语言生成(NLG)、语音合成(TTS)六大模块组成, 对话状态维护(DST)、动作候选系列(Policy),或者统一的称其为 对话管理(Dialogue Mannagement)。
在这些模块中,对话管理(DM)模块最为核心,要负责管理整个对话的流程。它的原理也很简单,当接收到 NLU 模块的输出后,通过上下文理解、封闭域多轮对话等方法明确用户意图,并且结合场景及用户特征信息等信息,判断系统应该跳转到什么状态,以及执行什么样的动作。从产品角度来说,DM就是在理解清楚用户的意图后,选择满足需求的方式。
对话式人工智能如何满足用户的需求
在对话式人工智能系统里,我们怎么满足用户的需求?一般来说,系统可以分为以下四个方式满足:闲聊、任务驱动的多轮对话、问答和推荐。
我们可以用三个用户画像来去举例子,在对话式人工智能系统里,他们的需求怎么被满足。
1、画像一:典型的小闲,是我没啥需求,我有时间,无聊,想聊天解解闷。
对于小闲用户,在交互中没有明确的信息或服务获取的需求,系统就会切换到闲聊系统,和用户不局限话题的聊天。闲聊在现有的对话式人工智能系统中,主要起到拉近距离,建立信任关系,情感陪伴,顺滑对话过程(例如在任务类对话无法满足用户需求时)和提高用户粘性的作用。
2、画像二:典型的大明,是男士买鞋子——我知道我要什么,我要最有效率、性价比好的东西。早期电商都是大明用户,京东的3C、携程的机票酒店都是标准产品,我直接得到我要的东西。百度也是服务大明的,我知道我要什么,你帮我以最快速度找到。
对于大明用户,带着明确的目的而来,希望得到满足特定限制条件的信息或服务。系统会视情况通过问答系统、任务驱动的多轮对话两种方式去满足需求。
(1)情况1:这个需求明确简单,例如“俄罗斯的首都是哪里”,就会切到问答系统,直接根据用户的问题给出精准的答案。问答更接近一个信息检索的过程,虽然也可能涉及简单的上下文处理,但通常是通过指代消解和 query 补全来完成的。问答系统可以是针对某一个封闭领域的,也可以是无领域限定的, 而后者的难度更大。
(2)情况2:用户需求比较复杂,订餐,订票,寻找音乐、电影或某种商品等,可能需要分多轮进行陈述,机器也可以通过询问、澄清或确认来帮助用户找到满意的结果。例如:“帮我订张广州去北京的机票”,系统会询问确定你的出发时间“您想什么时候出发”。任务驱动的多轮对话不是一个简单的自然语言理解加信息检索的过程,而是一个决策过程,需要机器在对话过程中不断根据当前的状态决策下一步应该采取的最优动作。
3、画像三:典型的笨笨,是女生出去逛街买衣服——我不知道我要什么,我要看,看了十几个服装店,几百件衣服,最后买了一顶帽子。这种用户就是我不知道要什么,我也没办法搜索。
对于笨笨用户,就会切换到推荐系统,系统会根据当前的用户query 和历史的用户画像主动推荐用户可能感兴趣的信息或者服务。例如小冰主持人这类对话式人工智能系统,可以根据过往你的用户画像推荐你可能感兴趣的歌曲,让你越听越喜欢。
简单而言,小闲用户用闲聊,大明用户用问答或任务驱动的多轮对话,笨笨用户用推荐。
对话式人工智能的挑战
听起来对话式人工智能系统挺棒的,我们只需要和机器通过最自然的对话,机器通过对话理解你的需求,无论你想解闷、你要买东西、你要了解健康知识、你要控制家电、好像它都可以将一切任务都执行得完美无瑕。
但是事实上,我们现在看到的无论是大公司的还是创业公司的对话式人工智能产品,更像一个人工智障。比如Facebook M;Amazon Echo;Google Assistant, Allo;Apple Siri;Microsoft Cortana;度秘等等......
如果对话式人工智能产品只是通过语音来进行简单的信息检索或者控制智能家居,用来查天气、查百科、控制开关等等,那它和普通的移动互联网产品有什么区别,并没有对用户体验有什么质的提升,相反更差。我们一开始的期望并不是这样的,我们希望对话式AI能颠覆现有的移动服务,那问题出在哪里?
很显然,用通俗的话来讲,现阶段机器无法很好的理解我们各种个性化的意图,并且能够提供的服务也是比较浅层面的、而且非常有限。
我在36kr看到一个作者是这样描述对话式人工智能系统面临的挑战,他认为是“NLP”和“供给端的数据”是对话式人工智能系统最大的两个瓶颈。他是这么描述的:
”我们假设如果有一个黑科技出现,使得NLP有了极大的进步,以至于两个条件:
1、基于上下文场景的对话;
2、口语逻辑,都能被理解了,甚至还能基于场景和上下文用NLG来生成各类问题——它能理解我们所有讲出来的需求。
在用户熟悉的范围内,它能结合所有的过去的对话,历史记录等等内部外部条件,帮助用户尽可能的实现“不用开口,就知道我在这个的需求”。比如当用户提出“推荐餐厅的需求”:
用户:”女朋友周日过生日,推荐一个餐厅,找有江景的,最好桌子旁边有一个大落地窗户,能看到外面的夜景。吃的不要太贵,环境好点,有现场音乐的最好是爵士,不要太吵的。”
Agent:“菜系有偏好么?”
用户:“意大利餐和法餐都可以,对了不要离外滩太远了”
Agent解析出以下选择餐厅的条件:
周日晚(营业)
适合女朋友过生日
有江景
有大落地窗
不要太贵
环境好
有现场音乐,爵士
不能太吵
意大利餐或者法餐
距离外滩不能太远
然后它去哪里找到这样的餐厅呢?在地图服务提供商,或者点评的API提供的信息里只有8,9,两项能找到数据。假设评论中有这样的数据,该用什么方式来传递呢?接口提供的都是结构化的数据,而“环境好”这样的非结构化数据,最多以标签的方式来做,但是这样的话,标签就会有无止境的多也不现实。
这就是我们所谓的“API困境”——当前基于API的数据传递方式,只能1)承载结构化数据;2)承载数量非常有限的结构化数据。当前基于GUI的产品,都是用API来传递结构化数据。但大量个性化数据往往是非结构化的,以当前API的方式很难被处理。这还是在使用场景或者服务比较简单的情况下。
在用户不熟悉的场景下,agent面对稍微专业一点的服务,就会遇到知识图谱的问题。简单来讲,agent要做推荐的前提是对推荐的内容得先有了解。好比,要向一位不懂酒的用户推荐一款威士忌,那就不能依赖这位用户自己提出的问题(很可能提不出要求),而得依赖“懂行”的自己对威士忌的理解的方方面面来引导用户做合适他的选择。一个助理显然无法拥有所有服务所需的知识图谱。
从知识图谱的结构来看,是相对可被结构化。一个服务可以以各种方式被拆解成很多个方面,但大量的方面在当前是没有结构化数据的(比如我们没有每家餐厅的“营业面积”的数据);甚至很多方面无法用结构化数据来表达(比如每家餐厅有否“适合浪漫约会”的环境)。
因此,智能助理就算有了强大的NLP,还需要全面的知识图谱(结构化数据)和处理并传递非结构化数据的能力——而这两点,在目前是无解的。“
作者最终得出的结论是,在”NLP“和”API困境“未彻底解决之前,基于人工智能的多任务agent不可能达到C端满意的水平。这个符合一般从业者的认知,看似很有说服力。作者所举的”找餐厅“的例子就是典型的大明用户,带着明确的目的而来,希望得到满足特定限制条件的信息或服务。其实浪漫就是第一诉求,作者为了证明其观点列了一堆当地人都很难满足的并列型推荐需求,这样的需求并不符合觉大部分人的习惯,太过极端,其实只需要推荐符合相关一两个条件的结果就行了。
当然我认同NLP和API困境在一定程度上阻碍了对话式人工智能的发展,但是并不阻碍它现在生长出让C端满意的产品。
对话式AI的未来
尽管现阶段确实不可能做出无所不知、无所不能的对话式人工智能产品,但是在封闭域下,做出一个让C端满意的浪漫餐厅的AI推荐助手是没问题的,甚至可以打通后续服务,AI帮你排号预订,都可以实现的。
所以现在不少公司的思路是做垂直领域的人工智能助理,产品的思路是限定谈话的领域,从宽度发展变为深度发展,结合图形化交互。这样一来场景比较小,语料库、语义相对有限,对话容易收敛。
对于对话式AI的未来,我的观点比较激进,我们会慢慢发现,在对话式人工智能领域,所有的古典互联网产品都值得重做一遍。
比如说我们做一个租房AI助手,大家觉得产品应该怎么设计?
未完待续。