Working languages:
English to Greek
Greek to English
Spanish to English

Morimel

Greece
Local time: 01:43 EET (GMT+2)

Native in: Greek Native in Greek
Account type Freelance translator and/or interpreter
Data security Created by Evelio Clavel-Rosales This person has a SecurePRO™ card. Because this person is not a ProZ.com Plus subscriber, to view his or her SecurePRO™ card you must be a ProZ.com Business member or Plus subscriber.
Affiliations This person is not affiliated with any business or Blue Board record at ProZ.com.
Services Translation, Editing/proofreading, Website localization, Software localization, Subtitling, MT post-editing
Expertise
Specializes in:
IT (Information Technology)Nutrition
Computers (general)Photography/Imaging (& Graphic Arts)
Biology (-tech,-chem,micro-)Medical (general)
Media / MultimediaPoetry & Literature
LinguisticsGames / Video Games / Gaming / Casino

Portfolio Sample translations submitted: 1
English to Greek: (Chapter) Oxford Handbook of Computaional Linguistics
General field: Tech/Engineering
Detailed field: Computers: Software
Source text - English
CHAPTER 35

NATURAL LANGUAGE INTERACTION

Ion Androutsopoulos
Maria Aretoulaki

ABSTRACT

This chapter is an introduction to natural language interaction systems, that is, systems that allow their users to formulate requests in spoken or written natural language. The chapter introduces the central concepts of natural language interaction systems, focusing in turn on two of the most studied forms of these systems: natural language interfaces and spoken dialogue systems.

35.1 INTRODUCTION

This chapter is an introduction to natural language interaction systems, a term used here to refer to applications where users can formulate requests addressed to a computer in natural language. The user’s requests may be spoken or written. They may be stand-alone sentences or parts of a dialogue. Furthermore, they may be analysed using shallow or deeper language processing. These options offer a range of choices to the system designer, different choices being more or less suitable to different applications.
The term natural language interface (NLI) has been used to refer mostly to natural language interaction systems where the user’s requests are processed – more or less – as isolated as sentences, often employing deep linguistic analysis. Systems of this kind have been studied extensively since the late 1960s, mainly in the context of database querying, and mostly with requests typed on a keyboard. More recently, attention has been shifting towards spoken dialogue systems (SDSs), where the user’s requests are spoken and they are seen as parts of an evolving dialogue. SDSs typically place greater emphasis on the analysis of the overall dialogue and its relation to the user’s intentions, often employing a more shallow analysis of individual sentences.
This chapter introduces the central concepts of natural language interaction systems, focusing in turn on NLIs and SDSs, as two of the most studied forms of these systems.

35.2 NATURAL LANGUAGE INTERFACES

Database querying constitutes the most studied form of NLIs (Perrault and Grosz 1988; Copestake and Sparck Jones 1990; Androutsopoulos, Ritchie, and Thanisch 1995; Androutsopoulos and Ritchie 2000). Typical database NLIs allow information to be retrieved from an underlying database by typing single-sentence queries, as in the following example where ‘U:’ and ‘S:’ mark user requests and system responses, respectively.

U: Which customers have bought SmartCopiers?
S: ABA France, QuickFly, Power Inc.
U: How many SmartCopiers has each one bought?
S: ABA France 15
QuickFly 12
Power Inc. 18
U: Have any of them also bought QuickCams?
S: Power Inc.

Although this section draws examples from database querying, most of the discussion also applies to other NLI applications, such as NLIs to operating systems (Wilensky et al. 1988), robots (Crangle and Suppes 1994), or virtual reality systems (Wauchope et al. 1997).

35.2.1 Basic NLI components

Fig. 35.1 sketches the typical NLI architecture. (We ignore for the moment speech input, assuming that the user types on a keyboard.) In most current NLIs, the user’s requests are translated into a meaning representation language (MRL), usually some flavor of logic, with a subsequent phase translating the MRL expressions into a formalism supported by the underlying application (e.g. a database language). This arrangement has portability advantages. For example, it makes it easier to reuse the components that translate from natural language to MRL with different underlying applications.
The user’s request first undergoes a pre-processing stage, which includes tokenization (Chapter 10), morphological analysis (Chapter 2), and lexicon look-up (Chapter 3). In database NLIs, proper names (e.g. SmartCopier) are very common. Name recognition and classification techniques (Chapter 30) can be used to identify them.
The pre-processed input is then parsed and analysed semantically (Chapters 4, 5, and 12), generating an MRL expression. In an MRL similar to first-order predicate logic, sentence (35.1) could be represented as (35.2). The ‘?’ is an interrogative quantifier specifying which variable values are to be reported. Expression (35.2) requires all the names x2 to be reported, such that x2 is the name of a customer x1, and x1 has bought a SmartCopier x3. To save space, here free variables are treated as existentially quantified. Tense and aspect issues are also ignored (Androutsopoulos, Ritchie, and Thanisch 1998; Androutsopoulos 2002).

(35.1) Which customers have bought SmartCopiers?
(35.2) ?x2 customer_name (x1,x2) ^ product_name (x2, SmartCopier) ^ purchase (x1,x3)

The resulting MRL expressions are often underspecified (Chapter 5), usually with respect to the semantics of anaphoric expressions, elliptical sentences (e.g. What about QuickCams?), and quantifiers. The underspecified MRL expressions are resolved during a semantic post-processing stage (Fig. 35.1); related techniques can be found in Chapter 14 and elsewhere (Alshawi 1992). Unlike SDSs, to be discussed in section 35.3, NLIs employ rather simple discourse models (Chapter 6). Typically, these record only previously mentioned entities, the point where they were mentioned, and properties like gender and semantic type, all useful for anaphora resolution (Barros and De Roeck 1994).
NLIs usually also consult a world model, which shows the ontology of the application (Chapter 25), including restrictions on the relationships between entity types, often called selectional or sortal restrictions (Alshawi 1992; Allen 1995). Sentence (35.3) illustrates their use. The intended meaning of (35.3) is (35.4), i.e. the holder of the licence is the employee. An NLI, however, would also have to consider (35.5), where the licence is held by the branch.

(35.3) List all employees of Paris branches that have driving licences.
(35.4) ?x2 employee_name (x1, x2) ^ branch_name (x3, x4) ^ city_name (x5, ‘Paris’) ^ works_at (x1, x3) located_in (x3, x5) ^ licence (x6) ^ for_driving (x6) ^ has (x1, x6)
(35.5) ?x2 employee_name (x1, x2) ^ branch_name (x3, x4) ^ city_name (x5, ‘Paris’) ^ works_at (x1, x3) located_in (x3, x5) ^ licence (x6) ^ for_driving (x6) ^ has (x3, x6)

In order to reject (35.5), the world model would contain a restriction stating that when the second argument of has (x,y) is a driving licence, the first argument must be a person, and the ontology would show that employees are persons, but branches are not.
The fully resolved MRL expressions are then translated into a formalism that the underlying application supports, for example shell commands when interfacing to an operating system, or a sequence of API (application programming interface) calls when interfacing to other applications. In database NLIs, the target is usually the SQLdatabase language. The translation from MRL to the underlying application (e.g. database tables; this is the ‘primitive translation information’ of Fig 35.1). Translation rules then specify how to translate more complex MRL expressions, possibly invoking recursively other rules to translate simpler MRL sub-expressions (Androutsopoulos and Ritchie 2000).

35.2.2 Other NLI components

Fully-fledged NLIs comprise additional components, not shown in Fig. 35.1. Some of these are listed below.

35.2.2.1 Paraphraser
NLIs often generate paraphrases of the user’s utterances that reflect the system’s interpretation of the utterances. This helps the users understand whether their requests have been interpreted correctly. When ambiguities arise, paraphrases of the candidate interpretations can also be presented, asking the user to select the most appropriate one. The paraphrases are produced from the MRL or application-formalism expressions by a component that uses generation methods. Related techniques can be found in Chapter 15 and elsewhere (De Roeck and Lowden 1986; Alshawi 1992).

35.2.2.2 Response generator

Most NLIs focus on the analysis of single-user utterances, without attempting to engage the users in dialogues. Hence, the planning of system responses is rather simple. In database NLIs, the system’s response is usually a listing of the retrieved information, possibly after some post-processing (e.g. to remove internal keys or replace them with names).
More difficult is the generation of appropriate responses when the user’s requests cannot be satisfied, in which case the cause of the failure must be explained (e.g. unknown word, syntax too complex). Particularly challenging are user requests that carry false presuppositions or do not express literally what the user wants to do. In the first question below, the system detects the false presupposition that ABA France has bought QuickCams, and generates an appropriate warning. To the second question, it does not reply with a single ‘yes’ (which could be the answer to the literal meaning of the question). It provides additional information, attempting to be more helpful.

U: Has any customer bought more QuickCams than ABA France?
S: ABA France hasn’t bought any QuickCams.
U: Has any customer bought more SmartCopiers than ABA France?
S: Yes, Power Inc. has bought 18.

Responses of this kind are known as cooperative, and in the general case require a user model to represent the user’s goals and beliefs (Chapter 7), a point that will be discussed further when presenting SDSs. In NLIs, however, relatively simple techniques often suffice (Kaplan 1982).

35.2.2.3 Portability tools

A significant amount of work on NLIs has been devoted to portability, i.e. the ability to reuse NLIs with different underlying applications (e.g. an operating system vs. a database) or in different domains (e.g. train ticket vs. payroll information). To achieve portability, NLI designers attempt to clearly separate those components that can be used across applications and domains from less portable ones, and to provide tools that allow the latter to be modified easily during a configuration phase (Grosz et al. 1987; Androutsopoulos, Ritchie, and Thanisch 1995; Androutsopoulos and Ritchie 2000).

35.2.3 The state of the art in NLIs

NLIs have been studied since the late 1960s (Woods, Kaplan, and Webber 1972), mainly for database querying. The current state of the art allows workable NLIs to be developed, and commercial database NLIs are available. The use of NLIs, however, is not as widespread as one might expect. This is usually attributed to the unclear linguistic capabilities of NLIs, the effort that is required to develop or configure an NLI, and the competition from graphical interfaces, which are often easier to configure and use (Whittaker and Stenton 1989; Bell and Rowe 1992; Decleva 1994). These points are considered bellow.
Every NLI has a limited coverage of linguistic phenomena. The boundaries of this coverage, however, are usually unclear, and users often have trouble formulating requests that the system can interpret. They may have to rephrase their requests until (if ever) a form that the NLI can interpret is reached – a frustrating experience. The problem can be alleviated, but not solved completely, using Wizard of Oz experiments (Chapter 7) to tailor the system’s coverage to the linguistic phenomena most likely to be found in user utterances, and robust parsing techniques to recover from parsing and interpretation failures. A related discussion on robust parsing can be found in section 35.3.2 below, Chapter 12, and elsewhere (Stallard and Bobro 1993; Bates et al. 1994).
To bypass the linguistic coverage problem one can move from stand-alone requests to dialogues. Knowledge about the typical dialogue structure and the user’s goals in a particular application domain can be used to fill in gaps left from the interpretation of the user’s utterances, and to sustain the dialogue until the system has a clear view of the task to be performed. This is the approach that dialogue systems (to be discussed next) adopt, and it appears to be practical with tasks that require relatively few parameters to be specified (e.g. ticket booking, on-line banking). With less standardized tasks (e.g. ad hoc querying of sales databases for marketing analysis) and in contexts where lengthy interaction is undesirable, other solutions are needed. In applications where the requests are short, menu-based NLIs may be workable (Tennant et al. 1983). In that case, the requests are formulated by selecting words from dynamically updated menus that reflect the linguistic coverage of the system, clarifying its capabilities. Multimodal interaction, the ability to combine language with gestures and graphics (Chapter 36), is a promising alternative, as it leads to linguistically simpler language interpretation failures (McGee, Cohen, and Oviatt 1998).
In terms of development or configuration effort, it seems most likely that graphical interfaces will maintain the lead. This suggests that NLIs that incorporate speech functionality may be more viable commercially for applications where graphical interaction is impractical or impossible (e.g. in hands-busy environments, such as cars). We shall return to future applications of NLIs after discussing dialogue systems, in the context of which speech issues have been studied to a larger extent.

