question

If the confidence level isn't high enough in what Alexa matches, it doesn't send you anything. It's not a generic speech to text service. It works best with a constrained vocabulary. I've seen Alexa return some rather wacky values. So if it did what you wanted, you would be stuck writing a complex linguistic comparison thing to work out what the user meant. You might be better off keeping your users to a constrained list of terms. But possibly add a second term to let them modify it. One, two, three... Red, green, blue... something like that. Between the two lists you should be able to give your users a reasonable selection, but keep to the constrained vocabulary that Alexa needs to produce a high quality result.

> If the confidence level isn't high enough in what > Alexa matches, it doesn't send you anything. It's not > a generic speech to text service. It works best with > a constrained vocabulary. I've seen Alexa return some > rather wacky values. So if it did what you wanted, > you would be stuck writing a complex linguistic > comparison thing to work out what the user meant. I'm not sure that's the case here... I'm using the voice simulator that's built into the amazon test suite. Why would a typed out "peanut butter" word have low confidence?

Sorry, I didn't catch you were testing it with typed text. The voice simulator does not simulate the entire pipeline. I rather suspect it skips the fuzzy matching part, since that is intimately linked with the speech resolution part. If so then, unlike Alexa, it will only return exact matches to your custom slot. Like EchoSim, it's really only good for positive testing.

That's really weird. I have a skill set up (to control Hue lights) that seems to follow your pattern very closely, with a custom slot listing all my lights and nothing else. I also have an utterance example of the form ControlLights turn off the {Light} I can confirm that the simulator does return values that are not listed in the custom slot, and that for me typing in "turn off the peanut butter light" (a light not listed in the custom slot) is slotted correctly. Maybe post your sample utterances here? Steve

@Steve: do you have two-word values in your custom slot? I recall that having samples representing different numbers of words is significant to Alexa somehow. I think that if all your custom slot values are one-word, then it will have difficulty matching the two word "peanut butter". Maybe that is the difference.

Yes...in fact they all are. I just checked matching against a four word value and, unsurprisingly, it only slotted two of the four words. So, that's a good call and something the OP should check. (Still, it's weird. Seems it should slot one of the two words if this is the problem.) Steve

I've got a pretty varied sampling of both 1 and 2 word phrases in my slot value. I'll go experiment with adding 3 and 4 word samples to see what it does with my example "failed" test that I used in the simulator.

Thanks for reaching back out. I've tested the values you've described and am facing the same issue of the slot not being matched. It appears the sample utterances are matching the intent without including all of the custom slots, due to the slots needing more training data to cover such edge cases. While I understand you don't want to have to worry about covering every possible variable, I propose the following adjustment: 1 - Add additional custom slots of any variety of one, two, or three words (house kitchen, bathroom lights, outside patio, etc), as well as a few wild card words such as peanut butter. This will enhance the training data to capture words outside of the word '____ room', which most of your custom slot values contain (I can put in peanut room, an it adds the value to the slot). Try to avoid too many consistent occurrences, and throw in anything to shake up the training data. 2 - Building additional error handling for such occurrences. It's safe to assume from a user perspective that anytime the intent is triggered with Turn On _______, if your intent.slots.deviceName.value === null, you can provide appropriate error handling, such as stating 'Sorry, this doesn't appear to be a valid location.' If you provide the additional random data in step one, the potential hitting this endpoint should be significantly less than what you've experienced in the past. [b]While it seems like this may be an error, it's important to think about custom slots as a container that is unaware of it's surroundings. If any given portion of an utterance does not match the potential value threshold of what a custom slot can interpret as a 'pass', it will fail to obtain a value. Because of this, the utterance may trigger an intent due to the variety of supplied data, but the slots can fail on their own.[/b]