Spoken Dialogue Management

The goal of a spoken dialogue manager is to make the interaction between user and system natural so that the user can speak freely just as she would with another human.

Managing the conversation between a user and an application consists to a good part of deciding how to react to user�fs speech on the right timing. Making this decision may be a surprisingly difficult task as the correct decision depends on many factors. Examples shown below are some of possible factors which many of speech interfaces do not support :

Challenge1 : Reliability of Recognition Result

Even when the speech recognizer does not provide a recognition result at all, the user may have said something that the system does not understand. In that case, the dialogue manager needs to decide what the system should speak back so that the conversation gets back on track.

ATOM's Free Programmability for Recovery Strategies

Because ATOM can be programmed using JavaScript, developers may program their own recovery strategies, specifically for the application. For example, a user says 'give me directions to 1st Avenue at Bond Street'. No such intersection exists, however, a map database contains the intersection 3rd Avenue at Bond Street. With this knowledge, and noting that phonetically, 1st Avenue is similar to 3rd Avenue, the dialogue system may now prompt the user whether he wanted to go to 3rd Avenue at Bond Street.

It is clear from this example that appropriate recovery strategies are highly application specific. Therefore, no one generally applicable recovery strategy may be given. The important point is that ATOM's free programmability gives application developers the means to develop their own recovery strategies and to integrate them with the voice user interface.

Challenge 2: Setting of Recognition Rate & Long, Repeating Interactions

The dialogue manager has to see if the speech recognizer provides a recognition result with a low or high confidence score. If the confidence score is low, it may be better to confirm the recognition result (e.g., Did you say X?).

Multiple Information Bits

But frequent confirmation may annoy the user so the dialogue manager may confirm several pieces of information at once (e.g., You said you want X, Y and Z. Is this correct?).

Implicit Confirmation

Typically, spoken dialogue systems seek to explicitly confirm information obtained from the user. While explicit confirmation is a useful and accepted dialogue strategy in many cases, it lengthens the duration of a dialogue, may be distracting, or inappropriate for other reasons.

On the other hand, implicit confirmation makes a dialogue speedy since it can include comfirming description in the next question.

With the ATOM Spoken Dialogue SDK, you can define your own confirmation strategies so that a developer can freely set implicit/ explicit confirmations depending on demands and situations. Even better, it is possible to package and re-use Interaction Pattern in other applications.

Challenge 3: Missing Information from a User

When the user did not provide all necessary information, the system needs to prompt for missing information. For example, a voice operated cell phone may react to the request �gCall Jack�h by prompting �gWould you like to call Jack Nicholson or Jack Daniels?�h

Retrieve Information from Database and Ask

In order to write a dialogue strategy that prompts the user only for information if necessary, the system can be programmed such that all phone book entries that match the information the user has provided are retrieved from the phone book.

In the example above, the system uses the first name 'Jack' to retrieve to phone book entries, one for Jack Daniels and one for Jack Nicholson. If more than one matching entry is retrieved, the system looks at the fields in which the entries differ. In the above example, the entries differ in the last name. The system then prompts the user for the missing information, enumerating the retrieved information from the phone book as ' Jack Nicholson or Jack Daniels'.

Challenge 4: In What Order to Ask Questions

For example, in a restaurant guide application, the database may contain several pieces of information, such as price category, type of food, whether a patio is available, and so on. The dialogue manager needs to decide the appropriate order questions to retrieve missing information from user effectively.

Check the Database

Similarly to the phone book example above, the system uses all information provided by the user to retrieve all matching restaurants. Again, the system will look at all fields in which the retrieved restaurants differ, for example, neighborhood and price category. Let's assume the system retrieves a set of restaurants that are located in 10 different neighborhoods and have two different price categories.

It is clear that if the user provides the desired neighborhood, the set of matching restaurants becomes much smaller than when the user provided the desired price category. Therefore, the dialogue system can choose the next question to ask in such a way that, on average, the matching set of restaurants is smaller.

Programmable Dialogue Manager

Depending on the application, there are many more issues a dialogue manager needs to take into account when deciding how to react to spoken input. The appropriate reaction may also depend on system state (e.g., how many restaurants there are in the database, how close they are to the current location, and so on).

For this reason, the ATOM Spoken Dialogue SDK gives the application developer maximum amount of freedom by providing a freely programmable dialogue manager.