瞬间灰色-()()101==+=C G P C G P i i (1)
We are going to assume a multiple goal evaluation scheme, thus multiple goals can be active if they vote positive. Moreover, we can identify the Out Of Domain, OOD, queries. OOD queries are those ones for which all BN vote negative. We have to point out that we have enhanced the basic topology for each goal adding some links between concept nodes, according to the expert’s criterion, to model the inter-concept dependencies.
These links introduce certain variation in the probability propagation for goal inference. Details regarding the exact inference algorithm we have used can be checked in [4]. The probabilities involved in the inference process (left hand of Eq.1) have been hand-assigned by the expert too. [5] presents a Minimum Description Length approach for learning topologies automatically. The conditional probabilities for each BN can be estimated simply just tallying the counts from training data.
Next we are going to introduce the “backward inference” technique. This is used to detect automatically missing or spurious concepts based on the inferred goal corresponding to the processed sentence. Consequently, we drive the dialog prompting for missing concepts and clarifying for spurious concepts. From the inferred goal we have to test the network’s confidence for each of the input concepts. Now we assume the inferred result, i.e. G i=1, as a new evidence that we must add to the observations’ vector. Then we apply Bayesian inference again but this time aimed at the estimation of P(C i|C’), the updated concept’s probability, where C’={G i=1, C1=0, C2=1,…, C M=1}.
Based on the value of P(C i|C’), we make a binary decision again in order to check whether that concept should be present or absent. Then we compare the result of that decision with the actual occurrence of the concept in the observations’ vector. If the binary decision indicates that the concept should be present but it is absent, the concept is labeled as missing and the dialog manager triggers a prompting act. If the binary decision indicates that the concept should be absent but it is actually present in the input sentence, the concept is labeled as spurious and the dialog manager invokes a clarification act.
3.2.Dialog Strategy
Figure 4 shows the adopted strategy for dialog modeling. First we build the observations’ vector considering the evidences extracted from the semantic concepts. Assuming a starting dialog act we directly apply Bayesian inference. Thus we infer the present dialog goals/actions to be executed according to the user’s intention. After evaluating the active goals we proceed to the detection of the missing and spurious concepts. To do this we apply the backward inference based on the inferred goals. In addition, we determine which concepts are confirmed as present by the network.
Subsequently, assuming that the user has provided all the required information regarding the requested actions, we are able to complete for each goal its corresponding execution frame filling it from the confirmed concepts. We store those concepts in the dialog history as consolidated knowledge. Finally, we update the system’s state according to the performed actions and inform users about those actions.
3.2.1.Partially Observed Goals
Sometimes people omit certain information which can be perfectly deduced from the dialog context. In such cases the user provides an incomplete observations’ vector. As a result several goals can be identified as present in the user’s utterance but complete information is not available for all those inferred goals. In order to handle those ‘partially observed’ goals, we make use of a number of different components: the Dialog History, which maintains a record of the evolving dialogue in the form of a stack of confirmed concepts from backward inference; the Current Dialog Act History, which maintains a similar record to the previous one but it only contains information regarding the current dialog act instead; and the system’s state, which contains all the information regarding the system’s current setup. Each user’s action can be coded by a frame constituted by three elements: a source, a parameter and a value. Therefore we have implemented different strategies in order to recover from each omitted element case.
Figure 4: Dialog Strategy
Regarding parameters, we assume that a parameter has been omitted when we find a value without an associated parameter. When this occurs (‘YES’ path for ‘Any omitted parameter?’ question in Figure 4), we try to match these values to a suitable parameter from the dialog history. There are values and ranges of values that are specific of a particular parameter, i.e. we can’t assign a value of ‘five’ to the ‘cd’ parameter since the system just has a three discs charger.
Typically, a particular parameter is omitted immediately in those subsequent user’s commands which have the aim of assigning a new value to that parameter. Based on this assumption we check the dialog history from more recent to older entries in order to extract, if possible, the closest suitable parameter, i.e. the user instantiates the ‘track’ parameter for a particular disc from: ‘play track six’, subsequently he simply says: ‘nine’. In the last command the parameter has been omitted but it can be perfectly elicited from the dialog history applying the described procedure. If we find any, this is included as an evidence to our observations’ vector before applying inference. On the other hand, if we don’t find any suitable parameter, we would have to expect the corresponding goal to be active although the
parameter is omitted. Otherwise, the user’s command would be misunderstood and no action would carry out.
Regarding omitted values no previous search is done in the dialog history before the inference process. Thus, we are referring to those cases where the inference process identifies the present goals properly in spite of the omitted value.
After the completion verification, which obviously results negative, we are going to check the system’s state to try to complete that frame. The system’s state contains all the information regarding the system’s current setup. It also captures the changes derived from the executed actions. Thus, from system’s state we are able to complete any dialog frame with a suitable value given a specific parameter.
Regarding how we confirm the user the inherited value, we must state some differentiation depending on the condition of the value and its corresponding parameter. We assume that we can use implicit confirmation just for that updated information induced by the past user’s interaction with the system. This information is known by the user since he confirmed it previously, whereas for the rest of information this is not true. In the latter case we must prompt the inherited value using an explicit confirmation procedure. This is clear from the following example: we assume that a user selected the cd two some significant time ago and after that he has performed several actions up to current time but none of them have been either a source or a cd change; if user simply says ‘put track number seven from the cd’ there’s no doubt that we should inherit the value ‘two’ for the ‘cd’ parameter from the system’s state. The user already knows which cd is selected by the time of processing that command so this information can be elicited directly from the dialog context. On the contrary, if no action for cd selection had occurred previously, the system would ask the user whether the selected cd, recovered from the system’s state, is the one that he wants to listen. In this case the user is supposed to be unaware of that information, so the system must explicitly consult him about it. Of course the user is free to select a different value instead of the proposed one.
Last of all, regarding omitted sources we proceed the same way as for omitted values. Thus, we assume that if no explicit change of source has occurred, the omitted source is the last one that was selected and which is stored in the system’s state, i.e. if the user says: ‘play the tape’, the ‘tape’ value is omitted but it can be recovered from system’s state by checking which tape is selected. Moreover, there are actions which are specific of a particular source, i.e. it is not possible to ‘rewind’ the radio tune. Thus, in those cases we can recover the source from the active BN.
Finally, after checking the system’s state, if we have been able to complete the dialog frame we store in the dialog history both the concepts confirmed from backward inference as well as those inherited ones as consolidated knowledge and start a new dialog act. On the contrary, if the frame is not complete yet, we have to trigger the system to prompt the user for requesting the necessary elements. Consequently, we are going to consider the current dialog act as not finished yet, so we have to store the useful available information before starting a new iteration within the dialog act. Exactly, we are going to store in the current dialog act history only those concepts confirmed from backward inference, neither the spurious nor the optional. Thus, we save the discourse state from the information provided by the user and the system’s current intention for confirming or repairing supplied or missing information.
In the next iteration, we are in the same dialog act so those confidence observations from the preceding iteration recorded in the current dialog act history should be inherited directly as part of the evolving observations’ vector. From the comparison between the inherited observations and the recently obtained ones the Dialog Manager is able to work out what has been repeated, modified or negated by the user. Therefore the system is able to interpret the user’s current utterance in the light of the intention behind its own last utterance and consequently to give an appropriate response.
4.Conclusions and Future Work
In this paper we have presented our recent efforts towards the goal of applying BN to spoken dialog systems for mixed-initiative dialog modeling in order to get a more flexible and natural spoken interaction. An approach for a Hi-fi system’s controlling domain is described. This can be easily extended
