This post is somewhat of an opinion post, but it is based on my experience using slot filling as well as helping my clients get unstuck by moving them away from slot filling.
Why I avoid slot filling
In my view, slot filling makes four implicit assumptions:
- perfect entity recognition
- complete entity definition
- perfect spelling
- full cooperation from user
Let me explain these one by one.
Perfect entity recognition
If you have used Dialogflow for a while, you already know it struggles with non-English names. If you make one of your slots a @sys.given-name, odds are it will repeatedly fail for many different names which you would expect it to handle.
Complete entity definition
So you realize you cannot get Dialogflow to identify all the non-English names. So you decide to augment it by adding some names you want it to handle - for e.g. the name of your boss.
But there is a limit to how far you can go with this system - because soon the chatbot creator needs to take responsibility of defining every possible entity value.
You will run into this issue even if you have a developer defined entity. For example, a list of names in your organization is likely to be fluid, and you will now need to put a process in place for keeping your entity up to date.
It is a bit ironic, but the rise of chatbots is supposed to be the result of the increasing use of messaging apps. So what else resulted from the increasing use of messaging apps? Typos!
Unfortunately, Dialogflow isn't very good at handling typos in its entity recognition either.
Full cooperation from the user
So the user needs to type out a required parameter and they get stuck in the loop. How are they supposed to come out of the loop?
Apparently, by typing Cancel or some other code word. Which is OK, but how do you let the user know after they entered the loop? Dialogflow could have made it easier by either a) allowing a maximum number of retries before quitting the loop or b) having a fallback message after N retries which explains to the user that they can come out of the loop by typing Cancel or Stop.
But don't these problems happen anyway in Dialogflow?
You might ask: Other than the last one (getting stuck in a loop), aren't the others already issues with Dialogflow anyway?
Yes, but if you don't use slot-filling, you have a lot more options to handle these things gracefully. You can
- choose to do a fallback where you reprompt once, and then you quit that particular input if there is a second fallback
- with a more complex UI, you can choose to show a list of options the user can select from after the first fallback
- with a complex UI, when there are typos, you can choose to show a list of options with spelling similar to the typo
Slot filling doesn't cause the issues I mentioned (except the last one), but it makes it very hard to handle the them.
Check out my guide to Dialogflow slot filling.
- Using Collect.chat for preNLU bots
- Reader Question: How to get some sample training data for Dialogflow?
- Getting the top 3 (or top N) intents in Dialogflow: An experiment
- Dialogflow Regexp (regular expression) entity
- Using Dialogflow for educational bots
- Chatbot makes $3 million in sales in 1 hour
- Reader Question: Intent based FAQ bots vs knowledge based FAQ bots
- Should you use Dialogflow from scratch?
- 3 ways Airtable can speed up your Dialogflow prototype development
- Automatically generating a rich Dialogflow website chatbot