ASR Language Models for Simulations

In very basic terms, a language model is a collection of words and phrases that you wish to be recognizable by your ASR. For simulation systems, this is typically in the form of a constrained grammar model (the pros and cons of different types of language models will be discussed in a future blog). The biggest hurdle when using a Context-Free Grammar is that every phrase you wish to support must be defined in advance and for some applications, this can be a monumental task.

In an earlier post, I briefly described an ATC simulator for the United States Air Force. The contract requirements for this simulator called for the ASR to support phrases from the FAA ATC handbook (FAA 7110.65) plus commonly used terminology. In analyzing these requirements, it was determined that for the tower simulation task, there were approximately 60 commands or phrases that a controller might use. For estimating purposes and to add some buffer for commonly used terminology, it was determined that 120 phrases would be enough. Today, that same simulator has support for literally tens of thousands of instructions and given that a controller may string up to 8 phrases in a single transmission, there are billions of permutations.

If the analysis showed only 60 phrases, then how did the system evolve to support so many more? Unfortunately for the ASR developer, there are many ways to issue each of those phrases. In one case, the taxi instructions, there were more than eighteen thousand variations of the instruction. Additionally, you can not rely on users sticking to formal terminology, especially if they are students. If you do not account for the use of unexpected terminology, your system will behave in a manner that negatively impacts its use or training benefits.

So how can you possibly define in advance all the sentences that you wish to be supported in your training simulator? Quite simply you cannot! Therefore when defining system requirements to be used in a competitive tender process, a different approach is needed. This approach will be described later in the series when we discuss the topic of “Requirements Specification” for your ASR system.