FAQ intent identification when input type set to from_text

Getting Started with Rasa Tutorials, Resources & Videos
,
1

Hi Team,

We have a form, having a slot named “shiftdescription” which can take random text value as input and hence we have set the input type to from_text.

We also have FAQ intent defined, which can be invoked at any time within the form or outside the form.

Below are the sample conversation snippets:

  1. Bot: Enter the shift description. User: Regular shift

  2. Bot: Enter the shift description. User: Morning shift

  3. Bot: Enter the shift description. User: What is shift?

Since the input type for shift description is set to from_text, in examples 1 and 2 values, Morning shift and Regular Shift gets stored in Shift Description slot correctly.

But in example 3, the value “What is Shift?” gets stored in Shift description slot, which is incorrect. Instead, the utterance “What is shift?” is defined under FAQ intent and corresponding response for the utterance should be displayed, which is not happening.

Could you please help us in this regard. If there is any way out , please let us know.

Thanks , Anjali

2 Likes
2

Hi Team,

Any thoughts about above query?

3

We have the same requirement as well, as explained above.

If anyone can please share points on this it would be helpful.

Thanks, Anirudh

4

@Anjalipatel there are a couple things you can do to handle this scenario. When you define the slot mappings in your form you can specify that text should only allowed if it maps to a certain intent. This is described in the docs here.

You can also handle instances where users ask a FAQ within a form by creating a rule. You can define a rule to handle these unhappy paths within forms like this example from the docs.

5

Thankyou so much @m.vielkind for your response. More or less, we have tried the options you have mentioned. The particular slot (mentioned in query) can take any random text value and since we are not able to define specific values to be captured we have made it as from_text. If we specify intent name also it is not classifying it to the specified intent since the slot can take any random text value and classifies it to be fallback.

For FAQ, we have written rules (unhappy paths) and it is working fine for slots having classification as from_entity, but when we have slot with from_text even though it recognizes it to be FAQ, the intent classification gets overridden and the slot is filled with the FAQ question that is uttered by the user. So, basically it’s failing to respond to that FAQ.

I hope, this description makes the scenario clear. Please let me know if more details are needed.

Thanks, Anjali

6

Could you share what your form and rules look like?

7

This is how it looks:

forms:

shift_form:
a_shiftname:
- entity: shiftname
  intent: give_shiftname
  type: from_entity
b_shiftdescription:
- type: from_text
  • rule: FAQ Interruption condition:
    • active_loop: shift_form steps:
    • intent: faq
    • action: utter_faq
    • action: utter_answered
    • action: action_listen
    • action: shift_form
    • active_loop: shift_form

Thanks, Anjali

8

Thanks! I think you need to make one update to your form adding the not_intent option to the b_shiftdescription slot:

shift_form:
  a_shiftname:
    - entity: shiftname
      intent: give_shiftname
      type: from_entity
  b_shiftdescription:
    - type: from_text
      not_intent: faq

What this instructs is to fill the b_shiftdescription slot with any text except if the intent for the user input is a faq. Now if the user responds with a faq your rule should takeover by responding to the FAQ and then asking for the b_shiftdescription slot again.

1 Like
9

Thanks @m.vielkind , we’ll try implementing this and get back.

10

Hi @m.vielkind , Good Day!

image
image996×402 26.4 KB

As mentioned in Screenshot above, InMemoryTrackerStore stores the conversation history in memory. I want to know, how can i access the entire stored history.

Could you please help me in this regard? If there is any way out , please let me know.

Thanks, Anjali