This article continues to focus on the industrial-level business dialogue platform and framework Rasa, and conducts a detailed analysis of the various components of the Education Bot project NLU Pipeline in the education field of the Rasa dialogue robot project, the components used by Dialogue Policies, as well as multi-intent recognition and dialogue management.
1. Education Bot Project NLU Pipeline, Dialogue Policies, Multi-intent Recognition and Dialogue Management Decryption
- Analysis of the interaction between Agent, NLU Pipeline and Dialogue Policies from the perspective of Rasa Architecture
A dialogue system is mainly developed around the interaction between user intent (intent), dialogue state (state), and microservices (action). Intent needs to be identified through a series of components defined by NLU Pipeline, and then transferred to the Dialogue Policies component to predict what the next behavior of the dialogue robot is, and we usually need to resort to microservice actions when conducting dialogue business processing. During the dialog, the dialog state will be affected based on the intents and entities input by the user. For example, after calling the microservice, the state in the tracker can be updated by triggering an event.
2. Education Bot project NLU Pipeline component-by-component analysis
This is the pipeline defined in config, which contains various NLU components, usually there is a certain dependency between them:
As can be seen from the Rasa DAG architecture diagram, these components can have dependencies or run in parallel. Policies depend on the state or context to predict actions, and the state is subject to the intents and entities produced by NLU components such as DIETClassifier. influence.
WhitespaceTokenizer：
Used to extract tokens from space-separated strings. Usually used in English, token_pattern specifies the regular expression used to match tokens.
RegexFeaturizer：
When using RegexFeaturizer, instead of using regular expressions as a rule to classify intents, it only provides a feature for intent classifiers (such as DIETClassifier) to learn patterns for intent classification. All current intent classifiers utilize available regular expression features for intent classification. A regular expression's name is human-readable to help people remember its purpose, and the name does not need to match any intent or entity name.
Lookup tables can be used in conjunction with RegexFeaturizer, providing enough training data for the intent or entity you want to match so the model can learn to use regular expressions as a feature.
LexicalSyntacticFeaturizer：
Create language-level features based on user input to support entity extraction, and the output is sparse features. Since there is a default configuration, there is no need to specify additional configuration, you can also specify the configuration as needed, for example:
CountVectorsFeaturizer：
It is used to create features for intent classification and response selection according to the way of vocabulary count, that is, to create a representation of the bag-of-words corresponding to the user input message, intent, and response. Two CountVectorsFeaturizers based on the token level and based on the characater level are configured in the pipeline. The CountVectorsFeaturizer at the token level is configured with the OOV_token parameter to specify the keyword corresponding to the "invisible" vocabulary (vocabulary), if training The data contains "invisible" words, then when predicting:
- If the value of OOV_token is not None, these words will be replaced by the value specified by OOV_token
- If OOV_token=None, these words will be ignored
The character-based CountVectorsFeaturizer has two parameters related to n-grams, that is, the upper and lower boundaries of n-grams. Another parameter analyzer can be set to char or char_wb.
DIETClassifier：
For intent classification and entity extraction, the parameter ranking_length here is used to set how many top-ranked intents need to be displayed in the intent_ranking list. Here is an example:
EntitySynonymMapper：
EntitySynonymMapper will map the extracted entities to defined synonyms according to the training data. Here is an example:
ResponseSelector：
For common question and answer or small chat scenarios, the corresponding response selector is identified according to the retrieval intent, and each selector has two attributes: response and ranking. Finally, the response corresponding to the highest confidence is selected according to the confidence in ranking. Here is an example:
FallbackClassifier：
FallbackClassifier is usually used in the following two situations:
-The confidence predicted by the intent is lower than the set threshold value
- The difference between the top 2 confidences is lower than the set ambiguity_threshold
The following example shows that the FallbackClassifier recognizes the intent as nlu_fallback based on user input:
You can use the FallbackClassifier to trigger a fallback action, for example, configure the relevant rules in this project:
3. Education Bot project Dialogue Policies analysis component by component
Here is the configuration of policies:
RulePolicy：
When the prediction is lower than the threshold set by fallback, the corresponding fallback action will be triggered.
AugmentedMemoizationPolicy：
This policy has a "forgetting mechanism", which will match the content of the dialogue turn and the data in the stories under the premise of ignoring some content. If the match is successful, the predicted action will be returned directly, and the confidence is 1.0; if no matching result is found, Then the prediction result is None, and the confidence is 0.0. The parameter max_history here specifies how many dialogue turns in the stories training data to refer to when making predictions.
TEDPolicy：
This is a machine learning based policy that uses the TED model to make predictions. The parameter max_history here specifies how many dialogue turns in the stories training data need to be used for training. You can consider how to split into shorter turns combinations for training based on max_history, as well as the selection of positive and negative samples.
4. Working principle and process analysis of Multi-Intent Multi-Intent Classifier in Rasa
When the content entered by the user involves multiple business scenarios or has an associated relationship between the previous and previous content, the use of multiple intents can be considered, which can be roughly divided into two categories:
- Multiple intents are level, for example: check_balances+transfer_money,
- A hierarchical structure is formed between multiple intents, such as feedback+positive or feedback+negative
The following NLU example defines:
The user input information is: How much money do I have? I want to transfer some to savings.
In the case of multiple intents, it is necessary to add explicit examples of multiple intent combinations in the training data, otherwise it is difficult for the model to predict the intent combination. In order to prevent the occurrence of too many uncontrollable intent combinations, it is necessary to include only the necessary multi-intent combinations in the training data according to the actual user dialogue.
Whichever tokenizer is used, the following properties need to be defined:
intent_tokenization_flag
intent_split_symbol
Here is an example configuration:
5. Multi-Intent Multi-Intent Dialogue Management Processing Mechanism and Example Analysis in Rasa
There are two ways to use multi-intent in dialog management:
-Add rules or stories for multiple intents, such as adding a rule for each intent:
Then add a rule for the intent composition, and specify multiple actions execution sequences to correspond to this composition:
- Policy that allows machine learning to generalize to multi-intent scenarios by training based on single-intent stories training data. In this case, multi-hot encoding is used to extract intent features, which means using check_balances+ transfer_money extracts features instead of extracting features for each intent. Although TEDPolicy can also make predictions based on multi-intent without explicit multi-intent combined training data in stories, the best practice is to explicitly specify stories or rules to handle multi-intent situations.