1.业务背景得物客服机器人自主研发初期，传统的一问一答的FAQ解决方案粒度相对粗。在实际业务场景中，越来越难以满足用户的咨询需求，也没有差异化的流程方案来精准引导用户解决问题。大量用户仍然依赖人工客服解决问题。早期的多轮SOP引擎主要依赖第三方平台，第三方响应速度相对较慢，所提供服务的定制化能力不足，流程配置效率较低。随着业务的快速发展，非常有必要提高机器人解决复杂场景的能力，降低人工客服成本，提供灵活可视化的多轮SOP流程配置后台。至此，自主研发的多轮SOP流程引擎已经上线。里程。2.多轮介绍在了解了业务背景之后，很多人可能对客服场景中的多轮不是很了解。这里我们介绍机器人是如何基于实际的人机对话，基于多轮解决用户问题的。从上面可以看出，用户咨询的过程是按照问答的过程一步步完成的。在此期间，没有人工客服的介入。在多轮对话中，客服机器人解决了用户的问题。那么这里可能会有一个问题，机器人是怎么知道要问什么和回答什么的呢？语义识别或者算法识别其实都不是。在配置后台，有对应的可视化构建页面，用于配置多轮流程。3、初步研究明确需求后，应该用什么样的技术能力来搭建机器人的多轮SOP流程，是从0到1实现还是基于开源框架实现是当时主要的选择问题那时。从0到1当然是最好的，也是很多技术同学挑战自我的机会。不过当时面临的主要问题是，构建过程中涉及到Canvas画布和图形编辑。如果没有专业知识背景，难度会比较高。比较大，再加上当时业务发展很快，急需多轮自研产品做定制能力，所以当时选择了开源框架来实现。在开源框架的研究中，我们也参考了更多流程配置的实现，如下：X-Flowchart-Vue：一个基于Vue的流程图编辑框架，可以实现流程图的构建，但不能满足业务场景自定义节点样式；vue-flowchart-editor：基于vue的流程图编辑框架，提供多种节点样式和简单的数据配置能力，自定义节点需要基于源码二次开发；Activity：一个比较完整的工作流解决方案，是一套集前端、后端和数据模型于一体的流程引擎。如果使用，不仅前端需要二次开发，后端也需要部署相应的服务或者二次设计开发成本比较高，Activity使用的前端技术栈比较老旧，很难集成到我们现有的系统中，所以不适合现在的业务场景；Flowable：一个业务流程引擎，主要开发语言是Java。如果使用，后端需要部署一整套流程引擎服务。前端主要配合修改，成本较高，不适合当前业务场景；X6：是AntV下的图形编辑器引擎，提供了一系列开箱即用的交互组件和简单易用的节点定制能力，可以轻松快速构建流程图等图形应用。每个框架都有自己的优点和缺点。最终我选择了基于antv-x6图文编辑引擎做二次开发。主要原因有：蚂蚁的开源数据产品，社区比较活跃；与技术栈无关，扩展性很好；支持自定义节点，定制能力强；工具组件比较齐全，开箱即用4.技术架构明确了技术选型后，接下来就是具体的技术实现。多轮SOP流程引擎不仅需要前端的设计与实现，还需要后端的设计与实现。整体架构设计如下图所示：4.1前端配置层前端配置层主要包括多轮SOP可视化流程构建、线上线下管理、版本管理和接口管理四个功能模块。多轮SOP可视化构建：包括各业务节点的拖拽操作和数据配置，通过不同业务节点的关联关系生成完整的流程配置；线上线下管理：对于已建立的多轮SOP流程，需要进行线上线下操作，当线上多轮流程出现问题时，需要及时下线；版本管理：配置的多轮SOP流程刚发布时，流程节点的回复词或功能比较基础，在线用户需要流程数据不断完善流程能力，每次变更都需要升级到保证线上稳定版可以针对多轮SOP流程持续优化；接口管理：流程中涉及的各个业务节点依赖业务域中不同的Service，比如订单需要依赖交易接口，物流需要依赖供应链接口等，这样的功能都涉及到业务流程配置，需要通过接口配置来实现。4.2后端服务层后端服务层的核心部分是流程执行引擎模块。在实际应用场景中，会根据用户输入的问题匹配最合适的流程，解决用户的问题。在执行匹配流程的过程中，执行引擎会首先创建流程的上下文。这里，上下文信息将从redis缓存中加载。根据上下文中记录的进程执行状态，决定从哪个节点开始执行。执行后，上下文信息更新。当流程执行结束时，执行上下文销毁操作。4.3应用层应用层主要是多轮SOP流程的具体使用场景。目前主要包括得物客服机器人和坐席辅助SOP两种使用场景。5.技术挑战5.1数据建模通过数据建模解决节点间的关系问题。在多轮SOP流程可视化构建过程中，canvas节点的创建和连接是最复杂的。一些多轮场景有100多个节点，节点之间的关系在画布上体现很重要。目前业务定义节点有四种类型，分别是：每个节点都有自己的业务属性，这里主要通过数据建模的思想抽象出每个节点的业务属性和关联关系属性，而思想如下：X6提供的原始数据类型比较简单。只有id、html、data、shape等基本属性字段。在实际业务场景中，需要在原有属性字段的基础上进行扩展。X6提供的数据属性可以很好的满足需求。自定义业务数据需求。分析了四类业务节点后，每个业务节点都可以抽象出一个通用的数据模型，其主要字段的含义如下：nodeName：节点的名称nodeType：节点的类型，这里有四种类型nodes：填槽节点、跳转节点、回复节点、判断节点fromNodeId：源节点IDnextNodeId：指向节点的IDfromEdgeIdList：源边ID列表nextEdgeIdList：指向边ID列表bizData：the不同业务节点的业务属性信息。用于存储不同业务节点的属性数据。比如填槽节点有slot、异常等业务属性，回复节点有contentSort、content等业务属性。通过抽象业务节点的数据模型，可以表示不同节点之间的关系，如下图所示：判断节点可以通过nextEdgeIdList属性关联到槽位填充节点和跳转节点；判断节点可以通过fromNodeId属性Node关联到人工回复；转为人工回复节点可以通过nextNodeId与底部回复节点相关联；底部回复节点可以通过fromEdgeIdList与手动回复节点相关联。通过语义属性表示不同的节点关联后，基于X6提供的addNode/addEdge方法实现节点与边的连接，这样无论canvas中有多少个节点，节点之间的关联都非常清晰。5.2RXJS通过RXJS事件订阅和单向数据流解决不同功能模块的数据流转问题在多轮SOP可视化构建的后台，有工具栏、画布区和数据配置区三个不同的功能区。各个区域的操作都会涉及到节点数据的变化，如果没有清晰的数据流转，会导致数据变化混乱，保存时有潜在的数据混乱的风险。这里我们使用RXJS事件订阅和单向数据流的设计模式。具体实现如下图所示：操作栏中的节点操作会触发一个事件，比如删除节点操作；在画布区域选中需要删除的节点，触发节点数据删除事件；数据表单配置区接收节点数据删除事件的数据，删除对应的节点数据并同步到数据内存缓存中；当进程最终提交时，将内存中的数据传递给服务器数据库。整个过程中，从节点数据到表单数据再到缓存数据，整个流向是单向的，无论哪个模块触发最终流向都是数据内存缓存。对于数据流，目前有很多开源框架可以使用，比如redux、vuex、dva等，这里为什么要用RXJS呢？主要是因为RXJS比较轻量，与技术栈无关，所以在未来有更好的扩展性。5.3流程编排通过流程编排技术解决复杂的多轮流程构建问题截至上半年，已有近200个多轮上线，部分复杂流程节点数超过100个。对于超过100个节点的复杂流程，如果是一个节点一个一个配置的话，配置效率极低，那么我们如何实现复杂流程的快速构建呢？这里用到了流程编排技术。流程编排是指通过拖拽可视化业务组件的方式编排业务流程，然后由流程引擎执行流程。它的标准化协议是BPMN协议。BPMN协议包含了流程布局中各种图标和组件的含义和使用规范。在实际应用场景中，我们并没有完全使用BPMN协议，而是遵循BPMN协议，制作自定义组件组件。对于复杂的流程，我们通过不同的子流程来安排，思路如下：这里，我们以取消订单的多轮流程为例，流程拆分如下：从上图来看，我们可以清楚地看到，取消订单的多轮流程包括判断三个子流程，分别是用户身份子流程、用户申诉子流程、订单取消子流程，每个子流程都是独立的和完整的过程。这样，通过三个子流程的安排，就可以构建一个复杂的多轮撤单流程。以上三点是自研过程中遇到的主要技术挑战。其实在做的过程中还有很多难点，比如如何实现数百个节点的即时渲染，复杂的逻辑（复制，剪切）如何排列，复杂的判断节点如何一键展开折叠等，这里不再赘述。6.业务效率。多轮自研的客服SOP流程引擎，全面替代第三方服务，不仅每年节省至少几十万的外包服务成本，而且在业务上也取得了不错的效果，实现了灵活定制和快速支持业务发展。自上线以来，主要覆盖得物客服机器人和坐席辅助机器人两大业务场景。其中得物机器人的多轮SOP流程有上百条，代理辅助机器人的多轮SOP流程有几十条，有了很大的提升。提高客服解决率，降低中转人工成本。上线后，以今年一个月的数据为例，客服机器人的解决率有了明显提升。与FAQ解决率相比，SOP解决率提升了15%以上，SOP接待量是FAQ接待量的2倍。次，大大节省了转移劳动力的成本。7、总结客服机器人多轮SOP流程引擎，从立项到发布，整个周期大概一个月左右。从无到有的过程是所有利益相关者共同努力的结果。目前，多轮流程引擎除了服务于以上两种场景外，还在探索工单业务和质检业务的使用场景。分辨率。在功能上，我们将不断完善流程引擎的能力，支持更多业务场景的使用，不断提升流程引擎的能力，成为行业标杆。
