Dialogue management method, device, computer-readable storage medium and program product

Abstract

The present application provides a dialogue management method, device, computer-readable storage medium and program product, the method comprising: obtaining a first routing request sent by a routing server; restoring the state of the dialogue based on the tag information determined by the first routing request to obtain the current state of the dialogue; determining a trigger event based on the tag information; persisting the trigger event to an event storage space, and deciding a pre-execution action based on the trigger event and the current state; sending a first routing response to the routing server, so that the routing server sends a dialogue response carrying a pre-execution action to the terminal. In this way, the dialogue state can be quickly restored based on the tag information, so that multiple rounds of dialogue do not need to have a fixed request route, thereby realizing flexible human-computer dialogue, and only the trigger event needs to be stored in the event storage space, without having to store a large number of intermediate dialogue states, which can reduce the occupied memory space.

Description

Technical Field

[0001] The present application relates to the field of artificial intelligence technology, and relates to but is not limited to a dialogue management method, device, computer-readable storage medium, and program product. Background Art

[0002] Dialogue Management (DM) controls the process of human-computer dialogue. It will decide what kind of response to the user based on the historical information of the dialogue. According to the different levels of intelligence, dialogue management can be simply divided into single-round dialogue and multi-round dialogue. Single-round dialogue is similar to an upgraded version of the question-answering system, which can be used as an efficient and low-cost automated information retrieval or query tool; the core function of multi-round dialogue is to collect customer information and clarify customer needs in the process of repeated questioning and dialogue.

[0003] Since the multi-round dialogue management system needs to maintain the latest dialogue state in the system memory and determine the candidate set of the next state based on the current state, and the business is diverse and the user input is highly arbitrary, the state structure and conversion relationship of the multi-round dialogue management system are very complicated. Therefore, in the related art, the multi-round dialogue management system generally maintains the state structure and conversion relationship between the state configured by the user in the memory of the single-machine system, and jumps to the current state of the state machine based on the user's dialogue content (triggered event). In the multi-machine environment of the distributed system, it is difficult to realize the state structure and conversion relationship of the multi-round dialogue management system, and it is impossible to restore the dialogue context at a specified time point on any machine. Summary of the invention

[0004] The embodiments of the present application provide a dialogue management method, apparatus, device, computer-readable storage medium, and computer program product, which can implement multi-round dialogue management based on event tracing and finite state machines in a multi-machine environment of a distributed system.

[0005] The technical solution of the embodiment of the present application is implemented as follows:

[0006] The present application embodiment provides a dialog management method, which is applied to a dialog server in a distributed dialog management system cluster, and the method includes:

[0007] Acquire a first routing request sent by the routing server, where the first routing request is obtained based on a conversation request sent by the terminal, and the conversation request carries tag information of the conversation;

[0008] Restoring the state of the conversation based on the tag information to obtain the current state of the conversation;

[0009] Determining a trigger event based on the tag information, wherein the trigger event is used to transfer a current state of the dialog to a next state;

[0010] Persisting the trigger event to an event storage space, and deciding a pre-execution action based on the trigger event and the current state;

[0011] A first routing response is sent to the routing server, wherein the first routing response carries the pre-execution action, so that the routing server sends a dialog response to the terminal.

[0012] The present application embodiment provides a dialog management method, which is applied to a routing server of a distributed dialog management system cluster, and the method includes:

[0013] Acquire a dialog request sent by a terminal for executing a dialog management task, wherein the dialog request carries dialog tag information;

[0014] Selecting a dialog server for executing a dialog management task from the distributed dialog management system cluster, wherein the dialog server is in an idle state;

[0015] Determine a first routing request based on the conversation request, and send the first routing request to the conversation server, so that the conversation server recovers and makes a decision on the conversation based on the tag information to obtain a pre-execution action;

[0016] Obtaining a first routing response sent by the dialog server, where the first routing response carries the pre-execution action;

[0017] A dialog response is sent to the terminal, so that the terminal performs the pre-execution action.

[0018] The present application embodiment provides a dialog management device, which is applied to a dialog server in a distributed dialog management system cluster, and the device includes:

[0019] A first acquisition module, configured to acquire a first routing request sent by a routing server, wherein the first routing request is obtained based on a conversation request sent by a terminal, and the conversation request carries conversation tag information;

[0020] A first recovery module, used for recovering the state of the conversation based on the tag information to obtain the current state of the conversation;

[0021] A first determination module, configured to determine a trigger event based on the tag information, wherein the trigger event is used to transfer the current state of the dialog to a next state;

[0022] A persistence module, used to persist the trigger event to an event storage space;

[0023] A decision module, configured to decide a pre-execution action based on the trigger event and the current state;

[0024] The first sending module is used to send a first routing response to the routing server, where the first routing response carries the pre-execution action, so that the routing server sends a dialogue response to the terminal.

[0025] The present application embodiment provides a dialog management device, which is applied to a routing server of a distributed dialog management system cluster, and the device includes:

[0026] A second acquisition module is used to acquire a dialog request sent by a terminal for executing a dialog management task, wherein the dialog request carries dialog tag information;

[0027] A screening module, used to screen a dialog server for performing a dialog management task from the distributed dialog management system cluster, wherein the dialog server is in an idle state;

[0028] A second determining module, configured to determine a first routing request based on the dialogue request;

[0029] A second sending module, configured to send the first routing request to the dialogue server, so that the dialogue server recovers and makes a decision on the dialogue based on the tag information to obtain a pre-execution action;

[0030] A third acquisition module is used to acquire a first routing response sent by the dialogue server, where the first routing response carries the pre-execution action;

[0031] The third sending module is used to send a dialogue response to the terminal, so that the terminal executes the pre-execution action.

[0032] The present application provides a dialog management device, including:

[0033] A memory for storing executable instructions;

[0034] The processor is used to implement the method provided in the embodiment of the present application when executing the executable instructions stored in the memory.

[0035] An embodiment of the present application provides a computer-readable storage medium, on which executable instructions are stored, for causing a processor to execute and implement the method provided in the embodiment of the present application.

[0036] An embodiment of the present application provides a computer program product, including a computer program, and when the computer program is executed by a processor, the method provided by the embodiment of the present application is implemented.

[0037] The embodiments of the present application have the following beneficial effects:

[0038] In the dialogue management method provided in the embodiment of the present application, the routing service end of the distributed system determines the first routing request based on the dialogue request sent by the terminal. After the dialogue service end of the distributed system obtains the first routing request, it restores the dialogue based on the tag information carried by the dialogue request and restores the dialogue to the current state; then determines the trigger event based on the tag information, and according to the principle of the finite state machine, decides the pre-execution action according to the trigger event and the current state of the dialogue, and then persists the trigger event to the event storage space, so that the dialogue can be restored when responding to the next dialogue request. Finally, the dialogue server sends the first routing response carrying the pre-execution action to the routing service end, so that the routing service end sends the dialogue response to the terminal, so as to complete a round of human-computer dialogue in the distributed system. The dialogue management method provided in the embodiment of the present application is applied to the dialogue management system in the distributed system. The dialogue server end can quickly restore the dialogue state based on the tag information, so that multiple rounds of dialogue do not need to have a fixed request route, and each round of dialogue can request to be routed to any server in the distributed system, thereby realizing flexible human-computer dialogue, and the event storage space only needs to store the trigger event, and does not need to store a large number of intermediate dialogue states, which can reduce the occupied memory space. BRIEF DESCRIPTION OF THE DRAWINGS

[0039] Figure 1 A schematic diagram of the network architecture of the conversation management method provided in the embodiment of the present application;

[0040] Figure 2 It is a schematic diagram of the composition structure of the dialogue management device provided in an embodiment of the present application;

[0041] Figure 3 A schematic diagram of an implementation flow of the dialogue management method provided in an embodiment of the present application;

[0042] Figure 4 A schematic diagram of another implementation flow of the dialogue management method provided in an embodiment of the present application;

[0043] Figure 5 A schematic diagram of another implementation flow of the conversation management method provided in the embodiment of the present application;

[0044] Figure 6 A schematic diagram of another implementation flow of the dialogue management method provided in the embodiment of the present application;

[0045] Figure 7 A schematic diagram of an implementation flow of a multi-round session management method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0046] In order to make the purpose, technical solutions and advantages of the present application clearer, the present application will be further described in detail below in conjunction with the accompanying drawings. The described embodiments should not be regarded as limiting the present application. All other embodiments obtained by ordinary technicians in the field without making creative work are within the scope of protection of this application.

[0047] In the following description, reference is made to “some embodiments”, which describe a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0048] In the following description, the terms "first\second\third" involved are only used to distinguish similar objects and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0049] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as those commonly understood by those skilled in the art to which this application belongs. The terms used herein are only for the purpose of describing the embodiments of this application and are not intended to limit this application.

[0050] Before further describing the embodiments of the present application in detail, the nouns and terms involved in the embodiments of the present application are explained. The nouns and terms involved in the embodiments of the present application are subject to the following interpretations.

[0051] 1) Multi-round dialogue. Compared with single-round dialogue, the multi-round dialogue mode usually involves questions and answers. The chatbot will also initiate inquiries, and the robot will be involved in the "decision-making" process in multi-round dialogue, which is closer to the general dialogue mode. The core of the multi-round dialogue function is to collect customer information and clarify customer needs in the process of repeated inquiries and dialogues, but multi-round dialogue is still limited to user needs with clear goals, and it is also a task-driven chatbot.

[0052] 2) Dialogue Management (DM) controls the process of human-computer dialogue. DM decides the response to the user at this moment based on the dialogue history information. DM tasks include maintaining the dialogue state, generating system decisions, interacting with the backend / task model as an interface, and providing expected values ​​of semantic expressions. In essence, task-driven dialogue management is actually a decision-making process. During the dialogue process, the system continuously determines the optimal action to be taken next (such as providing results, asking for specific restrictions, clarifying or confirming requirements...) based on the current state, so as to most effectively assist users in completing the task of obtaining information or services.

[0053] 3) Snapshot: A fully available copy of a specified data set, which includes an image of the corresponding data at a certain point in time (the time when the copy starts). A snapshot can be a copy of the data it represents, or a replica of the data.

[0054] 4) The state machine, which is composed of a state register and a combinational logic circuit, can transfer states according to pre-set states based on control signals. It is the control center that coordinates related signal actions and completes specific operations.

[0055] 5) Natural Language Understanding (NLU), commonly known as human-computer dialogue, is a branch of artificial intelligence. It studies the use of electronic computers to simulate the human language communication process, so that computers can understand and use the natural languages ​​of human society such as Chinese and English, and realize natural language communication between humans and computers to replace part of human mental labor, including querying information, answering questions, extracting literature, compiling information, and all processing of natural language information.

[0056] 6) Nginx (engine x) is a lightweight web server / reverse proxy server and email (IMAP / POP3) proxy server, released under the BSD-like protocol. Its characteristics are small memory usage and strong concurrency capability.

[0057] 7) Load balancer, which mainly adopts load balancing technology to perform various flexible distribution calculations to evenly distribute all network requests to devices on other servers.

[0058] 8) Persistence is a mechanism for converting program data between a persistent state and a transient state. In layman's terms, it means that transient data (such as data in memory, which cannot be permanently saved) is persisted into persistent data (such as data persisted in a database, which can be stored for a long time).

[0059] The following describes an exemplary application of implementing the conversation management device provided in the embodiment of the present application. The conversation management device provided in the embodiment of the present application can be implemented as a user terminal or as a server. The following describes an exemplary application when the conversation management device is implemented as a server.

[0060] Figure 1 A schematic diagram of the network architecture of the conversation management method provided in the embodiment of the present application is shown in FIG. Figure 1As shown, the network architecture at least includes a dialogue server 100, a routing server 200, a network 300 and a terminal 400. To support an exemplary application, the routing server 200 connects the dialogue server 100 and the terminal 400 through the network 300. The network 300 can be a wide area network or a local area network, or a combination of the two, and uses a wireless or wired link to achieve data transmission.

[0061] In the embodiment of the present application, the dialogue server 100 can be any server in the distributed system (or server cluster) that includes a dialogue management system, and the routing server 200 is a front-end machine of the distributed system (or server cluster), such as Nginx or a load balancer. The terminal 400 can be a smart phone, a tablet computer, a laptop computer, a desktop computer, a smart speaker, a smart watch, etc., but is not limited thereto.

[0062] When the user conducts a human-computer dialogue with the terminal 400, the terminal 400 sends a dialogue request to the routing server 200, and the routing server 200 determines and sends a first routing request to the dialogue server 100 based on the dialogue request, wherein the dialogue request carries the tag information of the dialogue. The dialogue server 100 receives and responds to the first routing request, restores the state of the dialogue based on the tag information, and restores the dialogue to the current state; and determines a trigger event based on the tag information, and the trigger event is used to transfer the current state of the dialogue to the next state; then the dialogue server 100 persists the trigger event to the event storage space of the distributed system, decides a pre-execution action based on the trigger event and the current state of the dialogue, and carries the pre-execution action in the first routing response and sends it to the routing server 200. The routing server 200 sends a dialogue response to the terminal 400 based on the first routing response, so that the terminal 400 executes the pre-execution action, and the user continues the content of the next round of human-computer dialogue based on the execution result, thus completing a round of human-computer dialogue in the distributed system. The dialogue management method provided in the embodiment of the present application is applied to the dialogue management system in a distributed system. Each round of dialogue can request to be routed to any server in the distributed system, which can realize flexible human-computer dialogue. In addition, the event storage space only needs to store triggering events, and there is no need to store a large number of intermediate dialogue states, which can reduce the occupied memory space.

[0063] See also Figure 2 , Figure 2 The structure diagram of the conversation management device provided in the embodiment of the present application, the conversation management device 10 can be a conversation server 100 or a routing server 200, according to Figure 2The exemplary structure of the dialogue management device 10 shown can foresee other exemplary structures of the dialogue management device 10, so the structure described here should not be regarded as limiting. For example, some components described below can be omitted, or components not described below can be added to meet the special needs of certain applications.

[0064] Figure 2 The dialog management device 10 shown includes: at least one processor 110, a memory 140, at least one network interface 120 and a user interface 130. Each component in the dialog management device 10 is coupled together via a bus system 150. It is understood that the bus system 150 is used to achieve connection and communication between these components. In addition to the data bus, the bus system 150 also includes a power bus, a control bus and a status signal bus. However, for the sake of clarity, the bus system 150 is not described in detail. Figure 2 Various buses are labeled as bus system 150 .

[0065] The processor 110 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc., where the general-purpose processor can be a microprocessor or any conventional processor, etc.

[0066] The user interface 130 includes one or more output devices 131, including one or more speakers and / or one or more visual display screens. The user interface 130 also includes one or more input devices 132, including user interface components that facilitate user input, such as a keyboard, a mouse, a microphone, a touch screen display, a camera, other input buttons and controls.

[0067] The memory 140 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard disk drives, optical disk drives, etc. The memory 140 may optionally include one or more storage devices that are physically remote from the processor 110.

[0068] The memory 140 may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, the non-volatile memory may be a read-only memory (ROM). The volatile memory may be a random access memory (RAM). The memory 140 described in the embodiments of the present application is intended to include any suitable type of memory.

[0069] The memory 140 in the embodiment of the present application can store data to support various operations. Examples of such data include: any computer program used to operate on the dialogue management device 10, such as an operating system and an application program. Among them, the operating system includes various system programs, such as a framework layer, a core library layer, a driver layer, etc., which are used to implement various basic services and process hardware-based tasks. The application program can include various application programs.

[0070] As an example of the method provided in the embodiment of the present application being implemented by software, the method provided in the embodiment of the present application can be directly embodied as a combination of software modules executed by the processor 110. The software module can be located in a storage medium, and the storage medium is located in the memory 140. The processor 110 reads the executable instructions included in the software module in the memory 140, and completes the method provided in the embodiment of the present application in combination with the necessary hardware (for example, including the processor 110 and other components connected to the bus 150).

[0071] The conversation management method provided in the embodiment of the present application will be explained in combination with the exemplary application and implementation of the device provided in the embodiment of the present application.

[0072] Figure 3 A schematic diagram of an implementation flow of the dialogue management method provided in the embodiment of the present application, which is applied to Figure 1 The dialogue server in the network architecture shown will be combined with Figure 3 The steps shown are explained.

[0073] Step S301, obtaining a first routing request sent by a routing server.

[0074] Here, the first routing request is obtained based on a dialog request sent by the terminal, and the dialog request carries dialog label information.

[0075] When the user conducts a human-computer dialogue, he inputs the dialogue information through the terminal, and the terminal determines the dialogue tag information based on the input information. Then the dialogue tag information is carried in the dialogue request and sent to the routing server of the distributed system (i.e., the server cluster). The routing server here is the front-end machine of the distributed system, such as Nginx or load balancer servers.

[0076] After receiving the dialogue request, the routing server obtains a first routing request based on the dialogue request, arbitrarily selects a server including a dialogue management system in the distributed system (or server cluster) as the dialogue server for the human-computer dialogue, and sends the first routing request to the dialogue server to restore the historical dialogue state on the dialogue server and respond to the current dialogue request.

[0077] In the embodiment of the present application, the tag information may include the state machine F to be loaded, the dialog identifier S1, and the current input information input by the user to the terminal.

[0078] Among them, the conversation identifier S1 can be an identification code of the terminal device, such as a device identification code (Device ID, Device Identity), an international mobile equipment identity code (IMEI, International Mobile Equipment Identity), a unique device identification code (UDID, Unique Device Identifier), a universally unique identification code (UUID, Universally Unique Identifier) ​​and the like; it can also be an identification code that can identify user identity information, such as an identification code such as an ID number, a mobile phone number and the like.

[0079] The current input information input by the user to the terminal may be text information directly input by the user to the terminal, or may be text information obtained after voice recognition based on voice information input by the user to the terminal.

[0080] Step S302: restore the state of the conversation based on the tag information to obtain the current state of the conversation.

[0081] Based on the tag information, the conversation server obtains the historical time series Event from the event storage space of the distributed system, obtains the state machine configuration information from the state machine configuration information storage space of the distributed system, configures the corresponding state machine F based on the state machine configuration information, and initializes the state machine F, and records the initial state obtained by initialization as F0. Then, based on the historical time series Event and the state machine F, the state of the conversation is restored to the latest state, and the current state of the conversation is obtained, which is recorded as Fn.

[0082] Step S303: determining a trigger event based on the tag information.

[0083] Here, the trigger event is used to transfer the current state of the dialog to the next state.

[0084] The conversation server determines the trigger event based on the current input information of the user in this round of conversation, recorded as e n+1 (Fn, Fn+1). Fn is the current state of the dialog, and Fn+1 is the next state of the current state. n+1 (Fn, Fn+1) can generally be abbreviated as e n+1 .

[0085] Step S304: persist the triggering event to an event storage space.

[0086] Will trigger event e n+1 Stored in the event storage space Event Store, in order to be able to restore the conversation in the server of other distributed systems, a persistent storage method is adopted here to enable it to be preserved for a long time, so that the historical state of the conversation can be restored in other servers.

[0087] In the embodiment of the present application, only triggering events need to be stored in the event storage space, and there is no need to store a large number of intermediate conversation states, thereby reducing the occupied memory space. Moreover, since only triggering events are stored, the amount of data transmitted during recovery is small, thereby increasing the speed of recovering the conversation and shortening the recovery time.

[0088] Step S305: determining a pre-execution action based on the trigger event and the current state.

[0089] In the embodiment of the present application, the dialogue server of the distributed system performs state recovery based on a state machine, which may include four elements, namely, the current state (i.e., the current state), the condition (i.e., the event), the action (i.e., the pre-execution action), and the next state (i.e., the next state). n+1 The current state Fn of the dialogue is used to determine the pre-execution action using the state machine principle. The pre-execution action is the machine's reply action to the user's current input information. By executing the pre-execution action, the reply information can be obtained, thus completing a round of human-computer dialogue.

[0090] Among them, the pre-execution action is the action executed after the condition is met. After the action is executed, the state machine can migrate to the next state. The next state can be a new state or any existing historical state. It should be noted that after the condition is met and the state is migrated to the next state, the next state is activated as the new current state.

[0091] Step S306: Send a first routing response to the routing server.

[0092] Here, the first routing response carries the pre-execution action, so that the routing server sends a dialog response to the terminal.

[0093] The dialogue server carries the pre-execution action in the first routing response and sends it to the routing server. The routing server then determines the dialogue response based on the first routing response and sends the dialogue response to the terminal, so that the terminal can execute the pre-execution action and complete a round of human-computer dialogue corresponding to the dialogue request.

[0094] The dialogue management method provided by the embodiment of the present application is applied to the dialogue server in the distributed dialogue management system cluster, and the method includes: obtaining a first routing request sent by the routing server, the first routing request is obtained based on the dialogue request sent by the terminal, and the dialogue request carries the tag information of the dialogue; based on the tag information, the state of the dialogue is restored to obtain the current state of the dialogue; based on the tag information, a trigger event is determined, and the trigger event is used to transfer the current state of the dialogue to the next state; the trigger event is persisted to the event storage space, and a pre-execution action is determined based on the trigger event and the current state; a first routing response is sent to the routing server, and the first routing response carries the pre-execution action, so that the routing server sends a dialogue response to the terminal, so as to complete a round of human-computer dialogue in the distributed system. The dialogue management method provided by the embodiment of the present application is applied to the dialogue management system in the distributed system, and the dialogue server can quickly restore the dialogue state based on the tag information, so that multiple rounds of dialogue do not need to have a fixed request route, and each round of dialogue can request routing to any server in the distributed system, thereby realizing flexible human-computer dialogue, and the event storage space only needs to store the trigger event, and does not need to store a large number of intermediate dialogue states, which can reduce the occupied memory space.

[0095] In some embodiments, Figure 3 In the illustrated embodiment, step S302 “recovering the state of the conversation based on the tag information to obtain the current state of the conversation” can be implemented as the following steps:

[0096] Step S3021: Based on the tag information, load the state machine and historical event sequence corresponding to the conversation.

[0097] After receiving the tag information, the dialog server parses it to obtain the state machine F to be loaded, the dialog identifier S1 and the current input information included in the tag information, and then restores the state of the dialog to the latest state according to the state machine F to be loaded and the dialog identifier S1.

[0098] In some embodiments, the above step S3021 can be implemented as follows:

[0099] Step S0211, parsing the tag information to obtain the to-be-loaded state machine and dialog identifier corresponding to the dialog.

[0100] Step S0212, obtaining state machine configuration information.

