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

ELICIT_RESPONSE_DEFAULT_MSG can't be changed #745

Closed
6 tasks
seano10 opened this issue Jun 28, 2024 · 3 comments
Closed
6 tasks

ELICIT_RESPONSE_DEFAULT_MSG can't be changed #745

seano10 opened this issue Jun 28, 2024 · 3 comments
Labels

Comments

@seano10
Copy link

seano10 commented Jun 28, 2024

Describe the bug
The default value for the field ELICIT_RESPONSE_DEFAULT_MSG is "OK.". I have tried changing it to a different value (eg "", or "W") but although I am able to save the settings the behaviour still returns "OK." In fact it returns even if I have provided a response message, meaning that I actually get "OK. Ok, thank you", when it should just return "Ok, thank you".

To Reproduce
Change the ELICIT_RESPONSE_DEFAULT_MSG in the settings tab of the QnA bot and then utilise the elicit response feature in an answer.

Expected behavior
I expect the returned value to include the value set in the ELICIT_RESPONSE_DEFAULT_MSG field, instead it always returns "OK."

Please complete the following information about the solution:

  • Version: 5.5.2

To get the version of the solution, you can look at the description of the created CloudFormation stack. For example, "(SO0189) QnABot [...] v0.0.1".

  • Region: [e.g. us-east-1] eu-west-2 (London)
  • Was the solution modified from the version published on this repository? No
  • If the answer to the previous question was yes, are the changes available on GitHub?
  • Have you checked your service quotas for the services this solution uses? yes
  • Were there any errors in the CloudWatch Logs? no

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Add any other context about the problem here.

@seano10 seano10 added the bug label Jun 28, 2024
@fhoueto-amz
Copy link
Member

Thanks, for raising this. We will analyze and revert back.

@fhoueto-amz
Copy link
Member

fhoueto-amz commented Jul 3, 2024

@seano10
The settings in the content designer is not well described. The Elicit_response_default_MSG setting is the default message that qna_bot will assume is coming from the elicit bot if the elicit bot closing response is empty (therefore the default in the setting name). We will clarify this in our UI and documentation. So this setting will typically not be used as the elicit bot will typically send back some closing response. To change the closing response sent back by the elicit response bot, you will need to go to your Amazon Lex console, find the elicit bot you are using, look at its conversational flow for the intent in question (see https://docs.aws.amazon.com/lexv2/latest/dg/understanding-new-flows.html). For example with the QNAName elicit bot, go to intent>nameIntent>conversation flow. On the last page, you will see the closing response (default is Ok.). If you want to modify that, edit the closing response to whatever you want, rebuild the bot, create a new version and set the live alias to the latest version (see https://docs.aws.amazon.com/lexv2/latest/dg/versions-aliases.html). The elicit bot answer will now be whatever you set in the closing response. Alternatively, you can delete the closing response, rebuild the bot, create a new version and set the live alias to the latest version. In that case, QnA bot will use the setting Elicit_response_default_MSG for that elicit bot as the response from that elicit bot is now empty.
in general, QNAbot does not have a control on the elicit response bot (by definition) and can only control what goes in and in some cases like the ELICIT_RESPONSE_DEFAULT_MSG, provide a default if the bot does not provide some expected output.

@seano10
Copy link
Author

seano10 commented Jul 4, 2024

@fhoueto-amz
Thank you for the quick turnaround on this, I will take a look at what you suggest but that makes sense now, thanks.

This was referenced Jul 19, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants