Dewu customer service robot multi-round SOP process engine technology practice

1. Business background

In the early days of self-development of Dewu customer service robot, the traditional one-question-one-answer FAQ solution was relatively coarse-grained. In actual business scenarios, it became increasingly difficult to meet the needs of users. Regarding consultation needs, there is no differentiated process solution to accurately guide users to solve problems. A large number of users still rely on manual customer service to solve problems. Early multi-round SOP engines mainly relied on third-party platforms. The response speed of the third-party was relatively slow, the services provided were not customizable, and the efficiency of process configuration was relatively low. With the rapid development of business, it is very necessary to improve the robot's ability to solve complex scenarios, reduce the cost of manual customer service, and provide a flexible visual multi-round SOP process configuration backend. This has started the self-developed multi-round SOP process engine. of mileage.

2. Introduction to Duolun

After understanding the business background, many people may not know much about Duolun in customer service scenarios. Here we will introduce how the robot works based on actual human-machine dialogue. Based on multiple rounds of solving user problems.

As can be seen from the above, the user consultation process is completed step by step according to the question and answer process. During this period, there is no manual customer service intervention. In multiple rounds of conversations, customer service Bots solve user problems. Then there may be a question here, how does the robot know what to ask and what to answer? In fact, it is neither semantic recognition nor algorithm recognition. There is a corresponding visual construction page in the configuration background to configure multiple rounds of processes.

3. Preliminary research

After clarifying the requirements, what kind of technical capabilities should be used to build the robot's multi-round SOP process? Whether to implement it from 0 to 1 or based on an open source framework? The main choice issue faced. It is of course the best to implement it from 0 to 1, and it is also an opportunity for many technical students to challenge themselves. However, the main problem faced at that time was that the process construction involved Canvas canvas and graphics editing. If you do not have a background of professional knowledge, it will be relatively difficult. It was relatively large, and coupled with the rapid development of the business at that time, there was an urgent need for the ability to customize multiple rounds of self-developed products, so I chose an open source framework to implement it. In the investigation of open source frameworks, we also referred to the implementation of many process configurations, as follows:

• X-Flowchart-Vue: A flowchart editing framework based on vue that can realize flowcharts Built, but it cannot meet the custom node styles in business scenarios;
• vue-flowchart-editor: A vue-based flowchart editing framework that provides several node styles and simple data configuration capabilities. For Custom nodes require secondary development based on source code;
• Activity: A relatively complete workflow solution, which is a complete set of process engines integrating front-end, back-end and data models. If used, not only the front-end We need to do secondary development here, and the back-end also has to deploy corresponding services or secondary design and development. The cost is relatively high, and the front-end technology stack used by Activity is relatively old, and it is relatively old in our existing system. It is difficult to integrate, so it is not suitable in the current business scenario;
• Flowable: a business process engine, the main development language is Java, if used, the backend needs to deploy a complete set of process engine services, the front-end side It mainly cooperates with modifications, the cost is relatively high, and it is not suitable in the current business scenario;
• X6: It is a graph editing engine under AntV, which provides a series of out-of-the-box interactive components and is easy to use The node customization capability makes it easy to quickly build flowchart and other graph applications.

Each framework has its own advantages and disadvantages. Finally, we chose the antv-x6 graph editing engine for secondary development. The main reasons are as follows:

• Ant's Open source data product, the community is relatively active;
• has nothing to do with the technology stack, and has good scalability;
• supports custom nodes and has high customizability;
• tools The components are relatively complete and can be used out of the box

4. Technical architecture

After the technology selection is clarified, the next step is the specific technology implementation. The multi-round SOP process engine not only requires the design and implementation of the front-end, but also cannot do without the design and implementation of the back-end. The overall architecture design is shown in the figure below:

4.1 Front-end configuration Layer

The front-end configuration layer mainly includes four functional modules: multi-round SOP visual process construction, online and offline management, version management and interface management.

• Multiple rounds of SOP visual construction: including drag-and-drop operations and data configuration of each business node, and generating a complete process configuration through the association of different business nodes;
• Online and offline management: for building a good The multi-round SOP process requires online and offline operations. When problems occur in the online multi-round process, you need to go offline in time;
• Version management: When the configured multi-round SOP process is just released , the reply skills or functions of the process nodes are relatively basic, and the process capabilities need to be continuously improved through the process data of online users. Each change requires an upgraded version to ensure a stable online version while being able to handle multiple rounds of SOP processes. Continuous optimization;
• Interface management: Each business node involved in the process relies on services in different business domains. For example, orders need to rely on transaction interfaces, logistics needs to rely on supply chain interfaces, etc., which are involved in business process configuration To achieve this type of function, you need to implement it through interface configuration.

4.2 Back-end service layer

The core part of the back-end service layer is the process execution engine module. In actual application scenarios, the most appropriate solution will be matched based on the questions entered by the user. Process to solve user problems. In the process of executing the matched process, the execution engine will first create the context of the process. Here, the context information will be loaded from the redis cache. Based on the process execution status recorded in the context, it will be determined from which node to start execution. After execution, the context will be Information updates. When the process execution ends, the context is destroyed.

4.3 Application layer

The application layer is mainly the specific usage scenarios of the multi-round SOP process. Currently, it mainly includes two usage scenarios of Dewu customer service robot and agent-assisted SOP.

5. Technical Challenges

5.1 Data Modeling

Solve the problem of the relationship between nodes through data modeling.

In the process of visualizing the multi-round SOP process, the creation and connection of canvas nodes is the most complicated. Some multi-round scenes have more than 100 nodes, and the relationship between nodes is very important on the canvas. . There are currently 4 types of business-customized nodes, as follows:

##Each node has its own business attributes. Here, the business attributes and association attributes of each node are abstracted mainly through the idea of ​​data modeling. The idea is as follows:

The original data types provided by Attributes can well meet the needs of customized business data. After analyzing the four types of business nodes, each business node can abstract a common data model. The meanings of its main fields are as follows:

nodeName: the name of the node
• nodeType: the type of the node , there are four node types: slot filling node, jump node, reply node and judgment node
• fromNodeId: ID of the source node
• nextNodeId: ID of the pointing node
• fromEdgeIdList: List of source edge IDs
• nextEdgeIdList: Pointing to the list of edge IDs
• bizData: Business attribute information of different business nodes

Here bizData is used as the business node A general data model used to store attribute data of different business nodes. For example, slot filling nodes have business attributes such as slot and abnorma, and reply nodes have business attributes such as contentSort and content. By abstracting the data model of business nodes, the relationships between different nodes can be expressed, as shown in the following figure:

• The judgment node can be associated with the slot filling node and the jump node through the nextEdgeIdList attribute;
• The judgment node can be associated with the manual reply node through the fromNodeId attribute;
• It can be converted to the manual reply node The bottom-up reply node is associated through nextNodeId;
• The bottom-up reply node can be converted to a manual reply node through fromEdgeIdList.

After different node relationships are expressed through semantic attributes, the connection between nodes and edges is realized based on the addNode/addEdge method provided by X6, so that no matter how many nodes there are in the canvas, the connections between nodes are The relationships are very clear.

5.2 RXJS

Solve the problem of data flow direction of different functional modules through RXJS event subscription and one-way data flow

In the multi-round SOP visualization backend, there are three different functions Area: toolbar, canvas area and data configuration area. The operation of each area will involve the change of node data. If there is no clear data flow, it will lead to chaotic data changes and the risk of potential data confusion when saving. Here we adopt the design pattern of RXJS event subscription and one-way data flow. The specific implementation is shown in the figure below:

• The node operation in the operation bar will trigger the event. For example, delete a node operation;
• Select the node to be deleted in the canvas area to trigger the node data deletion event;
• The data form configuration area receives the data of the node data deletion event, deletes the corresponding node data and Synchronize to the data memory cache;
• When the process is finally submitted, the data in the memory is transferred to the server database.

The entire process flows from node data to form data and then to cache data. The entire flow direction is one-way. No matter which module is triggered, the final flow direction is the data memory cache.

For data flow, there are currently many open source frameworks available, such as redux, vuex, dva, etc. Why is RXJS used here? Mainly because RXJS is relatively lightweight and has nothing to do with the technology stack, so it has better subsequent scalability.

5.3 Process Orchestration

Solve the problem of complex multi-round process construction through process orchestration technology

As of the first half of the year, there have been nearly 200 online multi-round processes, which are somewhat complicated The process contains more than 100 nodes. If a complex process with more than 100 nodes is configured node by node, the configuration efficiency will be extremely low. So how do we quickly build a complex process? Process orchestration technology is used here.

Process orchestration refers to arranging business processes by dragging and dropping visual business components, and then the process engine executes the process. Its standardized protocol is the BPMN protocol, which contains the meanings and usage specifications of various icons and components in process orchestration. In actual application scenarios, we did not fully use the BPMN protocol, but followed the BPMN protocol and made customized components. For complex processes, we arrange them through different sub-processes. The idea is as follows:

Here is an example of the multi-round process of canceling orders. The process is broken down as follows:

As can be clearly seen from the above figure, the multi-round order cancellation process includes three sub-processes: determining user identity sub-process, determining user appeal sub-process, and canceling order sub-process. Each sub-process is an independent and complete process. In this way, through the arrangement of three sub-processes, a complex multi-round process for order cancellation can be built.

The above three points are the main technical challenges encountered in the process of self-research. In fact, there are still many difficulties in the process, such as how to render hundreds of nodes in seconds and complex How to arrange logic (copy, cut), how to expand and collapse complex judgment nodes with one click, etc., will not be elaborated here one by one.

6. Business results

The self-research of multiple rounds of customer service SOP process engines has completely replaced the third-party services, which not only saves at least hundreds of thousands of outsourced service costs every year, but also improves business performance. It has achieved good results, achieved flexible customization, and quickly supported business development. Since its launch, it has mainly covered two business scenarios: Dewu customer service robots and agent-assisted robots. Among them, Dewu robots have hundreds of multi-round SOP processes, and agent-assisted robots have dozens of multi-round SOP processes, which has improved to a great extent. Improve customer service resolution rate and reduce transfer labor costs. After going online, taking the data from one month of this year as an example, the solution rate of the customer service robot has improved significantly. The SOP solution rate has increased by more than 15% compared to the FAQ solution rate. The SOP reception number is 2 times the FAQ reception number. This saves labor costs to a great extent.

7. Summary

The customer service robot multi-round SOP process engine takes about a month from project establishment to release. The process from scratch is the result of the joint efforts of all investors. At present, in addition to serving the above two scenarios, the multi-round process engine is also exploring usage scenarios in work order business and quality inspection business. It is also continuing to enrich agent assistance scenarios to provide standardized service processes for front-line customer service and improve front-line customer service. Resolution rate. In terms of functionality, we will continue to improve the capabilities of the process engine, support the use of more business scenarios, and continuously improve the capabilities of the process engine to become a benchmark in the industry.

The above is the detailed content of Dewu customer service robot multi-round SOP process engine technology practice. For more information, please follow other related articles on the PHP Chinese website!