亚历克斯对话系统框架_Roff_Python_下载.zip

Document version: 0.2

Last modification: 17/10/12

Author(s): Filip Jurcicek

UFAL Dialogue state update

The purpose of this document is to describe the principles and implementation of dialogue state update

in spoken dialogue systems developed at UFAL, MFF UK, Czech Republic. As a prerequisite, the

reader should be familiar with the definition of the UFAL dialogue act scheme as described in ufal-

dialogue-acts.odt.

Table of Contents

Selects.............................................................................................................................................10

Context................................................................................................................................................12

The last dialogue act slot.....................................................................................................................14

Ontology...................................................................................................................................................16

Probabilistic extension of the dialogue state update................................................................................20

Appendices...............................................................................................................................................25

Appendix A: CamInfoRest .................................................................................................................25

Appendix B: CamInfo.........................................................................................................................36

Appendix C: Letiste Praha..................................................................................................................45

Definition of a dialogue state

selected venue. In this domain, the goal can be composed of the following variables:

venue_type – defines what type of a venue the user is looking for

area – desired location of the venue

price_range – price range of the venue

near – whether the requested venue should be near another venue

food_type – type of food served at the venue if the venue type is a restaurant

stars – number of stars of the venue if the venue type is a hotel

Sometimes these variables are called slots or concepts and their values are called attributes. For

1/45

convenience, the slots representing the goal are called goal slots in this report. In addition to the goal,

the dialogue state can store information about what the user requested or wants to confirm, what the

system already informed about or what the system confirmed. This information is stored in additional

variables / slots.

The UFAL dialogue systems uses the concept of Information State Update, where the state is updated

whenever new information is available, either from a user or the system itself or any other partner in

the communication. Since the update is defined on the dialogue state, the process of updating the

t

.

It is assumed that the update is deterministic. Therefore, it must result in one specific dialogue state

given the previous state, system dialogue act and the current user dialogue act. Following the example

provided in the previous section, an example of the dialogue state update in a tourist information

domain can be performed as follows:

Turn 1

2/45

System says: How may I help you?

System says: What type of food are you looking for?

User says: I want a Chinese restaurant in a cheap price range.

Note that the value “None” denotes that user did not say anything about the relevant slot and it is a

default value for each slot.

Note that the values allowed in the slots in the previous example are very simple. The slots can store

only one value out of many. More complex values, such as sets or logic expressions, are not currently

supported. If sets are really needed then one can defined slot values as elements of a power set defined

3/45

for the original slot values.

Relatively simple requirement that the system should remember what user does not want turns out to be

complex to implement. The problem is that remembering only one value that user does not want is not

enough. For example, storing information from a user that does not want Indian food does not

discriminate between other options such as Chines, English, Italian, French, etc. To properly handle

- deny(food_type='Chinese') the slot value of the slot food_type is set None. This approach is shown in

the next example:

Turn 3

Updated dialogue state:

4/45

If the user said in the 3

rd

the update would look as follows:

User says: No. I do not want Chinese restaurant. I want Indian.

Updated dialogue state:

Simply, the inform act overwrites the deny act since the inform act is more informative.

In general, dealing with negation tends to be very complex. For example, should be the utterance “I do

not want Chinese restaurant.” interpreted as deny(food_type='Chinese') or deny(food_type='Chinese')&

deny(venue_type='restaurant') ?

Recording requests, confirmations and selects by users

So far, only the user inform dialogue act was considered when performing dialogue state update. Other

dialogue acts which must be considered are request, confirm, and select.

Requests

Typically a user requests a value of a particular slot if the user is offered a venue and the system did not

informed about that slot. Note the distinction between a property of a venue being offered and the

5/45