Update February 2018 - The new phrase slots are now the recommended way to collect less-predictable input. Learn more.
Today’s post comes from J. Michael Palermo IV, Sr. Evangelist at Amazon Alexa. You will learn why you should use a custom slot instead of the soon to be deprecated AMAZON.LITERAL.
We’ve been listening to your feedback for Alexa feature requests and questions. As such, this post provides details around the deprecation of literal slots. By the time you finish reading this post, you will see it doesn’t matter that the LITERAL slot type is going away because it already has a better replacement: custom slot types.
Before we get into the details, it’s clear that the community needs more time to experiment with custom slot types and to make the transition. So, we’re moving the LITERAL deprecation date for US skills to Feb 6th 2017. From the beginning, custom slot types (and not LITERAL) have been the solution in the UK or Germany.
Slots let you to build interaction models and pass phrases from the user to your skill. Amazon provides a set of built-in slot types that cover common things like numbers, names, and dates. Custom slot types go beyond these to enable support for the scenarios that you’ve chosen to build. They are a superset of the LITERAL slot type that we’re deprecating.
This post will describe how to support three common LITERAL scenarios we’ve seen.
Imagine a situation where you want to gather information from users that you don’t know when you build your interaction model. Examples include things like lists of wines, items in a game, names of cities, nicknames, etc. It’s clear that you could build a custom slot with all the values that you do know but how do you handle the values that you don’t or can’t know?
First, be sure to check the list of built-in slot types. You may find something that we’ve already built for you like first names, city names, last names, dates, numbers, and many more.
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.
Let’s look at an example of how to build support for something like nicknames. The custom slot type is named NICKNAMES. The custom slot values are shown here:
The intent schema uses NICKNAMES instead of AMAZON.LITERAL, and the sample utterances don’t require any sample slot data.
The following interactions that include nicknames not in the custom slot values yield the same as a LITERAL slot:
Utterances | Value |
“to make my nickname super nerd” | super nerd |
“to address me as master chief” | master chief |
“to call me head of household” | head of household |
Notice that in addition to achieving the desired functionality, custom slots also have a couple of extra benefits. Rather than having to add training data directly in the sample utterances like, SetNickname call me {geek|AMAZON.LITERAL} and SetNickname to nickname me {techie| AMAZON.LITERAL}, you can now add training data to improve accuracy once to the custom slots values and that training will apply to all utterances using the Nickname slot. So, it’s easier to tune for accuracy and utterance management is simpler.
If you expand your use of custom slot types to cover the grammar of your utterances, you can increase the number of variations that you train with the same or simpler utterance list.
Additionally, you can now collect the values for Action, Moniker, and Nickname so you can track how people are making the requests to set their nickname. It’s possible that people would say something like “use Paul as my tag”. With this, you could log an action of “use” and a moniker of “tag” and then update your code if those become popular.
You can also pass this data off to post processing, like sentiment analysis, and you can use elements like the Action or the Moniker to tune the response. (Ex: “ok, I’ve set your tag to Paul”)
To do this, you’d add more custom slots:
You’d also add custom slot values for Actions like:
You’d also add custom slot values for Monikers such as:
The new phrase slots, introduced in February 2018 are now the recommended way to collect less-predictable input. Learn more by reading this blog post.
Yes, a custom slot type can do everything the LITERAL slot type can do, but with simpler management of training data and easier to read sample utterances. Transitioning from LITERAL to custom slot types is primarily done in the Interaction Model section of the developer portal, not in code. There is literally no reason to hesitate using custom slots today!
Special thanks to Paul Cutsinger, Josh Campbell, and Sara Schertz for their technical contributions!