Typless input for Alexa

#1

Hello,

I need Alexa to recognize an input without sample values for input type or proprietary amazon types. If I build this into the language model, I am unable to deploy. Is there any way to do this?

Best regards and thanks in advance!

#2

Like is there an Amazon equivalent to dialogflow’s @sys.any

#3

AMAZON.SearchQuery should get you the result you want mate.

#4

I have tried that, but I need the input value to stand alone. Amazon.SearchQuery, to my understanding, needs a supplemental search phrase.

That is the closest thing to a solution I have found. I appreciate the suggestion. If anyone has any other suggestions that would be hugely appreciated!

Thank you in advance!

#5

Do you mean to say that giving it an input type that is defined with an empty “values” array does not work in production? That would be a big problem for me as well. I’ve only been prototyping locally and haven’t deployed yet :confused:

#6

I am not sure I understand?

My issue is that I need Alexa to recognize a sample input like:

"{bookName}"

AMAZON.SearchQuery requires a suplemental search phrase like:

"I would like to search for {bookName}", 
"I want {bookName}"

It won’t deploy if ‘bookName’ is type ‘AMAZON.SearchQuery’ and there is no supplemental search phrase. I am looking for a solution around this problem. Is this something similar to what you’re experiencing?

#7

Yes, that is what I need too. For local development I’ve been doing this:

   {
		"name": "AnswerIntent",
		"phrases": [
			"{answer}"
		],
		"inputs": [
			{
				"name": "answer",
				"type": {
					"alexa": "GenericInputType",
					"dialogflow": "@sys.any"
				}
			}
		]
	}

And my inputTypes looks like this:

"inputTypes": [
	{
		"name": "GenericInputType",
		"values": []
	}
]

Will this not work if deployed?

#8

i don’t think this will work. How have you been testing it?

#9

It’s been working locally with the jovo debugger. I haven’t deployed it anywhere yet.

#10

Jovo Debugger only creates JSON requests, there is no speech recognition or natural language understanding happening there. For stuff like this, there is always the need to test on the actual platforms

#11

Got it. Thanks! Do you see any workaround to this? I heard there used to be something along the lines of dialogflow’s sys.any but it was removed for various reasons.

#12

I also need to recognize arbitrary input with a catch all slot, without suplemental words. This allows me to accept more natural inputs and be able to log the raw input too.

The solution I’m using right now is the following (fairly similar to your answer above):

"intents": [
	{
		"name": "CatchAllIntent",
		"phrases": [
			"{answer}"
		],
		"inputs": [
			{
				"name": "answer",
				"type": {
					"alexa": "CatchAll",
					"dialogflow": "@sys.any"
				}
			}
		]
	}
],
"inputTypes": [
	{
		"name": "CatchAll",
		"values": [
			{
				"value": "hey hey hey"
			},
			{
				"value": "hey hey"
			},
			{
				"value": "hey"
			}
		]
	}
]

I haven’t deployed it yet, I hope this works in production.

However, this approach has some drawbacks I found in Alexa:

  • Single-word answers are not recognized when adding suplemental words to remove irrelevant information from the answer slot, for instance with a ‘I want {answer}’ phrase. With this phrase added an input ‘I want potatoes’ will work as expected filling answer to potatoes, but the input ‘potatoes’ by itself will not be recognized, I don’t know why, so you need to get it working in your backend always with the whole raw input taken by the answer slot, or have additional phrases but knowing that single word requests won’t work (or maybe working but with undefined answer slot).

  • Having other intents (e.g. AMAZON.YesIntent) will break the intent above with states, because Alexa NLU for the time being seems to be stateless, and AMAZON.YesIntent will be matched with inputs like ‘yes’ despite of having a state without YesIntent handler. In this case Jovo router will process the request with the Unhandled handler and therefore without the answer slot set, instead of matching CatchAllIntent with answer slot filled to yes, which would be the desired outcome while the state doesn’t expect any confirmation from the YesIntent.

#13

Sadly, you cannot deploy a language model with an “InputType” without values… at least as an Alexa Skill. My work around is similar to @Carleslc 's. I am running into similar problems too; namely, with Alexa’s NLU routing. I have mitigated the problem with explicit routing (toIntent(), etc) and states, though there are still frustrating bugs which persist.