Tips on rewrite files

This section describes how to construct a rewrite file for a Mix project.

What is a rewrite file?

For Krypton 4 and above, the recognition result can be modified using a configurable post-processor called TMFE (Transformation Modeling Front End), which is part of Krypton’s text processing. Inside Krypton, text processing formats the raw recognition result in terms of tokens, into a literal that is returned as the transcription of the recognized audio.

A rewrite file provides a way to remap tokens before they are formatted to text, giving the ability to “edit” the returned literal to some degree. For example, if you find that, despite the content of your DLM, the term “iPhone” is sometimes recognized by Krypton as “eye phone” (when you always want “iPhone” instead), you can configure a remapping in a rewrite file and apply it through a trained DLM to fix this problem.

Rewrite files are specific to a single language.

Creating a rewrite file

To create a rewrite file:

• Create a UTF-8, tab-separated text file called _tmfe.tsv. This specific name is required, and it must include the initial underscore.
• The file must start with the header <?tsv version="1.0"?>, followed by a blank line.
• Following after the blank line, add one or more additional lines to define any mappings. Each line needs to include the initial raw tokenized result, followed by the target it should be mapped to.
• Optionally, a line can include a third field for operators, TPLatticeProcessorAdaptationFlag_StartOnly or TPLatticeProcessorAdaptationFlag_EndOnly. These operators indicate that the mapping is to be applied only when the word appears as the first or last token of the sentence respectively.

Rewrite example

Here is an example of a simple rewrite file to illustrate the format.

<?tsv version="1.0"?>
 
eye phone    iPhone
Batman versus Superman    Batman v Superman
night rider    Knight Rider
direct TV    DirecTV 
my credit card plus    MyCreditCard+

Cautions and limitations

There are some important limitations that need to be kept in mind when using rewrites.

Rewrites are mostly context-free

If you define a remapping of a raw token, this remapping will be applied to all appearances of the token. Suppose in a banking related application, the phrase “BIC number” (banking identification code) was frequently getting transcribed as “big number.” A rewrite transforming “big” to “BIC” would address this issue. But it would also transform any other appearance of “big” as a token in other contexts. This may not be desirable.

To address this, you can specify a larger context surrounding the the tokens. For example, you could instruct to transform “big number” to “BIC number.” This will tend to work better, but you would want to make sure “big number” would not normally appear in spoken user inputs. Alternatively, you could apply transformations to multiple specific sequences, including both preceding and following tokens.

Note also that as mentioned above, you can include operators to cause the rewrite to happen only if the token appears at the start or the end of the unformatted recognition result. For a recognition result with only one token, either operator will trigger a rewrite, since the token is both the first and the last in that case. You can also put both operators on the same line, separated by a space. In that case the rewrite will only trigger if the result is a single token.

Tokens to remap must exactly match expected tokens

The initial raw tokenized result uses specific tokens known from a base data pack, or a customization such as a DLM or wordset. The format of these tokens cannot necessarily be inferred from the formatted recognition literals from ASRaaS/Krypton or the training text.

Note that since tokens are case sensitive, a rewrite will be case sensitive as well. So for example rewriting “Reading” as “Redding” would not apply to a token “reading.”

Also, note that if the token is a multi-word token containing whitespace, the whitespace must be replaced with an underscore (_) in the first column of the entry. So for example, a token “I tunes” would need to be written “I_tunes.”

The output of one rewrite rule cannot form the input to another

Only the original tokens in the initial raw tokenized result can serve as the basis for a remapping rule and remapping goes in a single pass. This means that you cannot apply one rewrite rule to create the input to another, no matter how the rules are ordered.

Conflicts among multiple concurrently loaded rewrite rules

If you are simultaneously using multiple DLMs to perform recognition, each with its own set of rewrite rules, and one mapping in one DLM conflicts with another mapping in a different DLM, this will be resolved in terms of the most recently loaded rewrite file.

Rewrite applies only to the top choice in the recognition n-best list

The token will only be mapped in the top result. If the incorrect token appears in the other results as well, these will not be rewritten.

Multi-language projects

If you have a multi-language project, you will need to create a separate rewrite file for each language in the project.