在得物客服机器人自研早期，传统一问一答式的FAQ解决方案粒度较粗，在实际的业务场景中，越来越难以满足用户的咨询需求，也没有差异化的流程解决方案精准的引导用户解决问题，大量用户的咨询依然依赖人工客服解决问题。早期的多轮SOP引擎主要依赖于三方平台，三方响应速度比较慢，提供的服务可定制化的能力不足，在流程配置上，效率也比较低。随着业务的快速发展，提高机器人在复杂场景下的解决能力，降低人工客服的成本，提供灵活的可视化多轮SOP流程配置后台，是非常有必要的，至此开启了自研多轮SOP流程引擎的里程。
在了解业务背景之后，可能很多人对客服场景中的多轮不太了解，这里结合实际的人机对话来介绍下机器人是如何基于多轮解决用户问题的。
从上面可以看出，用户咨询的过程按照问答的流程一步一步走完，期间并没有人工客服的介入，在多轮的会话中，客服机器人解决了用户的问题。那这里可能会有个疑问，机器人是怎么知道该问什么该答什么的？语义识别or算法识别，其实都不是，在配置后台有对应的可视化搭建页面来配置多轮的流程。
在明确需求之后，通过什么样的技术能力搭建机器人多轮SOP流程，是从0到1去实现还是基于开源的框架去实现是当时面临的主要的选择问题。从0到1去实现当然是最好的，也是很多技术同学挑战自我的机会，不过当时面临的主要问题是流程的搭建涉及Canvas画布以及图形编辑，这块如果没有专业知识的背景，难度相对会比较大，再加上当时业务的快速发展，亟需自研的多轮产品来做定制化的能力，所以当时选择了基于开源的框架去实现。在对开源框架的调研上，也参考了比较多流程配置的实现，具体如下：
每个框架都有自己的优缺点，最后选择了基于antv-x6图编辑引擎做二次开发，其主要原因如下：
明确了技术选型之后，接下来就是具体的技术实现了。多轮SOP流程引擎不仅需要前端这块的设计实现，也离不开后端的设计实现，整体的架构设计如下图所示：
前端配置层主要包括多轮SOP可视化流程搭建、上下线管理、版本管理和接口管理四个功能模块。
后端服务层核心部分是在流程执行引擎模块，在实际应用场景中，会根据用户输入的问题来匹配最合适的流程以解决用户的问题。在执行匹配到的流程的过程中，执行引擎会先创建流程的上下文，这里会从redis缓存里面加载上下文信息，根据上下文中记录的流程执行状态，确定从哪个节点开始执行，执行完以后进行上下文信息的更新。当流程执行结束的时候，再做上下文的销毁操作。
应用层主要是多轮SOP流程具体的使用场景，目前主要包括得物客服机器人和坐席辅助SOP两个使用场景。
通过数据建模解决节点与节点之间关联关系的问题。
在多轮SOP流程可视化搭建过程中，画布节点的创建和连接是最复杂的，有些多轮场景的节点超过100个，节点之间的关系在画布上的体现就非常重要。目前业务自定义的节点有4类，如下：
每个节点都有自己的业务属性，这里主要通过数据建模的思想把每个节点的业务属性以及关联关系属性做了抽象，其思路如下：
X6提供的原始数据类型相对比较简单，只有id、html、data、shape等这些基本属性字段，在实际的业务场景中需要基于原始的属性字段去做扩展，X6提供的data属性就能很好的满足自定义业务数据的需求。分析四类业务节点之后，每个业务节点可以抽象通用的数据模型，其主要字段的含义如下：
这里bizData作为业务节点的通用数据模型，用于存放不同业务节点属性数据，比如填槽节点有slot和abnorma等业务属性，回复节点有contentSort和content等业务属性。通过对业务节点的数据模型抽象，就可以表示不同节点之间的关联关系，如下图所示：
不同的节点关联关系通过语义化属性表示之后，再基于X6提供的addNode/addEdge方法实现节点和边的连接，这样无论画布中有多少个节点，节点之间的关联关系都非常的清晰。
通过RXJS事件订阅和单向数据流解决不同功能模块数据流向的问题
在多轮SOP可视化搭建后台，有三个不同的功能区：工具栏、画布区和数据配置区，每个区域的操作都会涉及到节点数据的变更，如果没有清晰的数据流，将会导致数据变更混乱，保存的时候潜在数据错乱的风险。这里我们采用了RXJS事件订阅以及单向数据流的设计模式，具体实现如下图所示：
整个过程，从节点数据流向表单数据再流向缓存数据，整个流向是单向的，不管在哪个模块触发最终的流向都是数据内存缓存。
对于数据流，目前有很多开源的框架可以使用，比如redux、vuex、dva等等，这里为什么采用RXJS？主要是因为RXJS比较轻量，同时跟技术栈无关，后续可扩展性更好。
通过流程编排技术解决复杂多轮流程搭建的问题
截止到上半年，线上的多轮已经将近200个，有些复杂的流程包含100多个节点，对于100多个节点的复杂流程如果是一个节点一个节点去配置的话，那配置效率是极其低下的，那我们是怎么实现复杂流程快速搭建的呢？这里用到了流程编排技术。
流程编排是指通过拖拽可视化业务组件来编排业务流程，然后由流程引擎来执行这个流程。其标准化的协议是BPMN协议，BPMN协议包含了流程编排里面的各种图标、元件的含义和使用规范。在实际的应用场景中，我们并没有完全使用BPMN协议，而是遵循了BPMN协议，做了自定义的元件组件。对于复杂的流程，我们通过不同的子流程进行编排，其思路如下：
这里通过取消订单多轮流程举例，其流程拆分如下：
从上图可以清楚的看到，取消订单多轮流程包含了判断用户身份子流程、判断用户诉求子流程、取消订单子流程这三个子流程，其中每个子流程又是一个独立完整的流程。这样通过三个子流程的编排，就可以搭建取消订单复杂的多轮流程。
以上三点是在自研过程中遇到的主要的技术挑战，其实在做的过程中，还有很多的难点，比如上百个节点如何做到渲染秒开、复杂的逻辑（复制、剪切）如何编排、复杂的判断节点如何做到一键展开和折叠等等，这里就不一一阐述了。
客服多轮SOP流程引擎的自研，完全取代了三方服务，不仅节省了每年至少几十万的外采服务成本，并且在业务上取得了不错的成效，做到了灵活定制，快速支撑业务的发展。自上线之后，主要覆盖得物客服机器人和坐席辅助机器人两个业务场景，其中得物机器人多轮SOP流程有上百个，坐席辅助机器人多轮SOP流程有几十个，在很大程度上提升了客服的解决率，减少了转人工成本。上线之后，以今年其中一个月份的数据为例，客服机器人的解决率有比较明显的提升，其中SOP的解决率相对于FAQ的解决率提升了15%多，SOP接待数是FAQ接待数的2倍多，在很大程度上节省了转人工成本。
客服机器人多轮SOP流程引擎从立项到发布，整个周期差不多一个月左右的时间，从无到有的过程，是各投入方一起努力的结果。目前多轮流程引擎除了服务于上述两个场景之外，也在工单业务、质检业务探索使用场景，同时也在持续丰富坐席辅助场景，为一线客服提供标准化的服务流程，提升一线客服的解决率。在功能上，我们也会持续完善流程引擎的能力，支持更多业务场景的使用，将流程引擎的能力不断完善，打造成为业界的标杆。
以上是得物客服机器人多轮SOP流程引擎技术实践的详细内容。更多信息请关注PHP中文网其他相关文章！
