- 3 scenarios where you should avoid using slot filling in Dialogflow
- Why I avoid using slot filling (required parameters) in Dialogflow
- What is slot filling using webhooks?
- Reader Question: Slot filling vs follow up intents
- Reader Question: Slot filling via REST API
Also check out my free Understanding Slot Filling guide – it shows you what happens under the hood when you use slot filling and why it is such a challenge.
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.