智能客服终将被颠覆,进化为下一代智能服务

2020 年 8 月 27 日

智能客服终将被颠覆,进化为下一代智能服务

在金融科技的风口之下,智能客服成为金融领域落地最为广泛的智能应用之一,其已成为金融机构的标配产品。可能很多人都曾有被银行的智能客服“折磨”过的经历,这些所谓的智能客服并不像它们所被宣称的那样“智能”。


现阶段的智能金融客服为什么不够智能?在落地过程中面临着哪些挑战?以及接下来智能客服应当朝着怎样的路径发展?带着这些问题,InfoQ 采访了智能对话领域创业者 Mingke。


Mingke 认为,现阶段智能客服在理念方向和技术上都存在一定瓶颈。在未来,智能客服终将被颠覆,将进化为下一代智能服务 。Mingke 认为,作为一家智能客服公司,要想快速建立起自己的核心壁垒,核心要诀应该是要更快地转型为智能服务公司。


以下为 InfoQ 与 Mingke 对话全文,经编辑。


智能客服为什么不好用?


InfoQ:智能客服是金融机构应用较多的AI产品,但很多用户体验后觉得这些产品并不能达到想象中的智能,甚至有些“智障”。一些智能客服产品与人对话时常常答非所问,对于一些金融专业词汇和知识等识别不准确、一遇到复杂的金融场景就“歇菜”… 智能金融客服为什么还不够智能,您认为,导致这一问题的原因有哪些? 在技术上还需要做哪些改进,才能解决这些问题?


Mingke:遇到的智能客服体验不好,很多人第一反应是 NLP 的水平不行。我建议这时再试试这家的人工客服体验如何,如果人工的体验还不错,那么才是智能客服的问题。但往往很多公司的客服体系本身的体验就差,原因是不去、也无法解决用户的具体问题。这就好像我在《人工智障2》里提到的很多对话智能产品,不关注服务的闭环,只关注对话管理,就没有太大商业价值。以此为基础,后面很多问题就都好解释了。


从产品价值定位来看,人工客服行业经过了多年发展,自身的演进却有限,从使用电话开始到现在,基本没有颠覆式创新。主要原因是大多人工客服系统在价值设计上并不帮助用户解决具体问题,只提供业务的规则。主流智能客服只是在复刻人工运营的思路,体验上也不会有颠覆性的差异,无非是把原来由人力提供的低价值,变为由机器来提供低价值。但在用户一端,这些低价值的服务不解决当前的用户需求,甚至比人工的价值更低。


主流“智能客服”的产品 owner 是客服部门,做产品定义的也就是客服部门自己。但客服只负责管理用户生命周期中的一个阶段的事情,通常是比较靠后的售后。而当用户提出的问题与其他阶段的数据有关时,数据往往由其他部门负责,客服们就很难去有效处理。以此定位打造出来的智能客服,能有的系统权限也就是过去人工客服有的系统权限。因此,抛开技术的上限,业务上能做什么的上限就这样被限定了。而实际上用户往往是带着具体问题来的,这些问题又分散到不同的业务系统当中,所以单是数据权限,就决定了系统的价值上限。


从业务数据的治理和使用角度看,大多数客服系统都只是从客服系统读出数据,提供给用户,这些查询类工作与具体业务相关度低。这时,用户需要自己去思考自身所处的条件是否满足客服提供的信息和业务规则,并依据自身判断去进行下一步的操作。 这类的客服系统,无论是人驱动的还是人工智能驱动的,很少进行具体用户数据的写入,它不能改变这一个用户和服务提供方之间的状态,所以用户能感知的价值低,用起来很累,这也是绝大多数智能客服的现状。


最后才是技术的问题。智能客服大都把技术栈堆在前端,关注自然语言理解、填槽、知识图谱,这些每家都差不多。这几项单拉出来都没有太多差异,大厂都做的挺好的,创业公司也没啥区别。而以目前的技术上限来看,这样的定位就是在挑战机器最不擅长的部分,反而在机器擅长的方面没有发挥出来。