35.3 SPOKEN DIALOGUE SYSTEMS

Let us now turn to spoken dialogue systems (SDSs), focusing on non-simulated human – machine dialogues (cf. Chapter 7).

35.3.1 The idiosyncrasy of spoken language input

SDSs involve spoken – rather than written – input, which is most often ungrammatical, incomplete, or even unintelligible. To exemplify these points, here is a hypothetical dialogue with an SDS, where what the user says is contrasted to what the system actually ‘understands’. Asterisks indicate one or more words what have not been recognized.
U: ErmHelloErm WhatD’You – I’dLikeSomeInformationOnaFlightaFlighttoAthens
[*hello * what * you * information * flight * flight to Aachen]
S: You want to fly to Aachen?
U: EhNoNoNotAachenAthensAthensIsaidAachenWhereIsAachenAnyway
[* no no Nottingham Aachen Athens * Aachen what is Athens airways]
S: So you want to fly to Athens?
U: YeahFinallyYouGotItIwantToLeaveFromGa – FromLondonGatwick
[yes * Gatwick I want * leave from *from London Gatwick]
S: You want to fly from London Gatwick?

The dialogue illustrated the difficulties involved in analyzing spontaneously spoken language. With continuous speech (Chapter 16), the input is a stream of sounds that cannot be broken down into individual words without some prior knowledge of the language and context. There are no pauses to separate words, on or punctuation to separate sentences. Here capital letters have only been used to help the reader identify the words.
Spontaneous utterances are also formed with limited time and cognitive resources, resulting in voiced gaps (erm), full or partial word repetitions (e.g. a flight a flight, Ga – Gatwick), false start and self-repair (e.g. what d’ you – I’d like, from Ga – from London Gatwick) (Levow 1998). Elliptical sentences (not Aachen, Athens) and anaphoric expressions (Chapter 14) are very frequent. Background noise may also be present (e.g. other people talking), and in telephone applications the channel quality will be lower and less predictable than with good studio microphone. The occurrence of extralinguistic phenomena, such as coughing and chuckling, is also unavoidable. Moreover, in contrast to speaker-dependent systems, in most SDSs the majority of user accents cannot have been encountered before (see also Chapter 16).

35.3.2 The architecture of SDSs

Fig. 35.2 provides a simplified overview of the typical SDS architecture, based on an amalgamation of knowledge sources and processing modules found across several different SDSs (Bernsen, Dybkjaer, and Dybkjaer 1998; Flycht-Eriksson 1999; Gallwitz et al. 1998; ISDS ’97; Smith and Hipp 1994; Veldhuijzen van Zanten 1996; Ward and Novick 1996; Young et al. 1989).

35.3.2.1 Word recognizer

The input speech signal is first processed by a word recognizer, which attempts to identify the words that were spoken on the basis of the words in the systems lexicon and predictions provided by other modules. (Related discussions can be found in Chapters 16 and 19.) The output of the recognizer is either a word chain or a word graph in the case of ambiguity. The following is an example of a user utterance and the corresponding word chain:

ErmHelloErmWhatD’You – I’dLikeSomeInformationOnaFlightaFlighttoAthens
[* hello * what * you * information * flight * flight to Athens]

35.3.2.2 Parser and semantic interpreter

The word chain (or graph) is passed on to the parser (Chapter 12). As the input is usually elliptical and often ungrammatical (e.g. in the case of self-repair), parsing has to be performed on ‘islands’ of words or phrases that can be processed in isolation but cannot be combined to make up a full sentence. Syntactic processing can be carried out in conjunction with a targeted shallow semantic interpretation of the utterance in the limited context of the application domain. Thus, heuristics are used to extract application parameters (e.g. departure airport and time) and fill in some kind of a frame structure (e.g. attribute-value pairs), much as in information extraction (Chapter 30). This eliminates irrelevant material from the input signal (such as the reason of travel in a flight information system), and delivers only the essential information to the dialogue manager (Fig. 35.2). The example below shows a possible frame structure produced from the word chain above:

[[greeting:hello], [dest_airport:Athens]]

As in the case of NLIs, a world model may be used during the semantic interpretation, for example showing the ontology of the application and sortal restrictions between entity types.

35.3.2.3 Task model

The task model contains knowledge about the tasks the user is likely to want to fulfill, especially the application parameter that need to be specified for each task. In an SDS for flight enquiries, the task model might include the following:

Search( [dep_date, dep_airport, dest_airport],
[dep_time_range, arr_time_range],
[flight_no, dep_time, arr_time])
Booking( [flight_no, dep_date, surname, initials], [], [status])
Cancellation( [flight_no, dep_date, surname, initials], [], [status])

The simplistic task model above lists three possible tasks: searching for a suitable flight, booking a seat on a flight, and cancelling a booking. For the first task, the departure date, departure airport and destination airport must always be specified, and the user may optionally specify a range for the departure or arrival time (all these are application parameters). The answer must report the flight number, and the exact departure and arrival times. In the booking and cancellation tasks, the flight number, departure date, passenger surname, and initials are needed, and the answer will report the status of the booking or cancellation. The SDS would exploit this task model to figure out which of the necessary application parameters have not been specified yet, and ask appropriate questions.

35.3.2.4 User model

A user model may also be present, which provides information about the user’s interests and represent what the system assumes to be the current user’s beliefs and goals. Related discussion can be found in Chapter 7 and elsewhere (Kobsa and Wahlster 1989). User models can be exploited, for example, to avoid reporting facts the user already knows, to identify information that is worth reporting even if it has not been explicitly requested, and to provide predictions about the next user utterance.

35.3.2.5 Discourse model

One of the main functions of the discourse model is to keep track of the discourse history. Apart from the entities that have been mentioned (useful for anaphora resolution purposes; see Chapter 14), the discourse history may show, for example, the dialogue acts (Chapter 7) associated with the user utterances and the system messages, along with related instantiations of application parameters. This s demonstrated in the following dialogue, where each utterance is followed by a discourse history entry (marked with ‘→’) recording the dialogue act and relevant application parameters.

S: On which day do you want to fly?
→system:[request:dep_date]
U: This Friday.
→user: [assert: [dep_date: 25.05,20001]]
S: Where do you want to fly to?
→system: [request: dest_airport]
U: Athens.
→user: [assert: [dest_airport: Athens]]
A history of the above type is useful, for example, when encountering elliptical user utterances (e.g. Athens), the meaning of which can be resolved only within the context of the previous dialogue exchange, a process known as anchoring (Alshawi 1992).
Apart from the discourse history, the discourse model often contains a representation of the typical dialogue structure in the particular application domain. To this effect, dialogue grammars (Chapter 7), often in the form of finite-state automata (FSAs; see Chapter 18) are used in many SDSs (Sutton et al. 1998). This is illustrated in Fig. 35.3, which shows an FSA model o a dialogue structure for flight enquiries. More elaborate discourse structures can be accommodated by employing statistical models (Nagata and Morimoto 1994; Reithinger et al. 1996) and machine learning techniques (Moeller 1997). The model of Fig. 35.3 accepts dialogues such as the following:

S: This is the Flight Info System. Name your destination airport.
U: Athens.
S: Which airport are you flying from?
U: Gatwick.
S: Sorry, I didn’t understand. Which airport are you flying from?
U: London Gatwick.
S: On which day do you want to fly?
U: Next Sunday.
S: What time do you want to leave?
U: Say, around 10 am.
S: The following two flights match your requirements: …
S: Thanks for ringing.

The ‘yes’/’no’ labels of Fig. 35.3 would in practice be tests, for example on the frame structures returned by the parsing and semantic interpretation, or on dialogue acts extracted from them, that would check if the user utterances contain the required information. (The absence of a label on an arc in Fig. 35.3 denotes an obligatory state transition. The OR signifies an alternative transition.) In some systems, each state has attached descriptions of messages to be generated whenever the state is entered. These may be canned texts (e.g. Which airport are you flying from?) or higher-level descriptions (e.g. system: [request: dep_airport]). States may also have attached predictions about the next possible user utterance, the idea being that at each dialogue state particular words or dialogue acts are more likely than others. These predictions can be exploited to improve the accuracy of the word recognizer and the parser.

35.3.2.6 Dialogue manager

The dialogue manager is the central module of a SDS. It exploits information provided by the world, task, user, and discourse models in order to:
• Anchor the frame structure representations of a user utterance in the current context (e.g. resolving anaphora and elliptical sentences, extracting dialogue acts and parameter values),
• Decide whether the system should generate a message, in which case a suitable representation of the message is passed to the message generator (Fig. 35.2),
• Decide whether the underlying application (e.g. database system) should be asked to perform some action (e.g. retrieve information), in which case a suitable command is passed to the application, possibly after invoking a translation stage similar to that of section 35.2.1.

The dialogue manager may also be responsible for the coordination and communication of the various modules. In the simplest case, the dialogue manager invokes each module individually, feeding it with input data and collecting its results. In more advanced systems, a blackboard mechanism may be in place (Erman et al. 1981), allowing the various modules to exchange data more freely in order to have mutual constraints limit the search space at each stage (Young et al. 1989; Ward and Novick 1996).
The dialogue manager may be based on dialogue grammars, as discussed above, or on more elaborate approaches, possibly involving plan recognition (Chapter 7). McTear (1999) provides a survey of possible approaches. The exact functions of the dialogue manager vary across different SDSs. In some systems certain of the above-mentioned tasks (e.g. anchoring) may be carried out by separate modules.

35.3.2.7 Message generator and speech synthesizer

Whenever a message is to be communicated to the user, the dialogue manager outputs a representation of the message. This may be a canned text, possibly with additional intonation mark-up, that can be passed directly to the speech synthesizer (Chapter 17)or it may be a higher-level description of the goals to be achieved by communicating the message. In the latter case, a message generator is present, which produces the surface form (text) of the message, employing techniques such as those described in Chapter 15. (To save space, Fig. 35.2 does not show resources related to language generation and speech synthesis.)

35.3.3 Initiative and dialogue flexibility

Generally, it is desirable to let the user take the lead in the course of the dialogue, at least until there is a communication problem or additional information is needed. This is illustrated below, where the user specifies the departure airport, the destination, and a time range for the flight, without waiting to be asked. The system then takes the initiative to confirm the destination, probably because the speech recognition confidence for the corresponding word was low, and then it detects that the departure date has not been specified.

S: Hello. This is you Flight Info System.
U: Hi, I’d like to find out about an evening flight from Gatwick to Athens please.
S: Did you say Aachen?
U: What? No, no, Athens.
S: On which day do you want to fly to Athens?

Systems of this type, that allow the initiative to be shared between the user and the system, are said to support mixed or variable initiative. In contrast, SDSs based on system initiative guide the user at every step, usually asking questions and expecting answers to those particular questions. There is also a third case, user initiative-based applications, where the system never takes the lead. The NLIs of section 35.2 involve user initiative. Another example is the following subdialogue with the BT MAILSEC email handling SDS (Williams 1996):

U: Do I have any messages from Peter?
S: You have two messages from Peter Wyard.
U: Do I have nay from David?

Selecting the appropriate initiative-sharing strategy requires a careful evaluation in the context of each application (Walker, Fromer, and Narayanan 1998; Haller and McRoy 1998/9). With dialogue managers based on plan recognition (Chapter 7), it is usually easier to support mixed initiative, with the cost of requiring elaborate inferencing to be performed in the course of the dialogue (Carberry 1990; Ferguson and Allen 1993; Smith and Hipp 1994; Traum 1996). To some degree, SDSs based on FSAs may be able to provide a similar effect by increasing the number of states and transitions, to model user utterances that do not answer directly system requests, jumps to previous topics, miscommunications, etc. FSA systems, however, still cannot avoid being rigid with respect to unpredictable situations, such as user-initiated counter-questions. Another problem with FSA systems is that their graph models become very difficult to design and maintain as the task complexity increases. This has instigated the development of generic dialogue-building tools, where short dialogue exchanges (e.g. subdialogues for specifying dates or credit card data) are saved as software libraries that can be reused in new applications (Baekgaard 1996; Aust and Schroeer 1998; Kolzer 1999).

35.3.4 Confirmation strategy

Equally important is the choice of confirmation strategy. It is often desirable to use implicit confirmations, at least when there have been no instances of misunderstanding:

U: I’d like to find out about a flight from Gatwick to Athens.
S: On which day do you want to fly from London Gatwick to Athens?

This is much more natural than explicitly asking for a confirmation of each application parameter, for example after every user utterance (Danieli and Gerbino 1995):

U: I’d like to find out about a flight from Gatwick to Athens please.
S: Do you want to fly from London Gatwick?
U: Yes.
S: Do you want to go to Athens?
U: Yes, yes.
S: On which day do you want to fly?

The other extreme of having no confirmations at all can sometimes be dangerous, because the system may misunderstand something and complete the task based on the wrong data. For some applications, it may be preferable to let the user select explicitly the confirmation (or initiative) strategy, as in ‘Implicit confirmations please’. (Litman and Shimei 1999). A more ambitious approach is to select the appropriate confirmation strategy automatically; for example, based on the confidence of the word recognizer or the parser (Smith 1997; Gallwitz et al. 1998).

35.3.5 The state of the art in SDSs

