Why I avoid slot filling

This is a somewhat opinionated view, 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.

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 – specifically the @sys.given-name entity. The @sys.person entity works better. 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 the employees in your organization.

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.

Perfect spelling

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, although it is quite good for regular words.

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 recover from them.