There has been some activity lately on the Yahoo VUIDs group about the difficulty of generating sentences from a speech recognition grammar. This is a recurrent problem in speech grammar engineering, one that really deserves a full blog post (and maybe more than one), especially since we’ve worked hard on this problem in the last year. So I’ll share my thoughts on this subject.
First, let me surmmarize why this problem is so difficult.
The problem
You have an ABNF (or GrXML, or GSL) grammar for which you would like to generate sentences. Except if it’s a toy grammar or a small item-list, the grammar will most certainly generate thousands, millions, or even more different sentences, if not an infinite number of them. Why? That’s simple:
- It can contain repeated items. If you have 10 words repeated 4 times, you have 10,000 sentences. When you have unbounded repeats, of course you get an infinite language.
- It can contain all sort of filler words, to better handle disfluencies (hesitations, corrections, etc.). When you have those fillers at the start and end of every possible sentence, the number of sentences grows very rapidly. For example, just adding 9 optional filler words at the start and end of every sentences multplies the number of sentences by a factor of 100.
For example, one of our VoiceXML applications has a grammar that generates 29,822,907,679,607,676,696 sentences! (after removing some fillers that would have made the language infinite.) And it’s just a grammar for collecting a building number, albeit a highly tuned one. Pretty standard stuff.
As you have certainly guessed, it is rather impractical to generate all sentences. Are you really interested in reviewing tens of thousands of sentences? Remember that most sentences will only differ in very uninteresting ways (the pre/post fillers, a “two” instead of a “three”, etc.).
What would you want to generate sentences for?
Sentence generation can be helpful in many situations:
- Grammar coverage. Coverage test sets can be built in many different ways. But one that works very well is to start with the grammar and generate sentences. As you do so, you add some or all of them to the coverage set, either as ING (in-grammar) or OOG (out-of-grammar) sentences.
- To detect problems. Sentence generation is often an effective way to find potential problems with a grammar. Typical problems are over-generation (which can lead to reduced recognition accuracy) and grammar problems (misplaced parentheses, missing parentheses, misplaced vertical bar, etc.).
- Application testing. Some people use the generated sentences in manual application test scripts. Automated, text-based testing tools could also use sentence generation to “navigate” an application call flow.
Some available tools
Many, if not most, recognition engine vendors provide tools to generate sentences from a grammar. For example, Nuance 9 comes with parseTool, which lets you generate a fixed number of random sentences from either a GrXML grammar or a compiled grammar.
Those tools, however, are rarely adequate at dealing with a large number of sentences in an effective way. They either exhaustively generate all sentences, or they generate a fixed number of random sentences. As I mentioned above, the exhaustive generation strategy works well only for very simple grammars. The random strategy, on the other hand, doesn’t provide any control mechanisms that enable us to only generate the sentences we want. As a result, we typically end up with mostly redundant sentences in which some sentence patterns are grossly over-represented while others are missing.
Our approach
In NuGram IDE Pro, we have implemented a very different approach to sentence generation. I won’t go into explaining all the details here, but let me emphasize some aspects of our approach:
- The generation strategies can be configured on a rule-by-rule basis.
- The generation algorithm can be started on arbitrary expansions (sequences of words and rule references) that can be derived from the root rule. These expansions are usually produced by the Sentence Explorer tool.
- The available strategies are:
- All sentences - This is the default strategy. As one would expect, it consists in exhaustively generating all the sentences. However, all referenced rules will obey their own strategy.
- First sentence - This strategy generates a single sentence, the “first” in the document order.
- Random sentences - This strategy generates a configurable number of random sentences each time the rule is referenced from another rule.
- Tags coverage - This strategy generates the smallest set of sentences that will cover all the semantic actions in the rule and its referenced rules (and recursively). This is a very effective strategy to build coverage sets to test all the semantic tags in a grammar/rule.
- All paths - This strategy is a variable of the tags coverage strategy. It generates the smallest set of sentences to cover all the paths in a rule and its referenced rules (and recursively).
- Rule examples - This strategy consists in using the examples in the rule’s documentation comment. This strategy is dangerous in that it can generate sentences that are not parsable by the grammar if the examples are not changed when the rule is modified.
Here is a screencast showing these concepts in action:
That’s it for now. My next post will be about how to use the sentence generation tool to effectively find common problems with grammars and how to fix them.
And I’d be very interested in knowing how you deal yourself with this problem. So leave me a comment!
