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

Bypass NLU pipeline when message is /intent or /intent + entities - [ENG 286] #12480

Merged
merged 17 commits into from
Jun 22, 2023

Conversation

varunshankar
Copy link
Contributor

@varunshankar varunshankar commented Jun 8, 2023

Proposed changes:

  • Bypass NLU pipeline when message is /intent or /intent + entities

Status (please check what you already did):

  • added some tests for the functionality
  • updated the documentation
  • updated the changelog (please check changelog for instructions)
  • reformat files using black (please check Readme for instructions)

@varunshankar varunshankar requested a review from a team June 8, 2023 22:57
@varunshankar varunshankar requested a review from a team as a code owner June 8, 2023 22:57
@varunshankar varunshankar self-assigned this Jun 8, 2023
@varunshankar varunshankar removed the request for review from a team June 8, 2023 22:58
Copy link
Contributor

@twerkmeister twerkmeister left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job so far! Can you also add the changelog file?

If we really wanted to do this right we should probably also address the following:

  • This change is currently difficult to test, because the RegexMessageHandler is still in the graph. We should remove the RegexMessageHandler from the graph ultimately, but this also involves touching the default recipe etc, because all NLU calls currently target this component as the execution target if I remember correctly.
  • We'd need to take a deeper look whether the http interpreters should actually also be covered by the regex parsing. This could be relevant if we remove the RegexMessageParser from the graph and then the http interpreters might not have any regex message parsing at all anymore. I am not really familiar with them

@varunshankar
Copy link
Contributor Author

Good job so far! Can you also add the changelog file?

If we really wanted to do this right we should probably also address the following:

  • This change is currently difficult to test, because the RegexMessageHandler is still in the graph. We should remove the RegexMessageHandler from the graph ultimately, but this also involves touching the default recipe etc, because all NLU calls currently target this component as the execution target if I remember correctly.
  • We'd need to take a deeper look whether the http interpreters should actually also be covered by the regex parsing. This could be relevant if we remove the RegexMessageParser from the graph and then the http interpreters might not have any regex message parsing at all anymore. I am not really familiar with them

Thanks a lot @twerkmeister, your review was very helpful. Is it better that I create a separate task to handle the comments that you said here?

@varunshankar varunshankar changed the base branch from 3.5.x to 3.6.x June 15, 2023 09:50
@varunshankar varunshankar requested a review from a team as a code owner June 15, 2023 09:50
@varunshankar varunshankar requested review from rasa-aadlv and removed request for a team June 15, 2023 09:50
@m-vdb
Copy link
Collaborator

m-vdb commented Jun 16, 2023

@varunshankar given that 3.6.0 has already shipped and this is a new feature, I would suggest to merge this into main instead of 3.6.x

@varunshankar varunshankar changed the base branch from 3.6.x to main June 16, 2023 08:14
Copy link
Contributor

@twerkmeister twerkmeister left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🚀

Comment on lines +117 to +136
with mock.patch(
"rasa.core.processor.MessageProcessor._parse_message_with_graph"
) as mocked_function:
# Case1: message has intent and entities explicitly set.
message = UserMessage('/greet{"name": "boy"}')
parsed = await default_processor.parse_message(message)
assert parsed["intent"][INTENT_NAME_KEY] == "greet"
assert parsed["entities"][0]["entity"] == "name"
mocked_function.assert_not_called()

# Case2: Normal user message.
parse_data = {
"text": "mocked",
"intent": {"name": None, "confidence": 0.0},
"entities": [],
}
mocked_function.return_value = parse_data
message = UserMessage("hi hello how are you?")
parsed = await default_processor.parse_message(message)
mocked_function.assert_called()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is really smart, I didn't know something like this was possible 😎. Very cool!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks Thomas, means a lot 😄

@github-actions
Copy link
Contributor

🚀 A preview of the docs have been deployed at the following URL: https://12480--rasahq-docs-rasa-v2.netlify.app/docs/rasa

@varunshankar varunshankar merged commit 59a46a6 into main Jun 22, 2023
@varunshankar varunshankar deleted the ENG-129-NLU-bypass branch June 22, 2023 12:47
souvikg10 pushed a commit that referenced this pull request Jun 26, 2023
…ENG 286] (#12480)

* Bypass NLU pipeline when a message is /intent or /intent + entities
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants