Patent Grant
10073843
This invention relates generally to translation systems and more particularly real-time cross-lingual communication methods and systems.
Language differences constitute barriers that block communication everywhere. In enterprises, language is a barrier to contacts with foreign-speaking customers, partners, distributors, sales reps, employees, colleagues, research collaborators, foreign government counterparts, etc. In hospitals, it is a barrier between foreign-speaking patients and doctors. In the military, the language barrier impedes sharing updated information moment-to-moment among members of a multinational force. In the personal world, it is a barrier to communicating with overseas relatives, service providers, etc.
Human interpreters provide way of addressing language differences in live meetings and phone calls. However, such specialists are difficult to schedule and prohibitively expensive for spontaneous and/or informal communications. Similarly, human translators for written communications are very expensive, and may introduce unacceptably long delays. Currently available machine translation tools are unreliable, and the benefits of real-time communication and direct human contact are often lost. Furthermore, when currently available, relatively fragile translation tools are combined with similarly imperfect automatic speech recognition systems, errors are compounded in each step of processing, to the point where the result is often unintelligible. Such speech-to-speech machine translation systems permit little or no user intervention in the speech recognition or translation processes, beyond rewriting the input sentence. Thus the user has no control over how the system recognizes or translates a given spoken sentence, and the errors that result undermine the user's confidence in computer-mediated communication.
One particular obstacle for machine translation quality is the problem of word-sense disambiguation, i.e., of correctly identifying the sense in which a given word was intended in the input sentence. Existing automatic techniques have proven insufficient for disambiguation because 1) many sentences in common usage are elliptical or ambiguous and 2) semantically rich dictionary information that is necessary for accurate translation is available only in limited quantities, from diverse sources, and in diverse implementations.
Further exacerbating the problem is the fact that machine translation systems for different languages are developed by different providers, with diverse and often incompatible interfaces and implementations, making installation, maintenance, and use infeasible. The upshot is that no convenient, cost-effective solution currently exists for bridging the language gap, especially for impromptu or informal communication situations.
As a result, there is a need to solve the problems of the prior art to providing accurate and real-time machine translation.
Broadly speaking, the present invention fills these needs by providing a method and system enabling real-time speech and text translation. It should be appreciated that the present invention can be implemented in numerous ways, including as a method, a system, computer-readable media or a device. Several inventive embodiments and components of the present invention are described below.
In one embodiment, a method for mapping word senses across lexical resources is provided. The method begins by selecting a target term from a first lexical resource. Then, possible matches to the target term are identified from a second lexical resource. The method includes calculation of a semantic distance between possible matches to the target term and the target term. The possible matches to the target term are then ranked according to relevance. Then the target term from the first lexical resource is associated with one of the possible matches having the lowest semantic distance from the target term.
In another embodiment, a computer-readable medium having program instructions for mapping word senses across lexical resources is provided. The computer-readable medium includes program instructions for selecting a target term from a first lexical resource and program instructions for identifying possible matches to the target term from a second lexical resource. Program instructions for ranking the possible matches to the target term according to relevance and program instructions for calculating a semantic distance between possible matches to the target term and the target term are included. Program instructions for associating the target term from the first lexical resource with one of the possible matches having the lowest semantic distance from the target term are provided.
In yet another embodiment, a system providing cross-lingual communication is provided. The system includes a client component configured to capture speech and tactile inputs. The client component provides a user interface configured to display meanings for an input term. A translation of the input term into a different language than the input language and a back-translation or paraphrase of the translation are also displayed on the user interface. The system includes a server component configured to provide the meanings, the translation, and the back-translation to the client component based upon the input term. The server component includes an interaction manager configured to request the translation of the input term. The interaction manager is further configured to access Meaning Cues corresponding to the input term for presentation through the client component.
In still another embodiment, a cross-lingual communication system is once again provided. The system includes a multi-modal user interface. The system further includes an interaction manager in communication with the multi-modal user interface. The interaction manager has logic for providing semantic cross-indexing between a translation engine and a database of meaning information. The translation engine provides a translation for a term delivered by the interaction manager. The database of meaning information includes corresponding meaning information for the term delivered by the interaction manager.
In another embodiment, a graphical user interface (GUI) enabling computer-mediated communication is provided. The GUI includes a first region for displaying input terms in a first language. The GUI includes a second region for displaying Meaning Cues for each of the input terms. A third region of the GUI is provided for displaying a translation of the input terms in a second language. A fourth region of the GUI is included for displaying a back-translation in the first language. The back-translation is based upon the translation.
In yet another embodiment, a method enabling cross-lingual communication through speech and text machine translation is provided. The method starts by receiving a first and a second language selection. Then an expression in the first language is received. The expression in the first language is presented for verification. Then the verified expression is translated into an expression in the second language. The method includes confirming the meaning of terms within the verified expression in the first language and back-translating the expression in the second language to a back-translated expression in the first language. The back-translated expression in the first language is then verified.
Other aspects and advantages of the invention will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, illustrating by way of example the principles of the invention.
The present invention will be readily understood through examination of the following detailed description in conjunction with the accompanying drawings, in which like reference numerals designate like structural elements.
An invention is described which permits for the first time a highly interactive style of automatic speech-to-speech translation. The interactive procedures enable a user to recognize, and if necessary correct, errors in both speech recognition and translation, thus providing much more robust translation output than would otherwise be possible. Because of this enhanced robustness, automatic speech-to-speech translation can for the first time be practically extended to wide-ranging language structures and topics, beyond the boundaries of narrow domains such as hotel or airline reservations, without sacrificing accuracy to the point of impracticality. The techniques for interactive translation crucially include facilities for monitoring and correcting word ambiguity errors. To effectively choose word meanings in context, users require Meaning Cues (definitions, synonyms, examples, associated words, pictures, etc.). Such cues must be collected from disparate sources and correlated by word sense, and then aligned with, or mapped into, the word senses of third party lexical resources, such as those of a machine translation or search lexicon. This correlation and mapping can be carried out through the creation and use of a database of Meaning Cues, here called SELECT. Embodiments to be described permit the intelligent building and application of this database, which can be viewed as an interlingua, or language-neutral set of meaning symbols, applicable for many natural language processing tasks, including search and language instruction. As for interactive speech recognition techniques: immediate voice-driven or manual correction of dictation (very large vocabulary speech recognition) is also crucial to the operation of a practical speech-to-speech translation system at the state of the art. Innovative techniques to be described here permit such interactive correction even when a speech recognition engine is running on a remote server. It will be obvious, however, to one skilled in the art, that the present invention may be practiced without some or all of these specific details. In other instances, well known process operations have not been described in detail in order not to unnecessarily obscure the present invention.
The embodiments described herein are designed to make machine translation (MT) and speech recognition (SR) practical for cross-lingual communication, especially with respect to real-time or short-term exchanges, whether in person or via instant messaging, chat, and email. While the embodiments described below may incorporate spoken input through speech recognition software, the input may instead be typed, entered through a stylus, or entered through some other suitable non-speech input technique.
Described below are techniques for interactive monitoring and correction of (1) word meaning errors in translation and (2) speech recognition errors (even when the recognition engine is running on a server).
Interactive Correction of Word Meaning Errors During Translation.
For MT, the ability to verify or correct the meanings of words and expressions during translation enhances the subsequent translation quality. For example, in the sentence: “The old man sat on the bank,” the word “bank” is likely intended to mean “river bank.” However, the MT engine may wrongly assume that “savings bank” or “piggy bank” was meant instead, and may mistranslate accordingly. The embodiments described below enable users the ability to check for, and head off, such errors before translation is completed. Thus the errors are corrected before they can cause confusion or embarrassment.
As mentioned, to select appropriate meanings, users need effective Meaning Cues in their own language. The Meaning Cues provide definitions, examples, synonyms, associated words, pictures, etc., that help users to resolve ambiguous meanings. For example, in the present case, “bank” should have, or if necessary should be assigned, the meaning corresponding to the definition and example “The rising ground along a river or lake,” e.g., “We went fishing along the river's bank”. However, it is not at all trivial to assemble understandable Meaning Cues for a given MT engine and input language, since cues must be gathered from various sources (online dictionaries, thesauri, etc.) and each MT engine handles word senses differently. Further, even once usable Meaning Cues have been assembled, they must be presented understandably and ergonomically.
It should be appreciated that the “Meaning Cues,” a set of definitions, examples, synonyms, associated words, pictures, etc., are used to facilitate word sense selection. As described in more detail below, the algorithms and data structures, especially a central structure referred to as the SELECT database, are used to assemble Meaning Cues from available resources and to align them with the word senses of a particular MT engine used for translation. An interface effectively presents Meaning Cues to a user in order to enable verification or selection of a word sense in context prior to translation. In one embodiment, the entire system supports gradual learning of the user's preferred word senses with continued use, so that less interaction is required as time goes on, i.e., the system is capable of storing the user's preferences.
Interactive Correction of Speech Recognition Errors, Even when the Recognition Engine Runs on a Server.
Dictation, or speech recognition with truly broad coverage, can be distinguished from other current speech recognition (SR) technology in several respects. Dictation requires the creation and maintenance of individual voice profiles, also called acoustic models, for each user. In other words, a speaker-dependent variety of speech recognition is assumed herein. Currently, most dictation is still executed at the client, or local computer. Such local processing avoids problems related to audio transmission, voice profile maintenance, and scaling. Local processing may also simplify the creation of facilities for immediate visual feedback concerning recognized words. However, local processing imposes the limitation that users are tied to one particular computer. That is, the user can dictate from nowhere else, since the speech recognition application and the individual voice profile remain loaded only at the client.
Services that let users dictate from anywhere by telephone lack the feedback and correction facilities described herein. As a result, users cannot see the resulting text, and correction is possible only in a post-processing phase after speech recognition for the entire dictation session is finished. Furthermore, unlike the speech recognition itself, this post-processing must be carried out using a client-based, as opposed to server-based, program. The embodiments described herein enable full graphic feedback and voice-driven or typed correction for server-based dictation. That is, the feedback and correction facilities have been extended to the online or server-based dictation world through the embodiments described herein, which include, among other things, techniques for audio transmission, voice profile maintenance, and scaling related to server-based feedback and correction of dictation.
System for Highly-Interactive Automatic Speech-to-Speech Translation.
In addition, techniques for concatenating interactive dictation and interactive machine translation to yield practical speech translation systems are described in more detail below. In one embodiment, speech recognition is separated from machine translation, and interactive correction is provided for both stages. As mentioned, these techniques allow speech-to-speech translation systems to reach unprecedented levels of output quality, even while permitting unprecedented linguistic and topical coverage, i.e., freedom to choose vocabulary and linguistic structures, and to move from topic to topic.
As explained further below, the cross-lingual system of
Interaction manager module 106 then outputs the transcription of the spoken phrase for display on multi-modal user interface 108. At this point, a user is able to immediately correct or change the transcription, even though speech recognition may be operating at a server. Any user selections or choices are communicated from client 100 to IM 106 in order to verify the transcription. Once the transcription has been verified, a user may initiate its translation through multi-modal user interface 108, which in turn transmits the captured instruction to IM 106. Machine translation engine 112 is in communication with IM 106 and provides meanings corresponding to each term of an utterance to be translated. In one embodiment, machine translation engine 112 provides a list of options for translation of a certain term. Machine translation engine 112 includes dictionary database 111. Dictionary database 111 stores meanings associated with the particular term being translated, but generally in machine-readable form only. Once the translated term is retrieved, IM 106 accesses SELECT database 114 in order to obtain human-readable Meaning Cues for the term being translated. As will be discussed further below, the Meaning Cues are one or more descriptions for each sense of a term that is being translated.
Server component of
SELECT database 114 of
Machine translation engine 112 of
A more detailed discussion of the SELECT database of Meaning Cues and the algorithms used to construct it and align it with third party lexical resources is provided below. For illustrative purposes, details will be given for both rule-based and statistical machine translation engine types.
The SELECT Database and Related Algorithms.
It should be appreciated that different lexical resources (like dictionaries, thesauri, collocation lists, etc.) provide various sorts of information about words and their senses. To make best use of lexical resources including machine translation engine dictionaries, robust methods are needed for aligning the information across resources, not by words, but by word senses. For example, the “financial institution” sense of “bank” in WEBSTER is associated with this sense's definition, etymology, pronunciation and example sentences, while the same sense in ROGET is instead associated with the correct superordinate and subordinate terms. In the SELECT database, all of this information is brought together under a uniquely identified word sense symbol. Similar alignment may be performed on resources in different languages so that the correct translation, definition, example sentences, etc., for the same concept in either language may be accessed. If the same scheme is extended to multiple languages, SELECT can serve as an interlingua, or language-neutral set of meaning symbols usable for many natural language processing tasks.
Unfortunately, each lexical resource uses a different categorization scheme (or “ontology”) to organize word senses or meanings. It is simply not possible to map directly from one scheme to the next because the category names and the ways of dividing and grouping word senses are different. If the categorization scheme is seen as an acyclic graph or “tree,” both the topology and the node labels are different from ontology to ontology, even if the same concepts are present as the “leaves” of the tree.
Solutions to this resource-alignment or ontology-mapping problem are often based on the observation that, even if the trees or classification schemes are different, in all of them the classes are defined as groups of terms (or “leaves”), often represented as synonym lists or “synsets.” These groupings or classes correspond to concepts, and the term lists which compose them constitute vectors of attributes. Thus concepts from distinct systems can be compared, since the more terms two concepts have in common, the more similar they can be considered. The term list within a concept can thus be taken to represent its “profile.” In the most general terms, then, the algorithm proposed here for intermapping or correlating two ontologies or sets of word sense classes proceeds as follows: it takes as input two Profiles, each a list of synonyms or other terms corresponding to a particular word sense in one of the ontologies, and computes how “close” or “associated” the two Profiles are, i.e., computes their semantic distance. Given a list of candidate word-sense Profiles which might be judged equivalent to the current input word sense, the algorithm chooses the best (most overlapping and thus most similar) one.
The available information about a term (word or expression) to be handled by the word-sense mapping algorithm varies widely. In the general case, only the term (the word or expression itself) is used as input to the algorithm, and information about its senses is retrieved from the current resource, e.g. the translation lexicon of a machine translation vendor like Word Magic. For each resource, at least some information concerning the current term (word) is generally available, e.g., a definition, translations, synonyms and/or related words, etc. In one embodiment, when there are multiple senses for the target term in the current resource, they are processed (mapped to the senses of another ontology, e.g. SELECT) one by one. For processing of one such word sense to proceed, some Profile of synonyms and/or related words must be constructed. As explained, this Profile is a vector of terms which can serve as indicators of the word sense in question. Profile generation can be carried out in various ways, and is a significant step in the intermapping of ontologies by word sense, because the Profiles are the principal indicators of the word senses involved.
For each sense in the SELECT database, several pieces of information may be available, e.g., a list of synonyms, a definition, lists of superordinate and subordinate terms, example sentences, a unique identifier, or links to equivalent concepts in other resources (e.g., ROGET, WEBSTER, WORDMAGIC, LINGENIO, etc). Of particular interest for mapping is the list of synonyms, since this list constitutes the Profile for that SELECT sense. Additional information contained within the Profile may also include other related words, such as hyponyms, hypernyms, and neighboring semantic terms. As used herein, neighboring semantic terms refer to terms within a radius of a certain semantic distance of a target term. In one embodiment, the semantic distance is set within two links to be considered a neighboring semantic term. For example, a term that includes the target term (a hypernym) may be referred to as one link, a term that includes a term of the hypernym is a neighboring semantic term within two links, and so on. In one embodiment, this relationship is between the sibling nodes of a tree. Of course any number of links may be used, as two links is exemplary and not meant to be limiting. This information can be used in several ways when attempting to map a target term from the current ontology to the most similar word sense in the SELECT database. The first step is to generate candidate word senses in SELECT, which can then be tested for closeness to the word senses of the target term. These candidate word senses may be generated by the following techniques: by target term, by Profile, by definition, and/or by components of the target term. Each of these techniques is briefly described below.
When generating candidate word senses by target term, the candidates become all SELECT database word senses whose Profiles (synonym lists) contain the target term. These candidates are added to selectSenseList. If the target term is not in the Profile of any SELECT word sense (as may be the case), the algorithm continues to generate candidates by other means listed below.
By Profile:
If the incoming information for the current target term is associated with a Profile (a list of synonyms/related words), then, for each synonym etc. in that Profile, all SELECT word senses whose Profiles contain that synonym are fetched and added to selectSenseList. (For the WORDMAGIC machine translation engine, the terms in the Profile of each word sense have already been disambiguated and given the correct wordMagic_id, thereby making them quite reliable indicators.)
By Definition:
Candidates become all word senses from the SELECT database whose definition includes the target term. As usual, all candidates are added to selectSenseList. For example, when attempting to map a certain word sense of “bank”, a SELECT word sense for “investment” might become a candidate if it contained the word “bank” in its definition.
By Components of the Target Term:
If a compound target term (an expression containing several words) was not found in SELECT, then all of the senses for each noun, verb, adjective or adverb in the target term expression are used to identify word sense candidates to be added to the selectSenseList. For example, when attempting to map the multi-word term “savings bank,” the word “bank” would be used to retrieve a candidate word sense for “bank”.
Once the SELECT candidates for the target term have been identified through these techniques, these candidates are ranked according to a weighted frequency. The idea here is that the SELECT word senses have been fetched most frequently as candidates by any of the above techniques are most likely to match the incoming target word sense. For instance, if a given SELECT candidates has been fetched as a candidate match for the target term, and also for its synonyms (when fetching by Profile), and also when fetching using the definition, then this particular word sense gains evidence as a plausible match. In one embodiment, different weights are assigned to each candidate word sense depending on the method of fetching it (its “source”) and how “informative” it is. Each time a selectSense appears, a weight is associated to it. In one embodiment, the weight is assigned by the source and informativity of the candidate as follows: profile (15), definition (10), component term (10) and by informativity (1/number of SELECT senses found as candidates). Here the numbers shown in parentheses as relative weight factors are provided for exemplary purposes only.
Once the list of candidate SELECT word senses has been gathered, a filter may be applied to organize it. In one embodiment, candidates with a frequency below 2 and duplicates are first removed. The top three candidates are then extracted from the lists fetched using the target term and Profile techniques. Then the top three candidates from the other techniques (definition, and components of target term) are identified. These 6 best SELECT candidates are then returned as the final list of matching candidates. Finally, in order to select the best mapping for every word sense of the input term, the Profiles of all input word senses and those of all candidate SELECT word senses are compared pairwise, to check all possible correspondences. (It should be appreciated that the SELECT candidates are ranked as described in the previous paragraph only when there are several SELECT candidates available for the input word sense being processed, or when there are several input word senses.)
When constructing the SELECT database, a new “MapSet” is built which includes a sorted array of “MapObjects,” one for each possible mapping between a resource word sense and a SELECT word sense. In building the MapSet, MapObjects are manipulated: they are tested for statistically significant differences between competing mappings, ordered, and sometimes discarded. As explained earlier, the score of an attempted match or mapping between a target word sense and a SELECT word sense depends on the degree of overlap between their respective Profiles. Various techniques can be used for evaluating the degree of overlap. In one embodiment, an Association value is computed for each possible mapping (map object). A Significance score can then be computed to compare possible mappings based upon their respective Association scores: Significance of the difference between the best two mappings is a function of the logarithm of the ratio Best Option Association/Second-Best Option Association.
A MapObject is an array of information about a possible mapping between a single resource sense and a single SELECT sense. The two key pieces of information produced in building a MapObject are the weighted Overlap (vector dot product) between the profiles of the two senses being compared, and the Association computed for that overlap. As input for the construction of a MapObject, we need information about the two senses being mapped, i.e., their respective Profiles (list of synonyms). When the same term appears in both profiles, the Overlap for the current MapObject is increased by 1*weight, where the weight can be computed in several ways, according to the input parameters. Weight can be a function of the current term's length (for instance, “savings bank” is longer than “bank”, see below), or its “informativity” (see below), or both, or neither.
“Informativity” is a measure of the ambiguity of the matched term, i.e., its reliability as an indicator of a given sense. Informativity is simply 1 divided by the number of senses found for the term in SELECT. If “bank” has 10 senses, its informativity is 0.10; if it has only 2, its informativity is 0.5. When informativity is used to compute the weight of an overlap, the weight is 1+informativity.
Term length, in number of words, is interpreted as an indicator of specificity of meaning. “National Savings bank” and “savings bank” are less ambiguous than (have more precise meanings than) “bank”. Thus if a longer, more precise term matches when two Profiles are compared, it is given more weight because it is a better indicator of a specific meaning. When length is used to compute the weight of an overlap, the weight is the length of the term matched. When using both length and informativity, the overlap is increased by length*(1+informativity) for each matched term.
Overlap is computed as a proportion of the size of the incoming profiles, to permit comparison across profiles of widely divergent sizes. In order to prevent the number of overlaps being hidden by the large size of a profile, a limit, e.g., 20 is imposed on the profile size, for the purposes of computing overlap.
Several measures of association (goodness of match or mapping between two word senses) have been implemented for use in the computeAssociation function. The specific measure and the size of relevant weights can be chosen as parameters for this function. In most general terms, all of these measures are defined in terms of the ratio of the size of the intersection of two sets to the size of their union. However, in one embodiment, one of the sets can be given greater importance by weighting it more heavily. If there is a match, the word is in both SELECT and in the resource, but the size of the profile is usually different, so that one match from a 20-item profile adds less to the distance score than one match from a 5-item profile. To compensate for this discrepancy, SELECT database terms are weighted (for example) three times more heavily than the resource to show that matches in the SELECT Profile are more important than matches in the resource profile. Of course, different weighting schemes may be applied to favor matches ion the SELECT Profile.
When all possible mappings between a target word sense and the SELECT database have been evaluated, it may occur that all of the candidate mappings are eliminated for lack of overlap, or for not meeting all threshold criteria. This situation is most often encountered when the target term simply is not found in SELECT. In this case, a new word sense representing the unmatched target word sense is added to SELECT. However, if there are several surviving mapping possibilities, and if the association computed for the first map option is significantly larger than that for the second map option (using a standard statistical procedure for assessing the significance of a difference, the t Test), then there is enough evidence to take the first mapping option as the correct one, and to record the successful mapping by adding the target word sense's identifier (its resource_id) to the SELECT word sense's record (its select_id). And finally, in some cases, the algorithm cannot (and often should not) decide between two surviving candidate SELECT senses as the closest to the target word sense, since the two SELECT senses are equally closely related. In this situation, all of the relevant word senses are displayed so that humans can select the best mapping.
As illustrated in
The SELECT database of Meaning Cues and the algorithms used to construct it and align it with third-party lexical resources have been described in detail. However, it should be appreciated that these details may vary depending upon the specific technology of machine translation engine(s) 112 of
Server-Based Interactive Correction of Dictation.
The server-based interactive dictation discussed herein is based on established technologies for distributed computing such as CORBA, Sun's Java RMI (Remote Method Invocation), and Microsoft's .NET Remoting services. As used herein, the term “remote invocation” refers to all such technologies.
Such models provide a framework for building applications which enable a client application to call methods and functions on server-based objects at runtime over TCP/IP or HTTP communication channels using syntax that, from the client code perspective, treats the remote object as if it is local. The notion of a proxy object is central to such distributed systems. A proxy object on the client stands in for the real object on the server, and underlying software manages the communication between proxy object and the server transparently.
One skilled in the art will appreciate the underlying mechanisms that enable such distributed systems to function, as these mechanisms are well known. The server-based dictation system discussed here allocates and manages third-party dictation engines on behalf of each user. This management includes an instance of the dictation engine itself for each user, as well as the associated speech profile for that user. Thus, all users effectively have access to their own personalized dictation systems, which will function properly and with low-latency on any distributed network. It is crucial that the dictation engine must natively support real-time correction (as does PHILIPS), so that this capability can be transparently passed through to the client. Remote invocation also supports load-balancing on multiple servers in such a way that the system can be scaled for use for thousands of simultaneous users. The fact that remote invocation supports multiple protocols (TCP/IP and HTTP) also provides for the issues that may arise in secure networks where firewalls are present.
Having described in detail techniques for interactive correction of both word sense errors in translation and speech recognition errors (even when the recognizer operates on a server), the cross-lingual communication system enabled by these interactive techniques is now described.
Cross-Lingual Communication System.
Referring to
The following use scenario repeats for clarity and further explains how the GUI, such as the GUI of
Users may indicate one or more preferred type of Meaning Cue from those available for the current translation direction. The Meaning Cues may be definitions, examples, synonyms, or associated (words). In one embodiment, the default is definitions plus examples, as shown above with reference to
Users can select parts of speech in the Part of Speech dropdown menu within the Change Meaning window. With reference to
Once the desired word meaning has been selected—through a click, by voice command, or through some other suitable selection technique—users can prompt incorporation of this meaning for renewed translation by clicking a button which indicates the way in which the selected word sense should be used: Use once, which is the default and may be activated by the RETURN key; Use for this session; or Use until further notice (which will update the user's personal translation resources at session shutdown time, thus tuning the system's behavior). It should be noted that these actions trigger complete renewed translation and repopulation of all three Translation Text Fields, just as when the Translate button is first pressed.
When users are satisfied with the current translation, they can send it to Instant Messaging, or some other suitable destination, using the Send command (This button becomes the default immediately after translation, so that sending can be executed simply by pressing the ENTER key.) Appropriate text will be displayed in the instant messaging transcript window. Depending on the settings in the Options dialog, the input text only, the output text only, or both may be shown; and text-to-speech may be generated. The text fields are automatically cleared after a Send command. However, users can manually use the Clear button to restart an utterance from scratch at any point, e.g. when the back-translation is questionable.
The Options menu will bring up a dialogue in which:
The Help menu gives access to online documentation and version and copyright information. It should be appreciated that the details of GUI use are provided for illustrative purposes and not meant to be restrictive.
Flowchart Diagram for Word-Sense Mapping.
Returning now to the method for mapping word senses across lexical resources in accordance with one embodiment of the invention,
Application of the Invention to Language Instruction.
An exemplary application for the use of the cross-lingual communication system for language instruction is described in detail below. Most simply, in one embodiment of the GUI for disambiguating word senses, the learner gains an awareness of multiple word meanings, thus learning to avoid the most classic translation errors arising from unsuspected ambiguity. However, we can also augment our interface specifically for instructional purposes. For instance, we can align each word in the translation with a source language gloss (in bold), so that students can immediately determine the meanings and functions of all foreign language words. We can also enable immediate access to translation dictionaries by double-clicking any source language or target language word. (Clicking an English word accesses the English-Spanish dictionary, while clicking a Spanish word brings up the Spanish-English dictionary.)
Further, instant text-to-speech for individual words, or for sequences of several words, in both languages may be enabled. For example, CTRL-left-click or some other shortcut or word sequence leads to pronunciation of a selected segment. As an additional augmentation, when the student uses the Change Word Meanings window to select a different meaning of a specified word, we can go beyond the present monolingual display by pointing to the translations corresponding to each word sense. Students can thus see how each word sense would be translated. For example,
Further, if the target language normally uses a non-romanized writing system, a transliteration or syllable rendering can be added to the interface. Here, for example, is how it might look in Japanese.
(eiga)
(usui maku)
Core Software Components.
The core software components of one embodiment of the invention are discussed below and are designated the Spoken application for convenience only. It should be appreciated that the components will be described for illustrative and explanatory purposes only, and are not intended to be limiting. In one embodiment, there are three principal Spoken services SpokenDictationService (speech recognition module 110 of
The SPOKEN service classes are described in more detail below.
SpokenDictationService
The SpokenDictationService class may in one embodiment have the following principal methods:
In one embodiment, the SpokenTranslationService class may have these principal methods:
The SpokenTTSService receives text and parameters indicating aspects of the voice to be produced, and outputs a corresponding audio file or stream.
It should be appreciated that the embodiments described above are not limited to symbolic, or rule-based, machine translation, where all aspects of such translation programs, such as grammatical patterns, the possible translations for specific words, etc., are programmed by hand. In other embodiments, the techniques described herein may be applied to statistical machine translation (SMT), in which comparable grammatical patterns and translation correspondences are automatically learned through statistical analysis of large corpora of human translations. Thus, the embodiments described herein may be integrated with statistical machine translation, as well as rule-based machine translation. In some embodiments, implementing the techniques to statistical machine translation enable the addition of interactive capabilities to existing statistical machine translation engines even if programmers are granted no access to the engines' code or input data. That is, the embodiments enable retrofitting of interactive capabilities even for statistical machine translation programs presented as “black boxes,” such as the statistical machine translation offered by GOOGLE™. Interactive SMT facilities are: useful for real-time verification and correction, and in addition the use of the feedback gained enables machine learning which can progressively improve the relevant SMT system's raw translation quality.
Meaning Cues, as discussed above, are sets of cues which explain the meanings of words or expressions for system users. When input words or expressions have multiple meanings, the cues let users know which meaning the system is presently using for translation. In our present translation systems, cues are presented using synonyms. For instance, a system may indicate that the word “cool” (in an input like “This program is cool”) currently (and erroneously) means “chilly, nippy, . . . ” The set of synonyms may be referred to as a synset for short. Users can then indicate preference for other meanings if necessary by specifying other synsets, e.g., “awesome, fantastic, great, . . . ” and can then obtain updated translations including the new meanings. In some embodiments, definitions, examples, pictures, and other cues may supplement synsets as Meaning Cues.
A Meaning Cues Set for a given word may be represented as follows:
Word1 (e.g. “cool”)
Meaning1 indicated through synset1 (e.g. “chilly, nippy, . . . ”)
Meaning2 indicated through synset2 (e.g. “awesome, great, . . . ”)
As described above, synsets are obtained and associated with existing machine translation lexicons in rule-based machine translation systems. In statistical machine translation (SMT) systems, similar results are obtained as follows:
Assume a standard SMT setup, consisting of a bi-corpus (a corpus in the input or source language along with its translation into the output or target language) and an SMT system. The SMT system may be word-based, phrase-based, hierarchical, or other.
Running the SMT system over the bi-corpus yields a translation model, including a translation phrase table—a table of associations between language and target language strings. Each association is annotated with a given probability that the current source will lead to a particular target.
The translation phrase table is run through a paraphrase extraction tool, e.g., Parex. The tool works by noting common translations—e.g. by recognizing, in the translation phrase table above, that both “cool” and “nippy” can be translated as French “frais”. The tool yields a paraphrase table in the following format:
This expression indicates that, in a given language, phrase1 (the reference phrase) can be paraphrased by phrase2 (a paraphrase) with probability prob. That is, prob is the probability of the paraphrase given the reference. For example:
Each line in the paraphrase table gives a pair of synonyms. Several such lines can be brought together to provide synsets (sets of synonyms). For example, the word “cool” may be grouped with “nippy” on one line, and with “chilly” on another, while “chilly” may itself be grouped with “nippy,” and these three synonyms can be grouped together, perhaps with other synonyms, to form a synset. A word or phrase with several meanings will participate in several such synsets. Thus “cool” may also be grouped with “fantastic”, “awesome”, etc. (e.g., because all of these words can translate French “chouette”).
The tool can fetch all of the synsets in which “cool” participates. It should be appreciated that in some embodiments it may be necessary to maintain the distinctions among several such synsets involving a given word or expression, e.g., “cool,” rather than collapsing them into a single set containing all of these synonyms. The set of synsets for a given word can then function as its Meaning Cue Set for the purposes of interactive SMT-based translation.
However, the SMT-based Meaning Cue Set has a feature not contemplated by rule-based sets. In the SMT version, each synonym in each synset is associated with the probability that the synonym is a good translation. Thus, probabilities for all synsets can be computed, e.g., as the average probability of the contained synonyms; and the synsets in the Meaning Cue Sets can be presented to the user in order of probability, with the synset representing the current meaning at the top, representing the machine translation system's current best guess. (Probabilities can optionally be converted into user-friendly scores, with color coded visual cues, etc.)
Further, the tool can augment the synsets with other sorts of Meaning Cues, such as pictures, definitions, and examples. The programs which can align these alternative cues with the synsets may be the provided through the functionality described above to compile the SELECT database.
Once the user has indicated a preferred meaning—that is, a preferred synset—from an interactive display associated with a current translation segment (phrase or sentence), it will be desirable to generate an updated segment translation which incorporates a translation of the current word or expression which is appropriate to the selected meaning. This controlled generation could be accomplished by modifying the probabilities of the translations associated with the preferred synset members. Alternatively, assuming that the SMT system yields an n-best list (e.g. ten-best list) of candidate translations, we could re-rank the candidates based on the elements of the preferred synset. Hopefully, the preferred translation is already in the list, even if it hasn't been judged the best candidate. This approach has the advantage of avoiding direct interaction with the decoder of the SMT system—the component which actually generates translation strings by assembling, reordering, and modifying partial translations.
The modification of the translation probabilities mentioned above could in principle be carried out in the master copies of the SMT translation phrase tables. However, this design would require rapid updating of the tables and may commit to changes which might prove undesirable. For example, users might commit errors, interfere with each other, etc. For these reasons, in some embodiments, translation phrase table updating is carried out offline at present. Pending changes can be temporarily maintained in separate data structures, which are later integrated into the master structures when appropriate.
In any case, whenever the master translation tables are updated, the updates enabled by interactive translation can progressively improve translation results. These changes can be made via feedback supplied even by monolingual users. Under current SMT systems, feedback for translation improvement can be provided only by users with knowledge of the output as well as the input language. The techniques proposed here, by contrast, can dramatically expand the crowd-sourcing of translation feedback. It should be appreciated that this use of interactive correction (to inform learning of translations) will soon become even more valuable than the original use (assuring reliability of the current translation).
The interactive translation system described herein includes back-translation—re-translation of the output back into the source language. Controls assure that the re-translation reuses the same meanings employed in the forward translation, so that the user will receive a reliable indication of the forward translation's meaning. Comparable results can be achieved for SMT as follows:
The problem of back-translation can be decomposed into two sub-problems:
To identify the synsets (and thus the meanings) used in the forward translation, the current proposed translation for each input expression is observed. For example, if “cool” is presently translated by “frais,” then we identify the source language synset composed of synonyms which can also be translated by “frais” and its target language synonyms, e.g. “cool”, “nippy”, “chilly”, . . . . A similar identification must be carried out for each expression in the source language input.
To force a back-translation with the same meanings as used in the forward translation, we employ the techniques outlined above: we may modify the relevant translation tables (whether these are temporary or permanent data structures) to force translations using the source language expressions belonging to the synsets just identified; or we may reorder an n-best list of candidate translations. “Frais” will thus be translated by “cool,” “nippy,” “chilly,” etc.—thus avoiding possible misleading back-translation as e.g. “fresh,” “unspoiled,” etc.
A “black box” SMT system is one for which no access is allowed to source code or source data, e.g. GOOGLE Translate. The above techniques for interactive translation are adaptable to closed SMT systems. An auxiliary statistical machine translation system, which may be referred to a shadow SMT system, is created for this purpose. The shadow SMT system behaves similarly to the black box system. However, its translation phrase table (and other elements) can be manipulated because they are accessible.
In order to create a shadow SMT system, a shadow translation bi-corpus is created. First, a source language shadow corpus is created. The source language shadow corpus is passed as input to the black box SMT system. The resulting target language output becomes the target half of the shadow bi-corpus, thus completing the shadow translation bi-corpus. A shadow translation model is then created from scratch, based on the now-complete shadow bi-corpus. In some embodiments, the original system's translations may be processed to create the shadow model dynamically, throwing away the translation after use.
In some embodiments, customized auxiliary SMT systems provide customized corpora and translation models for specific domains. These can be merged with those of a shadow SMT system, so that the resulting merged system outperforms the original black box SMT system in the specialized domain while delivering similar performance overall. Of course, if one is working with an SMT system to which access is allowed, i.e., an open-box system, a possible embodiment is to merge the custom system with the open box system directly, without benefit of a shadow system.
In some embodiments a useful tool for instantly turning on and off interactive verification is provided for use in the above described system. While verification and correction is powerful, it does require some time and attention. It is thus useful to offer a quick and intuitive way of bypassing verification when time is of the essence, or when the present conversation is relatively unimportant. For this purpose, a Traffic Light Icon containing the familiar red, yellow, and green signal lights is provided as part of the user interface. The yellow light signals “Proceed with Caution!”—that is, verify the current translation before pronouncing and displaying it to conversation partners. The green light indicates “Full Speed Ahead!” That is, bypass preliminary verification without delay and proceed to pronounce and display the translation (though post-verification may still be enabled, for example by displaying a back translation within a running transcript of the conversation). And finally, the red light signals “Lock Translation!” That is, disable translation entirely, for instance when private conversations are desired, or to guard against careless errors, etc.
This Traffic Light Icon can be used to enable interactive verification and correction during simultaneous automatic machine translation. Programs are now coming into use which can recognize speech and translate the speech quickly enough to simulate human simultaneous interpretation. At the state-of-the-art, however, these remain error-prone. Thus, while it will often be convenient to completely ignore the translation program so as to interpret simultaneously even if poorly, it will sometimes be important to enable users to temporarily stop the show to interrupt simultaneous translation to permit interactive translation for purposes of clarification. The Traffic Light Icon is ideal for this interruption.
In other embodiments, an aid to practicality in speech translation or other real-time translation is provided and is referred to as a Rewind Button. Not infrequently, users issue translations which the user may later wish to correct or refine. This happens most frequently when Green Light Mode is in effect, since then an imperfect or incomplete translation may be issued without any preliminary checking. However, the need may arise even if Yellow Light Mode is in effect, since pre-checking may have been hurried or just mistaken. In such cases, it's helpful to be able to order repetition of an earlier input, so that the translation can be modified or corrected without the need for verbal repetition and repeated speech recognition. The input to be brought back for modification will usually be the most recent one, but our present implementation supplies a list of all previous inputs to enable easy selection.
Translation Shortcuts are fixed phrases which can be used as speed-dial translations. Since Translation Shortcuts have been checked in advance, there's no need to verify them before presentation to conversation partners. Categorization of prepackaged translations is enabled, similar to those in phrase books for travelers. Translation Shortcut Categories can be embedded: for example, within the category of Pharmacy Shortcuts there might be a subcategory for Pharmacy Pickup Window, another for Pharmacy Consultation Window, etc. Quick search is enabled through existing Translation Shortcuts and users can enter a few initial characters or a collection of keywords into the input window in order to retrieve a menu populated by appropriate Shortcuts, from which instant selection can be made. Some unique and original features of Translation Shortcuts:
In summary, the above-described invention permits for the first time a highly interactive style of speech-to-speech translation. The interactive procedures enable a user to recognize, and if necessary correct, errors in both speech recognition and translation, thus providing much more robust translation output than would otherwise be possible. This enhanced robustness permits practical extension of automatic speech-to-speech translation to wide-ranging language structures and topics, beyond the boundaries of narrow domains, without sacrificing accuracy to the point of impracticality. The interactive techniques for monitoring and correcting word ambiguity errors during automatic translation, search, or other natural language processing tasks depend upon the correlation of Meaning Cues (definitions, synonyms, examples, associated words, pictures, etc.) and their alignment with, or mapping into, the word senses of third party lexical resources, such as those of a machine translation or search lexicon. This correlation and mapping can be carried out through the creation and use of a database of Meaning Cues, herein called SELECT. The intelligent building and application of this database, which can be applied for many purposes, is detailed herein. In particular, some uses of the invention for language instruction are described. Also crucial to the operation of a practical speech-to-speech translation system is interactive, immediate correction of dictation (very large vocabulary speech recognition). Innovative techniques described here permit interactive correction even when a recognition engine is running on a remote server.
With the above embodiments in mind, it should be understood that the invention may employ various computer-implemented operations involving data stored in computer systems. These operations include operations requiring physical manipulation of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. Further, the manipulations performed are often referred to in terms, such as producing, identifying, determining, or comparing.
The above-described invention may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers and the like. The invention may also be practiced in distributing computing environments where tasks are performed by remote processing devices that are linked through a communications network.
The invention can also be embodied as computer-readable code on a computer-readable medium. The computer-readable medium is any data storage device that can store data, which can be thereafter read by a computer system. Examples of the computer-readable medium include hard drives, network attached storage (NAS), read-only memory, random-access memory, CD-ROMs, CD-Rs, CD-RWs, magnetic tapes, and other optical and non-optical data storage devices. The computer-readable medium can also be distributed over a network coupled computer system so that the computer-readable code is stored and executed in a distributed fashion.
Although the foregoing invention has been described in some detail for purposes of clarity of understanding, it will be apparent that certain changes and modifications may be practiced within the scope of the appended claims. Accordingly, the present embodiments are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims. In the claims, elements and/or steps do not imply any particular order of operation, unless explicitly stated in the claims.
| Number | Name | Date | Kind |
|---|---|---|---|
| 5630121 | Braden-Harder | May 1997 | A |
| 6078878 | Dolan | Jun 2000 | A |
| 6243669 | Horiguchi | Jun 2001 | B1 |
| 6287125 | Dorcely | Sep 2001 | B1 |
| 6385568 | Brandon et al. | May 2002 | B1 |
| 6442522 | Carberry et al. | Aug 2002 | B1 |
| 6446035 | Grefenstette et al. | Sep 2002 | B1 |
| 6499013 | Weber | Dec 2002 | B1 |
| 6604101 | Chan et al. | Aug 2003 | B1 |
| 6615208 | Behrens | Sep 2003 | B1 |
| 6996520 | Levin | Feb 2006 | B2 |
| 6996800 | Lucassen et al. | Feb 2006 | B2 |
| 7028306 | Boloker et al. | Apr 2006 | B2 |
| 7184948 | Chalabi | Feb 2007 | B2 |
| 7286651 | Packingham et al. | Oct 2007 | B1 |
| 7328158 | Burridge et al. | Feb 2008 | B1 |
| 7392185 | Bennett | Jun 2008 | B2 |
| 7483828 | Abir | Jan 2009 | B2 |
| 7539619 | Seligman et al. | May 2009 | B1 |
| 8239207 | Seligman et al. | Aug 2012 | B2 |
| 8280721 | Snow et al. | Oct 2012 | B2 |
| 20020069048 | Sadhwani et al. | Jun 2002 | A1 |
| 20030236658 | Yam | Dec 2003 | A1 |
| Number | Date | Country | |
|---|---|---|---|
| 60500720 | Sep 2003 | US | |
| 60512599 | Oct 2003 | US | |
| 60535218 | Jan 2004 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 13797628 | Mar 2013 | US |
| Child | 15394343 | US | |
| Parent | 13567216 | Aug 2012 | US |
| Child | 13797628 | US | |
| Parent | 12424388 | Apr 2009 | US |
| Child | 13567216 | US | |
| Parent | 10936093 | Sep 2004 | US |
| Child | 12424388 | US |