为什么用户感觉"智障"的核心原因,是因为用户不会去区分,你是识别出错,还是没有服务能力。就算能识别用户的发问,只要不能处理服务的交付,用户也会觉得蠢。“我不能理解你的问题”和“我无法处理你的问题”,对用户来说是一样的智障。我认为自动完成高质量的服务闭环与交付才是内核,再用对话系统对内核进行“包裹”,完成交互。所以与其说技术到了瓶颈,不如说做技术实现的人在这件事儿的整体理念上还停留在过去,继而限制了技术的施展。


以现在的技术而言,如果上面这些方向不做出改变,技术能改变的部分也很有限。


与"智能客服"对应的是"智能服务",尽管都是对话系统的应用,但却是两种不同定位的产品。好比两个人都能讲话,但能做的事儿都不同。如果说智能客服是对标人工客服的,那么智能服务对标的是移动时代的 APP。这是面向下一代 B2C 服务的理念,即对专业服务的智能化,可以理解为:以用户为中心,覆盖“用户完整生命周期”,管理用户与服务提供方的关系状态的变化。甚至从“还不是客户”的阶段开始,比如对于航空公司,还没注册的用户,也在其服务范围内。


智能服务的 owner 不一定是客服部门,很有可能是在具体的业务部门。业务覆盖的范围,则是用户使用一个企业的所有产品或服务。产品定义上要解决的核心问题不是对话,而是服务的交付。


对智能服务的产品定位而言,不能只给用户提供静态信息,比如各种公司规则,没人愿意看。它需要帮助用户完成信息搜集、分析情况、套用业务规则、然后给出预测结果,如果用户愿意,并直接操作后台,完成数据写入。所以智能服务,一方面在强调完整用户生命周期的管理,另一方面则强调帮助用户直接解决整个任务。


当前行业应用的现状如何?


InfoQ:最近几年,银行等金融机构纷纷部署智能客服产品,似乎不用上就落后了,您如何看待这一现象?


Mingke:跟风很正常,早期是有一定规模的公司都需要这个服务,长远从行业整体来看,会逐步普及,大家早晚都会用。


大概在 2017、2018 年,对话系统刚火起来的时候,跟风现象比较明显。现在更理性一些了,有些企业的智能客服系统上线后不久又被下线推倒重做,冷静下来后,他们开始反思前面掉过的“坑”。


使用对话系统来做客服,在方向上是否出了问题?技术的边界在哪里?DevOps 方法论上是否还能沿用传统软件开发的套路?该整体业务是外包还是把工具拆出来找供应商做然后自己运营?选方案的时候 happy path 的 poc 一时爽,上生产了,后期运维成本巨高又怎么办?行业开始思考这类问题了,只是目前还比较早期,方案上没有"统一解"。


InfoQ:传统金融机构为什么这么积极地想要拥抱智能客服?


Mingke:当前金融机构对智能客服的核心需求就是降本增效,尤其是在一些采用量较大的场景,如高频问题自动回答、外呼、回访等客单价比较低的业务中,能够代替低端人工客服的重复操作。


但这个成本减下来是有前置条件的,就是用户不得不用,不用智能客服就根本没客服。一旦开放选择给用户的时候,很多人一上来就直接转人工了。这都是智能客服自身定位的瓶颈带来的问题。两端的价值 — 企业提供商业服务价值和用户使用服务的价值,还没有充分发挥出来,还有很多很多空间。


而有少部分头部企业是为了试图打造下一代智能金融服务,有接触过一些产品方向,也确实值得期待。理念上走在前面,确实想拉开服务的差异性,服务的对象更偏用户而不是业务、指标卡在如何提升服务质量上。这类案例往往强调人机结合;他们数字化程度高;组织结构转型更敏捷;服务对企业核心业务的价值明显;在战略上面向未来做规划;对核心业务系统的连接比较多,承载一些业务的战略转型,比如打造好的智能服务,还可以分发到其他渠道和终端上,完成从自动获客到交易闭环。放到智能终端上,还可以拓客;而如果做的是实智能客服,分发到智能音箱上,或者集成进车机里就根本没有意义了。


InfoQ:您怎么看待它们宣传口径中的“高回答准确率”?


Mingke: 这个和对话轮数一样,对服务本身没有太大意义,这属于对话系统的基本功,而不是智能服务的差异点。 识别准确,不表示回答正确;回答正确不表示服务正确,比如”正确的废话“。一个系统能听懂你的问题,但是就不帮你把事情解决掉,对用户并没有价值,对 B 端也完成不了闭环。


要做服务,就直接用评价服务的体系,比如 FCR 即”用户首次接触就完成服务的比例“;再加上 CSS 和 NPS 等。目前绝大多数智能客服体系,在这几个值上的体现都是惨不忍睹的,属于不敢公开的类型。如果 AI 的 FCR 做到 80-85%就比较厉害了,当然与真人专家是不能比的,好的品牌通常要 95%以上。


现在很多大厂、小厂的方案都一味只关注识别准确率,其开发思路还都停留在“分不清对话用来干什么”这个阶段,目前这很普遍。一个具体表现是,没有把"对话 session" 和 “服务 session” 分清楚,以为一次对话就是一次服务。而对智能服务而言,一次完整的服务闭环,可由多次对话(就是多个对话 session)组成,甚至跨模态和终端。那么管理对话的,就应该是服务本身,而非对话本身。


在下一代的智能服务设计的结构中,对话系统和服务系统需要被拆分开来,即"交互"和"交付"分拆。当前主流方案当中基本都没有拆分,所以会给人留下印象,对话系统好不好用,是靠识别的准确率来判断的。但是仅仅做到在语言上是正确的,而无法完成服务的交付,则对两方的最终价值不大。


智能服务的精华在于专业级服务的自动完成,称为 BSPA(Business Service Process Automation)。如果说 RPA 是机器模拟人在界面上的反复操作,那么 BSPA 就是机器模拟人在业务决策时的反复思考。而对话系统扮演的角色,只是一种交互方式,来包裹业务决策的模型。在完成服务的前提下,交互轮次越少越好。有些案例,甚至无须用户开口,就能预判需求,直接给出结果。你看这个过程根本不存在自然语言处理的准确率的问题,而是推荐系统是否好用的问题。


举个例子,你要选择一个理财顾问,有一个人能跟你说的天花乱坠,但是就是不帮你赚钱;而另一个话不多,交互少,但能准确 get 到你的需求,就是能帮你赚钱,你选择哪一个?因此,产品的核心评判是在于业务先要准确完成,哪怕语言不那么准确,只要业务准确了,依然能保证给用户传达价值,用户依然会买单


所以,当你选择只用"识别率"评价对话系统的时候,你就已经选择了价值有限、且机器不那么擅长的定位了,这种选择就类似”让中文老师帮你做理财“。


InfoQ:金融机构希望AI能够代替人工,降本增效,据您了解,目前应用上智能客服产品后,达到的“降本增效”水平是多少,可否用数据说明下?


Mingke:降谁的本,增谁的效?智能客服仅提供 QA,只关注识别率,那么降本增效的对象就是只负责不停说话的基础客服。这个部分其实我不太关心,因为产品玩不出什么花样,而且商业价值低。这些业务早就被外包出去了,在这个定位的智能客服,抢的是传统客服外包行业的盘子。


更大的盘子是整个用户生命周期的专业服务全流程,强调专业服务的端到端的自动完成。此时降本增效的对象是核心业务的操盘人员,他们往往是 in house 的雇员;专业领域的水平高;本身就是核心业务或者离核心业务非常近;系统操作权限更高;招募、培训、管理、以及运营成本也会更高。但是 AI 与这类角色并不是替代关系,而是强力辅助让人变得越来越专业,数量越来越少就能开展大规模的高质量服务。


智能服务的核心指标是 BSPA rate,意味着一个服务从提出到完成,所需要的所有服务状态改变和交互,都自动完成。从用户角度看,就是一个服务有没有从头到尾的自动完成,而且有些服务类型可能是过去单靠人力无法完成的。


目前主流智能金融客服大部分时间是只读系统的数据,然后“打回”给用户。有的能读系统数据已经不错了,有些连读业务系统数据的权限都没有,能读的内容只是知识图谱制作的一些抽象规则,就无法实现服务的闭环。哪怕看上去有挺好的数据也都是围绕对话的,本质上也是“自嗨”,可以哄哄领导拿点明年的预算。一个例子就是在服务系统里加入端到端的“尬聊”机器人,凡是不能处理的对话,都扔过去,用户怎么说都能兜住,就是不解决问题。表面上看说了很多话了,session 数量还占比很高,看上去是不是降本增效了?但是该解决的问题依旧没解决。


在能够把服务完成的理想情况下,完成一个服务为目标,应能够为用户预判需求并提供更好的服务,减少交互,增加交付。有一些金融服务的项目在比较优秀的数字化基础上,BSPA rate 能跑到 88%,这已经是比较高的水平了。以此为例,在 business case 上可以预设到至少 50%的实际成本降低。


另一个容易被忽略但真实存在的价值,是 knowledge transfer 的成本。人工客服的人员更换非常频繁,对新人员的训练需要专业人员反反复复去教,好不容易教会一批,过几个月走了,又换一批。这种重复劳动也让专业人员干起来很不开心,而培训 BSPA 型的系统,则是一个一次性的事情,可以在每个版本的 BSPA 模型上不断提升服务和推理能力的水平。专业能力是由系统来沉淀,而不是跟着一帮待不长的客服人员走的。


比如,我曾经接到过欧洲企业的需求,要打造 AI trainer,让这个 AI 培训师专门来培训不停流失又新入职的真人服务顾问。我跟他们说,既然都把行业知识训练给 AI 了,为什么不直接用来给终端客户呢?当然这与部门设计的根本利益也有关,由此可见在将来,智能服务的潜力还可能会改变一些更底层的商业形态。


InfoQ:您觉得,用智能客服“替代”人工这件事靠谱吗?


Mingke:这不靠谱。以目前的技术来看,不必过分担心基于统计的 AI 应用会整体上取代人,因为缺少通用的推理能力。


从另一个角度来看,如果有一天低成本跨域推理的能力真出现了,被代替的也远不止初级客服了。所以我认为在可预见的将来也就是在未来 5 到 10 年里,Hybrid Intelligence(混合智能)才是发展的核心方向。在这个方向上,一些基础客服,比如数据读写权限低、决策权限低的、照着手册念剧本的,确实会率先会被自动化系统取代,而且这个部分可能是 99.9%的取代。GPT-3 的中文版出现后,应该会有一波相关的升级,会加速这个级别的取代过程。


但业务能力再往上提高时,现在的智能客服就不行了。一方面是金融场景受限于当前的合规,有些关键决策流程必须有人参与;另一方面是基于行业的深度和复杂的推理,在这些场景下,智能客服就很难操作,需要具备完善领域能力的智能服务来处理。再往上走,遇到有些非结构化因素混杂在决策过程中,如投诉,这在贷款逾期的情况下经常遇到,这些问题往往伴随着用户情绪的管理,投诉和冲突的消解等等,这些类似问题还是交给真人专家去解决比较好。


不可能被全面取代的是专业服务的专家,他们可以做基于推理的业务决策,能处理长尾问题,有核心业务系统的权限。对于这些同事,AI 价值是在辅助工具上,比如不需要死记硬背很多东西,用自然语言做检索、自动核审、即时方案生成、协助决策等。而人更擅长去解决长尾以及纠纷解决等对语言能力要求很高、业务条件复杂、还缺少数据支持的业务。机器擅长的交给机器,人擅长的交给人。


智能客服没有壁垒?


InfoQ:当下智能客服公司的技术和产品是否存在同质化较严重的情况?


Mingke:目前主流的智能客服基本都差不多,同质化非常严重,无论是传统金融行业从供应商那里拿的方案,还是包括互联网大厂、金融科技自己的 in house 方案。现阶段,各金融机构所部署的智能客服产品,基本都属于同一大类的产品,也就是 FAQ 加上基于知识图谱的 info retrieval,再好一点的做些填槽和逻辑树来管对话流。


有些加入一些自我感觉良好的 feature,比如端到端的闲聊或者所谓的情绪处理,基本都是无关紧要的噱头,不构成实际的竞争差异。整体覆盖范围与企业的核心业务结合的紧密程度基本都不够,在用户角度,体验和价值都没什么差别。


InfoQ:作为一家智能客服公司的的核心壁垒应该是什么?


Mingke:在解决方案上,我不觉得智能客服本身有技术壁垒。


在智能服务方面,壁垒更多,特别是对特定领域的深挖,会不断积累一些基于领域的问题解决方案,在成为行业解决方案之后,这些积累会有比较明显的壁垒效果。在以后一个企业在提出业务需求的时候,会遇到两种方案:一个是智能客服,拿过来做话术配置,主要在售后问答的场景;另一个是某某领域的智能解决方案,已经对业务领域做过预训练了,拿过来做业务系统的对接,主要应对完整的获客和个性化服务交付。


产品上的壁垒会逐步从“理”转到“文”,比拼的不是技术实现,而是谁的服务设计更好。跟移动时代类似,当人人都会做 APP 的时候,就开始比拼谁的产品好了,再后面拼运营和资本。


InfoQ:目前,智能客服在金融行业的落地概况是怎么样的?现在这些智能客服公司的赚钱能力怎么样?


Mingke:智能客服落地项目还是很多的,水平参差不齐,使用量多多少少是有的。


据我了解,现在业内智能客服主流的做法是围绕问答展开的。也就是刚刚提到的 info retrieval,FAQ,还有基于 KB 的 QA 这些。这样做的好处是落地很快,系统集成少,也不需要跨部门,针对业务领域的开发少。不好的地方也明显,就是体验差,专业水平低,用户价值少。这类系统比较适合大规模跨行业的做,尽管每个领域的专业程度低,但是优势在快和便宜上,有总比没有好。


这类系统比较适合对服务不那么看重的企业,比如小企业,其用户本身对服务期望也不高。另一类适用的是大企业,但优质服务本身不是它的核心竞争力,甚至有没有服务都不影响它赚钱,大家平时生活中也经常遇到。对这个定位的智能客服公司而言,就是渠道和销售驱动,因为技术上几乎没有壁垒,那价格和渠道战是必须的,没必要谈产品。


另一种做法是专精在特定的行业领域做深,也就是智能服务的方向。这意味着,识别模型与架构、对话管理、业务服务建模、知识图谱、内外系统集成、跨部门运维协同,这些方面都需要深入行业打造。这个方向的核心价值在于,把专业人士从重复做类似的问题解决中解放出来,去解决那些提升服务质量的难题。最终商业价值和用户体验,都不是前一种方案可以相提并论的。在一套完善方案的基础上,可分发到不同渠道,文本电话智能终端等等。但是部署和训练成本高,跨域复用非常难。比较适合打造一套行业方案,供多个市场和语言来使用,增加复用。因此合适的客户可能是大型企业,非常在意服务质量,用户基数大,business case 才好建。


从 VC 普遍关注的短期增长来看,铺人去做项目带来的增长比较适合前一类的方案,但是在后面可能在各个领域遇到挑战。从长远上看,我比较看好在领域内“深挖”的做法。行业与行业间存在领域的壁垒,越往行业深挖,越不可能出现“一家通吃”的现象,因此未来的趋势可能会是一家公司擅长某些领域。往后,未来不同领域的公司间的合作、融合、兼并也或将出现。


InfoQ:对金融领域的智能客服来说,它的变现能力、商业化能力怎么样?


Mingke:金融应该算是智能客服商业化比较好的领域。相较其他领域,金融领域的数字化相对成熟,实施难度较低,总体经济体量较大。金融领域是智能客服头一批落地场景,再往后演进成为智能金融服务的条件相对充分。


InfoQ:对创企来说,在金融场景下落地,当下面临着哪些挑战?您在推进做项目的时候,有没有一些"踩坑"的地方?


Mingke:无论是智能客服还是智能服务,要想把体验做好为前提,对话系统在金融企业里落地的挑战也挺多的。