Research on dialogue-handling interaction systems can be traced back to ELIZA (Chapter 7), the keyboard-based system that pretended to be a consulting psychologist, scanning the user’s input for specific patterns that would trigger canned responses. SHRDLU (Winograd 1972), a keyboard-based goal-driven system for problem-solving in a toy blocks world, can also be seen as an early dialogue-handling system. Putting aside attempts to recognize isolated words, HEARSAY (Erman et al. 1981) was one of the first spoken language understanding systems, which also pioneered the use of a blackboard (englemore and Mordan 1988; Ward and Novick 1996; Aberdeen et al. 1999) for the communication between the system modules (section 35.3.2.6).
Since then, great progress has been made and numerous experimental SDSs have appeared, including systems for transport information (Zue et al. 1994; Veldhuidjen van Zanten 1996; Gallwitz et al. 1998), voice email (Williams 1996; Walker, Fromer and Narayanan 1998)planning and negotiation tasks ((Traum 1996; LuperFoy 1996; Kipp, Alexanderson and Reithinger 1999), telephone directory assistance, call centre automation and e-commerce (Minami et al. 1994; Vilnat 1996; Chu-Caroll and Car-Nugues et al. 1996; McGlashan 1996), computer-assisted instruction environments (LuperFoy 1996; Aberdeen et al. 1999), multilingual information retrieval (Aretoulaki et al. 1998), and many others. Several of these systems originate from research relate to the DARPA ATIS project (Air Travel Information Systems), which funded benchmark tests of different SDSs (Dahl 1995).
It seems likely that within the next two decades SDSs will become more common in real-life applications (Cole et al. 1995; Gibbon, Moore and Winski 1997; Aust and Schroeer 1998; Bernsen, Dybkjaer, and Dybkjaer 1998). Further research however, is still needed to develop, for example, more accurate speech recognizers, especially in noisy environments, reusable SDS components and system building tools (Baekgaard 1996; Aust and Schroeer 1998; Sutton et al. 1998; Kolzer 1999), improved user modeling (Young et al. 1989; Cole et al. 1993; Ward an Novick 1994; Flycht-Eriksson 1999) and emotion detection (Gallwitz et al. 1998) in order to dynamically adapt dialogue strategies to user behaviour, standards for SDS evaluation (Danieli and Gerbino 1995; Walker et al.1997; Walker et al. 1998; consult also Chapter 22), as well as flexible discourse models and techniques for the dynamic selection of initiative and confirmation strategies (Litman and Shimei 1999).

35.4 THE APPLICATIONS OF THE FUTURE

Section 35.2 and 35.3 have pointed to several applications where NLIs and SDSs are being explored. We conclude this chapter with a discussion of more ambitious forms of natural language interaction that may become possible in the longer term.
Modern households and offices are floored with increasingly sophisticated electronic devices. Video recorders, microwave ovens, fax machines – to name just a few appliances – all offer an ever-increasing and overwhelming number of functionalities. Navigating through the labyrinth of features and options with buttons and menus is very cumbersome. SDSs may in the future provide a solution, spoken dialogues being a more natural – and thus intuitively easier and more user-friendly – way of interaction, whether mono- or multimodal (McGlashan 1996; Nugues et al. 1996). Ongoing efforts to establish API standards for household and office appliances will play a crucial role towards that direction, as they will provide a uniform interface for SDSs to control these appliances.
Hands-busy environments where devices need to be controlled (e.g. cars) may also benefit from natural language interaction systems, probably in the form of speech-enabled NLIs. There is also a variety of possible device-controlling applications for users with special needs, ranging from simple speech-sensitive light switches to dialogue-based centralized home controllers. More conservative, but still challenging, are applications for accessing and navigating the World Wide Web using spontaneous speech. Related research aims to give greater to the blind and people who want to retrieve information from the web over the phone (Whalen and Patrick 1989; House 1995; Gallwitz et al. 1998; Boyle et al. 1999).

FURTHER READING AND RELEVANT RESOURCES

Several surveys of database NLIs exist (Perrault and Grosz 1988; Copestake and Sparck Jones 1990; Androutsopoulos, Ritchie, and Thanisch 1995; Androutsopoulos and Ritchie 2000), and they constitute a useful starting point for readers wishing to learn more about an NLIs. For more in-depth information on NLIs, readers are advised to consult Alshawi (1992), which provides a comprehensive description of a generic large-scale system that incorporates most of the modules of Fig. 35.1.
For SDSs, a good starting point is the book of Bernsen, Dybkjaer, and Dybkjaer (1998) and the handbook of Gibbon, Moore, and Winski (1997). McTear (1999) has written an extensive survey of the field; see also www.cs.cmu.edu/~aliceo/dialoglinks.html for a collection of publications from different research groups. Several specialized meetings on SDSs have been organized recently, and their proceedings constitute excellent overviews of the current approaches and applications (TWLT ’96; ISDS ’97; ISSD ’98; KRPDS ’99; SIGdial 2000). The special issue of Speech Communication on spoken dialogue (Shirai and Furui 1994) and the book of Smith and Hipp (1994) are also very useful sources of information. There is a special interest group on Discourse and Dialogue of the Association for Computational Linguistics; see www.sigdial.org. Related standards, resources, and best practice guidelines can be found at the web sites of the EAGLES project (http://coral.lili.uni-bielefeld.de/EAGLES), the DISC project (http://mate.nis.sdu.dk/isle and http://www.disc2.dk), and the VoiceXML Forum (http://www.voicexml.org). For those wishing to experiment with development tools for SDSs, we recommend the CSLU Speech Toolkit, available from cslu.cse.ogi.edi/toolkit, as a starting point.

Translation - Greek
ΚΕΦΑΛΑΙΟ 35

ΑΛΛΗΛΕΠΙΔΡΑΣΗ ΦΥΣΙΚΗΣ ΓΛΩΣΣΑΣ

Ίων Ανδρουτσόπουλος
Μαρία Αρετουλάκη

Περίληψη

Το κεφάλαιο αυτό εισάγει τον αναγνώστη στα συστήματα αλληλεπίδρασης φυσικής γλώσσας, τα συστήματα εκείνα που επιτρέπουν στους χρήστες τους να θέσουν αιτήματα σε προφορική ή γραπτή φυσική γλώσσα. Το κεφάλαιο παρουσιάζει τις κεντρικές έννοιες των συστημάτων αλληλεπίδρασης φυσικής γλώσσας, δίνοντας έμφαση σε δύο από τις πλέον μελετημένες μορφές τέτοιων συστημάτων: τις διεπαφές φυσικής γλώσσας και τα συστήματα προφορικού διαλόγου.

35.1 ΕΙΣΑΓΩΓΗ

Το κεφάλαιο αυτό αποτελεί εισαγωγή στα συστήματα αλληλεπίδρασης φυσικής γλώσσας. Ο όρος αυτός χρησιμοποιείται εδώ για να περιγράψει τις εφαρμογές που επιτρέπουν στους χρήστες να θέσουν κάποιο αίτημα σε έναν υπολογιστή σε φυσική γλώσσα. Τα αιτήματα του χρήστη μπορεί να είναι προφορικά ή γραπτά. Μπορεί να αποτελούνται από μεμονωμένες προτάσεις ή τμήματα διαλόγου. Επιπλέον, μπορούν να αναλυθούν με τη βοήθεια ρηχής ή βαθείας επεξεργασίας γλώσσας. Οι επιλογές αυτές παρέχουν στον σχεδιαστή του συστήματος ένα ευρύ φάσμα επιλογών, μεταξύ των οποίων μπορεί να επιλέξει τις καταλληλότερες για την εκάστοτε εφαρμογή.
Ο όρος διεπαφή φυσικής γλώσσας (ΔΦΓ) αναφέρεται κυρίως στα συστήματα αλληλεπίδρασης φυσικής γλώσσας όπου τα αιτήματα του χρήστη αντιμετωπίζονται – λιγότερο ή περισσότερο – ως μεμονωμένες προτάσεις και συχνά γίνονται αντικείμενα βαθιάς γλωσσολογικής ανάλυσης. Από τα τέλη της δεκαετίας 1960 πραγματοποιείται εκτενής έρευνα γύρω από τα συστήματα αυτά, κυρίως στο πλαίσιο της αναζήτησης σε βάσεις δεδομένων και με τη χρήση πληκτρολογίου για την εισαγωγή των αιτημάτων. Αργότερα, το ερευνητικό ενδιαφέρον στράφηκε προς τα συστήματα προφορικού διαλόγου (ΣΠΔ), όπου τα αιτήματα του χρήστη είναι προφορικά και δομούν έναν εξελισσόμενο διάλογο. Τα ΣΠΔ δίνουν μεγαλύτερη έμφαση στην ανάλυση του συνολικού διαλόγου και τη σχέση του με τις προθέσεις του χρήστη και συχνά χρησιμοποιούν ρηχή ανάλυση μεμονωμένων προτάσεων.
Το κεφάλαιο αυτό παρουσιάζει τις κεντρικές έννοιες των συστημάτων αλληλεπίδρασης φυσικής γλώσσας και επικεντρώνεται στις ΔΦΓ και στα ΣΠΔ, τις δύο πλέον σημαντικές, για την έρευνα, μορφές τέτοιων συστημάτων.

35.2 ΔΙΕΠΑΦΕΣ ΦΥΣΙΚΗΣ ΓΛΩΣΣΑΣ

Μεταξύ των εφαρμογών ΔΦΓ η αναζήτηση σε βάσεις δεδομένων βρίσκεται στο επίκεντρο του ερευνητικού ενδιαφέροντος (Perrault και Grosz 1988; Copestake και Sparck Jones 1990; Androutsopoulos, Ritchie, και Thanisch 1995; Androutsopoulos και Ritchie 2000). Οι συνήθεις ΔΦΓ επιτρέπουν την ανάκτηση πληροφορίας από μία υποκείμενη βάση δεδομένων με την πληκτρολόγηση αιτημάτων που αποτελούνται από μία φράση, όπως συμβαίνει στο παρακάτω παράδειγμα, όπου Χ και Σ συμβολίζουν τα αιτήματα του χρήστη και τις απαντήσεις του συστήματος αντίστοιχα.

Χ: Ποιοι πελάτες αγόρασαν SmartCopiers;
Σ: ABA France, QuickFly, Power Inc.
Χ: Πόσους SmartCopiers αγόρασε ο καθένας;
Σ: ABA France 15
QuickFly 12
Power Inc. 18
Χ: Πόσοι από αυτούς αγόρασαν και QuickCams;
Σ: Power Inc.

Παρόλο που η ενότητα αυτή αντλεί παραδείγματα από την αναζήτηση βάσεων δεδομένων, το μεγαλύτερο μέρος της συζήτησης ανταποκρίνεται και σε άλλες εφαρμογές ΔΦΓ, όπως οι ΔΦΓ με λειτουργικά συστήματα (Wilensky et al. 1988), τα ρομπότ (Crangle και Suppes 1994), ή τα συστήματα εικονικής πραγματικότητας (Wauchope et al. 1997).

35.2.1 Βασικές παράμετροι των ΔΦΓ

Το γράφημα 35.1 παρουσιάζει τη βασική αρχιτεκτονική των ΔΦΓ (προς το παρόν, αγνοούμε την εισαγωγή δεδομένων προφορικού λόγου, υποθέτοντας ότι ο χρήστης χρησιμοποιεί πληκτρολόγιο). Στις περισσότερες σύγχρονες ΔΦΓ τα αιτήματα του χρήστη μεταφράζονται σε κάποια γλώσσα σημασιολογικής αναπαράστασης (ΓΣΑ), η οποία δεν είναι παρά μια μορφή λογικής, και στη συνέχεια η ΓΣΑ μεταφράζεται σε φορμαλισμό υποστηριζόμενο από την υποκείμενη εφαρμογή (π.χ. μια γλώσσα βάσης δεδομένων). Παραδείγματος χάριν, είναι ευκολότερο να επαναχρησιμοποιηθούν τα συστήματα που μεταφράζουν από τη φυσική γλώσσα στη ΓΣΑ με διαφορετικές υποκείμενες εφαρμογές.
Το αίτημα του χρήστη θα υποβληθεί σε ένα στάδιο προ-επεξεργασίας, το οποίο περιλαμβάνει τις διαδικασίες της αναγνώρισης λεκτικών συμβόλων (Κεφάλαιο 10), μορφολογικής ανάλυσης (Κεφάλαιο 2) και της αναζήτησης σε βάση όρων (Κεφάλαιο 3). Σε ΔΦΓ βάσεων δεδομένων τα κύρια ονόματα (π.χ. SmartCopier) εμφανίζονται πολύ συχνά. Για την αναγνώρισή τους μπορούν να χρησιμοποιηθούν τεχνικές αναγνώρισης και ταξινόμησης ονομάτων (Κεφάλαιο 30).
Μετά την προ-επεξεργασία, τα δεδομένα που εισήγαγε ο χρήστης θα αναλυθούν συντακτικά και σημασιολογικά (Κεφάλαια 4, 5 και 12). Με τον τρόπο αυτό θα παραχθεί μία έκφραση ΓΣΑ. Σε μια ΓΣΑ όμοια με κατηγορηματική λογική πρώτης τάξης, η πρόταση (35.1) θα μπορούσε να αναπαρασταθεί όπως η (35.2). Το σύμβολο ‘?’είναι ένας ερωτηματικός ποσοδείκτης που προσδιορίζει ποιες μεταβλητές τιμές πρέπει να αναφερθούν. Η έκφραση (35.2) απαιτεί την αναφορά όλων των ονομάτων χ2, έτσι ώστε χ2 να είναι το όνομα ενός πελάτη χ1 και χ1 να έχει αγοράσει ένα SmartCopier x3. Για εξοικονόμηση χώρου, οι ελεύθερες μεταβλητές εδώ αντιμετωπίζονται ως υπαρξιακοί ποσοδείκτες. Ο χρόνος και το ποιόν ενεργείας αγνοούνται εντελώς (Androutsopoulos, Ritchie, και Thanisch 1998; Androutsopoulos 2002).

(35.1) Ποιοι πελάτες αγόρασαν SmartCopiers?
(35.2) ?x2 customer_name (x1,x2) ^ product_name (x2, SmartCopier) ^ purchase (x1,x3)

Οι εκφράσεις ΓΣΑ που προκύπτουν είναι συχνά υποκαθορισμένες (Κεφάλαιο 5), συνήθως ως προς τη σημασιολογία αναφορικών εκφράσεων, ελλειπτικών προτάσεων (π.χ. Και με τις QuickCams;) και ποσοδεικτών. Οι υποκαθορισμένες εκφράσεις ΓΣΑ επιλύονται κατά τη διάρκεια ενός σταδίου σημασιολογικής προεπεξεργασίας (Γράφημα 35.1). Στο Κεφάλαιο 14 παρατίθενται σχετικές τεχνικές, αλλά και αλλού (Alshawi 1992). Αντίθετα με τα ΣΠΔ, για τα οποία θα μιλήσουμε στην ενότητα 35.3, οι ΔΦΓ χρησιμοποιούν σχετικά απλά μοντέλα συνομιλίας (Κεφάλαιο 6). Αυτά συνήθως καταγράφουν μόνο οντότητες που έχουν προαναφερθεί, το σημείο στο οποίο έχουν αναφερθεί και ιδιότητες όπως το γένος και το σημασιολογικό είδος, τα οποία συμβάλλουν στην επίλυση της αναφορικής αμφισημίας (Barros και De Roeck 1994).
Επιπλεόν, οι ΔΦΓ συχνά συμβουλεύονται ένα μοντέλο της γνώσης του κόσμου, το οποίο παρουσιάζει την οντολογία της εφαρμογής (Κεφάλαιο 25), και τους περιορισμούς στις σχέσεις μεταξύ των διαφορετικών τύπων των οντοτήτων, οι οποίοι συχνά ονομάζονται επιλεκτικοί ή ειδολογικοί περιορισμοί (Alshawi 1992; Allen 1995). Η πρόταση (35.3) απεικονίζει τη χρήση τους. Η επιδιωκόμενη σημασία της (35.3) είναι η (35.4), ότι δηλαδή ο κάτοχος της άδειας είναι ο υπάλληλος. Ωστόσο, μία ΔΦΓ οφείλει να λάβει υπόψη και την (35.5), όπου δηλώνεται ότι η άδεια βρίσκεται υπό την κατοχή του υποκαταστήματος.

(35.3) Να αναφέρεις τους υπαλλήλους των υποκαταστημάτων του Παρισιού που είναι κάτοχοι άδειας οδήγησης.
(35.4) ?x2 employee_name (x1, x2) ^ branch_name (x3, x4) ^ city_name (x5, ‘Paris’) ^ works_at (x1, x3) located_in (x3, x5) ^ licence (x6) ^ for_driving (x6) ^ has (x1, x6)
(35.5) ?x2 employee_name (x1, x2) ^ branch_name (x3, x4) ^ city_name (x5, ‘Paris’) ^ works_at (x1, x3) located_in (x3, x5) ^ licence (x6) ^ for_driving (x6) ^ has (x3, x6)

Για να απορρίψει την (35.5) το μοντέλο της γνώσης του κόσμου θα πρέπει να περιλαμβάνει έναν περιορισμό ο οποίος να ορίζει ότι κάθε φορά που το δεύτερο όρισμα του has (x,y) είναι η άδεια οδήγησης, τότε το πρώτο όρισμα πρέπει να είναι ένα πρόσωπο και η οντολογία πρέπει να ορίζει ότι οι υπάλληλοι είναι πρόσωπα ενώ τα υποκαταστήματα όχι.
Οι εκφράσεις ΓΣΑ, αφού αναλυθούν πλήρως, μεταφράζονται σε φορμαλισμό ο οποίος υποστηρίζεται από την υποκείμενη εφαρμογή, παραδείγματος χάριν οι εντολές φλοιού κατά την διεπαφή με λειτουργικό σύστημα ή μία αλληλουχία ανακλήσεων API (διεπαφή προγραμματισμού εφαρμογών) κατά την αλληλεπίδραση με άλλες εφαρμογές. Στις ΔΦΓ βάσεων δεδομένων, η γλώσσα-στόχος είναι η SQLdatabase. Ακολουθεί η μετάφραση από την ΓΣΑ στην υποκείμενη εφαρμογή (π.χ. σε πίνακες βάσεων δεδομένων. Αυτή είναι η ‘πρωτόγονη μεταφραστική πληροφορία’ του γραφήματος 35.1). Στη συνέχεια, οι μεταφραστικοί κανόνες ορίζουν τον τρόπο με τον οποίο θα μεταφραστούν οι πιο σύνθετες εκφράσεις ΓΣΑ, επικαλούμενοι, με τη σειρά τους, άλλους κανόνες για τη μετάφραση απλούστερων υπο-εκφράσεων (Androutsopoulos και Ritchie 2000).

35.2.2 Άλλες παράμετροι των ΔΦΓ

Οι ολοκληρωμένες ΔΦΓ διαθέτουν επιπλέον παραμέτρους, οι οποίες δεν απεικονίζονται στο γράφημα 35.1. Παραθέτουμε μερικές στη συνέχεια.

35.2.2.1 Παραφραστής

Συχνά οι ΔΦΓ παράγουν παραφράσεις των εκφωνημάτων του χρήστη οι οποίες αντιστοιχούν στην ερμηνεία των εκφωνημάτων αυτών από το σύστημα. Η διαδικασία αυτή επιτρέπει στους χρήστες να ελέγξουν εάν τα αιτήματά τους έχουν ερμηνευθεί σωστά. Κάθε φορά που προκύπτει κάποια αμφισημία, παρουσιάζονται οι παραφράσεις των υποψήφιων ερμηνειών και ο χρήστης καλείται να επιλέξει την καταλληλότερη. Οι παραφράσεις παράγονται από την ΓΣΑ ή από τις εκφράσεις εφαρμογής-φορμαλισμού με τη βοήθεια μιας παραμέτρου που χρησιμοποιεί μεθόδους παραγωγής. Περαιτέρω σχετικές τεχνικές παρατίθενται στο Κεφάλαιο 15 και αλλού (De Roeck και Lowden 1986; Alshawi 1992).

35.2.2.2 Γεννήτρια αποκρίσεων

Οι περισσότερες ΔΦΓ επικεντρώνονται στη ανάλυση εκφωνημάτων από έναν χρήστη και δεν επιχειρούν να ξεκινήσουν διάλογο με τους χρήστες. Ως εκ τούτου, ο σχεδιασμός των αποκρίσεων του συστήματος είναι σχετικά εύκολος. Στις ΔΦΓ βάσεων δεδομένων, η απόκριση του συστήματος είναι συνήθως ένα σύνολο δεδομένων που προέρχεται από την επεξεργασία της πληροφορίας που έλαβε (π.χ. για την αφαίρεση εσωτερικών κλειδιών ή την αντικατάστασή τους με ονόματα).
Δυσκολότερη είναι η περίπτωση της παραγωγής κατάλληλων αποκρίσεων όταν τα αιτήματα του χρήστη δεν είναι ικανοποιήσιμα. Σε αυτήν την περίπτωση, το σύστημα πρέπει να εξηγήσει το λόγο για τον οποίο απέτυχε να ικανοποιήσει το αίτημα (π.χ. άγνωστη λέξη, πολύ περίπλοκη σύνταξη). Ιδιαίτερα απαιτητικά είναι τα αιτήματα που φέρουν λανθασμένες παραδοχές του χρήστη που δεν εκφράζουν κυριολεκτικά την επιθυμία του χρήστη. Από τις ερωτήσεις που ακολουθούν, στην πρώτη ερώτηση το σύστημα ανιχνεύει την λανθασμένη παραδοχή που δηλώνει ότι η ABA France αγόρασε την QuickCams και παράγει την κατάλληλη προειδοποίηση. Στη δεύτερη ερώτηση, δεν απαντά με ένα απλό ‘ναι’ (το οποίο θα ήταν επαρκής απάντηση στην κυριολεκτική σημασία της ερώτησης), αλλά παρέχει επιπλέον πληροφορίες σε μία προσπάθεια να εξυπηρετήσει το χρήστη.

Χ: Εκτός από την ABA France, αγόρασε κάποιος άλλος πελάτης QuickCams;
Σ: Η ABA France δεν αγόρασε QuickCams.
Χ: Υπάρχει πελάτης που να αγόρασε περισσότερα SmartCopiers από την ABA France;
Σ: Ναι, η Power Inc. αγόρασε 18.

Οι απαντήσεις αυτού του είδους ονομάζονται απαντήσεις συνεργασίας και απαιτούν ένα μοντέλο χρήστη για την αναπαράσταση των στόχων και των πεποιθήσεών του (Κεφάλαιο 7). Το στοιχείο αυτό θα συζητηθεί περαιτέρω στην ενότητα των ΣΠΔ. Για τις ΔΦΓ όμως, συχνά επαρκούν οι σχετικά απλούστερες τεχνικές (Kaplan 1982).

35.2.2.3 Εργαλεία φορητότητας

Η φορητότητα έχει απασχολήσει πολύ την έρευνα στον τομέα των ΔΦΓ. Πρόκειται για την ικανότητα επαναχρησιμοποίησης των ΔΦΓ με διαφορετικές υποκείμενες εφαρμογές (π.χ. ένα λειτουργικό σύστημα και μία βάση δεδομένων) ή σε διαφορετικά πεδία (π.χ. εισιτήρια τραίνου και πληροφορίες πληρωμών). Για να πετύχουν την φορητότητα, οι σχεδιαστές των ΔΦΓ προσπαθούν να διαχωρίσουν τις παραμέτρους εκείνες που μπορούν να χρησιμοποιηθούν ανεξαρτήτως εφαρμογής και πεδίου, και να παρέχουν εργαλεία που επιτρέπουν την εύκολη μετατροπή των υπόλοιπων παραμέτρων κατά τη φάση ρύθμισης (Grosz et al. 1987; Androutsopoulos, Ritchie, και Thanisch 1995; Androutsopoulos και Ritchie 2000).

35.2.3 Η σύγχρονη τεχνολογία ΔΦΓ

Οι ΔΦΓ έχουν αποτελέσει αντικείμενο μελέτης από τα τέλη της δεκαετίας του 1960 (Woods, Kaplan, και Webber 1972), κυρίως για χρήση στη διαδικασία της αναζήτησης σε βάσεις δεδομένων. Το σημερινό επίπεδο της τεχνολογίας επιτρέπει την ανάπτυξη χρηστικών ΔΦΓ και ήδη διατίθενται στο εμπόριο ΔΦΓ βάσεων δεδομένων. Ωστόσο, η χρήση τους δεν είναι τόσο διαδεδομένη όσο θα περίμενε κανείς. Αυτό αποδίδεται, συνήθως, στην θολή εικόνα των γλωσσολογικών ικανοτήτων τους, στην μεγάλη προσπάθεια που απαιτείται για την ανάπτυξη και τη ρύθμιση μιας ΔΦΓ και στην ύπαρξη ανταγωνισμού με τη μορφή γραφικών διεπαφών, οι οποίες παρουσιάζουν μεγαλύτερη ευκολία στη ρύθμιση και τη χρήση (Whittaker και Stenton 1989; Bell και Rowe 1992; Decleva 1994). Οι παράγοντες αυτοί αναλύονται στη συνέχεια.
Κάθε ΔΦΓ είναι ικανή να καλύψει ένα περιορισμένο αριθμό γλωσσολογικών φαινομένων. Ωστόσο, τα όρια της ικανότητας αυτής συνήθως δεν είναι ξεκάθαρα και οι χρήστες συχνά δυσκολεύονται να σχηματίσουν αιτήματα ερμηνεύσιμα από το σύστημα. Μπορεί να αναγκαστούν να ανασχηματίζουν συνεχώς τα αιτήματά τους μέχρι να καταλήξουν (εάν τα καταφέρουν) σε κάποια μορφή ερμηνεύσιμη από την ΔΦΓ – μία ιδιαίτερα κουραστική εμπειρία. Το πρόβλημα περιορίζεται (αλλά δεν λύνεται εντελώς) με τα πειράματα Wizard of Oz (Κεφάλαιο 7), τα οποία ρυθμίζουν το σύστημα ώστε να μπορεί να αντιμετωπίσει τα γλωσσολογικά φαινόμενα που είναι πιθανότερο να εμφανιστούν στα εκφωνήματα του χρήστη και με τεχνικές εύρωστης συντακτικής ανάλυσης, για την ανάνηψη από πιθανές αποτυχίες ανάλυσης και ερμηνείας. Παρακάτω, στην ενότητα 35.3.2, στο Κεφάλαιο 12 αλλά και αλλού (Stallard και Bobro 1993; Bates et al. 1994), παρατίθεται συζήτηση σχετική με την εύρωστη ανάλυση.
Μπορεί κανείς να προσπεράσει το πρόβλημα της γλωσσολογικής κάλυψης, περνώντας από τα μεμονωμένα αιτήματα στους διαλόγους. Η γνώση σχετικά με την φυσική δομή του διαλόγου και τους στόχους του χρήστη σε ένα συγκεκριμένο πεδίο εφαρμογής μπορεί να καλύψει τα κενά της ερμηνείας των εκφωνημάτων του χρήστη από το σύστημα και να διατηρήσει το διάλογο, έως ότου το σύστημα να διαμορφώσει μια καθαρή εικόνα της διεργασίας που πρέπει να διεκπεραιώσει. Αυτήν την προσέγγιση ακολουθούν τα ΣΠΔ (ακολουθεί εκτενέστερη ανάλυση) και αποδεικνύεται αποτελεσματική με διεργασίες που απαιτούν τη διευκρίνιση περιορισμένου αριθμού παραμέτρων (π.χ. έκδοση εισιτηρίων, ηλεκτρονικό σύστημα τραπεζικών συναλλαγών). Στις περιπτώσεις όπου οι διεργασίες είναι λιγότερο τυποποιημένες (π.χ. ad-hoc αναζήτηση σε βάσεις δεδομένων πωλήσεων για ανάλυση marketing) και σε εννοιολογικά πλαίσια όπου προτιμάται σύντομη αλληλεπίδραση, επιστρατεύονται άλλες λύσεις. Σε εφαρμογές όπου παρουσιάζονται σύντομα αιτήματα, μπορεί να αποδειχθούν ιδιαίτερα αποτελεσματικές οι ΔΦΓ που βασίζονται σε μενού (Tennant et al. 1983). Στην περίπτωση αυτή, τα αιτήματα διαμορφώνονται με την επιλογή λέξεων από μενού που ενημερώνονται με δυναμικό τρόπο και που αντιπροσωπεύουν την ικανότητα γλωσσολογικής κάλυψης του συστήματος. Ενδιαφέρουσα εναλλακτική αποτελεί η πολυτροπική αλληλεπίδραση, η ικανότητα συνδυασμού γλώσσας με κινήσεις και γραφικά (Κεφάλαιο 36), η οποία οδηγεί σε γλωσσολογικά απλούστερες αποτυχημένες προσπάθειες γλωσσικής ερμηνείας (McGee, Cohen, και Oviatt 1998).
Σε επίπεδο προσπάθειας ανάπτυξης και ρύθμισης, φαίνεται πως οι γραφικές διεπαφές θα παραμείνουν στην κορυφή. Αυτό σημαίνει ότι οι ΔΦΓ που ενσωματώνουν λειτουργικότητα ομιλίας μπορεί να είναι περισσότερο βιώσιμες εμπορικά για εφαρμογές όπου η γραφική αλληλεπίδραση είναι δύσκολη ή αδύνατη (π.χ. σε περιβάλλονται όπου τα χέρια είναι απασχολημένα, όπως κατά την οδήγηση). Θα επιστρέψουμε στην ανάλυση των μελλοντικών εφαρμογών των ΔΦΓ αφού συζητήσουμε για τα συστήματα διαλόγων, στο εννοιολογικό πλαίσιο όπου τα ζητήματα που αφορούν στην ομιλία έχουν μελετηθεί εκτενέστερα.

35.3 ΣΥΣΤΗΜΑΤΑ ΠΡΟΦΟΡΙΚΟΥ ΔΙΑΛΟΓΟΥ

Τώρα θα στραφούμε στα συστήματα προφορικού διαλόγου (ΣΠΔ), με επίκεντρο τους διαλόγους μεταξύ ανθρώπου – μηχανής, χωρίς διαμεσολάβηση.

35.3.1 Η ιδιοσυγκρασία της εισόδου προφορικής γλώσσας

Τα ΣΠΔ περιλαμβάνουν την είσοδο προφορικών – αντί γραπτών – δεδομένων, τα οποία, τις περισσότερες φορές, είναι ασύντακτα, ελλιπή, ακόμη και ακατανόητα. Ακολουθεί ένας υποθετικός διάλογος με ένα ΣΠΔ, όπου αυτό που ο χρήστης λέει αντιπαρατίθεται σε αυτό που το σύστημα ‘καταλαβαίνει’ στην πραγματικότητα. Οι αστερίσκοι δηλώνουν τη λέξη ή τη σειρά λέξεων που δεν αναγνωρίζει το σύστημα.

U: ErmHelloErm WhatD’You – I’dLikeSomeInformationOnaFlightaFlighttoAthens
[*hello * what * you * information * flight * flight to Aachen]
S: You want to fly to Aachen?
U: EhNoNoNotAachenAthensAthensIsaidAachenWhereIsAachenAnyway
[* no no Nottingham Aachen Athens * Aachen what is Athens airways]
S: So you want to fly to Athens?
U: YeahFinallyYouGotItIwantToLeaveFromGa – FromLondonGatwick
[yes * Gatwick I want * leave from *from London Gatwick]
S: You want to fly from London Gatwick?

Ο διάλογος αυτός απεικονίζει τις δυσκολίες που αντιμετωπίζει η ανάλυση αυθόρμητης προφορικής γλώσσας. Στην περίπτωση της συνεχόμενης ομιλίας (Κεφάλαιο 16), τα δεδομένα που εισάγονται δεν είναι παρά μία αλληλουχία ήχων που δεν είναι δυνατόν να διαχωριστούν σε μεμονωμένες λέξεις χωρίς κάποια προηγούμενη γνώση της γλώσσας και του εννοιολογικού πλαισίου. Δεν υπάρχουν παύσεις μεταξύ των λέξεων, ούτε σημεία στίξης μεταξύ των προτάσεων. Εδώ τα κεφαλαία γράμματα χρησιμοποιήθηκαν μόνο για τη διευκόλυνση του αναγνώστη.
Επιπλέον, τα αυθόρμητα εκφωνήματα δημιουργούνται σε περιορισμένο χρόνο και μέσα από περιορισμένους γνωσιακούς πόρους, με αποτέλεσμα να υπάρχουν φωνητικά κενά (Erm), ολόκληρες ή μερικές επαναλήψεις (π.χ. a flight a flight, Ga – Gatwick), λανθασμένη εκκίνηση και αυτοδιόρθωση (π.χ. what d’ you – I’d like, from Ga – from London Gatwick) (Levow 1998). Οι ελλειπτικές προτάσεις (not Aachen, Athens) και οι αναφορικές εκφράσεις (Κεφάλαιο 14) εμφανίζονται πολύ συχνά. Ακόμη, μπορεί να υπάρχει θόρυβος υποβάθρου (π.χ. άλλες ομιλίες), ενώ σε περιπτώσεις τηλεφωνικών εφαρμογών, η ποιότητα του καναλιού θα είναι χαμηλότερη και λιγότερο προβλέψιμη από εκείνη του επαγγελματικού μικροφώνου. Επίσης, αναπόφευκτη είναι και η εμφάνιση εξωγλωσσικών φαινομένων, όπως ο βήχας και το γέλιο. Τέλος, σε αντίθεση με τα εξαρτώμενα από το χρήστη συστήματα, στα περισσότερα ΣΠΔ η εκάστοτε διαφορετική προφορά των χρηστών αποτελεί απρόβλεπτο παράγοντα (βλ. και Κεφάλαιο 16).

35.3.2 Η αρχιτεκτονική των ΣΠΔ

Το διάγραμμα 35.2 παρουσιάζει μια απλοποιημένη μορφή της τυπικής αρχιτεκτονικής των ΣΠΔ, βασισμένη στο συνδυασμό πηγών γνώσεων και εργαλείων επεξεργασίας, κοινών σε αρκετά διαφορετικά ΣΠΔ (Bernsen, Dybkjaer, και Dybkjaer 1998; Flycht-Eriksson 1999; Gallwitz et al. 1998; ISDS ’97; Smith και Hipp 1994; Veldhuijzen van Zanten 1996; Ward και Novick 1996; Young et al. 1989).

35.3.2.1 Αναγνωριστής/Προσδιοριστής λέξεων

Το σήμα προφορικής ομιλίας εισάγεται και στη συνέχεια γίνεται αντικείμενο επεξεργασίας ενός αναγνωριστή λέξεων, ο οποίος επιχειρεί να προσδιορίσει τις προφορικές λέξεις αντιστοιχίζοντάς τες με λέξεις που περιλαμβάνονται στο λεξικό του συστήματος και τις προβλέψεις που του παρέχουν άλλα εργαλεία. (Στα Κεφάλαια 16 και 19 υπάρχουν σχετικές συζητήσεις). Τα δεδομένα που εξάγει ο αναγνωριστής μπορεί να έχουν είτε τη μορφή αλυσίδας λέξεων, είτε τη μορφή γραφήματος λέξεων, σε περίπτωση αμφισημίας. Ακολουθεί παράδειγμα εκφωνήματος χρήστη και της αντίστοιχης αλυσίδας λέξεων.

ErmHelloErmWhatD’You – I’dLikeSomeInformationOnaFlightaFlighttoAthens
[* hello * what * you * information * flight * flight to Athens]

35.3.2.2 Συντακτικός Αναλυτής και σημασιολογικός μεταφραστής

Η αλυσίδα (ή το γράφημα) λέξεων παραδίδεται στον συντακτικό αναλυτή (Κεφάλαιο 12). Καθώς τα εισαγόμενα δεδομένα είναι συνήθως ελλειπτικά και συχνά γραμματικά λανθασμένα (π.χ. η περίπτωση της αυτοδιόρθωσης), η συντακτική ανάλυση πρέπει να γίνεται σε ‘νησίδες’ λέξεων ή φράσεων, οι οποίες υπόκεινται σε επεξεργασία μεμονωμένα, αλλά δεν μπορούν να συνδυαστούν για να δημιουργήσουν μία ολόκληρη πρόταση. Η συντακτική επεξεργασία μπορεί να πραγματοποιηθεί σε συνδυασμό με την ρηχή σημασιολογική ερμηνεία-στόχο του εκφωνήματος στο περιορισμένο εννοιολογικό πλαίσιο του πεδίου της εφαρμογής. Έτσι, με τη χρήση ευρετικών μεθόδων εξάγονται οι παράμετροι της εφαρμογής (π.χ. αεροδρόμιο και ώρα αναχώρησης) και κατασκευάζεται ένα είδος δομής πεδίου (π.χ. ζεύγη χαρακτηριστικών-τιμών) όπως και στην εξαγωγή πληροφορίας (Κεφάλαιο 30). Η διαδικασία αυτή αποκλείει το άχρηστο υλικό του σήματος εισόδου (όπως ο λόγος για τον οποίο θέλει ο χρήστης να ταξιδέψει, σε ένα σύστημα πληροφοριών πτήσεων) και παραδίδει μόνο τις ουσιαστικές πληροφορίες στον διαχειριστή διαλόγου (Εικ. 35.2). Το παράδειγμα που ακολουθεί εκφράζει μία δομή πεδίου που θα μπορούσε να προκύψει από την παραπάνω αλυσίδα λέξεων:

[[greeting:hello], [dest_airport:Athens]]

Όπως συμβαίνει και με τις ΔΦΓ, έτσι και εδώ, κατά τη σημασιολογική ερμηνεία, μπορεί να χρησιμοποιηθεί ένα μοντέλο γνώσης του κόσμου το οποίο να παρουσιάζει, παραδείγματος χάριν, την οντολογία της εφαρμογής και τους ειδολογικούς περιορισμούς μεταξύ των διαφόρων τύπων οντοτήτων.

35.3.2.3 Μοντέλο διεργασιών

Το μοντέλο διεργασιών περιέχει πληροφορίες για τις διεργασίες που είναι πιθανόν να ζητήσει ο χρήστης και κυρίως την παράμετρο εφαρμογής που πρέπει να προσδιοριστεί κάθε φορά. Το μοντέλο διεργασιών ενός ΣΠΔ για αιτήματα πτήσεων θα μπορούσε να περιλαμβάνει τα ακόλουθα:

Search( [dep_date, dep_airport, dest_airport],
[dep_time_range, arr_time_range],
[flight_no, dep_time, arr_time])
Booking( [flight_no, dep_date, surname, initials], [], [status])
Cancellation( [flight_no, dep_date, surname, initials], [], [status])

Το απλουστευμένο αυτό μοντέλο περιλαμβάνει τρεις πιθανές διεργασίες: αναζήτηση της κατάλληλης πτήσης (search), κράτηση θέσης σε κάποια πτήση (booking) και ακύρωση της κράτησης (cancellation). Για την πρώτη διεργασία, πρέπει πάντα να προσδιορίζονται η ημερομηνία αναχώρησης, το αεροδρόμιο αναχώρησης και το αεροδρόμιο προορισμού, ενώ ο χρήστης μπορεί να επιλέξει να προσδιορίσει της ώρες αναχώρησης ή άφιξης που προτιμά (όλα αυτά είναι παράμετροι εφαρμογής). Η απάντηση του συστήματος πρέπει να παρέχει τον αριθμό πτήσης και τις ακριβείς ώρες αναχώρησης και άφιξης. Στις διεργασίες κράτησης και ακύρωσης, πρέπει να προσδιορίζονται ο αριθμός πτήσης, η ημερομηνία αναχώρησης, το επίθετο του επιβάτη και τα αρχικά του, ενώ η απάντηση του συστήματος παρέχει την κατάσταση της κράτησης ή της ακύρωσης. Το ΣΠΔ θα εκμεταλλευόταν αυτό το μοντέλο διεργασιών για να εντοπίσει ποιες από τις απαιτούμενες παραμέτρους δεν έχουν προσδιοριστεί και να υποβάλει τις ανάλογες διευκρινιστικές ερωτήσεις.

35.3.2.4 Μοντέλο χρήστη

Μπορεί, ακόμη, να υπάρχει ένα μοντέλο χρήστη, το οποίο να παρέχει πληροφορίες σχετικά με τα ενδιαφέροντα του χρήστη και να αντιπροσωπεύει αυτά που το σύστημα πιστεύει ότι αποτελούν τις πεποιθήσεις και τους στόχους του χρήστη. Στο κεφάλαιο 7 παρέχεται σχετική συζήτηση, αλλά και αλλού (Kobsa and Wahlster 1989). Τα μοντέλα χρήστη μπορούν να χρησιμοποιηθούν, παραδείγματος χάριν, για τον αποκλεισμό, από τις απαντήσεις, δεδομένων γνωστών στο χρήστη, για τον προσδιορισμό πληροφοριών χρήσιμων για το χρήστη, ακόμη κι αν δεν έχουν ζητηθεί, και για την πρόβλεψη του επόμενου εκφωνήματος.

35.3.2.5 Μοντέλο συνομιλίας

Μια από τις βασικές λειτουργίες του μοντέλου συνομιλίας είναι να καταγράφει το ιστορικό συνομιλίας. Εκτός από τις οντότητες που προαναφέρθηκαν (οι οποίες χρησιμεύουν στην επίλυση της αναφορικής αμφισημίας, βλ. Κεφ. 14), το ιστορικό συνομιλίας μπορεί να προσδιορίσει, παραδείγματος χάριν, τις διαλογικές πράξεις (Κεφάλαιο 7) που σχετίζονται με τα εκφωνήματα του χρήστη και τα μηνύματα του συστήματος, καθώς επίσης τους σχετικούς προσδιορισμούς των παραμέτρων εφαρμογής. Αυτό απεικονίζεται στον ακόλουθο διάλογο, όπου κάθε εκφώνημα ακολουθείται από μία καταχώρηση ιστορικού συνομιλίας (η οποία συμβολίζεται με το ‘→’), η οποία καταγράφει τη διαλογική πράξη και τις σχετικές παραμέτρους εφαρμογής.

S: On which day do you want to fly?
→system:[request:dep_date]
U: This Friday.
→user: [assert: [dep_date: 25.05,20001]]
S: Where do you want to fly to?
→system: [request: dest_airport]
U: Athens.
→user: [assert: [dest_airport: Athens]]

Ένα τέτοιο ιστορικό μπορεί να φανεί χρήσιμο σε περιπτώσεις, παραδείγματος χάριν, όπου εμφανίζονται ελλειπτικά εκφωνήματα (π.χ. Athens), η σημασία των οποίων αναλύεται μόνο με τη βοήθεια του εννοιολογικού πλαισίου του προηγούμενου διαλόγου. Η διαδικασία αυτή ονομάζεται αγκύρωση (Alshawi 1992). Εκτός από το ιστορικό συνομιλίας, το μοντέλο συνομιλίας συχνά περιλαμβάνει μία αναπαράσταση της τυπικής διαλογικής δομής του συγκεκριμένου πεδίου εφαρμογής. Στο πλαίσιο αυτό, σε πολλά ΣΠΔ χρησιμοποιούνται γραμματικές διαλόγου (Κεφάλαιο 7), συχνά με τη μορφή αυτομάτων πεπερασμένων καταστάσεων (ΑΠΚ – βλ. Κεφάλαιο 18) (Sutton et al. 1998). Η εικόνα 35.3 παρουσιάζει ένα μοντέλο ΑΠΚ μιας διαλογικής δομής για αναζήτηση πτήσεων. Με τη βοήθεια στατιστικών μοντέλων είναι δυνατή η κατασκευή πιο λεπτομερών διαλογικών δομών (Nagata and Morimoto 1994; Reithinger et al. 1996) και τεχνικών μηχανικής μάθησης (Moeller 1997). Το μοντέλο της εικόνας 35.3 δέχεται διαλόγους όπως ο ακόλουθος:

S: This is the Flight Info System. Name your destination airport.
U: Athens.
S: Which airport are you flying from?
U: Gatwick.
S: Sorry, I didn’t understand. Which airport are you flying from?
U: London Gatwick.
S: On which day do you want to fly?
U: Next Sunday.
S: What time do you want to leave?
U: Say, around 10 am.
S: The following two flights match your requirements: …
S: Thanks for ringing.

Στην πραγματικότητα, οι ετικέτες yes/no της εικόνας 35.3 θα ήταν δοκιμές, παραδείγματος χάριν, των δομών πλαισίου που θα εξάγονταν από την συντακτική ανάλυση και τη σημασιολογική μετάφραση, ή των παραγόμενων διαλογικών πράξεων. Οι δοκιμές αυτές θα έλεγχαν αν τα εκφωνήματα του χρήστη περιλαμβάνουν τις απαραίτητες πληροφορίες. (Η απουσία ετικέτας σε κάποια ακμή του γράφου στην παράσταση 35.3 δηλώνει ότι η μετάβαση είναι υποχρεωτική. Το OR δηλώνει μία εναλλακτική μετάβαση). Σε κάποια συστήματα, κάθε κατάσταση περιλαμβάνει ένα σύνολο περιγραφών για τα μηνύματα που πρέπει να παράγονται με την είσοδο στην κατάσταση αυτή. Αυτά μπορεί να είναι προκατασκευασμένα κείμενα (π.χ. Which airport are you flying from?) ή περιγραφές ανώτερου επιπέδου (π.χ. system: [request: dep_airport]). Επιπλέον, είναι πιθανό οι καταστάσεις να περιλαμβάνουν προβλέψεις για τα επόμενα πιθανά εκφωνήματα του χρήστη, ακολουθώντας τη λογική ότι σε κάθε διαλογική κατάσταση κάποιες λέξεις ή διαλογικές πράξεις είναι πιο πιθανό να προκύψουν από άλλες. Η εκμετάλλευση των προβλέψεων αυτών μπορεί να βελτιώσει την ακρίβεια του αναγνωριστή λέξεων και του συντακτική ανάλυση.

35.3.2.6 Διαχειριστής διαλόγου

Ο διαχειριστής διαλόγου είναι η κεντρική ενότητα του ΣΠΔ. Εκμεταλλεύεται τις πληροφορίες που λαμβάνει από τον κόσμο, τη διεργασία, το χρήστη και τα μοντέλα διαλόγου ώστε:

• Να αγκυρώσει τις αναπαραστάσεις της δομής πλαισίου ενός εκφωνήματος στο εκάστοτε εννοιολογικό πλαίσιο (π.χ. με την επίλυση της αναφορικής αμφισημίας και των ελλειπτικών φράσεων, με την εξαγωγή διαλογικών πράξεων και τιμών παραμέτρων),
• Να αποφασίσει αν το σύστημα πρέπει να παράγει κάποιο μήνυμα. Στην περίπτωση αυτή, παρέχεται στον παραγωγό μηνυμάτων η κατάλληλη αναπαράσταση μηνύματος (Παράσταση 35.2),
• Να αποφασίσει εάν πρέπει να ζητηθεί από την υποκείμενη εφαρμογή (π.χ. το σύστημα βάσης δεδομένων) να φέρει εις πέρας κάποια εργασία (π.χ. να ανακτήσει κάποια πληροφορία). Στην περίπτωση αυτή, παρέχεται στην εφαρμογή η ανάλογη εντολή, πιθανώς αφού περάσει από κάποιο στάδιο μετάφρασης, όμοιο με εκείνο της ενότητας 35.2.1.

Ο διαχειριστής διαλόγου μπορεί, ακόμη, να είναι υπεύθυνος για το συντονισμό και την επικοινωνία διαφόρων ενοτήτων. Στην πιο απλή περίπτωση, ο διαχειριστής διαλόγου επικαλείται κάθε υποσύστημα ξεχωριστά, του παρέχει δεδομένα εισόδου και συγκεντρώνει τα αποτελέσματα. Σε πιο περίπλοκα συστήματα, μια εφαρμογή μαυροπίνακα (Erman et al. 1981) μπορεί να διευκολύνει την ανταλλαγή δεδομένων μεταξύ των διαφόρων ενοτήτων ώστε να εκμεταλλευτούν τους κοινούς περιορισμούς για να μειωθεί ο χώρος αναζήτησης σε κάθε στάδιο (Young et al. 1989; Ward and Novick 1996).
Ο διαχειριστής διαλόγου μπορεί να βασιστεί στις γραμματικές διαλόγου ή σε πιο περίπλοκες προσεγγίσεις, οι οποίες πιθανώς να περιλαμβάνουν αναγνώριση σχεδίου (Κεφάλαιο 7). Ο McTear (1999) παραθέτει μια σειρά από πιθανές προσεγγίσεις. Οι ακριβείς λειτουργίες του διαχειριστή διαλόγου διαφέρουν από το ένα ΣΠΔ στο άλλο. Σε κάποια συστήματα, ορισμένες από τις παραπάνω διεργασίες (π.χ. η αγκύρωση) μπορεί να διεκπεραιώνονται από διαφορετικά υποσυστήματα.

35.3.2.7 Παραγωγός μηνυμάτων και συνθέτης ομιλίας

Κάθε φορά που το σύστημα καλείται να εμφανίσει κάποιο μήνυμα στο χρήστη, ο διαχειριστής διαλόγου εξάγει μία αναπαράσταση του μηνύματος. Αυτό μπορεί να είναι ένα προκατασκευασμένο κείμενο, πιθανώς με τη συνοδεία σήμανσης επιτονισμού, το οποίο παραδίδεται απευθείας στον συνθέτη ομιλίας (Κεφάλαιο 17), ή μπορεί να είναι μια περιγραφή ανωτέρου επιπέδου των στόχων που πρέπει να επιτύχει το μήνυμα. Στη δεύτερη περίπτωση, ένας παραγωγός μηνυμάτων κατασκευάζει την επιφανειακή μορφή (κείμενο) του μηνύματος, χρησιμοποιώντας τεχνικές όπως εκείνες που αναφέρθηκαν στο Κεφάλαιο 15. (Ελλείψει χώρου η παράσταση 35.2 δεν απεικονίζει πηγές που σχετίζονται με την παραγωγή γλώσσας και τη σύνθεση ομιλίας.)

35.3.3 Πρωτοβουλία και ελαστικότητα διαλόγου

Σε γενικές γραμμές, είναι προτιμότερο να επιλέγει ο χρήστης την πορεία του διαλόγυ, τουλάχιστον έως ότου προκύψει κάποιο πρόβλημα επικοινωνίας ή χρειαστεί επιπλέον πληροφορία. Στο παράδειγμα που ακολουθεί, ο χρήστης προσδιορίζει το αεροδρόμιο αναχώρησης, τον προορισμό και το χρονικό περιθώριο προτού του ζητηθούν. Το σύστημα αναλαμβάνει την πρωτοβουλία να επιβεβαιώσει τον προορισμό, πιθανώς λόγω της χαμηλής αυτοπεποίθησης του συστήματος αναγνώρισης ομιλίας για την αντίστοιχη λέξη, και στη συνέχεια, εντοπίζει ότι δεν έχει οριστεί η ημερομηνία αναχώρησης.

S: Hello. This is you Flight Info System.
U: Hi, I’d like to find out about an evening flight from Gatwick to Athens please.
S: Did you say Aachen?
U: What? No, no, Athens.
S: On which day do you want to fly to Athens?

Τα συστήματα αυτού του τύπου, που επιτρέπουν τόσο στο χρήστη όσο και στο σύστημα να αναλαμβάνουν πρωτοβουλία, ονομάζονται συστήματα που υποστηρίζουν μικτή ή μεταβλητή πρωτοβουλία. Αντιθέτως, τα ΣΠΔ που βασίζονται σε πρωτοβουλία συστήματος καθοδηγούν το χρήστη σε κάθε βήμα, κάνοντας ερωτήσεις και αναμένοντας απαντήσεις ανάλογες σε αυτές τις ερωτήσεις. Υπάρχει, ακόμη, μια τρίτη κατηγορία στην οποία ανήκουν οι εφαρμογές που βασίζονται στην πρωτοβουλία του χρήστη, στις οποίες το σύστημα δεν καθοδηγεί ποτέ το χρήστη. Οι ΔΦΓ της ενότητας 35.2 περιλαμβάνουν πρωτοβουλία χρήστη. Ένα άλλο παράδειγμα είναι ο παρακάτω υποδιάλογος με το ΣΠΔ διαχείρισης ηλεκτρονικής αλληλογραφίας BT MAILSEC (Williams 1996):

Χ: Έχω μηνύματα από τον Πίτερ;
Σ: Έχετε δύο μηνύματα από τον Πίτερ Ουίαρντ;
Χ: Από τον Ντέιβιντ;

Η επιλογή της κατάλληλης στρατηγικής καταμερισμού της πρωτοβουλίας απαιτεί προσεκτική αξιολόγηση του εννοιολογικού πλαισίου κάθε εφαρμογής (Walker, Fromer, and Narayanan 1998; Haller and McRoy 1998/9). Στις περιπτώσεις όπου οι διαχειριστές διαλόγου βασίζονται στην αναγνώριση σχεδίου (Κεφάλαιο 7), η υποστήριξη μικτής πρωτοβουλίας είναι συνήθως ευκολότερη, αλλά απαιτείται λεπτομερής συναγωγή κατά τη διάρκεια του διαλόγου (Carberry 1990; Ferguson and Allen 1993; Smith and Hipp 1994; Traum 1996). Τα ΣΠΔ που βασίζονται σε ΑΠΚ έχουν τη δυνατότητα, μέχρι κάποιο βαθμό, να επιτύχουν παρόμοιο αποτέλεσμα αυξάνοντας τον αριθμό των καταστάσεων και των μεταβάσεων ώστε να διαχειριστεί εκφωνήματα που δεν απαντούν ευθέως σε αιτήματα του συστήματος, άλματα σε προηγούμενα θέματα, επικοινωνιακά χάσματα κ.ο.κ. Ωστόσο, τα συστήματα ΑΠΚ παραμένουν δύσκαμπτα σε απρόβλεπτες καταστάσεις, όπως η χρήση ερώτησης από το χρήστη ως απάντηση σε ερώτημα του συστήματος.
Ένα άλλο πρόβλημα που παρουσιάζουν τα συστήματα ΑΠΚ είναι ότι η δυσκολία σχεδίασης και συντήρησης των γραφικών μοντέλων τους αυξάνεται ανάλογα με την περιπλοκότητά τους. Για το λόγο αυτό αναπτύχθηκαν γενικά εργαλεία κατασκευής διαλόγου, τα οποία συγκεντρώνουν σε βιβλιοθήκες λογισμικού σύντομους διαλόγους (π.χ. υποδιαλόγους για τον προσδιορισμό ημερομηνιών ή δεδομένων πιστωτικής κάρτας), ώστε να χρησιμοποιηθούν από νέες εφαρμογές (Baekgaard 1996; Aust and Schroeer 1998; Kolzer 1999).

35.3.4 Στρατηγική επικύρωσης

Εξίσου σημαντική διαδικασία είναι η επιλογή στρατηγικής επιβεβαίωσης. Συχνά, προτιμούνται οι υπονοούμενες επικυρώσεις, τουλάχιστον όταν δεν τίθεται ζήτημα επικοινωνιακών χασμάτων:

Χ: Θα ήθελα πληροφορίες για μία πτήση από το Γκάτγουικ στην Αθήνα.
Σ: Ποια μέρα θα θέλατε να πετάξετε από το Γκάτγουικ του Λονδίνου στην Αθήνα;

Ο παραπάνω διάλογος είναι πολύ πιο φυσικός από τον επόμενο, όπου το σύστημα ζητά επιβεβαίωση για κάθε παράμετρο της εφαρμογής, μετά από κάθε εκφώνημα του χρήστη (Danieli and Gerbino 1995):

Χ: Θα ήθελα πληροφορίες για μία πτήση από το Γκάτγουικ στην Αθήνα.
Σ: Θα θέλατε να πετάξετε από το Γκάτγουικ του Λονδίνου;
Χ: Ναι.
Σ: Θέλετε να πάτε στην Αθήνα;
Χ: Ναι, ναι.
Σ: Ποια μέρα θα θέλατε να πετάξετε;

Από την άλλη, η πλήρης απουσία επικυρώσεων μπορεί να έχει ως αποτέλεσμα το σύστημα να παρερμηνεύσει κάτι και να ολοκληρώσει τη διεργασία με λανθασμένα δεδομένα. Ίσως είναι προτιμότερο, για κάποιες εφαρμογές, να δίνεται η ελευθερία στο χρήστη να επιλέγει ο ίδιος την στρατηγική επικύρωσης (ή πρωτοβουλίας), παραδείγματος χάριν με την εντολή ‘αυτόματη επικύρωση’ (Litman and Shimei 1999). Μία άλλη φιλόδοξη προσέγγιση περιλαμβάνει την αυτόματη επιλογή της κατάλληλης στρατηγικής επικύρωσης: παραδείγματος χάριν, με βάση την αυτοπεποίθηση του αναγνωριστή λέξεων ή του συντακτικού αναλυτή (Smith 1997; Gallwitz et al. 1998).

35.3.5 Τα σύγχρονα ΣΠΔ

Η έρευνα γύρω από τα συστήματα αλληλεπίδρασης και διαχείρισης διαλόγου ξεκίνησε από το σύστημα ELIZA (Κεφάλαιο 7), ένα σύστημα βασισμένο σε πληκτρολόγιο που, προσποιούμενο τον ψυχολόγο, εντόπιζε συγκεκριμένα πρότυπα στα δεδομένα που εισήγαγε ο χρήστης και έδινε προκατασκευασμένες απαντήσεις. Αλλά και το SHRDLU (Winograd 1972), ένα στοχοστρεφές σύστημα βασισμένο σε πληκτρολόγιο, μπορεί να θεωρηθεί ως πρωτόγονο σύστημα διαχείρισης διαλόγου, με κεντρική λειτουργία την επίλυση προβλημάτων σε έναν μικρόκοσμο κύβων. Ακόμη, αν εξαιρέσει κανείς τη λειτουργία αναγνώρισης μεμονωμένων λέξεων, το HEARSAY (Erman et al. 1981) ήταν από τα πρώτα συστήματα κατανόησης προφορικής φυσικής γλώσσας, το οποίο, μάλιστα, χρησιμοποίησε για πρώτη φορά εφαρμογή μαυροπίνακα (englemore and Mordan 1988; Ward and Novick 1996; Aberdeen et al. 1999) για την επικοινωνία μεταξύ των υποσυστημάτων του συστήματος (ενότητα 35.3.2.6).
Από τότε μέχρι σήμερα έχουν εμφανιστεί αμέτρητα ΣΠΔ, μεταξύ των οποίων συστήματα παροχής πληροφοριών για μετακινήσεις (Zue et al. 1994; Veldhuidjen van Zanten 1996; Gallwitz et al. 1998), φωνητικής ηλεκτρονικής αλληλογραφίας (Williams 1996; Walker, Fromer and Narayanan 1998), διεργασιών σχεδιασμού και διαπραγμάτευσης (Traum 1996; LuperFoy 1996; Kipp, Alexanderson and Reithinger 1999), τηλεφωνικής βοήθειας, αυτόματων τηλεφωνικών κέντρων και ηλεκτρονικού εμπορίου (Minami et al. 1994; Vilnat 1996; Chu-Caroll and Car-Nugues et al. 1996; McGlashan 1996), περιβαλλόντων μηχανικώς υποβοηθούμενης διδασκαλίας (LuperFoy 1996; Aberdeen et al. 1999), πολύγλωσσης ανάκτησης πληροφορίας (Aretoulaki et al. 1998) και πολλά άλλα. Πολλά από αυτά τα συστήματα γεννήθηκαν με αφορμή την έρευνα που πραγματοποιήθηκε στο πλαίσιο του έργου DARPA ATIS , το οποίο χρηματοδότησε δοκιμές διαφόρων ΣΠΔ.
Φαίνεται πως μέσα στις επόμενες δύο δεκαετίες τα ΣΠΔ θα χρησιμοποιηθούν ευρέως σε πραγματικές εφαρμογές (Cole et al. 1995; Gibbon, Moore and Winski 1997; Aust and Schroeer 1998; Bernsen, Dybkjaer, and Dybkjaer 1998). Ωστόσο, θα χρειαστεί περαιτέρω έρευνα για την ανάπτυξη, παραδείγματος χάριν, ακριβέστερων συστημάτων αναγνώρισης ομιλίας, κυρίως σε περιβάλλον με πολύ θόρυβο, επαναχρησιμοποιούμενων υποσυστημάτων ΣΠΔ και εργαλείων ανάπτυξης συστημάτων (Baekgaard 1996; Aust and Schroeer 1998; Sutton et al. 1998; Kolzer 1999), βελτιωμένης μοντελοποίησης χρήστη (Young et al. 1989; Cole et al. 1993; Ward an Novick 1994; Flycht-Eriksson 1999) και αναγνώρισης συναισθήματος (Gallwitz et al. 1998), ώστε να προσαρμοστούν οι διαλογικές στρατηγικές στην ανθρώπινη συμπεριφορά και τα επίπεδα αξιολόγησης των ΣΠΔ (Danieli and Gerbino 1995; Walker et al.1997; Walker et al. 1998; consult also Chapter 22). Τέλος, μέσα από την έρευνα αυτή θα δημιουργηθούν συνομιλιακά μοντέλα και τεχνικές για την δυναμική επιλογή της πρωτοβουλίας και των μεθόδων επικύρωσης (Litman and Shimei 1999).

35.4 ΟΙ ΕΦΑΡΜΟΓΕΣ ΤΟΥ ΜΕΛΛΟΝΤΟΣ

Στις ενότητες 35.2 και 35.3 έγινε λόγος για διάφορες εφαρμογές στις οποίες ερευνάται η χρήση των ΔΦΓ και των ΣΠΔ. Ολοκληρώνοντας το κεφάλαιο αυτό, θα θέλαμε να αναφερθούμε σε κάποιες πιο φιλόδοξες μορφές αλληλεπίδρασης φυσικής γλώσσας που μπορεί να εμφανιστούν στο μέλλον. Τα σύγχρονα νοικοκυριά και γραφεία εξοπλίζονται όλο και περισσότερο με εκλεπτυσμένες ηλεκτρονικές συσκευές. Καταγραφείς εικόνας, φούρνοι μικροκυμάτων, συσκευές φαξ, – είναι μόνο κάποιες από τις σύγχρονες συσκευές – κάθε ένα από αυτά παρέχει πληθώρα λειτουργιών. Συχνά, ο λαβύρινθος αυτός από κουμπιά και επιλογές μπορεί να γίνει ιδιαίτερα κουραστικός. Τα ΣΠΔ μπορεί στο μέλλον να δώσουν τη λύση, καθώς ο προφορικός διάλογος αποτελεί έναν πιο φυσικό – και ως εκ τούτου ενστικτωδώς ευκολότερο και φιλικό προς το χρήστη – τρόπο αλληλεπίδρασης, μονοτροπικό ή πολυτροπικό (McGlashan 1996; Nugues et al. 1996). Ήδη γίνονται προσπάθειες να καθιερωθούν πρότυπα API για οικιακές συσκευές και συσκευές γραφείου, τα οποία θα επιτρέψουν τη καθιέρωση μιας κοινής διεπαφής για τον έλεγχο των συσκευών αυτών από ΣΠΔ.
Τα συστήματα αλληλεπίδρασης φυσικής γλώσσας, πιθανώς με τη μορφή ΔΦΓ συμβατών με ομιλία, μπορεί να φανούν ιδιαίτερα χρήσιμα και σε περιβάλλοντα όπου απαιτείται η χρήση κάποιας συσκευής ενώ τα χέρια είναι απασχολημένα με κάποια άλλη εργασία (π.χ. σε αυτοκίνητα). Επιπλέον, υπάρχει η περίπτωση δημιουργίας διαφόρων εφαρμογών ελέγχου συσκευής για χρήστες με ειδικές ανάγκες, από απλούς διακόπτες φωτός με αναγνώριση φωνής, μέχρι οικιακά συστήματα κεντρικού ελέγχου με υποστήριξη διαλόγου. Ακόμη, η έρευνα που ασχολείται με εφαρμογές πρόσβασης και πλοήγησης στο Διαδίκτυο με αυθόρμητη ομιλία, αν και συντηρητική, παραμένει δυναμική. Έμφαση δίνεται στις ανάγκες τ

Translation education Bachelor's degree - Ionian University, Department of translation
Experience Years of experience: 11. Registered at ProZ.com: May 2011.
ProZ.com Certified PRO certificate(s) N/A
Credentials English to Greek (Ionian University, Department of Foreign Languages, Translation & Interpreting)
Greek to English (Ionian University, Department of Foreign Languages, Translation & Interpreting)
French to English (Ionian University, Department of Foreign Languages, Translation & Interpreting)
French to Greek (Ionian University, Department of Foreign Languages, Translation & Interpreting)
Memberships N/A
Software Adobe Acrobat, Adobe Photoshop, Dreamweaver, Frontpage, Microsoft Excel, Microsoft Office Pro, Microsoft Word, Subtitle Workshop, SDL TRADOS, SDLX
CV/Resume English (DOCX), Greek (DOC)
Bio
No content specified


Profile last updated
Mar 30, 2015



More translators and interpreters: English to Greek - Greek to English - Spanish to English   More language pairs



Your current localization setting

English

Select a language

All of ProZ.com
  • All of ProZ.com
  • Term search
  • Jobs
  • Forums
  • Multiple search