Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retrieval intent needs to store full intent name in tracker #4826

Closed
rgstephens opened this issue Nov 22, 2019 · 12 comments · Fixed by #5432
Closed

Retrieval intent needs to store full intent name in tracker #4826

rgstephens opened this issue Nov 22, 2019 · 12 comments · Fixed by #5432
Assignees
Labels
type:enhancement ✨ Additions of new features or changes to existing ones, should be doable in a single PR

Comments

@rgstephens
Copy link
Contributor

Description of Problem:
The intent ask_faq/python_version is grouped into a single retriever event and placed in the tracker store as ask_faq. If you are using the TwoStageFallbackPolicy and the ActionDefaultAskAffirmation to further contextualize the conversation with the user, lack of the full intent name means you cannot determine the users intent.

Overview of the Solution:
Store the full intent name in the tracker store when using retrieval intents.

@rgstephens rgstephens added the type:enhancement ✨ Additions of new features or changes to existing ones, should be doable in a single PR label Nov 22, 2019
@amn41
Copy link
Contributor

amn41 commented Nov 23, 2019

it should be available in the tracker.latest_message right? that should contain the top predicted response for the retrieval action

@erohmensing
Copy link
Contributor

erohmensing commented Nov 25, 2019

@amn41 maybe so, but not sure that solves all the problems this issue causes:

ask_faq/python_version is grouped into the single retriever intent and placed in the tracker store as ask_faq

This seems less than ideal, i’ve also been talking to a customer who ran into this. Their use case involves lots of FAQs, but they want to know which ones are being asked the most so they can turn those into further contextual conversations to continue to help the user. as of now it is impossible when looking in the tracker store to filter by the specific faq.

@amn41
Copy link
Contributor

amn41 commented Nov 25, 2019

right, but that isn't the use case for retrieval actions. Retrieval actions are there to cover all the things where context doesn't matter, like FAQs https://rasa.com/docs/rasa/dialogue-elements/completing-tasks/#simple-questions . If you need to handle it differently, it should be a separate intent

@erohmensing
Copy link
Contributor

The idea here is to be able to decide, out of these questions, which ones should actually be handled differently, which they can't do without conversations with real users, to see which paths should have further information. I guess you could do that by having them all as separate intents, but it IMO feels like we're missing an easy win here by not letting you filter by the sub-intent

@amn41
Copy link
Contributor

amn41 commented Nov 25, 2019

ok, I get it now! Yeah it would be great to have a way to find out which faqs should be "promoted" to real intents

@erohmensing
Copy link
Contributor

I think that fits super well into "Moving from step 2 to step 3" dialogue as well -- first start with handling a bunch of faqs, then see what ones your users have follow-up questions for

@erohmensing
Copy link
Contributor

cc @akelad ideas for moving from step 2 to 3

@erohmensing erohmensing self-assigned this Dec 2, 2019
@erohmensing erohmensing assigned rgstephens and unassigned erohmensing Feb 1, 2020
@erohmensing
Copy link
Contributor

@rgstephens is this still happening?

@akelad
Copy link
Contributor

akelad commented Mar 2, 2020

not by Greg probably. Do you want to take it on instead? Or should this be on a different board?

@rgstephens
Copy link
Contributor Author

@erohmensing do you want to do a code walkthrough on where I left this?

@akelad
Copy link
Contributor

akelad commented Mar 12, 2020

@melindaloubser1 is gonna look into this, so maybe you two can chat

@indam23 indam23 linked a pull request Mar 17, 2020 that will close this issue
4 tasks
@indam23
Copy link
Contributor

indam23 commented Mar 17, 2020

@erohmensing should this be based off of master and go into 1.9? I've transferred the work Greg and Daksh did to a branch off of 1.8.x but I realize it will break loading old models since it will look for an extra file (response_text_key-dict) to load from and won't find it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:enhancement ✨ Additions of new features or changes to existing ones, should be doable in a single PR
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants