作者:赛泽

2016年,我开始接触服务机器人,2年多的时间,让我逐步了解人工智能和智能硬件服务机器人。现写下当时完成智能硬件服务机器人解决方案过程中的实战经验和教训、收获和感想,既是对自己的沉淀,也是希望能够帮助想要了解智能服务机器人的朋友。
一、整体方案思路
我接触的智能服务机器人针对的市场是to B市场,客户主要是政府和银行等大型企业。公司是专门做语音语义服务平台,所以我们做服务机器人的初衷是希望把AI的技术和单纯的硬件机器人结合,形成AI+硬件机器人的一套完整方案。我们的智能服务机器人的整体方案基本的思路是:基础产品实现→项目定制上线→售后运营和维护→产品更新迭代。
1、基础产品的实现
要实现智能服务机器人产品,主要涉及这几个方面:产品应用场景→产品功能/技能(主要AI技术/引擎和基础技术)→硬件机器人的整体设计(对应的硬件支持)及软件系统选择。具体如下图:
  1. 应用场景:
服务机器人分为几种,有的是重点做智能问答咨询和简单业务办理,有的是做货物递送、巡航等,有的是单纯做业务的整合,还有的仅仅是娱乐互动等。我们的服务机器人更偏向于第一种,因为公司本身有AI语音语义的优势(多领域对话积累和NLP(Natural Language Processing自然语言处理)平台等),所以更偏向于做大厅的咨询员、大堂经理等这样的角色,目的主要是为了给客户减少人工成本、分流人工服务压力。后来,在真实环境中,由于很多人对智能交互的陌生、环境噪音及口音等不相同等多种因素,虽有引导话术,但想要咨询流畅有时候还是需要工作人员在旁协助。
除了大厅担任服务人员这样的角色外,我们也利用室内导航技术,使机器人可以担任展厅和大厅的引导员,与工作人员相互配合,给用户指引路线,比如带领用户到某个办事窗口。不过在实际应用过程中效果并不是很突出,一是实际场景用的少,二是受制于当时技术限制,后来跟第三方合作有做改进。
服务机器人还可以参加各种舞台表演,能够聚集人气,给人新鲜感。我们的机器人参加了很多的展示、表演,甚至上过大型舞台。舞台表演虽然不能完全展示机器人的能力,也不能帮助客户解决实际问题,但是很大程度上吸引了人流、聚集了人气,既能宣传我们公司,又可以宣传客户公司,这也说明,有的公司使用机器人更多的目的是“炫”和宣传营销。
  1. 产品功能:
基于业务场景,我们的功能主要以语音业务咨询办理为主,其他功能为辅。整体语音功能主要包括:
  • 语音唤醒,唤醒词,免唤醒词
  • 语音识别
  • 欢迎词,引导词,属性知识等
  • 闲聊问答对话和NLP知识库
  • 业务知识对话和业务知识库
  • 指令动作表情反馈对话
  • 语音播报音色选择
这些语音功能和配合程度都需要产品定义和选择。其中,闲聊问答和NLP知识库根据公司情况选择,如果本身公司就有NLP基础知识库(比如闲聊、天气、百科等),那根据需求对接即可,如果本身公司这方面薄弱,那就要使用第三方的知识库或者自己建设。
业务知识对话一种是通过语料收集-模型训练测试到对话实现,一种是快速通过已有的强大对话管理平台实现,我们更偏向于后者。我们的语音交互大部分都是在云端完成的,但是机器人也存在无法连接网络的时候,所以有部分的对话,也会放在本地。
基于语音交互,我们还利用新的技术做了声源定位转向和语音打断功能。前者可以使机器人能够判断对话人的方向并且面向对话人,后者可以不用唤醒持续对话,提升对话的流畅度。
(注:基于硬件的语音交互一般是:唤醒(免唤醒)-[可加声纹识别/人脸识别]-语音识别-语义理解-对话处理(本地或云端)-硬件执行操作,同时语音播报;若支持EC(Echo canceller,回声消除)的话,可支持打断;不同场景可能有所不同)
语音功能除了VUI语音对话,也要有GUI界面相互配合,能让用户更容易明白回答的内容和流程。
基于语音的能力,我们还使机器人具备了人脸迎宾、行走避障,室内导航、唱歌舞蹈等这些功能(含GUI)。为了丰富功能,可以接入第三方服务,尽可能的让机器人看得到、听得到、答得出、有表情、会唱、能走能停、会跳,能导航,做一个有多种功能的业务咨询机器人。
在我平时测试和演示过程中,机器人在办公室环境还是比较稳定,整体效果还是不错的。
由于硬件做远场语音交互对外界环境要求较高,所以在完成机器人的语音交互的过程中,有几个语音上的难点:
  • 如何更好地在远场情况下屏蔽真实环境的噪音,做到更好的语音识别效果
  • 如何更好地判断此时与机器人说话的是谁
  • 如何提升语音交互的流畅度,不用反复唤醒又能易于使用
我们利用降噪、Beamforming(波束成形)等多种方式解决,有一定效果,但是在人声比较嘈杂的环境中还是很难达到特别好的效果。
在设计行走导航的功能上,避障和路线规划是非常重要的,因为行走对机器人来说是和其他硬件的区别之一。机器人毕竟不是人,很难做到人那样可以在人群中灵活穿梭,如果避障不及时会导致撞到人或物体,如果避障距离过于大,也会导致反复避障,对用户体验不好。路线规划亦是如此。
导航有几种方式,一是在没有传感器和二维码的情况下,只能设定固定路线,这种是一旦受到外部影响就要重新推回到原来的位置,现在已经不用了;二是使用二维码的方式,这种方式需要在天花板上贴上很多二维码,机器人可以在二维码范围内规划路线,但脱离了二维码就无法导航;三是利用激光传感器和深度摄像头,这种方式可以扫描整个室内,形成地图,然后再进行起点和终点的路线规划,会自由很多,但是一旦原来地图里的障碍物发生了变化,那就会影响路线规划。
  1. AI技术/引擎:
在整个智能服务器人开发的过程中,要融入多方面的AI技术和引擎。
在语音交互方面,主要是在唤醒引擎、语音识别引擎及TTS上会使用多方的技术作实验和比较,目的一是希望是在能够在我们的机器人上和我们要求的环境中达到比较好的效果,二是集成多方的能力在做项目上也会更加的灵活。比如唤醒率我们就会特别关注,因为这是和机器人交互的第一步,如果唤醒率达不到要求,就无法有好的用户体验,这样也就没有后续的业务咨询对话了。
语音唤醒优先选择用科大讯飞的技术,本身引擎的效果是可以,如果唤醒词选择合适且阈值调节到合适的数值,唤醒率可以达到95%以上,能达到我们的要求。唤醒引擎的效果和麦克风的选择也有关系,一开始我们使用2麦的麦克风,使用的是软件唤醒,实际表现的唤醒率达不到95%,后来使用6麦的麦克风(使用6麦其中一个原因是为了进行声源定位),使用硬件唤醒,唤醒率明显提高了很多,但是误唤醒率也有一定的增加,这需要根据场景调节阈值。成本是增加的,但是相比效果,我们更要求好的效果,而且服务机器人售价并不低。
语音识别实际效果对比了云知声,声瀚,科大讯飞(普通话,办公室安静环境,人机距离30-40cm),在机器人上的效果差不了太多,长短句识别率都可以(部分专业词汇识别需要优化),但因为考虑到唤醒引擎用的是讯飞的,所以识别引擎也选择的科大讯飞。
基础知识库和业务对话知识库,一种方式是通过使用公司自己的知识库和平台,还有一种是使用外部的开放知识库(比如图灵,讯飞等)和公司对话管理平台能力结合。
除此之外,还用到了人脸识别技术,手势识别技术,声源定位,Beamforming和EC,室内路线规划导航技术等多种AI技术。
使用多种技术引擎对系统和配置都有一定的要求,因为多引擎同时使用时,会占用较大的资源,如果系统和硬件无法支持,会导致多项AI技术无法更好的配合使用(如页面卡顿,交互不流畅等),影响用户体验。
具体系统和配置的选择要看调用引擎的数量和应用环境,比如如果使用widows系统,那么选择酷睿i7处理器,处理速度会更快,但是可能对机器人续航有影响,也会增加成本,这个时候要根据实际情况选择。如果不考虑成本,那么尽可能的使用中高端的硬件配置(硬件如:麦克风、CPU、GPU、内存、传感器等),能让整个产品表现更优。
  1. 硬件选择和构成:
对公司而言,硬件不是主业,核心还是软件和语音语义的能力,因此可以分为两种方式,第一是和其他硬件机器人合作,使用合作方的硬件机器人(国内比如木爷、优必选等,国外引进硬件机器人,如Ina),我们做软件功能的二次开发;第二是自己研发符合我们自己设想的机器人并和我们的软件能力结合。我主要负责的是第二种。
智能服务机器人的硬件外形多以仿人形、拟人化为主,因此设计也会相对耗时。每一个硬件机器人的硬件选择都会要和它的功能有紧密联系。服务机器人硬件除了CPU、电池、散热器、外壳和底座等基础硬件之外,还包括:
  • 高清摄像:做人脸识别
  • Kinect传感器:做手势识别(当时技术不成熟,功能不实用)、人脸识别都行(类似的传感器在国内也有人做)
  • 屏幕:主要的操作界面和视觉界面
  • 麦克风(2麦、4麦、6麦…):可做唤醒、声源定位、beamforming、语音识别等(一般唤醒距离长于识别距离)
  • 喇叭:发声,如果有音乐功能的话,对喇叭的要求会更高
  • 声波传感器/激光传感器:主要做避障,导航等
机器人产品主要是的操作来自于上层软件应用和底层驱动的配合,驱动应硬件完成相应的功能。机器人上层应用可以是客户端也可以是网页,也可以是安卓系统下的一个APP等,具体试系统而定。
服务机器人的整体硬件需要多种部分组成,尤其是外壳、底座等,需要定制,但是量又少,所以机器人成本也比较高,动辄几万、十几万。再加上其他的售后服务等,导致服务机器人的售价可以是十几万到上百万不等。一般的小企业不会购买,而更愿意购买价格低的终端机。
2、项目定制上线
智能服务机器人对应的场景和行业都不固定,只要有类似需求的行业都可以成为我们的客户。比如除了政府和银行,还有旅游、教育、医疗等行业。
项目定制一般分为知识定制、功能定制及硬件定制。一般定制最多的还是知识对话的定制,因为针对不同的企业,业务是必然有不同的。
3、售后运维
To B智能硬件一般的售后运维分为三个部分:语音交互的运维;应用软件系统的运维;硬件的运维
  • 语音交互:语料知识的更新;技能的更新(一般直接在云端进行维护)
  • 应用软件系统:界面的更新;功能的维护(一般是远程或云端更新维护)
  • 硬件的运维:电话或者现场支持(根据机器人的量,量小的话,3-5人的团队即可,量大的话会更多;或者是硬件供应商负责)
二、失败的教训
  1. 成功项目实际场景观察
对已经上线的项目,在允许的情况下可以到实际场景下观察用户的使用情况,用户类型、对用户的使用难度、什么问题问的最多、什么功能使用最多、真正帮助用户解决的问题、是否需要工作人员协助(有的后台可查看)。
实际场景中,发现一些问题 :
  •  有的用户可以简单的问机器人几个问题,能得到回答,但是不多,且能够连续上下文交流的对话少
  • 业务话术过于标准,用户问的问题非常口语化,会导致一些问题无法理解
  • 虽然有使用引导,但是接触机器人的用户少,有的人试了几下不会用就不用了,偶尔现场工作人员也会在旁协助
  • 现在网上办理业务很方便,去服务大厅的人不多,中年老年居多,有的本地口音会比较重,就很难得到正确的回答
  • 如果大厅很嘈杂的时候,机器人的识别会变差一点,有时会导致无法正确回答
  • 导航功能在大厅应用的少,因为大厅本身就不大,用武之地比较少,而且机器人行走较慢,跟不上人的步伐,很难能像人一样自由穿梭在人群中。
  • 正在业务大厅的时候,机器人的娱乐功能基本上没有人用,只有在做演示的时候,这样的功能才能吸引大众
到后来,真正在业务大厅的服务机器人,用的人会越来越少,大部分时候是现场工作人员只要给机器人开机后就放在那里。
所以,实际上,虽然可以帮助用户回答业务问题,但真正使用的用户不是很多,使用的用户由于对智能交互不熟悉、口音、噪音等问题也不能很快得到答案,几轮机器人回答不知道,就会导致用户蒙圈。还有的客户会说当用户使用的时候他们工作人员就会在旁协助。
虽然完成产品和上线项目,会有成就感,但实际看到的却会有种挫败感。除了环境、用户陌生等外在因素,其实,这和目前本身机器人的技术能力也有很大关系,目前的人工智能技术大都还不成熟,技术能还不能使机器人达到每次都能准确理解用户的每句话,不能达到和人完全自由流畅的交流。
这个问题不只是我们的产品如此,其实整个市场的现状就是这样,很多做机器人的公司突然涌出来,基础参差不齐,我们还是其中做得不错的。很多公司宣传的很智能,但是实际并非如此。
2、失败项目案例教训
曾经有过失败的项目,当时机器人在客户现场,但是客户总负责人却认为机器人和他想象的不符,认为机器人不像他想象的那般智能,通过了解知道他所想象的是当时技术很难实现的机器人的能力,至少是需要耗费大量精力去慢慢训练的,比如希望机器人能够用自己的语音唱歌。最终这个项目已失败告终,其中一个原因是给客户期望值太高,现实与想象差距较远。不置可否,也许智能服务机器人的发展可能才刚刚开始。
3、对未来发展的看法
智能服务机器人未来的发展必然还有很多山路要走,也依赖人工智能技术的发展。就目前而言,我认为服务机器人更上一层楼很难,需要更务实一些,产品要稳定,要尽可能降低成本,最好能找到用户能够经常使用到的业务结合点,突出一两个优点,能真正帮助用户或者客户解决某个问题。外形不一定要像人,但是要让它和人的交互更舒服更流畅。
三、总结
  1. 目前语音交互技术可以实现问答对话,但还达不到能和人自如交流的问题,尤其在远场语音交互环境,还存在一些困难。
  1. 在有用户界面的情况下,GUI界面应和VUI界面相互配合,帮助用户快速完成操作。
  1. AI技术里包含很多,但现在大部分的AI技术发展基本是各发展各的,没有相互融合。
  1. 智能服务机器人场景杂、行业多、再加上业务的差异,难在多个行业深入下去。
  1. 想真正在这些场景做好机器人的服务并非易事,还需不断的摸索,现阶段更重要的是保证产品稳定,易用(VUI和GUI相互配合)。
  1. 目前还在人工智能初期,应该是所谓的弱人工智能,技术还不成熟,机器人虽能够解决一些简单的业务问答、识人和路线导航等,但还存在许多不足。
  1. 从2016到2018年,有些机器人公司倒在市场的血泊,或不在出现、或改头换面重来,有些机器人公司抓住大树,得以喘息、继续前行。只要人工智能的发展越来越好,我相信,智能服务机器人的未来也会越来越好,这只是刚刚开始。

 hanniman hanniman 6月6日

 

智能客服,是现阶段非常明确的“能够赚钱”的AI细分领域;但是,“能够赚钱”并不意味着可以“赚大钱”,或者“很快而容易的赚大钱”。

本文主要从产品视角来聊聊,智能客服产品方向,可能的2个坑和2个出路。

1

智能客服产品方向,可能的2个“坑”

1、现阶段,做“通用智能客服系统”,很可能是一个“大坑”

从结果看,不论是技术还是产品方面,现阶段都支撑不了通用智能客服的落地,但是,这部分的探索,本身也是有益、甚至绕不过去的环节;对部分公司来说,就应该用心去做,然后才能更好的做非通用领域的落地。

如追一科技产品负责人@汶林丁 所说:

我们刚开始的时候,就是在做一个通用工具集、积累方法论;经历的业务多了,才能知道,哪些是智能内核,哪些是业务层面的事情,这块只有踩过很多坑,才有去通用化、组件化的动力,也会体会边际成本不断降低的快感,相当于在证明复制性,这也得益于我们之前在腾讯是做架构出身的。

2、做“垂直行业的智能客服解决方案”,如果价值定位还是“(为垂直行业)节省客服成本”,虽然可能养活团队,但会是一个hard模式;因为往往会被局限在为几个大客户做项目,一旦没处理好下面几个绕不过去的槛儿,很可能也会倒进坑里。

1)最大最大的难点是,如果AI团队本身不具备该垂直行业经验,很难做出真正好的解决方案。很多时候,AI团队需要深入大客户公司内部去了解业务流程、细节、问题等,甚至有观点认为,核心门槛就在“把问题梳理清楚”——如果问题梳理清楚了,很多时候就大概知道该怎么解决了,而大客户公司有多年经验的内部员工,自己都梳理不清楚问题……

2)退一步讲,如果把问题梳理清楚了,又可能出现一个新的不利情况:如果只是解决20%的核心问题,甚至都不一定需要用到真正的AI解决方案……曾经听说,某公司用一套自己创造的“粗暴规则+大量人工”方式,就能很现实的解决问题,已经从一些AI公司手里抢到了大单。

而且,真正有极大“降低客服成本”需求的公司,很有可能自建团队来做的。既有成本考虑,也有数据安全考虑。比如滴滴,很多人没想到的是,滴滴已经是国内人工客服成本最大的公司了,而相关数据又非常敏感,所以滴滴有极大的动力去自建智能客服团队。还有阿里,也是花了几年的时间,把网上购物等领域的客服相关问题梳理清楚,花了很多人工整理大量有效数据,然后才一步步的把智能客服真正落地的。

3)再退一步,暂且不纠结“AI方案”是否能绝对碾压“粗暴方案”(即,假设各家公司的方案都能部分解决客户的问题),这时,还会面临竞标时的“搞关系”问题

4)假设很幸运,拿到了某个大客户的单子,那后续怎么办呢?垂直行业内的大客户公司就这么多,公司收入的增速和总量,都会有天花板。而且近似外包的做项目,还意味着成本也是在线性增加的

5)如果大公司不好做,那小公司呢?一般中国的中小企业,即使觉得“减少人工客服成本”是好事,但更大的动力还是在“如何增加收入”,即,如何拉新、如何提高转化率等。

3、如果价值定位还是想设定在“节省客服成本”,可以怎么做?

如图灵机器人-产品负责人@蜗牛 老师在《系统化思维,AI产品经理的必修课》中分享的:

解决70%都会被问到的问题。30%人本身也解决不好的问题,智能客服也解决不了。要把问题范围框定在能解决的范围,并给客户算账(输出成客户能理解的语言:省了多少钱,我们赚的钱只是省的钱的一部分)。

比如,在去年9月份一个大会上,有嘉宾分享过其公司的2个合作案例:1)建设银行,日均300万交互量,相当于9000个人工坐席,对应9亿元的人工成本;2)交通银行,月均代替的呼叫量为200万次,对应月均成本140万。

2

智能客服产品方向,可能的2个“出路”

大方向来说,目前这个阶段做AI落地,“直接代替人”是非常危险的(不论从产品体验,还是从商业可行性来说),建议更多考虑如何“AI辅助人工”。

下面,从2B和2C两个方向分析。

1、2B

不是给客户提供“NLP技术方案”,也不是给客户提供“智能客服产品方案”,而是给客户提供“智能客服商业方案”,即,重点不是告诉客户我们产品技术的“准确度”或“问题解决率”有多高,而是直接阐述商业价值——如何能帮他拉新、提高转化率、提高满意度等。

比如,对于“如何设置智能客服的评估指标(体系)”这个问题,常规想法可能是,完全从“有用”、“效率”角度出发,去看“问题解决率”(不确定各家公司是否这么命名,总之类似这种说法吧)。

但是,是否可以更关注用户体验?举例来说,当用户问题没有被解决的时候,是否能有些更友好的交互体验(比如更有好多引导流程/文案、设置一些小彩蛋等,有很多可以挖掘的东西),让用户不那么生气,重新再来尝试一次,或者即使这次失败了,也不至于“对这种AI客服模式或者这家商家产生严重的抵触情绪、进而以后再也不来了”。

相当于,“问题解决率”,关注重点仅仅是“这一次”用户需求的满足情况,而“用户满意度”,导向的是长期用户需求的满足。

以上这个想法,好像也没什么特别的,大家也许都能想到。但为什么没人这么去做呢?不能说我的想法一定是对的(其实也是拿出来抛砖引玉),但这个想法背后存在一个认知的区别:

假设目前行业AI技术水平,“解决问题效率”是93分,很多从业者可能认为,通过AI技术,也许有可能做到98分,还有很大空间可以去做AI技术探索,值得把很多人力资源投入进去;而我的认知是,很可能95分、甚至94分,就是“目前”整个AI行业技术水平的天花板了,1、2年内,可能更应该投入“可控”的人力去做技术攻坚,而把更多的资源倾向给AI产品经理们,放到“提高用户体验效果”的探索方向去,这方面,可能做几个中等量级的优化feature,就能够整体提升2~4分的产品价值。

为什么这2种想法,差别这么大呢?

可能是因为,很多从业者是技术背景出生,虽然他们也知道,目前AI技术水平,并没有根本性的突破,但是,他们只有“技术”这一个认知维度;而如果我们从产品或商业出发,至少会多出1~2个维度。

举个例子,大家都知道对于Siri这种语音助手产品,成年人去和她交互,问10次,即使9次都对了,只要1次回答不好,那么1个月之后,用户慢慢就再也不用了。——也就是说,从纯技术角度来说,即使已经做到了90分,但是在产品角度来看,这个模式的用户价值不足60分;如果再考虑商业价值,可能就不足30分了(至少现阶段是这样,未来也许有机会)。——也就是说,技术维度+产品维度,不是在做加法,而是在做“归一化”,是不能把90分作为整体产品价值的baseline的。

2、2C

基于现有的智能客户产品技术条件,如何应用到普通用户?有正反两个例子。

1)不成功的magic模式(AI+HI)

前几年,有一批中国公司copy非常火的magic模式(AI+HI),目前来看没有太成功的,主要原因可能有:

A)需求定位的两难(长尾 vs 头部)。对于高频需求,用户本身用app就能解决了;而如果想覆盖太多长尾领域意味着,需要更多细分领域的专业客服;而“更多细分领域专业客服”的投入产出比是不经济的。

B)做MVP验证的思路问题(注:MVP,minimum viable product的缩写,意为“最小可行性产品”)。2017年10月23日,我曾在饭团“AI产品经理大本营”里分享过:

……没必要一开始就去挖大价钱挖大量的AI技术人才,因为他们(magic模式)提供的本质价值是(对接)服务,所以做MVP验证时,需要用真人来模拟、走通闭环就行,等验证成功了再挖AI技术人才

而且曾经有该领域公司技术负责人亲口给我说过,他们的技术没做那么深入,因为很多情况下,回复语料(即回答数据)就能够满足用户了(不一定完美回复,但是“可接受”的)。

即,这背后的逻辑是:如果用人工,一开始就能有80~85分的效果,但如果用AI,一开始只能有60~70分效果;所以,如果用人工做MVP,用户都用不起来,就没必要大投入AI技术了;但如果一开始用AI实现,很可能由于效果没有足够好,而无法判断MVP方案本身是否OK,甚至可能被AI研发周期和成本给拖死。

另外,关于MVP方面,再分享下追一科技产品负责人@汶林丁 的实战心得:

……在标杆客户的身上收集需求,从而打磨一个MVP的产品出来,慢慢上线运营,从解决基本需求到运营到体验,不过这个过程也非常痛苦。只有有标杆性的企业需求满足后,产品解决的问题,才有代表性和可复制性。

“从解决基本需求到运营到体验”,是很务实的思路。

2)最近非常火的Google  Duplex

Google最近在其个人助理 Google Assistant 中,新增了Duplex功能,可以帮用户给饭馆、理发店等商家打电话沟通、预订。

这里的精妙之处在于,虽然表面上AI是在服务于普通用户,但真正的AI对话产品体验的交互对象是商家的客服人员,而这类人群本身的对话流程、语言方式甚至语料内容都是相对更加清晰可控的!详见《会打电话的 AI 背后:谷歌Duplex技术解析》。

即,反过来说,如果AI技术表面上是服务于客户公司,但最终产品对话体验的交互对象其实是普通用户,那么,对于现阶段AI产品技术来说,这种对话流程非常不可控的。

可以说,Duplex这个例子正好证明了我一直以来的观点:现阶段的AI产品技术,虽然还不完美,但已经完全不影响我们做demo了,而这正好是我们AI产品经理施展的机会——这需要有一定的AI技术理解力+垂直场景认知积累+AI产品落地方法论,这些,都是我在饭团“AI产品经理大本营”里,经常会分享的。

最后,针对“智能客服作为AI产品经理的发展前景”,简单分享2点:

1、智能客服,是很好的入行AI方向。因为相关公司可选范围不少、相关职位类型高中低都有(AI产品经理、人工智能训练师、数据标注等)、面试门槛没那么高(对NLP有一定了解,或者,如果有垂直行业经验的话,会更有机会)。

注:扩展阅读《深度报告 | AI新职位“人工智能训练师”

2、但是,锻炼成长后,要明确自己的长期积累方向,是在哪个更能落地的领域,即,最好不要局限在给垂直行业大客户做项目的公司,更好的可能性是

1)2B,阿里、滴滴这类大公司内部的智能客服部门;自己公司内,就有很好的落地场景、用户量、数据和锻炼机会。

2)2B,价值方向不是“准确度”或“问题解决率”,而是直接阐述商业价值——如何能帮他拉新、提高转化率、提高满意度

3)2C,有更多的产品创新可能性。

注1:曾在饭团“AI产品经理大本营”里分享过6份智能客服相关的行业公开PPT,涉及几家行业领先的智能客服产品;下载链接,可点击最后的阅读原文

注2:饭团“AI产品经理大本营” ,是黄钊hanniman建立的、行业内第一个“AI产品经理成长交流社区”,通过每天干货分享、每月线下交流、每季职位内推等方式,帮助大家完成“AI产品经理成长的实操路径”;详情可点击“阅读原文”查看。

前言:本文作者是团员@Wing微信公众号:鸡翅姐

本文分3个部分:

一、客服机器人的分类和决策引擎

二、客服机器人的数据来源与使用方法(重点)

三、客服机器人的知识管理方式(重点)

一、客服机器人的分类和决策引擎

1、客服机器人的分类

无论是哪个领域,只要是一个定位明确的客服机器人,其产品设计的目标都是通过最短路径为用户提供服务,“服务”包括信息查询(比如电商场景下的查询订单状态)、购买咨询(比如保险场景下的产品购买建议)、FAQ类咨询(比如公司地址与联系电话等)等等。

如下图,我把客服机器人与用户的对话,分为三个类型:

  • 寒暄类:与核心业务流程无关的对话,可以统称为“寒暄类”,也是客服机器人的兜底话术。我这里没有用“闲聊”,是因为我个人不认为“闲聊”是客服机器人应提供的核心服务之一。
  • 任务类:通过一或多轮对话的方式帮用户完成某项目的明确任务。
  • 咨询类:为用户答疑解惑,通常为一问一答的方式,也包括通过澄清和指代消解而产生的多轮对话。

本文分享的内容,主要是聚焦在(针对于)咨询类对话

从实现方式上作区分,咨询类对话又可以分为检索式语义匹配式KBQA三种;然而,在咨询的时候,用户是感知不到这三类的区别的——用户的诉求很简单:通过最短路径获得准确、直观、完备的答案。

2、客服机器人的决策引擎

客服机器人在解析用户query的第一步是在去判断用户的意图。意图检测是由叫做“Route bot(路由机器人)”的系统来完成,比如,当用户输入“我银行卡余额”时,可以识别出用户此时是想完成“查询银行卡余额”这一任务;而当用户询问“银行卡余额在哪儿可以查”时,则需要识别出用户需要一个查询银行卡余额的路径。确认用户意图后,路由机器人再将此query交给不同的“子机器人(Botlets)”去处理。最后,Botlets生成的回复将在策略中心完成融合、去重和重排序等过程,最终产生一个或一组最优解

下面这幅流程图,描述了从用户Query到生成回复的过程。该流程的每一步都值得深挖,但由于不是本次分享的重点暂不赘述。

 (摘自https://blog.csdn.net/qq_40027052/article/details/78723576

从用户query–>机器人response的整个决策过程,是由数据、算法和算力共同支持的、由下到上的过程,同时也类似于人类从懵懂到形成“直觉”的过程。

在客服场景中,我们尝试去重现的,就是一个积累了业务流程知识产品与服务知识以及用户交流技巧的客服人员。

对于刚上岗零经验的客服人员来说,Ta首先需要了解的,通常是以下几点:

  • 服务的边界:自己负责的产品线/业务线的服务范围是什么?对于不在服务范围内的项目,如何与客户沟通?
  • 服务的特色:有哪些是服务的核心亮点?如何在服务的过程中巧妙地趋利避害?
  • 升级渠道:服务过程中遇到难以解决或意外情况如何处理?

通过培训与实操,客服人员逐渐从每日的工作中成长起来,一方面,对公司的服务内容愈发熟悉,另一方面,总结着保证用户满意度的方法。类似的,当我们培养一个客服机器人,也需要让Ta经历“培训”和“实操”的过程。本文,我们主要探讨的就是如何培养客服机器人的数据能力。

二、客服机器人的数据来源与使用方法

前文提到,咨询机器人可以通过“检索式”、“语义匹配”以及“KBQA”三种方式来生成答案,其实,上述每一种方式都需要收集相应的语料来训练,且不管是哪一类语料,从数据的结构化程度来说,都可以分为以下三种:

1、结构化数据:指可以使用关系型数据库表示和存储、表现为二维形式的数据。例子: 

最多 22 列
  • 剪切
  • 复制
  • 粘贴
    请使用 Ctrl+V 粘贴
  • 向上插入 1 行
  • 向下插入 1 行
  • 向左插入 1 列
  • 向右插入 1 列
  • 合并单元格
  • 取消合并单元格
  • 删除列
  • 删除行
  • 删除表格

id

name

age

gender

1

lyh

12

male

2

lianyh

13

female

3

amy

18

female

2、半结构化数据:结构化数据的一种形式,它并不符合关系型数据库或其他数据表的形式关联起来的数据模型结构,但包含相关标记。这些标记是用来分隔语义元素,以及对记录和字段进行分层。半结构化数据也被称为自描述的结构。例子:

<person>
  <name>A</name>
  <age>13</age>
  <gender>male</gender>
</person>

3、非结构化数据:即就是没有固定结构的数据。各种文档、图片、视频、音频等都属于非结构化数据。这种数据广泛地存在,但并不直接可用。需要通过一定手段来提取/标注每个数据所包含的关键信息。

下面,我们逐个聊聊这三种类型的数据如何获取与使用

2.1 结构化数据的来源与使用方法

目前大多数的DUI平台,都支持以“Question-Answer”的格式批量导入语料。比如下图,是海知智能(ruyi.ai) 机器人平台提供的知识库批量导入模板与示例。

最多 22 列
  • 剪切
  • 复制
  • 粘贴
    请使用 Ctrl+V 粘贴
  • 向上插入 1 行
  • 向下插入 1 行
  • 向左插入 1 列
  • 向右插入 1 列
  • 合并单元格
  • 取消合并单元格
  • 删除列
  • 删除行
  • 删除表格

用户说

机器人答

怎么联系你们

请关注艾如意宝宝。

晚安

晚安,睡个好觉!

晚安

晚安,做个好梦!

晚安

晚安,好梦啦

你好

好呀!

以及图灵机器人配置平台提供的批量导入模板:

最多 22 列
  • 剪切
  • 复制
  • 粘贴
    请使用 Ctrl+V 粘贴
  • 向上插入 1 行
  • 向下插入 1 行
  • 向左插入 1 列
  • 向右插入 1 列
  • 合并单元格
  • 取消合并单元格
  • 删除列
  • 删除行
  • 删除表格

问题

答案

相似问法

(不限制条数)

关键词

(多个关键词请用英文逗号分割!)

以及思必驰会话精灵知识问答批量导入模板:

最多 22 列
  • 剪切
  • 复制
  • 粘贴
    请使用 Ctrl+V 粘贴
  • 向上插入 1 行
  • 向下插入 1 行
  • 向左插入 1 列
  • 向右插入 1 列
  • 合并单元格
  • 取消合并单元格
  • 删除列
  • 删除行
  • 删除表格

问题

相似问题

(最多9个)

答案

相似答案(最多4个)

question

question

answer

image

_url

link

_url

answer

image

_url

link

_url

当客服机器人有这样一个充满QA语料的知识库之后,就可以通过基于语义相似度的Q-Q匹配模型,从知识库中召回与用户query相似度较高的几个标准问题。(注:有相关的参考文章《NLP基本功-文本相似度 | AI产品经理需要了解的AI技术通识》

然而,从我观察客服手工整理知识库的经验来看,扩充相似问题/相似说法并不是件容易的事情,特别的,当涉及到垂直领域业务强相关的问题时,客服人员很难开脑洞给每个问题想出几百种不同的问法。我司的客服机器人在上线之前,相似说法/标准问题的比率大概在10

然而当机器人上线之后,我们从每天客服bot与用户的聊天日志中找到了灵感。在聊天日志中,我们主要关注并收集了大量“未应答问题”(由于置信度不够没有返回答案导致的badcase),这些未应答问题一部分可以作为存量标准问题的相似说法,还有一部分为新增标准问题提供了灵感。我们发现,让标注人员去“猜用户的疑惑”的难度远高于“将用户query标注为扩展问”。做填空题是难于做选择题的。

因此,我们的知识库平台在多个环节,都会尝试引导知识库管理员去标注扩展问。这里简单分享两个设计点:

1、助手机器人:平台内部用于测试问答表现效果的Demo机器人。

知识管理员在与Demo bot对话时,通常会通过口语化的表达来测试问答匹配效果。在Demo界面,我们提供了与测试query语义最相似的Top 5列表。如发现问题匹配错误,可以在测试的过程中,及时将测试query映射至其他的标准问题,这既是纠错、也是标注相似说法的过程。

2、日志挖掘:将与未应答问题相似度最高的Top 5标准问题返回给知识管理员进行标注。

为了提高标注效率,可以考虑根据语义相似度,先将未应答问题做聚类,然后标注人员再统一将这一组问题映射至一个标准问题。并且,出于标注的准确性考虑,我们会提供上下文信息给标注人员,以帮助其更好地对bad case进行分析。最后,要想继续提高效率与精准度,可以根据业务发展情况与线上的表现来做调整。

此外,如果在上线客服机器人之前,业务已经有线上客服的渠道或者论坛(类似于百度知道/知乎的版块),则可以在设计机器人初期,就将线上客服沉淀下来的数据做清洗,并从中提炼出热点/高频问题优先进行梳理

讲完结构化数据后,下面我们讲讲半结构化知识数据的来源与使用方法。

2.2  半结构化数据的来源与使用方法

假设我们需要给耐克设计一个客服机器人,对于如下所示的产品类信息,可以从哪里低成本获得呢?

最多 22 列
  • 剪切
  • 复制
  • 粘贴
    请使用 Ctrl+V 粘贴
  • 向上插入 1 行
  • 向下插入 1 行
  • 向左插入 1 列
  • 向右插入 1 列
  • 合并单元格
  • 取消合并单元格
  • 删除列
  • 删除行
  • 删除表格

产品名称

所属类型

产品颜色

产品价格

库存

Air Jordan 1 Retro High OG

复刻男子运动鞋

帆布橄榄绿/帆白

¥1299

100

如果你本身就是这家企业的员工,那一定能找到product catalogue(产品目录)。它可能是以多个excel文件的形式散落在各个部门,也有可能已经被存至数据库、并应用在官网或其他电商渠道。如果客服bot所需的部分信息已经在线上,直接去爬取就可以获得大量半结构化数据。当然,在爬取之前,需要对目标网站内容的可信度进行充分评估。若从多于一个渠道爬取数据,则还涉及到数据融合的问题。

当我们有一个整理如上述格式的产品目录之后,就可以通过搭建知识图谱来回答以下几个问题:

  • “复刻男子运动鞋”类有哪些选择/产品?
  • Air Jordan 1 多少钱?
  • 绿色的鞋有哪些选项?
  • Air Jordan 1 有货吗?

也可以基于简单的推理回答以下问题:

  • 价格在800-1000左右的鞋有哪些选项?
  • Air Jordan 1 和 Air Force 哪个便宜?
  • 除了Air Jordan 1 之外,绿色的运动鞋还有哪些选项?
  • 复刻系列里面最便宜的是哪一款?

大家可能尝试过,在Google或百度的搜索框里直接问一些与人物、机构相关的问题,比如“微软的创始人是谁?”,它会直接把比尔盖茨的信息卡片返回给你。这个过程,就是基于底层的一个庞大的人物&机构知识图谱。当然,你的知识图谱能回答哪些问题,是需要根据图谱搭建的深度和广度去人为定义模板的。比如“绿色的鞋有哪些选项?”这个问题就会被解析成一个“ ? (产品)—颜色属性—绿色”的查询语句,在整个知识图谱中完成搜索,并输出符合该条件的答案。

这种基于知识图谱构建的问答也被叫做KBQA与客服手工构建QA pair相比,KBQA的最大好处就是可以回答预设好的“几类问题”比如说“XX色的鞋有哪些选项?”,就是一类问题,而XX这个实体的值可以是任何颜色。这样就不需要手工去逐个编写“蓝色的鞋有哪些选择?”“红色的鞋有哪些选择?”…从而节省了大量的人工标注成本。

2.3  非结构化知识的来源与使用方法

之前我们讲过,非结构化数据就是没有固定结构的数据,而“在线客服与用户的聊天日志”就属于非结构化知识。在3.1小节提到过,可以把聊天日志中用户的Query抽取并清洗出来,进而丰富问答语料。但其实,如果你保留了大量的对话片段,也可以使用检索式模型从库中pick最优回复。

 

基于检索的对话模型所需的语料形式是“Context-Utterance”,即“上下文-回复”对,而标签则是“0”和“1”,其中“1”表示该Utterance可以作为Context的回复(见下图:Ubuntu Dialog Corpus的样例)。

最多 22 列
  • 剪切
  • 复制
  • 粘贴
    请使用 Ctrl+V 粘贴
  • 向上插入 1 行
  • 向下插入 1 行
  • 向左插入 1 列
  • 向右插入 1 列
  • 合并单元格
  • 取消合并单元格
  • 删除列
  • 删除行
  • 删除表格

Context

Utterance

Label

well, can I move the drives? I guess I could just 1 __EOS__ ah not like that 

I guess I could just 1 __EOS__ ah not like that get an enclosure and copy via USB

1

well, can I move the drives? you can use “ps ax” 0 __EOS__ ah not like that

you can use “ps ax” 0 __EOS__ ah not like that and “kill (PID #)

0

(摘自Lowe et al., 2016. The Ubuntu Dialogue Corpus: A Large Dataset for Research in Unstructured Multi-Turn Dialogue Systems)

模型的原理和实现细节,就不在此赘述了。该模型的本质,是一个预测模型,即对于一个输入的Context,预测某个Utterance为合理回复的概率。比如,当我的库中已经有了大量与手机维修相关的Context-utterance正样本后,当该情景再次出现时,我会将最大概率为正确回复的Utterance返回给用户。 

(摘自Bartl & Spanakis, 2017. A retrieval-based dialogue system utilizing utterance and context embeddings.图中的Context描述了一个手机维修的对话场景;“Actual Response”是该Context的真实回复内容。而“HREDG-CAR”是文中所用模型召回的三个最佳候选回复。)

如果要使用这样的方法来生成回复,那需要标注人员做的,就是将在线客服与用户的聊天记录做场景化整理比如“报修”、“退换货”、“补差价”、“优惠券领取”等。对于情景复杂、需要上下文信息的咨询类场景来说,可以尝试使用这样的模型。

三、客服机器人的知识管理方式

客服机器人与闲聊机器人最大的区别,在于前者是与公司的核心业务强相关的,而后者不是。因此,做客服机器人的知识管理,需要考虑到知识的时效性、专业性和一致性比如,活动类的QA有起效和过期的时间,在到期之前和过期之后,都要给客户/用户一个友好的引导;服务和产品类QA需要与用户属性相关,比如,对于不同的新客户和VIP客户,即使是同一个问题,其答案也要做差异化的回复和引导;还比如,对于同一个用户,如果Ta在不同时间、不同渠道(比如官方小程序、App、微信公众号后台)问了同一个问题(比如某某分店的地址是哪里联系方式是什么),我们需要确保答案(表意)的一致性,否则会使用户迷惑。

因此,客服机器人的知识库构建,不仅需要Q-A相关的信息,也需要其他的字段来给Q-A做描述或限制。这里,就需要产品经理结合公司的核心业务来做深入思考,并设计一个拓展性强、可用性与灵活性高的知识管理平台。

这个知识管理平台,需要兼顾对语料的管理和对聊天日志的管理,并结合NLP手段尽可能地降低bad case的分析与标注成本。如下图,知识管理平台需要给知识管理员提供一个bad case标注功能,用线上数据快速扩充语料并优化模型。

 

除此之外,引导并鼓励知识管理员去丰富专业词库丰富问答语料将匹配度较高的标准问题标记为用户query的负样本,都对提升问答引擎的表现有帮助。当然,以上功能点的重要性以及投入产出比,需要产品与算法工程师以及业务负责人沟通后再决定优先级。

-END-

 

机器人可以算得上是一个先进而又古老的词汇,科幻小说中的种种展示着人们对它的完美预期。但机器人发展几十载,业界至今对它还没有明确的定位。小谛机器人科技有限公司CEO彭军辉深耕机器人大脑多年,对于他来说足够“聪明”的机器人才能称得上是机器人。消费者需要什么样的机器人大脑,也是彭军辉一直在寻找的答案。

 

氖星智能 彭军辉

 

前两年机器人行业获得了社会各界广泛关注,而最近几年机器人行业似乎进入了低潮。

我认为行业进入低潮也是相对的。前两年的蓬勃发展不过是虚火过旺。这个行业有一些关键性问题并没有得到解决。

关于什么是机器人,行业甚至没有公认的标准。有人说人形才叫机器人,有人说会语音互动才叫机器人,有人说会自己行走才叫机器人。以至于故事机、刀削面机都自称机器人了。

这里不需要讨论什么是机器人,因为大家的角度不一样,必然理解也不一样。让我们先讨论下消费者需要什么样的机器人?

 

1. 消费者需要什么样的机器人

大家都知道目前智能手机和电脑已经非常强大,已经极大地提高了我们的工作效率。那为什么我们还需要一个机器人呢?这就要从智能手机和电脑的的短板说起。

最早我们在电脑输入汉字需要学输入法。有阵子流行五笔字型输入法。我是上的电脑培训班才学会这个输入法的。当时我就想,既然电脑这么强大,为什么它不能理解人而需要人去理解它呢?

对,这就是智能手机和电脑存在的问题——它们需要人去理解它们的规则:理解它们的系统结构,记住每个功能的使用方法,学会开发语言的格式等等。

这便让使用手机和电脑变成了有一定门槛的事情。你最起码得识字吧?你还得有一定的智商。现在还有很多人不会使用电脑和智能手机。

如果和一个人交流,你会发现要比和一台电脑一部智能手机交流要简单得多。如果对方足够聪明,即便你有语言障碍,对方也会明白你含混不清的表达。如果对方足够聪明,即使你表达了只言片语,对方也会理解你的想法。如果对方足够聪明,即使你一言不发,仅仅通过猜度,对方也会理解你的想法。这是为什么呢?因为对方是智能的,是人类。

那么能不能把人类的智能赋予机器呢?这样即使不识字,即使半文盲或者文盲,即使老年人也可以和机器顺畅交流了。

很久以来我们都期望有一个和人一样聪明的机器。电影电视里描绘了各种机器人的样子。他们有的是人形的有的不是,有的会说话有的不会,有的会动,有的只是一套系统没有外形,但他们的共同特点都是——能理解人类的意图。

能理解人类的意图,这才是市场需要的机器人。

有人说你这个根本不可能实现。

但市场需求就是这个样子的。能不能实现是厂商的事情。

 

2. 为什么说操作系统不能解决机器人的问题

前几年有很多厂商声称自己是做机器人操作系统的。有些厂商甚至在机器人操作系统上投资了很多资源。

然而,收效甚微。

机器人最核心的问题是怎么更好地理解用户意图。而操作系统则并不是主要解决这个问题的。有些做机器人操作系统的厂商甚至更关注怎么和硬件对接。

操作系统是位于用户和硬件之间的系统,它把用户的命令传递给硬件,由硬件完成再通过操作系统反馈给用户。它包含了和用户交互的部分,也包含了和硬件交互的部分。

和硬件交互的部分机器人和电脑手机并没有多大差别,直接从电脑和手机的操作系统继承和升级就可以了。

难在和用户交互的这部分。这部分做不好,机器人和电脑手机就没有什么区别了。

如果还用电脑和手机操作系统的思维模式去开发机器人的操作系统,基本上不会有什么升级和革新,做出来的不过是个电脑或手机的操作系统。

机器人需要理解用户意图,电脑和手机处理的是用户命令。这两者有什么区别呢?

用户命令是明确的,固定的,有限的。比如开机、关机,就是明确的。用户命令是机器语言,是个固定的集合。

但用户意图则是模糊的,变化的,无限的,是用自然语言表达的。比如用户说“吃”,是要吃什么呢?谁吃呢?同样表达“吃”这个想法,用户可能说的不是这个词而是“我”“想”“要”“给我”等等。

对用户意图的理解是个思辨的过程,而操作系统只能做条件反射式处理。

所以,我认为操作系统解决不了机器人的问题。消费者需要机器人大脑。

 

3. 什么样的机器人大脑才是好的机器人大脑

个人认为,机器人大脑是机器人的推理、决策、学习系统;它根据用户意图,经过推理和决策,指挥相关底层系统,为用户做出合理的反馈。

它不是用户界面UI(User Interface)系统,UI系统把用户语音或者文字信号输出给机器人大脑;大脑通过推理和决策,做出恰当地处理。UI系统是用户界面,只是条件反射式反馈信息。

机器人大脑的主要功能也不是硬件驱动。

用户界面和驱动系统是操作系统的两大组成部分。而机器人大脑和这两个东西则是完全独立的。

机器人大脑主要的作用是准确理解用户意图。它处理的对象是用户意图,处理的主要媒介是人类自然语言。另外,它的处理媒介也可以是手势、表情、语音之外的其他声音信号、旗语、手语、交通信号等等。

它对用户意图的处理是个思辨的过程,是推理和决策的过程,不像操作系统对用户输入的处理是条件反射。你跟机器人说一句话,机器人要去思考你的意图是什么。它要考虑:你说的是不是个省略句,你是不是说错了,你说的话和上下文有什么关联等等。

而操作系统对用户的处理则要简单得多。你在计算机键盘按“1”,屏幕就显示“1”。

操作系统要解决什么问题基本上是由它的软件决定的。不管系统自带软件还是第三方开发的应用,都是写死的程序。

而机器人大脑能解决什么问题取决于它的能力和知识。如果想让机器人具备某项功能只要为它增加相关知识就行,根本不需要开发新程序。而增加知识的过程可以通过一个网页上的表单去完成(这个就是机器人学习知识的过程)。这里说的能力,包含两个层次:一个是因为机器人学会了某条知识而增加的能力,另一个是机器人对人类自然语言的理解能力。显然后一种能力是机器人的核心能力。知识是用人类自然语言表达的,机器人先要有理解语言的能力才能学习知识。

机器人学会了糖尿病相关知识,它就成了一个糖尿病方面的专家;机器人学会了电商方面的知识,它就成了一个导购员或者一个客服;机器人学会了销售方面知识,它就成了个推销员。

这个和人类是类似的。一个小孩子6岁的孩子显然已经有了强大的语言能力了;但他只有通过学习掌握某方面知识才能具备某方面能力。比如学习计算知识,具备了计算能力;学习绘画知识,具备了绘画能力;学习音乐,具备了音乐能力。

这样,我们发现机器人最核心的能力其实是对人类自然语言处理的能力。

一些传统做自然语言处理的公司习惯了用搜索技术做问答。但问答和搜索是完全不同的。机器人大脑需要的是问答技术,而不是搜索技术。

搜索技术的核心是关键字相关性查询。只要关键字有相同的,搜索都会列出来。

但问答技术的核心是语义相似性计算。问答技术要计算句式和用词,处理上下文和对话话题,处理一个问题的多种问法,计算可能存在的输入错误和同音字,以及处理其他和语义相关的问题。

搜索技术虽然也可以用在机器人大脑上,但搜索的处理太粗糙。他们不处理虚词、不处理句式、不处理多音字、不处理上下文、不处理可能存在输入错误,以至于会造成大量语义信息丢失。用搜索技术做问答有的厂商正确率只能做到20%,而大多数厂商平均做不到65%。

我们经过十多年的不断努力,不断升级完善自然语言问答技术,目前正确率平均是大于82%的。我们处理一个问题的多种问法,处理句子之间的细微差别(这种差别可能来自于虚词、句式等),处理句子里可能存在的错误,处理上下文等等。我们对语义的理解就是个思辨的过程。

从操作系统到机器人大脑的转变不仅仅是条件反射到思辨的转变,而且是系统结构的转变。操作系统结构是菜单式的,树状的;而机器人大脑的系统结构是平行的。

你在手机上执行一个应用的某个功能,你要找到这个应用的ICON点击打开它,找到功能再执行。要执行别的应用你要先退出当前应用,找到一个新应用打开它才行。而自然语言交互没法去展示菜单和界面,所以如果系统结构是树状的,用户无法直观理解每个功能在“功能树”的哪个位置,也就没法使用“功能树”。在实际的产品里,厂商为每个功能定义了打开命令,这样就实际上就形成了一个命令菜单。这样做的问题在于,命令不是自然语言,不利于记忆;命令太多增加记忆成本;命令可能产生冲突。比如说“停”是停止放音乐了还是停止前进后退呢?如果机器人正在前进同时还在放音乐,该怎么执行呢?有的厂商甚至把机器人的功能和命令印刷成了菜单,这样就不是机器人了。

我们机器人大脑的系统结构是平行的,也不存在命令菜单。用户不用记忆命令,用户按照自己的习惯表达就行。你可以说“放音乐”“我想听音乐”“听刘德华的歌”“放个歌”“放忘情水”等进入放音乐功能。你可以说“朝前走”“前进”“后退”“朝左转”进入运动控制功能。我们对平行结构的要求是想进入就进入、想退出就退出、不想进入不进入、不想退出不退出。这样机器人对用户意图的反馈才是稳定、可控的。

机器人的算法和系统结构问题处理了,我们发现内容才是最大短板。我们经过反复探索终于找到了一种方法,它可以把网页变成机器人的知识。于是整个互联网都成了机器人的知识库。

目前我们的机器人大脑还在发展的早期,它拥有的知识量还十分有限。但它支持用户自建个性化知识库,不需要机器学习和人工标注一样可以获得很高的准确率。每个用户都可以培养出来自己的个性化专业化的机器人。目前我们平台已经有1000多个机器人,他们能回答孕婴健康、营养健康、糖尿病等等知识。

大家可以在http://www.neonstar.cn建立自己的机器人测试我们产品。

综上所述,一个好的机器人大脑必须基本以下能力:强大的自然语言处理能力、稳定可控易操作的系统结构、完善的知识库。

 

目前机器人行业,尤其是需要和人互动的服务机器人行业,机器人大脑成了行业瓶颈。

这也是我们工作的动力。我们知道我们的工作非常有价值。虽然经过了十多年的努力,依然没有取得商业上的成功,甚至是屡屡失败,我们依然没有放弃最初的梦想。

 

 

这篇文章主要谈谈目前Bot-Skill开放平台中最为核心的技能构建部分,目前国内无论是大厂如百度的DuerOS、Unit或小爱平台,还是诸多创业公司如思必驰DUI、猎户OS、海知智能等均有自家的对外开放平台。虽然这些平台在设计上各有特色和不同,但他们底层的逻辑框架是基本相同的

前段时间的工作实践中,我也设计了Bot-Skill平台(目前还没有完全开放,对内使用中),过程中大量研究了国内外的类似对话平台,包括Google-Dialogflow、亚马逊的Alexa、百度、小爱、思必驰DUI等。所以结合自己的之前学习与实践,尝试抽象出Bot平台的底层逻辑框架和共性分享出来。

在谈具体的Bot-Skill设计之前,先对这篇文章做个简要的说明:

1)主要会谈Bot-Skill平台的偏底层的内在逻辑,也即回答“为什么”的问题。因为功能层面上的体现和说明,业内平台的产品体验与文档已经展现得很清楚,而为什么会进行这样的设计则并没有全面清晰的说明。

2)承接第二点,一些的基本概念如意图、槽位就不再赘述解释。不明白的童鞋,推荐大家去Dialogflow或DuerOS了解。

3)文章目的是对Bot-Skill平台设计中底层逻辑和共性的抽象,所以不会集中拿一个平台说事,在不同模块可能会拿出如百度的DuerOS、Unit、思必驰DUI、猎户OS、小爱开放平台、海智智能等来举例。

目录

一、Bot-Skill平台模型概述

二、Bot-Skill模块化分析

  1. 触发的智能:Intent与Pattern
  1. “三位一体”解析:Slot-Entity-Value
  1. 多模态-回复输出:Response
  1. 基于Context的多轮对话设计
  1. Bot-Skill整体结构与方法论

三.Bot-Skill平台的现状与演化

  1. Bot平台现状与演化方向
  1. 关于语音/语义交互的一些个人看法/观点

一.Bot-Skill平台模型概述

Bot-Skill平台中已经被大家耳熟能详的诸如意图、实体和槽位等概念已经非常普及了,我个人将目前Bot归纳为六个基本要素,这六大要素形成一个基本的逻辑链路,用于解决在接受到一个用户Query后“触发-解析(完整)-执行-返回”这四个基本问题。(这里Query指的是经过ASR和语音转文本后的Query)

这六个基本要素如下:

·Intent(意图)

·Pattern(句式模板)

·Entity(实体)

·Slot(槽位)

·Response(回复)

·Context(上下文)

其中前五个要素(除去用于解决多轮对话的Context),分布在该链路中的不同位置,解决Query从进来到返回结果的子问题。

图-1(Bot逻辑链路图)

1)意图分类/排序

Query文本经过分词后,首先会将该Query进行意图分类或排序,以找到最最有可能的Intent(目前大多以排序模型为主,从中挑选一个权重最高的Intent)。该模块主要涉及的要素是Intent与Pattern,通过Pattern的模板/文法配置与对话样本的模型训练两种方式,让系统更加智能触发对应Intent。

2)槽位完整填充

触发某个意图后下一步要解决的问题,就是将实体填充到对应的槽位。同时要解决的一个子问题就是对于请求后续服务来讲必填的槽位要保证被填充上,这个模块主要涉及的要素为Slot和Entity。

3)意图回复

意图回复针对触发的意图进行回复,也即Response要素。

上面的五个要素的共同作用下,会完成一次对话闭环,当然还有关于Context多轮设计的内容,后面也会以一个模块单独去讲。

二.Bot-Skill模块化分析

2.1 触发的智能:Intent与Pattern

之所以叫“触发的智能”,因为这可能是最能体现AI的地方之一(也可能没有之一….)。将所有相同含义的话抽象为一个Intent在以前不能做到,就是因为不可能去枚举所有的可能话术,而机器/深度学习的模型的特性,可以通过部分的对话样本训练,实现大量的程度可控的泛化。

关于Bot-Skill中的意图和句式模板,各个平台都基本类似,先是自建意图,在意图中输入可以触发此意图的句式模板,为了方便配置,也可以直接引用意图中的槽位,来直接覆盖槽位中所含的内容。

但在Pattern模块还有个经常被忽略的维度:

偏工程构造的句式模板与文法设计,在实际开发一个语音Skill时,即使能够在句式中引用槽位来批量覆盖词汇,但这种抽象程度远远不够。可能还需要枚举大量的“同特征词汇”,可能因为槽位或词汇之间顺序调整就要多造N多个句式,又或者该意图中均为“非必填槽”,还需要枚举各种“有无”情况,都会造成大量繁琐操作。

2.1.1 模板与文法设计理念

关于偏工程特征的模板与文法的设计,很多平台都没有体现出来。它主要解决在配置意图句式中,可以通过简单的功能操作来抽象覆盖大量句式。

在模板符号与文法设计上每家平台都会有所差别,但我个人用三个关键来概括其核心,他们分别是:

  • 抽象
  • 有无
  • 顺序

下面我以对外公开的百度Unit来简单说明一下其设计逻辑。

2.1.1.1 抽象

槽位中的实体,往往是对一个领域内词汇的抽象集合(比如@China-city中会含有所有中国城市名称),在构造句式时引用这个实体,在句式中的该片段只要出现该实体中所含有的词汇就全部会被识别。如果该实体含有1000个值,那么意味着只配置一个句式等于枚举了1000个。

但除槽位/实体之外的词汇,在真实场景中还存在大量的类似具有相同含义,但不同描述的词汇或短语表达。比如一个订火车票的场景,句式前面可能会出现类似“我需要、我想要、我要订、帮我订、订一下、帮我找找….”的描述,如果一个个枚举可以想象工作量之大。但本质上他们可以被解读抽象为一个“查询特征词”集合,所以可以针对这类词汇构建一个模板(命名为:Booking),将类似词语添加进去。句式中只要配置一个模板,就可以承接住用户的不同问法。

它的另一个好处就是这些“特征词模板”也可以积累管理,如果下次要做一个订飞机票、订船票、订酒店的Skill,都可以直接引用相同的【booking】模板。例如:

2.1.1.2 有无

在解决抽象的问题后,句式的触发还有两个维度非常重要,一个是“有无”,也就是句式中的某个要素对于该意图触发来讲的必要性。槽位的“必填性”是一直被强调的概念,但对于句式触发的“必要性”却一直被忽略。对于意图触发来讲,槽位反而不一定重要。(关于这个逻辑如果大家有兴趣,可以看我之前写的一篇关于“意图必要要素理论”的文章)。

比如订火车票这个场景来说,三个槽位“From-city”、“To-city”和“Date-time”均为必填,但对于意图的触发来讲都是非必要的,反而是“我要订、我想订”以及“火车票”这些词汇(非槽位/实体)构成的“我要订火车票”对于意图的触发是必要条件。

了解意图触发“必要性”后,模板中关于“必要性”的设计,就是通过对于一个句式不同要素的“必要性”的可配置,来进一步对句式进行抽象。如果一个意图的触发句式中包含5个模板/槽位,分别为【A】【B】【C】【D】【E】,在不考虑顺序的情况下,假设只有【A】对于意图触发是必要的,其余四个均为非必要。那枚举式的配置下我们需要配置(C4x3x2x1)也即24种句式模板(注意这还是在不考虑顺序维度的情况下)

图-2“有无”维度可配置

如果我们可以针对这五个要素,从对于句式触发的“必要性”上进行配置,也即设定【A】为必须存在,其余四个要素则均为“非必要”,就可以将24种句式模板抽象为只有一种。

2.1.1.3顺序

关于句式触发意图的另一个维度为“顺序”。有时句式模板中的多个要素顺序不同,也会影响意图的触发。比如对于查询天气来讲,这六类要素相同但顺序不同的句式,说出来应该是都可以被触发的::

  • 【city】【date】天气
  • 【date】【city】天气
  • 【city】天气【date】
  • 【date】天气【city】
  • 天气【city】【date】
  • 天气【date】【city】

如果可以针对句式中的要素,从另一个维度即“出现的顺序对于句式触发”实现可配置化,又可以对句式做进一步的抽象。

Unit对这个在这个维度的设计逻辑,我个人认为很好地解决了这个问题。它可以对句式模板中的每个要素的顺序进行顺序配置如“1、2、3”,就代表3个要素只能顺序出现才能被意图触发;其次如果你将多个要素的序号设定为相同,则他们之间的顺序可以完全任意出现,但都能被意图接住;最后如果某个要素的序号为“0”,则可以出现在句式中的任意位置。依照这样的设计逻辑,上面6类需要枚举(在不考虑要素有无对于触发必要性的前提下),就又可以抽象为一种配置,如下图:

 图-3“顺序”维度可配置

2.1.2 模板与文法设计优劣

上面谈了基于特征工程的模板与文法设计的好处,但任何硬币都有两面,它也有很大的弊端。

(1)优势与好处

·让开发者从意图句式/模板的繁琐配置中解脱出来,极大程度抽象句式的配置。

·模板本身具有“可叠加性”,可以随着时间积累和管理。

·对于一开始没有什么对话样本数据去训练模型的窘境,可以通过模板与文法在短期内承接用户大量句式

(2)弊端

模板与文法过于依赖特征工程,而且它的本质与AI理念相悖。它的工程理念还是基于对数量枚举的抽象,以及从“有无和顺序”这种逻辑维度的可配置性出发解决问题,但通过模板/文法的句式最大弊端在于它没有办法通过模型去训练从而持续优化NLU模型。这一点在Dialogflow上有特别的说明,强调希望开发者去通过纯碎的对话文本去配置,以此可以训练模型从而持续优化。

总结下来,基于模板和文法的句式配置效果“短平快”,但长期下来无法实现可闭环的持续对算法模型的优化;而基于纯碎对话文本则需要大量的数据和标注,是一种耗时耗力,但长期积累下来才能有效果的路线。

2.2 “三位一体”解析:Slot-Entity-Value
2.2.1 实体填充槽位逻辑

触发意图后,接下来要解决的问题,如何在Query中抽取关键参数。现在比较熟知的概念“槽位、实体和词典值”是专门用于解决这个问题,主要说下着三个要素是构建了怎么样的逻辑模型,来解决这个问题。

图-4“槽位-实体-值”逻辑

如本模块的小标题,个人习惯将这三个要素Entity-Slot-Value定义为“三位一体”的关系。实体是为了专门承接住用户Query中的关键参数。实体的来源以及其中内涵的具象值则是根据业务场景不同而定。实体中会内含一些该实体的特定“值”,这些值在分词过后会被单独标记出来;与此同时必须创建一个槽位,该槽位必须关联该特定的实体。注意接下来完成“实体填充”这个动作的逻辑条件:

当且仅当该特定实体1中的某一个值1-1出现,并且刚好对应上意图内关联该特定实体1的槽位1的条件成立,那么值“1-1”会插入到特定的槽位1中(否则就乱了),导致“实体填槽”这个动作的完成,也即获得“关键参数”这个结果。

2.2.2 必要与必填

关于槽位的必填功能本身就不多说了,重点在于为什么会有“必填槽”的设定,“必填槽”的设定本身,是为了解决一个限定条件下的问题,这个限定条件刚好连接我在Pattern模块所说的“意图触发必要”逻辑。

一个关联实体的槽位本质上就是一堆领域词汇的集合,这个槽位(所关联实体的内涵词汇集合)可能对于意图的触发来讲是“非必要”的,但对于意图的Action来讲却是必填的,所以才会形成必填槽及其追槽方式的设定。因为对于意图触发“非必要”意味着该槽位可以不出现,而对于意图Action的必填则意味着请求服务必须使用到该槽位的值,那么就需要一个功能去填补这个特殊情况下,把槽位补上的功能。

如果不符合这个限定条件,就不会出现“必填槽”的概念。为了进一步说明,可以通过“必要”和“必填”的二维视角解读:

最多 22 列
  • 剪切
  • 复制
  • 粘贴
    请使用 Ctrl+V 粘贴
  • 向上插入 1 行
  • 向下插入 1 行
  • 向左插入 1 列
  • 向右插入 1 列
  • 合并单元格
  • 取消合并单元格
  • 删除列
  • 删除行
  • 删除表格
必填 非必填
必要 必要-必填 必要-非必填
非必要 非必要-必填 非必要-非必填

首先可以明确的是,对于最后两个“非必填”的维度是不需要理会的,因为他们本身就是“非必填”,如果所有槽位本身就是“非必填”就不需要“必填槽”的概念,所以先将他们这两种情况排除掉,他们肯定不是“必填槽”出现的原因。

其次可以再看“非必要-必填”,这个也就是我刚才提到的“限定条件”,必填槽的功能逻辑就是为了解决这个单一情况而出现的。

重点是在“必要-必填”这种情况。如一个意图中含有两个槽位【A】【B】,他们两个对于意图Action来讲,里面的值都是必须要含有的(必填);同时对于意图的触发来讲,【A】【B】槽位中的值也必须同时出现,也就是说他们两同时存在是该意图触发的“充要条件”。只要该意图被触发,【A】与【B】槽位中的值是已经必然填充上的,那这种情况是不需要“必填槽”的设定以及后续的补槽功能,因为“充要条件”是可以因果互推的,意图触发则可以反推出【A】【B】已经必然被填充上。

举一个具象的例子,一个“查询人物的某种属性”的意图,【人物名称】与【人物属性】两个槽位只有同时出现,这个意图才能被触发:

  • 【@人物名称】的【@人物属性】是什么?

当该意图被触发的时候,就意味着执行意图的两个必须有的槽位值已经被填充上,无需必填槽的设定及追问等方式。

通过上面两节,大概说明了在“Slot-Entity-Value”这个模块是如何解决获取关键参数这个问题的逻辑,与之对应功能上的体现,有创建/引用实体;在槽位列表中,也需要给被创建的槽位“引用特定实体”的功能。

对“槽位列表”为什么会有“必填槽及其补槽方式”的功能的原因,也做出了比较合理的解释。

图-5思必驰DUI-槽位列表

2.3 多模态-回复输出:Response

在Bot回复的设计上,可以笼统分为“基础回复”与“多模回复”两类形式。基础回复包含“可引用槽位动态文本回复”与“基于Webhoolk服务”的回复。这两种回复形式在DuerOS或小米小爱平台上都可以直接体验,在这里就不作为重点去说了。

主谈一下多模态形式回复,现在随着有屏设备的普及,只有文本TTS的回复在平台上越来越无法满足多模态回复产品需求。这方面做得比较有特点是“海知智能”和“思必驰DUI”。

2.3.1 海知–素材管理库

海知平台上有一个素材管理库,有点类似于“微信公众号”中的素材管理,开发者只有先在自己APP的素材管理库中上传不同形式(图片、音频、视频)素材后,才能在自定义技能的回复模块中使用。

图-6海知智能素材管理库

2.3.2 思必驰DUI–控件与逻辑

思必驰DUI回复中有两点设计比较有特色,其一是可以针对意图Action请求结果的不同逻辑,进行个性化配置,每个逻辑下的回复配置都是独立的(最典型的比如“找到结果”和“没有找到结果”);其二是单独针对“有屏设备”支持丰富的可配置控件。个人感觉,丰富的回复逻辑与控件是DUI平台的优势,但也同时成为了他们的劣势。因为“回复”仅作为Bot中的一个模块,占据了大量空间显得过于臃肿,初来的开发者很难一下搞懂如何配置。

图-7思必驰DUI回复控件

2.4 基于Context的多轮对话设计

关于多轮对话这块,首先说一下目前多轮对话的大体情况。依据底层实现的不同,多轮对话可以分为“闲聊型多轮”和“任务型多轮”,其中“闲聊型多轮”是基于记忆神经网络模型的,以小冰为代表产品,而“任务型多轮”是现在大多数平台基于逻辑和规则去实现的多轮对话,也是产品经理可以更多介入、进行产品设计的模块。

目前比较主流的方式(也是我个人比较推崇和参考进行设计的)是以Dialogflow和DuerOS的基于Context(上下文)的多轮对话,其次国内还有小米小爱和猎户OS基于这个底层模式进行了一些快捷方式和简化的“前置意图设计”。这一节以Context的设计为主,以前置意图设计为辅来谈谈对任务型多轮对话的理解。

2.4.1 多轮问题本质及分类

(1)问题本质

核心问题会有两个:

其一,该不该接?(本质上,这是一个条件判定问题)

其二,怎么接?(如何把上下文组成完整信息)

(2)多轮问题分类

多轮对话大致可以进行如下类型

·线性多轮

旨在收集足够的语义槽并获取用户的关键信息后,执行对应的Action逻辑

·非线性多轮

非线性多轮又按照是否“跨意图”分为以下三个类型:

·非线性意图内多轮对话:意图不变,槽位的更改或新增

·非线性跨意图对话圈内意图切换:跨意图,同层级之间

·非线性跨意图路径分支多轮对话:跨意图,不同层级之间形成依赖路径分支,且不同分支之间意图不能随意切换

2.4.2 Context概念及逻辑关系

Context的两个核心作用也即“条件判定”和“承载/传递信息”刚好对应上面任务型多轮对话要解决的两个本质问题。

2.4.2.1 Input / Output context 概念及作用

(1)Output context

·定义

每个Intent都可以在其后输出一个context,即output context。

·生命周期

每个被输出的Context都有生命周期的存在,即只有在其有效期内,context的两大作用才会生效。

·承载/传递信息

被输出的output context将会承载该Intent的槽位/值,以在另一个意图触发后,将所需要的关键信息传递过去,组合成完整的intent。

(2)Iutput context

·定义

某些意图,只有需要在特定上文(意图)的情况下才会被触发,则此意图需要配置对应的Input context。

·条件判定

在存在条件判定功能条件下,只有当上一轮的intent1的output context与某个intent2的input context符合触发条件才会触发Intent2(不过“触发条件”后面会提到)。

·接受/共享槽位信息

将上一轮意图的槽位/值传递至本轮触发的意图,组合成完整的intent以再一次请求服务。

2.4.2.2 input / Output context 关系及工作方式

(1)Input之间关系

·“或”关系

在小米/猎户OS代表的“前置意图设计”中,每个意图都有一个代表自己的输出,那就意味着在该Skill种所有意图本质上都是平级关系。一个意图,如果需要允许多个意图都可以触发或传递槽位信息,那么其input context之间的关系必然是“或”。

·“且”关系

在以Dialogflow为代表的Context设计中,允许自由配置多输入/多输出是其一,其二再加上“依赖树”对话结构,是“且”的关系。

(2)基本逻辑方式

当且仅当上一轮被触发的Intent1的Output context与本轮某个已经配置好的Intent2的Input context符合触发条件时,该Intent2会通过条件判定机制被触发,同时从上一轮的Intent1中继承全部槽位/值,对本轮出现的冲突类型槽位值进行更新与替换,组合成完整的意图。

(3)Output可刷新性

Output的可刷新性体现在,如果某个意图的Input和Output中配置了相同的“ContextA”,那么ContextA的生命周期和其中所承载的值会被重置更新。

这一特性对于2轮以上的意图内多轮非常重要,因为ContextA中的承载槽位/值无法随着对话轮数去更新某个槽位的值,就不符合对话中的“信息就近原则”(具体的体现再下面的Case中会体现出来)。

2.4.3 基于Context的意图内槽位更新/替换

(1)问题抽象描述

意图本身不变,但用户对已经触发的意图中某些已填槽位值进行修改;或是在该意图中增加槽位,其余已填写的槽位全部继承。下面举一个比较典型的Case来说明解这类问题的逻辑。

(2)设计解

以查天气为例,假设用户第一轮已经完整填充关于【city】和【date】的槽位,第二轮需要更新已填充的槽位值:

Q1:北京今天天气

Q2;那南京呢 /那明天呢

那么基于Context的配置方法如下,需要单独配置一个Intent以承接所有意图内的槽位更新

最多 22 列
  • 剪切
  • 复制
  • 粘贴
    请使用 Ctrl+V 粘贴
  • 向上插入 1 行
  • 向下插入 1 行
  • 向左插入 1 列
  • 向右插入 1 列
  • 合并单元格
  • 取消合并单元格
  • 删除列
  • 删除行
  • 删除表格
意图配置 典型句式 input context output context
查天气 北京今天天气 A
查天气意图内多轮 那南京呢/那明天呢 A A

·条件判定

如果直接问“那{date}呢、那{city}呢”是必然不会触发意图的,因为对话管理中并没有“A”存在。

·槽位引用默认继承

触发意图后,槽位列表中会默认将A中的所有槽位/值全部继承,将冲突的槽位值进行更新,以形成新的意图触发。在这里如果Q2问“那南京呢”,会将A中的【city】由“北京”替换为“南京”,组合成一个新的Intent去继续调取天气服务。

·槽位值刷新机制

输出的Output context“A”中所承载的值会被刷新为最新的“值”,以保证意图内多轮对话的“信息就近原则”。比如在上面的case中,假设Q2问到得是“那南京呢”,ContextA中的【city】会由“北京”更新为“南京”保留下来,也就是前面提到的“可刷新性”的作用。

从逻辑上推演就可知道,如果不存在Context中的槽位/值刷不存在刷新机制,那么ContextA中的【city】值会仍然保留为“北京”,这时候如果你在Q3轮问到“那明天呢”,返回的结果将会是“北京明天”的天气情况。但问题在于用户Q2轮已经问得是“南京”这个城市,它的Q3的明天的意思根据对话的“信息就近原则”应该是查询“南京天气”更为合理,解决这个问题的方式就是Context中的承载信息必须具有可刷新性

2.4.4 基于Context的跨意图槽位值继承

(1)问题

某个Skill由n个意图构成,意图之间的槽位完全相同可共享;三个意图作为首轮意图在用户Query中有槽位的情况下均可被直接触发,然后再继续的对话中无需再说槽位,可以实现跨意图的槽位继承。

比如“查天气”、“查限行尾号”和“查空气质量”分别为三个不同的Intent(假设),他们之间的在Q1触发并填充完必填槽【city】和【date】之后,Q2轮之后再问“那限行尾号”、“那空气质量”呢这样的case可以直接给出结果,而不需要再继续追问用户以填充这两个槽位。

Q1:北京今天天气

Q2:那限行尾号呢

Q3:那空气质量呢

(2)设计解

在基于Context的设计中,可以通过下面的配置方式去解这类Case。其中无论首轮触发的是哪个Intent,都必然会收集到两个必填槽【city】与【date】,那么三个intent的output context均可设定为“A”,其中承载的也是上面两个槽位/值

最多 22 列
  • 剪切
  • 复制
  • 粘贴
    请使用 Ctrl+V 粘贴
  • 向上插入 1 行
  • 向下插入 1 行
  • 向左插入 1 列
  • 向右插入 1 列
  • 合并单元格
  • 取消合并单元格
  • 删除列
  • 删除行
  • 删除表格
Intent pattern slot input output
查天气 北京今天天气 city、date A
查空气质量 北京今天空气质量 city、date A
查限行尾号 北京今天限行尾号 city、date A
查天气-1 那天气呢 #A.city/date A A
查空气质量-1 那空气质量呢 #A.city/date A A
查限行尾号-1 那限行尾号呢 #Acity/date A A

对于跨意图(同层级)的槽位共享继承这类Case,他们为什么有必要去实现跨意图,根本原因是因为他们有可以共享继承的某个Slot。那么这有N个Intent是哪一个被触发执行(填好槽),都意味着我们收集到了用户某个槽位中的信息,那也就意味着无论下一轮是哪个被触发实际上我们并不Care,只要它需要引用继承这个槽位信息,就都需要在Input中配置这个Context。

所以在配置方法上可以看到,三个不同的意图配置的Output context是完全一致的(代表他们内涵同样的槽位/值),三个负责承接这类case的多轮意图,也自然都配置A。同时每个意图都Output context也不意味着代表它自个,形象点说它更像是给对话状态“续命和更新”

2.4.5 前置意图设计

说完了基于Context的多轮对话,接下来看看小米和猎户OS的“前置意图设计”,其实这个前置意图的底层逻辑,同样是基于Context,只不过两家平台各自针对自己的理解,做了一些具象化的改变让配置更加简便易懂,但同时也不可避免地造成了一些弊端。

2.4.5.1 前置意图设计概述

前置意图设计中分为“输出意图”和“前置意图”。“输出意图”也即上面的Output context,它的作用也是相同的可以承载该意图中的槽位/值,唯一的不同是在创建每个意图时,都由系统默认配置一个“代表自己”的输出意图(开发者无法对输出进行配置),也就是说每个意图都有一个代表自己的“符号”并承载自己的槽位/值(输出意图)。

那么这个设定也就必然导致了前置意图的关系必须为“或”而不能是且,因为在跨意图的多轮对话配置上,一定会出现某个意图允许多个其他意图触发的情况,而多个其他意图又已经由系统默认设定好属于自己的“输出意图”,那么该意图的“前置意图”必须允许配置多个,同时他们之间的关系只能是“或”,才能保证多个意图之后都允许触发它。这样的前置意图设计逻辑有优点也有其缺陷,下面会以同样的两类Case去进行验证。

2.4.5.2 意图内槽位值更新/替换与“输出前置意图”开关

在猎户OS的多轮配置中,会有一个非常明显的“输出前置意图开关”,这个开关就是为了单独解决“意图内槽位更新/替换”这个Case的。上面已经知道系统会默认帮每个意图都建立一个属于自己的输出意图

图示-9猎户OS前置意图开关

如果对“输出前置意图开关”打开后,则这个意图被触发执行后,其“输出意图”输出的就不再是“代表自己这个意图的输出意图”,而是更新其前置意图的“槽位/值”和生效轮数,输出的意图也是自己配置的“前置意图”

这种方式与Context配置中两个均为“A/A”去解决该类问题的本质是一样的,均是更新“Context A”的生效轮数和其中承载的值,只不过在方法上不再是自己配,而是通过系统的开关设定去解决,配置比较简单。

2.4.5.3 跨意图槽位继承–“前置意图”弊端

任何一个intent都有一个代表自己的“输出意图”,如果你想要一个意图可以继承来自多个意图的槽位/值,那么在前置意图的关系则必然是“或”(且肯定要采取多个配置)。仍然是针对“查天气”“查空气质量”和“查限行尾号”这三个跨意图之间的多轮对话来解,配置的方法呈现如下

最多 22 列
  • 剪切
  • 复制
  • 粘贴
    请使用 Ctrl+V 粘贴
  • 向上插入 1 行
  • 向下插入 1 行
  • 向左插入 1 列
  • 向右插入 1 列
  • 合并单元格
  • 取消合并单元格
  • 删除列
  • 删除行
  • 删除表格
Intent pattern slot input output
查天气 北京今天天气 city、date A
查空气质量 北京今天空气质量 city、date B
查限行尾号 北京今天限行尾号 city、date C
查天气-1 那天气呢 #A.city/date B/C/E/F/D D
查空气质量-1 那空气质量呢 #A.city/date A/C/D/F/E E
查限行尾号-1 那限行尾号呢 #Acity/date A/B/D/E/F F

通过配置结果,可以清晰对比出“猎户/小米”的前置意图设计和Context对这类问题的解不同,前置意图设计中每个Intent有一个代表自己的Context,同时每个意图自然是可以被其他多个意图都能触发,所以他们配置的Input context(前置意图)会繁琐臃肿,但根本原因并不是因为这个三个意图之后可以接某个意图,而是因这三个意图之间刚好有可以共享继承的槽位。前置意图设计最大的问题就是配置起来显得很臃肿,如果场景简单可能还好,如果是非常复杂的场景(意图很多),那么配置和维护的成本会非常高。

当然前置意图设计也并非完全没有优势,虽然在操作上比较繁琐需要枚举,但其底层设计思想将“每个意图配置一个代表自己的输出意图,前置意图需要什么枚举式配什么”,非常符合人的直觉思维,在这一点上我也深有体会…..绝大多数开发者对于这样的设计能够秒懂。

以上是对于Context和前置意图多轮对话的理解篇幅原因只能把核心思想和比较简单的case拿出来作说明,如果之后大家还有兴趣的话,可以单独把多轮对话这块拎出来系统性谈谈,关于任务型的多轮对话就先说到这里了。

2.5 Bot-Skill整体结构与方法论

回顾最开始的主题,我个人理解的Bot六大基本构成要素“Intent、Pattern、Entity、Slot、Response和Context”,在整个对话过程中以怎样的模块化分布和逻辑关系去解不同子问题,已经贪玩。理解了这些要素之间的关系后,Bot操作方法论以及平台所需要支持的功能,自然是在这个底层逻辑模型下更具象层面的自然涌现。

而对于这六种要素的构成整个Bot交互模型结构,大家可以参考下面的图示,基本是各家平台的Bot交互模型都类似。

图10-整体交互模型

三.Bot-Skill平台的现状与演化

3.1 Bot平台现状与演化方向

目前国内外的Bot平台综合来看能力和逼格有高有低,但基本逻辑都差不太多这也是目前对话平台的天花板,即使增加一些功能性的东西,也很难有非线性增长突破。对于如何突破天花板地演化方向,我个人有如下三个层面的看法:

(1)功能层面

·可视化-简易性配置

现在的Bot-Skill平台虽然可以配置出一套完整的语音技能,但意图与意图之间以列表形式平铺,加上用于承接多轮的意图后整个Skill的配置和后期维护成本较高。其二,当前单个Bot-Skill的整体逻辑没办法进行宏观层面上的配置和呈现。

所以以可视化(类似于流程图)的配置形式,对每个Skill的整个意图逻辑链路,能有完整清晰的呈现,通过在画布中以“拖拽”式地交互完成Bot技能的创建,是我觉得每一个平台都可能要考虑的一个方向。

(2)多维度层面

·多模态

《三体》有一个词叫“降维打击”,放在这里也正合适。几乎当前所有的Bot平台,都是将Query作为输入,以意图作为触发节点的方式承接信息。既然是一种信息的输入,就不单单只有语音/语义,触发的节点也并非一定是“意图”,“意图”只是基于Bot框架逻辑的一种“触发节点”的具体表现,但它本身也是“触发节点”抽象集合的一个子集。

图像、视频、事件和体感(如车载中的传感器),也都是信息,如何收集到这些信息作为输入的触发节点,并且与当前的Bot底层框架深度结合起来,让平台不仅仅存在对话逻辑这一个维度,而是可以实现多维度多模态的输入与输出,平台实现“降维打击”的一种方式

(3)垂直领域的演化

·特性演化

目前业内大多数平台都定位于偏“通用”的性质,在平台A上可以做到得技能,在平台B也可以完成(虽然多少有一些差异,但并不足够明显),这也是目前市面上语音交互Skill同质化比较严重的原因之一。

在偏通用性质的平台上,基于平台和公司的基因,根据自身公司的独特业务和场景的需求,演化出更具有“垂直领域特色”的Bot-Skill平台是一种很大的可能(此处为@团长大大带来的观点和启发特别是针对AI领域的创业公司来说,这更可能会成为一个突围地机会。毕竟大厂们更偏向于适用领域广泛通用性强的平台而对于创业公司来说每家的具体业务和场景的侧重点都有所不同,反而更有可能演化出具有自家特色的平台设计。

这个逻辑也类似于物种的演化,比如同样是“鹿”(类比为Bot通用平台),长颈鹿演化出的长脖子,可以帮助其获取更高树木的食物,而角鹿演化出的大角,用来吸引异性,各自有各自的特色和演化路径。

3.2 关于语音/语义交互的一些个人看法/观点

最后,想聊聊作为一个AI语音/语义产品经理,我个人的一些感受

最初,大家对于语音交互可能有着非常高的热情(甚至有点狂热),想通过语音交互的方式解决一切问题。但冷静和理性地看,语音交互作为一种新的技术手段,形成的产品还有很多不成熟的地方。后来大家也认识到这一点,在缺失视觉/操控时,语音交互作为一种交互形式,存在着很大局限。语音交互技术和产品,仍然需要时间的检验。

不过同时,我也对此抱有极大的乐观,倒不是因为我正在从事这个领域,而是因为一个基石假设和第一性原理的思考方式:

人类的底层需求是几乎永恒不变的,变化的东西永远是在具象层面,流变。而一旦时机或技术成熟,人类一定会回到最原始的本来面目。

就像当年乔布斯刚发布iPhone的时候砍掉了键盘操作,一开始一大堆人说没有键盘怎么操作,但其实人的婴儿一出生,它与外界的交互方式就不是键盘,而是通过自己手指戳来戳去地方式去与外界进行交互,因为那才是人类底层最自然的一种交互方式。

如果上面的基石假设是正确的,而这次语音交互又有可能(或至少部分可能)将人与机器的交互方式带回到“本来就该有的样子”,那么对此保持乐观就不是盲目自信,而是基于逻辑推理的自然结论。

 

 hanniman

TTS(Text-To-Speech,语音合成),目前是一个“小而美”的AI领域,但我个人觉得非常有意思,感觉TTS在未来会被行业真正重视起来,并且会出现做得不错的创业公司。

本文,是我收集了很多线上/线下的相关信息后,提炼出的AI产品经理“最必要”了解的TTS技术知识和行业现状多了没必要,少了又不足以入门、准备面试或工作实战);不仅帮大家节省了时间,更是过滤了很多无用信息和过于技术的内容。

目录

一、核心概念

二、当前技术边界

三、瓶颈和机会(重点

1

核心概念

1、TTS和ASR的概念区别

我们比较熟悉的ASR技术(Automatic Speech Recognition,语音识别),是将声音转化为文字,可类比于人类的耳朵。

TTS技术(Text-To-Speech,语音合成),是将文字转化为声音(朗读出来),类比于人类的嘴巴。大家在Siri等各种语音助手中听到的声音,都是由TTS来生成的,并不是真人在说话。

TTS的技术实现方法,主要有2种:“拼接法”和“参数法”——

2、拼接法

1)定义:从事先录制的大量语音中,选择所需的基本单位拼接而成。这样的单位可以是音节、音素等等;为了追求合成语音的连贯性,也常常用使用双音子(从一个音素的中央到下一个音素的中央)作为单位。

2)优点:语音质量较高

3)缺点:数据库要求太大。一般需要几十个小时的成品预料。企业级商用的话,需要至少5万句,费用成本在几百万元

3、参数法

1)定义:根据统计模型来产生每时每刻的语音参数(包括基频、共振峰频率等),然后把这些参数转化为波形。主要分为3个模块:前端后端声码器

    • 前端做的事情,是把文本进行解析,决定每个字的发音是什么,这句话用什么样的语气语调,用什么样的节奏来读,哪些地方是需要强调的重点等等。常见的语气相关的数据描述包含但不限于下面这些:韵律边界,重音,边界调,甚至情感。 还有更多的信息甚至是难以客观描述的,目前的算法只能暂且忽略。
    • 注:拼接法和参数法,都有前端模块,拼接和参数的区别主要是后端声学建模方法的区别。

2)优点:数据库要求相对较小一些。

    • 如果只需要出声(做demo),大概500句就可以,但是效果肯定不行。
    • 通用TTS,一般至少需要5000句,6个小时(一般录制800句话,需要1个小时)。——从前期的准备、找人、找录音场地、录制、数据筛选、标注,最终成为“可以用的数据”,可能至少需要3个月。(讯飞在各方面比较成熟,用时会短很多)
    • 个性化TTS,大多数是用“参数”方法的。(adobe、微软也有尝试过拼接法,不过相对参数方法来说不是太成熟,效果也并不是太通用)

3)缺点:质量比拼接法差一些。因为受制于发声算法,有损失。

  • 因为主要弱点和难点就是声码器。声码器的作用是复现声音信号,难在重现声音细节,并且让人听不出各种杂音、沉闷、机械感等等。目前常见的声码器都是对声音信号本身作各种理论模型以及简化假设,可以说对细节的描述近似于忽略。
  • 注:DeepMind的WaveNet,基本解决了声码器的问题。因为他们直接对语音样本进行预测,不依赖任何发音理论模型。最后出来的音质细节十分丰富,基本达到了与原始语音类似的音质水准(所谓质量提高了50%,就是这里),而且几乎可以对任意声音建模(这就太牛了)。

4、TTS的评判标准

1)主观测试(自然度),以MOS为主

A)MOS(Mean Opinion Scores),专家级评测(主观);1-5分,5分最好。

  • 注:微软小冰公开宣传是4.3分,但有业内朋友认为,也不能据此就说其“绝对”比科大讯飞好,因为每次评审的专家人选都不一样。说白了,目前整个AI行业内,还是各家说自己好的节奏。

B)ABX,普通用户评测(主观)。让用户来试听两个TTS系统,进行对比,看哪个好。

C)每次主观测评应该有区分。比如这次着重听多音字,下次主要听语气词等。

2)客观测试

A)对合成系统产生的声学参数进行评估,一般是计算欧式距离等(RMSE,LSD)。

B)对合成系统工程上的测试:实时率(合成耗时/语音时长)、首包响应时间(用户发出请求到用户感知到的第一包到达时间)、内存占用、CPU占用、3*24小时crash率等。

2

技术边界

1、通用TTS

1)在用户预期不苛刻的场景(APP/硬件),能满足商业化需求,比如语音助手/滴滴/高德/智能音箱/机器人);但如果用户预期非常高的话,是很难满足的,因为还是会有“机器感/机械感”,不能非常自然的模拟人声。

2)目前行业各家公司的产品效果差不多,都基本能商用。

2、个性化TTS

1)在用户预期不苛刻的场景,能“基本”满足商业化需求,但是效果没通用TTS那么好。但如果用户预期非常高的话,暂时是满足不了的。

2)目前行业内能成熟商用的,主要还是科大讯飞,也有些创业公司在这个领域有所布局,如微量分贝(HEARD)这家致力于海量内容音频化的企业,对声音进行了分门别类的生成和储备,他们瞄准的企业级需求也会更为个性化、品牌化,诸如阿里巴巴旗下的“动物园”品牌(如天猫、闲鱼、盒马、菜鸟等),都会生成诸如“小猪佩奇”这样的角色化TTS 并被商用。

3、情感TTS

1)目前业界的情感合成更多了,是因为数据本身变多了、更有节奏了,超过了传统的播音风格,但并不是真正的“喜怒哀乐”等情感合成(想高兴就高兴的这种智能)

2)在情感TTS的理论方面,学术界是有储备的,但是,整个行业目前都没怎么做(或者没做好)是因为情感TTS很依赖“情感意图识别”,“情感特征挖掘”、“情感数据”以及“情感声学技术”等,是个系统工程。其中第1点,即是和自然语言处理相关,比如需要知道“什么时侯该高兴或悲伤”;同时,具有情感演绎的语音数据的储备,也非常重要。

3

瓶颈和机会

主要有5个方向的瓶颈(同时也是机会)。

1、基础技术

1)TTS技术正处于重大变革端到端(End-to-End)的TTS建模方法,加上WaveNet 的声码器思想,是未来TTS的发展方向。

  • 端到端TTS,一般指tacotron,tacotron只是Google提出的合并了原先时长模型和声学模型的中段结构,可以接任何TTS前端和TTS后端。TTS前端如中文分词、注音、词性,都会提升tacotron性能;后端,参数、拼接、wavenet都可以选用。
  • 关于WaveNet技术的商业化:Google今年初将第二代WaveNet技术商业化了,速度比第一代快一万倍。而国内各家公司,基本也仿制出来了(论文算法),但工程化还需要时间,而且成本还是太高,短期内应该没法商用。
  • 关于效果:TTS最终效果好坏,技术只占50%不到,在技术都差不多的情况下,声优质量数据量最重要,其次是相同部署规模和成本的TTS才能相互比较即,不能简单的说哪家公司的效果比另一家更好,a)比如,拿百度/腾讯/阿里/图灵等很多家AI公司的WaveNet v1的效果,一般都能超过讯飞线上的接口,但部署成本高几万倍,且不实时;WaveNet V2商业化以后,虽然能实时,但部署成本至少也比高配拼接TTS高10倍左右。b)成本,部分和采样率相关,例如,讯飞/百度TTS的采样率都是16k,如果用24k和48k,主观体验至少强50%,但成本会翻倍;也就是说,其他AI公司的24kTTS的MOS,能吊打讯飞/百度的API,但不能说他们的技术就比讯飞/百度强,因为在商业化时,会牺牲效果来降低成本。

2)如何让离线版效果达到在线版水平。很多客户希望(奢望)有离线版本,并且效果和在线版本一样好……现阶段来说,可能真是“臣妾做不到啊”。

2、数据缺乏

一方面,特别是个性化TTS,需要数据量更大。比如默认男孩声音,要转成女孩,就比较难。

另一方面,数据的获取(制作)成本和周期,也是各家在初期的竞争着力点,比如,一般来说,一款(套)TTS数据,至少需要先录制2-3万句话,再加上数据标注,通常耗时在3个月以上(且需要主播全力配合),对于30小时的数据,价格通常在30-50万,而上文提到的微量分贝(HEARD)这家公司,调动了8000+位优质播音人员,在给不同内容配音的同时,也做了大量结构化数据的存储(库存化),这样,针对大部分客户的数据需求,并不需要再找主播进行录制,而是直接从仓库调取数据进行解冻即可(数据标注);通过将这种 “边进行业务边赚取数据”的流程标准化,其获取数据的成本大大降低到行业的五分之一 ,并且一旦有需求,可以在1个月内进行交付。这家公司在南方搭建的数据标注工场的规模,也是巨大的,包括华为等公司都从其采购语音合成数据。

3、人才匮乏

不仅没法跟NLP、CV等热门AI人才比,就算跟同样不算热门的ASR比,TTS的人才都还要少一些。

4、产品化难度

由于技术限制,现阶段不可能有非常完美的TTS效果,所以

1)尽量选择用户预期不苛刻的场景,或者在产品体验设计时,管理好用户预期(比如打车软件,郭德纲/林志玲的声音,差不多就行)。

2)选择“参数法”还是“拼接法”,和公司的技术储备、成本、以及产品目标相关。在垂直领域,现有的TTS技术(参数或者拼接)都可以针对产品做得很好。现在行业还没有太好的效果,很大原因是因为产品经理还没有深入介入,有很多细节的坑要踩(产品设计+工程化实现)——未来应该会有惊艳的产品出现。

3)体验细节设计,和一般互联网产品很不同,比如

A)文案设计,非常重要;因为在语音交互场景,不能太长,用户没耐心和时间听完的。

B)可以加入背景音乐,掩盖杂音等细节瑕疵。

C)特殊场景,还有特别的需求,比如远场场景和戴耳机场景相比,还是会有区别的。

D)中英文混合TTS。比如用户想播首英语歌曲,困难在于:所有中文的发音当中,中文和英文合拍念出来是很难的,为什么呢?因为往往录音的人。录中文是一批人,录英文又是一批人。两种语言结合起来,再用机器学习学出来,声音就会变得非常怪。这方面,小雅音箱曾经花了很大的精力和成本去“死磕”解决,详见《傅盛:人工智能的破局点是技术和产品结合【猎户星空发布小雅语音 OS】》

5、商业化压力

1)如果要有足够的市场竞争力,至少需要12个月的时间,2~6人团队(如果有人做过前端相关工作,会节省巨大成本——工作量主要在中文前端NLP部分,比如分词、注音、词性文本规整化等),几百万资金投入(1个GPU一年十万,支持并发只有几十个)。并且,大公司的先发优势巨大,小公司必须切细分场景。

2)我个人认为,个性化TTS、情感TTS会在各细分场景得到更大的应用,比如知识付费、明星IP、智能硬件、车联网、实体/虚拟机器人等

附:相关资

1、相关高校及实验室

语音合成涉及专业领域较广,包含语言学、听觉与发声机理、自然语言分析、深度学习、信号处理等诸多领域,是一门综合性学科。

国际上,英国爱丁堡大学Simon King教授,卡耐基梅隆大学Alan W Black教授, 日本和歌山大学Kawahara教授,谷歌Heiga Zen所在的实验室均为国际顶级实验室。

国内来说,中国学术届也一直走在行业的前列,国际语音合成挑战赛blizzard challenge已经连续10多年冠军在中国。国内大部分的语音合成人才,均来自于中科大、中科院自动化所、中科院声学所、清华大学、西北工业大学等几家单位,比如西北工业大学的谢磊老师组,已向语音合成届输送了大量人才,在微软、百度、搜狗、小米、IBM、讯飞、流利说、出门问问、猎户星空、同盾等公司的核心岗位上,都有来自西工大的学生。

2、参考文章

  • 《目前,人工智能语音在说中文时的语气感觉上还比较机械,怎样使人工智能语音的语气更自然一些?》http://t.cn/RFnP7EH
  • 《如何评价谷歌下一代语音合成系统WaveNet?》http://t.cn/RFnPUkA
  • 《TTS(Text-To-Speech)的原理是什么?》http://t.cn/RFnPfP1
  • 《百度Deep Voice作者与Bengio团队探讨五大技术细节,端到端的语音合成还有多远?》http://t.cn/RoUvHAg

3、相关产品

讯飞配音app、讯飞朗读助app、闪电配音(http://www.soundems.com )等。

4、有趣视频

《武汉地铁语音播报已逆天,这是要称霸全国的节奏啊》

AI+医疗影像在2017年实实在在火了一把,而从另一方面来看,也出现了“同一医院堆了10家AI公司的产品,但大多躺在医院吃灰”的情况。AI究竟能不能真正解决医生的工作需求痛点?医院对AI辅助产品有无真正需求以及付费意愿?AI+医疗产品未来的商业化方向是哪里?本文对以上几个话题进行了分析。

如今,随着AI医疗发展,医工交叉——这个由来已久问题也延伸到这块新兴的土地上。隔行如隔山,这对于IT界和医疗界来说尤其贴切,当双方团队共同打造一个产品时,面临着话语体系不同、评价方式不同、谁来主导等诸多问题。

目前这个市场还处于初期,各路玩家相继入场,产品仍处于科研摸索期。相对于蜂拥而入的AI公司来说,愿意参与进来并且拥有丰富经验的医生专家是更加稀缺的资源。那么什么阻碍了他们?当医生想要参与时,他们考量什么、在意什么?

武警总医院CT科,十余位影像医生正在阅读医院前一天200多例患者的CT图像。医生小刘在电脑上打开一个检查单,上面有患者信息、症状(咳嗽一月、曾低热、肺炎)、检查项目等。点击进入影像页面,一家医疗AI公司提供的肺部筛查产品给出了10条可疑病灶,如右肺上叶、尖段、3.1mm、20.19m³、实性结节。根据提示和自己的判断,小刘书写报告,全程约8分钟,这样的病例他一天大约要看30份。

以前,小刘需要阅读每个病人的几百幅影像,逐个找出结节。现在AI帮他找出肉眼不容易发现的小结节,只需要根据系统提示检查核对,漏诊率大大下降。

这类医疗影像AI产品为智能CT辅助筛查系统,行业内推出这一产品的有推想科技、汇医慧影、图玛森维等几十家创业公司。

记者调查发现,在AI产品扎堆的影像领域,一个三甲医院可能同时安装10余家AI公司的产品,医生真正使用的只有一两家,因为AI找到结节后尚不能辅助诊断,且目前产品多集中在肺结节查找上,同质化严重。而这些需要深度学习的AI产品,少了医生的纠错与补充,模型迭代也会变慢

未来,影像AI的出路在哪儿?多名业内人士表示,医疗影像AI公司仅靠单一产品,在医院盈利难度较大。未来创业公司可以开发短平快的优势盈利模块、与设备厂商合作相互赋能或在体检机构、基层医院推广使用AI影像产品。

关于AI落地时的盈利模式。1)比如,初期先帮助客户做好相关数据的数字化(比如影像存储,常规的阿里云服务不划算,因为图片太大,但每年用不了几次,就需要有专门针对这个领域的图片存储云服务),等争取到了客户,并积累了数据后,再向客户推广AI应用。2)还比如,将自己的AI产品技术服务,提供给行业下游厂商,提高其整体方案的(噱头)价值,打包销售。3)更多相关内容,未来有机会我再专文叙述。

AI“双重审核”,降低医生漏诊率

2014年以来,AI技术的发展逐步进入垂直细分领域,医疗影像以其标准化程度相对较高而被认为是最早能够实现AI落地的场景之一。一时间,几十家创业公司涌入影像AI赛道,其中不乏已经拿到C轮融资的独角兽企业。

武警总医院CT科主任王贵生早在16年前读博士时候,就接触到了美国推出的影像AI产品,用于肺结节的辅助测量,但主要是做科研,临床并没有推广起来。

直至2016年底,美国一家科技公司联系到武警总医院,将一个肺结节筛查AI产品的试用版安装到了科室的电脑里。

“当时的系统特别慢,需要先把影像资料导到服务器上,然后它给出格式化报告再导出来。它的敏感性高但特异性差,发现东西但不知道是啥,费半天劲只是标出来了结节,更有价值的判断并没体现,后来就不用了。”王贵生回忆。

AI实战落地时,就会遇到类似的问题——只能做个demo,离“有用”,“可用”,“付费”还有很大距离。

真正落地到武警总医院的是2018年引入的两个产品,分别来自深睿医疗和推想科技。虽然功能和之前美国的产品大同小异,但操作时间缩短了不少

国内产品体验设计方面,跟美国比,确实还是有优势的,特别在吸引用户(客户)尝鲜体验时候。

据介绍,在武警总医院这样的综合型三甲医院,一天做CT的病人约270个,科室有7名医生读片子、写报告,5名医生审核,每位医生平均每天要看30多个病人的片子,一个病人约有500多幅图像,每个图像需要二级或三级审,至少要过三遍。

AI产品的出现一定程度上减轻了医生负担

王贵生表示,一个片子阅读加写报告约要5-8分钟,用了AI产品之后,时间上并没有明显的减少,但系统提示过以后,漏诊的几率低了因为在血管密集的地方或者人眼疲劳时会漏掉结节。

落地现状:时间并没有明显减少哦!

另一方面在于AI对结节大小体积的测算比人工准确,尤其是对于椭圆形的结节,医生惯用最大的横线和垂线计算得出,由于它不规则,难免有误差,AI的测量则相对准确。

以上2点,都还是AI相比人在生物性和计算能力方面的优势,但这,也许就应该是AI早期咱们该关注和承认的。

某三甲医院影像医生小宇(化名)介绍,其医院目前使用了依图科技和推想科技两家公司的产品。

“最初我们很期待,但用了之后发现不太习惯,加上刚开始系统可能不稳定、准确率也不高,或漏诊或多筛,作用没有想象中那么大。用AI看一遍,自己再检查一遍,也没有节省时间。

后来,随着医生和公司双方的反馈更新,有了较大改观。第一家公司进来以后发现大家积极性不高,提出了一些激励制度,如果补充标注结节会给医生资金上的奖励,虽然没有真正实施,但小宇认为:“有了AI相当于一个双重审核,我们平时找起来很吃力,容易漏掉的小结节,AI正好擅长。”

产品同质化严重,闲置率高

在走访中,记者发现,虽然一些医院同时安装多家公司的AI产品,但真正使用的只有一两家,甚至一家都未使用,存在大量闲置情况。

武警总医院的多名医生表示,他们平时会从根据使用习惯、系统的稳定性等只用一家,比较少去切换比对。广东省第二人民医院也表示引入了图玛森维、腾讯、推想科技的产品,日常用的也是1家。

某匿名行业内人士透露,因为使用体验并不理想,有的医院是使用一段时间就不用了,“筛查不精准,或者调用软件时导致系统崩溃,这让医生不愿意花费时间。”

客观来说,确实有很多AI应用的产品体验和稳定性太差,这让用户想试用都慢慢的打退堂鼓了。

医疗类媒体动脉网也曾报道,邵逸夫医院放射科合作的医疗AI公司达到了10家,重庆医科大学附属第一医院合作了7家,但一位医生大多只用一款产品。

为什么会出现产品闲置的情况?

其中原因在于虽然AI能帮助找出结节,但在进一步的良恶性判断与报告意见出具方面,AI尚不能给出结论。而且,目前市场上的产品多集中在肺结节上,同质化严重

一位影像AI领域从业者透露,肺结节出产品容易而新病种攻克难度大。

具体而言,肺结节公开数据最多,很多数据集可以直接下载,而且肺结节影像相对直观,不管是创业公司还是上市公司,过去两年都相继推出类似产品;而新病种研发需要大量深度学习模型训练,获取单病种数据难度大,还需要与大量专家合作进行精标注,新病种的验证周期也非常长

获取有效数据难度大(数量+质量),会成为纯深度学习性的AI应用的重要落地瓶颈。

在各家创业公司的研发端,除肺部筛查产品之外,也在开发适用于脑部等其他部位的AI应用,只是大多数产品还没进入到临床应用阶段。

虽然大家都在做肺结节,但是在医院的使用情况截然不同。同质化不重要,关键看的是医生的信任度与点击量,这才是判断产品的标准。“未来公司将开发胸部、脑部更多的模块,形成产品矩阵,让医院更加依赖于我们的产品体系,当然,AI产品的发展与成熟还需要与医院医生互相配合培养,还需要时间。”

只是锦上添花,医院购买意愿低

经过了三年多的发展,影像AI领域内的公司依然处于打磨产品的阶段,没有清晰的商业模式与盈利场景,医院的付费意愿很低。

发展了3年,还只是这个样子,在传统互联网领域是不可想象的。这也说明,AI落地的时机可能还没有到,特别是一些行业属性非常重、水很深的领域。

王贵生表示,就目前看,拿肺结节产品来收费肯定是不可能的,因为各公司都能做到而且都在免费使用。

在他看来,AI产品盈利能力受限的根本原因还是在于现阶段的产品对医生来说并不是刚需,有了是锦上添花,没有也不耽误事,就像是滴滴,用它方便叫车,但没有也能出行。

我之前分享过,现阶段,很多领域的AI应用,本身就不是刚需——主要价值在于,通过AI元素来提高终端C用户的转化率。即,本来没有人用这家客户的产品,但因为加了AI因素,C用户愿意来尝鲜体验。这样,获得更多数据后,才可能更深入的去做出更好的产品。

小宇也表示,找到结节只是第一步,医生要做的是对它定性,看没有变成肺癌的风险,而目前AI还没有这样的功能,让医院买单难度太大。

美国AI医疗服务商More Health联合创始人胡泊认为,影像AI产品难以真正落地使用,其中除了技术问题,还有责任问题。如果AI给出的结果错误,谁来承担这个责任,这需要相关的政策和法律支持。同时,企业的良性发展问题尚未解决。目前大部分企业在烧钱,中国大部分机构或医院不愿意为软件买单,找到可带来现金流的产品是难题。

此外,国内数据有不连续性和多样性,每个医院的标准不一样,一个患者可能去四五家医院,数据不连续,大部分医院现在还是信息孤岛,想要打通短期之内很困难。

“中国如果在数据的规范和安全以及流通性上如果能做出更好的举动的话,医疗AI发展会比美国更快,毕竟中国的患者更多,数据更多。”胡泊说。

我还找不到与AI公司合作的方式

做医学图像挖掘,医生与AI创业公司的合作是必不可少的,但一定要以医生为主导来做,公司负责后续的产品化。其中最关键在于:要解决什么样的临床问题。

我是做研究的,思路与公司可能不太一样,双方都是要提升诊断率,差异就在于具体聚焦在什么地方?科研解决的是悬而未决的问题,而AI公司是要打造一个产品解决实际问题,双方目标不一样,我觉得很多东西不是想象的那么简单。

从科研的角度来讲,目的在于提出一个临床假设,并证明。比如我想通过影像数据挖掘判断某种疾病的愈后好不好或判断疗效,在这种情况下,我会搜集病例,用某些方法验证,最后得到一个结果。至于结果如何,我们并不知道,创业者的想法跟我们肯定完全不一样。

有公司找我合作,说实在的,我还找不到合适的方式,如果要合作,一定是深入的交流,其中需要有人起到桥梁、翻译的作用。比如深度学习的很多概念我们临床医生搞不懂,但同时工科的人也多半不懂什么叫预后,甚至不知道这样做的意义何在。

医学上很多问题和其他领域不一样,比如阿里要调研用户的购买习惯,这种数据多得不得了,但医学上很多疾病数据很少,一个单位可能仅有一两百病例符合标准。我想没有一家医院敢说有几千例这样的复合标准的图像。我们医院有数万病例,但基于不同的疾病、检查方式、研究目的区分之后,数据一下子就变得很少了。

工业界和学术界的合作,对双方都有很高的要求:一是有共同的目标;二是有很好的合作机制,协调如何把利益最大化;三是双方团队质量很重要,缺一不可。

如果我与创业公司合作,最关心的他们的人员构成和数据来源。

做医学数据挖掘,一定要有医疗背景的专家,他能起到桥梁作用,把临床问题转换为技术问题,让IT团队实现;同时,做技术的没有接触过医学,可能不明白人体分为几个系统、每个系统由什么组成、有哪些脏器,更不要说疾病了。我知道很多医院做的事情是把数据提供给公司,这个方法确实可行。但如果要真正挖掘,一定要深入,不是一方简单地提供数据,一方简单地提供算法,双方直接应该有深度的交流、沟通,共同发现问题,解决问题。

国内最常见的合作方式是医院提供数据,公司来分析,双方共享成果或是公司卖软件给医院。但我认为这样的合作不长久,目标不同,长期以往,估计会分道扬镳。我觉得目前的合作,肯定得以医生为主导,靠医生发现临床问题。但跟创业公司这么说,他们肯定不乐意,我的算法很先进,凭什么你做主导?所以我不是很愿意跟他们合作,我们自己有团队,我们团队做的东西在国际上是某些研究方面是很靠前的。如果我们没有团队,也没办法。除此之外,我也考虑过,跟创业公司合作,他们是否愿意配几个人给我,专门负责某个项目,我想这是不可能的事情,怎么可能呢?

还有的医院与公司合作打造出的产品,以专利授权的形式给了公司,这对医生有吸引力,但我没尝试过,没想过转化,这样很分散精力。我关心的是公司有没有好的范例,医生是否真正获得了收益,无论是以股份、顾问费等形式。但公司愿意给吗?

创业公司很难请到一个真正专业的医学人士,去了以后怎么做项目?除非公司能跟十几、二十多家医院合作了一个临床设计,但仅把各个项目的医学语言翻译成工科语言,工作量就相当大;其次,医生如何在里面起到真正的作用,这是很难定义的。

这几段,作者说的都是非常现实的问题,一般的行业新闻报道,是不可能写这么深入的。

虽然现在市面上有AI公司与医生合作做一些事情,但在大部分情况下,他们的研究是小规模研究,但应用到临床的东西,需要前瞻的多中心试验验证,这是一个很漫长的过程。况且,图像只是很小一方面,只有深入去做,潜心做临床研究,才有可能得到好的结果。

开发盈利模块,往基层拓展

从医生的角度,AI除了筛查结节降低误诊率之外,测量、对比、了解结节密度的改变也对医生很有帮助,“比如,肺结节大小的改变其实是体积的改变,如果AI能给出准确的体积改变与前后对照,价值是较大的,这类问题也是AI的优势。”

AI公司如果想让医院买单,应该把它最优势的机器运算发挥起来,将人脑做不到或误差率非常大的东西细化、产品化,拿这些模块来补现在免费的模块,产品的系列多了就好卖了。此外,AI公司可以跟设备厂商结盟,依附于医疗设备上,将付费方和受益方形成一致,这可能是一个更快的盈利方式,传统厂商也能增加卖点。

一来就想上临床,对生命太不尊重了

智能影像诊断还有非常长的路要走,要真正应用在临床,要解决它的精度、实用范围和政策等问题,如果要政策批准,必须经过临床试验验证,耗资会很巨大。

我个人感觉,创业公司除了定位于肺结节检出等临床应用外,搭建科研平台也是不错的选择,要是我自己开公司,我就会这样做,帮助医生做科研的市场也不小,可以共同申请基金来维持,我知道有些创业公司就在合作申请基金。如果数据积累多了,再考虑做临床转化,像Watson这样的,这样才可能逐步走向临床。很多公司一来就想到临床,对生命太不尊重了,如果仅靠靠几百、几千例数据就取得了批准,我肯定不敢用这样的产品。

我个人觉得,医疗人工智能还非常漫长,目前无疑是过火的。

在IBM蓝色logo缠绕旋转的眨眼间,三阴乳腺癌晚期患者李春梅的丈夫刘银松看到了IBM Watson for oncology(IBM Watson肿瘤解决方案,下称WfO)给出的诊疗方案。该方案与多位专家的推荐方案完全一致,然而,李春梅夫妇却觉得6000元的会诊费打水漂了。

四年以来,40岁的李春梅辗转于北京各大医院,历经手术、化疗和放疗,目前服用药物奥拉帕尼(Olaparib)控制,因担心出现耐药性,期望Watson能给出下一步的治疗方案。

2018年7月5日上午10时30分,刘银松代其妻子参加了上述多学科会诊。“(Watson)给出的方案是医生都知道的,也是现阶段采用的。”刘银松失望地对《财经》记者说。

同样,百洋医药集团董事长付刚也感受到预期与现实之间的距离。他此前在接受《财经》记者采访时坦称,WfO在华的推广进度跟预期有差距。

IBM Watson一度是AI医疗的代名词,但入华商业化推广两年来,“不如预期”却成了最大的评价。

尽管IBM Watson health副总裁Kathy McGroddy在接受《Fortune》采访时称,Watson health不仅是对医疗行业的变革,还是IBM 本身的革命。财务数据却显示,IBM已经连续21个季度总营收下滑。

两年来,IBM大刀阔斧削减传统业务,将业务架构从软件+硬件+服务,转变为云+认知+行业。其中,人工智能认知计算平台IBM Watson承载着转型的全部期望,这是一个集合高级自然语言处理、信息检索、知识表示、自动推理、机器学习等认知技术平台。

虽为时下最成熟的认知计算平台,IBM Watson仍只是一个科研项目。据华尔街著名投资银行Jefferies报告显示,在过去5年里,IBM投资了数十亿美元用于Watson研发和相关数据/分析能力的获取。IBM至今还没有公布Watson的财务数据

技术落地,需要找准合适的应用场景、对行业的洞察以及深度运营等。现在这位蓝色巨人不得不再次回答如何让“大象起舞”,也与大多数AI公司的焦虑相同——如何将炫酷的AI技术变现。

Watson价值几何?

希望从没有离开过刘银松夫妇,他们期待着新的药物、新的疗法上市,这也是驱使他们来找Watson的一大原因。

7月会诊WfO推荐的奥拉帕尼,李春梅已经在医生的建议下自5月15日就开始服用了。这是一款2014年在美国获批的治疗晚期卵巢癌单药,尚未在国内上市。国家药监局将奥拉帕利片纳入优先审评审批程序,预计2018年内上市,至于现阶段如何买到这种药,刘银松狡黠一笑,道:“看《我不是药神》啊。”

WfO是由纪念斯隆凯特琳肿瘤中心(MSKCC)四年训练而成,已学习超过300种医学专业期刊、250种以上的医学书籍、1500万页论文研究数据以及大量的临床案例。

IBM Watson推荐的方案还是太稳”,刘银松期待的是,Watson能给出最前沿的治疗方案

Watson并未收录最新疗法,因最新疗法还未产生大量数据,而其推荐的每个治疗方案背后都有相应的实证支持。此前,IBM Watson Health首席医疗顾问在一次行业会议上曾解释,Watson会倾向于保留数据量更大、更早期的临床数据和结论,医生可以看到这些临床数据的具体细节。

Watson不是帮病人看病,而是给医生做参考,让会诊过程中的信息更加标准化、格式化”。付刚称。

hanniman:在付费使用之前,患者为什么没了解到“Watson并不会给出最前沿的治疗方案”,以及“Watson不是帮病人看病,而是给医生做参考”这两点的?暂且不说Watson效果如何,至少在用户预期的沟通方面,就存在问题。要么是卖方为了赚钱,故意避重就轻,要么是患者自己存在侥幸心理,出了问题再把责任推向Watson,而不承认自己曾经听卖方介绍过。anyway,涉及到利益或生命,人们的言行就不那么“正直/理性”了。

这样的谨慎,使Watson推荐的方案与专家诊断符合度高。其宣传文案也说明了这一点,沃森肿瘤给出的治疗方案和MSKCC专家给出的方案有90%以上的符合度。

一位三甲医院肿瘤科主任认为, Watson与专家的诊断一致不奇怪,其数据和分析过程来自指南、高水平文献、高水平医院的经验,其对医生的指导不会出现严重偏差。

不过,这一说辞遭到挑战。国外医疗媒体STAT在对WfO的专题报道中提到,丹麦一份未发表的研究称,Watson给出的诊断方案与专家给出的仅有30%的符合度,所以该医院拒绝采购Watson系统。

hanniman:这种情况也正常,因为AI一定会出现一些未知性的结果,数据量超级大的时候,一定会出现黑天鹅事件,数据量小的时候,也一定会出现“体验不好”的用户反馈(比如人类和机器人聊天)。

对于操作者,WfO处理过程不复杂:医生输入主要病例特点,Watson从中提取病人属性,使用这些属性查找临床指南确定候选治疗方案,并搜索证据数据库,以查找每个选项的支持证据,包括并发症、禁忌症、MSK优选治疗等。最终,根据最佳证据,使用Watson分析算法优先考虑治疗方案。

医生们对Watson褒贬不一。

一些专家很重视其给出的诊疗意见,“Watson实现了文献、证据和数据在临床的应用。”参与刘银松会诊一主治医生对《财经》记者说,在所有的学科中,肿瘤是最讲究循证的。

认知关怀网络科技有限公司(下称认知关怀)副总经理王泰峰认为,Watson在所有的医院都有价值,其可以提升基层医生的决策效率,大医院专家可利用Watson的海量文献,提高会诊效率,对顶级专家而言,Watson可作为一种病例教学的工具,并且发现Watson的不足,进行相应训练。

而一些专家质疑,Watson就像一名律师助理,主要技能只不过是搜索文献而已,并提出疑问,它应该用在哪里?

如果Watson能解释是如何一步步给出患者诊疗方案,会让刘银松觉得更有用一些。

Watson提供的诊疗方案仅是方向性的框架,没有细到作为治疗方案去用的地步,需要具体执行的医生去细化。针对每个肿瘤病人的治疗方案需要考虑身体状况、既往疾病等因素,在刘银松看来,上述会诊结束后,医生私下建议妻子去做药敏试验反而是这次会诊最大的收获。

hanniman:这个可能就是Watson价值的体现,反而应该被卖方重视、强调。

Watson水土不服

自2016年,以一个商业化的产品身份进入中国,开始推广,美国籍的IBM Watson面临着中美医疗在体系、模式、诊疗方案差异等,诸多方面水土不服。

Watson秉持了多学科会诊模式,这也是中美肿瘤诊疗最大的差异。中国常是单科室作战,美国肿瘤治疗往往是多学科会诊——肿瘤外科、内科、放疗、介入科、影像、病理、检验等多学科参与。

去年Watson落地上海十院。上海十院肿瘤科主任许青告诉《财经》记者,如果没有Watson,多学科会诊中意见不一致时,最终还是听那些高资历医生的建议,有了Watson之后,相当于有一个相对客观的方向把控。

hanniman:Watson不可能来把控方向、承担责任;最终还是得听资历最老的专家。

涉及多个科室、多个专家,这对于现阶段国内以科室为主的医院提出了很高的要求。

积年习惯,公立医院不同科室之间难以配合,谁组织、谁落实等权责难以厘清。盛诺一家副总经理兼首席医务官王舜告诉《财经》记者,国外医疗机构设有肿瘤中心,其中又有外科、放疗科、病理科等多个学科的医生,而国内医院都是肿瘤外科、肿瘤内科等,各自为政,不可能每周拿几个病例进行讨论。

hanniman:“AI+行业”的文章,如果没有这种非常接地气、一看就知道是做了功课后才写得出的内容,那文章的差异化价值就不大。

《财经》记者获得的一份市场推广资料称,WfO现可支持乳腺癌、肺癌、结肠癌、直肠癌等10种癌症。

在刘银松预约举办的会诊中,参与会诊医生有10余名肿瘤科医生。一位医生就抱怨道,医生工作繁忙,时间紧张,还要浪费时间在会诊上。

许青介绍,在上海十院Watson智能会诊中心已经接诊过将近500名患者。这些患者多为经济情况较好的男性或因疑难杂症,或是咨询过多个医院的专家,但说法不一,希望进一步明确诊疗。

在三甲医院,WfO会诊难以频繁开展,而日常诊疗应用也受限。“日常诊疗太简单了。Watson的价值就不是很大,它的价值在于相对复杂的疾病或是大家的意见不一致的时候。”许青说。

由于中美在肿瘤治疗防范方面的差异,Watson也在接受本土化训练。然而,一些学者认为Watson最好不要太本土化,他们希望Watson提出的方案与他们给出的不同,这样才有探讨学习的空间。

“本土化”也意味着针对中国本地的病例、文献等进行训练。此前,IBM公司管理层曾对媒体表示,Watson需要更好与医疗机构内部的信息系统对接,并且需要更多的真实病人数据,这决定着其能否长大,这不仅是IBM面临的挑战,也是所有AI公司的难题。

许青称,目前Watson没有与上海十院的HIS系统打通,会诊中,仍需要人工输入病人的资料。

有一家医院在拒绝采购Watson时,提出三点:一是Watson没有通过美国和中国的监管部门的认证,出了问题谁来承担?二是为什么要向患者收费6000元;三是医疗数据开放给外企的担忧。

2017年10月,中电数据与IBM成立合资公司,向中国市场提供Watson Health相关解决方案 ,“就是要解决引进先进技术,数据不出境。”中电数据董事长李世锋告诉《财经》记者,中电数据提供给IBMWatson的是模拟数据。

在全球范围内,Watson还在寻求更多的数据、覆盖更多的癌症类型。Watson对数据的胃口很大,这意味着IBM必须长期源源不断地砸重金在数据获取上。

“三岁”Watson要赚钱

全球范围内,仅有少数医院采购了Watson系统,这离IBM的目标——主导数十亿美元的全球癌症市场,还相去甚远。但已有声音指责IBM对Watson系统商业化操之过急。

上述STAT的报道就称,IBM未能充分认识到全球范围内部署到医院所需面临的挑战,推出了一个不成熟的产品,正是因为IBM急于通过Watson变现。

变现的压力不仅是IBM的,国内代理商同样背负着。2016年,认知关怀成为WfO在中国的本地运营服务提供商;2017年,百洋医药集团与IBM签约,旗下百洋智能科技为Watson Health中国地区的战略合作伙伴。

在分级诊疗大背景下,国内代理商期望在基层医疗机构找到商机,打出的卖点是:WfO可以规范肿瘤治疗过程。

不过,县级医院更多定位为常见病的诊疗,与Watson的价值——为疑难杂症治疗提供第二诊疗意见不符。何况“(指基层医生)只能骑自行车,大卡车肯定开不了。”许青认为,Watson更适合辅助大医院的专科医生。

基层医生也不敢直接用系统给的判断。”一位AI医疗业内人对《财经》记者说。

盛诺一家曾与百洋科技合作引入WfO,但没能真正落地。“Watson限制太多。”王舜分析,如WfO不支持18岁以下的肿瘤患者、孕妇及多原位癌,它更适合那些经过一线治疗但还没有二三线用药的患者。

hanniman:AI落地初期,一定有更细分的场景/用户定位可以被挖掘。目标用户范围被缩小了,不是坏事,反而是好事,但关键是,产品业务负责人如何解读、如何针对这个细分定位来做MVP验证和迭代优化。

目前,认知关怀和百洋科技都对WfO交互界面做了汉化。认知关怀总经理华松鸳告诉《财经》记者,汉化了几十万条词库,同时建立了一套汉化的标准,但IBM Watson提供的诊疗意见多是发表在国际顶级杂志上的英文文献,目前并未汉化。这要求基层医生具有较高的英文文献阅读水平,而国内大多数基层医生很难达到。

hanniman:垂直领域应用AI,就会遇到类似这种差异化的问题,但这种看似“脏活累活”的地方,反而是有一定价值的,可能就是机会,不能太忽略过去。

国内代理商需要探索Watson在国内的落地解决方案、训练其不断长大,并且找到适合的商业模式。

尽管认为大众对Watson期待过高,“你要允许三岁小孩有三岁小孩的能力,但还是能帮你去工作的”。华松鸳还是称,“百洋科技关心的是下家在哪里?”怎么把产品转卖给别人,怎么样像药品一样通过层层渠道分销下去。

从项目伊始,定位相同的两家代理商是Watson在中国最主要的推手,两者也是竞争不断。认知关怀给《财经》的数据是,WfO在70多家三甲医院正式落地运营;百洋方面称,截至2018年3月,WfO已覆盖65家医院和医疗机构。全球范围内,WfO覆盖了150多家医院。

Watson肿瘤认知包括WfO、WfG等六个产品。百洋科技和认知关怀代理销售WfO,百洋科技则为WfG在中国地区的独家分销商。WfG正在方案组建阶段阶段,还没大规模的使用。

3月,百洋科技与IBM共同宣布,将WfO的独家总代分销权战略合作协议由三年延长至八年,即百洋科技还可以选择别的机构进行分销。“如果只是三年,可能还在研发。”付刚说。

STAT报道称,全球范围内,根据提供的产品以及绑定的服务不同,Watson收费额度从1000元到8000元不等。

华松鸳称,国内Watson的收费是基于其服务内容,如不同级别的专家提供服务、不同配套的其它服务等,收取费用从一两千元到几万元不等。

许青介绍,在上海十院,如果指导会诊的有5到6位医生的多学科团队收费6000元;如果仅一二名医生,则收费2000元。

这也被视为Watson是附着在医生来收费。“沃森从来没有对患者开药,它只是一种辅助手段,不能代替医生决策。”华松鸳表示,Watson就像计算机一样,仅是医生的一个工具。

既然是医生的工具,为何患者来买单?“如果医院觉得IBM Watson能提升品牌,代患者买单也可以。”华松鸳称,IBM开发、杭州运营产品有成本,又有市场取向,总要有人买单。

而付刚认为,Watson的推广需要有一种“不赚钱”的心态。截至发稿,IBM未回应记者的采访。

一位业内人士告诉《财经》记者,百洋科技在IBM Watson的项目上至少亏损2亿元。华松鸳称,认知关怀现在有营收,但是是否盈利则不方便透露。

Watson没有经过监管部门审批,被很多医生视为最大的风险因素。“如果按照Watson推荐的方案,出了问题谁来负责?”一位三甲医院影像科主任向《财经》记者质疑道。

2017年2月,美国德克萨斯大学宣布关闭Watson合作项目;5月,风投公司Social Capital的创始人Chamath Palihapitiya 在 CNBC 上直言:Watson就是个笑话,IBM的专长其实是通过强大的营销和市场体系,以及信息不对称,让消费者为他们并不了解的服务买单。

“IBM是个科技公司,他们对自己的技术非常有信心。”付刚称,但具体到技术,向哪个方向去滋生、去演变,他们也不是那么有把握。

——浅谈智慧城市在管理决策中应用的一些设想
本文共19622字,共分为三部分:
1.初心篇:为什么需要智慧城市以及什么是智慧城市?
2.操作篇:如何建设智慧城市?
3.设想篇:一些关于智慧城市的思考及可能的远景应用设想
本文为作者原创文章,未经授权,不得转载
简介
建立一个“全知全能”的“城市大脑”来辅助管理者来实现更科学,更人性化的治理的设想很早就被前人既在严肃的科学论述也在诗意的科幻小说中提到过。从上世纪中人工智能这个概念被提出来后,人类便一方面开始生活在人类的决策地位被机器颠覆的忧虑中,一方面为了提高效率兴奋地发展智能技术。智慧城市这个概念,也随着2012年深度学习算法在ImageNet比赛上突破而掀起的第三次人工智能热潮到来而再次进入风口浪尖。
遗憾的是,迄今为止我们还没有一个为大家所共同接受的对”智慧城市”的定义。这个概念究竟意味着什么?或者换个角度来说,”不智慧的城市”与”智慧城市”之间差异是什么?现在普遍认为,要建设智慧城市则需要一套先进的科技系统(姑且称之为智慧城市系统),那么建造这套智慧城市系统是为了解决什么问题?设计的出发点应该是什么?
如果用一个不太恰当的比喻,把建设智慧城市系统与克隆人脑类比起来看,现在我们在市场上见到的智慧城市项目,更像是我们因为技术上的突破成功得克隆了如视觉细胞或听觉细胞等部分模块,而我们离一个由中枢神经细胞控制的大脑(”城市大脑”)至少还缺了两个部分:1.克隆出中枢神经细胞,2.能把中枢神经细胞和已经有的模块顺畅联结起来的系统。骨感的现实是,我们离这两步还很远。
正因为离我们还很远,智慧城市的概念还很模糊,我们便能很有幸地享受建设智慧城市最有趣的一部分工作:探索智慧城市的内涵。
虽然我们对智慧城市的概念不太清楚,工业4.0这个概念是定义是较为清晰的,通过智能化技术升级改造制造业(第二产业)。从产业角度来看,我们是不是可以把智慧城市的概念依此类推至用智能化技术升级赋能囊括第一、第二、第三产业的系统呢?
答案是否定的,至少是不全面的。需要注意的一个问题是,用智能化技术升级改造第一、第二产业都没有问题,但是我们一般理解的第三产业,也即服务业(包括代理业、旅店业、饮食业、旅游业、仓储业、租赁业、广告业等),主要是考虑的企业端的服务,或者说”私人端”(private side)。而作为一个城市,其主体功能是公共服务(public service),包括行政、经济、文化、交通等多方面决策管理协调功能。因此我们在实际建设智慧城市的时候可以一步一步来,从外围的功能,以项目为试点。但是在建设之前,设计时需要优先以城市的核心功能作为切入点进行统筹规划。什么是城市的核心功能?我们认为,就是政府的决策管理功能。
本文目的是就如何建设智慧城市做一个探讨。由于智慧城市系统对应的城市业务功能范围很广,下文主要讨论的是智慧城市管理决策方面,也是我们认为的一个城市功能核心,并对智慧城市系统能在经济等领域有哪些应用提出一些抛砖引玉的设想。
下文结构大致如下:首先,我们将以增值税为切入点讨论智慧城市主要解决的核心问题:信息的不对称性,并提出智慧城市的目标是精细化的管理决策。第二部分将讨论什么是智慧城市?包括介绍目前建设智慧城市的发展现状,及存在的部分问题并提出我们对智慧城市系统的定义。第三部分将对如何建设智慧城市进行两方面的讨论,1. 首先从路径层面提出自上而下(国家顶层设计),自中间而下(由省为单位试点),及自下而上(信息打通及个人赋能)三种维度,相辅相成得逼近我们对智慧城市的刻画。2. 挑选智慧城市系统中较为重要的城市综合管理平台系统为代表,从操作层面讨论技术实施的路径。为此我们把决策流程一分为七,并分别讨论每一个模块中哪些智能化技术也许能起到赋能升级作用,整体又如何组合成城市综合管理平台,后简要介绍融资及运营机制。通过前三部分的铺垫,我们希望向读者传达我们对智慧城市概念的理解,并将智慧城市在未来经济等领域应用的设想及思考放在最后,以希望跟业内人士进行交流。

目录
  1. 为什么需要智慧城市?由增值税的由来及发展历程引出智慧城市的核心问题是信息的不对称,目标是精细化管理决策
  1. 智慧城市是什么?
  1. 发展现状:国内国外智慧城市部分案例
  1. 发展中出现的问题:缺乏清晰顶层规划,项目导向而非效果导向,技术导向而非体验导向
  1. 智慧城市的定义
  1. 以农村寄宿学校撤点并校为例看有无智慧城市的情况
  1. 智慧城市系统相关技术
  1. 如何建设智慧城市?
  1. 智慧城市发展路径
  1. 自上而下(国家顶层设计):主要分为顶层设计,控制性技术规范层,企业产品层三个层面,定义每一部分内容与相互关系
  1. 智慧城市管理中评价体系:有智慧城市功能后一个重要控制层
  1. 自中间而下:以省为单位进行试点为较为实际的操作路径,但需注意标准化体系的建立
  1. 自下而上
  1. 基层部门之间联结:提升信息交互效率,顶层规划并不可能规划到具体执行层面,智慧城市系统应建立沟通机制设立渠道,各部门工作层面的联系机制应向记忆神经突触一般按使用频次及重要程度来分配资源
  1. 个人层面:通过智能技术把一线工作人员从重复性的劳动中解放出来,从而进行需要人类高级思维的工作。个人智能助手的发展前景及潜在应用,语音成为下一代人机交互接口的可能性,其在智慧城市中应起到收集个人操作数据的作用
  1. 智慧城市技术实施路径
  1. 智慧城市综合管理平台:最为重要的智慧城市应用怎么建,之所以认为是最重要的应用,是因为其在信息层面是覆盖信息范围是最广的,各个垂直行业的应用可以根据功能模块定制相对应的平台,比如交通领域的阿里城市大脑
  1. 感知层:第一个层面是把部门间“信息孤岛”数据打通
  1. 平台层:第二个层面是数据的融合,清洗,构建相应数据库
  1. 应用层:第三个是根据需求建立相关应用,如政府对个人信用记录,检索交通信号灯监测等
  1. 业务层:第四个是大业务需求,根据业务需求选择模块化功能,如宏观审慎监管信息体统架构的建立,以法人为脉络的资金链回溯实现穿透式监管等等
  1. 智慧城市现有应用案例
  1. 交通领域:
  1. 阿里巴巴城市大脑在交通领域应用的案例
  1. 智慧城市为城市功能片区规划提供更好的数据支撑
  1. 智慧城市融资及运营模式
  1. 运营模式
  1. 国内智慧城市建设典型PPP模式对比
  1. 存在的问题
  1. 智慧城市建设过程中一些思考 (本文重点)
  1. 智慧城市能为经济改革做什么?经济改革核心问题为理顺扭曲的资金供应关系问题,具体体现为宏观去杠杆,降低影子银行规模等,中间重要一步为梳理系统性重要金融机构,有了智慧城市系统后能怎么更好的办这件事情的设想,包括从Alpha Go带来的启发
  1. 负反馈机制与延展预测,模拟:以一个信访的实际案例介绍建立负反馈机制能怎么改进政策制定的流程设想
  1. 新的融资机制和组织架构:是否存在新的组织形式?
  1. 附录
  1. 智慧城市部分技术应用及前沿:简要介绍物联网,云计算,自然语言处理,计算机视觉的应用领域及科研前线问题
  1. “政务型产品经理”是什么?:政务型产品经理的需求,角色定位,能力要求,潜在来源讨论
  1. 参考

1. 为什么需要智慧城市?
在介绍智慧城市之前,我们先来看看目前的城市管理决策中存在哪些痛点是可以通过智慧城市系统改进的?下面以增值税为中心,介绍几个例子。
在一段几年前网上流传的的视频上,刘QD在一次内部员工会议上讲到为什么在品牌方动辄采购几十亿元并获得极低采购价的JD在价格上却屡屡要竞争不过别的网站上销售额仅为百上千万的小商户,“除去一些卖假货的,核心是17%的增值税,小商家因为进货时没开增值税的发票,或者是把富余的发票违规卖给别的行业,这给他们带来成本上百分之五到八个点的优势,导致一些小商家甚至可以在售价比JD进货价还便宜的情况下生存。”这就是所谓的劣币驱逐良币,规规矩矩交税的商家竞争不过非正规交税的商家。政府的出发点应该是营造一个公平的市场竞争环境,一个良好的制度既需要把有能力的企业甄选出来,促进其发展,同时也需要让“老实人”不吃亏,自然的随着市场竞争环境“自生自灭”,还要把不法企业甄别出去。
增值税作为我国重要的税种之一是1979年开始试行的,我国现行的增值税制度是以1993年财税改革的成果为基础的,是由朱总理他老人家带着人一个省一个省跟地方谈判谈下来的,当年确定并被后来长期保持的17%增值税率,是根据在当年的经济环境下确保大部分企业在营业税改成增值税后不增加税负而核算出来的。当年为使各省同意税制改革谈判已经很难,要在这基础上改变也难。虽然后续一直有一些小幅改革,但是对于一般制造业17%的增值税税率一直保持到了2018年5月1日才改为16%(其他行业税率不同)。由此可以看出,政府制定政策就像人一样有天然的惯性,其影响的范围又决定了改变一项既定决策比制定初始政策可能需要更大的推动力,需要更多的因素撬动。
有时候一个政策在制定时出发点是好的,实行的过程中情况往往很复杂,可能跟设想的有出入。比如通过降税免税扶持小微企业。刘QD在讲话中提到一个例子。政府提出要收互联网小电铺的税,但是有人反对说收税会影响中小企业生存,这跟国家的大政方针相背离。但是小微企业背后事实上有两个群体要区分开来。我们这里脑海里浮现出来的小微企业往往主要是指在电商上的小微企业,这部分企业背后的主体是上过大学有良好网络知识基础的人群。从这个角度看,不收电商中小企业税确实促进了互联网行业的发展,鼓励了年轻人创新创业,对国家经济转型是有帮助的。
但从另外一个角度看,电商作为一种先进的商业模式,其发展意味着生产效率的提升,对于整个社会来说则意味着科技代替了部分劳动力。而这些被替代的主体是谁呢?主要是分布在中国各地的商业模式远远落后的街边小店。这些街边小店背后是主要是没上过大学的年轻人,更多的是三四十岁下岗工人,农村打工人员进城打拼多年后积累下来开的小店。不收互联网中小企业税对于这个群体来说则显得不公平,这种80年代兴起的路边小店因为线下的经营方式从创立之初就一直在交着各种营业税,定额税,城管费,垃圾运营费等大小杂税,并且会继续交下去。而在网上开店的人群往往受各种杂费影响较小,因为工商局一般也找不到。这客观上就可能造成不公平的现象,本来竞争力就更强的网店,没有被杂税干扰,被免征税,街边小店们的竞争劣势更加扩大,如果他们无法成功转型,则可能意味着这条生计都无法维持,造成潜在的社会问题。一个理想的公平制度,应该是不管线上线下一视同仁,30万元营业额以下企业全部免税。
一项出发点很好的政策,其实际执行的效果也可能会走了样。这是因为上面制定政策时对下面情况不一定会完全了解。下面未来的情况,也不一定能及时的反映上去以提供做及时调整的支撑。这就导致制定政策时,有时候会写的比较模糊,给下面预留操作空间,但这个操作空间又可能会滋生别的问题,比如腐败。
综上所述,1.政府的出发点应该是制定营造公平的环境的政策。2.政府的惯性意味着做任何一项决策都需要十分的慎重,一做就要做尽可能正确的决策,后续要改是很麻烦的。3.即使是尽可能好的决策,也未必那么有效,需要实事求是地不断与时俱进做出精准的决策
这归根结底反映的矛盾点是什么呢?信息的不对称。政府做出的决策是面对一个整体的,是在一个时间点上的,因而导致做出的决策大多数是线性的,出发点是好的政策不一定在每个地方都有效,一项再好的政策也不可能永远是正确的。
比如对多数行业的增值税率就是17%没有例外,比如银行存款利率面向公众是一致的,这是一条线。而当特殊情况出现,政策线的边界需要做局部调整了的时候,方式主要是人工的,信息的反馈不一定是及时的。如资管新规发布后导致一些企业资金出现困难,政府发布前肯定已经意识到会出现一些问题,但因为没有一个追踪企业级资金的精准信息系统,具体哪里会出现并不好预计,人工的方式进行全面的预先摸排也不现实;比如面对中小企业降低税率扶持生存;比如精准扶贫;比如给深圳特区特殊政策优先改革开放,这些重大决策都需要人类思维中高层级的智慧,通过把过往丰富的经验进行高度抽象的整合。目前的情况前期支持决策的抽象数据不一定充分,决策前后信息反馈也不一定及时全面;总体而言,因为人力物力及科技水平的限制,政府的决策总体是线性的而非曲线的,出发点是希望得到全局最优解的,而我们连局部最优解也许都没法保证达到。因为信息的不对称,要针对每一个社会主体定制个性化的政策方案是非常非常困难的。
一个智慧城市核心问题应该解决的是什么?我们认为应该是信息不对称。想要靠人工发明的机器系统实现人类能做到的高层级智能还很远很远,不具备可操作性,可操作的是收集为决策做支持的信息和数据。要实现与时俱进(时间)、因地制宜(地点)、实事求是的精准决策,需要在架构上实现扁平化,这就要求信息的沟通渠道是实时,全面而且准确的。
因此精准化管理决策,即利用智能化技术优越的信息采集、分析能力,在政府决策领域帮助决策者不断逼近全局最优解,以尽可能改善信息不对称的情况则是我们认为的智慧城市发展的目标

2. 智慧城市是什么?
2.1 发展现状
自从智慧城市的概念被提出以来,智慧城市的发展建设情况方兴未艾,据国家新型智慧城市建设部际协调工作组统计,全国共有220个城市开始了智慧城市相关规划,如无锡,银川,杭州,深圳等一系列城市走在前列。无锡拥有全国唯一的传感网创新示范区,是首批国家智慧城市建设试点城市,杭州市依托阿里巴巴建设“城市大脑”平台,深圳在“华为智慧城市分会2017”上发布智慧城市建设成果,与腾讯合作建设“智慧广东”,银川举办全球(银川)TMF智慧城市峰会,嘉兴市组建了市委副书记、市长、以及实施公司总经理组成的新型智慧城市“三组长”架构领导智慧城市建设。财政部已入库智慧城市PPP项目共计71项,总投资规模达565亿元。华为、腾讯、阿里、百度、滴滴、京东、商汤等企业先后宣布进入智慧城市领域。国际上一些国家、城市与企业也已探索出丰富成果,2009年IBM提出“智慧地球”概念,随后美国宣布“智慧地球”成为国家级发展战略,韩国通过填海造陆把松岛市打造成了“全球第一个智慧城市样板”,巴黎里约热内卢与IBM公司合作整合了市政管理系统,Google下属Sidewalk Lab发布智慧城市愿景规划,计划将多伦多东部的一片区域打造成“未来之城”,新加坡,伦敦,纽约,旧金山等城市在2018年英国Juniper Research发布的全球智慧城市领先城市Top 20榜单上位居前列。
2.2 发展中出现的问题
近年来,智慧城市的发展如火如荼,与智慧城市相关的项目如雨后春笋般落地,如自2012年以来因为深度学习在视觉识别上算法的突破,我国有一批人工智能视觉算法团队在技术上开始能满足公安部门在安防,交通等领域的工程落地标准,因而得以蓬勃发展。但是,对于整个城市来说,目前智能化技术还处于早期阶段。落地的主要是因为计算机视觉技术成熟而推动的试点项目,项目与项目之间缺乏统筹规划,因而可能形成新的”信息孤岛”。
客观的说,现行阶段的大多数项目都是经过公安部分的工作人员与企业技术人员经过深思熟虑讨论后决定的技术与需求能结合的比较紧密的项目,之所以出现关联性不大的问题原因有几点:1.时机早:目前智慧城市的建设工作处于早期探索阶段,技术如何能成体系的升级城市功能需要一批既懂技术又懂业务的人进行思考设想,这是在物联网,人工智能时代新的思维模式,需要适应。2.技术不成熟:机器在理解水平上还处于非常早期阶段,自然语言理解,知识图谱等一系列技术还不能让人们设计出足够”智慧”的产品,智能技术在一些零散的任务上也许能达到需求(如搜索),但是因为场景的复杂性,通用的系统还不够智能,处于一个食之无味,弃之可惜的尴尬阶段。
2.3 智慧城市系统的定义
智慧城市系统究竟是什么呢?智慧城市系统不应仅仅是一种政府信息技术手段的升级,总体规划也不应是物联网、云计算、大数据、“互联网+”、人工智能等技术的简单堆砌。智慧城市系统应该是一个全面,精准,实时的把老百姓需求与城市管理决策对接在一起的决策辅助系统,是在新技术条件环境下,一种新的管理思维模式,是以城市宏观业务需求为设计出发点,以提升城市生活体验为目的的复杂巨系统。智慧城市系统需要整合城市功能的各个模块。智慧城市的总体规划需要通过对城市治理,运行管理,功能服务等机制的深入了解,提出与技术手段相配套的针对深层次弊端的解决问题的技术架构框架。总体规划应该着眼于较长的一段时间,建设过程循序渐进,并充分引入公众参与,培育一个政府,社会,公众三方参与的可持续的商业模式。
——参考自《新型智慧城市发展报告 2017》

2.4以农村寄宿学校撤点并校为例看有无智慧城市的情况
为了方便读者理解这么一个复杂抽象的定义,下面用一个例子来介绍一下在智慧城市中决策具体意味着什么?
城市的发展方向其实是由一个个大小决策决定的,因为决策背后太多有多方面复杂的考量,我们以一个很小很具体的案例入手:
《财新》18年6月发布了一篇《农村寄宿制小学:代理家长在哪里》主要讲述了在城镇化背景下,许多乡村小学实行”撤点并校”,导致许多”家门口”的小学被关闭,许多农村孩子不得不去乡镇里集中上寄宿制学校。这些孩子因为本来就从去城市里打工的父母身上得到关爱不够,如今又在年幼时离开爷爷奶奶辈的照顾去寄宿制学校,普遍产生心理问题,负面情绪主要体现在抑郁,孤独,甚至有想自杀的情况。
如果我们把一项决策的过程抽象为以下几个步骤:
感知- 选择 – 预测延展 – 执行 – 指标 – 反馈 – 优化
1.感知:通过基础设施传感器(视频监控)、政府系统内部渠道(如公安报案信息、银行等)、群众信件、媒体、网络等方式得到的数据进行汇总,了解什么问题是需要解决的?
2.选择:有什么解决方式供选择?
3.预测延展:预测选择一个解决方式对问题本身有什么直接影响?,对各个不同部门、方面会产生什么间接影响?
4.定义:定义验收结果时需要看的指标
5.执行:具体执行选择的解决方式
6.反馈:收集该解决方式实际对各个方面的显性影响及整理隐形影响
7.优化:优化解决方式及验收指标的选择

(没有智慧城市系统时)那么具体在这个乡镇府的角度来决定是否执行撤点并校来说,他的决策可能就被分解为:
1.感知:通过工作人员对基层学龄人群情况,教师状况,本乡乡村学校运行情况的了解,上面下达的任务要求,指标,自身财政水平等现实因素发现了需要对该校的小学进行调整
2.选择:有哪几种方案?是不是一定要撤点并校?在哪里建设新学校?现状维不维持的下去?别的乡镇怎么做的?别的省怎么做的?等等
3.预测延展:预测撤点并校能不能实现?自身财政上能否满足?对乡政府有什么得失?对上级各部门主要有什么影响?(现在主要考虑的)对学生学习成绩有什么影响?对乡村教师有什么影响?对家庭有什么影响?(可能会考虑到的?)对儿童心理有什么影响?(延展到别的部门影响:一般在预测顺序很后端)
4.定义:如果执行撤点并校主要看什么标准来验证效果?(目前主要看新校楼落成,开学)谁去验收校舍建筑质量?(需不需要乡政府考量,这个问题目前考不考量?)学生成绩来看办校影响?学生心理健康程度这个指标基本存不存在决策考量排序内?
5.执行:根据前面的信息决策,然后执行决策,如执行撤点并校
6.反馈:建校成果如何?上级反映如何?村民反映如何?学生反映如何?社会反映如何?能否对反馈进行反馈,如发现的问题能否有效反映上去?如这次媒体报道会对该决策有什么反馈,负反馈的效果?
7.优化:如何改进现有决策及优化下次决策?如学生心理健康指标是否能够加入考虑的范围?生活老师的配套资金能够确保跟上?下次如果没有配套资金的时候有什么预案?能否引入社会资本?
即使是乡村小学这一个小的案例,其背后的因素已经足够复杂,现实的因素是乡政府不得不最先考虑的因素。儿童心理问题没有被考虑到,或者被考虑到但是被忽视了有其现实原因,要改变也不是乡政府一方有能力能办到的。那么智慧城市系统在这个问题上能对解决问题提供什么帮助呢?我认为最根本的就是通过信息化把思考的流程记录下来,让问题按照重要程度在政府系统内与考核制度联系起来,也就是前面说的把需求和目的对接起来,解决信息的不对称。

(有智慧城市系统时)我们按照上面7点来看,如果我们有一个智慧城市综合信息平台,那我们的决策流程能升级成怎么样呢?
1.感知:首先什么是问题重要程度呢?一个简化的指标就像是政府内网的报告中被提及的次数,现在的问题就是乡一级政府也许觉得问题是本级政府解决不了的,也就不向上反馈,或者反馈了又被中间某一层压下来了,反馈渠道不通畅。因为没有电子化,制定政策的部委在问题矛盾积累到一定程度以前并不一定了解实际问题发展的范围。试想如果未来的各级政府能有一个像知乎一样的问题平台,根据问题被提及的次数,其能被推送的范围就会上升,使得很多小地方的问题能汇聚成一类大问题。
比如心理健康问题,也许情感监测功能在智慧城市系统建成时已经内嵌到系统里了,但是如果没有足够多的反馈让系统”意识”到寄宿学生心理是一个需要关注的问题,技术人员就不知道需要把这个情感监测工具用到监测儿童的课堂表现上来感知儿童心理状态。进而,通过情感识别的算法感知儿童心理这个手段也就无法被应用了。
2.选择:解决方案的办法案例收集分享渠道不通畅,村支书们对于有什么办法能产业脱贫没有信息平台了解,有好的经验也无处分享
3.预测延展:如果有一个好的延展方向得到验证,可以同步到每一个村的信息平台中,比如让县一级镇一级政府认识到需要加入从儿童心理角度的考量呢?至少可以促进他们从这方面去思考
6.反馈:如万达内部管理系统一样,对一项任务需要根据系统内设的角度进行反馈上报,通过自然语言理解,大数据技术进行汇总提炼。
7.优化:试想一下运营人员像滴滴打车车中有无异味一样提供选项让村支书选择某个反馈问题值不值得加入邻村反馈问题表中,通过A/B test优化反馈流程

2.5智慧城市系统相关技术
总之,通过智慧城市系统,我们设想可以把决策的流程通过信息化手段记录下来形成数据,学习这些数据,优化,并逐渐发展成一些自动预警的决策辅助功能。另外智能化技术在决策的流程上只在某些环节能较大程度的赋能。
基于目前的技术水平,智慧城市在整个管理流程中短期内能够提升的步骤是感知(1)和反馈(6),其中主要涉及的技术有物联网、云计算、人工智能中自然语言处理(Nautral Language Processing,NLP)和计算机视觉(Computer Vision,CV)
中长期内可以取得突破的应该是预测延展(3)及优化(7),其中主要技术包括但不限于自然语言处理,知识图谱等等。目前的自然语言处理技术对以文字语义及逻辑上的理解(semantic understanding)或者说是机器认知能力还有待突破,没有语义的理解,无论是信息的收集,还是构建数理模型都造成了信息的流失。
关于智慧城市系统中部分具体技术的介绍,及相关技术的研究前沿请参考附录1 智慧城市部分技术应用及前沿

3. 如何建设智慧城市?
3.1 智慧城市发展路径
介绍完为什么需要智慧城市及什么是智慧城市后,我们来讨论一下如何建设智慧城市的问题。上文简要介绍了一下智慧城市决策可以被分为7个部分,及相关部分可能涉及的技术。下面介绍一下怎么把这些模块”拼成”一个智慧城市系统。
我们的设想主要有三种相辅相成的路径,自上而下-国家层面规划,自中间而下-省级开始试点,自下而上-基层部分打通沟通机制及个人智能助手。
3.1.1 自上而下(国家层面的顶层设计)
这条路径主要分为顶层设计,控制性技术规范层,企业产品层三个层面,这三个层面是由大到小的覆盖关系。
智慧城市建设是一个要素复杂、应用多样、相互作用、不断演化的综合性复杂巨系统。智慧城市建设,要有负责城市顶层设计的“总体部”,要有规划设计复杂巨系统的有效方法论。用以往设计电子政务、行业信息化等中小规模系统的组织管理模式和规划方法理论来规划设计智慧城市从方法上是行不通的。
3.1.1.1 顶层设计
对于政策规划层面的顶层设计,政府要从城市发展的战略全局出发研究制定智慧城市建设方案,把有限的资源投入到亟待解决的问题上,不能只谋一域,也不能贪大求全、照搬照抄。要把老百姓的切实感受放到第一位,坚持以人为本,聚焦发展重点,区分轻重缓急,统筹开展工作。
3.1.1.2 控制性技术规范
对于技术实施层面的顶层设计,应将其定位为总体规划的细化和落实,作为智慧城市总体规划与建设实施方案间的衔接桥梁,其作用类似于城市规划中的“控制性详细规划”,总的特点是具有“整体的明确性”和“具体的可操作性”,在建设实践过程中能够“按图施工”,避免各自为政造成工程建设过程的混乱无序。技术实施层面的顶层设计要从全局视角出发,对项目的各个层次、要素进行统筹考虑。通过业务、数据、系统和技术等多个视角,采用全局的系统分析。进行目标架构设计、互联规范和统筹建设约束分析。明确业务之间的协同关系、系统之间的协同和共享关系、各项任务的配合关系,设计目标架构路径,以此指导智慧城市的全局统筹发展,推动信息共享、系统整合和业务协同,真正实现智慧城市建设的目标一致、功能协调、架构统一、数据融合、资源共享和业务协同。
以上参考自《我国智慧城市健康发展面临的挑战》国家信息中心单志广博士
3.1.1.3 政务型产品经理
在政策规划层和控制性技术规范层下,第三个层级是企业在技术实施环节与上文提到的“控制性详细规划”对接,使得各个地方在标准上能够实现共通,我们暂时称之为产品层。在智慧城市发展的起始阶段,项目主要通过技术推动。但是智慧城市因为本身的公共服务性质,其发展的路径应该区别于传统的技术驱动行业,如互联网,移动互联网一般都遵循技术——产品——运营的发展阶段,智慧城市在项目设计之初,就应该更多的从以产品和运营为出发点,以体验为导向的设计思路,设身处地的为老百姓谋福利才能真正保证智慧城市的可持续性。在这之中,随着基础设施及平台逐步建设,在以城市体验为导向的智慧城市建设中,起到承上启下作用的智慧城市的“政务服务产品经理”的作用会逐渐重要。
“政务服务产品经理”需要懂得政务业务,具有互联网思维,还需要具有决策权力,能够协调多方资源。既要是业务能手,又要是管理者。
–《新型智慧城市发展报告2017》
关于这支亟待建立的政务型产品经理从何建立做了一些简单设想,详见附录2 “政务型产品经理”是什么?
3.1.1.4 评价体系的建立
智慧城市在建设过程中还有一项重要的内容:统一的评价体系的建立
评价体系独立于建设标准,是对建设成果,运营治理水平进行量化计算,设定标准的流程在建设前能更好的了解城市的优势劣势及重点解决的问题,对运营水平进行统一化管理。
智慧城市评价体系参考案例
智慧前海建设评价体系架构–参考自《智慧城市–顶层设计与实践》

3.1.2 从中间(省级)而下
有了顶层设计后,根据中国的实际情况及目前的发展阶段,智慧城市还是会以项目试点为主要方式推进,以省为单位进行智慧城市建设的逐渐成为目前的状况,如贵州省,广东省,上海市,江苏,北京都先后宣布了各自规划。以重点项目制试点制发展的好处是能集中力量快速做成有示范效应的项目,同时也能把经验推广到后续项目中。主要需要统一的就是确立未来信息融合时的统一建设,接口,评价标准。标准的建立需要具备前瞻性,需要为未来可能的新技术预留接口及工程缓冲空间。如韩国的松岛市智慧城市做为一个示范案例规划的时间为本世纪开端,当时智能手机,WiFi等技术均没有大规模发展,设计规划人员也坦言当时没有预料到如今智能手机的普及性。因此在规划时概念的领先及对未来变化的预留空间显得尤为重要,背后的设计哲学如何从以人为本的角度出发,如果更多的使居民和城市功能有机的结合到一块,需要专业的人员来思考。
目前发展案例:贵州省大数据发展管理局,雄安新区等

