Myujth

I'm new to developing Alexa Skills. I'm working on a Skill for the Spanish store, so I'm using the es-ES voice. I use the Node.js ASK-SDK and I've come across this issue:

When I'm trying to develop a conversation with reprompt, if the user says gibberish, that shouldn't trigger any of my utterances, I expect to enter in the Error Handler, as it's the one with canHandle == true, but the actual result is that that gibberish is detected and sorted by Alexa as one of the correct utterances. I've seen that in en-US you have the AMAZON.Fallback to sort-of prevent this issue but as none of the Spanish SDK have this, how can I detect this?

I've upload a demo project to emulate this behaviour

You can try with this the workflow:

• Start the Skill


• The skill returns the "Number One" text and stays listening (as there's a reprompt)


• You write number two


• The skill returns the "Number Two" text and stays listening with another reprompt


• You say gibberish, for example, "d" or "blah blah blah"


• You are sorted on a apparently random utterance.

Here's an example of the JSON input for "blah blah blah"

"version": "1.0",
"session": 
 "new": false,
 "sessionId": "amzn1.echo-api.session.55b928a6-ecb2-4b55-857e-af6a76dee6fe",
 "application": 
 "applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
 ,
 "user": 
 "userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
 
,
"context": 
 "System": 
 "application": 
 "applicationId": "amzn1.ask.skill.dd0b7ffd-b408-489a-ab5e-a7d7b8d05da3"
 ,
 "user": 
 "userId": "amzn1.ask.account.AFWPOWCRQULHUVKQTTX7JIS3O264CCHSUY4MPHCSJS4LKLQX45YARJ67LTGHPMS7RWUXVNYUTXT6JMT3DICTL5YZ7QHSLZ3QIHEKDP5YRPLCAEFXTD4BRY6WJIKC36UO3QU4F5X5BLFAGX6C3KN76MQJETO5PY6I65CVNOFBQLGNZ3P4YN4IOLYBCC7NDGAQ6LFAWMWTKT6DWQY"
 ,
 "device": 
 "deviceId": "amzn1.ask.device.AETBPXRLKFDMVR23WFUFQ3HOFTGHQDISLOQAPWS4BDBD4FAGXUKW2P56RJ3G74C75HG63MS52UV7KFYJAENEVT6VIRZUEKWCQQHNGV3FMP6BM3A5JZCUXH2LRYDHLQLBH5ABDJ7EYRWUI5532NYEZLUCYIGMRZCM2WKQ3XG6NX5VZPOELTKUO",
 "supportedInterfaces": 
 ,
 "apiEndpoint": "https://api.eu.amazonalexa.com",
 "apiAccessToken": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjEifQ.eyJhdWQiOiJodHRwczovL2FwaS5hbWF6b25hbGV4YS5jb20iLCJpc3MiOiJBbGV4YVNraWxsS2l0Iiwic3ViIjoiYW16bjEuYXNrLnNraWxsLmRkMGI3ZmZkLWI0MDgtNDg5YS1hYjVlLWE3ZDdiOGQwNWRhMyIsImV4cCI6MTU0MjM1OTg1NCwiaWF0IjoxNTQyMzU2MjU0LCJuYmYiOjE1NDIzNTYyNTQsInByaXZhdGVDbGFpbXMiOnsiY29uc2VudFRva2VuIjpudWxsLCJkZXZpY2VJZCI6ImFtem4xLmFzay5kZXZpY2UuQUVUQlBYUkxLRkRNVlIyM1dGVUZRM0hPRlRHSFFESVNMT1FBUFdTNEJEQkQ0RkFHWFVLVzJQNTZSSjNHNzRDNzVIRzYzTVM1MlVWN0tGWUpBRU5FVlQ2VklSWlVFS1dDUVFITkdWM0ZNUDZCTTNBNUpaQ1VYSDJMUllESExRTEJINUFCREo3RVlSV1VJNTUzMk5ZRVpMVUNZSUdNUlpDTTJXS1EzWEc2Tlg1VlpQT0VMVEtVTyIsInVzZXJJZCI6ImFtem4xLmFzay5hY2NvdW50LkFGV1BPV0NSUVVMSFVWS1FUVFg3SklTM08yNjRDQ0hTVVk0TVBIQ1NKUzRMS0xRWDQ1WUFSSjY3TFRHSFBNUzdSV1VYVk5ZVVRYVDZKTVQzRElDVEw1WVo3UUhTTFozUUlIRUtEUDVZUlBMQ0FFRlhURDRCUlk2V0pJS0MzNlVPM1FVNEY1WDVCTEZBR1g2QzNLTjc2TVFKRVRPNVBZNkk2NUNWTk9GQlFMR05aM1A0WU40SU9MWUJDQzdOREdBUTZMRkFXTVdUS1Q2RFdRWSJ9fQ.H50aG2L-K_AH-vRQ4ueu6n8GY_3T14KVjJysJjpWaAJEMfVlkx6CNwnQjDQJZHd1GQ1UpqcT3AkpqGDg86Z2J50RDmRp5ScUqqMQu0ZjrCxG9hItwT02ca4wxEo_hFrMb5VTTgqSORbfgzmDHJMOVaWjb_zJAcAFCJrF3qxzYzEo-E2ptBdRb7xKY0y_3MisF302HTUiZC3uTiRvWxv3jMT0_vq9cXDoHOar_WDf7Q6afF4DrEj6naX_vRpHT-63nWug1TiKRaJY4sEEaTlX0BVDigJ7t1LuH76ULeDEpJrSNW3mQtrHqUCnFNRYe9_-ru-rf-NkMpotYE7glWNnZg"
 ,
 "Viewport": 
 "experiences": [
 
 "arcMinuteWidth": 246,
 "arcMinuteHeight": 144,
 "canRotate": false,
 "canResize": false
 
 ],
 "shape": "RECTANGLE",
 "pixelWidth": 1024,
 "pixelHeight": 600,
 "dpi": 160,
 "currentPixelWidth": 1024,
 "currentPixelHeight": 600,
 "touch": [
 "SINGLE"
 ]
 
,
"request": 
 "type": "IntentRequest",
 "requestId": "amzn1.echo-api.request.fef2e2fc-b404-4729-85b4-e8ced71b6ecd",
 "timestamp": "2018-11-16T08:17:34Z",
 "locale": "es-ES",
 "intent": 
 "name": "NumberTwoIntent",
 "confirmationStatus": "NONE"
 

How can I prevent this? I'd expect to enter the error, as it's the only one handler that could return true for "blah blah blah" utterance and so, tell the user there's been an error for their speech, but as it's being classified on a utterance, it returns some information the user hasn't asked for.

Thank you

The recommended strategy for handling out-of-domain utterances in locales that have no FallbackIntent yet is to be as extensive as possible with the intents that your model can indeed handle and try to recognize some utterances people might want to ask your skill outside the domain and catch them in a separate intent that ultimately will provide extra answers specifically for those cases.

So overall the recommendation is to:

1. Provide between 7 and 50 utterances per Intent, try to provide a representative sample of utterances to make sure you'll catch a lot of variations for the same intent




2. Make sure you don't have utterances in different intents that are the same or similar (this will provide unpredictable results when the model selects an intent)




3. If your intent has slots, validate them and notify the user if the values are not what you'd expect. You can validate slots yourself in the back-end or, just added recently, you can also validate slots via dialog management. Note that you can use slot elicitation if you need to get a valid slot value from the user after validation fails




4. Do not create intents with a lot of random utterances since you risk messing up the model for the skill, as would creating slots for that purpose. The trade off is not worth it. If you still want a workaround try this




5. You can create an intent to handle out-of-domain utterances that you can kind of anticipate. For example a lot of skills in en-US have an intent that can handle bla bla bla as people tend to say it




6. Do not rely on catch all handlers (canHandle() set to always return true) to help you with this. Some examples use an UnhandledIntentHandler and mislead people to think out-of-domain utterances will be handled by it which is not the case if there's no FallbackIntent. Similarly, do not rely on an ErrorHandler added via addErrorHandlers() as it will only trigger is there's an actual error in the code which is not inside a try/catch

As soon as Amazon.FallbackIntent becomes available in your locale implement it and get rid of your own out-domain intents and/or workarounds if you have them

Since there is no AMAZON.FallbackIntent Alexa always tries to map it to the closest intent.

ErrorHandler is triggered when there's an actual error in the code which is not inside a try/catch or there are no intent handlers ( including UnhandledIntentHandlers) that can fulfil the request. Do not get confused between ErrorHandlers and UnhandledIntentHandlers. ErrorHandlers are for handling errors and UnhandledIntentHandler are/should be an IntentHandler for handling unhandled intents.

In your, case each time an intent is mapped even for the gibberish utterances. As a result there is always an intent handler and ErrorHandler is never called.

Since AMAZON.Fallback cannot be used, try these:

1. Validating slots:

Consider the following utterance:

[BuyProductIntent]
Utterances:
I want a large pizza
give me a large pizza

which can be changed to

I want a size product
give me a size product

where

size-> regular, medium, large
product->pizza, burger

Now whenever your backend receives an BuyProductIntent request, validate the slots and respond with appropriate message. If some how BuyProductIntent is triggered with some gibberish the slots won't be filled and hence you can assume that something is not right. You could then respond something like this.

"Sorry, I didn't understand. Do you want to order pizza"

This is not a complete solution, but this will certaianly help you to reduce this issue. Moreover, validating slots is always a good idea.

2. Add an OutOfDomainIntent

Create an OutOfDomainIntent and add some totally random gibberish and utterances that your skill wont support and respond with a proper error message. Make sure that this wont affect your interaction model design or VUI. Be very careful with this, do not do this unless you know what you are doing and there is no other way. This is not recommended.