JP2022076439A - Dialogue management - Google Patents

Abstract

To provide a module for updating a dialogue state for use in a dialogue system for conducting a dialogue with a user, a method for training a classifier, and a method for updating a dialogue state for the user.SOLUTION: A dialogue system updates a dialogue state stored in a memory and having a data structure that stores information exchanged between a user and the dialogue system by comparing natural language input from the user with a plurality of actions indicating possible requests of the user and using information from the action that matches with the natural language input, and the dialog system generates a response to the natural language input using the updated dialogue state.SELECTED DRAWING: Figure 3

Description

The embodiments described here relate to dialogue management.

Dialogue systems, such as task-oriented dialogue systems, are natural language interfaces to tasks such as information retrieval, customer support, e-commerce, physical environment control, and human-robot interaction. Natural language is a universal communication interface that does not require the user to learn a set of task-specific commands. The voice interface allows the user to communicate by speaking, and the chat interface is enabled by typing. Correct interpretation of user input can be a daunting task for automated dialogue systems that lack the grammatical and common sense knowledge that allows a person to comfortably interpret a wide range of natural inputs.

Embodiments will be described with reference to the following drawings.
FIG. 1A is a schematic diagram of a mobile using a dialogue system according to an embodiment. FIG. 1B is a schematic diagram of a mobile using a dialogue system according to an embodiment. FIG. 2A is a schematic diagram of a system according to an embodiment. FIG. 2B is a schematic diagram of the application shown in FIG. 2B. FIG. 3 is a flowchart showing a method according to the embodiment. FIG. 4 is a schematic diagram of an exemplary dialogue state. FIG. 5 is a schematic diagram of a system according to an embodiment.

In one embodiment, a module is provided for updating the dialogue state for use in a dialogue system for interacting with a user.
User input and
With the processor
With memory,
Here, the processor is adapted to update the dialogue state in response to natural language input from the user, and the dialogue state is stored in memory.
The dialogue state has a data structure that stores the information exchanged between the user and the dialogue system.
The processor updates the dialogue state by comparing the natural language input from the user with a plurality of possible actions, the action indicating the user's possible request and using information from the action that matches the natural language input. And it is configured to update the state.

In a state-based dialogue system, dialogue states are used to exchange information between the user and the system as the dialogue progresses. The challenge with state-based dialogue systems is to update the state as more information is received from the user. When the user first speaks to the dialogue system, the dialogue state is generally empty and the dialogue begins. The system will then respond and the user will respond by providing more information about the dialogue state to be updated. The system and the user then take turns providing the utterance.

The disclosed module enhances computer functionality by enabling the computer performance of previously unexecuted functions by a computer running an interactive system that uses a statistical model that takes the text input of the user's speech as input. Bring improvement. Specifically, the disclosed system provides a dialogue system capable of outputting an appropriate response when the user refers to the information provided in the order prior to the dialogue. It provides this improvement by a three-stage approach, and in embodiments, the system is:
1) Guess the candidate action from the dialogue state;
2) Calculate the relevance score ∈ [0,1] for each candidate action;
3) Update the state with the most likely action.

The above system enables enhanced functionality without implementing domain-specific natural language understanding components. Moreover, there is no need to design annotation schemes and annotate intents and entities.

In embodiments, the dialogue state comprises a data structure comprising the items mentioned during the dialogue. In some embodiments, the interactive state will store information by providing a slot. Elsewhere, a decision tree data structure will be provided. In other embodiments, some free text portion of the structure may be provided.

In embodiments, the plurality of possible actions includes actions relating to the plurality of items mentioned during the dialogue. In some embodiments, all items mentioned in the dialogue can be included in possible actions. This allows the user's latest utterance to be compared to previous items referenced during the dialogue. In other embodiments, the possible actions are based on the last few orders rather than all dialogues.

Multiple possible actions are inferred from the state and domain definitions. A domain definition is a description of a data structure. For example, in a restaurant search domain, the domain definition includes a set of informable / requestable slots. In the catalog order domain, it is the item type and its attributes (color, size, etc.). In ordering food, it is a structure that represents a restaurant menu.

Domain definitions can also include domain-specific rules. For example, in a hotel reservation system, a user can specify an arrival date and a departure date, or an arrival date and a length of stay. The domain definition (along with the current dialogue state) is used to generate a list of candidate actions.

Dialogue systems can be adapted for many uses. One possible use is information retrieval. However, other uses are possible, such as information gathering, troubleshooting, customer support, e-commerce, physical environmental control, and human-robot interaction. The interactive state comprises information exchanged between the user and the system. The dialogue system is configured to retrieve information, wherein the dialogue state comprises a user purpose and a history, the user purpose indicates information requested by the user, and the history previously in response to the user purpose. Define the item being retrieved. The user's purpose may be the type of food desired by the user, the physical area of interest, and the like.

In a further embodiment, the processor is configured to compare natural language input from the user with a plurality of possible actions by using a binary classifier to indicate matching and unmatched actions. The binary classifier is configured to output a score, which score is compared to a threshold to determine if the actions match.

In one embodiment, the processor is configured to compare natural language inputs from the user to multiple possible actions by generating multiple model inputs for each action, where each model input is natural from the user. The processing with the language input and the action is further configured to input the model input into a binary classifier implemented as a trained machine learning model in order to output the score.

The trained machine learning model may be a transformer model. The transformer model uses a self-attention mechanism, which captures dependencies regardless of these distances. The transformer model may use an encoder-decoder framework and the trained machine learning model may be a bidirectionally trained machine learning model such as BERT.

In embodiments, the model input further comprises a previous response from the dialogue system. For example, the last system utterance may be used, or earlier system utterance expressions such as the lexical dialogue corresponding to the system utterance may be used.

In embodiments, the action may be selected from a candidate action and a state update action, where the candidate action indicates a question asked by the user in a previous response from the system and the state update action is from the system. Indicates a request from a user that does not link to the previous response of. The state update may represent a "purpose change".

Module input to an action may include a representation of the system's previous response, user input, an item description for an item in the dialogue state history, and suggested questions related to the item referenced in the item description. Module inputs to state update actions include representations of the system's previous responses, user inputs, and suggested questions related to possible user queries.

The above modules may form part of a dialogue system. Therefore, in a further embodiment, the dialogue system is
User input and
With the processor
Equipped with memory
The processor is adapted to update the dialogue state in response to natural language input from the user, and the dialogue state is stored in memory.
The dialogue state has a data structure that stores the information exchanged between the user and the dialogue system.
The processor updates the dialogue state by comparing the natural language input from the user with a plurality of possible actions, the action indicating the user's possible request and using information from the action that matches the natural language input. And is configured to update the state,
The processor is configured to use the updated state to generate a response to natural language input.

In a further embodiment, a computer implementation method for updating the dialogue state for a user in a dialogue system for interacting with the user is provided, the method of which is:
Receiving natural language input from the user and
Using the processor to update the dialogue state in response to natural language input from the user, the dialogue state is stored in memory, and the dialogue state is exchanged between the user and the dialogue system. With a data structure to store information
It comprises updating the dialogue state by comparing the natural language input from the user with a plurality of possible actions, wherein the action indicates a possible request of the user and information from the action that matches the natural language input. Use to update the status.

In a further embodiment, a method of training a classifier for updating state in a dialogue system.
Providing a classifier, the classifier compares a natural language input from a user to a possible action such that the classifier outputs a score indicating a match when the natural language input matches a possible action. Is possible,
Training the classifier using a dataset with natural language input and possible actions, the dataset provides a positive combination, natural language, if the natural language input and possible actions match. If the input and possible actions do not match, provide distractors.

In the above method, the possible action is selected from a candidate action and a state update action, where the candidate action indicates the question asked by the user in the previous response from the system and the state update action is from the system. Indicates a request from a user that does not link to the previous response.

Classifier training may be performed with or separately from policy model training.

The above method may be performed using a computer-readable medium with instructions, which causes the computer to perform the above method when the instructions are executed by the computer.

User input in a dialogue system can be understood using a combination of components of natural language understanding (NLU) and dialogue state tracking (DST). NLU identifies domain-specific intents and entities in user input, and DST updates the dialogue state.

1A and 1B are schematic views of a smartphone for illustrating the use of a method according to an embodiment. In FIG. 1A, the user inputs question 1 "I am looking for a cheap Italian restaurant" to phone 3. In FIG. 1B, the telephone 5 answers with "Zizzi Cambridge is a good restaurant in the center".

FIGS. 1A and 1B show one example of a task-oriented dialogue system related to restaurant search in Cambridge, which will be used in this description. However, the method can be applied to any task-oriented dialogue system that receives natural language power from the user, such as information retrieval, customer support, e-commerce, physical environment control, and human-robot interaction. User input can be received via a microphone as an utterance processed via voice recognition, or may be text input.

A smartphone is shown, but the method can be implemented on any device that has a processor. For example, a standard computer, any voice-control automation, server configured to handle user queries in stores, banks, transportation providers, and the like.

The conversation is shown below.

The user enters the query in orders 1, 3, and 5, and the system responds in orders 2, 4, and 6, respectively.

In the fifth order of the dialogue, the user asks for the address of the restaurant (Zizzi) presented by the system in the third previous order immediately after the presentation of another restaurant (Nando). The user identifies the target restaurant by referring to the expression "Italian restaurant". This type of dialogue is especially problematic in dialogue systems.

The dialogue shown above is accomplished using the system described with reference to FIGS. 2A and 2B and the flowchart of FIG.

FIG. 2A is a schematic diagram of the hardware that can be used to implement the method according to the embodiment. It should be noted that this is just one example and other configurations can be used.

The hardware comprises a computing section 700. In this particular example, the components in this section are described together. However, it is recognized that they are not necessarily placed in the same position.

The components of the computing system 700 include a processing unit 713 (such as a central processing unit, CPU), system memory 701, and a system bus 711 that combines various system components including system memory 701 to processing unit 713. It may be, but it is not limited to these. The system bus 711 may be any of several types of bus structures, including peripheral buses and local buses that use any of memory buses or memory controllers, various bus architectures, and the like. The computing section 700 also includes an external memory 715 connected to the bus 711.

The system memory 701 includes a computer storage medium in the form of volatile / or non-volatile memory, such as read-only memory. The basic input / output system (BIOS) 703 includes routines that help convert information between elements in the computer, such as during startup, and is typically stored in system memory 701. Further, the system memory includes an operating system 705, an application program 707, and program data 709 used by the CPU 713.

Further, the interface 725 is connected to the bus 711. The interface may be a network interface on which the computer system receives information from additional devices. The interface may also be a user interface that allows the user to respond to certain commands and the like.

In this example, video interface 717 is provided. The video interface 717 includes a graphic processing unit 719 connected to the graphic processing memory 721.

The graphics processing unit (GPU) 719 is particularly well suited for training classifiers by their adaptation to data parallelism, such as neural network training. Therefore, in the embodiment, the process for training the classifier may be divided between the CPU 713 and the GPU 719.

It should be noted that in some embodiments, different hardware may be used for training the classifier and performing state updates. For example, classifier training may occur on one or more local desktop or workstation computers, or devices in a cloud computing system, which include one or more separate desktop or workstation GPUs. Often, one or more separate desktop or workstation CPUs are processors with, for example, a PC-oriented architecture and, for example, a substantial amount of volatile system memory of 16 GB or more. For example, although interactive performance may use mobile or embedded hardware (these include or do not include a mobile GPU as part of a system-on-chip (SoC)), one or more. Mobile or embedded CPUs, such as mobile-oriented architectures, or microcontroller-oriented architectures, and processors with, for example, less than 1 GB of volatile memory may be used. For example, the hardware that performs the dialogue may be a voice assist system 120, such as a smart speaker or a mobile phone that includes a virtual assistant.

The hardware used to train the classifier may have significantly more computing power, for example, one second than the hardware used to perform tasks using agents. More operations can be performed and more memory is available. It is possible to use hardware with less resources. Because, for example, performing speech recognition by performing inferences using one or more neural networks is more than training a speech recognition system, for example, by training one or more neural networks. This is because it is a substantially small amount of computational resource. Further, techniques can be used to reduce the computational resources used to perform speech recognition, eg, to perform inferences using one or more neural networks. Examples of such techniques include model distillation, and for neural networks include neural network compression techniques such as pruning and quantization.

For dialogue, the application program 707 of FIG. 2A has three main modules shown in FIG. 2B. These are 1) action state update component 751, 2) system move selection component 753, and 3) template-based natural language generator 755.

The dialogue system operates using the dialogue state. An example of the dialogue state is shown in FIG. In embodiments, the dialogue state stores the system beliefs about the dialogue history and user objectives, including previously discussed items. After each utterance or user input, the state is updated by the action state update component 751. The updated state is moved to the system move selection component 753. The system move selection component 753 receives the updated state and applies the system move selection policy to determine the answer. With so many such modules configured to provide a response when they receive an updated state, there are many possible options for the system move selection component or the "policy component". In embodiments, statistical learning policies are used. However, other systems that use a rule-based approach can also be used. In the example, the following methods can be used. "Agenda-based user simulation for bootstrapping a POMDP dialogue system" in Human Language Technologies 2007 by Jost Schatzmann et al. Association for Computational Linguistics, pp. 149-152, April 2007.

The output of the system move selection component 753 is then converted into a natural language response by the template-based natural language generator 755.

FIG. 4 shows an example of the state. The state has a purpose. In this particular example, the purpose is represented by three slots: food, area, and price range. At the beginning of the dialogue, each slot is empty, but as more information is gathered from the user, the slots will be populated.

The dialogue state also comprises a dialogue history. It should be noted that in this example, the dialogue history contains three items, but the number of items is not fixed and will increase as more items are added during the dialogue. The system of this embodiment defines a history of the slot filling system, which in this example allows the user to find a restaurant that matches a particular area, price range, or food type. These are slots that can be informative in the domain definition of this example and are set in the dialogue history for each item (in this case, a restaurant). In addition to the informable slots, the requestable slots are also defined. In this example, the requestable slots are phone number, address, zip code, area, price range, and food type. Slots are defined by the domain.

In embodiments, state updates are seen in a set of actions or actions. Each action changes the value of the interactive state. For example, the state update action for the utterance "I am interested in Italian-style food" updates the user's purpose with food = Italian-style. The state update action for the utterance "Which area is the Italian restaurant?" Turns on the request bit for the area field of the entity that matches the attribute food = Italian style. Action detection is the task of identifying which state-changing action is intended by the user in a given context. In our approach, actions, which are commands for state changes, are detected without semantic analysis of the utterance.

The entire process will be described with reference to the flowchart of FIG. In step S101, a user input is received, which is a natural language input.

In step S103, a plurality of input actions are generated, which may be a candidate request action and a purpose change action. Candidate request actions are generated for each of the requestable slots for each item stored in the dialogue history. For example, if the dialogue history includes these restaurants, 18 request candidate actions are generated (6 requestable slots x 3 items). Changing the user's purpose, in contrast, is a context-independent action. Given the domain ontology, the model classifies the same number of repurpose actions in each order that correspond to (informative) slot-value pairs. For example, the Cambridge restaurant domain has a value of 102 for a food type, area, and price range slot.

These are then transformed as inputs to the model. In this embodiment, the input to the model is a word sequence consisting of: 1) a word sequence derived from the last utterance of the system, which may be the system utterance in which it appears, or a lexical. It may be a system utterance in the form of a converted dialogue action, 2) a user utterance from step S101, 3) an item description, and 4) a template generation action statement. The item description is a string generated from the action. For item-independent action (change of purpose), the item description is empty; for item-independent action (request for information), it corresponds to the requested item description. The description corresponding to the action request address of the first item for the state of FIG. 4 is "name zizi area central price cheap food Italian style".

To illustrate this, for this example, the system will generate 18 inputs for the requested action.

Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name zizi Area Central Price Cheap Food Italian Style SEP Phone Number?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name zizi Area Central Price Cheap Food Italian Style SEP Address?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name zizi Area Central Price Cheap Food Italian Style SEP Zip Code?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name zizi Area Central Price Cheap Food Italian Style What is the SEP Area?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP name zizi area central price cheap food Italian style SEP price range?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name zizi Area Central Price Cheap Food Italian Style SEP What type of food?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name Gandhi Area Central Price Affordable Food Indian Style SEP Phone Number?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name Gandhi Area Central Price Affordable Food Indian Style Italian Style SEP Address?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name Gandhi Area Central Price Affordable Food Indian Style SEP Zip Code?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name Gandhi Area Central Price Affordable Food Indian Style What is the SEP Area?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name Gandhi Area Central Price Affordable Food Indian Style SEP Price Range?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name Gandhi Area Central Price Affordable Food Indian Style SEP What type of food?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name Hotpot Area North Price Expensive Food Chinese Style SEP Phone Number?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name Hotpot Area North Price Expensive Food Chinese Style SEP Address?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name Hotpot Area North Price Expensive Food Chinese Style SEP Zip Code?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name Hotpot Area North Price Expensive Food Chinese Style What is the SEP area?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name Hotpot Area North Price Expensive Food Chinese Style SEP Price Range?
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP Name Hotpot Area North Price Expensive Food Chinese Style SEP What type of food?
The input of 102 for the change purpose action is of type:
Nando is a good restaurant in the north What is the price range for SEP Italian restaurants?
SEP SEP Food Italian Nando is a good restaurant in the north SEP Italian restaurant price range?
SEP SEP Food Chinese-style Nando is a good restaurant in the north SEP Italian-style restaurant price range?
SEP SEP area center

In the above, SEP indicates the separation between sentences.

In step S105, the input is scored. In embodiments, this is done by inputting into a trained model that is a bidirectional transformer. This is schematically shown in FIG. Inputs with 1) system, 2) user, 3) item description, and 4) action statement have been shown to be input as a sequence to a bidirectional encoder (in this case, BERT). A classification flag CLS is generated for the entire input, which is then provided through a linear layer to generate a score. By including an item description in the model input, the transformer model's attention mechanism learns to detect whether an action can be inferred from a user's utterance in a given context. The existence of item descriptions, the dynamic generation of candidate actions, and the method of data generation allow the model to interpret the referenced representation.

The above method of having inputs in different parts has a potential advantage, which is to encode the meaning from pre-training.

The above "action statement", eg, "price range", as input is in contrast to simply using the word "price range". However, it is also possible to use only the word "price range". Since "request price range" is not natural, the sentence is generated and the BERT is optimized to work in natural language.

In step 107, an input with a score higher than the threshold is selected and the threshold is 0.5 in this case. Then in step 109, these inputs are used to update the state, i.e. to change the purpose (slot value) or set the request bit for one of the items in the dialogue history. Used to update the dialogue state by either. During the update, the following heuristics apply: 1) If multiple actions are predicted for a slot, the one with the highest score is used; 2) Multiple request actions are from 0.5 When receiving a large score, only the request bit for the most recently mentioned item is used. As described above, the dialogue state stores the dialogue history in the order of the most recent mentions, and thus it is possible to easily determine the most recently mentioned item. Once the request bit is set, this information is a policy that determines how to handle other state update information, for example, the information for which the request bit is set, taking into account that the purpose is updated. Moved to the module. In embodiments, the policy model is a classifier that selects a template for the system response. This may be a rule-based response selection where the rule is triggered by the setting of the request bit.

In step S111, the updated dialogue state is then received by the policy model, which is used to provide the system response in step S113. The natural language response can be generated using the natural language generation component to provide the output in S115. The system response is then provided to the user and the user response is awaited. Once the user input is received, the process returns to S101 and resumes. However, here, the system response in step S115 is used to generate the plurality of inputs.

In the above embodiment, a set of candidate actions is generated from the dialogue state. The context is stored in the interactive state and statistical methods are used to update the interactive state. Binary classification is used to detect actions intended by the user. These actions then deterministically update the state.

The proposed "action detector" model is trained to identify the action intended by the user utterance from the list of candidate actions. Candidate actions in a task-oriented dialogue system are dynamically generated based on the current dialogue state and domain ontology. The above embodiment is captured as an input word for a user's utterance, such as typed text in a text-based chat, or as the output of a speech recognizer in a speech dialogue system.

In the above embodiments, state updates are considered as a set of actions or actions. Each action changes its value in the dialogue state, which stores a system belief about the user's purpose and dialogue history, including the previously discussed items. For example, the status update for the utterance "I am interested in Italian-style food" updates the user's purpose with food = Italian-style. The state update action for the utterance "Which area is the Italian restaurant in?" Turns on the request bit for the area field of the entity that matches the attribute food = Italian.

FIG. 5 outlines a process and model that can be understood from the above description of FIG. In FIG. 5, the $ slot is one of the price range, area, food type, and the $ value is these values stored in the database (cheap / affordable / expensive, north / south /. ..., Indian style / Italian style / ...).

In an embodiment, the above state update module performs three basic steps:
1) Guess the candidate action from the dialogue state 2) Calculate the relevance score for each candidate action 3) Update the state with the most probable action

The first step in the algorithm, generating a set of candidate actions for the current dialogue state, is deterministic. The action can be inferred from the current state. The final step of updating the state of a given set of actions is also deterministic. The second step of the algorithm is to score each candidate action with that probability intended by the user.

In the above embodiment, a BERT encoder with binary output and a linear layer are used. The input to the model is a word sequence and consists of: 1) a sequence of lexicalized dialogues, 2) user utterances, 3) item descriptions, and 4) templates-generated action statements. The item description is a string generated from the action. For item-independent action (change of purpose), the item description is empty; for item-dependent action (request information), it corresponds to the requested item description. The model outputs the probability of whether the action was intended by the user.

Next, classifier training is described. Classifiers are trained using positive and negative examples.
<sys, usr, action → (itemdescr, actionsent)>: 0/1

The term "sys" is the previous system response, "usr" is the user utterance, and action is the action intended by the user. To be consistent with the example above, "action" is subdivided into item descriptions and action statements as described above.

To create a training set, the action is intended by the user in the positive example (labeled with 1), but not in the negative example (labeled with 0). Since the action is an instruction about the current state, for example, "request the price range of the first item", the item description and the input of the action statement to the model are inferred from the action and the state. The three datasets for training the classifier are summarized in Table 2 below.

The baseline dataset is generated from the training division of the DSTC2 corpus. For each order, a positive example is generated for each action intended by the user. The intended action is inferred from the manual NL annotation, for example, the action is extracted from the NL annotation, for example, "I want italian / FOOD_TYPE food" / request_food ('I want italian / FOOD_TYPE food). '/ REQUEST_FOOD) corresponds to the action request_Italian style. It is considered to use all valid unintended actions (slot-value pairs) to generate negative examples (incorrect choices). However, this creates a highly distorted dataset when the number of actions is large. Instead, for each positive example, unintended actions are sampled using frequency and similarity heuristics to select more relevant incorrect answer options. Due to the design of the task, the DSTC2 dataset does not include representational references in the user's turn. All user requests are general and refer to the last presented item (eg, what is the phone number?). Therefore, the model trained in the baseline dataset can only understand the reference to the last presented item.

extH extends the baseline dataset with auto-generated utterances that reference the representation. The user may ask a question about any of the requestable slots and refer to any of the informative slots. To do this, requestable and informative can be provided by randomly sampling the request utterance without a reference representation for the request slot from the DSTC2 dataset and concatenating it with a template-generated reference representation for the reference slot. A 10K / 3K request is generated with reference to the representation for training / developing the dataset for all combinations of slots (see Table 3).

As shown in Table 2, active learning is used to generate additional datasets. The key idea is that the algorithm can select training samples. The extA dataset in Table 2 is generated by automatically selecting the most challenging incorrect answer choices from the simulated dialogue.

The training set can be extended to seek out multiple locations and request slots for the locations provided early in the dialogue by repeatedly changing the objective constraints. In addition, a template is generated to generate utterances with reference to the representation for this new behavior, resulting in a hybrid search / template-based model for generating simulated user utterances.

As a test, a first simulation is performed on an ASU module that uses a trained classifier with a baseline dataset for 5000 dialogues. In a simulation on behalf of the actual user, another system is used to simulate the user. In this particular example, a user simulated based on a rule that receives a randomly selected purpose and produces an utterance similar to a human-computer dialogue is used. From the simulated user intent, the "intended" user action is inferred and new training examples are automatically labeled. Each "intended" action in which the baseline model predicts a relevance score below T1 is used as a positive example. The maximum M "unintended" action with the highest relevance score greater than T2 is used as a negative example. In this test, T1 =. 99, T2 = 0.5, and M = 2. All generated utterances that refer to the representation are also used as a positive example, even if these are correctly classified in the model trained in the baseline dataset.

To demonstrate the above, the ASU approach is trained in a baseline model on a test subset of the DSTC2 corpus, ie, without reference to representations. Using a user-entered manual transcript, the model correctly identifies 96% of user notifications and 99% of user requests (average purpose and required accuracy as calculated by the official DSTC2 evaluation script).

Next, the approach proposed for the simulated dialogue with reference to the representation in the user request is evaluated. The simulation is performed with the proposed action state update components for the baseline, expH, and expA datasets.
The results are shown in Table 4.

As a GOLD condition, the simulation is performed with the correct action inferred from the simulated dialogue. The policy model is trained by agenda-based simulations that use dialogue (DA) as input and as a 25% dialogue confusion rate. For models trained at expH and expA, the policy model is also trained as input with simulated user utterances rather than dialogue hypotheses. In this condition, the policy may be learned to overcome the state update error created by the ASU model.

5000 dialogues are simulated for each experimental condition and statistics for dialogues and individual turns are calculated. If the location provided by the system (possibly after a number of objective changes) matches the simulated user's objective constraints, the dialogue success rate is the ratio of the simulated dialogue and the simulated user. Provide additional information requested by. The state update accuracy is calculated as average accuracy over a) all orders, b) the order annotated as notification only, and c) the order annotated as request only.

The simulated user behavior is influenced by the state update model. The average length of the simulated dialogue ranges from 7.93 for the GOLD condition to 10.06 for the baseline. Lower state update accuracy leads to longer dialogue. This is because the simulated user iteration or paraphrase request increases the length of the dialogue when the system fails to respond correctly. Baseline conditions achieve only 43.9 percent dialogue success and 50 percent state update accuracy in turn for all users. Under expH DA conditions, dialogue success and overall accuracy increase to 91.1% and 75.1% with an accuracy of 79% for notifications and only 50.0% for requirements. The active learning approach (expA DA) increases dialogue success and overall accuracy to 99.5% and 98.1% with an accuracy of 98.8% for notifications and 94.0% for requirements. Using a matched policy model impacts the performance of both the expH and expA models, increasing accuracy by 4.3 and 1.4 absolute percentage points for requirements. However, using policies trained by the expH model, the accuracy of the user notification action is reduced by 3.1 points and the length of the dialogue is increased. The results show that the action state update approach is effective in combination with active learning.

Preliminary user studies were performed to test the proposed action detection model with real users. The text-based system consists of a proposed dialogue state tracker using the expA action detection model, a dialogue policy trained in a text-based user simulator, and a template-based natural language generator. Subjects are hired and asked to perform five tasks with restaurant information navigation. In each task, the subject is given a default constraint (eg, food type: Chinese style, price range: cheap) and asked to get appropriate recommendations from the system. They then get two alternative recommendations by continuing the conversation, changing the constraints, and getting a total of three recommended locations. Finally, they are asked to get additional information such as phone numbers or addresses about these two locations. Subjects are also asked to indicate when the system response was incorrect by entering <error>. After completing all five tasks, the subject will have a five-sentence question and a number of tasks to score on a six-point Likert scale ranging from "strongly disagree" to "strongly agree". Fill in the question (see Table 5) asking if it was successful and completed.

Each user entered an average of 60.9 turns, marking 15 percent of these as errors. The results of the questions indicate that the system understood the reference to their location (mean score 4.8). Half of the users completed all five tasks and only one of the users felt that the system was not well understood. A high standard deviation across the user indicates high volatility in the user experience and perhaps system expectations. Human evaluation shows that the above model can be used in an interactive dialogue system.

The embodiments described herein provide a novel approach to updating the dialogue state and can succeed in interpreting a user utterance, including a request to refer to a representation. The experimental model is trained by extending the first Cambridge restaurant dataset with simulated requirements that include reference to representations and sampled incorrect answer choices. Models trained on a dataset in which incorrect choices are sampled using an active learning approach achieve best performance regardless of the smaller size of the training set. Human evaluation of this model shows that the approach can be used in real-world user-interaction systems.

Although certain embodiments have been described, these embodiments are presented by way of example only and are not intended to limit the scope of the invention. In fact, the new devices, methods described herein may be embodied in various other forms, as well as various omissions, replacements, and modifications in the form of devices, methods, and products described herein. However, it may be done without departing from the scope and spirit of the present invention. The accompanying claims and their equivalents are intended to cover such forms or modifications, as is within the scope and spirit of the invention.

Claims (20)

A module for updating the dialogue state for use in a dialogue system for interacting with a user.
User input and
With the processor
Equipped with memory
The processor is adapted to update the dialogue state in response to a natural language input from the user, and the dialogue state is stored in the memory.
The dialogue state comprises a data structure that stores information exchanged between the user and the dialogue system.
The processor updates the dialogue state by comparing the natural language input from the user with a plurality of possible actions, wherein the action indicates a possible request of the user and is from an action that matches the natural language input. A module configured to update the above state using the information in. The module of claim 1, wherein the dialogue state comprises a data structure comprising items mentioned during the dialogue. The module of claim 2, wherein the plurality of possible actions include actions relating to the plurality of items referred to during the dialogue. The dialogue system is configured for information retrieval, the dialogue state comprises a user purpose and a history, the user purpose indicates information requested by the user, and the history is previously searched in response to the user purpose. The module according to claim 1, which defines an item that is being used. The processor is configured to compare the natural language input from the user with a plurality of possible actions by using a binary classifier to indicate matching and non-matching actions. The module described in. The module of claim 5, wherein the binary classifier is configured to output a score, the score being compared to a threshold value to determine if the actions match. The processor is configured to compare the natural language input from the user to a plurality of possible actions by generating multiple model inputs for each action, where each model input is the action and the natural from the user. 6. The processor is further configured to input the model input into a binomial classifier implemented as a trained machine learning model to output the score, comprising a language input. Module. The module according to claim 7, wherein the trained machine learning model is a transformer-based trained machine learning model. The module according to claim 7, wherein the trained machine learning model is a machine learning model trained in both directions. The module of claim 7, wherein the model input further comprises a previous response from the dialogue system. The action is selected from a candidate action and a state update action, the candidate action indicates a question asked by the user in a previous response from the system, and the state update action does not link to a previous response from the system. The module according to claim 7, which indicates a request from a user. The module input to the candidate action comprises a representation of the previous response of the system, the user input, an item description of the item in the dialogue state history, and a proposed question related to the item referenced in the item description. The module according to claim 11. 11. The module of claim 11, wherein the module input to the state update action comprises a representation of the previous response of the system, the user input, and a proposed question related to a possible user query. 12. The module of claim 12, configured to set a request bit when the module inputs for the candidate action match. 13. The module of claim 13, configured to update the state when the module inputs to the state update action match. A way to train a classifier to update a state in a dialogue system,
Providing a classifier, wherein the classifier may receive the natural language input from the user such that the classifier outputs a score indicating a match when the natural language input matches the possible action. It is possible to compare with,
Training the classifier using a dataset with natural language input and possible actions, said dataset comprising a positive combination if the natural language input and possible actions match. A method that provides incorrect answer options when natural language input and possible actions do not match. The possible action is selected from a candidate action and a state update action, the candidate action indicates the question asked by the user in the previous response from the system, and the state update action does not link to the previous response from the system. The method of claim 16, wherein the request from the user is shown. It ’s a dialogue system,
User input and
With the processor
Equipped with memory
The processor is adapted to update the dialogue state in response to a natural language input from the user, and the dialogue state is stored in the memory.
The dialogue state comprises a data structure that stores information exchanged between the user and the dialogue system.
The processor updates the dialogue state by comparing the natural language input from the user with a plurality of possible actions, wherein the action indicates a possible request of the user and is from an action that matches the natural language input. It is configured to update the above state using the information in
The processor is configured to use the updated state to generate a response to the natural language input. It is a computer implementation method for updating the dialogue state with the user in the dialogue system for interacting with the user.
Receiving natural language input from the user and
The processor is used to update the dialogue state in response to a natural language input from the user, wherein the dialogue state is stored in memory and the dialogue state is the user and the dialogue system. It has a data structure that stores information exchanged with and from.
It comprises updating the dialogue state by comparing the natural language input from the user with a plurality of possible actions, wherein the action indicates a possible request of the user and is consistent with the natural language input. A method of updating the state using information from an action. A computer-readable medium comprising an instruction that causes the computer to perform the method of claim 19 when the instruction is executed by the computer.

Images