Entity groups in rasa 2 forms?

Rasa Open Source
1

Hi,

I’m looking for help to use

My example is a purchase dialog that allows the user to specify any number of entity groups, e.g.:

  • Buyer: I would like to buy some apples and 5 bananas.
  • Seller: Sure. How many apples did you want?
  • Buyer: 3.
  • Seller: Anything else?
  • Buyer: Yes. 2 Oranges.
  • Seller: That’s… $$

So there are 2 challenges:

  1. the user can provide more than 1 entity group per utterance
  2. the bot needs to ask for any missing information (e.g. quantity) in any of the entity groups

Can the Rasa forms handle this? How?

2

Hey @andreaschuch, thanks for the interesting question!

Regarding the 1st challenge, that should be doable with entity groups:

I would like to buy [some]{"entity": "amount", "group": "1"} [apples]{"entity": "type", "group": "1"} and [5]{"entity": "amount", "group": "2"} [bananas]{"entity": "type", "group": "2"}.

As for the 2nd challenge, forms may or may not be the best solution. Forms are relatively rigid – they are best at asking for some pre-determined kind of information. Your example scenario looks like there is no information that the assistant wants to collect at the beginning – instead, it lets the user provide some information and then it asks only for some missing pieces (like the number of apples). In this sense, maybe creating the logic for this in a custom action would be better.

However, if you want to use forms, you’ll want to dynamically change the set of required slots (see the docs) by overriding the required_slots method, where you’ll condition on current slot values to request the correct next slot. You might also need to generate the actual questions in a context-sensitive way (this could help), but that’s I guess something to think about once the previous things work :slight_smile:

Let me know how it goes!

3

Hi @SamS,

very happy to read your considerate reply! :slight_smile: My code is all checked in at GitHub - andreaschuch/purchase_dialog at entity_groups, in case you want to take a look to point out specific mistakes on my side.

For the entity groups, I did annotate the NLU-example just like you describe, except that I don’t annotate the word “some” as it does not provide quantity information.

However, Rasa interactive learning comes back with a different annotation, for example:

Is the intent 'order' correct for '[15]{"entity": "quantity", "group": "1"} [apples](commodity)[apples]{"entity": "commodity", "group": "1"}' and are all entities labeled correctly? (Y/n)

which is also stored in the training data. (NB: Also know that whenever I correct something in interactive learning, the training data gets all messed up.)

So is

[apples](commodity)[apples]{"entity": "commodity", "group": "1"}

correct, or should it rather be

[apples]{"entity": "commodity", "group": "1"} ?

One NLU-error I see frequently is that a the groups get messed up, for example:

Is the intent 'order' correct for '[2]{"entity": "quantity", "group": "1"} [apples](commodity)[apples]{"entity": "commodity", "group": "1"} and [3]{"entity": "quantity", "group": "1"} [pears](commodity)[pears]{"entity": "commodity",
     "group": "2"}' and are all entities labeled correctly?  (Y/n)

even though the exact utterance is in the NLU training data. Not sure if there is hope, to get correct group classifications for “2 apples and 3 pears”, “3 apples and 2 pears”, “3 pears and 2 apples” and “2 pears and 3 apples”?

Regarding the dialog flow, I did indeed implement a custom action (see purchase_dialog/actions.py at entity_groups · andreaschuch/purchase_dialog · GitHub) My main obstacle with the forms was that they would not ask for quantities as soon as at least 1 quantity was set. So for example, “apples and pears” would ask for quantities, because no quantities were set. But “1 apple and pears” would not ask for quantities, even though the quantity was missing in the second group. I have a question for you: Do you think asking for every value missing in any of the groups would make sense as default behavior of forms? Or is it that I’m just thinking along my own usecase, and you can imagine other usecases where this behavior is not desirable?

I would like to start another attempt using forms, if you could elaborate a little more how the “required_slots” method can help with the problem?

4

Hey @andreaschuch,

the duplicated entity annotation happens because you have two entity extractors in the pipeline. The regex extractor creates the simple annotation ([apples](commodity)) and DIET creates the complex one that includes group information. I recommend removing the regex extractor from the pipeline (or at least not using it for the entities which you want to handle with DIET).

Not sure if there is hope, to get correct group classifications for “2 apples and 3 pears”, “3 apples and 2 pears”, “3 pears and 2 apples” and “2 pears and 3 apples”?

Surely there is hope, but you’ll have to provide DIET with enough data to learn from. It is quite possible that with little data the model won’t learn to correctly label all the examples you’ve enumerated. Entity groups and roles take a lot of data to be learned properly.

As for the dialog flow, I think you’ll have to build the logic that controls what gets asked about when. I thought it could be combined with forms, but now seeing that you’ve created a custom action already, I would say: You’ll see, maybe that’s easier than using forms (by the way, think of forms as just a special type of a custom action that should make your life easier in specific situations, but never harder). I won’t propose a solution here, I’ll just note that required_slots could be used if you wanted to dynamically add slots to be requested – whether this adding would happen while extracting information from user utterances (in custom extract_<slot_name> methods), during validation in individual validate_<slot_name> methods, or even after that somewhere like in request_next_slot. However, I’m not proposing any concrete way of how forms could deal with the quantity and commodity slots set separately for many different fruits…