Confused about slot types and their impact on entity detection

This is a companion post to my original issue [Inform acting quirky, might it be my training data? - #5 by saurabh-m523 ], but I didn’t want to diverge the thread in the other post to get clarification about something.

If you don’t read the other post, I’m basically trying to conversationally change slot values instead of the bot asking for specific values, it makes the experience more open ended and real-life.

For example : my first name is Jon / my last name is Wheat

In playing around I changed the slot type from unfeaturized to text. I still get some odd behavior, but initially it seems to work.

The docs say

Unfeaturized Slot:

There will not be any featurization of this slot, hence its value does not influence the dialogue flow and is ignored when predicting the next action the bot should run.

What I’m confused about is this. As far as I can tell the training data is using an entity for training not slots, and the stories also set an entity training value.

Why would changing a slot type have an impact on the proper detection of what I’ve typed and the prediction of what it should do with what I’ve typed?

I have a repo here if you’re curious what I’ve done - specifically the config-slot-text branch

Thanks for any pointers and corrections

Hi Jonathan,

In general, don’t use featurized slots. Use them only if you want the value of the slot to be used to control the flow via stories. In most use cases, forms are a better way to manage the dialogue.

For names, you should try Spacy for entity extraction. You will still probably want to use a form to help verify that you’re setting first and last name correctly based on the dialogue flow.

Greg

I feel like Forms are pretty strict, and I’ll essentially have a form action for each field I want to change, as opposed to forcing a user down a formAction to change / verify each field one after the other.

I’ll try it anyway to see how it goes.