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

原创滴滴智能中台滴滴技术

桔妹导读：客服是连接事业部和用户之间的桥梁，相较于一些垂直业务主要专注于业务领域内的问题，客服业务有一个特点：面向各种业务各种场景解决用户的各类问题。面对多样化的场景需求以及业务的不断发展迭代，解决方案平台通过标准化的思路，整合业务提供的业务信息和服务能力，拉齐不同渠道的答案和处置方案，提供可视化的方案管理平台。本文介绍了体验平台团队如何针对客服业务的特点和挑战建设解决方案平台以及相关技术沉淀。

前言

客服是连接用户与事业部的桥梁。从用户角度，用户通过智能渠道如C端自助或者人工客服渠道反馈问题和表达诉求，渠道识别和记录用户问题后，给出问题对应的解决方案。

在过去，问题对应的解决方案散落在渠道及各相关模块中，导致很多问题的解法（包括体验和逻辑）不一致，解决方案质量难以保证，影响解决能力和用户体验，而且难以管理和运维。另一方面，这些解决方案很大程度依赖事业部提供的服务能力，以往的编程式接入成本高迭代周期长，而且缺乏统一管理会导致相同场景下服务能力使用的一致性难以保证，影响解决方案的质量和用户体验。

为了保证解决方案质量，提升用户体验和管理效率，我们需要统一管理这些解决方案：建设解决方案平台，整合各事业部提供的业务信息和服务能力，为人工和智能渠道统一提供标准化解决方案。

解决方案平台

分析散落各处的解决方案，一般是基于事业部输入的业务逻辑和服务能力封装的处理能力，大体可以分为两类：回答咨询使用的话术和解决问题的处理流程。为此我们目前提供了静态知识和动态流程两类标准解决方案，加上方案匹配层，组成整个解决方案平台：

动态解决方案：主要指流程，简称为SOP，应用场景比较广泛，例如用户自助处理单车关锁失败的流程，或者人工客服解决用户费用投诉的流程等，主要支持需要按标准流程处理和解决用户问题的场景；
静态解决方案：主要指知识，相关产品在业内通常称为知识库，在咨询类和指导类场景中很常见，例如用户进线咨询某个活动的规则，又例如客服熟悉新业务知识等，主要应用于规则介绍、问题解释和指导等场景；
方案匹配：主要负责管理问题到答案的关系；

▍动态解决方案

针对需要通过标准化流程引导以及解决用户问题的场景，我们提供了流程管理平台，负责生产、执行和管理动态流程。用户（C端用户、客服等）通过表单界面进行信息交互，背后则是处理该问题的业务流程向前驱动和处理，下图是对这个链路的一个简单示意：

在这个链路中需要解决几个问题：1). 如何支持不同渠道的交互方式；2). 如何支持处理流程标准化；3). 业务信息和服务能力如何规范且高效地接入。为此，我们在设计上从几方面进行了拆分：

交互方式：通过不同的表单类型支持各渠道不同的交互方式。同时通过多样化的组件能力、交互方式实现表单的可扩展性，支持不同业务在不同场景的各种诉求，为用户提供标准化的交互能力和一致的交互体验。
流程管理：流程是业务处理逻辑的核心部份，它负责根据用户和业务的输入数据，驱动处理步骤按业务规定的逻辑执行，起到引导和规范的作用。我们基于流程引擎提供了核心的流程执行和管理能力，支持业务针对不同场景自定义处理流程，实现从流程接入到执行的线上化和标准化。
资源管理：表单和流程的设计支持了业务信息的标准化接入，而对于服务能力的接入，我们从使用的角度定义了资源的概念，主要包括了api以及api返回的字段field。为了管理资源，我们基于资源引擎搭建了资源配置化接入和使用的能力，支持事业部服务能力的标准化接入，同时对业务运营使用服务能力更加友好。

整体功能架构

目前，基于流程的整套配置管理能力，一个流程从设计到测试到上线实现了全流程线上化，很大程度地缩短了业务迭代周期，提升产研效率。同时，基于这条链路实现了业务可视化管理，为业务在业务梳理、质量把控、风险控制等方面提供了有力支持。在今年年中，我们打通了C端自助链路，意味着一个用户问题对应的处理自助流程上线可以完全配置化上线，迭代效率平均提升60%。在此基础上也同时打通了端-解决方案-工单的数据链路，为业务精细化运营提供数据支撑，助力业务综合提升解决能力。

▍静态解决方案

针对大量业务信息要透传给用户或者辅助客服解决用户问题的这些场景，我们提供了标准的静态知识解决方案，从产品层上提供客服知识点、用户Q&A对、相似问题列表等。

整体功能架构

在客服业务中，对静态知识有两个核心诉求：1. 知识的结构化/非结构化存储；2. 适用各场景的检索能力。当前产品在这两方面的能力受限于关系型数据库的存储，接下来将进行一系列升级建设，同时也包括产品层面知识检索、运营和反馈等功能的进一步加强。

▍方案匹配

方案匹配是指根据用户问题找到相应的解决方案，处理多渠道的问题与同一方案的匹配关系。

一般说来对于匹配过程，一个问题能找到唯一的解决方案，一个解决方案可以对应多个问题。那么理想情况下，我们分别为用户的每个问题和每个解决方案设计唯一的编号，方案匹配层只需要维护问题到答案的一对多的关系即可。但在落地过程中我们发现：

用户问题的描述方式不是唯一编号，而是多维度的排列组合；
每次想匹配的不一定是一个标准解决方案，也可以是一组，比如一个静态知识方案和一个动态流程方案打包成最终的解决方案；

因此方案匹配层的设计思路是维护问题组到答案组的关系，目前这一层的能力比较单薄，未来计划升级底层能力，支持异构的问题组和答案组匹配，提升可扩展性以适应业务及产品层的快速迭代。

技术沉淀

前面我们从业务视角介绍了解决方案平台如何支持客服业务，其实在平台建设过程也遇到了一些技术上的挑战，下面主要结合解决方案平台建设过程中遇到的问题介绍一些技术沉淀：

▍流程引擎

背景

在介绍动态解决方案的时候，我们提到它底层依赖的核心基础能力——流程引擎。在方案选型的时候我们调研了Activiti等方案，作为比较成熟的工作流引擎，activiti功能强大且有比较完整的生态，但在我们的场景中优势并不明显，主要体现在几方面：

从定位上，我们建设的是流程引擎产品化后的产品，对流程引擎只依赖流程驱动的核心能力；从功能上，在流程定义和执行过程中对部署校验、数据交互、分支选择等方面有activiti不满足或不易扩展的需求；从性能上，Activiti的通用性和灵活性决定了实现的复杂度，如频繁的存储层操作等导致其性能表现不佳，不能很好地满足我们的C端场景对性能的需求；此外考虑上手成本及维护成本等综合因素，最终我们决定针对我们的场景自研。作为轻量级的流程引擎，自研流程引擎主要负责提供稳定而高效的能力：驱动流程执行，告诉上层下一个节点是什么。

关键模型

以上图为例，简单介绍下我们如何描述一个流程（*考虑到兼容性，我们在设计如何描述流程时参考了bpmn的相关规范）：

流程：定义了起点、终点以及起点到终点需要执行的活动、执行路径、执行策略；
流程元素：构成流程中的各种元素，分为节点和顺序流两大类，其中节点又分了事件节点（如开始和结束节点）、任务节点、网关节点（如排他网关节点）；
流程模型：每个元素中描述了它从哪来可以向哪去，于是用流程元素列表可以完整描述一个流程；

整体设计

要使用一个流程分两步：1. 设计一个流程；2. 执行这个流程；好比定义一个类与创建一个对象的关系。因此流程引擎的架构基本也是按照这样的思路来设计，分为两大部份：流程定义和流程执行：

1. 流程定义

为了保证流程在执行过程中，不受流程模型更新的影响，以及考虑运维场景的需求，我们在流程定义时对流程模型采用了近似快照的处理，在流程执行时直接使用快照模型：

2. 流程执行

流程执行其实是从开始节点开始，处理当前节点，完成处理后根据当前状态及配置规则找到下一个节点，并继续处理节点，直到结束节点：

RuntimeProcessor：在流程执行过程中，上游主动与引擎交互的时机为开始执行流程和执行流程中的一些任务节点，流程引擎为流程执行开放了三个核心接口：开始执行、提交任务、回滚任务（提交的逆向操作）；
FlowExecutor：负责根据流程定义不断驱动节点的处理，同时管理流程实例的状态；
ElementExecutor：负责单个节点的处理，包括下一个节点的选择，同时管理节点实例的状态；

经过数月验证与迁移，现在我们的流程引擎已支撑动态解决方案90%的流量，其中包括面向C端的链路。在性能和稳定性表现比较好，上线至今未发生过任何一起相关故障。除了解决方案平台的使用场景以外，流程引擎也在进一步探索开放化，目前已在工单相关场景中落地。

▍资源引擎

背景

前文提到，解决方案平台为了解决各种用户问题，会整合的业务输入中还有一部份是服务能力（目前主要是由各事业部通过API提供）。不仅解决方案平台，整个客服业务在其他场景也有类似对接大量业务API的需求。基于使用和管理这些API以及高效接入和迭代的各种需求与痛点，我们参考解决方案平台的API接入&管理模式，将其沉淀抽象出资源引擎，收敛管理客服体系内接入的事业部API，提供使用资源的工具，支持配置化接入及统一管理。

整体设计

在这里我们将事业部提供的服务能力称为“资源”，并根据使用场景将资源分为两大类：

API：主要指事业部提供的接口能力，eg. 查询订单详情api；
Field：通常为一个字段，eg. 订单详情接口返回的“总金额”字段。

使用资源分为定义资源和获取资源两部份，资源引擎提供的能力也以这两部份为核心，辅以相关的配套管理能力，于是我们设计了相关的模块：

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

交互模式：

系统架构：

Manager：资源管理后台，是资源及相关的配置管理入口；
Server：服务端，需要高性能且稳定地支持客户端的查询，尽量做到轻量，因此server只做两件事：访问控制和高效查询；
Client：客户端SDK，负责获取资源；
*Resource：事业部提供的服务能力，目前主要支持API，未来根据需求考虑扩展；

资源计算

可以看到，其中Client即SDK负责最核心的获取资源的逻辑，层次设计：

Protocol：协议层，描述sdk使用方如何使用资源，例如可扩展GQL等；
Processor：核心逻辑，a. 与server交互获取资源相关定义；b. 根据定义计算执行计划；c. 通用executor调用事业部API；d. 解析和加工API返回的数据，得到最终结果；
Executor：根据资源定义，调用事业部能力获取直接结果；

举个例子，已知：

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

求：f1、f2的值；

Interpret：协议解析，解析出参数列表以及需要获取的资源列表；
Preprocess：这里包括要获取的资源以及它们依赖的所有资源的配置；
Allocate：将2得到的资源列表分成组，分组原则是组内的每个资源至少与组内的另一个资源有依赖关系，且不依赖任何组外的资源，抽象来说类似有向联通图的意思；
Process：将每个组内的资源列表提交给处理任务，遍历进行原子处理：