对话机器人RASA结构和相关知识点
本文主要是读了一遍rasa文档https://rasa.com/docs/rasa/installation/，总结的。
目录
1 Rasa 结构 1
2 NLU Data 2
2.1 Training Examples 2
2.2 Entities实体 2
2.2.1 Pre-trained Entity Extractors 2
2.3 Synonyms 同义词 3
2.4 Stories 3
2.4.1 Step 3
2.4.2 Action 4
2.4.3 Slots 4
2.4.4 Checkpoints 4
2.4.5 Or 4
2.5 Rules 5
2.6 Forms 5
2.7 Test stories 5
3 Config.yml 5
3.1 Policies 5
3.1.1 优先级 5
3.1.2 TED Policy 6
3.1.3 UnexpecTED Intent Policy 6
3.1.4 MemoizationPolicy 7
3.1.5 Augmented Memoization Policy 7
3.1.6 Rule-based Policies 7
4 Tracker store 7
4.1 InMemoryTrackerStore 7
4.2 SQLTrackerStore 7
4.3 RedisTrackerStore 8
4.4 MongoTrackerStore 8
4.5 DynamoTrackerStore 8
4.6 custom tracker store 8
5 Event Brokers 9
6 Conversation-Driven Development (CDD) 9
1 Rasa 结构
Rasa两个最主要单元是 Natural Language Understanding (NLU) 和对话管理，分别对应下图的 NLU Pipeline、Dialogue Policies。NLU 可以处理意图识别、实体抽取、响应检索。对话管理决定下一个action。
- Action server：
当对话助手预测一个自定义动作（ custom action）时， Rasa server会发送一个post请求给action server，请求内容为json格式，包括预测的action、conversation ID、tracker 信息、 domain信息。
当action server完成自定义动作（ custom action）的运行后，会回复一个包含response和event的json。
然后Rasa server将response发送给用户，同时添加event到conversation tracker.
- Lock store：用以支持多个rasa 服务同时并行运行。
- Tracker Store：保存会话内容。
2 NLU Data
NLU (Natural Language Understanding)是Rasa的一部分，其进行意图识别、实体提取、响应检索。
收集真实的数据
合成的数据不是太靠谱。
避免意图混淆
当不同的意图包括相同顺序的单词，可能导致意图识别不清楚。
2.1 Training Examples
2.2 Entities实体
[]{“entity”: “”, “role”: “”, “group”: “”, “value”: “”}
2.2.1 Pre-trained Entity Extractors
包括SpacyEntityExtractor and DucklingEntityExtractor.
2.3 Synonyms 同义词
2.4 Stories
Storie和rules是用户和对话助手之间会话的表示。Stories用来训练一个机器学习模型来确定对话模式，进而应用到非可见的对话路径。Rules描述了较少部分的对话，该对话总是采用相同的路径，采用rulepolicy进行训练。
对话路径分为happ 路径和unhappy 路径。 Happy 路径指用户跟随我们期望的对话流。但用户经常偏离happy 路径。
2.4.1 Step
Step包括如下：
• A user message, represented by intent and entities. 可以加入实体，利用NLU。
• An or statement, which includes two or more user messages under it.
• A bot action.
• A form.
• A slot was set event.
• A checkpoint, which connects the story to another story.
2.4.2 Action
有两种类型的action。
1） Responses:以“utter_”开头。发送一个指定的消息给用户。
2） Custom actions：以”action_”开头。可以运行任意代码、发送任意数量消息。
2.4.3 Slots
Slot表现为机器助手的记忆。
2.4.4 Checkpoints
**用于连接stories。**Checkpoints可以用于storie开始，也可以用于stories结尾。
Checkpoints可以帮助简化训练数据、减少冗余，但不要过度使用。使用太多Checkpoints会很快的使stories较难理解。
如果Checkpoints用于storie开始，可以通过slot附加条件，如下：
2.4.5 Or
带有Or的stories在训练时会被转换成多个独立的stories.
Or也不建议过度使用。
2.5 Rules
规则类似stories。增加了conversation_started、conditions 。
2.6 Forms
收集用户信息。
2.7 Test stories
进行测试。
3 Config.yml
3.1 Policies
3.1.1 优先级
智能助手会预测10个动作，按可信度取最高的。如果最高两个的可信度相同，那么按下面默认优先级：
• 6 - RulePolicy
• 3 - MemoizationPolicy or AugmentedMemoizationPolicy
• 2 - UnexpecTEDIntentPolicy
• 1 - TEDPolicy
3.1.2 TED Policy
Transformer Embedding Dialogue (TED) Policy. 用来训练找到下一个合适的action。
TED policy架构包含如下步骤：
- 连接输入特征，包括用户输入或者经过user transformer encoder加工后的、上一步系统action或者机器响应（经过 bot transformer encoder处理的）、slot和form。
- 上面的输入特征转换成embedding，输入到dialogue transformer encoder。
- 将dialogue transformer encoder输出应用于dense层，获得dialogue embedding。
- 应用dense层生成系统action的embedding。
- 计算系统action embedding和dialogue embedding的相似性。
- 将user transformer encoder的输出和dialogue transformer encoder的输出进行连接。
- 应用CRF算法预测每个用户输入的实体。
微调：
参数可以选择epochs、max_history(默认none，表示看全部)、number_of_transformer_layers、transformer_size、connection_density、split_entities_by_comma（实体是否用逗号分隔）、constrain_similarities、model_confidence（softmax、linear_norm）。
3.1.3 UnexpecTED Intent Policy
UnexpecTEDIntentPolicy 和TED policy有相同的架构。
UnexpecTEDIntentPolicy 识别客户意图，如果NLU预测的客户意图和UnexpecTEDIntentPolicy 不一致， 触发action_unlikely_intent 。
UnexpecTEDIntentPolicy 更新是TED policy的一个助手。
为了减少错误预警，UnexpecTEDIntentPolicy 在预测时有下面两个机制：
1） UnexpecTEDIntentPolicy 的优先级应比所有的基于rule的policy低一些，因为对于UnexpecTEDIntentPolicy 和TED policy新颖的，但rule可能存在。
2） 如果最后的意图在任何训练stories中不存在（可能存在rule中），UnexpecTEDIntentPolicy 不要触发action_unlikely_intent 。
参数：tolerance， 在0与1之间。帮助调节触发action_unlikely_intent的阈值分数。
当tolerance=0，都会触发action_unlikely_intent的；
当tolerance=1，即100%的负样本高于阈值，意味着阈值分数会很低，导致不会触发action_unlikely_intent。
UnexpecTEDIntentPolicy 仅基于stories训练，不是rules。
3.1.4 MemoizationPolicy
MemoizationPolicy 会记忆训练数据的stories，将当前对话和stories匹配。返回的自信度要么是0，要么是1，不会是小数。
3.1.5 Augmented Memoization Policy
增加了忘记机制，忘掉一定的对话记录。
3.1.6 Rule-based Policies
没有maxhistory 参数，考虑rule的全部长度。
4 Tracker store
4.1 InMemoryTrackerStore
会话存档保存在内存中，如果重启，会话记录会丢失。
4.2 SQLTrackerStore
会话保存在sql支持的数据库。在endpoints.yml中配置。如下
支持如下数据库：
• PostgreSQL
• Oracle > 11.0
• SQLite
4.3 RedisTrackerStore
聊天会话保存到redis。
4.4 MongoTrackerStore
聊天会话保存到mongodb.
4.5 DynamoTrackerStore
聊天会话保存到DynamoDB. Amazon的一个NoSQL数据库。
4.6 custom tracker store
自定义会话存档
5 Event Brokers
event broker允许我们链接到运行的对话助手，以处理来自于对话的数据。
当Tracke每次更新起状态时，所有事件会以字典形式的数据（如下）传输到broker。
{
“sender_id”: “default”,
“timestamp”: 1528402837.617099,
“event”: “bot”,
“text”: “what your bot said”,
“data”: “some data about e.g. attachments”
“metadata” {
“a key”: “a value”,
}
}
Broker支持rabbitmq、kafka、sql数据库、文件、自定义等。
6 Conversation-Driven Development (CDD)
CDD指聆听用户的声音，改善AI助手。
CDD includes the following actions:
• Share your assistant with users as soon as possible
• Review conversations on a regular basis
• Annotate messages and use them as NLU training data
• Test that your assistant always behaves as you expect
• Track when your assistant fails and measure its performance over time
• Fix how your assistant handles unsuccessful conversations