在产品方面,有监管与数据问题。因为做智能服务会牵涉到数据的使用,如果智能客服只给用户提供基于知识图谱的 QA 那还好一些,系统不需要详细了解用户。对数据的监管,最后都会限制产品的用户体验。有些整体的操作,同一个企业的服务,放在中国市场可行,但是一旦放在欧洲市场就可能过不了 GDPR,用户体验甚至价值都会因此妥协。


在监管下,行业里一家机构能用的核心业务数据,别家差不多也能给。专业领域上实质不会有太多质的差别,比如"利息",大家能给用户的点数都是那么多。但是从用户管理角度来看,专业领域的基础差不多,只是面向用户的服务传递可以做很多差异,就可能给用户差异化的体验。可以理解为,银行之间,利息能给的都一样,而且不是银行能决定的,但基于这个如何做出不同服务却各有招数。


BU(业务团队)与 IT(IT 团队)协作。因为智能客服业务总体较新,且有很多分支,行业里可靠的评价方法尚未成型。企业内部的业务部门(BU)和 IT 部门;该如何管理这种新项目;如何进行跨部门配合;以及如何评判成果等方面都要做好协调;是以业务为中心来设计还是以用户为中心来设计?最好能提前沟通好。


CUI 产品与 GUI 产品的 DevOps 方面。落地智能客服的企业,十有八九会遇到“上线快,运维坑”的情况。就是上线之后,再来改业务的技能,增加新的 usecase,覆盖更多的用户的新表达(比如疫情对业务的影响),维护这些对话管理的成本非常高,而且效果往往都很差。然后,预算 call 在 CR 和运维上的成本会慢慢高于实施的成本,最后项目就慢慢“崩”坏了。这不是某一家厂商的问题,也不是金融场景的问题,而是整个对话智能行业的问题。不仅仅是智能客服,如果你做一个智能助理,拿去 2C,这个问题甚至比智能客服还要严重的多。


这涉及到一个对话系统的本质问题,也是目前被行业忽视的,就是该如何设计一套对话系统?这个问题具体表现在,如果你去看一家(企业)的对话产品的产品文档,如果还在用 excel 记录对话文本再配以流程图或者树状图,那么你的项目就一定会遇到上面的问题。


智能客服将进化为下一代智能服务


InfoQ:2016-2017年,可以说是智能客服行业创业投资都比较热的发展时期,最近这两年,由于一些问题凸显,业界对于这个行业的盈利能力等也或多或少有所质疑,您怎么看待,这个行业的发展历程?


Mingke:现在的技术正在颠覆“在固定时间和地点上班”这些企业(作为服务提供方)运营的基本概念了。实际上一些行业领先的企业,已经开始重新思考,面向未来的下一代的服务体系是什么。就好像改变马车的不是更多的马,最终彻底颠覆客服的也不是智能客服,而是智能服务,范围从技术选择、产品形态到商业模式。


智能客服的技术门槛低,价格和渠道拼到一定程度,这个行业可能就没什么钱可赚了,对每一家而言都是如此。做不出什么差异化,生存状况堪忧。这时就需要有一些新的东西来破局,行业会进化到“分垂直领域”阶段,因为领域自带壁垒,慢慢就形成专业服务的智能化,而不是客服的智能化。


InfoQ:有没有可能会在技术上实现很大的突破,从而让智能客服迎来了一个大升级?


Mingke:产品升级肯定有,技术的突破是有的。包括这两天非常火的 GPT-3 也是,对有些场景是挺有帮助的。比如对只回答静态规则的智能客服而言,有团队可能过去在这个方面做了很多自研的各种栈,可能会被 GPT3 维度碾压。只是一旦业务要求要回复结果精准,对生成过程需要可被解释,特别是在金融服务里,就不能直接拿 GPT3 来用。就算是 GPT-30,你问它"我银行账户里还有多少钱?" 它会根据统计模型给你一个答案,这个数字不是从银行系统取出来的,你敢信?


一旦这个跨域推理有突破,就会改变一切,不只是智能客服、智能助理,甚至人类社会的整体经济形态都会发生本质的变化。只是在眼前以深度学习为核心范式的前提下,想要解决跨域做推理的问题,在自然语言处理领域理论上是不现实的。所以只要这个底层的逻辑依然成立,就有很多 solution 上做选择的空间了,有行业壁垒的公司会逐渐击穿那些做浅层的智能客服公司。中期真正比拼的是,对领域的熟悉程度、专业程度、建模的颗粒度等。


InfoQ:到领域里深耕,如何判定一家创业公司做到行业的专家了?


Mingke:这里面很重要的一点与 AI 自身特点类似,就是做领域的推理,因为我们没有办法用一种功能技术建出一个对所有事情都能做推理的系统,我们现在只能模拟一些做推理的结果。而用人力去模拟每一个领域的推理结果,就意味着成本的极速增加。评价一个系统或一家公司,在某一领域的深挖程度是否有足够多价值,它能不能产生壁垒点,主要是判断它能否在该领域做更多复杂的推理,且对用户更有价值。其实行业里也有在特定领域做的挺好的,比如一些领域的电商做的智能客服,对企业客户确实省下不少钱,对自己也赚了钱,就是终端用户不满意,但是总比没有好,也是一个慢慢发展的方向。


InfoQ:尚不成熟的智能客服行业之所以火爆起来,这里面是否有炒作的成分在?


Mingke:有炒作,无论是来自于自身还是媒体的宣传,夸大效果,或者给出“大饼”的时候不提实现成本,都会导致最后落地不了。不止是智能客服,整个 AI 行业都存在炒作现象,这是不太好的一点。


InfoQ:2020年以来,因为新冠疫情的影响,很多线下的银行网点加快了收缩、关闭的步伐,对此您有什么看法?


Mingke:疫情期间,服务人员与用户的当面沟通减少,确实会加速远程办公、协同工具等智能服务发展。所谓智能服务是指让更多系统、机器能提供自动服务,个性化程度更高。当企业在一些场景下,不能线下面对面开展服务时,线上的需求就明显增加。人机混合的智能服务是未来,疫情会加速这个进程。


在接下来 1-3 年,我认为银行业应该会有“管钱助理”这种级别的智能服务出现。终端用户只认一家银行的 logo,说话提出需求就自动获得完善服务,或者被主动推送合适的服务,不合适就不用,这也是自然语言交互。而不是现在各个部门的客服汇总在一起,甚至一个 app 里就有多个部门的客服入口和对话窗口。


InfoQ:您为什么对于智能客服/助理持批判和怀疑态度?


Mingke:其实我对用对话系统做智能客服或者智能助理本身并没有偏见,我本身也是对话智能的创业者,也在用前面提到的所有技术为客户提供服务,智能客服的项目和智能服务的项目都在做。可能有朋友在《人工智障 2》一文中看到我对深度学习对语言的处理表示悲观,其实更多的我是想让大家比较实际的看到技术的边界,然后基于此来考虑如何打造真正传达价值的产品。


如果说批判,则是针对最开始提到的问题:当前系统远不如宣传那么好。以及类似的行业泡沫、炒作现象,当前 AI 不应该被不合理的神化或者被放大。


InfoQ:对于接下来,智能客服以及智能客服在金融场景下的技术和应用的发展趋势,您有什么看法?


Mingke:每一个行业都会诞生属于这个领域的智能服务,金融领域是首当其冲的。这些智能化之后,服务首先会覆盖售后的部分,也就是目前智能客服主要的用例,继而逐步颠覆智能客服,然后向用户生命周期的前面延伸,直至全面覆盖。


这个抽象过程也是深挖行业、场景的过程,行业逐步会分化。我们本身就是例子,我们现在就在为这样的企业提供面向未来的服务设计,其中包括一些大家耳熟能详的品牌。尤其对于那些数字化程度较高的企业,差不多 1-2 年就可以看到到处开花的效果了。


与这个过程伴随出现的,还有配套的工具、平台、基础设施,以及其他"卖水给掘金者"的业务,都会纷纷出现。下一个时代可能是属于智能服务的,看上去像是由 to B 开始的,巅峰的时候可能是全面 to C。智能服务是我认为 AI to C 的方向最有可能出现的做法。所以我对未来是非常期待的,如果有对这个行业感兴趣的小伙伴欢迎跟我讨论或者加入这个行业。