3.1.3 自下而上(设想)
自下而上主要从两个角度:1.基层及部门之间交互联结 、2.以人为个体的智能助手训练
3.1.3.1 基层部门之间的联结打通
智慧城市发展的技术路径第一步是打通政府各部门“信息孤岛”,实现部门间信息的连接,这一点后面会详细描述。虽然有了从上到下的架构,但是基层一线工作人员其实最了解单位之间联系最频繁,最重要的节点在哪里,有些并不一定能给规划人员包括在内。因此应该建立一种像神经元细胞相互自主连接的机制,通过建立平台使得部委,省市各厅局间可以自行建立网络,某一链接被激活的越频繁,其在系统内的权重及分配得到资源相应提升,就如同建立了不断强化的神经突触间的联系。
3.1.3.2 个人智能助手(脑洞系列)
目前很多一线工作人员或者中小企业的工作人员每天的工作中存在大量重复性的劳动,如制作更新报表,形成文字报告,复印信息,或者把纸质文件转录成电子信息,把A表格的某信息找出来填入另一份文件中等等工作。如果我们单单把其中一项任务拎出来,也许都能找到相应的软件去解决其中一项问题,如扫描文件,图片转录成文字,网络爬虫或数据库抓取更新信息,办公软件填入信息平台,形成电子文档等功能实际已经成熟,甚至根据风格自动撰写文字,自动总结文章内容,自动翻译,检查文档错误在一些特定功能场景下已经实现,如法律智能助手。但是在许多部门或者中小企业的工作人员离从繁重的重复劳动中解放出来依然遥遥无期,其中部分原因是其所在的单位由于体量等原因无法定制办公软件系统,更重要的其实是每一个个体的劳动虽然重复性大,但是相互间又有一些差异,目前的机器还没能形成“智能”能把一个个已经实现的小任务功能根据人的训练,要求串联起来。这种能把小任务串联起来的逻辑,其实一部分原因是上文所说的机器的语义理解的问题。
  • CALO计划
美国国防部下的国防高级研究计划局(Defense Advanced Research Projects Agency,DARPA)在上世纪资助了很多人工智能项目,其举办的自动驾驶大赛吸引了众多自动驾驶,人工智能与机器人的先驱学者、工程师。但是上世纪还有一个更加不为人知但雄心勃勃的计划,CALO(Cognitive Assistant that Learns and Organizes)计划。这项计划耗资近2.5亿美元,是有史以来最昂贵的人工智能项目之一。CALO项目的研究员希望能打造出一个拥有类似人类能力的软件助手,并且这个软件助手还能从曾打过交道的人身上学习,并对自己的行为进行相应的调整。
虽然这个有巨型团队,但又被DARPA过度控制的项目当年没有给现实世界带来直接影响,但是其负责人Adam Cheyer后来组建了一个公司,叫做Siri。这家公司又和苹果公司Allen Kay的Knowledge Navigator构想相结合,成为了乔布斯带到千万人手中语音助手。
  • 智能助手设想
我们的设想是自然语言理解在未来是否能在特定的场景下(如细分办公场景),通过与PaaS,知识图谱等技术的结合做成一个以语音和文字命令为接口的智能办公助手。刚刚介绍到语音接口的一个优势是一对多的检索,设想一下如果机器能够理解iPhone中每一个app的大致功能并通过人的要求自动匹配打开该功能模块,这个效率就比在iphone上的app store里寻找相应功能的软件,在打开那一个小方格以启动其背后代表的功能模块要快很多。通过简短的一个对话框(如Siri)能连接背后上百万个软件包,这也是为什么语音被视为下一代人机交互接口的一个重要特征。通过这样一个连接一定功能模块的助手,人可以通过训练机器把一些重复性的任务串联起来,实际上是让每一个普普通通的工作人员变成了一定程度上的程序员。这其中涉及到什么困难呢?其中之一是这意味着整个生态系统的改变,乔布斯当年把Siri引入iPhone的时候,实际上需要苹果的工程师们在iOS操作系统的底层把所有程序的接口重新改写了,发展到今天的瓶颈其实也是自然语言理解的功能还没那么完善,怎么样在语义层面让机器理解每一个程序的功能,理解人的需求的含义,并且把人的需求分解为不同程序的功能模块,调用模块的功能依然是一个待解决的问题。
至于这个智能助手在智慧城市中发挥了什么样的角色呢?所谓一个城市大脑,或者智慧城市的中枢在辅助城市运行的管理决策的时候,需要从小的功能模块发展成大的复杂模块,但是整一个发展的过程中是需要数据进行训练和支撑的。智能助手其实也是在收集一线工作人员的操作数据,也就是我们在寄宿儿童心理健康问题所提到的把决策的流程通过信息化手段记录下来。

3.2 城市综合治理平台技术实施路径
讨论完整体发展路径后,因为智慧城市各层级应用非常广,这里决定选择智慧城市综合治理平台,这个最为重要的智慧城市应用为例来讨论具体在技术上怎么建设。之所以我认为是最为重要的应用是因为其在信息层面是涵盖信息范围最广的,各个垂直行业的应用可以根据功能模块定制相对应的平台,比如交通领域的阿里城市大脑是在综合平台架构下的一个领域的分支。
智慧城市的实施路径第一步 – 打通政府间”数据孤岛”
要决策的流程通过信息化手段记录下来,或者说城市信息融合的核心是以城市业务需求为导向的。促进整合各部门信息资源,只有以业务需求为导向才能深入痛点问题促进体系的改变,对城市的整体需求进行对城市全面的资源整合和共享。
信息资源与共享方法框架————参考自《智慧城市–顶层设计与实践》
智慧城市由下到上的架构为:
感知层-平台层-应用层-业务层
智慧城市信息融合包含了连通数据的感知层(基础设施层,IaaS),处理数据的平台层(数据融合层)和建立在平台之上的应用层(应用平台),以业务需求为导向的业务层(业务架构)。
3.2.1 感知层 Iaas
感知层 IaaS – 该层解决的是人类世界和物理世界的数据获取问题
通过传感器,探头,摄像头等采集外部数据,通过RFID,条码,工业现场总线,蓝牙,红外等短距离传输技术传递数据。
通过贯通把电信、电视、互联网网络架构体系把数据传输到云计算数据中心
通过政府系统,媒体,企业等渠道收集人工汇总,内部数据等信息,数据输入平台
3.2.1.1五类信息数据
感知层收集的数据包括五类:
1.人口信息,以自然人为主线,包括公安人口信息、计生、劳动和社会保障、民政、残联、教育、税务、统计等部门
2.地理空间信息,以城市管理为主线,包括规划、国土、建委、公安、市容、安监、环保、以及社会的空间地理信息
3.法人信息以法人为主线,整合国税、地税、工商、质监、人事、财政、人行、公安、外汇管理、统计、交通、海关等部门的信息,实现以税源监控为目的的企业基础信息资料库
4.宏观经济资源库以宏观经济指标为主线,包括工业增加值增长速度、工业主要产品产量及增长速度、客货运运输量、固定资产投资情况、城镇投资情况、社会消费品零售总额、居民消费价格指数、消费者信心指数等
5.基础设施资料包括路网资源、市政设施、学校等公共服务资源
3.2.2 平台层 Paas
平台层 -信息资源共享的核心层 PaaS
定义指标度量体系、关联关系、数据标准
对数据进行清洗、整合形成统一标准数据库供应用
3.2.2 应用层 Saas
作为城市的大脑,集合了感知,平台及应用三种层级的平台可以根据业务需求定制不同的应用功能。从老百姓的角度出发,建立城市综合运行管理平台只是城市功能的一部分,但是对于旨在提供良好生活体验的智慧城市来说,综合运行管理平台是一个较为重要的中枢。其能高水平的整合城市的各个系统、各项资源,可以准确搜集、分析、处理城市服务的各项信息,打破信息孤岛,行业孤岛式的运营。对一些紧急事件实现及时监控,快速响应。还可以被扩展,根据业务需求被整合成具体部门的应用。
智慧城市综合管理平台结构示例————参考自《智慧城市–顶层设计与实践》
正如前文所述,智慧城市的应用除了综合运行管理中心之外,也包括信息资源中心,数据交换中心等其他功能,城市综合治理平台是智慧城市的核心设施,但远远不是全部。
以上智慧城市实施路径部分主要参考自《智慧城市——顶层设计与实践》,其中包含江苏省邮电规划设计院对智慧城市的探索,并对该书作者表示感谢。

3.2.3 智慧城市现有应用案例
3.2.3.1 交通领域
下面我们用一些具体案例或者设想来探讨一下城市大脑,或者智慧城市综合运行管理平台目前或者将来能发挥什么价值。
智慧城市在交通领域的应用
  • 阿里巴巴城市大脑
阿里巴巴城市大脑自2016年宣布以来,2017年10月11日正式在杭州萧山区上线,让萧山区信号灯自动配时路段的平均道路通行速度提升15%;平均通行时间缩短3分钟;应急车辆到达时间节省50%,救援时间缩短7分钟以上。在苏州实现试点线路公交出行人数增长17%。
  • 城市规划
八十年代上海市政府解决上海交通问题核心是修跨江隧道,跨江大桥,当时要解决的根本性问题是基础设施结构性问题。时过境迁,空间规划逐渐成为更为严重的问题。
通过大数据关联分析发现,在我国有些城市因经济发展规划和居住区规划不协调,经济重心与人口重心偏移并扩大,跨区式的出勤需求是造成交通拥堵压力剧增的重要原因。“如果是这个原因,大力发展公共交通已不是有效解决城市拥堵问题的首要手段。” “我们的分析结果目前已经得到这些城市的重视,开始着手解决这个问题。”
——摘录自《智慧城市的建设实践——大数据互联网下的行业切入与发展机会》
注:城市规划作为一项不确定性较大,面对时间跨度较长的任务,智能技术能够辅助人类决策的部分仍然有限,“有些时候还不一定有领导拍脑袋来的准”,所以如整个智慧城市通用系统一样,是一个需要慢慢积累的长期工程。

3.3 智慧城市融资及运营模式
3.3.1运营模式
智慧城市项目因为承载了城市的部分业务功能,使得项目本身具备了公共服务属性,因此注定了在项目的融资及运营架构的设置上从普通项目不同,需要仔细考量。目前智慧城市的运营模式主要有:
1. 政府独营模式:完全由政府进行投资建设运营。主要适合涉及公共安全、行政管理等领域,涉及部分较多且后期无法带来商业价值的项目,资金完全来自于政府信息化预算及专项资金
2.PPP(Public-Private-Partnership)模式,政府与企业进行合作,共同开发投资建设,并运营。这种模式可以较好地缓解财政资金压力,并优化资源配置,通过理清政府”监督者”和”提供者”之间的角色,提升公共服务质量。就具体操作方式上分:
  • BOT(Build-Operate-Transfer)模式即”建设-经营-转让”模式。特许期内将智慧城市工程建设特许权授予承包企业,负责设计、融资、建设和运营,并回收成本赚取利润,特许期后将所有权移交给政府。以BOT为例,流程简要来说为:中标后,政府制定投资主体与社会资本共同出资组建特殊目的项目公司(Special Purpose Vehicle,SPV);项目公司经政府授权负责投融资、建设和运营、面向政府、民众、和企业提供公共服务。运营期满,将经营权,所有权移交给政府资产管理机构。
智慧城市建设项目PPP模式操作方式案例——参考自《新型智慧城市发展报告2017》
  • 此外,还有建设-拥有-运营-移交(Build-Own-Operate-Transfer,BOOT),建设-拥有-运营(Build-Own-Operate, BOO),委托运营(Operations & Maintenance,O&M),建设-移交(Build-Transfer,BT),管理合同(Managing Contractor,MC),转让-运营-移交(Transfer-Operate-Transfer,TOT),改建-运营-移交(Reconstitution-Operate-Transfer,ROT)等。
3.3.2 国内智慧城市建设典型PPP模式对比
国内智慧城市建设典型PPP模式对比——参考自《新型智慧城市发展报告2017》
3.3.3 存在的一些问题
尽管PPP模式被认为是目前最适合智慧城市建设的模式,但是因为发展程度的原因仍存在一些问题。构建智慧城市的一个目的就是通过改善信息不对称的情况,合理配置城市资源,这与PPP模式设计的出发点是一样的,即公共部门和民营部门存在一个共同的目标:在某个项目上,以最少的资源,实现最多最好的产品或服务的供给。私营部门通过此目标实现对自身利益的追求,公共部门则以此实现对公共福利和利益的追求。因为PPP项目是带有公益性的项目,因此需要控制私营部门在执行过程中形成超额利益。另外还需要合理共同分担风险,主要是体现在各自优势方面的伴生风险,公共部门体现为为私营部门的基本预期收益提供引导补贴。私营部门则在具体管理责任上承担较多,以规避政府”官僚主义低效风险”等。
另外,从目前PPP项目建设项目经验看,一些地方政府为了吸引社会资本,多上项目,通过BT、政府回购、承诺固定投资回报等明股实债方式,带来政府隐形债务风险在,短期债务长期化风险。部分参与PPP项目企业,不愿意以承担运营风险,期望通过施工获取利润,违背了政府推广PPP初衷。鉴于此,建设移交(Build-Transfer,BT)模式不被纳入我国PPP范围。
目前财政部开展的748个PPP示范项目中,仅有10余个直接与智慧城市和信息化有关,可供参考成功案例仍然缺乏,为形成量化考核指标带来困难。
以上章节参考自《新型智慧城市发展报告2017》及《智慧城市——顶层设计与实践》

4. 智慧城市建设过程中一些思考
在前三部分分别对智慧城市的出发点(为什么?Why),定义(是什么?What)和建设路径(怎么做?How)进行了铺垫后,我们在这一部分重点谈一下对未来建设智慧城市的一些思考,及一些较为重要的应用设想。
4.1 智慧城市能为经济改革做什么?
智慧城市在经济发展中问题的应用设想(脑洞系列)
构建信息平台,整合数据资源只是第一步。整合完后还可以根据数据对将要实施的政策进行模拟,预测政策会影响的范围和效果。比如最近推行的资管新规马上导致了包括盾安集团等一系列企业出现资金链断裂的问题,通过打通政府各部门之间的数据,我们设想的智慧城市将可以辅助决策者在决策前预测政策可能带来的影响,比如通过把银行数据库,税务数据库,及法人数据库等信息共享,可以画出一个企业,银行间的资金脉络表,也就是所谓的穿透式监管,能较大程度的控制政策影响的范围和程度。
中国经济改革其中最重要的一个问题就是理顺扭曲的资金供应结构,扭转大型国有银行只能贷款给国有企业,民营企业、中小企业通过资本市场等直接融资渠道并不能筹措到足够的资金,只能寻求诸如信托等非正规渠道,国有企业持有大量资金但苦于无法找到高回报的投资渠道,反而把钱贷给中介机构,实质导致国有企业实际在做银行业务,致使影子银行迅速扩大。特别是08年金融危机以来宽松的货币政策,信贷规模迅速扩大,大笔钱流入国有企业,又致使一大批盈利能力并不一定强的项目上马。我国总体负债跟GDP比例已经超过200%,其中企业负债占大比重,影子银行跟GDP比例达95%。政 府为了防止系统性金融风险,其中很重要的一步就是去杠杆,肯定会采取市场政策,出清一部分债务负担超过企业承受能力的竞争力不强的企业,让该破产的企业遵循市场规律破产,该倒闭的倒闭一批,政 府也不可能给所有企业兜底。这其中很重要的一部就是理清楚哪些金融机构是系统性重要的,梳理各金融机构资金,看清楚哪些金融机构是牵一发而动全身的,哪些则是需要投资者和发债人一起承担损失的,非系统性重要金融机构应该允许破产,政 府也不应该给这些机构兜底。
在确定系统性重要金融机构这个重要一步中,建立信息共享融合的机制,就可以按照前面提到的建立智慧城市感知层,通过连接法人数据库,宏观经济数据库,自然人数据库,建立金融业的准确及时的信息系统,辅助监管层决策。
中国在实施大型的政府行动(如反腐,去杠杆)时讲究谋定而后动,前期需要搜集大量的信息,仔细斟酌研究利弊,然后有步骤的进行。比如老 wang推行的巡 视制度,巡 视的顺序先去哪,后去哪,其实需要极高的政 治智慧,需要对整体形势有非常深刻地把握,然后反复权衡,预测,反馈,决策,这种层级的智能也许在非常长的时期内机器都难以达到,或者说也许某种程度上就达不到。
但是从另一个角度看,这跟围棋中“势”类似,在Alpha Go出来之前人们也以为机器做不到,虽然后来机器远超人们的预期,但其中围棋的行动选择(361个落子点)比起真实世界来说确实小巫见大巫。我们也许从Alpha Go设计的思路上学习一些能被用到智慧城市上的方法。Alpha Go 结合了深度神经网络,增强学习,蒙特卡洛树搜索以及后续的对抗学习算法,其本质是在与人类棋谱以及自我对弈的过程中不断积累经验提升自己。在智慧城市的建设中,我们如何构建安全的系统,以及如何不断从自己过去收集的操作经验,和群体智慧中反思提升治理水平。
就如我们建立的一个个独立的办公软件一样,数据库里的数据是独立的。如何从资料库之间,建立网络化的信息处理模式。能把不同资料库之间的数据链接起来其实就是我们人类的智慧。或者说能从过往的经历中积累下经验,见微知著,了解能从纷繁的信息中抽丝剥茧寻找出未来要找的路,这就是对政府体制的深入把握。

4.2 负反馈机制建立
信访案例反馈与负反馈机制 (脑洞系列)
下面从一个信访案例探讨智慧城市解决信息不对称中的应用以及对建立负反馈机制的一些想法。
一家国有企业中心与员工家属近期发生一起纠纷,事情的经过是老员工过世后,他的几位子女来企业取丧葬费用,但因为其中一位子女与老员工断绝了子女关系,另几位子女无法获得其身份证件。而企业员工觉得按照规定无法在未获得所有子女证件的前提下给另外几位子女发放丧葬费用,顾虑在于如果后续另外一个断绝关系的子女要是来找企业的话很难给一个说法把所有丧葬费用都给了前几位子女。这件事情因而闹到了国家信访局,再一层一层下发批示处理。子女们看来企业员工为了免责,怕惹事上身,企业员工觉得自己按规定办事。双方都没有明显的过错,问题出在规定的灵活性及制定规定时没有思考周全上。这本身也是可以理解的问题,毕竟社会各种情况复杂,不一定能十全十美。但制定时没有思考周全,出现问题也未能及时纠正,就拖成了问题。
这个问题实际上反映了一类社会问题的缩影,一方面体现为公务员能不能设身处地的为老百姓思考,背后深层次的问题是规定的漏洞如何能得到及时的弥补,以及制定规定是能否得到更多的决策。
通过智慧城市的手段,建立及时的信息平台,预定老百姓反馈意见的通道,及时的履责监督系统,就像互联网公司一样,之前系统里出现了一个bug,马上系统指定专人处理,并跟踪处理结果,用户可以对处理结果进行反馈。
更深一层想,通过自然语言理解技术的发展,对信访案例进行归档建模,对每次案件进行自动整理及逻辑归纳。如果能让机器理解了这其中的矛盾点和需求差异,并因此得以预测某一政策对该案件中老百姓的态度改变,那么对于政策制定者来说就可以在制定之初对新政策产生的影响进行一个预测。
简单的想法可能是从新政策引起的该分类下上访案件上升数量预测来评估新政效果,如果推行新政策,预测上访人数减少了,那么也许就是值得推行的。未来可能发展成机器自动分析并生成规定建议修改文本,使得矛盾得以更及时的解决。

4.3 新的融资机制和组织架构
上文谈到PPP模式是目前状态下智慧城市建设最为理想的组织模式。智慧城市的项目因为面向的是公众,在组织形式上存在一个为谁负责?被谁监督的问题。如果采用现有的PPP模式还是存在一个设计SPV公司的问题,既然是一个公司就存在董事会的问题。
以董事会为中心的公司最初在欧洲形成,其早期是以东印度公司为代表一批具有社会经济职能的组织,其治理方式形式上一定程度可以说是代议制由”公”到”私”的延伸。现代董事会制度主要有三个基本原则:1.董事会是公司权力的最高行使者(director primacy); 2.董事会采用一人一票平等的并且集体合议方式行事; 3.董事会对公司制度的有效和正当运作负有最后责任。
董事会制度明确对股东大会和董事会的权利和职责,由股东大会选举董事会,由董事会指派总经理并对其监督。总经理向董事会负责,董事会向全体股东负责。由于种种原因,中国企业在董事会模式运行一直差强人意。
但是问题的根本在于?董事会制度真的适合智慧城市项目吗?我们讨论了智慧城市的建设出发点应该是市民的城市生活体验,但是股东大会的主体需求跟市民的是否能保持一致呢?换句话说,全体股东大会能不能代表市民的长远需求,董事会会不会为城市体验负责?
举一个简单但不一定恰当的例子,报道上经常出现学生家长自愿为孩子学校宿舍出钱装空调,但不被学校批准的例子。给孩子宿舍装空调(市民长远需求)被学生家长群体提出(市民组织),但是被学校拒绝。虽然具体的实际情况因情况而异,也许学校有别的方面的考量,但是总体来讲,我们希望学校是能够为了学生的利益负责的。当学生所在的组织没有办法及时的解决其需求时,是不是有另外一套组织形式更符合要求呢?
自亚当·斯密时代以来,董事会由于始终不能完全保护股东财产而一直遭到质疑,包括美国法学院(1982)、Lorsch和Lipton(1992)、Jensen(1993)在内的很多人曾都针对董事会的改革提出了各种不同的建议。尽管存在诸多不足之处,但董事会始终被人们认为是解决困扰所有大型组织的代理难题的次优办法(当然不是最优办法,否则就不会面临如此多的质疑),目前还尚未找到可以代替它的其他有效制度。
——参考自《董事会制度》
我们不由思考区块链或别的新兴技术能否给如智慧城市项目这种以公益性质为主的实体带来新型的组织架构呢?比如市民如果觉得某些项目是值得做的,而政府又在财政上有困难的,有没有更直接的组织形式能让市民们为了其生活体验更直接的参与到智慧城市项目的建设中去呢?公司制度下的组织架构已经存在几百年了,新的模式在智慧城市范畴下是否必要?

5. 总结
本文从WHY-WHAT-HOW的思路上介绍了一下智慧城市建设的一些思考,为什么需要智慧城市?因为我们看到智能化技术给我们提供了一种新的思维方式,让我们更加接近了一种能系统化记录、分析、优化我们的思考的模式。智慧城市系统是什么?本文做出了一个抛砖引玉的定义:一个全面,精准,实时的把老百姓需求与城市管理决策对接在一起的决策辅助系统。至于怎么建设智慧城市?我们提到第一步就是把决策的信息流通过新兴的技术电子化,按照感知层-平台层-应用层的架构搭建智慧城市综合管理平台,其他领域可以挑选模块定制系统。在操作路径上则有自上而下,自中间往下,和自下而上三种相辅相成的方式。最后我们提出也许是本文最有价值的一些应用思考,文章以增值税开始,以经济改革结束,也是因为在这个政府决策中举足轻重的领域,我们看到了智慧城市未来广大的发展空间。路还很长,需要仰望星空,脚踏实地。基辛格博士在《世界秩序》一书中曾提到,18世纪出席维也纳会议旨在重构一站后世界秩序的外交官们因为距离本国往往有较长的通讯距离,得到的指示都是笼统,模糊,主要靠临场应对。21世纪外交官们可实时与首都保持联系。实时通讯技术的发展,给当代外交模式带来了本质上的变化,进而也影响到了世界秩序的发展进程。智慧城市相关的云计算,人工智能,大数据,量子计算等技术的发展会给城市运行模式将带来什么影响?让我们拭目以待。

附录
附录1 智慧城市部分技术应用及前沿
基于目前的技术水平,智慧城市在整个管理流程中短期内能够提升的步骤是感知(1)和反馈(6),其中主要涉及的技术有物联网、云计算、人工智能中自然语言处理(Nautral Language Processing,NLP)和计算机视觉(Computer Vision,CV)
中长期内可以取得突破的应该是预测延展(3)及优化(7),其中主要技术包括但不限于自然语言处理,知识图谱等等。目前的自然语言处理技术对以文字语义及逻辑上的理解(semantic understanding)或者说是机器认知能力还有待突破,没有语义的理解,无论是信息的收集,还是构建数理模型都造成了信息的流失。
短期,中长期可能用到的智慧城市部分技术介绍:
1.互联网
2.物联网 (Internet of Things, IoT): 在感知层收集基础设施,设备等数据
主要技术
RFID(射频识别)应用如一卡通
NB-IoT(Narrow Band Internet of Things) 二维码 应用如共享单车
传统传感器:摄像头,红外,GPS
3.云计算
服务类型分:基础设施即服务(Infrastructure as a Service, IaaS) :服务器,存储设备打包成服务给用户 应用如云盘,AWS
平台即服务(Platform as a Service, PaaS):提供应用软件开发, 测试,运行环境,适合小企业开发自己的软件 应用如微信小程序,Google App Engine
软件即服务(Software as a Service, SaaS):提供用户所需的软件,软件部署在云服务器上,中小企业不需要雇佣IT人员进行运行维护
4.人工智能分支之下深度学习
自然语言处理:
信号处理,语音识别,语音合成等已经有一定解决方案,目前瓶颈主要在自然语言理解(Natural Language Understanding,NLU),近期能否突破在于以深度学习为推动路径的数据训练模式是否能够走得通?业界有认为需要新的理论思维方式,如符号学派方法与深度学习结合的方式,也有把自然语言抽取并投影到语义空间的尝试,未来方向会向多模态合并(语音,视觉等)发展
自然语言投影到语义空间的尝试-京东研究院何晓东博士
如图:
1.”小明快递了一袋苹果给外公”
2.”外公从小明那收到了袋红富士”
3.”小明快递了一个苹果X”
第一句话和第二句话虽然文字上迥然不同,但是我们能理解是近似的意思,第三句话虽然文字上跟第一句话很像,但是在语义空间上是跟第一句话相隔很远的。
重要模块:语音识别(Automatic Speech Recognition,ASR),语言理解(NLU),对话管理(Dialogue Management,DM),语音合成(Text to Speech,TTS)
在物联网浪潮中有成为重要人机接口的潜力,适合一对多类型搜索,例子在手机中通过语音说一个应用功能以取代以视觉在众多图像icon中寻找功能,应用如智能助手
按人机对话对话类型分:
1.任务型 带有明确目的,以完成任务为目标,Ontology 驱动任务型对话系统,应用如买机票
2.问答型 配合知识图谱完成知识问答
3.聊天型
4.搜索型
计算机视觉:
应用有人脸识别(正面),物体识别(多角度,被遮挡情况下识别),深度检测
目前发展方向往视频中的识别处理,及图片的语义理解方向发展,如看图自动形成简短文字描述内容。另外还有时空特征识别,做深层次的空间,人,车,物关联分析。