[0101] Here, the state machine configuration information is stored in the state machine configuration storage space of the distributed system. The dialog server obtains the configuration information corresponding to the state machine F to be loaded from the state machine configuration storage space according to the state machine F to be loaded obtained after parsing.

[0102] Step S0213: Load the state machine to be loaded based on the state machine configuration information.

[0103] The dialog server loads the acquired configuration information into itself, and obtains the to-be-loaded state machine F corresponding to the configuration information.

[0104] Step S0214: Based on the conversation identifier, load the historical event sequence corresponding to the conversation identifier from the event storage space.

[0105] The dialogue server determines the dialogue to be restored according to the dialogue identifier S1, loads the historical event sequence corresponding to the dialogue to be restored from the event storage space Event Store of the distributed system, and records the historical event sequence as Event. Among them, the historical event sequence includes at least one historical trigger event e, and the number of historical trigger events in the historical event sequence is the round (number) of the human-computer dialogue.

[0106] In the embodiment of the present application, if the historical event sequence does not include a historical trigger event, that is, the historical event sequence is empty, it indicates that the user has not had a human-computer dialogue before, and therefore there is no historical trigger event.

[0107] Step S3022: restore the state of the dialog according to the state machine and the historical event sequence to obtain the current state of the dialog.

[0108] According to the loaded state machine F and the historical event sequence Event, the state of the dialogue to be restored is restored. In some embodiments, the above step S3022 can be implemented as follows:

[0109] Step S0221, initializing the loaded state machine to obtain the initial state of the dialog.

[0110] The dialog server initializes the loaded state machine F to obtain the initial state F0 of the dialog to be restored.

[0111] Step S0222: using each historical triggering event included in the historical event sequence, triggering the initial state of the dialogue to be gradually transferred to obtain the current state of the dialogue.

[0112] Since it has been determined in advance that the historical event sequence includes at least one historical triggering event, that is, it has been determined that the historical event sequence is not empty, combined with the state machine principle, starting from the initial state F0, in the order of the historical event sequence, each historical triggering event is traced, and each state in the dialogue is restored in turn, and finally restored to the current latest state, that is, the current state Fn of the dialogue.

[0113] In the dialogue management method provided in the embodiment of the present application, the dialogue server parses the tag information to obtain the state machine to be loaded and the dialogue identifier corresponding to the dialogue; obtains the state machine configuration information, loads the state machine to be loaded based on the state machine configuration information, and initializes the loaded state machine to obtain the initial state of the dialogue; then based on the dialogue identifier, loads the historical event sequence corresponding to the dialogue identifier from the event storage space, and uses each historical trigger event included in the historical event sequence to trigger the initial state of the dialogue to gradually transfer, and obtain the current state of the dialogue. Based on the tag information, the embodiment of the present application realizes the recovery of the dialogue on the dialogue server of the distributed system, and there is no need to maintain the state structure and conversion relationship of the dialogue on each server included in the distributed system, so that multi-round dialogues do not need fixed request routing, and realize a multi-round dialogue management system in a distributed multi-machine cluster environment.

[0114] In some embodiments, Figure 3 In the illustrated embodiment, step S303 "determining a trigger event based on the tag information" can be implemented as the following steps:

[0115] Step S3031, parse the tag information to obtain current input information.

[0116] Here, the current input information may be text information directly input into the terminal by the user, or may be text information obtained through voice recognition based on voice information input into the terminal by the user.

[0117] It should be noted that, if the current input information has been obtained by parsing the tag information when executing step S0211, there is no need to execute step S3031, and the current input information obtained by parsing step S0211 can be directly obtained.

[0118] Step S3032: Process the current input information based on NLU to obtain target dialogue content.

[0119] Since the current input information entered by the user has multiple expressions, but their semantics are the same, in order to unify the multiple expressions, the NLU service is called to process the current input information to obtain the target dialogue content. Multiple information with the same semantics but different expressions will have the same content after NLU processing. Processing the current input information based on NLU is equivalent to standardizing the current input information for machine recognition.

[0120] Step S3033, determining the next state of the dialogue according to the current state and the target dialogue content.

[0121] The dialogue server uses a state machine, regards the target dialogue content as the conditional element of the state machine, makes decisions based on the current state Fn and the target dialogue content, and obtains the next state Fn+1 of the dialogue.

[0122] Step S3034, determining a trigger event based on the current state, the next state and the target conversation content.

[0123] The conversation server determines the trigger event as e based on the current state Fn of the conversation, the next state Fn+1, and the target conversation content. n+1 (Fn, Fn+1), generally abbreviated as e n+1 .

[0124] The dialogue management method provided in the embodiment of the present application is that the dialogue server obtains the current input information by parsing the tag information, processes the current input information based on NLU to obtain the target dialogue content, decides the next state of the dialogue according to the current state and the target dialogue content, determines the trigger event based on the current state, the next state and the target dialogue content, and realizes machine dialogue based on event tracing and state machine in a distributed environment, thereby realizing human-computer dialogue in a distributed system.

[0125] based on Figure 3 After the illustrated embodiment conducts multiple rounds of dialogue, the embodiment of the present application further provides a dialogue management method to query the historical status of the multiple rounds of dialogue. Figure 4 Another implementation flow diagram of the dialogue management method provided in the embodiment of the present application is applied to Figure 1 The conversation server in the network architecture shown is Figure 4 As shown, the dialogue management method includes the following steps:

[0126] Step S401, obtaining a first routing request sent by a routing server.

[0127] Here, the first routing request is obtained based on a dialog request sent by the terminal, and the dialog request carries dialog label information.

[0128] In the embodiment of the present application, steps S401 to S406 are Figure 3 In the illustrated embodiment, steps S301 to S306 correspond to each other one by one, and their implementation manners and effects refer to the implementation manners and effects in steps S301 to S306, respectively.

[0129] Step S402: restore the state of the conversation based on the tag information to obtain the current state of the conversation.

[0130] Step S403: determining a trigger event based on the tag information.

[0131] Here, the trigger event is used to transfer the current state of the dialog to the next state.

[0132] Step S404: persist the triggering event to an event storage space.

[0133] Step S405: determining a pre-execution action based on the trigger event and the current state.

[0134] Step S406: Send a first routing response to the routing server.

[0135] Here, the first routing response carries the pre-execution action, so that the routing server sends a dialog response to the terminal.

[0136] Step S407: Acquire the second routing request sent by the routing server.

[0137] Here, the second routing request is obtained based on a query request sent by the terminal, the query request carries query condition information, and the query condition information is one of a deadline, a conversation duration, or a conversation number.

[0138] When the user wants to view the historical conversation, he enters the query condition in the terminal, and the terminal determines the query request according to the query condition, and sends the query request to the routing server, and the routing server determines the second routing request according to the query request, and sends the second routing request to the conversation server. It should be noted that in some embodiments, the conversation server when performing the query can be the same server as the conversation server in steps S401 to S406, or it can be a different server.

[0139] The query condition input by the user can be any one of time, conversation round, duration, etc. The terminal generates corresponding query condition information according to the input query condition: deadline, conversation duration or number of conversations. Further, based on the query condition information, a query request carrying the query condition information is generated.

[0140] Step S408: restoring the state of the conversation to a query state based on the query condition information.

[0141] Based on the query condition information, the dialogue server obtains the historical time series Event from the event storage space of the distributed system, obtains the state machine configuration information from the state machine configuration information storage space of the distributed system, configures the corresponding state machine F based on the state machine configuration information, and initializes the state machine F, and records the initial state obtained by initialization as F0. Then, based on the historical time series Event and the state machine F, the state of the dialogue is restored to the corresponding dialogue state when the query condition is met, that is, the query state.

[0142] Step S409: determining a query result based on the query status.

[0143] The conversation server determines the restored multi-round interaction information of the historical conversation as the query result according to the query state.

[0144] Step S410: Send a second routing response to the routing server.

[0145] Here, the second routing response carries the query result, so that the routing service end sends the query result to the terminal.

[0146] After the dialogue server obtains the query result, it carries the query result in the second routing response and sends it to the routing server. The routing server then carries the query result in the query response and sends it to the terminal. After receiving the query result, the terminal outputs it for the user to view.

[0147] Here, when the query result is output, it can be output in text form, can also be output in voice form, and can also be output in other possible forms.

[0148] In the conversation management method provided in the embodiment of the present application, the conversation server obtains a second routing request sent by the routing server, restores the state of the conversation to the query state based on the query condition information, determines the query result based on the query state, and sends a second routing response to the routing server, where the second routing response carries the query result, so that the routing server sends the query result to the terminal, realizes the query of historical conversations, and can quickly restore the conversation to the query state on any server in the distributed system, so as to facilitate the user to query historical conversations.

[0149] Based on the above embodiments, the present application further provides a dialogue management method. Figure 5 A schematic diagram of another implementation flow of the dialogue management method provided in the embodiment of the present application, which is applied to Figure 1 The routing server in the network architecture shown in Figure 1 is as follows: Figure 5 As shown, the dialogue management method includes the following steps:

[0150] Step S501: obtaining a dialog request sent by a terminal for executing a dialog management task.

[0151] Here, the dialog request carries dialog tag information.

[0152] When the user conducts a human-computer dialogue, he inputs the dialogue information through the terminal, and the terminal determines the dialogue tag information based on the input information. Then the dialogue tag information is carried in the dialogue request and sent to the routing server of the distributed system (i.e., the server cluster). The routing server here is the front-end machine of the distributed system, such as Nginx or load balancer servers.

[0153] In the embodiment of the present application, the tag information may include the state machine F to be loaded, the dialog identifier S1, and the current input information input by the user to the terminal.

[0154] Among them, the conversation identifier S1 can be an identification code of the terminal device, such as a device identification code (Device ID, Device Identity), an international mobile equipment identity code (IMEI, International Mobile Equipment Identity), a unique device identification code (UDID, Unique Device Identifier), a universally unique identification code (UUID, Universally Unique Identifier) ​​and the like; it can also be an identification code that can identify user identity information, such as an identification code such as an ID number, a mobile phone number and the like.

[0155] The current input information input by the user to the terminal may be text information directly input by the user to the terminal, or may be text information obtained after voice recognition based on voice information input by the user to the terminal.

[0156] Step S502: Screening a dialog server for executing a dialog management task from the distributed dialog management system cluster.

[0157] Here, the dialogue server is in an idle state.

[0158] In the embodiment of the present application, the first terminal may be any terminal in the server-side dialogue management system cluster. One implementation of screening the first terminal may be: randomly selecting a terminal from the server-side dialogue management system cluster; when the terminal is in an idle state, determining the terminal as the first terminal. When the terminal is in a non-idle state, continue to randomly select until the selected terminal is in an idle state.

[0159] Step S503: determining a first routing request based on the dialogue request.

[0160] After receiving the dialog request, the routing server determines a first routing request based on the dialog request, where the first routing request carries the tag information of the dialog.

[0161] Step S504: sending the first routing request to the dialog server, so that the dialog server recovers and makes a decision on the dialog based on the tag information to obtain a pre-execution action.

[0162] In a distributed system (or server cluster), a server end including a dialog management system is arbitrarily selected as a dialog server end for human-computer dialog, and a first routing request is sent to the dialog server end to restore the historical dialog state on the dialog server end, and respond to the current dialog request to obtain a pre-execution action.

[0163] Step S505: obtaining a first routing response sent by the dialogue server.

[0164] Here, the first routing response carries the pre-execution action.

[0165] Step S506: Send a dialog response to the terminal, so that the terminal executes the pre-execution action.

[0166] The dialogue server carries the pre-execution action obtained by the decision in the first routing response and sends it to the routing server. After receiving the first routing response, the routing server determines the corresponding dialogue response based on the first routing response and sends the dialogue response to the terminal, so that the terminal can execute the pre-execution action and complete a round of human-computer dialogue corresponding to the dialogue request. Here, the dialogue response carries the pre-execution action.

[0167] The dialogue management method provided in the embodiment of the present application is applied to the routing server of the distributed dialogue management system cluster, and the method includes: obtaining a dialogue request sent by the terminal for executing the dialogue management task, and the dialogue request carries the tag information of the dialogue; screening the dialogue server for executing the dialogue management task from the distributed dialogue management system cluster, and the dialogue server is in an idle state; determining a first routing request based on the dialogue request, and sending the first routing request to the dialogue server, so that the dialogue server recovers and makes decisions on the dialogue based on the tag information to obtain a pre-execution action; obtaining a first routing response sent by the dialogue server, and the first routing response carries the pre-execution action; sending a dialogue response to the terminal, so that the terminal executes the pre-execution action, so as to complete a round of human-computer dialogue in the distributed system. The dialogue management method provided in the embodiment of the present application is applied to the dialogue management system in the distributed system, and the routing server randomly determines the dialogue server from the distributed system, so that multiple rounds of dialogue do not need to have a fixed request route, and each round of dialogue can request routing to any server in the distributed system, thereby realizing flexible human-computer dialogue.

[0168] Based on the above embodiments, the present application further provides a dialogue management method. Figure 6 A schematic diagram of another implementation flow of the dialogue management method provided in the embodiment of the present application, which is applied to Figure 1 The network architecture shown in Figure 6 As shown, the dialogue management method includes the following steps:

[0169] Step S601: The terminal sends a session request to the routing server.

[0170] Here, the dialog request is used to perform a dialog management task, and the dialog request carries dialog tag information.

[0171] When the user conducts a human-computer dialogue, he inputs dialogue information through the terminal, and the terminal determines the dialogue tag information based on the input information. Then the dialogue tag information is carried in the dialogue request and sent to the routing server of the distributed system (i.e., the server cluster).

[0172] In the embodiment of the present application, the tag information may include the state machine F to be loaded, the dialog identifier S1, and the current input information input by the user to the terminal.

[0173] Step S602: The routing server randomly selects a server from the distributed dialog management system cluster.

[0174] Step S603: When the one server is in an idle state, the routing server determines the one server as a dialogue server.

[0175] The routing server randomly selects a server from the distributed dialogue management system cluster as the dialogue server, so that multiple rounds of dialogue do not need a fixed request route. Each round of dialogue can request routing to any server in the distributed system, thereby achieving flexible human-computer dialogue.

[0176] Step S604: the routing server determines a first routing request based on the dialogue request.

[0177] Here, the first routing request carries the label information of the dialogue.

[0178] Step S605: the routing server sends the first routing request to the dialogue server.

[0179] Step S606: the dialog server parses the tag information to obtain the to-be-loaded state machine and dialog identifier corresponding to the dialog.

[0180] Step S607: the dialogue server obtains state machine configuration information.

[0181] Here, the state machine configuration information is stored in the state machine configuration storage space of the distributed system. The dialog server obtains the configuration information corresponding to the state machine F to be loaded from the state machine configuration storage space according to the state machine F to be loaded obtained after parsing.

[0182] Step S608: The dialog server loads the state machine to be loaded based on the state machine configuration information.

[0183] The dialog server loads the acquired configuration information into itself, and obtains the to-be-loaded state machine F corresponding to the configuration information.

[0184] Step S609: the dialogue server loads the historical event sequence corresponding to the dialogue identifier from the event storage space based on the dialogue identifier.

[0185] The historical event sequence includes at least one historical trigger event e, and the historical event sequence includes the number of historical trigger events, which is the round of the human-computer dialogue.

[0186] Step S610: the dialog server initializes the loaded state machine to obtain the initial state of the dialog.

[0187] Step S611: The dialog server uses each historical triggering event included in the historical event sequence to trigger the initial state of the dialog to be gradually transferred to obtain the current state of the dialog.

[0188] In the embodiment of the present application, combined with the state machine principle, starting from the initial state of the conversation, each historical triggering event is traced in the order of the historical event sequence, and each state in the conversation is restored in turn, and finally restored to the current latest state, that is, the current state of the conversation.

[0189] Step S612: the dialogue server parses the tag information to obtain current input information.

[0190] Step S613: The dialogue server processes the current input information based on NLU to obtain the target dialogue content.

[0191] In the embodiment of the present application, processing the current input information based on NLU is equivalent to standardizing the current input information for machine recognition. After NLU processing, multiple information with the same semantics and different expressions obtain the same content.

[0192] Step S614: the dialogue server decides the next state of the dialogue according to the current state and the target dialogue content.

[0193] The conversation server uses a state machine to make decisions based on the current state and target conversation content to obtain the next state of the conversation.

[0194] Step S615: the conversation server determines a trigger event based on the current state, the next state and the target conversation content.

[0195] Here, the trigger event is used to transfer the current state of the dialog to the next state.

[0196] Step S616: the dialog server persists the trigger event to the event storage space.

[0197] The triggering event is stored in the event storage space. In order to be able to restore the conversation in the server of other distributed systems, a persistent storage method is adopted here to enable it to be preserved for a long time, so that the historical state of the conversation can be restored in other servers.

[0198] Step S617: the dialog server decides a pre-execution action based on the trigger event and the current state.

[0199] Among them, the pre-execution action is the action executed after the trigger event is satisfied. After the action is executed, the state machine can migrate from the current state to the next state.

[0200] Step S618: the dialogue server sends a first routing response to the routing server.

[0201] Here, the first routing response carries the pre-execution action, so that the routing server sends a dialog response to the terminal.

[0202] Step S619: the routing server sends a dialogue response to the terminal.

[0203] Here, the first routing response carries the pre-execution action, so that the terminal executes the pre-execution action.

[0204] Step S620: The terminal executes the pre-execution action.

[0205] The dialogue server carries the pre-execution action in the first routing response and sends it to the routing server. The routing server then determines the dialogue response based on the first routing response and sends the dialogue response to the terminal, so that the terminal can execute the pre-execution action and complete a round of human-computer dialogue corresponding to the dialogue request.

[0206] The dialogue management method provided in the embodiment of the present application implements a multi-round dialogue management system in a distributed system, and can quickly restore the dialogue state based on tag information, so that multi-round dialogues do not need a fixed request route, and each round of dialogue can request routing to any server in the distributed system, thereby realizing flexible human-computer dialogue, and the event storage space only needs to store trigger events, and there is no need to store a large number of intermediate dialogue states, which can reduce the occupied memory space.

[0207] In some embodiments, the terminal may also query historical conversations. In this case, after the above step S620, the method may further include the following steps:

[0208] Step S621: The terminal sends a query request to the routing server.

[0209] Here, the query request carries query condition information, and the query condition information is one of a deadline, a conversation duration, or a conversation number.

[0210] When the user wants to view historical conversations, he enters the query conditions in the terminal. The terminal determines the query request based on the query conditions and sends the query request to the routing server. The query conditions entered by the user can be any of time, conversation rounds, duration, etc. The terminal generates corresponding query condition information based on the entered query conditions: deadline, conversation duration, or number of conversations. Further, based on the query condition information, a query request carrying the query condition information is generated.

[0211] Step S622: The routing server randomly selects a server from the distributed dialog management system cluster.

[0212] It should be noted that the dialogue server used when performing the query may be the same server as the dialogue server in step S601 to step S620, or may be a different server.

[0213] Step S623: When the one server is in an idle state, the routing server determines the one server as a dialogue server.

[0214] The routing server randomly selects a server from the distributed dialog management system cluster as the dialog server and can query historical dialogs on any server.

[0215] Step S624: The routing service end determines a second routing request based on the query request.

[0216] Here, the first routing request carries query condition information.

[0217] Step S625: the routing server sends the second routing request to the dialogue server.

[0218] Step S626: The dialog server restores the state of the dialog to the query state based on the query condition information.

[0219] Based on the query condition information, the dialogue server obtains the historical time series from the event storage space of the distributed system, obtains the state machine configuration information from the state machine configuration information storage space of the distributed system, configures the corresponding state machine based on the state machine configuration information, and initializes the state machine to obtain the initial state. Then, based on the historical time series and the state machine, the dialogue state is restored to the dialogue state corresponding to the query condition, that is, the query state.

[0220] Step S627: the dialogue server determines the query result based on the query status.

[0221] The conversation server determines the restored multi-round interaction information of the historical conversation as the query result according to the query state.

[0222] Step S628: The dialogue server sends a second routing response to the routing server.

[0223] Here, the second routing response carries the query result, so that the routing service end sends the query result to the terminal.

[0224] Step S629: the routing server sends a query response to the terminal.

[0225] Step S630: The terminal receives the query response and outputs the query result carried in the query response.

[0226] The routing server sends the query result to the terminal in the query response, and the terminal outputs the query result after receiving it so that the user can view it.

[0227] The conversation management method provided in the embodiment of the present application realizes the query of historical conversations of multi-round conversation management in a distributed system, and can quickly restore the conversation to the query state on any server side of the distributed system, so as to facilitate users to query historical conversations.

[0228] The following is an explanation of an exemplary application of an embodiment of the present application in a practical application scenario.

[0229] Simply put, the work of an intelligent dialogue system is to understand human language and communicate effectively with humans, and then perform specific tasks or make responses based on the understanding of human intentions. According to the different levels of intelligence, the conversational expressions of intelligent dialogue systems can be simply divided into single-round and multi-round dialogues. Single-round dialogue is similar to an upgraded version of a question-and-answer system. It can be used as an efficient and low-cost automated information retrieval or query tool, and can guide users to perform self-service, giving full play to the role of the enterprise knowledge base; the core of the multi-round dialogue function is to collect customer information and clarify customer needs during repeated inquiries and conversations, but multi-round dialogue is still limited to user needs with clear goals, and is also a task-driven chatbot.

[0230] In the related art, the main solutions for multi-round conversation (i.e., dialogue in the above text) management system include maintaining the state structure and the conversion relationship between states configured by the user in the memory of a single-machine system, such as using a hash table as a data structure or using a state machine as a logical abstraction. Based on the user's conversation content (triggered event), the current state of the state machine is jumped. On this basis, in order to schedule and restore the conversation context in a cluster environment, there are generally two solutions:

[0231] Solution 1: Use fixed request routing to locate the same session to a specific machine, while still keeping the state in memory. This method requires that all states be kept in memory, storing complete session states and context information. If you need to trace back history, you need to take a snapshot of the historical state.

[0232] Solution 2: Take a real-time snapshot of the session context state and store it persistently. When scheduling to different machines in the cluster, the entire memory state needs to be restored based on the snapshot.

[0233] Since the multi-round session management system needs to keep the latest session state in the system memory and determine the candidate set of the next state based on the current state, it is very complicated to maintain such a state structure and transition relationship, and it is difficult to implement in a multi-machine environment of a distributed system; and due to the diversity of business and the high degree of randomness of user input, the relevant technology cannot restore the session context at a specified time point on any machine.

[0234] To solve the above problems, the present application provides a multi-round session management method based on event tracing and finite state machine in a distributed environment. Figure 7 A schematic diagram of an implementation flow of a multi-round session management method provided in an embodiment of the present application, such as Figure 7 Said method comprises the following steps:

[0235] Step S701: The front-end machine of the server session management system cluster sends request routing information to the machine M1.

[0236] The client connects to the front-end machine (such as Nginx or load balancer) of the server-side session management system cluster. The front-end machine can forward the request routing information to any instance machine M1 in the cluster that contains the session management system. The request routing information includes the tag Meta information of the conversation. In the embodiment of the present application, the tag information may include the state machine F to be loaded, the session unique identifier S1, user input information, etc.

[0237] Step S702, M1 loads the historical event sequence Event and the state machine.

[0238] M1 obtains the historical event sequence Event from the event storage space Event Store and the state configuration information from the state configuration information storage space. Machine M1 loads the corresponding state machine F according to the request routing information and initializes it to F0, and loads the historical event sequence Event according to the session unique identifier S1.

[0239] Step S703: M1 performs event tracing and state recovery.

[0240] If Event is not empty, M1 starts event tracing and restores the state in sequence (assuming that it contains events e1, e2, ..., e n , the state machine jumps F1, F2, ..., Fn) according to the configuration, and finally recovers to the current latest state Fn.

[0241] Step S704, M1 calls the NLU service, makes a decision on the next state, and obtains the next state Fn+1 and the pre-execution action.

[0242] The session management system calls the NLU service to determine the next state Fn+1 of the current state Fn from the next state candidate set of the state machine.

[0243] Step S705, M1 triggers a new event e n+1 , and update the status.

[0244] The session management system triggers a new event: e n+1 This event includes the state information of the decision in step S704, that is, setting the next state of the state machine to Fn+1.

[0245] Step S706, M1 responds to event e n+1 Make it persistent.

[0246] Session management system persistence n+1 To the event storage space, update the current event sequence to e1, e2, ..., e n , e n+1 ; and according to e n+1Modify the state of the state machine and jump to the next state Fn+1.

[0247] Step S707, M1 returns the pre-execution action to the client.

[0248] The session management system returns the result of this round of conversation to the client, completing a request.

[0249] When a new client connects to the server session management system, the process from step S701 to step S707 is repeated to restore and execute the session management task in any machine.

[0250] If you need to restore the state context to any point in time, you only need to restore the conversation state to the corresponding point in time based on the historical event sequence Event.

[0251] The dialog management method proposed in the embodiment of the present application introduces an event tracing mechanism into the session management system, and can implement a multi-round session management system in a distributed environment without the need for fixed request routing; it can reduce the storage of intermediate states and can quickly restore the session state to any specified time point; and it can quickly scale the session management system horizontally in a distributed environment.

[0252] The following is an exemplary structure of the dialog management device provided in the embodiment of the present application as a software module. In some embodiments, the dialog management device 80 stored in the memory 140 can be applied to the dialog server in the distributed dialog management system cluster, and can also be applied to the routing server in the distributed dialog management system cluster, such as Figure 2 As shown, when the dialog management device 80 is applied to the dialog server in the distributed dialog management system cluster, the software modules in the dialog management device 80 may include:

[0253] A first acquisition module 81 is used to acquire a first routing request sent by the routing server, where the first routing request is obtained based on a conversation request sent by the terminal, and the conversation request carries conversation tag information;

[0254] A first recovery module 82, configured to recover the state of the conversation based on the tag information to obtain the current state of the conversation;

[0255] A first determining module 83, configured to determine a trigger event based on the tag information, wherein the trigger event is used to transfer the current state of the dialog to a next state;

[0256] A persistence module 84, used to persist the trigger event to an event storage space;

[0257] A decision module 85, configured to decide a pre-execution action based on the trigger event and the current state;

[0258] The first sending module 86 is used to send a first routing response to the routing server, where the first routing response carries the pre-execution action, so that the routing server sends a dialogue response to the terminal.

[0259] In some embodiments, the first recovery module 82 is further configured to:

[0260] Based on the tag information, loading the state machine and historical event sequence corresponding to the conversation;

[0261] The state of the dialog is restored according to the state machine and the historical event sequence to obtain the current state of the dialog.

[0262] In some embodiments, the first recovery module 82 is further configured to:

[0263] Parsing the tag information to obtain a to-be-loaded state machine and a dialog identifier corresponding to the dialog;

[0264] Acquire state machine configuration information, and load the state machine to be loaded based on the state machine configuration information;

[0265] Based on the dialog identifier, a historical event sequence corresponding to the dialog identifier is loaded from the event storage space.

[0266] In some embodiments, the first recovery module 82 is further configured to:

[0267] Initializing the loaded state machine to obtain the initial state of the dialogue;

[0268] The initial state of the dialogue is triggered to be gradually transferred using each historical triggering event included in the historical event sequence to obtain the current state of the dialogue.

[0269] In some embodiments, the first determining module 83 is further configured to:

[0270] Parsing the tag information to obtain current input information;

[0271] Processing the current input information based on natural language understanding (NLU) to obtain target dialogue content;

[0272] Determine the next state of the dialogue according to the current state and the target dialogue content;

[0273] A trigger event is determined based on the current state, the next state, and the target conversation content.

[0274] In some embodiments, the dialogue management device 80 may further include:

[0275] a fourth acquisition module, configured to acquire a second routing request sent by the routing server, wherein the second routing request is obtained based on a query request sent by the terminal, the query request carries query condition information, and the query condition information is one of a deadline, a conversation duration, or a number of conversations;

[0276] A second recovery module, configured to restore the state of the conversation to a query state based on the query condition information;

[0277] A third determination module, configured to determine a query result based on the query state;

[0278] The fourth sending module is used to send a second routing response to the routing server, where the second routing response carries the query result, so that the routing server sends the query result to the terminal.

[0279] In some other embodiments, when the dialog management device is applied to a routing server in a distributed dialog management system cluster, the software modules in the dialog management device may include:

[0280] A second acquisition module is used to acquire a dialog request sent by a terminal for executing a dialog management task, wherein the dialog request carries dialog tag information;

[0281] A screening module, used to screen a dialog server for performing a dialog management task from the distributed dialog management system cluster, wherein the dialog server is in an idle state;

[0282] A second determining module, configured to determine a first routing request based on the dialogue request;

[0283] A second sending module, configured to send the first routing request to the dialogue server, so that the dialogue server recovers and makes a decision on the dialogue based on the tag information to obtain a pre-execution action;

[0284] A third acquisition module is used to acquire a first routing response sent by the dialogue server, where the first routing response carries the pre-execution action;

[0285] The third sending module is used to send a dialogue response to the terminal, so that the terminal executes the pre-execution action.

[0286] In some embodiments, the screening module is further used to:

[0287] Randomly select a server from the distributed dialog management system cluster;

[0288] When the one server is in an idle state, the one server is determined as a dialogue server.

[0289] It should be noted that the description of the above dialogue management device embodiment is similar to the above method description and has the same beneficial effects as the method embodiment. For technical details not disclosed in the dialogue management device embodiment of the present application, those skilled in the art should refer to the description of the method embodiment of the present application for understanding.

[0290] The embodiment of the present application provides a computer program product or a computer program, which includes computer instructions stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the above-mentioned conversation management method of the embodiment of the present application.

[0291] The embodiment of the present application provides a storage medium storing executable instructions, wherein the executable instructions are stored. When the executable instructions are executed by a processor, the processor will execute the method provided by the embodiment of the present application, for example, Figures 3 to 7 The method shown.

[0292] In some embodiments, the storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or various devices including one or any combination of the above memories.

[0293] In some embodiments, executable instructions may be in the form of a program, software, software module, script or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a stand-alone program or as a module, component, subroutine or other unit suitable for use in a computing environment.

[0294] As an example, executable instructions may, but need not, correspond to a file in a file system, may be stored as part of a file that stores other programs or data, such as in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple coordinated files (e.g., files storing one or more modules, subroutines, or code portions).

[0295] By way of example, executable instructions may be deployed to be executed on one computing device, or on multiple computing devices located at one site, or on multiple computing devices distributed across multiple sites and interconnected by a communication network.

[0296] The above is only an embodiment of the present application and is not intended to limit the protection scope of the present application. Any modifications, equivalent substitutions and improvements made within the spirit and scope of the present application are included in the protection scope of the present application.

Claims

1. A dialogue management method, characterized in that: Applied to a dialog server in a distributed dialog management system cluster, the method comprises: Acquire a first routing request sent by the routing server, where the first routing request is obtained based on a conversation request sent by the terminal, and the conversation request carries tag information of the conversation; Restoring the state of the conversation based on the tag information to obtain the current state of the conversation; Determining a trigger event based on the tag information, wherein the trigger event is used to transfer a current state of the dialog to a next state; Persisting the trigger event to an event storage space, and deciding a pre-execution action based on the trigger event and the current state; Sending a first routing response to the routing server, wherein the first routing response carries the pre-execution action, so that the routing server sends a dialog response to the terminal; The method further comprises: Obtaining a second routing request sent by the routing server, where the second routing request is obtained based on a query request sent by the terminal, where the query request carries query condition information, where the query condition information is one of a deadline, a conversation duration, or a number of conversations; Restoring the state of the conversation to a query state based on the query condition information; Determine a query result based on the query status; A second routing response is sent to the routing server, where the second routing response carries the query result, so that the routing server sends the query result to the terminal.

2. The method according to claim 1, characterized in that The restoring the state of the conversation based on the tag information to obtain the current state of the conversation includes: Based on the tag information, loading the state machine and historical event sequence corresponding to the conversation; The state of the dialog is restored according to the state machine and the historical event sequence to obtain the current state of the dialog.

3. The method according to claim 2, characterized in that The step of loading a state machine and a historical event sequence corresponding to the dialog based on the tag information includes: Parsing the tag information to obtain a to-be-loaded state machine and a dialog identifier corresponding to the dialog; Acquire state machine configuration information, and load the state machine to be loaded based on the state machine configuration information; Based on the dialog identifier, a historical event sequence corresponding to the dialog identifier is loaded from the event storage space.

4. The method according to claim 2, characterized in that: The restoring the state of the dialogue according to the state machine and the historical event sequence to obtain the current state of the dialogue includes: Initializing the loaded state machine to obtain the initial state of the dialogue; The initial state of the dialogue is triggered to be gradually transferred using each historical triggering event included in the historical event sequence to obtain the current state of the dialogue.

5. The method according to claim 1, characterized in that The determining a trigger event based on the tag information includes: Parsing the tag information to obtain current input information; Processing the current input information based on natural language understanding (NLU) to obtain target dialogue content; Determine the next state of the dialogue according to the current state and the target dialogue content; A trigger event is determined based on the current state, the next state, and the target conversation content.

6. A method for dialogue management, characterized in that: The method is applied to a routing server of a distributed dialog management system cluster, and comprises: Acquire a dialog request sent by a terminal for executing a dialog management task, wherein the dialog request carries dialog tag information; Selecting a dialog server for executing a dialog management task from the distributed dialog management system cluster, wherein the dialog server is in an idle state; Determine a first routing request based on the conversation request, and send the first routing request to the conversation server, so that the conversation server recovers and makes a decision on the conversation based on the tag information to obtain a pre-execution action; Obtaining a first routing response sent by the dialog server, where the first routing response carries the pre-execution action; sending a dialog response to the terminal so that the terminal performs the pre-execution action; Acquire a query request sent by a terminal, wherein the query request carries query condition information, and the query condition information is one of a deadline, a conversation duration, or a number of conversations; Determine a second routing request based on the query request, and send the second routing request to the dialogue server, so that the dialogue server restores the state of the dialogue to the query state based on the query condition information, and determines the query result based on the query state; Obtaining a second routing response sent by the dialogue server, where the second routing response carries the query result; A query response is sent to the terminal.

7. The method according to claim 6, characterized in that The step of selecting a dialog server for executing a dialog management task from the distributed dialog management system cluster includes: Randomly select a server from the distributed dialog management system cluster; When the one server is in an idle state, the one server is determined as a dialogue server.

8. A dialogue management device, characterized in that: The device is applied to a dialog server in a distributed dialog management system cluster, and comprises: A first acquisition module, configured to acquire a first routing request sent by a routing server, wherein the first routing request is obtained based on a conversation request sent by a terminal, and the conversation request carries conversation tag information; A first recovery module, used for recovering the state of the conversation based on the tag information to obtain the current state of the conversation; A first determination module, configured to determine a trigger event based on the tag information, wherein the trigger event is used to transfer the current state of the dialog to a next state; A persistence module, used to persist the trigger event to an event storage space; A decision module, configured to decide a pre-execution action based on the trigger event and the current state; A first sending module, configured to send a first routing response to the routing server, wherein the first routing response carries the pre-execution action, so that the routing server sends a dialogue response to the terminal; a fourth acquisition module, configured to acquire a second routing request sent by the routing server, wherein the second routing request is obtained based on a query request sent by the terminal, the query request carries query condition information, and the query condition information is one of a deadline, a conversation duration, or a number of conversations; A second recovery module, configured to restore the state of the conversation to a query state based on the query condition information; A third determination module, configured to determine a query result based on the query state; The fourth sending module is used to send a second routing response to the routing server, where the second routing response carries the query result, so that the routing server sends the query result to the terminal.

9. A dialogue management device, characterized in that: A routing server applied to a distributed dialog management system cluster, the device comprising: a second acquisition module, configured to acquire a dialog request sent by a terminal for executing a dialog management task, the dialog request carrying dialog tag information, and further configured to acquire a query request sent by a terminal, the query request carrying query condition information, the query condition information being one of a deadline, a dialog duration, or a number of dialogs; A screening module, used to screen a dialog server for performing a dialog management task from the distributed dialog management system cluster, wherein the dialog server is in an idle state; A second determination module, configured to determine a first routing request based on the dialogue request, and the second determination module is further configured to determine a second routing request based on the query request; a second sending module, configured to send the first routing request to the dialogue server, so that the dialogue server recovers and makes a decision on the dialogue based on the tag information to obtain a pre-execution action; the second sending module is further configured to send the second routing request to the dialogue server, so that the dialogue server recovers the state of the dialogue to a query state based on the query condition information, and determines a query result based on the query state; a third acquisition module, configured to acquire a first routing response sent by the dialogue server, the first routing response carrying the pre-execution action; the third acquisition module is further configured to acquire a second routing response sent by the dialogue server, the second routing response carrying the query result; The third sending module is used to send a dialogue response to the terminal so that the terminal executes the pre-execution action; the third sending module is also used to send a query response to the terminal.

10. A conversation management device, characterized in that: The device comprises: A memory for storing executable instructions; A processor, configured to implement the method of any one of claims 1 to 5 or 6 to 7 when executing the executable instructions stored in the memory.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores executable instructions for causing a processor to execute the method according to any one of claims 1 to 5 or 6 to 7.

12. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 5 or 6 to 7 is implemented.

Images