A multi-terminal soft service robot dialogue state migration method

Abstract

The present invention discloses a multi-terminal soft service robot dialogue state migration method, the method comprising the following steps: step S1, dialogue state element construction; step S2, dialogue log design; step S3, state trigger mechanism design; step S4, state-related dialogue process expansion; step S5, dialogue state storage. The present invention can abstract the dialogue into a file that can be transmitted on different terminal devices, realize the abstraction of the dialogue process, make it possible to transmit the unfinished dialogue process, and allow the dialogue to be transferred along with the scene, so that an unfinished dialogue process can be awakened and continued anytime, anywhere in the device belonging to the same user in any scene at any time, realize the synchronization of each terminal to the same dialogue, and keep the long dialogue task continuous between multiple terminal devices.

Description

Technical Field

[0001] The present invention belongs to the technical field of computer services, and relates to a method for migrating a dialog state, and in particular to a method for migrating a dialog state of a multi-terminal soft service robot. Background Art

[0002] In recent years, with the rapid development of artificial intelligence, blockchain, smart hardware, network technology, and especially the continuous breakthroughs in natural language processing technology, soft service robots have emerged. Soft service robots are a new type of conversational robot that guides users to raise their needs and obtain their needs through dialogue and questions in daily communication, and finally provides users with corresponding services. At present, many large companies at home and abroad have launched similar products and are constantly seeking further technological breakthroughs, which continuously promotes the development of soft service robots. The use of soft service robots can greatly simplify the old human-computer interaction method and transform some cumbersome operations into more acceptable voice communication.

[0003] With the advent of the 5G era, existing services have begun to grow exponentially. With the growth of services, the number of terminal devices available for interaction with users is gradually increasing, and thus the number of scenarios for human-computer interaction is gradually increasing. As the scenarios in which users are located continues to change, existing methods have been developed to meet the needs of users in multiple fields and at multiple levels through scenario-oriented intelligent terminal dialogue state design. This has led to the fact that the relationship between people and terminal devices is no longer just one-to-one. It is not uncommon for one person to have multiple terminal devices, and users may deploy different interactive terminals in different scenarios. These terminals are equipped with services that may be most suitable for users in the current scenario, and users often choose the most convenient terminal in the current scenario for interaction. As the number of service types increases, the interaction scenarios will become more and more refined and the use of terminals will become more and more frequent.

[0004] At present, due to the hardware limitations in traditional interactions, even if a user has multiple terminal devices for interaction, these devices are often independent individuals, and each individual maintains the conversation on its own terminal, resulting in a lack of interconnection between different terminal devices. At the same time, users often need to dynamically switch the terminal devices of multiple soft service robots in mobile scenarios to conduct continuous conversations to complete long tasks. The current soft service robot does not support the maintenance of continuous conversation status between multiple terminals. The original intention of using soft service robots is to simplify the interaction process between people and terminals to the greatest extent. At present, there is a lack of a conversation method that can effectively utilize the conversations that have been conducted on each terminal device, so that the previously existing conversations can be perfectly continued after the scene is changed, that is, the state of the conversation is migrated as the scene is transferred.

[0005] Based on the above research background, it can be found that by effectively abstracting the conversation and extracting the state of the conversation from it, the state of the conversation can be used to dynamically switch the end device of the conversation when the scene switches, thereby ensuring the continuity of long-task conversations. Summary of the invention

[0006] In order to solve the above problems existing in the existing technology, the present invention provides a multi-terminal soft service robot conversation state migration method for users to dynamically switch multiple soft service robot terminal devices for continuous conversation in mobile scenarios. The present invention can abstract the conversation into a file that can be transmitted on different terminal devices, realize the abstraction of the conversation process, make it possible to transmit the unfinished conversation process, and allow the conversation to be transferred along with the scene, so that an unfinished conversation process can be awakened and continued anytime and anywhere in the device belonging to the same user in any scene at any time, realize the synchronization of each end to the same conversation, and keep the long conversation task continuous between multiple terminal devices.

[0007] The objective of the present invention is achieved through the following technical solutions:

[0008] A multi-terminal soft service robot dialogue state migration method comprises the following steps:

[0009] Step S1: Constructing dialogue state elements:

[0010] The dialogue state elements include the following three elements:

[0011] Element E1, task-based dialogue algorithm;

[0012] Element E2, state abstract representation element: including the dialogue intermediate result, dialogue control identifier, device identifier, state elimination mechanism and state identifier, among which:

[0013] The intermediate results of the conversation are used to record the results expressed by the user in the completed conversation and store the requirements that the user has put forward;

[0014] The conversation control flag is used to control the direction of the entire conversation and restore the conversation process to the state before the conversation ended after the conversation state is migrated;

[0015] The device identifier is used to identify the device for the conversation. When the conversation requires the assistance of the terminal device, it finds the appropriate terminal device and initiates the request.

[0016] The state elimination mechanism is used to ensure that the conversation state does not continue to accumulate, and to discard unnecessary states when necessary;

[0017] The state identifier is used to reasonably identify the state so as to distinguish and find the corresponding appropriate state, giving the state a unique mark;

[0018] Element E3, state storage and wake-up mechanism;

[0019] In view of the complex and numerous problems of soft service robot dialogue algorithms, the elements of the dialogue state are often constructed differently. The dialogue state element construction in this step is mainly used for abstract dialogue. The completed process can be represented in a suitable text or file format, including the intermediate results obtained up to the current process and the communication process under the current process. It is now constructed in the following way:

[0020] Step S11: The intermediate result of the dialogue depends on the task-based dialogue algorithm of element E1. The requirements expressed by the user can be stored in a suitable format. The result stored in this format is the intermediate result of the dialogue. The model includes the value of the user input content and the description of the type corresponding to the value.

[0021] Step S12: The control mechanism of the task-based dialogue algorithm of element E1 is used as the basis for the control of the dialogue process. The part of the task-based dialogue algorithm of element E1 that controls the dialogue is stored in the form of parameters to obtain a dialogue control identifier in element E2 and used as an item of the dialogue abstract representation element. When a certain dialogue state is reawakened, the dialogue control identifier is input as a starting parameter to restore the dialogue state.

[0022] Step S13: No specific steps are required for the specific implementation of device identification, state elimination mechanism and state identification;

[0023] Step S2: Design of dialogue log

[0024] In the conversation process, a conversation log is added as a human interface for the conversation state. It is mainly used to reasonably extract and encapsulate the conversation records, and to help users recall the conversation process to reach the current conversation state in the most effective way. The conversation records stored in the log include the main body of the conversation, and invalid conversations and conversations that have been covered are eliminated. The conversation log should ensure that there are no contradictions between the recorded conversations and the abstract conversations, and can help users distinguish different states when the contents of the states themselves are similar.

[0025] Step S3: Design of state trigger mechanism

[0026] Add state-related elements based on trigger words or knowledge graphs to ensure that the state-related needs raised by users can be captured and recognized by the soft service robot terminal and then enter the processing flow of the dialogue state. The state trigger mechanism includes two trigger mechanisms: dialogue state storage trigger mechanism and dialogue state awakening trigger mechanism. Among them:

[0027] (1) When the conversation state storage mechanism is triggered, the intermediate results and conversation control identifiers of the entire conversation are extracted according to step S1. At the same time, the extracted results are bound to the conversation logs up to this point and a unique tag is assigned to the conversation state. Finally, the conversation state and conversation logs are stored as a whole.

[0028] (2) When the dialogue state awakening mechanism is triggered, the soft service robot searches for the most appropriate state for the user based on the dialogue state tag. When the states are similar and cannot be distinguished by tags, the soft service robot provides the user with a dialogue log to help the user recall the dialogue process of how to reach the dialogue state.

[0029] Step S4: Expanding the state-related dialogue process

[0030] If you want to add a dialog state migration method to the dialog based on step S2 and step S3, you need to expand the original dialog process. The specific steps are as follows:

[0031] Step S41, each user input is judged twice: first, the state trigger mechanism of step S3 is used to make a first judgment to determine whether each input triggers the trigger mechanism of step S3. If it is triggered, the corresponding operation is performed according to step S3. If it is not triggered, a second judgment is made to determine the validity of each dialogue, and the validity input is written into the dialogue log according to step S2;

[0032] Step S5: Dialogue state storage

[0033] Give each conversation state a unique tag and store it. The specific steps are as follows:

[0034] When the dialogue state storage mechanism in step S3 is triggered, the dialogue is abstractly extracted through the dialogue control identifier in step S1. The dialogue state needs to be stored because it is often not used immediately. The dialogue state needs to be marked with a unique identifier, and the mark must be mapped to a mark that the user can understand, such as time. When the state is stored, a unique tag is added to each state, and the user can easily find the expected dialogue state based on the tag.

[0035] Compared with the prior art, the present invention has the following advantages:

[0036] 1. The multi-terminal soft service robot dialogue state migration method proposed in the present invention makes up for the shortcomings of the existing dialogue mode. The concept of dialogue state is embedded in the dialogue to more fully maintain the consistency of the dialogue, synchronize the dialogue on each terminal device, and realize the dynamic switching of long dialogue tasks on the terminal device.

[0037] 2. The dialogue state migration method proposed in the present invention is not related to a specific dialogue algorithm, but is an external module of the algorithm itself. According to the present invention, any algorithm can model and abstract its own dialogue state. Developers can customize the state model and state module according to the actual algorithm to achieve a kind of universal soft service robot dialogue state migration.

[0038] 3. The present invention effectively associates soft service robots in different scenarios through the dialogue state. The dialogue state can be used to treat soft service robots in multiple scenarios as a whole, forming a special distribution, which enhances the association between different ends of the soft service robots.

[0039] 4. The present invention can support the abstract representation and storage of conversations, realize the transmission of conversation processes between different devices, and connect multiple devices to complete collaboration. It can realize the same transfer of conversations under scene switching, so that the conversation moves with the movement of the user, and complete a conversation in multiple scenes. BRIEF DESCRIPTION OF THE DRAWINGS

[0040] Figure 1 It is a relationship diagram of the elements of the multi-scenario soft service robot dialogue method based on state transfer of the present invention;

[0041] Figure 2 is the overall model of the dialogue state;

[0042] Figure 3 The present invention is a flow chart of the multi-scenario soft service robot dialogue method based on state transfer. DETAILED DESCRIPTION

[0043] The technical solution of the present invention is further described below in conjunction with the accompanying drawings, but is not limited thereto. Any modification or equivalent replacement of the technical solution of the present invention without departing from the spirit and scope of the technical solution of the present invention should be included in the protection scope of the present invention.

[0044] The present invention provides a multi-terminal soft service robot dialogue state migration method, the method comprising the following three elements:

[0045] Element E1: Task-based dialogue algorithm

[0046] The core of a soft service robot is the dialogue algorithm. In the present invention, there is no requirement for the dialogue algorithm. As long as the dialogue algorithm can support the dialogue, it can be embedded in the present invention.

[0047] Element E2: State abstract representation element

[0048] For task-based dialogues of soft service robots, the dialogue state can be expressed as follows:

[0049] Conversation state = <conversation abstract, conversation record>

[0050] Conversation abstraction is mainly for the terminal, encapsulating the information in the previous conversation, and the machine uses the information in the abstract conversation to restore the conversation process. Conversation records are mainly for users, helping users recall the conversation process at this state.

[0051] For different algorithms, in order to fully represent and restore the state of the conversation, the state abstract representation elements should include the following:

[0052] (1) Intermediate results of a conversation: This is a fully abstract element of a state identifier. Its main purpose is to record the results expressed by the user in the completed conversation and store the requirements that the user has put forward.

[0053] (2) Dialogue control flag: An identification parameter that controls the flow of a conversation. Its main purpose is to control the direction of the entire conversation. It can restore the conversation process to the state before the conversation ended after the conversation state is migrated.

[0054] (3) Device identification: Identifies the device on which the conversation is taking place. When the conversation requires assistance from a terminal device, it can find a suitable terminal device and initiate the request.

[0055] (4) State elimination mechanism: This mechanism is set up to ensure that the dialogue states do not continue to accumulate, and to discard unnecessary states when necessary.

[0056] (5) State identification: A reasonable identification is given to the state to facilitate the distinction and search for the corresponding appropriate state. The purpose of state identification is to give the state a unique mark.

[0057] Element E3: State storage and wake-up mechanism

[0058] Ensure that users can store and wake up the state at the appropriate time. When the scene the user is in needs to change or the unfinished conversation has to be terminated due to some circumstances, the terminal device needs to determine whether to store the conversation state independently or through a very brief conversation. After the scene is changed or the user expresses his / her willingness, the user's previously stored conversation state is woken up according to the state identifier, and the unfinished conversation encapsulated in this state is continued.

[0059] The corresponding relationship between the three elements is as follows Figure 1As shown, the dialogue control identifier and the intermediate dialogue result of the element E2 state abstract representation element are all from the task-based dialogue algorithm of element E1, wherein the dialogue control identifier can be converted with the algorithm dialogue control flow in the task-based dialogue algorithm, and the intermediate dialogue result is the storage of the intermediate result in the task-based dialogue algorithm. The state storage and wake-up mechanism of element E3 will be directly inserted into the task-based dialogue algorithm of element E1. According to the task-based dialogue algorithm itself, the specific dialogue state model is determined in accordance with the present invention. The relationship between the modules of element E2 is as follows: Figure 2 shown.

[0060] From the traditional soft service robot dialogue mode to the soft service robot dialogue mode based on dialogue state, in the case of the existing element E1 task-based dialogue algorithm, it is necessary to add some additional designs without changing the original algorithm, such as Figure 3 As shown, the method comprises the following steps:

[0061] Step S1: Constructing dialogue state elements:

[0062] This step is the core step of the present invention, and specifically provides a structured description of the dialog state in response to the needs of scene transition. The state abstract representation element is constructed according to the various parts in element E2.

[0063] (1) The intermediate results of the dialogue rely on the task-based dialogue algorithm of element E1, and mainly exist in the form of filled slots. When the dialogue state is awakened again, these results will be directly inherited by the next dialogue as part of the final result of the dialogue. The representation of the intermediate results of the dialogue should take into account all possible intermediate result forms, including but not limited to slot values, sensor switch control, and information query operations.

[0064] (2) The dialogue control flag takes the intermediate parameters of the task-based dialogue algorithm of element E1 as the basic starting point, and records the process that the task-based dialogue algorithm of element E1 is currently in each dialogue state storage. As the part of the dialogue state that controls the entire dialogue process, it is as simple as possible on the basis of accurately controlling the dialogue flow. When the scene changes and the dialogue state is awakened, the dialogue control flag is input into the algorithm as the initial value to reach the unfinished dialogue breakpoint.

[0065] (3) Device identification creates a unique ID for each device, with public terminals and private terminals using different identification methods. Public devices are pre-assigned device IDs, and the public device IDs remain unchanged unless the device IDs are updated. Private devices are not pre-assigned IDs, and IDs are assigned to devices when new private devices join the user's group.

[0066] (4) The state elimination mechanism is used to clean up unnecessary dialogue states. Common elimination mechanisms include processing expired states regularly according to time and processing states that reach the call threshold according to the number of calls. Developers can configure more than one state elimination mechanism for dialogue states based on the needs of the task-based dialogue algorithm itself and the actual situation.

[0067] (5) Status tagging creates a unique identifier for each conversation state that can be distinguished from other conversations. Common identifiers include date, time, conversation topic, etc., which jointly tag a conversation from multiple user-understandable dimensions. Users can find the expected conversation state by searching for the identifier.

[0068] In this step, the tasks built based on the dialogue state elements are mainly divided into five categories: 1) Interaction tasks: users and soft service robots interact with each other using voice as the medium; 2) Input and output processing tasks: extract valid information from user input and package the valid information into natural language output; 3) Log recording tasks: dependent on task 2) recording the dialogue between the user and the soft service robot, setting up logs for the dialogue to record; 4) State extraction tasks: extract the state corresponding to the current dialogue to ensure that the dialogue state will not be wrong or lost; 5) Scene recognition tasks: identify the current scene through the state id, determine whether the scene has changed, and realize the transfer of dialogue between multiple scenes; 6) External service provision tasks: meet the final needs of the dialogue by calling external service objects, and call external services in the most appropriate scene according to the scene recognition tasks.

[0069] Step S2: Design of dialogue log:

[0070] This step is the user interface of the dialogue state. After the scene is switched, the dialogue log is needed to help the user recall the previous dialogue. It is mainly used to remind the user which slots have been filled. The log record is designed for the dialogue intermediate result of step S1 to extract and store the dialogue for obtaining the slot value, and after the state is awakened, the stored extracted dialogue is restored to the user in a way that the user can understand.

[0071] Step S3: Design of state trigger mechanism:

[0072] This step, as the entry and exit of the process from normal dialogue to dialogue state, includes two state trigger mechanisms: dialogue state storage trigger mechanism and dialogue state awakening trigger mechanism. The two mechanisms are mostly set as keyword trigger and scene transfer trigger.

[0073] (1) When the conversation state storage mechanism is triggered, the entire conversation is extracted according to step S1 to extract the intermediate results and conversation control identifiers. At the same time, the extracted results are bound to the conversation logs up to this point and a unique tag is assigned to the conversation state. Finally, the conversation state and conversation logs are stored as a whole.

[0074] (2) When the dialogue state awakening mechanism is triggered, the soft service robot searches for the most appropriate state for the user based on the dialogue state tag. When the states are similar and cannot be distinguished by tags, the soft service robot provides the user with a dialogue log to help the user recall the dialogue process of how to reach the dialogue state.

[0075] Step S4: Expand the status-related dialogue process:

[0076] This step directly embeds the state transfer into the conversation process of the soft service robot. For each valid input of the user, the state trigger mechanism of step S3 is used to determine. If the state trigger mechanism is triggered, the conversation state processing related process is entered. If the state trigger mechanism is not triggered, the validity of the conversation is determined, and the valid input is written into the conversation log file according to step S2 for subsequent use.

[0077] Step S5: Dialogue state storage design:

[0078] This step is the last step of the multi-scenario soft service robot dialogue method based on state transfer. The dialogue state elements and dialogue logs are stored as a whole dialogue state. At the same time, all end devices jointly maintain a dialogue state tag list. Every time a new dialogue state is stored, the tag of the new state is added to the list. The process of waking up the state queries the user's expected wake-up state according to the state list. When the state is awakened, in addition to deleting the dialogue state itself, the tag corresponding to the state must also be deleted from the list.

Claims

1. A multi-terminal soft service robot dialogue state migration method, characterized in that The method comprises the following steps: Step S1: Constructing dialogue state elements: The dialogue state elements include the following three elements: Element E1, task-based dialogue algorithm; Element E2, state abstract representation element: including dialogue intermediate results, dialogue control identifier, device identifier, state elimination mechanism and state identifier; Element E3, state storage and wake-up mechanism; Step S2: Dialogue log design Adding a conversation log to the conversation process as a human interface for the conversation state is used to reasonably extract and encapsulate the conversation records, and to help users recall the conversation process that reached the current conversation state in the most effective way; Step S3: Design of state trigger mechanism The state trigger mechanism includes two trigger mechanisms: the dialog state storage trigger mechanism and the dialog state wake-up trigger mechanism. Among them: (1) When the conversation state storage mechanism is triggered, the intermediate results and conversation control identifiers of the entire conversation are extracted according to step S1. At the same time, the extracted results are bound to the conversation logs up to this point and a unique tag is assigned to the conversation state. Finally, the conversation state and conversation logs are stored as a whole. (2) When the dialogue state awakening mechanism is triggered, the soft service robot searches for the most appropriate state for the user based on the dialogue state tag. When the states are similar and cannot be distinguished by tags, the soft service robot provides the user with a dialogue log to help the user recall the dialogue process of how to reach the dialogue state. Step S4: Expanding the state-related dialogue process Each user input is judged twice: first, the state trigger mechanism of step S3 is used to make the first judgment to determine whether each input triggers the trigger mechanism of step S3. If it is triggered, the corresponding operation is performed according to step S3. If it is not triggered, the second judgment is made to determine the validity of each dialogue, and the valid input is written into the dialogue log according to step S2; Step S5: Dialogue state storage Each dialog state is given a unique tag and stored.

2. The multi-terminal soft service robot dialogue state migration method according to claim 1 is characterized in that The intermediate result of the conversation is used to record the results expressed by the user in the completed conversation and store the requirements that the user has put forward; The conversation control identifier is used to control the direction of the entire conversation and restore the conversation process to the state before the end after the conversation state is migrated; the device identifier is used to identify the device for the conversation and find the appropriate terminal device and initiate the request when the conversation requires the assistance of the terminal device; the state elimination mechanism is used to ensure that the conversation state does not accumulate and discard the unnecessary state when necessary; the state identifier is used to reasonably identify the state to facilitate the distinction and search for the corresponding appropriate state, giving the state a unique mark.

3. The multi-terminal soft service robot dialogue state migration method according to claim 1 or 2, characterized in that The dialogue intermediate result and dialogue control identifier are constructed in the following manner: Step S11: The intermediate result of the dialogue depends on the task-based dialogue algorithm of element E1. The requirements expressed by the user are stored in a suitable format. The result stored in this format is the intermediate result of the dialogue. The model includes the value of the user input content and the description of the type corresponding to the value. Step S12: The control of the dialogue process is based on the control mechanism of the task-based dialogue algorithm of element E1 itself. The part of the task-based dialogue algorithm of element E1 itself that controls the dialogue is stored in the form of parameters to obtain a dialogue control identifier of one of the elements E2 and used as an item of the dialogue abstract representation element. When a dialogue state is reawakened, the dialogue control identifier is input as a starting parameter to restore the dialogue state.

4. The multi-terminal soft service robot dialogue state migration method according to claim 1 is characterized in that The conversation records stored in the log include the main body of the conversation, and eliminate invalid conversations and conversations that have been covered. The conversation log should ensure that there are no contradictions between the recorded conversations and the abstract conversations, and can help users distinguish different states when the content of the states themselves is similar.

5. The multi-terminal soft service robot dialogue state migration method according to claim 1 is characterized in that The specific steps of step S5 are as follows: When the dialog state storage mechanism in step S3 is triggered, the dialog is abstractly extracted through the dialog control identifier in step S1, and when the dialog state is stored, a unique tag is added to each state, and the user finds the expected dialog state according to the tag.

Images