采访嘉宾介绍:


Mingke (wechat: mingke27) 是《人工智障2:你看到的AI与智能无关》一文的作者,同是对话智能领域创业者,目前为跨国企业设计智能服务体系,团队 MRS.ai 尚在 stealth mode,正在招募北京和上海的产品与研发。欢迎对智能服务领域感兴趣的小伙伴与我交流。


2020 年 8 月 27 日 13:351115
用户头像
刘燕 InfoQ记者

发布了 471 篇内容, 共 147.0 次阅读, 收获喜欢 831 次。

关注

评论

发布
暂无评论
发现更多内容

区块链产业,怎样“链”住未来?

CECBC区块链专委会

区块链

当人脸识别对准执法者,AI的应用边界博弈

脑极体

2020双11:每秒58.3万笔!阿里云又扛住了!

阿里云情报局

云计算 互联网 运维 云原生 科技

这份笔记我必啃完!美团T9首发内部JVM高级特性笔记,差距不止一点点

Java架构追梦

Java 源码 架构 面试 JVM

低代码开发平台核心功能设计——组件自定义交互实现

徐小夕

前端 编辑器 H5 大屏可视化 lowcode

数字人民币都来了 黄金还有什么用?

CECBC区块链专委会

数字货币

代码简易调试方法.md

HQ数字卡

Java LeetCode 调试

祝贺 StreamNative 团队成员 Jennifer 当选 Apache Pulsar PMC 成员

Apache Pulsar

大数据 开源 Apache Pulsar

架构师训练营第八周

我是谁

极客大学架构师训练营

「Java并发编程」从源码分析几道必问线程池的面试题?

Java架构师迁哥

一个技术总监的忠告:精通那么多技术,你为何还是受不到重用?

四猿外

程序人生 技术管理 加薪 职场成长 源码阅读

Pulsar Summit Asia 2020 | 主题演讲:大咖呈现,紧扣社区

Apache Pulsar

大数据 开源

靠脑机接口“隔空探物”,大脑植入芯片可实现“心灵感应”

脑极体

Rethink:多版本文件的命名细节

Sicolas Flamel

团队 随笔杂谈

Reactor中的Thread和Scheduler

程序那些事

响应式编程 reactor 多线程 程序那些事 reactivex

5G为数字化转型插上翅膀

CECBC区块链专委会

5G网络安全

记不住Spring中Scheduled中的Cron语法?让我们看看源码吧

AI乔治

Java spring 编程 架构

实时指挥调度的发展和优势

anyRTC开发者

ios android 音视频 WebRTC RTC

如何应对大促流量洪峰?揭秘京东技术人的备战手册

京东智联云开发者

云计算 大数据 亿级流量

如何预防工业物联网中的恶意攻击?

VoltDB

大数据 数据分析 5G 工业互联网

Dubbo-go Client端调用服务过程

apache/dubbo-go

dubbo dubbo-go dubbogo

文科妹子都会用 GitHub,你这个工科生还等什么

沉默王二

GitHub

架构师训练营第 1 期第 8 周学习总结

好吃不贵

极客大学架构师训练营

甲方日常 47

句子

工作 随笔杂谈 日常

甲方日常 48

句子

工作 随笔杂谈 日常

微信视频号强制置顶朋友圈:盈利不可牺牲用户体验

石头IT视角

深度解析ThreadLocal原理

AI乔治

Java 架构 线程 ThreadLocal

O'Reilly出版社又一经典之作——Python设计模式

计算机与AI

Python

Spring bean 加载顺序导致的 bug 问题

AI乔治

Java 架构 Spring Boot

什么?美团T9首发内部JVM高级特性笔记,看完差距不止一点

小Q

Java 学习 程序员 架构 面试

当我们在讨论实时性的时候,我们在讨论什么?

VoltDB

数据分析 5G 工业互联网

智能客服终将被颠覆,进化为下一代智能服务-InfoQ