Patent Application
20150347375
Building speech recognition applications can be a time consuming process. Development of natural language understanding (NLU) systems, in particular, can be one of the most challenging aspects of developing speech applications. Such development may involve the use of special linguistic and software development skills. Development of natural language understanding systems may also rely on grammars written manually and statistical models that are trained on large quantities of manually-annotated text. Manual annotations may be time-consuming and error-prone that can increase development time and affect the quality of the grammars and statistical models produced.
Various approaches to enhance the development of grammars and statistical models have been attempted. With respect to grammar development, for example, some conventional approaches might utilize unsupervised grammar induction techniques, integrated development environments (IDEs) for authoring grammars, or graphical user interface, i.e., GUI-based interactive tools as alternatives to manual grammar creation.
Unsupervised grammar induction techniques, however, do not provide meaningful grammar rules that are readable to humans and also require further manual tuning Although IDEs may be useful in testing grammars, debugging grammars, and visualizing parsing results, such IDEs do not provide suggestions regarding the target grammar structure, grammar rules, or the ordering of such rules. Instead IDEs delegate these tasks to the user. While GUI-based interactive tools may be helpful in guiding a user through an annotation process, such tools use complicated statistical and lexicalization models (e.g., hidden Markov models and context-free grammars). As a result, such GUI-based tools require significant amounts of effort to properly define slot fillers based on regular expressions.
Improved approaches to developing natural language understanding systems and annotating text samples have been described. The disclosures set forth in further detail below describe additional improvements to the development of natural language understanding system and text annotation processes.
The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosure. The summary is not an extensive overview of the disclosure and is not intended to identify key or critical elements or to delineate the scope of protection sought. The following summary merely presents some concepts of the disclosure in a simplified form as an introduction to the more detailed description provided below.
A first aspect described herein provides a method for improving the text annotation process. An annotation module may obtain a set of annotations for a set of text samples based, at least in part, on an ontology and a grammar. A quality assurance module may automatically perform one or more quality assurance checks on the set of annotations, the ontology, the grammar, or combinations thereof. The quality assurance module may generate a list of flagged annotations during performance of a quality assurance check. The list of flagged annotations may be presented at an annotation review interface displayed at a display device.
A second aspect described herein provides a annotation system. The annotation system may include at least one processing unit, an annotation module, a quality assurance module, and an annotation review interface. The annotation module may be configured to, in operation, obtain a set of annotations for a set of text sample based, at least in part, on an ontology and a grammar. The quality assurance module may be configured to, in operation, perform one or more quality assurance checks on the set of annotations, the ontology, the grammar, and combinations thereof. The quality assurance module may also be configured to, in operation, generate a list of flagged annotations during performance of the one or more quality assurance checks. The annotation review interface may be configured to, in operation, present the list of flagged annotations at a display device.
A selection of one of the flagged annotations may be received at the annotation review interface and presented at an annotation interface displayed at the display device. Responsive to presentation of the flagged annotation selected, the ontology, the grammar, the flagged annotation selected, or combinations thereof may be updated based on user input received.
The list of flagged annotations may be grouped by type of quality assurance check.
Performing one of the quality assurance checks may include comparing an arrangement of a set of hypernyms of one annotation to another arrangement of a matching set of hypernyms of another annotation. If the arrangements of hypernyms do not match, then the list of flagged annotations may be configured to include those annotations.
Performing one of the quality assurance checks may include grouping a plurality of text samples to obtain a group of text samples. The respective hypernyms used to annotate each text sample of the group of text samples may be compared. If two of the text samples of the group of text samples have been annotated with a different hypernym—i.e., have not been annotated with a common hypernym—then the list of flagged annotations may be configured to include the annotations associated with those text samples. Semantic clustering techniques may be applied to the set of text samples in order to obtain the group of text samples. User input may be received corresponding to a selection of a hypernym selected for the group of text samples, and each annotation of a group of annotations for the group of text samples may be updated to include the hypernym selected.
Performing one of the quality assurance checks may include determining whether multiple grammar rules of the grammar can parse an n-gram. If multiple grammar rules of the grammar can parse the n-gram, then the list of flagged annotations may be configured to include one or more annotations that include the n-gram.
Performing one of the quality assurance checks may include determining whether the grammar is an acyclic grammar. If the grammar is not an acyclic grammar, then the list of flagged annotations may be configured to include one or more annotations that are associated with a cycle of the grammar.
Performing one of the quality assurance checks may include determining whether the set of annotations is consistent with the ontology. If an annotation is determined to be inconsistent with the ontology, then the list of flagged annotations may be configured to include the annotation. Determining that the annotation is inconsistent with the ontology may include determining that the annotation includes a hypernym that is not defined in the ontology or that the annotation includes a nested hierarchy of hypernym tags that does not conform to a relationship defined by the ontology.
Additional aspects will be appreciated with the benefit of the additional description provided in further detail below.
The details of these and other embodiments of the disclosure are set forth in the accompanying drawings and description below. Other features and advantages of aspects of the disclosure will be apparent from the description and drawings.
Commonly-owned U.S. patent application Ser. No. 14/188,206 to Rachevsky et al., incorporated by reference, describes various approaches to automating aspects of the grammar construction process when constructing a natural language understanding grammar for speech applications. As described in that application, the grammar construction process may include annotating a set of text samples in order to train a classifier used to automatically annotate textual representations of speech audio. The present disclosure extends the teachings of that application by providing various improvements to the text annotation process. The various improvements to the text annotation process are described in further detail below. The improvements enhance the text annotation process by improving the suggested annotations, by grouping text samples using semantic clustering and suggesting annotations for the group, and by providing automated quality assurance checks to ensure consistency among the annotations. These and additional advantages will be appreciated with the benefit of the disclosures set forth in further detail below.
As aspects of the present disclosure are directed toward natural language understanding, the following terminology is adopted in the present disclosure for the purposes of convenience. A text sample refers to a string of one or more words. A substring refers to one or more consecutive words of a string in which the order of the words is preserved. One or more words of a text sample may be hyponyms (relatively low-level concepts) that correspond to or are otherwise associated with one or more hypernyms (relatively high-level concepts). An ontology may define a semantic relationship between hyponyms and hypernyms. A hyponym may be a single word of a text sample or multiple consecutive words of a text sample. It will be appreciated that a hypernym may, in some instances, be a hyponym of another hypernym. As an example, “Chicago” may be a hyponym of the hypernym “CITY,” which may in turn be a hyponym of the hypernym “LOCATION.” Additional examples will be appreciated with the benefit of this disclosure.
An annotation refers to a text sample in which an n-gram has been replaced by or tagged with a hypernym associated with the n-gram. An annotation may include multiple hypernyms that have respectively replaced or tagged multiple n-grams. An n-gram refers to a substring of text sample or an annotation having n consecutive words (for a text sample) or n consecutive words and/or hypernyms (for an annotation). Accordingly, a 1-gram may refer to a substring of text sample having one word of the text sample, or may refer to a substring of an annotation having one word or hypernym of the annotation. Likewise a 2-gram may refer to a substring of a text sample having two consecutive words of the text sample or may refer to a substring of an annotation having two consecutive words, two consecutive hypernyms, or a consecutive word and hypernym of the annotation. Additional examples will be appreciated for 3-grams, 4-grams, and so forth.
When an annotation has been tagged with a hypernym, the annotation may be referred to as a tagged annotation. A tagged annotation is one in which an n-gram is wrapped in a hypernym tag. A hypernym tag may indicate the hypernym associated with the n-gram and include an opening tag (e.g., “[ . . . ]”) positioned before the n-gram and a closing tag (e.g., “[/]”) positioned after the n-gram in the tagged annotation. As an example, the text sample “fly to JFK” may result in the tagged annotation “fly to [AIRPORT] JFK [/]” in which the hypernym tag for the concept of “AIRPORT” wraps the 1-gram “JFK.”
A tagged annotation may also include a nested hierarchy of hypernym tags in which one or more hypernym tags of a tagged annotation is wrapped by another hypernym tag that indicates a relatively higher-level and semantically-related concept. The ontology may be used to construct the nested hierarchy. As an example, the tagged annotation of “fly from [ARRIVAL_LOCATION] [LOCATION] [AIRPORT] JFK [/] [/] [/]” may be generated based on an ontology that defines the following semantic relationship of “ARRIVAL_LOCATION”→“LOCATION”→“AIRPORT.”
In the following description of the various embodiments, reference is made to the accompanying drawings identified above and which form a part hereof, and in which is shown by way of illustration various embodiments in which aspects described herein may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope described herein. Various aspects are capable of other embodiments and of being practiced or being carried out in various different ways. It is to be understood that the phraseology and terminology used herein are for the purpose of description and should not be regarded as limiting. Rather, the phrases and terms used herein are to be given their broadest interpretation and meaning The use of “including” and “comprising” and variations thereof is meant to encompass the items listed thereafter and equivalents thereof as well as additional items and equivalents thereof. The use of the terms “mounted,” “connected,” “coupled,” “positioned,” “engaged” and similar terms, is meant to include both direct and indirect mounting, connecting, coupling, positioning and engaging. In addition a set refers to a collection of one or more elements. Furthermore computer-readable media as used in this disclosure includes all non-transitory computer-readable media and excludes transitory computer readable media such as propagating signals.
Referring now to
The NLU development system 100 may reside at a computing device such as a desktop or laptop computer. A user may thus access and utilize the NLU development system 100 through local operation of the computing device. The NLU development system 100 may additionally or alternatively be hosted by a computing device such as an application server. A user may thus additionally or alternatively access the NLU development system 100 through remote operation via a portal (e.g., a web portal).
The annotation module 102 may be configured to, in operation, annotate text samples and generate annotations for the text samples. The annotation module 102 may be configured to annotate text samples in an automatic fashion or, additionally or alternatively, in response to input received from a user, i.e., in a manual fashion. The annotation module 102 may cause text samples and annotation candidates to be presented to a user at an annotation interface such as annotation interface 118 displayed at a display device. Through the annotation interface 118, a user may provide user input via an input device (e.g., a keyboard or a pointing device such as a mouse), to confirm automatically selected annotations for a text sample or to manually select annotation candidates as the annotations for a text sample. The annotation module 102 may, for example, be configured to present the list of annotation candidates to a user (e.g., in a contextual menu) and allow the user to manually select one of the annotation candidates as the annotation for the text sample.
The annotation module 102 may be configured to generate a set of annotation candidates corresponding to possible annotations for a text sample. The set of annotation candidates may include one or more annotation candidates and may be referred to as a list of annotation candidates. The annotation module 102 may then automatically select one of the annotation candidates as the annotation for the text sample, e.g. the annotation candidate having the highest score and appearing at the top of the list. The user may then provide input to confirm the automatically selected annotation candidate or to manually select a different annotation candidate from the list of annotation candidates. The annotation module 102 may also be configured to, in operation, annotate portions of a text sample by generating annotations for individual n-grams of the text sample. The user may thus confirm an automatically selected annotation for an individual n-gram of the text sample or manually select a different annotation for the individual n-gram. The annotation module 102 may save annotations to the data store 108 as elements of the set of annotations 112. The set of annotations 112 may also be referred to as an annotation corpus.
Referring briefly to
In
Referring back to
As noted above, the ontology 114 may define semantic relationships between concepts. The semantic relationships defined by the ontology may indicate that some concepts are hyponyms of other concepts and that some concepts are hypernyms of other concepts. With additional reference to
Some concepts of the ontology 114 may be referred to as intention concepts (or intentions) as such concepts may be utilized to tag n-grams of text samples in order to indicate the intent of a user. Examples of concepts that indicate an intent to travel via airplane may include the “BOOK_FLIGHT” intention concept and the “FLY” intention concept. The ontology 114 may also define semantic relationships between intention concepts and other concepts of the ontology. An example semantic relationship 420 between an intention concept 422 and other concepts 424-428 defined in the ontology is shown by way of example in
Referring back to
As also noted above, the annotation module 102 may also utilize the ontology 114 to generate a tagged annotation having a nested hierarchy of hypernym tags that wraps an n-gram. Referring briefly to
Referring back to
In some example implementations, the annotation module 102 may receive input from the user via the annotation interface 118 during the annotation process. The annotation interface 118 may include an output interface such as a graphical user interface (GUI) that displays text samples to be annotated and suggested annotations for the text sample. The annotation interface 118 may also include one or more input interfaces to receive input from the user via one or more input devices such as a keyboard or pointing device. Through the input interfaces of the annotation interface 118, a user may confirm an automatically suggested annotation for a text sample, select a different suggested annotation for a text sample, provide a new annotation for a text sample, and so forth. A user may also select or provide individual annotations for individual n-grams of a text sample through the annotation interface 118. The annotation interface 118 may, for example, present suggested annotations for a text sample or n-gram in a context menu when the user respectively selects the text sample or n-gram presented at the annotation interface.
Referring briefly to
If the user has selected a top-level n-gram (block 606:Y), then the annotation module may determine whether the grammar parses the n-gram (block 610). If the grammar does not parse the selected n-gram (block 612:N), then the annotation module may again simply replace the n-gram with the selected hypernym (block 608). If, however, the grammar does parse the n-gram (block 612:Y), then the annotation module may identify the lowest-level hypernym of the grammar that parses the n-gram (block 614) and determine whether the ontology defines a unique path between the top-level hypernym and the lower-level hypernym (block 616). For example, a grammar may include a grammar rule that parses the n-gram of “JFK” with the hypernym of “AIRPORT,” and an ontology may define a semantic relationship such as “ARRIVAL_LOCATION”→“LOCATION”→“AIRPORT.” If the ontology does not define a unique path between the hypernyms (block 618:N), then the annotation module may simply replace the n-gram with the selected hypernym (block 608). If, however, the ontology does define a unique path between the hypernyms (block 618:Y), then the annotation module may construct a nested hierarchy of hypernym tags based on the path between the hypernyms defined in the ontology (block 620). For example, the annotation module may construct the following nested hierarchy of hypernym tags based on the path defined by the example semantic relationship mentioned above: [ARRIVAL_LOCATION] [LOCATION] [AIRPORT] . . . [/] [/] [/].
The annotation module may then generate an annotation for the text sample and wrap the n-gram with the nested hierarchy of hypernym tags (block 622). Continuing the example above, the annotation module may generate an annotation that wraps the n-gram of “JFK” as follows: . . . [ARRIVAL_LOCATION] [LOCATION] [AIRPORT] JFK [/][/][/] . . . In this way, a user may advantageously observe the relatively higher-level or relatively-lower level hypernyms selected for an n-gram of the annotation. It will be appreciated that the steps for wrapping an n-gram of an annotation with a nested hierarchy of hypernym tags are described by way of example only and that additional and alternative approaches may be selectively employed.
Referring again to
As noted above, the present disclosure provides improvements to the annotation candidates suggested for a text sample or an n-gram of the text sample. Improvements to the suggested annotations may be achieved by configuring the annotation module 102 to exclude one or more annotation candidates from the list of annotation candidates. Excluding an annotation candidate from the list of annotation candidates may be accomplished by removing an annotation candidate from a list of annotation candidates and, additionally or alternatively, refraining from including an annotation candidate in a list of annotation candidates. In some example implementations, the annotation module 102 may iterate over the list of annotation candidates and filter any annotation candidates that i) include a concept that is a hyponym of a concept included in another annotation candidate of the list, and ii) cover a smaller portion of the text sample being annotated than the other annotation candidate.
As an example, the text sample, “book flight to JFK,” may be selected for annotation. The list of annotation candidates, in this example, may be based on the ontology 402 of
In
In some example implementations, the annotation module may select one of the annotation candidates from the list (block 706), and select another one of the annotation candidates form the list for comparison (block 708). The annotation module may then compare the respective concepts (e.g., a concept or concept tag) included in the selected annotation candidate and the annotation candidate selected for comparison (block 710). If the concept of the selected annotation candidate is a hyponym of the concept in the annotation candidate selected for comparison (block 712:Y), then the annotation module may compare the respective portions of the text sample covered by the selected annotation candidate and the annotation candidate selected for comparison (block 714). If the selected annotation candidate covers a smaller portion of the text sample compared to the annotation candidate selected for comparison (block 716:Y), then the annotation module may exclude the selected annotation candidate from the list of annotation candidates selected for comparison (block 718).
The annotation module may, in some example implementations, compare a selected annotation candidate to each annotation candidate in the list of annotation candidates. Therefore if the concept in the selected annotation candidate is not a hyponym of the concept in the annotation candidate selected for comparison (block 712:N), or if the selected annotation candidate does not cover a smaller portion of the text sample compared to the annotation candidate selected for comparison (block 716:N), then the annotation module may determine if any annotation candidates remain to be selected for comparison (block 720). If there are additional annotation candidates to compare to the selected annotation candidate (block 720:Y), then the annotation module may select the next annotation candidate (block 722) for comparison to the selected annotation candidate and repeat these steps for the next annotation candidate selected for comparison.
The annotation module may also, in some example implementations, analyze each annotation candidate in the list of annotation candidates in order to determine whether to exclude the annotation candidate for the list. Accordingly, having analyzed one of the annotation candidates, the annotation module may determine whether any additional annotation candidates remain to be analyzed (block 724). If additional annotation candidates remain to be analyzed (block 724:Y), then the annotation module may select the next annotation candidate in the list (block 726) and repeat these steps for the next selected annotation candidate.
Once no additional annotation candidates of the list remain to be analyzed (block 724:N), the annotation module may provide the list of annotation candidates to the annotation interface for presentation to a user (block 728) in order to annotate the text sample. It will be appreciated that, having performed the steps described above, the list of annotation candidates may be a filtered list of annotation candidates from which the annotation module excluded one or more annotation candidates. The annotation interface may receive a selection of one of the annotation candidates from the user (block 730) and annotate the text sample using the selected annotation candidate in order to obtain an annotation for the text sample (block 732). It will be appreciated that the criteria used to filter the list of annotation candidates described above is described by way of example only. Additional or alternative criteria may be selectively employed to filter the list of annotation candidates thereby improving the annotation candidates suggested to the user during the annotation process. Moreover, the set of annotations generated via the text annotation process may be utilized to generate statistical engines that are utilized to automatically annotate subsequent text samples, e.g., during processing of a text sample obtained from audio at a speech application.
As another example, the intention for an n-gram may be utilized to construct or filter the list of annotation candidates that may be selected for the n-gram. When an intention is selected for an n-gram, e.g., when the n-gram is tagged with the intention concept, the annotation module may query the ontology for other concepts semantically-related to the selected intention concept. The annotation module may thus include the concepts associated with the selected intention concept in the list of annotation candidates for the n-gram. The list of annotation candidates may therefore include only those concepts that are semantically-related to the selected intention concept and exclude concepts that are not semantically-related to the selected intention concept. If the list of annotation candidates is constructed before an intention concept is selected, then the annotation module may filter the list of annotation candidates when the intention concept is selected. The annotation module may, for example, iterate over the list of annotation candidates and determine whether a concept listed is semantically-related to the selected intention concept in the ontology. If the concept is not semantically-related to the selected intention concept, then the annotation module may remove that concept from the list of annotation candidates. In this way the speed and consistency of annotating n-grams is advantageously improved.
Referring back to
Furthermore the quality assurance checks improve the set of annotations 112 (the annotation corpus) such that the NLU processing performed by NLU systems is also advantageously improved. NLU systems may include NLU engines that may be selectively configured to operate using various data-driven techniques. One such data-driven technique utilizes grammars inferred from the annotations of an annotation corpus. Another data-driven technique trains statistical classifiers or configures statistical models using the annotation of an annotation corpus. Some NLU engines may be configures to employ a hybrid approach in which both inferred grammars and statistical classifiers are utilized for NLU processing. Such NLU engines may thus be referred to as hybrid NLU engines.
Due to the reliance on the annotation corpus, it will be appreciated that the quality of the output of an NLU engine may depend on the quality of the annotation corpus provided as input to the NLU engine. The quality assurance checks described in further detail below improve the quality of the annotation corpus which in turn improves the NLU processing output of annotation engines relying on that annotation corpus for data-driven NLU processing. It will also be appreciated that the improved annotation corpus may be provided to third-parties such that those parties may also realize the benefits of the improved annotation corpus during the development of their own NLU systems.
In
As noted above, the quality assurance module may include in the list of flagged annotations information indicating the reason the quality assurance module flagged the annotation. The information may also include, e.g., information identifying the quality assurance check that flagged the annotation. Upon completion of the quality assurance check, the quality assurance module may determine whether there are any additional quality assurance checks to perform (block 812). If there are additional quality assurance checks to perform (block 812:Y), then the quality assurance module may select the next quality assurance check (block 814) and repeat these steps for the next selected quality assurance check. It will also be appreciated that no annotations may be flagged during performance of one or more quality assurance checks in which case the annotation review interface may inform a user that the ontology, grammar, and set of annotations have passed each of the quality assurance checks performed.
If there are no additional quality assurance checks to perform (block 812:N), then the quality assurance module may provide the list of flagged annotations to the annotation review interface for presentation to the user (block 816). As noted above, the list of flagged annotations may be grouped by type of quality assurance check. Accordingly the annotation review interface may display groups of flagged annotations grouped and ordered according to type of quality assurance check. The annotation review interface may, for example, allow the user to select one of the quality assurance checks and present only those annotations flagged during the quality assurance check selected. The annotation review interface may also, for example, allow the user to select one of the flagged annotations for review. Selecting a flagged annotation from the list may cause the annotation review interface to present information associated with the flagged annotation, e.g., the information indicating the reason the quality assurance module flagged the annotation, the hypernyms of the annotation, the grammar rules and ontology definitions associated with those hypernyms, and so forth. Selecting a flagged annotation from the list may also cause the annotation interface to present the flagged annotation selected thus allowing the user to modify one or more hypernyms of the annotation. In this way, a user may review flagged annotations, and if desired, modify the hypernyms used to annotate the annotation (block 818). A user may also dismiss a flagged annotation via the annotation review interface upon review of the annotation and determination that no corrections to the annotation are needed.
The quality assurance module may perform the quality assurance checks to, among other things, ensure consistency between the ontology defined for a natural language processing application. It will be appreciated that the ontology may undergo various revisions during development of the application. Therefore when natural language application developers update the ontology (block 820), and these steps may be repeated to ensure the set of annotations conform to and are consistent with the updated ontology. Because the quality assurance module automates performance of the quality assurance checks, the process of analyzing and validating the set of annotations may advantageously be performed relatively quickly. Moreover the quality assurance checks improve the quality of the set of annotations 118 which in turn improves the quality of the data-driven NLU engines as described above.
As noted above with reference to
The arrangement consistency quality assurance check verifies that annotations for similar text samples are arranged in a similar way. Stated differently the arrangement consistency quality assurance check determines whether the hypernyms of annotations for similar text samples are inconsistently arranged. If the arrangement of hypernyms in the respective annotations for similar text samples is inconsistent, then the quality assurance module may flag the annotations for further review as described above.
As an example, the set of text samples may include the following similar text samples: “next flight to San Diego” and “next flight to London.” During the annotation process, the following annotations may be generated based on these text samples: “[FLIGHT] [ORDER] next [/] flight to [ARRIVAL_LOCATION] [LOCATION] [CITY] San Diego [/] [/] [/] [/]” and “[ORDER] next [/] [FLIGHT] flight to [ARRIVAL_LOCATION] [LOCATION] [CITY] Los Angeles [/] [/] [/] [/].” In the former annotation, the “ORDER” hypernym tag is wrapped by (i.e., inside) the “FLIGHT” hypernym tag. In the latter annotation, the “ORDER” hypernym tag is not wrapped by (i.e., outside) the “FLIGHT” hypernym tag. The quality assurance module may identify this inconsistency during the arrangement consistency quality assurance check and flag the annotations for further review. A user may thus review the flagged annotations at the annotation review interface and, if desired, correct one of the annotations at the annotation interface to ensure consistency between the arrangement of hypernym tags for the annotations of the similar text samples.
If the set of text samples does not include text samples similar to the selected text sample (block 910:N), then the quality assurance module may determine whether additional text samples remain to be analyzed (block 912). If there are additional text samples that remain to be analyzed (block 912:Y), then the quality assurance module may select the next text sample (block 914) and repeat these steps for the next selected text sample. If, however, the set of text samples does include a text sample similar to the selected text sample (block 910:Y), then the quality assurance module may retrieve the respective annotations for the selected text sample and the similar text sample (block 916). The quality assurance module may then compare the respective arrangements of the hypernym tags in the annotations (block 918). If the arrangements of the hypernym tags in the annotations are consistent (block 920:Y), then the annotations need not be flagged. The quality assurance module may thus determine if additional text samples remain to be analyzed and, if so, repeat these steps for the next selected text sample.
If, however, the arrangements of hypernym tags in the annotations are not consistent (block 920:N), then the quality assurance module may flag the annotations and add the annotations to a list of flagged annotations (block 922). The quality assurance module may also include in the list of flagged annotations information to associate the annotations having the inconsistent arrangements of hypernym tags, information indicating that the annotations were flagged during the arrangement consistency quality assurance check, and any other information that may be useful to determine whether corrections to the text samples or annotations are needed when reviewing the flagged annotations.
When no additional text samples remain to be analyzed during the arrangement consistency quality assurance check (block 912:N), the quality assurance module may provide the list of flagged annotations to the annotation review interface for presentation to a user (block 924). The annotation review interface may receive a selection of one of the flagged annotations (block 926), and display the flagged annotation selected along with the related annotation having an inconsistent arrangement of hypernym tags (block 928). The annotation review interface may also, for example, highlight the inconsistencies in the respective arrangements of the hypernym tags in each of the flagged annotations under review (block 930). As described above, the user may provide corrections to one or more of the flagged annotations via the annotation interface in order to correct the inconsistencies in the arrangement of the hypernym tags.
The grouping consistency quality assurance check determines whether semantically-similar annotations have been annotated with a common (i.e., the same) hypernym, e.g., tagged with a common hypernym tag. The quality assurance module may group semantically-similar text samples using semantic clustering techniques in order to obtain one or more groups of text samples. In some example implementations, the semantic clustering techniques described in commonly-owned U.S. patent application Ser. No. 8,515,736 to Duta may be employed to group semantically-similar text samples. If the quality assurance module determines that the text samples of a clustered group of semantically-similar text samples have not been annotated with the same hypernym, then the quality assurance module may flag the annotations of the group for further review.
The grouping consistency quality assurance check may be employed, for example, to determine whether semantically-similar annotations have been tagged with the same intention tag. As an example, the set of text samples may include the following text samples: “book this flight please” and “please book the Monday flight.” An annotation module may generate the following annotations for these text samples: “[BOOK_FLIGHT] book [/] this flight please” and “please [FLY] book [/] the Monday flight.” A semantic clustering process may group these two text samples as being semantically-similar, and the quality assurance module may compare the hypernyms (intention tags in this example) of the respective annotations of the text samples. Because the semantically-similar text samples have been annotated with different hypernyms, the quality assurance module may flag these annotations during the grouping consistency quality assurance check. A user may review the flagged annotations at the annotation review interface and select a desired hypernym to apply to the flagged annotations of the grouping. In this way, a user may advantageously ensure that semantically-similar text samples are annotated with a common annotation.
If, however, the annotations for the semantically-similar text samples are not the same (block 1012:N), i.e., if at least one of the annotations includes a different hypernym, then the quality assurance module may flag the annotations and include the flagged annotations in a list of flagged annotation (block 1018). The quality assurance module may then determine if additional groups remain to be analyzed and, if so, repeat these steps for the next selected group of semantically-similar text samples. When no additional groups remain to be analyzed (block 1014:N), the quality assurance module may provide the list of flagged annotations to the annotation review interface for presentation to the user (block 1020). The annotation review interface may group the annotations flagged during the grouping consistency check based on the groups of semantically-similar text samples. The annotation interface may thus receive a selection of one of the groups of flagged annotations (block 1022), and the annotation review interface may present the flagged annotations of the selected group (block 1024). The annotation interface may also highlight the differences between the hypernyms of the flagged annotations in the group (block 1026). In this way, the annotation review interface may enable a user to easily view how the annotation module annotated semantically-similar text sample differently. Additionally the annotation interface may receive a selection of a desired hypernym to apply to each flagged annotation of the group (block 1028), and the annotation interface may update each annotation of the group with the hypernym selected (block 1030). Continuing the example above, a user may select the “FLY” hypernym as the desired intention for the annotations, and the annotation module may update the annotations to such that the following annotations result: “[FLY] book [/] this flight please” and “please [FLY] book [/] the Monday flight.” In this way, the user may advantageously ensure that annotations for semantically-similar text samples include consistent hypernyms.
The annotation completeness quality assurance check determines whether an n-gram can be parsed by multiple grammar rules of a grammar derived during the grammar construction process. If the quality assurance module determines that an n-gram can be parsed by multiple rules of the grammar, then the quality assurance module may generate a set of alternative annotations for the text samples containing the n-gram based on those rules. The set of alternative annotations may then be presented for review at the annotation review interface, and a user may accept one of the alternative annotations to add to the set of annotations for an n-gram or text sample. The annotation system may maintain information that associates a grammar rule with the corresponding annotation from which the grammar rule was derived as well as information that associates the annotation with the text sample used to generate the annotation. Accordingly the annotation review interface may enable a user to trace alternative annotations to the respective grammar rules that generated the annotation, the respective annotations that resulted in the grammar rules, and the respective text samples the annotations were based on. The user may then correct a text sample or annotation such that a subsequently derived grammar does not include multiple rules that can parse the n-gram.
During a grammar completeness quality assurance check, the quality assurance module may, for example, determine that a grammar includes multiple rules that parse the n-gram, “Boston.” The grammar in this example may include one grammar rule that parses the n-gram, “Boston,” as a “CITY” and another grammar rule that parses the n-gram, “Boston,” as an “AIRPORT.” Additionally the set of text samples may include the following text sample: “I want to fly to Boston.” Based on the two grammar rules that parse the n-gram, “Boston,” the quality assurance module may create the following set of alternative annotations:
The quality assurance module may flag these alternative annotations and present them at the annotation review interface in a list of flagged annotations. Upon selection of the latter alternative annotation at the annotation review interface, the quality assurance module may retrieve the grammar rule that parsed the n-gram, “Boston,” as an “AIRPORT” and retrieve the annotation from which this grammar rule was derived. In this example, the set of text samples may include the text sample, “I want to fly from Boston to Boston,” which resulted in the following annotation:
As seen in this example, the text sample seemingly indicates the same departure and arrival location. As a result, the annotation generated from this text sample has annotated “Boston” as both a “CITY” and an “AIRPORT” resulting in the multiple grammar rules that parse the n-gram, “Boston.” Having detected the multiple grammar rules that parse the n-gram and presenting the alternative annotations at the annotation review interface, the quality assurance module advantageously enables a user to quickly and easily address any ambiguities in the text samples and corresponding annotations from which a grammar is derived.
If, however, more than one grammar rule of the derived grammar parses the n-gram (block 1112:Y), then the quality assurance module may identify text samples in the set of text samples that include the n-gram and generate a set of alternative text annotations based on the multiple grammar rules that parse the n-gram (block 1118). The quality assurance module may also identify the source of the multiple grammar rules (block 1120). As described above, the source of a grammar rule may include the annotation from which the grammar rule was derived, the text sample used to generate that annotation, or both the annotation and corresponding text sample. The quality assurance module may flag the alternative annotations and include the alternative annotations in a list of flagged annotations (block 1122). The quality assurance module may then determine if additional n-grams remain to be analyzed and, if so, repeat these steps for the next selected n-gram.
When no additional n-grams remain to be analyzed (block 1114:N), the quality assurance module may provide the list of flagged annotations to the annotation review interface for presentation to the user (block 1124). The annotation review interface may receive a selection of one of the flagged alternative annotations (block 1126), and the annotation review interface may present the flagged alternative annotation selected along with the grammar rule used to generate the annotation and the source of the grammar (block 1128). The annotation review interface may also highlight the alternative annotations for the n-gram. One or more corrections may be received from the user to correct the text sample or the annotation for the text sample that caused the multiple grammar rules capable of parsing the n-gram (block 1130). Receiving a correction may include receiving a selection of an alternative annotation for an n-gram or text sample. The annotation selected as an alternative annotation may be added to the set of annotations for the text sample or replace an existing annotation in the set of annotations. Using the example above, the user may revise the text sample, “I want to fly from Boston to Boston,” to indicate a different destination location, e.g., “I want to fly from Boston to Atlanta.” Having revised the text sample, the user may re-run the annotation process and grammar construction process to generate a new set of annotations and derive a new grammar that does not include multiple grammar rules that parse the n-gram.
In another example, the text sample “I want to fly to Georgia” may receive the following annotation: “I want to fly to [STATE] Georgia [/].” Because a grammar may include multiple grammar rules that parse “Georgia,” however, e.g., as a state or country, the annotation completeness check may propose the alternative annotation of, “I want to fly to [COUNTRY] Georgia [/].” The user may then select the alternative annotation proposed to include in the set of annotations for the text sample.
The acyclic grammar verification quality assurance check determines whether the derived grammar includes any cycles. When defining the ontology, relatively weak ontology constraints may result in a hypernym being its own ancestor. A grammar derived from such an ontology may lead to self-references in the grammar causing one or more cycles. During the acyclic grammar verification quality assurance check, the quality assurance module determines whether the derived grammar includes any cycles and, if so, flags any annotations that include hypernyms associated with the cycle. The flagged annotations may be presented at the annotation review interface where the user may correct the annotation and the ontology. As an example, an ontology may define the relationship, “LOCATION”→“ARRIVAL_LOCATION”→“LOCATION”→“AIRPORT” in which the hypernym “LOCATION” is defined to be its own ancestor. The quality assurance module may thus flag annotations that include one or more of these hypernyms during the acyclic grammar verification quality assurance check for further review by a user.
If the derived grammar does not include any cycles (block 1212:N), then the quality assurance module may validate the grammar as an acyclic grammar (block 1214). If, however, the quality assurance module determines that the grammar includes a cycle (block 1212:Y), then the quality assurance module may identify one or more hypernyms of the cycle (block 1216). The quality assurance module may then retrieve the annotations that include the one or more hypernyms associated with the cycle (block 1218). The quality assurance module may flag those annotations and include the flagged annotations in a list of flagged annotations (block 1220). The quality assurance module may then provide the list of flagged annotations to the annotation review interface (block 1222) for review by the user. The annotation review interface may also highlight the hypernyms involved in the cycle (block 1224). The user may then provide one or more corrections that eliminate the cycle in the grammar (block 1226). For example, the user may revise the ontology such that a hypernym is not defined to be its own ancestor. Having corrected the ontology, the user may re-run the grammar construction process to derive a new grammar that does not include any cycles. The user may also re-run the acyclic grammar verification quality assurance check on the newly derived grammar to ensure the cycle has been eliminated.
The ontology consistency quality assurance check determines whether the set of annotations is consistent with the current ontology. During development of a speech application, a developer may revise an ontology to modify existing semantic relationships or add new semantic relationships. As the developer adds or modifies semantic relationships, the developer may add or remove hypernyms. In order to ensure the set of annotations are consistent with the current version of an ontology, the quality assurance module may identify annotations having hypernyms that are not defined in the ontology or identify annotations having nested hierarchies of hypernyms that do not correspond to the relationships defined in the ontology. The quality assurance module may also identify hypernyms defined in the ontology that do not appear in any annotation of the set of annotations. The quality assurance module may flag any annotations that are inconsistent with the current version of the ontology, and the annotation review interface may present the flagged annotations to the user for review. The annotation review interface may also present hypernyms defined in the ontology that do not appear in any annotations of the set of annotation also for review by the user.
As an example, a first version of an ontology may include the hypernym, “ENTERTAINMENT,” which is used to annotate the text sample, “movie on this flight,” as “[ENTERTAINMENT] movie [/] on this flight.” A subsequent version of the ontology, however, may remove the hypernym, “ENTERTAINMENT,” thus making any annotations that include this hypernym obsolete. The quality assurance module may flag such annotations during the ontology consistency quality assurance check for presentation to the user at the annotation review interface. Upon review the user may, if desired, remove the annotation tagged with the obsolete hypernym.
As another example, a first version of the ontology may define the following semantic relationship, “LOCATION”→“ARRIVAL_LOCATION”→“AIRPORT,” which is used to annotate the text sample, “fly to Boston,” as “fly to [LOCATION] [ARRIVAL LOCATION] [AIRPORT] Boston [/] [/] [/].” A subsequent version of the ontology may revise the semantic relationship as “ARRIVAL_LOCATION”→“LOCATION”→“AIRPORT.” As a result, the nested hierarchy of hypernym tags in the annotation (based on the previous semantic relationship) does not conform to the current semantic relationship defined in the current version of the ontology. The quality assurance module may thus flag the annotation during the ontology consistency quality assurance check for further review by the user at the annotation review interface.
The ontology consistency quality assurance check may also be utilized to ensure consistency between intentions and other concepts in an ontology. As an example, the text sample, “I want to check-in in business class,” may be annotated as “[CHECK-IN] I wanted to check-in in [CLASS] business class [/] [/]” based on a relationship between the intention, “CHECK-IN,” and the concept, “CLASS,” in an ontology. If this relationship is subsequently modified or removed from that ontology, the ontology consistency quality assurance check would flag the annotation in this example for review.
If the selected annotation conforms to the ontology (block 1312:Y), then the selected annotation need not be flagged, and the quality assurance module may determine whether additional annotations remain to be analyzed (block 1314). If additional annotations remain to be analyzed (block 1314:Y), then the quality assurance module may select the next annotation (block 1316) and repeat these steps for the next selected annotation. If, however, the selected annotation does not conform to the ontology (block 1312:N), then the quality assurance module may flag the selected annotation and include the selected annotation in a list of flagged annotations (block 1318). The quality assurance module may then determine if additional annotations remain to be analyzed and, if so, repeat these steps for the next selected annotation. When no additional annotations remain to be analyzed (block 1314:N), the quality assurance module may provide the list of flagged annotations to the annotation review interface for presentation to the user (block 1320). The annotation review interface may receive a selection of one of the flagged annotations and present the flagged annotation selected (block 1322). The annotation review interface may also highlight the inconsistencies between the ontology and the flagged annotation selected (block 1324). Upon review of the flagged annotation selected, the user may correct the annotation at the annotation interface, e.g., to replace an obsolete hypernym or to revise a nested hierarchy of hypernym tags such that the annotation conforms to the current version of the ontology. The user may also delete the annotation and corresponding text sample if the text sample is no longer relevant to the current version of the ontology. The ontology consistency quality assurance check may be performed each time revisions are made to the ontology to ensure the set of annotations always corresponds to the most recent version of the ontology.
Another type of quality assurance check provided by the quality assurance module described herein may identify potential annotations that are missing for a text sample. This other quality assurance check may identify text samples having the same n-gram. If the n-gram is annotated in one of the text samples, but not the other text samples, then the text samples lacking the annotation may be flagged for review. The annotation review interface may identify the n-gram common among the text samples and highlight or otherwise indicate which text samples that n-gram is annotated in and which text samples the n-gram is not annotated in. The annotation review interface may include an option to automatically add the annotation to the text samples that do not include the annotation or an option to automatically remove the annotation from the text samples that do include the annotation. As an example the text samples, “Is flight number 960 on time?” and “Is my flight on time?” each include the n-gram, “on time.” An annotation process may generate the following respective annotations for these text samples: “Is flight number 960 [FLIGHT_INFO] on time [/]?” and “Is [FLYER_INFO] my [/] flight on time?” As seen in this example, the latter annotation lacks the tag, [FLIGHT_INFO] even though it includes the same n-gram, “on time,” as the former annotation. Accordingly this additional quality assurance check may flag these example annotations for review by a user.
As described above, the quality assurance checks improve the annotation corpus resulting from the annotation process. Data-driven NLU engines may infer grammars based on the annotation corpus, and the inferred grammars may be enhanced due to the improved annotation corpus. Techniques for inferring grammars from an annotation corpus are described in commonly-owned U.S. patent application Ser. No. 13/841,873 entitled “Ontology and Annotation Driven Grammar Interface” and filed on Jul. 15, 2013, which is incorporated by reference. The statistical models of data-driven NLU engines may likewise be enhanced due to the improved annotation corpus as also described above.
Speech applications may be configured to include such enhanced NLU engines for natural language processing. A speech application may be configured to include the grammar such that the speech application may parse text corresponding to received speech audio using the grammar. The speech application may receive speech audio from an individual via an audio input device such as a microphone. The speech application may obtain an electronic representation of the speech audio, e.g., an audio file. The speech application may then transform the audio file into a text file using a speech recognition module. The speech application may then parse and annotate the text file using the grammar during lexical analysis of the text file. As shown above, one example of a speech application may be a speech application for making airline reservations based on speech audio received from an individual regarding a desired departure location, arrival location, and departure date. It will be appreciated, however, that speech applications may be developed as described above for additional and alternative activities and endeavors.
In
In
In one embodiment, the processor routines 1416 and 1422 as well as data 1418 and 1424 are a computer program product, including a computer-readable medium (e.g., a removable storage medium such as one or more DVD-ROM's, CD-ROM's, diskettes, tapes, etc.) that provides at least a portion of the software instructions for implementing aspects of the present disclosure. The computer program product can be installed by any suitable software installation procedure, as is well known in the art. At least a portion of the software instructions may also be downloaded over a cable, communication and/or wireless connection. Computer-readable media include all computer-readable media but do not include transitory propagating signals.
One or more aspects of the disclosure may be embodied in computer-usable or readable data and/or computer-executable instructions, such as in one or more program modules, executed by one or more computers or other devices as described herein. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types when executed by a processor in a computer or other device. The modules may be written in a source code programming language that is subsequently compiled for execution, or may be written in a scripting language such as (but not limited to) HTML or XML. The computer executable instructions may be stored on a computer readable medium such as a hard disk, optical disk, removable storage media, solid state memory, RAM, etc. As will be appreciated by one of skill in the art, the functionality of the program modules may be combined or distributed as desired in various embodiments. In addition, the functionality may be embodied in whole or in part in firmware or hardware equivalents such as integrated circuits, field programmable gate arrays (FPGA), and the like. Particular data structures may be used to more effectively implement one or more aspects of the disclosure, and such data structures are contemplated within the scope of computer executable instructions and computer-usable data described herein.
While aspects have been particularly shown and described with references to example embodiments thereof, it will be understood that various changes in form and details may be made therein without departing from the scope and spirit identified by the appended claims.
This application claims the benefit of U.S. Provisional Patent Application No. 62/005,709 entitled “AUTOMATED QUALITY ASSURANCE CHECKS FOR IMPROVING THE CONSTRUCTION OF NATURAL LANGUAGE UNDERSTANDING SYSTEMS” and filed on May 30, 2014 which is incorporated by reference herein in its entirety. This application is related to commonly-owned U.S. patent application Ser. No. 14/188,206 to Rachevsky et al. entitled “Automated Text Annotation for Construction of Natural Language Understanding Grammars” and filed on Feb. 24, 2014, which is incorporated by reference in its entirety herein. This application also incorporates by reference the entirety of commonly-owned U.S. patent application Ser. No. 13/941,783 entitled “Ontology and Annotation Driven Grammar Interface” filed on Jul. 15, 2013 and commonly-owned U.S. Pat. No. 8,515,736 to Duta entitled “Training Call Routing Applications by Reusing Semantically-Labeled Data Collected for Prior Applications” which issued on Aug. 20, 2013.
| Number | Date | Country | |
|---|---|---|---|
| 62005709 | May 2014 | US |