附录2 “政务型产品经理”是什么?
政务产品经理培养来源、能力模块探讨 (脑洞系列)
来源
1.国家信息中心,新型智慧城市建设部际协调工作组等智慧城市规划部门干部,对智慧城市发展路径,国家政策,撬动体制内能力强,对政府运行模式及弊端了解较深,良好的大局观但能否有较为灵活的思维适应快速变化的环境?
2.大型互联网,AI公司产品经理团队与政府团队对接,如腾讯智慧广东,阿里城市大脑等团队项目产品经理,这个团队有产品方法论,但对政务实际运作业务了解有限。
3.地方团队,公安,税务等各行业体制内公务员。与1类似,对全国发展现状不如1,但对地方情况更为了解,是运营团队的理想人选。如江苏省邮电规划设计院,贵州省大数据发展管理局
4.其他行业,如NGO团队
模块
1. 以人为本的初心
2. 政情把握
3.发展成熟商业模式能力
4.与技术团队沟通落地能力
5.抽象能力,分隔各模块功能及其间联系功能及其他产品经理基本功

参考
1.《新型智慧城市发展报告 2017》
2.《农村寄宿制小学:代理家长在哪里》
3.《我国智慧城市健康发展面临的挑战》
4.《智慧城市——顶层设计与实践》
5.《智慧城市的建设实践——大数据互联网下的行业切入与发展机会》
6.《与机器人共舞》
8.《智慧城市——大数据、互联网时代的城市治理》
以上内容,来自饭团“AI产品经理大本营”,点击这里可关注:http://fantuan.guokr.net/groups/219/ (如果遇到支付问题,请先关注饭团的官方微信服务号“fantuan-app”)
———————
作者:黄钊hanniman,图灵机器人-人才战略官,前腾讯产品经理,6年AI实战经验,9年互联网背景,微信公众号/知乎/在行ID“hanniman”,饭团“AI产品经理大本营”,分享人工智能相关原创干货,200页PPT《人工智能产品经理的新起点》被业内广泛好评,下载量1万+。

—— 全文大概5400字,读完共需9分钟 ——
一、序言
随着人工智能技术的发展,近半年来涌现了大量基于人工智能的呼叫中心业务服务商和集成商。仅电销机器人这一个方向就至少有近百家公司正在推广运营,包括百度、讯飞、智齿、硅基、百应、箭鱼、容联等。商务上的需求非常强烈,整个市场都飞快地热闹起来。
一套可提供saas服务的智能外呼系统,看起来功能并不复杂。一个网站可注册、充值缴费开票,登录后在后台页面选择或者定制外呼话术脚本,新建外呼任务并导入外呼号码列表,明确外呼策略(时间段、重呼次数),设置外呼机器人数量(同时拨出几个号码),点击开始。然后就可以看着进度条走完,外呼机器人按照列表一个个打电话出去。任务完成后,可以查看外呼结果列表。
那么如何从零开始搭建一套对外可以提供saas服务的智能外呼系统呢?
二、总览
我们先列出,搭建这样一整套系统需要哪些技术和资源:
1、运营商线路。提供方包括三大运营商、集成线路商。这是我们打电话出去要交电话费,必须涉及的供应商。
2、呼叫中心设备。商用设备原厂包括avaya、genesys、cisco、华为等。集成商很多。开源的也有一些。在发起外呼任务时,saas平台是把外呼请求发给了呼叫中心设备经由运营商线路而拨出去的。
3、AI能力。包含语音识别、语音合成、语义理解。这就是外呼机器人的核心组成部分,它能听懂接电话的人所说的话、表达的意思,并回复和引导对话。
4、saas服务平台。即用户可以注册、登录、缴费、上传呼叫列表、发起外呼任务、外呼结果查看的网站。这个是终端用户唯一可以看得到的前端界面。
简单关系示意图如下:
上图中四个主要模块,其中一些难以自研,只能选择供应商:
  • AI能力部分(中文ASR/TTS)基本已经格局稳定,没太多可挑选的。
  • 运营商资源这块儿,可以选择大牌老厂的码号线路资源多的然后便宜的去谈合作,一方面外呼应用在催收场景时容易被封号,同时话费再便宜也好几分钱一分钟,也是重要的成本。
  • 呼叫中心设备,因为涉及不少接口对接调试,优先选自己熟悉的,其次选便宜的且技术资料多的。
  • 最后是外呼saas平台,可能这是各个电销机器人服务商/集成商最容易实现自研的部分。。
明确了涉及到的技术和资源之后,再明确一下建设步骤。由于各个厂商都有各自的资源和能力,建设方式也各不相同,简单来说可以分成以下几类:
1、有运营商资源的,等着别人找上门来就行了。
2、呼叫中心厂商,必然有已长期合作的运营商线路资源,手里也有呼叫中心设备+职场,也有技术人员。于是就选择自研saas平台,然后找AI能力厂商合作提供ASR/TTS/NLU。
3、AI能力厂商,尤其以NLU起家的在线客服类厂商,通常会选择接入百度/讯飞的语音能力,然后去找呼叫中心类厂商合作。
4、啥都没有,只有几个技术人员的,选择自研saas平台,接入呼叫中心设备、AI能力、运营商资源。
作为初学者,为了自行从零开始搭建一套对外可以提供saas服务的智能外呼系统,身份必然是第四种,啥都没有,啥都要干。
以上这四部分,核心角色是呼叫中心。AI只是插上了想象力的翅膀,但是没这翅膀,呼叫中心还是呼叫中心,但是AI就只是空中楼阁了。业务明确可落地的呼叫中心才是想象力的基石。这一点与CV和安防的关系很像。
三、呼叫中心搭建
3.1 通信原理
目前对呼叫中心比较普遍接受的定义是:呼叫中心是以计算机电话集成(CTI)技术系统为基础,将计算机的信息处理功能、数字程控交换机的电话接入和智能分配、自动语音处理技术、 Internet技术、网络通信技术、商业智能技术与业务系统紧密结合在一起,将公司的通信系统、计算机处理系统、人工业务代表、信息等资源整合成统一、高效的服务工作平台 。
最新一代呼叫中心架构NGCC(Next Generation Call Center)如下图所示:
具体如何理解呢?
先从最简单的说起:个人A给个人B打了个电话。
流程:A→PSTN→B
解释:
PSTN是Public Switched Telephone Network,公共交换电话网络,也就是运营商的电话网络。
然后来个复杂点的:个人A给呼叫中心400xxxxxxxx打了个电话,拨通后先听到了录音,“您好,找B类接线员说话请按0号键”。按了0,然后听到录音,“排队中,请稍后”。几分钟后接通,B0026号接线员接了电话。
流程:A→PSTN→PBX→IVR→ACD→B
解释:
PBX是Private Branch Exchange,用户级交换机,这是企业内部的局端用户级交换机,整个呼叫中心的出入口设备。
PSTN到PBX之间是中继(分成模拟中继、数字中继、IP中继),这是将通讯公司的局端交换机与企业内部的用户级交换机(PBX)相连的通讯线路。
IVR是Interactive Voice Response,互动/交互式语音应答,我们把它叫语音导航。实现的是类似拨打10086后听到录音说,xx业务请按x,这个环节。主要用途是根据业务分流来电,进入对应的排队机。
ACD是Automatic Call Distribution,自动电话分配,也叫排队机。
再来个复杂点的:个人A给呼叫中心400xxxxxxxx打了个电话,拨通后先听到了录音,“您好,您想找哪类接线员?”个人A说,“B~~”。然后很快接通,“您好,这是B0026号机器人,有什么可以帮您?”个人A说,“我不想跟机器人说话,泥奏凯~”然后听到录音,“为您转接很贵的真人客服,排队中,请稍后”。几分钟后接通,B1026号真人接线员接了电话。
流程:A→PSTN→PBX→IVR(→ASR→NLU)→ACD(→ASR→NLU→DM→NLG→TTS)→ACD→B
解释:
现在智能的部分,也就是我们说的语音机器人的部分,分别在IVR和虚拟坐席处体现。
IVR部分,不再需要提示按键,而是直接问来电方需要办理什么业务,然后识别语音、理解意图后,进入对应的业务队列排队。
排队后可以等待真人客服接待,也可以由机器人先行接待。
机器人(实际是服务器资源)资源空闲时,直接接待,进行语音对话,对话过程就是语音识别、语义理解、语音合成的多次调用,部分业务涉及业务数据接口对接调用,比如查询话费、积分。
并可以根据需求自动或者选择转人工,再次进入排队,等候真人客服接待。
其中IVR部分示意图如下:
3.2 集成实施
上面提到的全部流程中,PBX、IVR、ACD等部分基本都是由我们说的呼叫中心设备商提供,产品有三种类型:板卡式、交换机式、VoIP形式。
交换机式比较适合大型职场,例如三五百人以上,硬件价格五位数。交换机领域,主要有:avaya、genesys、cisco、华为、中兴。其中最常用的两家对比下来,avaya比genesys便宜
板卡式适合中小型职场,比如几十人到两三百人,硬件价格四位数。基于板卡建设呼叫中心的步骤,可以参考使用三汇板卡的这几篇(主要前4篇讲原理)。
选择板卡之前,先要确定选用哪种中继线路。比如使用常规的数字中继,那么就需要选择数字板卡。这个找板卡的供应商问就行了。通常来说呼叫中心要购买的一条E1数字中继报价五位数/年,由用户级交换机将局端的光信号转换为30路模拟信号,也就是支持30个人同时接打电话。通话费会另外按照实际呼出分钟数收取。
近期一个实际落地项目是选择了数字中继+Asterisk(开源VoIP PBX纯软方案)。(可参考:安装配置https://blog.csdn.net/u010148712/article/details/53241700,调试https://blog.csdn.net/u010148712/article/details/53244000)示意图如下:
具体的软件业务细节,比如常规客服中心需要的管理模块、配置模块、工单服务、坐席服务、报表模块、CRM,还有比如坐席班长监听、通话插入、质检,录音文件管理等整套软件细节,不做详述。
四、AI能力对接
在具体落地中,这个领域的常规参与者通常具备呼叫中心能力或者AI能力其中一种,而主要的对接点也就在于AI能力与呼叫中心设备去对接,而ASR/TTS与呼叫中心设备对接的常规协议主要是mrcp/sip。
媒体资源控制协议(Media Resource Control Protocol, MRCP)是一种通讯协议,用于语音服务器向客户端提供各种语音服务(如语音识别和语音合成)。有两个版本的MRCP协议,版本2使用SIP作为控制协议,版本1使用RTSP。
实际对接的时候,会遇到不少技术问题,有的呼叫中心厂商会要求ASR/TTS引擎做私有云部署,这样避免了内外网穿透时防火墙的诸多设置和语音流的时延。这对基于语义起家(并购买语音能力)的公司是一个小小的难题。
4.1 语音识别
现有技术中实现一次性语音识别典型的流程时序,具体包括一下步骤:
■ MRCP Client发送INVITE消息给MRCP Server请求建立会话,携带MRCP Client侧的SDP;
■ MRCP Server回复200表示请求已经成功接受处理,携带MRCP Server侧的SDP;
■ MRCP Client随后发送ACK消息证实200消息已经收到,至此一个SIP会话成功建立;
■ MRCP Client发送RECOGNIZE消息给MRCP Server请求语音识别,按照MRCP协议规定的格式携带相关的语音识别控制参数,并且指定语法文件路径;
■ MRCP Server接收RECOGNIZE请求,编译语法文件,回复200消息给MRCP Client;
■ MRCP Client此时开始根据之前协商好的SDP,开始源源不断的发送RTP语音流给MRCP Server;
■ MRCP Server接收RTP语音流,当检测到用户开始说话时,发送START-OF-INPUT事件;
■ 当MRCP Server根据语法文件定义得到识别结果时,通过RECOGNITION-COMPLETE事件返回识别结果;
■ MRCP Client发送BYE消息给MRCP Server结束会话;
■ MRCP Server发送200消息给MRCP Client确认结束;
■ MRCP Client通过上述流程获得MRCP Server提供的一次完整语音识别能力。
电话渠道的语音流采样率一般是8k 16bit,这种语音识别的准确率远远低于app等渠道采集音频的识别率。再加上人在打电话时说话方式相对随意,导致语音识别部分成为了影响电话机器人能力和效果的重要瓶颈。
4.2 语音合成
实现语音合成典型的流程时序,具体包括一下部分:
■ SPEAK:向服务器端提供文本,启动语音合成(c→s)
■ STOP:如果服务器正在语音合成资源,则停止语音合成与语音流(c→s)
■ PAUSE:通知服务器资源暂停语音合成与语音流(c→s)。
■ RESUME:通知暂停的语音合成资源继续进行语音合成与语音流(c→s)
■ CONTROL:更改语音合成资源相关参数,从而影响合成的语音流(c→s)。
■ SPEAK-COMPLETE: SPEAK请求已经成功处理(s→c)。
■ SPEECH-MARKER:服务器正在处理语音标签时,遇到请求消息头字段 Speech Marker中标记的tag(s→c)。
■ BARGE-IN-OCCURRED:客户端检测到barg-in-able事件或DTMF数字时,发送该消息通知服务器(c→s)。
现在主流厂商为了使通话效果尽可能模拟真人外呼,除了涉及业务接口调用的数据查询使用了TTS,基本采取整句录音的方式。
4.3 NLU部分
准确来说,一个简单的对话机器人系统框图,包括语音识别(ASR)、语音合成(TTS)、自然语言理解(NLU)、对话管理(DM)、自然语言生成(NLG)几个模块组成。而这一部分就是智能外呼系统的主流玩家——NLU类(智能客服)厂商的强项了。
对于呼叫中心从业者来说,ASR/TTS/NLU如同黑盒一般,只暴露出接口。而国内语音能力的供应商,要么很土豪,少量QPS不要钱,要么就是非常标准的报价五位数一条线路/年,实在也没有太多可以选择的余地。
对于只有NLU能力的厂商来说局面也是一样,除了需要接入ASR/TTS的能力,还需要去寻找可以合作的呼叫中心,并且想办法拿到尽可能低的话费报价。
五、行业现状
经过一些调研和竞品分析,行业内虽然有至少近百家公司在推广和运营电销机器人,但毫不客气地说,大部分都不及格。
一星级 ★ :
  • 官网粗制滥造,类似有漂浮闪动flash,反复频繁提示你联系商务。
  • 对各类基础能力只有含糊其辞的描述,没有录音、演示、试用途径。
二星级 ★★ :
  • 有录音可以试听。但明显可以听出来,部分是真人直接对话录音,而并非机器人与真人的通话录音。部分若干家公司用于试听播放的录音文件完全一致,不知道谁抄谁的。
三星级 ★★★ :
  • 有录音可以试听,甚至也有演示视频。录音可能仍有作假嫌疑,演示视频部分能感觉出来是按照特定的对话脚本去走流程,但是可以完成多轮对话了,语音时延在2s以内,属于基本可用。
  • 不支持NLG,机器人所说的内容均为录音。
四星级 ★★★★ :
  • 支持NLG(Natural Language Generation),支持字段调用,支持TTS合成与录音无缝衔接。但由于TTS调用的是某几个大厂的api,而录音多数为自己根据业务需求去录的,会出现衔接生硬的问题。解决方案是直接全文TTS,或者选择与TTS音色相接近的播音员进行录制。
  • 对打断的处理有待优化。要么不支持打断,要么打断后处理方式粗糙(如重播、多次打断后多次直接播放对应录音)。
  • 语义理解能力相对较弱,但配合相对完善的话术策略,可以保持相对可接受的兜底。
五星级 ★★★★★ :
  • 支持对话中识别关键词打断。如介绍推销信息时被打断问价格,则直接停下并立刻回复价格信息。
  • 报价模式不局限于“线路xxxxx元/年,话费0.xx元/分,话术脚本xxxx/个”的模式。如纯录音外呼机器人0.xx元/分,含NLG的外呼机器人x.xx元/分。
  • 除了根据业务场景定制话术脚本之外,基于已有的积累(如呼叫中心金牌电销的通话记录等)形成特定行业的金牌话术模板,只需要填入特殊字段信息即可使用。
  • 语义层面,支持跨节点/返回节点问答(比如先回答说我不是本人,进入到下一个节点后,客户再说一次我是本人,系统仍能处理)。
  • 外呼结果分析。目前阶段通常机器人外呼只用来做第一轮初筛,需要对通话内容进行语义判断,按需分析是否需要第二轮人工跟进。
  • 通话中转人工。是否允许在机器人外呼过程中被动或主动转人工,这一项在实现时接近于IVR部分机器人应答+转人工的模式,在流程设计和资源配置上相对有难度。
  • 根据通话内容自动判别二次回拨。如被告知“现在没空接电话,10分钟后再给我打”(机器人二次呼叫),或者表示“有兴趣,需转人工跟进”后经由预测式外呼后回拨到用户号码上(真人接线)。
六、商业落地
商务模式比较简单粗暴,粗略的成本核算如下:
  • 首先运营商的通讯资源,几分钱一分钟的话费成本,以及平均下来一千左右一路的中继线路费用。
  • 其次是呼叫中心厂商的服务器、带宽、呼叫中心设备license/运维等成本。
  • 再次是AI能力的使用费,比如讯飞公开报价2w每线路每年。
  • 最后是外呼saas平台的建设和运维成本。
那么电销机器人厂商,竞争这么激烈,谁才会笑到最后呢?
一是要有价格相对低廉的运营商资源和语音能力资源,这样可以明确的报出一个行业内相对较低的价格。比如完全不按照主流友商们1-3w/线/年的报价方式,直接来几毛钱一分钟随便打,随打随充。
二是呼叫中心资源方,最好是带客进场,别从0开始找客户,直接把现有的呼叫中心B端客户转化一部分成为机器人电销客户。
三是语义的能力,尤其是话术模板的设计能力。这一块儿很容易被忽视,但是这反而也是产品经理可以出成绩的地方。一般来说可以拿呼叫中心多年积累的语料去分析一套最佳话术模板(堪比金牌销售的万能对话体系),然后做ABtest也好,从mvp开始逐渐增加主要话术分支也好,心理学基础必须要有,必要时可以从游戏成瘾机制等角度入手,《恋与制作人》的对话技巧学起来,一句话怎么说能让接电话的人最大概率的顺着自己的思路走,达成目的,从而形成特定细分领域机器人话术模板,得到最佳的外呼效果(接通率、通话时长、电销意愿、催收意愿)。这一块儿虽然很细,但是反复迭代之后可以以一敌万,甚至达到现在各类智能音箱背后核心系统一样的地位。
四是外呼saas平台。这部分是web类产品经理的天下了。具体功能点就不详细列举了,友商们的网页和后台过一遍,基本好坏也能判断出来了。至于现在此时此刻被视作亮点的可视化外呼脚本编辑,笔者个人认为其实是鸡肋,普通人根本用不好,脚本逻辑只能做得很简单,多轮对话、跨节点对话效果也不好,反而很容易导致客户放弃。还不如干干脆脆给个可设置变量的场景化标准模板(金牌话术模板由产品经理提供),外呼试用效果好,客户更容易买单。
七、结语与参考资料
这一套智能外呼系统搭下来,不仅仅可以做电销机器人、可以做各类外呼,也可以做IVR语音导航、呼入电话客服。“NLU+CallCenter”就像这几年“CV+安防”的结合一样,也会如商汤科技联合创始人林达华所说,“中间也存在风险:一边是从应用端往前走,一边是从技术端往后走,大家都想占领技术上的制高点。这需要大家建立一种信任和共赢机制,只有这样合作才能长久”。
AI虽然火热受追捧,但具体项目落地并被市场认可和买单并不是那么容易。作为入行并不久的初学者,尝试借以此文抽丝剥茧梳理了从0开始搭建智能外呼系统的全流程,才疏学浅囿于见闻,疏漏和不当之处在所难免,权当抛砖引玉。诸多细节限于主题和篇幅不做详述,如有任何问题,欢迎随时交流。
参考资料:

*Avaya大中华区副总裁、大中华区首席技术官熊谢刚在《客户世界》杂志6月刊发表题为《AI时代客户联络中心的“数商”、“智商”与“情商”》的署名文章。
以算力、算法和数据为框架的新一轮人工智能的触角不断延伸,推动着客户联络中心向智能化升级纵深发展。如何打造“数商”、“智商”与“情商”兼备的AI时代的客户联络中心?智能化基础平台架构的能力建设是立身之本。
运营与管理中的数据智能与业务洞察
AI场景下的客户联络中心,依靠机器智能在一定程度上优化了业务办理的速度和流程,提升了客户体验,但联络中心的运营管理最终的落点在于人,如何抓取和利用呼叫中心中的大数据,发现运营中的问题,支持业务的动态发展,同时,提供给坐席及时恰当的指导和帮助,提升绩效,是极具管理价值的议题。
传统的呼叫中心数据分析,依靠的是相对固化的报表,缺乏交互能力,无法实现实时的业务分析。在实际的业务运营中,状况实时变化,联络中心必须具备较高的“数商”,管理者才能敏锐地捕捉到数据背后的逻辑走向,在短时间内快速完成海量数据的时效性分析,在直观的图形化分析结果中,准确定位问题,推导出潜在的原因以及可能的解决方案。
如何才能让联络中心具备“数商”?底层平台是基础,大数据分析工具的数据建模是核心。
底层平台必须是包容的,从而随业务动态同步发展。通过AI connector智能连接器,不断将日新月异的新技术能力吸纳至底层平台,持续补充渠道交互以及智能的数据获取和分析的能力。比如,把解决数据孤岛的区块链技术作为数据收集和交叉对比的能力支持,将图像以及视频识别技术作为平台内置组件,丰富渠道交互渠道等。同时,设置标准的API接口,为特定的业务形态和项目需求进行定制化建模做铺垫。此外,底层平台的原始数据,包括数据字典,每个数据字段的含义,必须是开放的,方便管理者快速准确地理解模型含义,根据业务需求进行选择性加工和计算。
联络中心的大数据分析工具的数据建模分两个层次。首先,对联络中心全媒体的交互数据,包括语音、微信、视频等,基于交互特征,按照通用的计算维度和指标进行计算,比如,电话渠道上更多分析的是通话时长和平均响应时长的指标,而微信渠道则更多会考虑有效的处理率和用户满意度等。其次,根据具体的业务项目进行定制化的数据建模,以数据组合加工的方式,得出基于业务场景的定制数据分析结果。比如,银行业务较多关注转换率、成单率等指标,把客户联络中心交互的数据与业务成单数据做组合计算,就能得出每百通电话的成单率和交易金额等数据。
当联络中心具备足够高的“数商”之后,许多有价值的针对性思考都可以得到快速验证。比如,全媒体渠道上线之后,对电话量的分流是多少?电话量大的时候,能否让大量的来电消解在多媒体渠道?在来电高峰期,对比分析实时的传统语音与多媒体渠道交互数据,就能直观看出是否多媒体渠道是否具备消解部分高峰来电的能力;在下一代产品推广的节点时,通过数据趋势图,提前预见高峰来电,适时增加坐席人员,并调整语音系统的导航菜单,增加提示音,告知客户可在多媒体渠道获取相关服务。
运用大数据分析工具,基于贴合业务动态发展的深度计算模型,获得针对性强的数据分析、动态验证和逻辑洞察,辅助联络中心的运营与管理决策。
交互与运营中的机器智能与情感计算
计算机图像识别、语音识别、知识图谱与自然语言处理等人工智能技术赋予了联络中心看、听、读、说的能力。随着全媒体渠道的铺设,联络中心与客户的联接不断向多元化的边缘接触点分布,分散化的交互方式给客户旅程管理以及体验提出了新的挑战。如何基于用户画像和市场营销模型实现精准化主动联络,提供跨渠道、跨平台的一致且连续的服务,利用AI智能提升坐席的服务质量和业务绩效,成为了新的研究课题。
一个“智商”过人的联络中心带给客户的体验是什么样?以银行场景为例。
用户在银行官网浏览信用卡分期的信息,联络中心立即识别出该用户在系统中的个人信息,并感知到当前行为,于是在页面让弹出是否需要介绍信用卡分期的窗口。倘若用户点击同意,自动触发云呼叫,AI机器人开始向用户介绍信用卡分期相关的政策,在通话过程中用户做出分期的肯定答复后,AI机器人自动帮用户完成账单业务的办理。如果用户未点击主动弹出的联络窗口,而是在一段时间之后电话联系了银行客服。用户在电话接通之后,听到的不再是标准的IVR导航菜单,而是直接推送给用户特定的信息用分期的语音提示音。
如何才能实现联络中心的赋能?底层平台的智能感知能力是根本。在提供给用户的任意渠道或者接触点,结合底层的用户画像以及营销决策模型设定触发规则,以文本、视频、语音,或者预约坐席进行回呼等多种手段富媒体的手段,为用户提供主动联络和精准营销服务。以理财或者保险产品为例,当用户输入的金额大于企业设定的目标值,会弹出主动联络;指定某一项业务设置人工服务介入,当有空闲坐席时弹出,无空闲坐席则不主动弹出。
当坐席与用户的交互时,AI机器人全程提供“智商”与“情商”兼具的智能化辅助。
首先,辅助座席判断客户的意图,通过实时分析获取的语音流,适时地做知识库的推荐或者知识的推送。比如,客户说出想要查询某款理财产品时,AI机器人可以立即从知识库中搜索到这款产品的介绍推送给坐席,提高了座席的工作效率。
第二,在营销的场景理解客户意图,做话术推荐。比如,客户对某款产品不感兴趣,AI机器人会告诉座席如何继续推荐,起到了一个销售辅助的作用。
第三,辅助进行实时质检。AI机器人可以在通话过程中,辅助进行流程合规性操作,检查座席是否完成了相关流程的命中,包括判断是否涉及违禁语,并在命中时触发后台告警。
第四,侦测判断客户的情绪。把客户的情绪变化直接呈现给座席,提示坐席参考系统给出的指标进行对比,适时调整服务方式。当感知到客户的情绪比较糟糕时,会触发相关提醒,由管理者提前介入。
第五,监测坐席人员的疲劳状态。将疲劳信息提交给运营主管,为排班决策提供有价值的信息参考。
新一代的联络中心,是AI场景下的全联接中心,底层的大数据和AI综合智能支撑起平台上的每一个组件和功能,从而在交互层面,无论是自助还是人工服务,坐席资源的配置与管理,座席的辅助和赋能,整体的运营洞察,赋予客户联络中心以“数商”、“智商”与“情商”。