容联七陌×阳光出行丨打造智能应答与智能辅助的交互“灵动岛”

12月19日，容联云“未来生成式——大模型应用升级新品发布会”在北京举办。发布会上，作为容联七陌标杆客户代表，阳光出行智能服务部负责人王妙心，分享了阳光出行使用大模型等AI技术的经验。

阳光出行智能服务部负责人王妙心

阳光出行与容联云生成式大模型的合作，打造了基于场景串联AI能力的智能辅助和智能应答系统，包括语音、文字交互的形式和类似苹果交互的灵动岛形式，以及智能提醒、智能导航提示等功能。此外，阳光出行还自研了一套AI的决策平台，与容联七陌的多媒体联络中心打通，实现了智能化辅助判责、客诉处理、工单填写等功能。通过技术上的深入合作，阳光出行优化了其服务流程和用户体验，实现了商业价值的提升。

以下为王妙心演讲实录全文：

今天非常荣幸也非常高兴，受邀来到容联云生成式大模型的发布会，跟大家一起分享和交流我们自己在出行行业中做的东西，也希望大家能给更多的意见和建议。

不知道大家有没有听说过阳光出行，因为我们C端的APP，大家正常打车的情况下可能用得比较少，但如果通过滴滴或者高德，或者类似腾讯出行、百度地图上面打车的话，其实大家都坐过阳光的车，只是大家没有仔细地了解过。

我们实际是运力的服务提供商，主要服务对象是司机，我们在北京也是第一家接入到滴滴第三方的运力提供商，所以在AI上的能力和场景落地，主要以司机为主，现在也慢慢与渠道合作，把乘客这一侧的交互和智能化服务做起来。

阳光出行的机器人叫做阳仔，根据阳光的形象打造的，主要是用场景串联AI能力，打造一个落地的产品，这个产品的形态在很多App上面，或者很多服务上面也都见过类似的，产品主要以语音、文字交互的形式，包括现在新做的类似苹果交互的灵动岛形式，来做司机的服务，正常订单完成之后的服务（售后服务），做文字形式和语音形式的交互，实际在司机驾驶的情况下，为了解放司机的双手，更多是以悬浮窗互动的形式跟司机互动。

我们整个智能辅助和智能应答在整个订单服务阶段完成，所有跟智能相关的交互能力，都是依托于容联七陌的服务打造的，我们跟容联七陌的合作也持续了很多年。

阳光出行可能不像银行等大客户，属于是刘院长介绍的腰部客户，但我们更多专注打造小而美的交互形式，这是悬浮窗灵动岛的交互形式，包括在订单导航和服务页面，会有智能提醒、智能导航提示。

正如刚才说到的，整个智能助手在出行服务当中的每一个环节，都会根据司机的状态和订单的状态，去完成整个服务的导航。从司机的出车、等单、接驾途中、服务中到订单完成，出车异常的提醒、偏好的设置、整个听单派单的策略，以及现在的路况、天气、途中以外情况的报备，基本都把定制化的能力加入到机器人的交互当中。

实际上司机在日常的驾驶过程中经常会说接不到单的问题，实际阳光是接入大量C端流量平台，不管是高德还是滴滴，阳光出行的订单总量非常高，尤其像最近下大雪，可能其他平台出了一点小问题，有大量的订单也到了阳光身上，但司机想的是我从早上9点出车一直到晚上9点，不想停，想一直有单子，这一块儿对于听单的能力监测，阳光专门做了一套策略，会在同城的所有司机当中会去计算听单的转化率分布。

通过这个听单的转化能力，我们去评估司机在当天整个单均的等单时长，单均服务的价格，以及司机自身的听单转化率，然后计算出他在同城司机当中分布的情况，后面会基于这种所处的位置去做对应的听单的指引。

听单指引主要是计算司机的ETA预估到达时间，给司机一个热区的具体位置。在司机的驾驶过程当中，阳光会实时的计算，司机在整个热区的区域当中被派单的几率能有多大的提升，基于司机驾驶的方向再去同步的给到最新的订单，优先派发给司机。

那么在订单完成的服务当中，其实阳光还会去做智能辅助的判责，判责这块也是我们一个重要的业务指标，因为跟各个渠道都有客诉率上面的一些评估和要求。实际上二线人工的座席会进行大量的客诉处理，比如说司机爽约或者是司机多收了一些附加费，或者是在行驶过程中司机有绕路的行为。

基于这些典型的场景，实际上阳光现在都已经加入了一些智能化的辅助判责的手段，通过这些手段减少二线人工处理的人力。我们后面自研了一套AI的决策平台，这个决策平台跟阳光用到的容联七陌多媒体联络中心已经全部打通了，在座席的工作台上，实际上人工座席可以实时的看到司机和乘客进线之后关于订单所有的信息。

这些信息里面可以看到锁定对应的场景，把相关的订单、信息去做一个总结的推送，会智能化的把一个处理的方案生成，最后实际会体现在工单处理、结案陈词、智能的工单填写、填充，以及整个客诉流程，把原来人工单一去处理的环节，尽量去减少。结合智能判责的能力，包括历史推荐数据和智能处置入手，实现整个人工处理效率有一个质的飞跃。

除了这个事后的判责之外，实际上也会做一些实时的或者是前置的风控的判断，我们希望把事情扼杀到摇篮当中，能够事先的把整个客诉去降下来。不管是事后对于订单上面的一些问题做判责，还是事前（包括事中的时候），其实都会去通过相应的智能化模型，来处理和预判对应的一些问题。

阳光也是梳理了基于业务场景维度下面的数据特征，包括一些时空的数据，地图的坐标、轨迹、时间相关的，包括订单本身的类型属性，以及司机整个过往的服务记录、评分以及累计的投诉或者是评价的情况。

另外阳光也有达标的平台，去做数据的标注和处理，然后结合现在实时特征的数据，包括IM的数据，包括从容联七陌呼叫中心当中触发通话的数据和订单的轨迹流，会用到离线和在线的模型，去实时计算事件发生过程当中出现的问题。

我们针对自己出行场景上面TOP问题，迟到、爽约、线下交易、附加费和绕路的一些问题做前置的一些判断和风控的提醒。赤兔大模型发布以后，我们也跟容联七陌相关的产研的同事去做过一些对接，因为我们早些年其实已经完成了容联七陌整个系统的私有化部署，后来赤兔发布之后，直接去升级，这个事我们肯定要积极去研究。

因为GPT发布之后，其实这块的能力我们也是有一个比较大的关注，因为GPT展现的能力，如何在阳光的场景下落地，这个效果可能是非常显著的，因为我们公司的老板非常注重降成本这件事。

未来我们希望能够把一线的座席全部换成智能化机器人的方式来去做处理的，但是这块我们现在也是在探究的过程当中。刚才容联云的产品发布当时，说到了检索增强的生成方式，其实也是我们目前重点去探索和去研究的。

REG这种方式其实在GPT 4.0发布之后，这块研究和使用落地的情况现在已经不少了，阳光也是想在这方面做一些突破。如果只是用公开的API去试，其实整个的效果来说就会存在一些相应的问题。比如说我们知道常见的这种，因为大模型的底层原理是基于概率的，文字接龙本身对于大模型来说是一个驾轻就熟的事，但是它一本正经的回复实际上并没有提供太多的实用的信息价值。

但是大模型本身生成的能力和组织会话的能力，要怎么利用起来，其实是我们自己想研究和利用的重点。也是希望说通过检索增程式的方式，来做外挂的知识库，不管是我们自己向量的知识库，还是知识图谱。

以及订单系统里面检索索引，这些我们都希望加进去来实现对应的功能。因为通用的回复当中，可能它的答案太泛泛了，但是我们希望把提示信息做的特别具体，比如说会告诉大模型，司机现在接到的是一个即时的订单，这个单子预估接下来有10公里，这个派单距离有点远，但是希望给司机最后一个回复，要求司机能够尽量的去服务，这个远程接待是有补贴的，希望能提前联系乘客。

相关的一些具体数据和信息都会体现在阳光出行平台的服务规范上，直接通过阳光建立的索引，给到大模型，通过模型自身的回复能力，结合我们给到它的具体提示信息，能得到更好的回复效果。

最后我想简单的介绍一下我们这么多年跟容联七陌合作的具体内容，不管是我们现在已经做好的智能客服、座席辅助、智能工单，还是现在正在做的可视化语音，其实在多媒体呼叫联络中心这一块，我们合作的模式以及现在的成果已经比较显著了。

包括现在阳光即将去做的检索增强的生成，以及智能推理的引擎这一块，都是一个探究的阶段。因为我们不只是想把阳仔的助手做成一个客服的角色，还是希望它有一个领航员的角色，因为我们希望它有一个智能推理的能力。

这块现在有Reasoning Agent的方式可以去做，也希望跟容联七陌可以探究这部分的方法和方案，可以实现这些研究的方向，谢谢大家！