Box 1: {"fr", "de", "es"}
A common task of speech translation is to specify target translation languages, at least one is required but multiples are supported. The following code snippet sets both French and German as translation language targets. static async Task TranslateSpeechAsync()
{
var translationConfig =
SpeechTranslationConfig.FromSubscription(SPEECH__SUBSCRIPTION__KEY, SPEECH__SERVICE__REGION); translationConfig.SpeechRecognitionLanguage = "it-IT";
// Translate to languages. See, https://aka.ms/speech/sttt-languages translationConfig.AddTargetLanguage("fr"); translationConfig.AddTargetLanguage("de");
}
Box 2: TranslationRecognizer -
After you've created a SpeechTranslationConfig, the next step is to initialize a TranslationRecognizer.
Example code:
static async Task TranslateSpeechAsync()
{
var translationConfig =
SpeechTranslationConfig.FromSubscription(SPEECH__SUBSCRIPTION__KEY, SPEECH__SERVICE__REGION); var fromLanguage = "en-US"; var toLanguages = new List { "it", "fr", "de" }; translationConfig.SpeechRecognitionLanguage = fromLanguage; toLanguages.ForEach(translationConfig.AddTargetLanguage); using var recognizer = new TranslationRecognizer(translationConfig);
}
Comment 1
Since airports can appear in many forms and combinations (Example variations:
JFK
John F Kennedy Airport
New York JFK
JFK Airport), Pattern.any looks better. List is used for Small, fixed vocabulary.
Comment 2
List entities ARE great for airports
BUT the question specifically says "similar utterances" - this is Pattern.any territory
Comment 3
A list entity is perfect for airport names and codes because they represent a finite, well-defined set of values with known synonyms. This approach dramatically reduces the number of training utterances needed by allowing you to generalize utterance patterns and handle all airport variations through the predefined list mappings rather than requiring separate training examples for each airport.
Comment 4
List entities allow you to define a set of known values (like airport names or codes) and their synonyms.
When an utterance contains any of these values, LUIS will recognize them without needing to add separate utterances for each airport.
This minimizes the number of training utterances because you don’t have to create variations for every airport name or code.
Comment 5
Not A (Pattern.any) because that entity just captures free text placeholders without restricting values.
You’d still need many utterances to cover variations.
With D (list), you define all airport names/codes once, and the model generalizes across intents—minimizing training utterances
Comment 6
Pattern.any entities are ideal when you want to reduce the number of utterances needed for training.
They act as placeholders in patterns (like {fromAirport} or {toAirport}), and can match any word or phrase, such as airport names or codes.
This is especially useful when you have many similar utterances that differ only by variable data like city names, airport codes, etc.
Comment 7
To minimize the number of utterances needed for training when many intents share similar utterances with variable airport names or codes, you should use the Pattern.any custom entity. This entity type allows you to define patterns with placeholders for variable parts (like airport names/codes), reducing the need to enumerate every possible utterance variation.
Suppose you have intents like:
BookFlight
CheckFlightStatus
And users might say things like:
"Book a flight to JFK"
"Book a flight to London Heathrow"
"Check the status of flight DL123"
"Check the status of flight to SFO"
The variable parts are airport names, airport codes, or flight numbers.
You define a Pattern.any entity called, for example, @destination or @flightCode.
Intent: BookFlight
Pattern:
"Book a flight to {@destination}"
Intent: CheckFlightStatus
Pattern:
"Check the status of flight {@flightCode}"
"Check the status of flight to {@destination}"
Comment 8
Either A or D, both works. A less development effort, D a better solution. However, the requirement is not talking about minimizing development efforts.
Comment 9
Either A or D, both works. A less development effort, D a better solution. Howeve,r the requirements it is not talking to minimize development effort.
Comment 10
pattern.any https://learn.microsoft.com/ja-jp/azure/ai-services/luis/reference-entity-pattern-any?tabs=V2
list https://learn.microsoft.com/en-us/azure/ai-services/language-service/conversational-language-understanding/concepts/entity-components
Comment 11
List: fixed, close set of related words
Comment 12
It shoul be LIST
Comment 13
D. List
https://learn.microsoft.com/en-us/azure/ai-services/luis/reference-entity-list?tabs=V2
Suppose the app has a list, named Cities, allowing for variations of city names including city of airport (Sea-tac), airport code (SEA), postal zip code (98101), and phone area code (206).
List item Item synonyms
Seattle sea-tac, sea, 98101, 206, +1
Paris cdg, roissy, ory, 75001, 1, +33
book 2 tickets to paris
In the previous utterance, the word paris is mapped to the paris item as part of the Cities list entity. The list entity matches both the item's normalized name as well as the item synonyms.
Comment 14
LIST entity
Comment 15
USing a list entity allows you to define a set of values and their synonyms which will help minimize the number of utterances needed to train the model.
Hence the answer must be:
D) List
Comment 16
Pattern, you can use this to summarise multiple utterances into intents
Comment 17
"Patterns are designed to improve accuracy when multiple utterances are very similar. A pattern allows you to gain more accuracy for an intent without providing several more utterances."
So, it has to be pattern. The only one in the list is Pattern.Any.
Looks like the MIcrosoft guy just read this line and made the question and randomly chose a pattern type
Comment 17.1
regular-expression entity is given as an option to trick those who actually read the example for that using flight code. If you did not read much, then you are safe in Microsoft world