What is the conceptual relation between Entities and Slots?

Hi everybody! I am porting AWS Alexa-based voice bot to Rasa and I am struggling with how to translate concept of slots and slot types to Rasa properly. I apologize in advance if this post feels blunt but I am really confused here :crazy_face:.

In Alexa, the interaction model (nlu+domain in Rasa) is quite simple:

  • user utterance maps to intent (the same way as in Rasa)
  • utterance may contain slots - or more precisely values that are extracted and stored to slots
  • each slot is of given type - either built-in (number, duckling-style, etc.) or custom - mostly enumerated values

This is a concept where slot is akin to variable in programming and slot type is, well, its type and every developer understands this right away. It also naturally allows to have multiple slots of the same type in single utterance - you just extract them into different slots.

Now I am wondering how to translate this model correctly to Rasa. The straightforward way is that extracted slots become entities and if there is a slot with the same name, it is filled with the extracted value.

But this looks severely limiting - consider e.g. banking application where there are plenty of amounts and currencies in different utterances and contexts, e.g. as payment order, transaction, debt or interest amount and you must never mix and match them. Yet that is exactly what Rasa forces me to do because there is the only single “currency” entity/slot that gets filled in every utterance regardless of context and meaning. The problem becomes painfully obvious when you have to extract two instances of the same entity in the same utterance - hence you need entity roles - a concept that seems totally redundant to me. Why can’t I fill two different slots instead of roles?

From the side of slots: slots have types, I understand that, but:

  1. Slot type is not named and reusable - when I want to use the same set of enumerated values for two slots I have to repeat them and keep them in sync
  2. Entities have sort of “type” too, given by regex, lookup table, or the like. But within implicit “entity to slot with the same name” mapping, slot and entity type are either redundant - one of them would do - or are in conflict which leads to hard-to-find errors in entity extraction.

As with previous banking example if entity serves as slot type, none of these problems would exist.

Am I getting something wrong? Or missing something crucial in Rasa bot setup? I also found this blog offering tricky ways how to map entity+role to slot so I got the feeling it is indeed an issue.

Any useful advice will be greatly appreciated :-).


Hi @kralikX, welcome to the forum!

Maybe it will help if I give a quick explantation of entities and slots.

Entities are any values that can be extracted from a user message. For example in the message: “I am Joe”, “Joe” could be the value of an entity called “name”. Or in the message: “I am happy” - “happy” could be the value of an entity called “mood”. (See: Domain)

Entities are extracted via NLU components e.g. SpacyFeaturizer, DIETClassifier or RegexEntityExtractor. (See: Components)

Extracted entities are saved on the conversation tracker and can influence the future direction of the conversation. (See: Stories)

Entity roles and groups allow for more complex splitting or grouping of similar or related entities. For example a the same entity, e.g. City, can have different roles in a sentence, e.g. departure or destination, however they are still conceptually the same entity. (See: NLU Training Data)

Slots are a separate but related concept. Slots represent data we want to store and then use again later. Slots can be filled information provided by the user but also from things like API or database calls. (See: Domain)

The setting of slot values is also stored in the tracker and can influence the future direction of the conversation. (See: Stories)

A slot can be filled using a custom action (See: Custom Actions) which can use arbitrary programming code and calculate the slot value any way it pleases.

A slot can also be filled following entity extraction. One way is slot auto-fill (See: Domain) where if an entity and slot have the same name the slot will be automatically filled when the entity is extracted.

Another way is though the use of forms (See: Forms). Forms are a collection of slots that you can fill from extracted entities from within a conversational “loop”. When the form loop is active extracted entities will be put into the slots that reference them.

I hope this makes the relationship between entities and slots clearer. Let me know if anything is still unclear or you have any other questions.

1 Like

in rasa entity is rather abstract piece of information that is extracted from user utterance only, while slots are contextual. In Rasa, slots with different names should be filled in a custom action that is predicted by dialogue policy. If you need to fill a bunch of slots in a form fashion, I recommend to use a FormAction

Hi, @jjuzl - thanks a lot for your explanation, it cleared the concepts a lot. I guess this kind of overview should really be in the docs, it would help many readers new to Rasa to get on track.

It does indeed confirm the mental image I made about the Rasa basics. However neither your explanation nor comment from Ghostvv answers central question of my post - why there is a distinction between slots and entities in the first place?. You write that the concepts are “separate but related” but your post mainly names capabilities that are the same for both entities and slots. You also name few differences (slots can be filled e.g. from DB), but these are descriptions of current implementation differences not necessary conceptual distinctions.

Please don’t regard it as that I am contesting Rasa design decisions - the framework is indeed a great piece of software - rather as a proposal of making Rasa just a little simpler and easier to use. When entities become slot types I believe there are benefits:

  • you get rid of both entity roles and groups and replace them with existing slot feature
  • you no longer need to duplicate some type definition info in slots and entities (e.g. categorical slot types and corresponding entity lookup table)

The drawbacks I am not aware of, are there any?