| << Prev | - Up - |
Methods that are more sophisticated.
As we've just seen, using finite state techniques in dialogue processing may lead to good results with relatively little effort, but only under certain conditions. If for instance great flexibility in a complicated domains is what is needed, finite state techniques often don't lead to satisfying solutions.
In such cases, one uses methods that are more sophisticated linguistically as well as technically. Such methods often involve a fair amount of reasoning, for instance about plans and communicative intentions. A key idea is that of representing the user's and the system's knowledge state explicitely and employ reasoning techniques on these state representations. Fully-fledged reasoning also allows for the consideration of domain knowldege to the extent needed for solving even quite complex tasks. Another concept of great importance in designing advanced dialogue systems is that of speech act s or dialogue act s, defining what role a each utterance plays within a dialogue.
Two examples of quite ambitious dialogue systems are the TRAINS system and its successor, the TRIPS system. Both deal with helping humans in logistics tasks. The basic dialogue scenario that TRAINS deals with is route-planning in a transportation domain. TRIPS collaborates with the user in disaster relief management.
A TRAINS example dialogue
Here's an example of a dialogue with the trains system:
User[1]: | I need to get to Detroit, Syracuse and Montreal. |
Syst[2]: | Ok. [highlights the three cities] |
User[3]: | Let's send the trains from Chicago to Detroit. |
Syst[4]: | Ok. [draws route from Chicago to Detroit via Toledo] But the terminal at Toledo is delaying traffic due to bad weather. Trains will take an additional five hours to move from there. [highlights Toledo red] |
User[5]: | That's ok. Now let's go from Atlanta up to Syracuse. |
Syst[6]: | Please tell me a route to use to get from Atlanta to Syracuse [highlights engine at Atlanta and city Syracuse] |
User[7]: | Go via Charleston and Pittsburgh. |
Syst[8]: | Ok. [draws route via Cincinnati] But traffic through Cincinnati is being delayed due to construction. |
User[9]: | Ok, let's go via Charleston and Buffalo instead. |
Syst[10]: | No problem. [draws route] |
User[11]: | That's great. |
Syst[12]: | I hope it was helpful. |
User[13]: | Finally, I want to go from Montreal to Philadelphia. |
Syst[14]: | Ok. [draws route] |
User[15]: | That's great. I'm done. |
As you can see from this small dialogue already, the TRAINS system allows for much more flexible interaction than for instance the speaking elevator. Dialogues start by either the system presenting the user with a problem, or the user presenting the system with their goal. The participants then have to define tasks in order to solve the original problem and talk about them. Interactions are interpreted with reference to all previous interactions.
TRAINS was built with the objective of allowing the user and the system to collaborate towards solving the problem in a way that humans collaborate with each other. Each participant is responsible for the part of the task that they can perform better. That means that the user is responsible for the top level goals of how to attack a problem. The system constantly tries to infer from the user's input what the user's goals are, with respect to the task. Based on that, it draws the user's attention to possible problems and makes relevant suggestions. Due to the aimed behaviour for the system, a lot of planning and plan recognition becomes necessary. The TRAINS system uses domain-specific reasoning techniques to make plan recognition less computationally expensive. As far as planning is concerned, the system is deliberately weak, so that more collaboration with the human user is provoked.
Demo videos
This website has further information (including demo videos with extensive dialoguies) on the TRAINS and TRIPS systems.
| << Prev | - Up - |