Skip to content
← Alexa Skills - Developer Voice And Vote

How can we improve Alexa Skill development services and tools?

Alexa Skills - Developer Voice And Vote: Other

Categories

JUMP TO ANOTHER FORUM

(thinking…)

Allow skill to anticipate/disallow specific intents during conversation

I would like my skill to be able to listen for specific responses, i.e. make Alexa bias towards utterances of one or multiple intents that I specify in the skill's response, for the next user input.

For example, let's say my skill has a CityIntent which has utterances:

  • I live in {city}
  • It is {city}
  • {city}

And my skill has another MovieIntent which has utterances:

  • I like {movieType}
  • I prefer {movieType}
  • {movieType}

And at certain times my skill may also expect {yes/no} answer from user.

Since {city} and {movieType} have different value, Alexa usually does a good job of figuring out which intent should be mapped.

However, sometime the single word utterances are incorrectly mapped to wrong intents, and there's very little or hacky way for my skill can cope with such cases.

Therefore I want my skill to have the ability to specify what the NEXT intention user is likely to make, at any point during conversation. Then Alexa can bias the listening towards the likely utterances and map to the correct intents.

I have looked into DialogModel, however it doesn't seem to be applicable because it doesn't allow switching intent, i.e. my code cannot be handling MovieIntent and then request Alexa to ElicitSlot for CityIntent.

Thanks!

84 votes

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close

We’ll send you updates on this idea

Daniel Lam shared this idea  ·   ·  Report…  ·  Admin →
How important is this to you?

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Comments are closed An error occurred while saving the comment
  • Tom Hewitson commented  ·   ·  Report

    We'd like to be able to do this too as we have intents with large numbers of slot values which tend to match more often even when they're not needed for that specific interaction.

  • Uday Dhadve commented  ·   ·  Report

    Instead of telling what Intents to consider we can also specifically target an Intent after one. Example,
    1) Plan my trip
    - Response cab be something like Sure, Tell me where you would like to go?
    2) Now in First step, we can target bookTripIntent, and map out the questions one by one, in the same intent and always ask for same intent i.e. bookTripIntent to be triggered for this entire context, until we reach the end, or user wishes to discontinue.
    We can map the context by storing the questions one after another in session/persistent store.

  • VoiceShouldFlow commented  ·   ·  Report

    The following workaround would work.

    Make a third Intent named, "Single-word-intent" and in that intent, determine if it is a movie or a city based on the context, then call the appropriate CityIntent or MovieIntent.

    In general, with the way Alexa works, it's better to define intents based on reply types ("Such as Yes/No, Movie name, City name, numbers, long descriptive sentences, etc), and then determine the true intent (cancel the subscription, buy the movie, delete a movie, etc) based on the context and what is spoken.

  • Jeffrey Perrone commented  ·   ·  Report

    We need Intent Context as described by Mark Tucker below!

  • Ryan Clancey commented  ·   ·  Report

    What would really make things easier is if the skill could elicit a slot for any intent, not just the current intent. If the user can switch intents, the skill ought to be able to as well.

  • Giorgio Robino commented  ·   ·  Report

    Hi Mark, I voted and of course I fully agree with the change request you propose.

    I reckon there are some simple solutions to manage the required state machine.
    1/ simple:with a simple modification of intent model, adding a "state" attribute.
    2/ a bit complex: decomposing the "singleton" Alexa cloud side machine learning in multiple learnings ( basically: different ML for different states(contexts you say).

    my two cents
    giorgio

  • Giorgio Robino commented  ·   ·  Report

    Hi Mark, I voted and of course I fully agree with the change request you propose.

    I reckon there are some simple solutions to manage the required state machine.
    1/ simple:with a simple modification of intent model, adding a "state" attribute.
    2/ a bit complex: decomposing the "singleton" Alexa cloud side machine learning in multiple learnings ( basically: different ML for different states(contexts you say).

    my two cents
    giorgio

  • Mark Tucker commented  ·   ·  Report

    1. One word/one phrase utterances are part of natural conversation: Yes, No, Fargo, Harry Potter
    2. Generally, all intents in a skill are candidates for all utterances a user speaks which can lead to intent confusion and the wrong intent being selected.
    3. Dialog Management's purpose is slot filling of one or more slots. It requires an intent with one or more slots with surrounding text or a text phrase.
    4. Once an intent is selected, Dialog Management can weigh remaining slot values higher then the intents in the skill.
    5. State Management is not a first-class construct and is enabled by storing session state and round-tripping those values in subsequent requests. The Alexa service makes no use of STATE when determining which intents are candidates in the current context of the conversation. Once an intent is selected, STATE allows different code to run for the same intent.
    6. What is needed is a way for developers to influence how the Alexa service selects candidate intents for consideration. When conflicts between intents occur, developers can provide additional context to get the needed conversational experience. Intent Context solves this issue.