This article continues to focus on the industrial-grade business dialogue platform and framework Rasa, the education Bot project Policies Data in the education field of the Rasa dialogue robot project, the training method of end-to-end and the matters needing attention when using it, the use of checkpoints, how to use it in a specific Use rules and other aspects for detailed analysis under conditions.
1. Detailed explanation of the Education Bot project Policies Data in the education field of the Rasa dialogue robot project
- Architecture Design of the Separation of Stories and Rules in Education Bot Project Policies Data
The following is a sample of stories training data. You can see that each intent and corresponding action are defined in steps, and the MemoizationPolicy or AugmentedMemoizationPolicy defined in rules.yml will search for matching data in stories according to the content of the conversation. If If matching data is found, the action in the data will be used directly as the predicted action. The prediction confidence of these two policies is either 1.0 (matching data) or 0.0 (no matching data), so if a prediction error occurs and the confidence is 1.0, no other policy can override its prediction.
The Stories data is used to train the dialogue management model, which enables the model to generalize to other currently unknown dialogue paths.
About the format:
A story is a data representation of a conversation between a user and a conversational robot, and its data format includes:
- Express user input as intents (and entities, if present)
-Represent the responses and actions of the dialogue robot as action keys
The following is an example of the story data format:
2. Analysis of the three components of User Messages, Actions and Events in Policies Data
About User Messages:
When writing stories, you don’t need to deal with the actual content of the message the user sends, but instead leverage the output of the NLU pipeline, which uses a combination of intents and entities to represent all the messages the user might send for an intent. It is important to include entities because policies are based on the combination of intents and entities to predict the next action.
About Actions:
All the actions and responses executed by the dialogue robot are defined under the action key in the stories. The responses in the stories come from the content under the responses key in the domain file, and the custom actions called by the stories come from the content under the actions key in the domain file.
About Events:
During training, Rasa does not call the action server, which means that the dialog management model of the dialog bot does not know what events a custom action will return. Based on this, events that trigger slot settings or activate or deactivate forms must be explicitly written in stories. If a slot is set by a custom action, then the slot_was_set event needs to be added after the action in the stories. The following is an example:
3. Detailed explanation and case analysis of Form Events
When dealing with forms in stories, there are three types of events to be aware of:
-form action event: will be used when the form is started for the first time, and the form action needs to be continued when the form is activated
-form activation event: used after the first form action event occurs
-form inactive event: used to make the form enter the inactive state
4. Detailed explanation and case analysis of Checkpoints
You can use checkpoints to modularize or simplify your training data, and while checkpoints are useful, don't overuse them. Using too many checkpoints can easily cause your stories training data to be hard to understand, slowing down training. A better way is to use Rules or ResponseSelector.
Here is an example of stories data that includes checkpoints:
5. Detailed explanation and case analysis of OR statements
Using the or keyword can make stories shorter, especially when dealing with multiple intents or slot events. If you ask the user to confirm something, for example, you can treat both intents confirm and thank you in the same way. The following story will be converted to 2 stories for processing during training:
The following is an example of handling multiple slots events, for example the value of the slot can be set to one of two values:
6. End-to-end Training working mechanism analysis and case analysis
When using end-to-end training, there is no need to process intents based on user messages extracted through the NLU pipeline, or use responses in the domain file alone. You can include user messages and chatbot responses directly in stories. Here is a sample data:
You can mix training data in an end-to-end format with annotated intents and actions. When using the end-to-end approach, the intents and extracted entities identified by the NLU pipeline from user input are ignored, and policies can be predicted directly based on user text data.
Only Rule Policy and TED Policy can be trained end-to-end.
RulePolicy: When the user text data defined by the rules is the same as the user input during prediction, the RulePolicy will be used for matching
TEDPolicy: Pass user messages through additional neural networks to generate hidden representations of text. In order to obtain a more robust performance, it is necessary to provide enough stories training data to capture user text data based on various end-to-end dialogue turns.
You can add entity tags to user text data, so that it can be extracted by TEDPolicy. The syntax format is the same as that used for NLU training data. Here is an example:
You can also use the bot key to specify what you want the bot to say:
Here is an example of mixing the two end-to-end approaches above:
For TEDPolicy, end-to-end training requires more parameters and therefore more computing resources, the amount of which depends on how many end-to-end dialogue turns are included in the stories.
7. Rules for the Conversation Start detailed explanation and case study
Rules describe smaller dialogue segments that need to always follow the same dialogue path, and rules are used to train RulePolicy. Rules are defined under the rules key. A rule has a step key, which contains the same list of steps as stories, and can also contain conversation_started. To only use a rule at the beginning of a conversation, configure it like this:
8. Rules with Conditions detailed explanation and case analysis
You can use the condition key to specify that the rule can only be used when this condition is met, for example:
9. Skip Waiting for User Input at the End of a Rule
By default, when the rules complete the last step, they will wait for the user's next input. If you want to skip this state and transfer the prediction of the next action to another story or rule, you can use the following configuration (set wait_for_user_input: false ):
10. Detailed explanation and example analysis of ActionExecutionRejection mechanism under Form
When a form is active, execution of the form action is rejected if user input cannot fill the requested slot. At this time, the form will automatically throw an exception: ActionExecutionRejection. As part of your custom validation logic or slot mapping processing, you can also intentionally throw ActionExecutionRejection to terminate form action execution.
In some cases, when the user does not want to continue business processing, you can use a default action "action_deactivate_loop" to deactivate the form and reset the requested slot. The following is an example:
