A dialogue management method and computer program product based on finite state machines

Abstract

The application provides a conversation management method and computer program product based on a finite state machine. The conversation management method comprises: receiving user input information; performing intent recognition on the user input information to determine user intent information; obtaining a pre-state in which a target task instance currently locates; determining a target transition rule matched with the query information from at least one transition rule; according to the target transition rule, transitioning from the pre-state to a target state of the target task instance, and responding in a response mode associated with the target transition rule, the response mode being one of at least one preset response mode, the at least one preset response mode comprising: outputting a preset first conversation text, and / or inputting a preset constraint prompt word and model input information into a large model to output a second conversation text by the large model. The conversation management method provided by the application limits the preset response mode within a preset range, and can ensure compliance of the conversation response.

Description

Technical Field

[0001] This invention relates to the field of human-computer interaction technology, and more specifically, to a dialogue management method and computer program product based on a finite state machine. Background Technology

[0002] With the rapid development of artificial intelligence technology, intelligent dialogue systems have been widely applied in customer service, marketing, government affairs, and other fields. Traditional intelligent dialogue systems sometimes employ hard-coded processes for flow control, using numerous if-else statements and other encoded data to determine user input and the next step. This approach suffers from poor flexibility, high maintenance costs, and excessively long business adjustment cycles when applied to complex business scenarios. Summary of the Invention

[0003] In order to at least partially solve the problems existing in the prior art, according to one aspect of the present invention, a dialogue management method based on a finite state machine is provided, the technical solution of which is as follows.

[0004] A finite state machine contains multiple states of a target task instance. A finite state machine defines at least one transition rule. The dialogue management method includes the following dialogue management operations:

[0005] Receive user input information;

[0006] Perform intent recognition on user input information to determine user intent information;

[0007] Get the current state of the target task instance;

[0008] From at least one transition rule, determine the target transition rule that matches the query information, which includes the previous state and user intent information.

[0009] According to the target transition rules, the current state is transitioned to the target state of the target task instance, and the response is made in accordance with the response method associated with the target transition rules.

[0010] The response method is one of at least one preset response method, which includes: outputting a preset first dialogue text, and / or inputting preset constraint prompts and model input information into the large model so that the large model outputs a second dialogue text, wherein the model input information includes user input information and / or user intent information.

[0011] For example, at least one preset response method also includes: performing a preset operation by calling an application programming interface.

[0012] For example, after responding according to the response method associated with the target transfer rule, the dialogue management method further includes:

[0013] Operation information corresponding to dialogue management operations is stored in global context information. Operation information includes one or more of the following: pre-state, user intent information, end marker corresponding to the target transfer rule, and user profile. The end marker is used to indicate that a response has been made to the target transfer rule. The user profile is obtained by calling the application programming interface to execute preset operations. The user profile includes user feature tags when the historical task instance was executed. The historical task instance and the target task instance are the same type of task instance.

[0014] The query information also includes at least some of the information from the global context information.

[0015] For example, the user intent information includes an intent identifier and task association parameters, which are parameters required for the execution of the target task instance. Each of the at least one transfer rule corresponds to a transfer condition, which includes one or more of the following requirements:

[0016] The user intent information matches the preset intent type;

[0017] Task-related parameters include parameters of preset types;

[0018] The global context information stores operation information of preset types;

[0019] The global context information does not store the end marker corresponding to the corresponding transition rule.

[0020] For example, user intent information includes intent identifier and task association parameters, where the task association parameters are the parameters required for the execution of the target task instance. Each of the at least one transfer rule corresponds to a transfer condition. Determining the target transfer rule that matches the query information includes:

[0021] Queries the transition rules that match the preceding state and intent identifier;

[0022] From the retrieved transfer rules, determine the target transfer rule. The target transfer rule is the transfer rule that meets the corresponding transfer conditions. The transfer conditions include the requirements corresponding to the task-related parameters, as well as the requirements corresponding to the information in the query information other than the previous state and user intent information.

[0023] For example, at least one transfer rule has a priority, and the target transfer rule is determined from the retrieved transfer rules, including:

[0024] The query retrieves the transfer rules in descending order of priority, and the first transfer rule that satisfies the corresponding transfer condition is taken as the target transfer rule.

[0025] For example, a finite state machine includes:

[0026] A set of states, which includes multiple states;

[0027] The set of trigger intents includes a variety of preset trigger intents;

[0028] A set of transfer rules, which includes at least one transfer rule;

[0029] The state set, trigger intent set, and transition rule set are all defined through a preset configuration file. Before the dialogue management operation, the dialogue management method also includes the following engine initialization operation:

[0030] Load the first preset configuration file that defines the set of states;

[0031] Load the second preset configuration file that defines the set of trigger intents;

[0032] Load the third preset configuration file that defines the set of transfer rules.

[0033] For example, the engine initialization operation also includes one or more of the following verification operations:

[0034] Verify whether each state in the verification state set, except for the termination state, can be transitioned to the next state through the transition rules. If each state can be transitioned to the next state through the transition rules, the first verification operation is determined to be successful; otherwise, the first verification operation is determined to be unsuccessful.

[0035] Starting from the initial state in the state set, each state is traversed forward along at least one transition path defined by a transition rule to determine the next state of each state, in order to verify whether there is an unreachable state in the state set. If there is, the second verification operation is determined to fail; otherwise, the second verification operation is determined to pass.

[0036] Verify that each transition rule in at least one transition rule corresponds to only one next state. If so, determine that the third verification operation passes; otherwise, determine that the third verification operation fails.

[0037] If a strongly connected component exists in the state set, the fourth verification operation is deemed to have failed; otherwise, the fourth verification operation is deemed to have failed.

[0038] Starting from the terminal state in the state set, each state is traversed in reverse along at least one transition path defined by a transition rule to determine the previous state of each state. If the traversed and determined states include all states in the state set except the terminal state, then the fifth verification operation is determined to pass; otherwise, the fifth verification operation is determined to fail.

[0039] The first, second, and third preset configuration files take effect when one or more verification operations pass.

[0040] For example, performing intent recognition on user input information to determine user intent information includes:

[0041] User input is fed into a natural language understanding model for intent recognition to determine user intent information;

[0042] The finite state machine includes a set of trigger intentions, which includes a variety of preset trigger intentions. Each trigger intention has one or more sets of keywords. The natural language understanding model is trained based on the keywords corresponding to each of the various trigger intentions, so that when the user input information contains keywords, the natural language understanding model can identify the user input information as a trigger intention corresponding to the keywords.

[0043] For example, at least one transfer rule includes a default transfer rule, the triggering intent defined by the default transfer rule being represented by a wildcard.

[0044] According to another aspect of the present invention, a dialogue management device based on a finite state machine is provided. The finite state machine includes multiple states and defines at least one transition rule. The dialogue management device includes:

[0045] The receiving module is used to receive user input information;

[0046] The recognition module is used to recognize the intent of user input information in order to determine the user's intent information;

[0047] The acquisition module is used to obtain the current state of the target task instance.

[0048] The determination module is used to determine the target transfer rule that matches the query information from at least one transfer rule. The query information includes the previous state and user intent information.

[0049] The transfer module is used to transfer from the current state to the target state of the target task instance according to the target transfer rules, and to respond according to the response method associated with the target transfer rules.

[0050] The response method is one of at least one preset response method, which includes: outputting a preset first dialogue text, and / or inputting preset constraint prompts and model input information into a large model so that the large model outputs a second dialogue text, wherein the model input information includes user input information and / or user intent information.

[0051] According to another aspect of the present invention, an electronic device is also provided, including a processor and a memory, wherein the memory stores computer program instructions, which, when executed by the processor, are used to perform any of the finite state machine-based dialogue management methods described above.

[0052] According to another aspect of the invention, a storage medium is also provided, on which program instructions are stored, wherein the program instructions, when executed, are used to perform any of the finite state machine-based dialogue management methods described above.

[0053] According to another aspect of the present invention, a computer program product is also provided, comprising computer program instructions that, when executed, perform any of the finite state machine-based dialogue management methods described above.

[0054] The dialogue management method based on finite state machines provided in this invention includes a finite state machine containing multiple states and defining at least one transition rule. According to the transition rule, a state can transition to another state, and a response can be made according to a response method associated with the transition rule. This response method is one of at least one preset response method, which includes outputting a preset first dialogue text and / or inputting preset constraint prompts and model input information into a large model so that the large model outputs a second dialogue text. In this finite state machine-based dialogue management method, the finite state machine can perform state transitions based on user input information. Each state transition performed by the finite state machine can be responded to with a preset response method, thereby advancing the dialogue process, shortening the number of dialogue rounds, and covering more business scenarios. This solution ensures that each dialogue stage corresponds to a clear state, and the transition conditions between states are clear and controllable, effectively solving the state tracking problem in multi-turn dialogues. Simultaneously, the preset response method is limited to a preset range, making the overall response deterministic, thus making the overall output more controllable, reducing the influence of artificial intelligence illusions, and effectively ensuring the compliance of dialogue responses.

[0055] A series of simplified concepts are introduced in the description of the invention, which will be further explained in detail in the detailed description section. This description is not intended to limit the key features and essential technical features of the claimed technical solution, nor is it intended to determine the scope of protection of the claimed technical solution.

[0056] The advantages and features of the present invention will be described in detail below with reference to the accompanying drawings. Attached Figure Description

[0057] The following figures are included as part of this invention for understanding its principles. The figures illustrate embodiments of the invention and their descriptions, serving to explain the principles of the invention. In the figures,

[0058] Figure 1 A flowchart illustrating the dialogue management operation in a finite state machine-based dialogue management method according to an exemplary embodiment of the present invention is shown.

[0059] Figure 2 A flowchart illustrating the dialogue management operation in a finite state machine-based dialogue management method according to an exemplary embodiment of the present invention is shown.

[0060] Figure 3 A schematic block diagram of a finite state machine-based dialogue management device according to an exemplary embodiment of the present invention is shown; and

[0061] Figure 4 A schematic block diagram of an electronic device according to an exemplary embodiment of the present invention is shown. Detailed Implementation

[0062] In the following description, numerous details are provided to enable a thorough understanding of the invention. However, those skilled in the art will appreciate that the following description merely illustrates preferred embodiments of the invention, and that the invention can be practiced without one or more of these details. Furthermore, to avoid obscuring the invention, some technical features well-known in the art have not been described in detail.

[0063] As mentioned above, some traditional intelligent dialogue systems employ hard-coded methods for process control. While this approach is maintainable when business logic is simple, the amount of code grows exponentially and maintenance costs rise sharply as business scenarios become more complex. This is especially true in enterprise applications, where dialogue flows often involve multi-turn interactions, complex business logic, and dynamic transition conditions. Traditional solutions face numerous challenges in handling these complex scenarios, including chaotic state management, difficulty in clarifying transition logic, long business adjustment cycles, and difficulty in guaranteeing process correctness. Furthermore, intelligent dialogue systems can also employ intent-slot-based dialogue management methods and deep learning-based end-to-end dialogue management methods, but these methods all have certain drawbacks. Intent-slot-based dialogue management methods advance dialogue by recognizing user intents and filling slots, but lack systematic modeling of multi-turn dialogue states, making it difficult to handle complex state dependencies and transition logic. Deep learning-based end-to-end dialogue management methods use neural networks (i.e., artificial intelligence models) to directly generate dialogue responses, but suffer from poor controllability and interpretability, making it difficult to guarantee the accurate execution and compliance of business logic.

[0064] To at least partially address the problems of chaotic state management, difficulty in handling complex state dependencies and transition logic, and poor controllability and interpretability due to artificial intelligence illusions in existing intelligent dialogue management methods, this invention provides a dialogue management method based on a finite state machine. This method can be applied to any electronic device with instruction execution capabilities, including but not limited to personal computers, servers, and mobile terminals. Any type of application with intelligent dialogue functionality can be deployed on the electronic device to implement the dialogue management method. Through the intelligent dialogue function, users can conduct business inquiries or transactions. The business described herein can be of any type and belong to any field. For example, the business can include, but is not limited to, order tracking, bank account opening, flight booking, smart home control, mobile phone package application, broadband package application, SIM card purchase, and number portability. A business can be represented by a task instance. Each task instance can correspond one-to-one with a dialogue instance, and different task instances can be processed through different dialogue instances. Each dialogue instance can have a corresponding dialogue identifier (i.e., dialogue ID), which distinguishes different dialogue instances. For example, each dialogue instance can correspond to a dialogue window; that is, opening a dialogue window can generate a new dialogue instance accordingly.

[0065] A Finite State Machine (FSM), as a computational model, can perform state transitions based on predefined states and according to transition rules. A FSM can contain multiple states (or state nodes) of a target task instance, and these states can be predefined. The target task instance is the task instance corresponding to the currently ongoing dialogue instance (which can be called the current dialogue instance). The multiple states can be different stages in the execution process of the target task instance, or they can be understood as different business nodes or stages in the target business processing process. For a dialogue management method based on a FSM, taking the dialogue process management in mobile phone package application as an example, the multiple states can include an initial state (e.g., START), an information collection state (e.g., INFO, collecting mobile phone numbers; ADDRESS, collecting addresses), a business processing state (e.g., PROFILE, querying user profiles; RESOURCE, verifying resources), a recommendation decision state (e.g., RECOMMEND, recommending a solution), a confirmation state (e.g., CONFIRM, confirming the application), and a termination state (e.g., END). A FSM can define at least one transition rule, which can be associated with the current state, input symbols, and transition conditions. When a finite state machine is in its current state, different input symbols are input. By combining the current state with the input symbols, at least one transition rule can be determined that matches both the current state and the input symbols. Among these at least one transition rule, the one whose associated transition condition is satisfied can be used as the target transition rule. The transition from the current state to the next state can be completed according to the target transition rule. For ease of description and distinction, the process of the current state transitioning to the next state according to the target transition rule can be considered as the previous state transitioning to the target state according to the determined target transition rule (i.e., the current state is considered the previous state). For example, the process of the previous state transitioning to the target state according to the determined target transition rule may include exiting the previous state and entering the target state. Here, the input symbols of the finite state machine can be considered as one of the conditions triggering state transitions, and the input symbols can be defined as needed. In the dialogue management method according to embodiments of the present invention, the input symbols can be user intent information. For example, the input symbols may include a set of trigger intents, which may include a variety of preset trigger intents, as will be described in detail below.

[0066] Figure 1 A flowchart illustrating the dialogue management operation in a finite state machine-based dialogue management method according to an exemplary embodiment of the present invention is shown. Figure 1 As shown, the dialogue management method based on finite state machines includes dialogue management operations, which include the following steps S10, S20, S30, S40 and S50.

[0067] Step S10: Receive user input information. User input information can be natural language input, including but not limited to text input and / or voice input. User input information can describe the user's intent in the dialogue. It is understood that in dialogue flow management, the user's intent can be related to the execution of a target task instance, such as the processing of a certain business. In this case, the user input information will also be roughly related to the business processing. Therefore, the user input information can actually be within a predictable range, which can be related to the domain of the dialogue flow. For example, in a dialogue flow related to mobile phone plan processing, taking the initial user input information as an example, the user input information might be: "Apply for a plan," "Mobile phone plan," "Get a mobile phone plan," etc. Although these user input information differ in natural language expression, they contain similar meanings and have similar purposes. Therefore, it can be considered that these user input information are actually within a certain range and have the same intent.

[0068] Step S20: Perform intent recognition on the user input information to determine the user's intent information. For example, this can be done using a Natural Language Understanding (NLU) model or any other suitable existing or future intent recognition method. Intent recognition allows for the determination of user intent information based on the input information. Intent recognition can be understood as identifying the intent within the user input information, that is, identifying the intent in the user's dialogue. Similarly, compared to the user input information itself, the user intent information determined through intent recognition can be within a smaller range. This is because user input information with similar purposes can be identified as having the same or similar user intent information after intent recognition. For example, still using a dialogue process related to mobile phone plan subscription, user input information such as "subscribe to a plan," "mobile phone plan," and "get a mobile phone plan" can all be identified as "subscribe to a plan" after intent recognition. In other words, intent recognition can transform user input information, thereby converting it into user intent information within a preset, limited range. User intent information can serve as the triggering intent mentioned above. In other words, user intent information can serve as the input symbol for a finite state machine. The finite state machine can have transition rules that match the user intent information, and the user intent information can serve as one of the conditions for triggering state transitions.

[0069] Step S30: Obtain the current preceding state of the target task instance. The preceding state can refer to the state before each state transition. The preceding state obtained in step S30 is the current state of the target task instance. The preceding state can be the initial state in a finite state machine, or it can be the target state of the previous state transition in the finite state machine. For example, for a finite state machine with extended history functionality, obtaining the preceding state can be based on the history of the finite state machine. In some embodiments, the preceding state can also be obtained from the context information of the current dialogue instance.

[0070] Step S40: From at least one transition rule, determine the target transition rule that matches the query information, where the query information includes the preceding state and user intent information. For example, a state transition rule table can be pre-constructed, which may include query information and transition rules. A lookup in the table can determine the target transition rule that matches the query information. Of course, the state transition rule table is optional; other forms (such as key-value pairs) can be used to store the relationship between the query information and the transition rules. The query information may only include the preceding state and user intent information, or it may include the preceding state, user intent information, and other information. Therefore, based on the preceding state and user intent information, at least one matching query information can be obtained. A lookup in the table based on this at least one query information can determine at least one transition rule. Subsequently, the at least one transition rule can be filtered based on the portion of the query information excluding the preceding state and user intent information to determine the target transition rule.

[0071] When the query information only includes the preceding state and user intent information, the target transfer rule can be determined by looking up the table based on the preceding state and user intent information.

[0072] When the query information includes other information besides the preceding state and user intent information, at least one matching transition rule is determined based on the preceding state and user intent information. Then, by combining the other information in the query information (excluding the preceding state and user intent information) with the transition conditions, the at least one transition rule is filtered to determine the target transition rule. For example, to facilitate the filtering of at least one transition rule, a pre-constructed state transition rule table can include the preceding state, user intent information, transition conditions, and transition rules. By looking up the table, it is easier and more direct to determine whether the other information in the query information (excluding the preceding state and user intent information) meets the transition conditions. If the other information in the query information (excluding the preceding state and user intent information) meets the transition conditions, the target transition rule can be determined accordingly.

[0073] Step S50: According to the target transition rule, transition from the previous state to the target state of the target task instance, and respond according to the response method associated with the target transition rule. The response method is one of at least one preset response method, which includes: outputting a preset first dialogue text, and / or inputting preset constraint prompts and model input information into the large model so that the large model outputs a second dialogue text. The model input information includes user input information and / or user intent information. The response method can be associated with the transition rule. After determining the target transition rule, state transition can be performed according to the target transition rule to respond according to the response method associated with the target transition rule. Since the response method is associated with the transition rule, and the target transition rule is determined by the query information, the response method associated with the target transition rule can be related to the query information. Thus, the response is related to the query information, and since the query information includes user intent information, the response can be related to the user intent information, which facilitates the advancement of the dialogue process with the user. Moreover, as mentioned above, user intent information can be determined within a certain range; therefore, the related response can also be determined within a certain range, so at least one preset response method can be preset within a certain range.

[0074] The response method is one of at least one preset response method, that is, one of the at least one preset response methods is selected as the response method in step S50. At least one preset response method may include outputting a preset first dialogue text (which may be referred to as the first response method), or inputting preset constraint prompts and model input information into a large model so that the large model outputs a second dialogue text (which may be referred to as the second response method), or simultaneously including both outputting the preset first dialogue text and inputting preset constraint prompts and model input information into a large model so that the large model outputs the second dialogue text. At least one preset response method may only include the aforementioned first response method and / or second response method, or may further include other response methods besides the first and second response methods, such as performing preset operations by calling an Application Programming Interface (API).

[0075] The preset first dialogue text is a fixed, pre-defined dialogue text. For example, the preset first dialogue text could be: "What's your phone number? Let me check for you," "Please tell me your specific needs for the plan," or any other suitable dialogue text. For instance, taking a dialogue process related to mobile phone plan application as an example, the user input information could be "apply for a plan." After performing intent recognition on the user input information, the determined user intent information could be "apply for a plan." At this point, the obtained prior state could be, for example, the initial state. Based on the query information containing the prior state and user intent information, a target transition rule can be determined. The response method associated with this target transition rule could be, for example, outputting the preset first dialogue text, such as "What's your phone number? Let me check for you." This allows the dialogue process regarding applying for a plan to proceed.

[0076] A trained large model can output corresponding dialogue text based on user input and / or user intent. However, the aforementioned "AI illusion" problem may occur when the large model outputs dialogue text. To constrain the dialogue text output by the large model within a certain range, preset constraint prompts can be input as constraints along with the model's input information. These preset constraint prompts can be related to a preset range of the second dialogue text, thus constraining the second dialogue text within a certain range. This ensures that when the preset constraint prompts are input as constraints, the large model can output the preset second dialogue text. When the preset constraint prompts are input as constraints for the large model to output the second dialogue text, the output of the large model will be within the preset range of the second dialogue text because the preset constraint prompts are used as constraints. In this case, the output of the large model is similar to selecting from the preset second dialogue text, thus reducing the probability of the large model exhibiting AI illusion and ensuring the compliance of the dialogue process. For example, in a dialogue process related to mobile phone plan application, during the plan recommendation stage, the user input information could be "100GB of data". After intention recognition of the user input information, the determined user intention information could be "expression of needs". The preceding state obtained at this time could be, for example, "plan application". Based on the query information composed of the preceding state and user intention information, a target transfer rule can be determined. The response method associated with the target transfer rule could be, for example, inputting a preset constraint prompt as a constraint condition along with the model input information into the large model so that the large model outputs a second dialogue text. The preset prompt could be, for example, "100GB". Such a preset prompt can limit the second dialogue text to a certain range. The second dialogue text output after constraint can be a dialogue text recommending different plans. By using the preset prompt as a constraint condition to constrain the large model, the second dialogue text output by the large model could be, for example, a plan with at least 100GB of data.

[0077] As mentioned above, in addition to the two preset response methods, at least one preset response method may also include any other suitable response method, and this application does not limit this.

[0078] Taking the dialogue management method provided by this invention applied to a telecommunications service hall as an example, this invention can handle services such as mobile phone package application, broadband application, SIM card purchase, and number portability. First, a finite state machine is designed. A finite state machine can be defined as a five-tuple model, which is a five-tuple model of a set of states, an input alphabet, a state transition function, an initial state, and a final state. The state set of the finite state machine can include multiple states of the target task instance, such as an initial state (e.g., START), an information collection state (e.g., INFO, collecting phone numbers; ADDRESS, collecting addresses), a service processing state (e.g., PROFILE, querying user profiles; RESOURCE, verifying resources), a recommendation decision state (e.g., RECOMMEND, recommending a solution), a confirmation state (e.g., CONFIRM, confirming the processing), and a final state (e.g., END). The input alphabet of a finite state machine (FSM) can be a set of input symbols. Taking user intent as an example, an NLU model can identify the intent of user input. The input alphabet can include user intent information obtained by the NLU model. This user intent information can be represented by intent identifiers, and each user intent information can have one or more corresponding keywords. The NLU model is trained based on the keywords corresponding to each of the multiple user intent information, so that when the user input information contains keywords, the NLU model can identify the user input information as user intent information corresponding to the keywords. For example, the input alphabet can include the following intent identifiers: Package (corresponding user intent information could be "subscribe to a package," and triggering keywords could include "package," "subscribe," "subscribe to a package"), Broadband (corresponding user intent information could be "subscribe to broadband," and triggering keywords could include "broadband," "install broadband"), Phone (corresponding user intent information could be "provide a mobile phone number"), Agree (corresponding user intent information could be "agree," and triggering keywords could include "okay," "can," "agree"), Refuse (corresponding user intent information could be "refuse," and triggering keywords could include "don't want," "never mind"). The state transition function of the finite state machine can represent a set of transition rules, which can be associated with the previous state, input symbols, and transition conditions. The initial state of a finite state machine can be the state at the start of the dialogue instance corresponding to the target task instance, such as START. The final state of a finite state machine can be the state at the end of the dialogue instance corresponding to the target task instance, such as END.

[0079] In a finite state machine, the set of states can include the following states:

[0080] START: Initial state; INFO: Information collection state (collecting user mobile phone numbers); PROFILE: User profile query state (calling API to query user information); PACKNEED: Package demand collection state (collecting user's demand for data, voice, and pricing); RECOMMEND: Package recommendation state (recommending packages based on demand); CONFIRM: Confirmed application state; ADDRESS: Address collection state (required for broadband service); RESOURCE: Resource verification state (checking if the address has broadband resources); END: Normal termination state; CANCEL: Cancelled application state.

[0081] Of course, the above states are just examples, and a finite state machine can include various other suitable states.

[0082] The input alphabet (intent set) can include the following intents:

[0083] Package: Intent to subscribe to a package service; triggering keywords include "package", "subscribe", "subscribe to a package"; Broadband: Intent to subscribe to broadband; triggering keywords include "broadband", "install broadband"; Phone: Intent to provide a mobile phone number; 11-digit number identified through regular expressions; Need: Intent to express needs; user describes specific needs (e.g., "need 100GB of data"); Agree: Intent to agree; triggering keywords include "okay", "okay", "agree"; Refuse: Intent to refuse; triggering keywords include "no", "never mind".

[0084] Similarly, the above intention is merely an example, and various other suitable input symbols can be included in a finite state machine.

[0085] The state transition function of a finite state machine can include a state transition rule table, as shown below as an example:

[0086] START Package user_profile is None INFO What is your China Unicom mobile number? Let me check it for you. INFO Phone The length of phone_number is 11. PROFILE Call the API to query user profiles PROFILE * user_profile is not None PACKNEED Please tell me your specific needs for the package. PACKNEED Need True RECOMMEND Calling large model recommendation package RECOMMEND Agree True CONFIRM "Okay, please confirm the processing information." RECOMMEND Refuse True END Okay, please feel free to contact me if needed. START Broadband Address not provided ADDRESS "Which neighborhood would you like to subscribe to for broadband?" ADDRESS Address Address provided RESOURCE Call the API to verify the address resource

[0087] like Figure 2The diagram illustrates a flowchart of a dialogue management method according to an embodiment of the present invention. A dialogue instance corresponding to a target task instance can begin with user input. The user input information can be used by an NLU model for intent recognition. During intent recognition, the NLU model can perform natural language input mapping on the user input information (which, as mentioned above, can be natural language input), i.e., perform natural language mapping to obtain user intent information. User intent information can include an intent identifier and / or related parameters; for example, user intent information represented by an intent identifier can be obtained. User intent information can be input as an input symbol into a finite state machine engine. After the finite state machine obtains the current state of the target task instance, at least a portion of the query information can be composed of the current state and the user intent information. At least one transition rule can be obtained based on the current state and user intent information in the query information. Subsequently, transition conditions can be evaluated to determine the target transition rule. Evaluating transition conditions refers to the situation where the query information includes other information besides the current state and user intent information. Based on this, the other information in the query information, along with the transition conditions, is used to filter at least one transition rule to determine the target transition rule. Once the target transition rule is determined, the state transition can be executed. For example, in a single state transition, the exit from the pre-state action can be performed first, followed by the state transition action, and finally the entry into the target task instance's target state action. Optionally, after entering the target task instance's target state action, the current state can be updated, i.e., the relevant operation information can be stored in the global context information. This will be described in detail below and will not be repeated here. After the state transition is complete, a response type determination can be performed. The response type can be associated with the transition rule, meaning a response can be made according to the response method associated with the target transition rule. The response method can be one of at least one preset response method, as shown in the figure, which illustrates three exemplary preset response methods. Based on the response method determined according to the target transition rule, a response can be returned to the user to advance the dialogue instance. After returning the response to the user, the global context information can also be updated. Then, it can be determined whether a termination state has been reached, i.e., whether the target state in this state transition is a termination state. If so, the dialogue instance ends in the termination state; otherwise, it waits for the next round of input. In the next round of input, a new loop begins with user input.

[0088] The dialogue management method based on finite state machines provided in this invention includes a finite state machine containing multiple states and defining at least one transition rule. According to the transition rule, a state can transition to another state, and a response can be made according to a response method associated with the transition rule. This response method is one of at least one preset response method, which includes outputting a preset first dialogue text and / or inputting preset constraint prompts and model input information into a large model so that the large model outputs a second dialogue text. In this finite state machine-based dialogue management method, the finite state machine can perform state transitions based on user input information. Each state transition performed by the finite state machine can be responded to with a preset response method, thereby advancing the dialogue process, shortening the number of dialogue rounds, and covering more business scenarios. This solution ensures that each dialogue stage corresponds to a clear state, and the transition conditions between states are clear and controllable, effectively solving the state tracking problem in multi-turn dialogues. Simultaneously, the preset response method is limited to a preset range, making the overall response deterministic, thus making the overall output more controllable, reducing the influence of artificial intelligence illusions, and effectively ensuring the compliance of dialogue responses.

[0089] For example, at least one preset response method further includes: performing a preset operation by calling an Application Programming Interface (API). Various preset operations can be implemented by calling the API; the preset operation performed by calling the API could be, for example, querying a user profile, verifying address resources, or any other suitable operation. When at least one preset response method includes calling an API to perform a preset operation, this approach can cover more business scenarios, thereby broadening the applicability of the dialogue management method.

[0090] For example, after responding according to the response method associated with the target transition rule, the dialogue management method further includes: storing the operation information corresponding to the dialogue management operation in the global context information, the operation information including one or more of the following: pre-state, user intent information, end marker corresponding to the target transition rule, and user profile.

[0091] An end marker is used to indicate that a response has been made to the target transition rule. The end marker indicates that the current state transition is complete, and the current target state can serve as the prerequisite state for the next state transition. The end marker indicating a response to the target transition rule means that the state transition based on the currently determined target transition rule has been completed and has been responded to using the response method associated with the target transition rule. Taking a dialogue process related to mobile phone plan subscription as an example, the user input information could be "subscribe to a plan." Intent recognition is performed on the user input information, determining the user's intent as "subscribe to a plan." At this point, the prerequisite state can be the initial state. A target transition rule matching the existing query information is determined, and the system transitions from the prerequisite state to the target state according to the target transition rule. That is, from the initial state to the state corresponding to the first business node of the plan subscription (i.e., the target state of this state transition). At this point, a response can be made according to the response method associated with the target transition rule. For example, it could output a preset first dialogue text, such as "What is your mobile phone number? Let me check for you." After the entire state transition process is completed, the end marker corresponding to this entire process can be stored in the global context information. The global context information here refers to the context information corresponding to the current dialogue instance, which is also the context information corresponding to the target task instance. Each dialogue instance has its own global context information, and when a new dialogue instance is generated, its corresponding global context information can be generated accordingly.

[0092] User profiles are obtained by calling an Application Programming Interface (API) to perform a preset operation, which is called querying the user profile. The user profile includes user feature tags from historical task instances, where the historical and target task instances are of the same type. For example, both the historical and target task instances might correspond to mobile phone plan subscription services. User feature tags are labels formed by extracting user characteristics, preferences, and other features into structured data. The statistical source of the user profile can be the user currently engaged in the conversation, other users besides the current user, or a combination of the current user and other users. User profiles can be obtained, for example, by calling the API to query big data, or by calling the API to query historical transaction records. Taking mobile phone plan subscription as an example, the user profile can include feature tags from previous mobile phone plan subscriptions, such as the user's preferences when choosing among available plans when subscribing to similar plans last time. Based on the user feature tags from historical task instances, it is possible to help determine the user's preferences when choosing similar services, thus providing guidance for subsequent plan recommendations.

[0093] The query information also includes at least a portion of the global context information. When the query information includes at least a portion of the global context information, the target transition rule determined based on the query information can have a certain correlation with the global context information. In this way, when transitioning from a previous state to a target state according to the target transition rule, that is, from one business node to the next business node in the entire dialogue process, this process is more closely related to the entire dialogue process. The response made by the response method associated with the target transition rule can also be more in line with the entire dialogue process, which can further improve dialogue efficiency and shorten the number of dialogue rounds in the dialogue process.

[0094] For example, the query information may include an end marker from the global context information. When matching transition rules based on the prior state and user intent information, multiple transition rules may match. In this case, the transition rules that have already been responded to can be further excluded based on the end marker in the query information to avoid a dialogue loop and thus further improve dialogue efficiency. In some cases, after determining the target transition rule based on the prior state and user intent information, and responding in a pre-defined manner to advance the dialogue flow, the response may not meet the user's needs, and user input information such as rejection may be received. In this case, the corresponding end marker can be stored in the global context information. Then, based on the same prior state and user intent information, and by excluding the transition rules that have already been responded to using the end marker in the query information, a target transition rule that better meets the user's expectations can be determined, and finally, the response can be delivered in a manner that meets the user's expectations.

[0095] For example, the query information may include user profiles from the global context information. Target transfer rules are determined based on the query information, and the response method associated with the target transfer rule can refer to the user profile. For instance, in the service processing stage of package recommendation, the target transfer rule is determined based on the query information. The response method associated with the target transfer rule is to input preset constraint prompts and model input information into the large model, which then outputs a second dialogue text. This second dialogue text can be dialogue text related to the recommended package. Since the query information includes user profiles from the global context information, and user profiles can guide package recommendations, the second dialogue text output by the large model can better meet the user's needs when recommending packages. This further shortens the dialogue process.

[0096] For example, user intent information includes intent identifiers and task-related parameters. Intent identifiers are used to distinguish and mark different intents. For example, intent identifiers can be text, letters, numbers, symbols, or any other suitable form. Intent identifiers can summarize the content of user intents, serving as input symbols and reducing the computational load of the finite state machine. For instance, as mentioned above, determining the user intent information as "package application" can be represented by "package application." For example, when the user intent is to apply for a package, after intent recognition of the user input information and determination of the intent information, the intent identifier can be "Package." Each of the multiple states corresponds to an execution stage (i.e., a business node) of the target task instance, and the task-related parameters are the parameters required for the execution of the target task instance. During the execution of the target task instance, there may be a stage where information is requested from the user. For example, during the application for a mobile phone package, the user's mobile phone number needs to be asked. Based on this request, the user enters their mobile phone number. When performing intent recognition on such user input information, it can be determined that the user intent information includes task-related parameters. Of course, the mobile phone number used here as a task association parameter is just an example. Depending on the business corresponding to the target task instance, the task association parameter can be any parameter required during the execution of the target task instance. For example, the task association parameter can also be address information, etc.

[0097] Each of the at least one transfer rule corresponds to a transfer condition, which includes one or more of the following requirements: the user intent information conforms to a preset intent type; the task association parameters contain parameters of a preset type; the global context information stores operation information of a preset type; and the global context information does not store an end marker corresponding to the corresponding transfer rule. When determining the target transfer rule based on the query information, at least one transfer rule can be determined first based on the preceding state and user intent information, and then the target transfer rule can be determined from the at least one transfer rule using the transfer conditions corresponding to each of the at least one transfer rule.

[0098] For example, the transfer condition may include user intent information conforming to a preset intent type. In this case, after determining at least one transfer rule based on the prior state and user intent information, the transfer rule where the user intent information conforms to the corresponding preset intent type can be determined as the target transfer rule. The user intent information may include an intent identifier. When determining whether the user intent information conforms to the preset intent type, the intent identifier in the user intent information can be identified, and it can be judged whether the intent identifier conforms to the preset type.

[0099] For example, the transfer condition may include a task-related parameter containing a preset type. In this case, the user intent information may include the task-related parameter. After determining at least one transfer rule based on the prior state and the user intent information, the transfer rule whose type of the task-related parameter matches the corresponding preset type can be determined as the target transfer rule. The transfer condition in this embodiment can be considered as a parameter integrity condition. For example, the preset type of the parameter in the transfer condition may include a mobile phone number. When the task-related parameter is a mobile phone number, the task-related parameter matches the preset type. The preset type of the parameter in the transfer condition may also include multiple preset types. For example, in the process of broadband application, the transfer condition may include two types of parameters: mobile phone number and address information. When the task-related parameter includes both mobile phone number and address information, the task-related parameter matches the preset type. For example, the judgment on whether the task-related parameter matches the preset type may only be based on the parameter type. For example, only the judgment on whether the string of numbers contained in the task-related parameter belongs to a mobile phone number may be performed, without focusing too much on the content of the task-related parameter itself, such as not focusing on the specific mobile phone number. Based on such a transfer condition for judging parameter integrity, it is possible to check whether the necessary parameters in the execution process of the target task instance have been collected.

[0100] For example, transition conditions may include the global context information storing operation information of a preset type. For example, the preset type of operation information may be a user profile or a specific prior dialogue management operation. A prior dialogue management operation may refer to a dialogue management operation performed before the current state transition, in which a state transition may have occurred. Before the next state transition, necessary parameter collection and / or necessary prior dialogue management operations may be performed. It is understood that the prior dialogue management operations mentioned here are relative to the next state transition. Taking the preset type of operation information including a user profile as an example, when the next state transition requires the user profile, the transition condition matching the next state transition may include the global context information storing the user profile. Such a transition condition is equivalent to performing parameter integrity verification. To ensure that the global context information stores the user profile, the prior dialogue management operation before the next state transition may include a prior dialogue management operation whose response method is to call an API to perform a preset operation. This preset operation may be retrieving the user profile. After performing such a prior dialogue management operation, the user profile can be stored in the global context information. For example, the response in the next state transition is to output a preset first dialogue text, such as "Okay, please confirm the processing information." In the next state transition, the user actually needs to confirm the processing package. Before this, a prior dialogue management operation to recommend a package to the user needs to be performed. This means that the response method involves inputting preset constraint prompts and model input information into a large model, which then outputs a second dialogue text. This second dialogue text can be associated with recommending a package to the user. The transition conditions include storing preset types of operation information in the global context information. This ensures the logical consistency between global dialogue contexts during the execution of the target task instance, avoiding omissions in the progress of the target task instance, such as avoiding the omission of collecting certain parameters. This makes the dialogue flow more compliant during the execution of the target task instance.

[0101] For example, a transition condition may include the absence of an end marker corresponding to the transition rule stored in the global context information. In this case, when the target transition rule is about to be determined based on the query information, it is necessary to ensure that the target transition rule has not been executed in the global context information, thus avoiding dialogue loops and repeated execution of the same response.

[0102] The above requirements can exist individually or multiple times simultaneously in the transfer conditions. When multiple requirements exist simultaneously in the transfer conditions, the transfer conditions are determined to be met when all requirements are satisfied, and the corresponding transfer rules are matched with the query information.

[0103] For example, the user intent information includes an intent identifier and task association parameters, where the task association parameters are those required for the execution of the target task instance, and each of the at least one transfer rule corresponds to a transfer condition. Determining the target transfer rule that matches the query information includes:

[0104] Step S41: Query the transition rules that match the preceding state and intent identifier.

[0105] For example, an index can be created based on the preceding state and intent identifier, such as a hash index. This index allows for quick retrieval of transition rules that match the preceding state and intent identifier. The retrieved transition rules can be at least one; for example, one transition rule, two transition rules, or any other suitable number of transition rules can be retrieved.

[0106] Step S42: From the retrieved transition rules, determine the target transition rule. The target transition rule is the transition rule that satisfies the corresponding transition conditions. The transition conditions include requirements corresponding to the task-related parameters and requirements corresponding to information in the query information other than the pre-state and user intent information. Since the pre-state and user intent information have already been used to query and match the transition rules in step S41, the transition conditions here do not need to judge the pre-state and user intent information, thus reducing the computational burden of the finite state machine.

[0107] Determining the target transfer rule based on the above steps S41 and S42 can be faster, require less computation, and have a lower latency in dialogue response.

[0108] For example, at least one transfer rule has its own priority, which can be determined according to the actual business scenario. Determining the target transfer rule from the queried transfer rules includes step S421: traversing the queried transfer rules in descending order of priority, and selecting the first transfer rule that satisfies the corresponding transfer condition as the target transfer rule. After querying at least one transfer rule that matches the preceding state and intent identifier, the at least one transfer rule can be arranged in descending order of priority. Subsequently, all queried transfer rules can be traversed in descending order of priority, and the first transfer rule that satisfies the corresponding transfer condition can be selected as the target transfer rule. This can further reduce computational load, lower dialogue response latency, and improve dialogue response speed. Moreover, this avoids the problem of difficulty in determining the target transfer rule when the transfer conditions of multiple transfer rules are met, or the problem of contradictions when multiple selections are made.

[0109] For example, a finite state machine may include a set of states, a set of triggering intentions, and a set of transition rules. The set of states may include multiple states, each of which may correspond to an execution stage of a target task instance, i.e., a business node of the target business. The set of triggering intentions may include various preset triggering intentions. Triggering intentions may include, for example, user intent information; further, triggering intentions may include, for example, intent identifiers, task-related parameters, and other input symbols of any suitable form. The set of transition rules may include at least one transition rule, which may be associated with a state in the set of states and a triggering intention in the set of triggering intentions. A transition rule may also have a transition condition; for a transition rule associated with a state and a triggering intention, and also having a transition condition, the state, triggering intention, and transition condition must all match before the transition rule can be executed.

[0110] The state set, trigger intent set, and transition rule set can all be defined through a preset configuration file. Before the dialogue management operation, the dialogue management method also includes an engine initialization operation, which includes the following steps S01, S02, and S03.

[0111] Step S01: Load the first preset configuration file that defines the set of states;

[0112] Step S02: Load the second preset configuration file that defines the set of trigger intents;

[0113] Step S03: Load the third preset configuration file that defines the set of transfer rules.

[0114] After the engine initialization is complete, dialogue management operations can be performed.

[0115] For example, in the second preset configuration file that defines the set of triggering intents, each triggering intent in the set of triggering intents can have a corresponding second preset configuration file. For the second preset configuration file corresponding to the triggering intent "package application", it can include: intent identifier (Package), intent number (intent_id, which can be defined according to actual needs, for example, it can be Package), intent name (intent_name, which can be package application), keywords (keywords, which can include "package", "application", "apply for package"), and priority (priority, which can be defined according to actual needs). For the second preset configuration file corresponding to the triggering intent "provide mobile phone number", it can include: intent identifier (Phone), intent number (intent_id, which can be defined according to actual needs, for example, it can be Phone), intent name (intent_name, which can be provide mobile phone number), regular expression (regex, which can be "1[3-9]\\d{9}"), parameter name (params, which can include "phone_number", "11-digit mobile phone number"), and priority (priority, which can be defined according to actual needs).

[0116] For example, in the third preset configuration file defining the set of transition rules, a corresponding third preset configuration file can be defined for each transition rule in the set. For a state transition rule from the initial state to the information collection state, the corresponding third preset configuration file may include: a pre-stage (prev_stage, which can be START), a trigger intent (intent, which can be Package), a transition condition (condition, which can be "user_profileis None"), a target state (next_stage, which can be INFO), a priority (which can be defined according to the actual situation), and a response (which can be outputting a preset first dialogue text, such as outputting "What is your phone number? Let me check it for you"). For a state transition rule from the information collection state to the user profile query state, the corresponding third preset configuration file may include: a pre-stage (prev_stage, which can be INFO), a trigger intent (intent, which can be Phone), and a transition condition (condition, which can be "params.get('phone_number') is not..."). The third preset configuration file can include: "None", target state (next_stage, which can be PROFILE), priority (which can be defined according to the actual situation), and preset action (action, which can be "query_user_profile"). For the state transition rule from the package recommendation state to the confirmation processing state, the corresponding third preset configuration file can include: prev_stage (prev_stage, which can be RECOMMEND), trigger intent (intent, which can be Agree), transition condition (condition, which can be "True"), target state (next_stage, which can be CONFIRM), priority (which can be defined according to the actual situation), and response method (response, which can be outputting the preset first dialogue text, such as outputting "Okay, please confirm the processing information").

[0117] By defining state sets, trigger intent sets, and transition rule sets in configuration files, the configuration files can be directly modified according to the actual business process to change the overall dialogue flow of the dialogue management method, thus reducing the overall maintenance cost. Moreover, configuration file modifications can take effect immediately through configuration hot updates, significantly reducing the response time for overall business process modifications. Through the related design of configuration management, it can support historical tracing, difference comparison, and fast rollback of configuration files. When applied to specific applications, it can also support canary releases based on user groups.

[0118] For example, the engine initialization operation also includes one or more verification operations, wherein the first preset configuration file, the second preset configuration file, and the third preset configuration file take effect when one or more verification operations pass.

[0119] The first verification operation verifies whether every state in the state set, except the terminating state, can transition to the next state through the transition rules. If every state can transition to the next state through the transition rules, the first verification operation is considered successful; otherwise, it is considered unsuccessful. When the first verification operation is confirmed to be successful, every state in the state set, except the terminating state, has at least one relevant transition rule that can be executed to transition to the next state. The first verification operation can be considered an integrity verification. When the first verification operation is confirmed to be successful, every non-terminating state has at least one exit path. The first verification operation can prevent deadlock in the finite state machine.

[0120] The second verification operation: Starting from the initial state in the state set, traverse each state forward along at least one transition path defined by a transition rule to determine the next state for each state. This verifies whether there are any unreachable states in the state set. If an unreachable state exists, the second verification operation fails; otherwise, it passes. In the second verification operation, a breadth-first search algorithm can be used to traverse all reachable states and check for unreachable states (i.e., isolated state nodes). A reachable state is defined as a state that can be reached from the initial state through a finite number of state transitions; otherwise, it is an unreachable state. The second verification operation can be considered a reachability verification. When the second verification operation passes, every state in the finite state machine's state set is reachable.

[0121] The third verification operation verifies whether each transition rule in at least one transition rule corresponds to only one next state. If so, the third verification operation passes; otherwise, it fails. A failure indicates that for the same state, based on the same transition rule (i.e., the preceding state, triggering intent, and transition condition are all identical), there are at least two target states, resulting in a conflict between them. A passing third verification operation means that for the same state, based on the same transition rule (i.e., the preceding state, triggering intent, and transition condition are all identical), there is only one target state. The third verification operation can be considered deterministic, preventing transition conflicts.

[0122] The fourth verification operation checks if a strongly connected component exists in the state set. If it does, the fourth verification operation fails; otherwise, it fails. Strongly connected components can be detected using a depth-first search algorithm, such as Tarjan's algorithm. When a strongly connected component exists in the state set, the two strongly connected states can transition between each other, which may lead to an inescapable loop during a single state transition. The fourth verification operation can be considered a deadlock detection mechanism, preventing the state transition from entering an inescapable loop.

[0123] The fifth verification operation: Starting from the terminal state in the state set, traverse each state backwards along at least one transition path defined by a transition rule to determine the previous state of each state. If the determined states include all states in the state set except the terminal state, the fifth verification operation is considered successful; otherwise, it is considered unsuccessful. The fifth verification operation can be considered a termination verification. It ensures that each state can transition to the terminal state after a finite number of state transitions, thus ensuring that the overall dialogue flow will not get stuck in a loop and cannot end.

[0124] For example, performing intent recognition on user input information to determine user intent information includes:

[0125] Step S21: Input the user input information into the Natural Language Understanding (NLU) model for intent recognition to determine the user's intent information;

[0126] The finite state machine includes a set of triggering intentions, which includes a variety of preset triggering intentions. These triggering intentions may include, for example, user intent information, and further, intent identifiers, task-related parameters, and other suitable input symbols. Each triggering intention has one or more sets of keywords. For example, keywords may be related to the intent to subscribe to a package, such as "package," "subscribe," or "get a package"; keywords may be related to the intent to agree, such as "okay," "can," or "agree"; and keywords may be related to the intent to refuse, such as "don't want" or "never mind." The NLU model is trained based on the keywords corresponding to each of the multiple triggering intentions, enabling the NLU model to recognize user input containing keywords as triggering intentions corresponding to those keywords. Training the NLU model with keywords related to the triggering intentions makes the NLU model more closely aligned with actual business scenarios when performing intent recognition. When user input information is fed into the NLU model for intent recognition, keywords can be automatically extracted from the user input information. Based on this, intent recognition of the user input information can be performed to obtain triggering intents that are more closely related to the keywords. The resulting triggering intents can better fit the actual business scenario and better meet user needs. At the same time, it can also avoid invalid dialogue and shorten the dialogue process.

[0127] For example, at least one transition rule includes a default transition rule, where the triggering intent defined by the default transition rule is represented by a wildcard. Any intent can be considered to match the triggering intent represented by the wildcard; that is, provided that other information in the query information besides the user's intent information meets the transition conditions of the default transition rule, the default transition rule can be matched regardless of the user's input information, i.e., regardless of the user's intent. The default transition rule can handle default logic, and its design can enhance the robustness of the finite state machine.

[0128] For example, the dialogue management operation also includes: generating and displaying a state transition diagram corresponding to the finite state machine in response to a visual instruction from a business user. The generated state transition diagram can be in any suitable visual format. The state transition diagram can intuitively display the state, triggering intent, and transition rules of the finite state machine, making it easier for business users to understand and review.

[0129] According to another aspect of the invention, see Figure 3 A dialogue management device 300 based on a finite state machine is provided, wherein the finite state machine includes multiple states and defines at least one transition rule. The dialogue management device 300 includes:

[0130] The receiving module 310 is used to receive user input information;

[0131] The recognition module 320 is used to perform intent recognition on user input information in order to determine user intent information;

[0132] Module 330 is used to obtain the current state of the target task instance;

[0133] The determination module 340 is used to determine the target transfer rule that matches the query information from at least one transfer rule. The query information includes the previous state and user intent information.

[0134] The transfer module 350 is used to transfer from the previous state to the target state of the target task instance according to the target transfer rules, and to respond according to the response method associated with the target transfer rules.

[0135] The response method is one of at least one preset response method, which includes: outputting a preset first dialogue text, and / or inputting preset constraint prompts and model input information into a large model so that the large model outputs a second dialogue text, wherein the model input information includes user input information and / or user intent information.

[0136] According to another aspect of the invention, see Figure 4 Furthermore, an electronic device 400 is provided, which may include a processor 410 and a memory 420. The memory 420 stores computer program instructions, which are executed by the processor 410 to perform the aforementioned dialogue management method based on a finite state machine.

[0137] According to another aspect of the present invention, a storage medium is also provided, on which program instructions are stored. When the program instructions are executed by a computer or processor, the computer or processor performs the corresponding steps of the finite state machine-based dialogue management method described above in the embodiments of the present invention, and is used to implement the finite state machine-based dialogue management apparatus described above in the embodiments of the present invention. The storage medium may, for example, include a memory card of a smartphone, a storage component of a tablet computer, a hard disk of a personal computer, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a portable compact disc read-only memory (CD-ROM), a USB memory, or any combination of the above storage media. A computer-readable storage medium may be any combination of one or more computer-readable storage media.

[0138] According to another aspect of the present invention, a computer program product is also provided, including computer program instructions that, when executed, perform the dialogue management method based on the finite state machine described above.

[0139] Those skilled in the art can understand the specific implementation and beneficial effects of the above-described finite state machine-based dialogue management device, electronic device, storage medium, and computer program product by reading the detailed description of the finite state machine-based dialogue management method above. For the sake of brevity, they will not be described in detail here.

[0140] Although exemplary embodiments have been described herein with reference to the accompanying drawings, it should be understood that the above exemplary embodiments are merely illustrative and are not intended to limit the scope of the invention. Various changes and modifications can be made therein by those skilled in the art without departing from the scope and spirit of the invention. All such changes and modifications are intended to be included within the scope of the invention as claimed in the appended claims.

[0141] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0142] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed.

[0143] Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0144] Similarly, it should be understood that, in order to streamline the invention and aid in understanding one or more of the various aspects of the invention, features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof in the description of exemplary embodiments of the invention. However, this approach should not be construed as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as reflected in the corresponding claims, its inventive point lies in solving the corresponding technical problem with fewer features than all of those in a single disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of the invention.

[0145] Those skilled in the art will understand that, apart from the mutual exclusion of features, all features disclosed in this specification (including the accompanying claims, abstract, and drawings) and all processes or elements of any method or apparatus so disclosed may be combined in any combination. Unless otherwise expressly stated, each feature disclosed in this specification (including the accompanying claims, abstract, and drawings) may be replaced by an alternative feature that serves the same, equivalent, or similar purpose.

[0146] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of the invention and form different embodiments. For example, in the claims, any of the claimed embodiments can be used in any combination.

[0147] The various component embodiments of the present invention can be implemented in hardware, or as software modules running on one or more processors, or a combination thereof. Those skilled in the art will understand that microprocessors or digital signal processors (DSPs) can be used in practice to implement some or all of the functions of some modules in the finite state machine-based dialogue management device according to embodiments of the present invention. The present invention can also be implemented as a device program (e.g., a computer program and computer program product) for performing part or all of the methods described herein. Such programs implementing the present invention can be stored on a computer-readable medium or can take the form of one or more signals. Such signals can be downloaded from an Internet website, provided on a carrier signal, or provided in any other form.

[0148] It should be noted that the above embodiments are illustrative of the invention and not restrictive, and that those skilled in the art can devise alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses should not be construed as limiting the claims. The word "comprising" does not exclude the presence of elements or steps not listed in the claims. The word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements. The invention can be implemented by means of hardware comprising several different elements and by means of a suitably programmed computer. In the unit claims enumerating several means, several of these means may be embodied by the same item of hardware. The use of the words first, second, and third, etc., does not indicate any order. These words can be interpreted as names.

[0149] The above are merely specific embodiments or descriptions of the present invention, and the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. The scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. A finite state machine based dialog management method, characterized by, The finite state machine contains multiple states of the target task instance, and the finite state machine defines at least one transition rule. The dialogue management method includes the following dialogue management operations: Receive user input information; The user input information is subjected to intent recognition to determine the user's intent information; Obtain the current state of the target task instance; From the at least one transfer rule, a target transfer rule matching the query information is determined, wherein the query information includes the prior state and the user intent information; According to the target transition rule, the process transitions from the previous state to the target state of the target task instance, and responds according to the response method associated with the target transition rule. The response method is one of at least one preset response method, which includes: outputting a preset first dialogue text, and / or inputting preset constraint prompts and model input information into a large model so that the large model outputs a second dialogue text, wherein the model input information includes the user input information and / or the user intent information.

2. The dialogue management method according to claim 1, characterized by, The at least one preset response method also includes: performing a preset operation by calling an application programming interface.

3. The dialogue management method according to claim 1, characterized in that, After responding according to the response method associated with the target transfer rule, the dialogue management method further includes: The operation information corresponding to the dialogue management operation is stored in the global context information. The operation information includes one or more of the following: the pre-state, the user intent information, the end marker corresponding to the target transfer rule, and the user profile. The end marker is used to indicate that a response has been made to the target transfer rule. The user profile is obtained by calling the application programming interface to perform a preset operation. The user profile includes user feature tags when the historical task instance was executed. The historical task instance and the target task instance are the same type of task instance. The query information also includes at least a portion of the information in the global context information.

4. The dialogue management method according to claim 3, characterized in that, The user intent information includes an intent identifier and task association parameters. The task association parameters are parameters required for the execution of the target task instance. Each of the at least one transfer rule corresponds to a transfer condition, which includes one or more of the following requirements: The user intent information conforms to a preset intent type; The task association parameters include parameters of preset types; The global context information stores operation information of a preset type; The global context information does not store the end marker corresponding to the corresponding transition rule.

5. The dialogue management method according to claim 1, characterized in that, The user intent information includes an intent identifier and task association parameters. The task association parameters are parameters required for the execution of the target task instance. Each of the at least one transfer rule corresponds to a transfer condition. Determining the target transfer rule that matches the query information includes: Query the transition rules that match the preceding state and the intent identifier; From the retrieved transfer rules, a target transfer rule is determined. The target transfer rule is a transfer rule that meets the corresponding transfer conditions. The transfer conditions include requirements corresponding to the task-related parameters and requirements corresponding to information in the query information other than the pre-state and the user intent information.

6. The dialogue management method according to claim 5, characterized in that, Each of the at least one transfer rule has a priority, and determining the target transfer rule from the queried transfer rules includes: The transfer rules are traversed from high to low priority, and the first transfer rule that satisfies the corresponding transfer condition is taken as the target transfer rule.

7. The dialogue management method according to any one of claims 1-6, characterized in that, The finite state machine includes: A set of states, wherein the set of states includes the plurality of states; A set of triggering intents, which includes a variety of preset triggering intents; A set of transfer rules, wherein the set of transfer rules includes the at least one transfer rule; The state set, the trigger intent set, and the transition rule set are all defined through a preset configuration file. Before the dialogue management operation, the dialogue management method also includes the following engine initialization operation: Load the first preset configuration file that defines the set of states; Load the second preset configuration file that defines the set of triggering intents; Load the third preset configuration file that defines the set of transfer rules.

8. The dialogue management method according to claim 7, characterized in that, The engine initialization operation also includes one or more of the following verification operations: Verify whether each state in the state set, except for the termination state, can be transitioned to the next state through the transition rules. If each state can be transitioned to the next state through the transition rules, then the first verification operation is determined to be successful; otherwise, the first verification operation is determined to be unsuccessful. Starting from the initial state in the state set, each state is traversed forward along the transition path defined by the at least one transition rule to determine the next state of each state, in order to verify whether there is an unreachable state in the state set. If there is, the second verification operation is determined to fail; otherwise, the second verification operation is determined to pass. Verify whether each of the at least one transition rule corresponds to only one next state. If so, determine that the third verification operation passes; otherwise, determine that the third verification operation fails. Detect whether there is a strongly connected component in the state set. If it exists, determine that the fourth verification operation fails; otherwise, determine that the fourth verification operation fails. Starting from the termination state in the state set, each state is traversed in reverse along the transition path defined by the at least one transition rule to determine the previous state of each state. If the traversed and determined states include all states in the state set except the termination state, then the fifth verification operation is determined to pass; otherwise, the fifth verification operation is determined to fail. The first preset configuration file, the second preset configuration file, and the third preset configuration file take effect when one or more verification operations pass.

9. The dialogue management method according to any one of claims 1-8, characterized in that, The step of performing intent recognition on the user input information to determine user intent information includes: The user input information is fed into a natural language understanding model for intent recognition to determine the user intent information; The finite state machine includes a set of trigger intentions, which includes a variety of preset trigger intentions. Each trigger intention has one or more sets of keywords. The natural language understanding model is trained based on the keywords corresponding to each of the various trigger intentions, so that when the user input information contains the keywords, the natural language understanding model can identify the user input information as a trigger intention corresponding to the keywords.

10. A computer program product comprising computer program instructions, characterized in that, The computer program instructions, when executed, are used to perform the dialogue management method based on a finite state machine as described in any one of claims 1-9.

Images