滴滴客服平台建设解决方案

案言客服是连接用户与事业部的桥梁从用角度用户过能道C自助或者人工服渠道反馈问和表达诉求道识别和记录用户问题后，给出问题对应的解决方案。在过去问题对应的解决方案散在渠道及各关模块中导很问的包括体验和逻辑一致解决方案质量难以保证影解决能力和用户体验，而且难管理运维另一方面，这些解决方案很大程度依赖事业部提供的服务能力往的编程式接入成高代期且缺乏统一管会导致相同场景服务能力使用的一致性难以保证，影响解决方案的质量和用户体验。为了保证解决方案质量提升用户体验和管理效率我们需统一管理这些解决方案建设解决方案平台整各事业部提供业信和务能力，为人工智能渠道统一提供标准化解决方案。决方平台分析散落各的解决方案般是基于事业部输入的业务逻辑和服务能力处理能力大体以分为使的和解决问题的处理程我们前提了识和标准解决方案，方案，成整解决方案平台：：主要指流，简称为，应用场景比广，户问题的场景；主要指知相关产品在业内通常称为知识库，的问题解释和指导等场景；：主要负责管理问题到答案的关系；案针对需要通过标准化流程引导以及解决用户问题的场景们提供流程管理平台，负责生、执行和管理态程。用户（C端用户、客服等）过单面进行息互，背后则是理问题的业务流程向前驱动和处理，下是对这个链路的一个简单示在这个链路中需要解决几个问题：1).如何支持不同渠道的交互方式2).如何支持处理流程标准化；3).业务信和服务能力如何规范且高效地接入。为此，我在设计上从几方面进行了拆

式。交互方式实现表单的可支不同能力和一致的交互体验。的逻辑执行，起的作用的流程执能力，支接入到执行的线上化和标准化。能力的接入，我们从了及回的字段为了管理资源我们化接入和使的能力，服能力的标准化接入，同时对业营服能力更加友好。基于流程的整套配置管能力一个流从设到测到上线实现了流程线上化很大程度地缩短了务迭代周期提升产研效率。同时基这条链路现业可化管，业在务梳理、量把控、风险控制等方面提了有力支持。在今年年中，我们打通了端助链路味着一个用户问题应的处理自助流上线以全置上，代率均升。此基础上也同时打通-决方案单的数据链路业务精细化运营提供数据支撑，助力业务综合提升解决能力。静态决方针对大量业务信息要透传给用户或者辅助客服解决用户问题的些场景我们提供了标准的静态知识解决方案从产品层上提供客服知识点、用户对、相似题列表等。在服务对静态知识有两个核心诉求1.知识的结化/非构存；2.用各场景的检索能力。前产品在这两方面的能力受限于关系型数据库的存储接下来将进行一系列升级建设时也包括产品层面知识检索、运营和反馈等功能的进一步加强。方案匹配方案匹配是指根据用户问题找到相应的解决方案理多道的问题与同一方案的匹配关系。一般说来对于匹配过程一个问题能找到唯一的解决方案一个解决方案可以对应多个问那么理想情况下我们分别为用户的个问题和每个解决方案计唯一的编号案匹配层只需维护问题到答案的一多的关系即可。但在落地过程中我们发现：

用户问题的描述方式不是唯编号，而是多维度的排列组解决一方一方案的解决方案；因此方案匹配层设计思路是维护问组到答案组的关前这一层的能力比较单薄未来计划升级底层能力支持异构的问题和答案组匹配，提升可扩展性以适应业务及产品层的快速迭代。淀前面我们从业务视角介绍了决方案平台如何支持客服业其实在平台建设过程也遇了一些技术的面要合解决方案平台建设过程遇到的问题介绍一技术沉淀：流程在介绍动态解决方案的时候们提到它底层依赖的核心基础能——流程引擎。在方案选型的时候我们调研了Activiti等方案，作为比较成熟的工作流引擎activiti功能强大且有比较完整的态，但在我们的景中优势并不明显主要体现在几方从定位上我们建设的是流程引擎产品化后的产品对流引只依赖流程驱动的核心能从功能上在流程定义和行过程中部署校验、数据交互、支选择等方面有满足或不易扩展的需求；从性能上，Activiti的通用性和灵活性决定实现的复杂度如频繁的存储层操作等导致其性能表现不佳不能很好地满足我们的端场景对能的需求外考虑上手成本维护成本等综合因素，最终我们决定针对我的场景自研。作为轻量级的程引擎，自研流程引擎主要负责提供稳定的能力驱流执上层是型上为，介绍我们如流程*虑到性，我们在如流程时考了bpmn：

起点行路径、执策略；成流中的种元分为节点和顺序流两大了事件节点（点）、任务点、网关节点（如排他网关节点）；流程元素列表可以完整描述一个流程；要使用一个流程分两步：1.设计一个流程；2.执行这个流程好比定义一个类与创建个对象的关系此流程引擎的构基本也是按照这样的思路设计，分为两大部：流程定义和流程执：程定义为了保证流程在执行过程不受流程模更新的影响以及虑运维场景的需求们在流程定义时对流程模采用了近似快照的处理，在流程执行时直使用快照模型：程执行流程执行其实是从开始节点开始处理当前节点完成理后根据当前状态及配置规则到下一个节点并继续处理节直到结节点•

在程行程，游动引交互节点，流程引擎

工落地▍资源背文到种户问题整合输入还有部是服力主要是各事业部通整服业有业APIAPI入各种API入&资源服入事业部资源工入在里我们将事业部提供的服务能称为资源，并根据使用场景将资源分为大类：

API：主指事业部提供的接能力查询订单详情apiField：通常为一字段，eg.单详情接口返回的“总额”字段。使用资源分为定义资源和获取资源两部份源引擎提的能力也以这两部份为核心辅以相关的配套管理能力于是我们设计了关的模块：

客服端：SDK，使用方自行集SDK，根据资源引协议查询资源定义，并获取及解析资源服务端：服务端，支持源定义的查询；管理平台：配置化接入资源及资源列表的统一管理*量数据产出离线数据包括接入资源的用情况错误率、耗时等质量数据，帮助使用方及事业部发问题，迭代方案；互模：系统：

Manager：资源理后台，是资源及相关配置管理入口；Server服务端，需要性能稳定地支持客户的查询，尽量到量因此server只做两件：访问控制高效查询；Client客户端负责获取资源；：事业提的服能力目前要支持API，根据需求考扩展；可看，中即负责核心的获取资源的逻辑，层次设计：

：协层，描述用方如何使用资源，例如可扩展等；：核心逻a.与交互获取资源相关定义；根据定义计算执行计划；c.通用调事业部；解析和加工返回的数据，得到最终结果；：根据资源定义，用事业部能力获取直结果；举个例子，已知：

f1来自a1(应返回结果的apiField1段)；api参数为f4;f4不是数据，是对f3再加工；f3值为；f2述省略...求：f1、f2值；

协议析析出参数列表以及需要获取的资源列表；：这里括要取的源以它们赖的源配置；将得的资源列表分成组，组原则是组内每外的资源，抽象来说类似有向联通图的意思；Process每个组内的资源列表交给处理任务遍历进行原子处理：递归获取该资源依赖的资源列表；执行，得到原始结果；根据对原始结果进行工，得到最终结；