8
votes

I noticed something strange when testing my interaction model with the Alexa skills kit.

I defined a custom slot type, like so:

CAR_MAKERS Mercedes | BMW | Volkswagen

And my intent scheme was something like:

{
  "intents": [
    {
      "intent": "CountCarsIntent",
      "slots": [
        {
          "name": "CarMaker",
          "type": "CAR_MAKERS"
        },
   ...

with sample utterances such as:

CountCarsIntent Add {Amount} cars to {CarMaker}

Now, when testing in the developer console, I noticed that I can write stuff like:

"Add three cars to Ford"

And it will actually parse this correctly! Even though "Ford" was never mentioned in the interaction model! The lambda request is:

  "request": {
    "type": "IntentRequest",
    ...
    "intent": {
      "name": "CountCarsIntent",
      "slots": {
        "CarMaker": {
          "name": "ExpenseCategory",
          "value": "whatever"
        },
 ...

This really surprises me, because the documentation on custom slot types is pretty clear about the fact that the slot can only take the values which are listed in the interaction model.

Now, it seems that values are also parsed dynamically! Is this a new feature, or am I missing something?

2
I noticed that user @samiles shares my observation in the answer to this question: stackoverflow.com/a/34078869/1375015Konstantin Schubert

2 Answers

6
votes

Actually that is normal (and good, IMO). Alexa uses the word list that you provide as a guide, not a definitive list.

If it didn't have this flexibility then there would be no way to know if users were using words that you weren't expecting. This way you can learn and improve your list and handling.

1
votes

Alexa treat the provided slot values as 'Samples'. Hence slot values which are not mentioned in interaction model will also get mapped.

When you create a custom slot type, a key concept to understand is that this is training data for Alexa’s NLP (natural language processing). The values you provide are NOT a strict enum or array that limit what the user can say. This has two implications

1) words and phrases not in your slot values will be passed to you,

2) your code needs to perform any validation you require if what’s said is unknown.

Since you know the acceptable values for that slot, always perform a slot-value validation on your code. In this way when you get something other than a valid car manufacturer or something which you don't support, you can always politely respond back like

"Sorry I didn't understand, can you repeat"

or

"Sorry we dont have in our list. can you please select something from [give some samples from your list]"

More info here