Gavin老师Transformer直播课感悟 - Rasa项目实战之银行金融Financial Bot智能业务对话机器人系统启动、语言理解、对话决策、状态管理、微服务调用全生命周期流程(五十一)

     本文继续围绕工业级业务对话平台和框架Rasa，通过Debugging模式对Rasa项目实战之银行金融Financial Bot智能业务对话机器人的系统启动、语言理解、对话决策、状态管理、微服务调用等全生命周期流程进行解析。

一、Rasa项目实战之银行金融Financial Bot智能业务对话机器人系统启动、语言理解、对话决策、状态管理、微服务调用全生命周期流程解析

1. 使用Rasa shell --debug模式启动银行金融Financial Bot分析

运行命令rasa shell –debug启动调试模式：

这里使用了默认的credentials.yml，可以使用这个文件定义一些连接访问时身份验证信息：

显示当前Rasa server连接的channel为”cmdline”，即命令行模式：

下面是Rasa官方文档提到的可以支持的channels：

Your Own Website

Facebook Messenger

Slack

Telegram

Twilio

Microsoft Bot Framework

Cisco Webex Teams

RocketChat

Mattermost

Google Hangouts Chat

Custom Connectors

     

      Rasa server是基于Sanic（https://sanic.readthedocs.io/en/stable/）来构建的，你可以配置跨域访问：

     对web server routes进行检查：

启动标识信息：

从Rasa 3.x开始，在domain配置中定义slots时一般都会使用mapping机制，并且移除了slot的自动填充机制，这是因为在之前的版本里存在自动填充造成slot状态不正确的问题：

在这里使用默认的tracker store和lock store，当然也可以使用Redis等来存储状态：

这是Rasa官网（https://rasa.com/docs/rasa/img/architecture.png）提供的一幅架构图：

Agent就是Rasa server，其中Tracker Store保存了对话状态，通过操作它就可以操作对话机器人。Lock Store跟对话用户的身份ID管理有关，譬如对话机器人有100万用户连接时，需要使用ID来区分不同的用户：

初始化语言生成器：

加载训练好的模型：

运行使用的tokenizer和featurizers：

这些都定义在config文件的pipeline里：

加载DIETClassifier模型，并设置finetune_mode为false，这是因为当前是inference模式：

运行FallbackClassifier和DucklingEntityExtractor组件以及依赖的NLP库SpacyNLP：

加载domain.yml文件：

加载各个policies组件：

加载Public Ensemble组件来对各个policies的预测结果进行处理：

标识Rasa server已经启动完成并处于运行状态：

 2.  从Rasa 3.X的Graph Architecture的视角分析Financial Bot启动步骤内幕

     从DAG图中可以看到，在对话机器人启动时，会从model storage中加载每个组件，也就是对组件进行实例化。组件之间会存在依赖关系，Rasa server启动后会把pipeline定义里的每个组件映射为DAG图中的一个节点，从而建立graph运行上下文环境。

 3.  用户输入Message在NLU处理中的各大组件process方法解析

 输入信息：

创建对话ID并运行action “action_session_start”来启动一个对话：

这是当前tracker中的slots的信息：

从下面信息可以看到在组件运行时都是调用各个组件的process方法：

输出识别到的intent和提取的entities，这里为空：

调用默认验证action来验证提取的slots信息：

调用policy部分进行预测：

 4.  基于State而进行的并行化policies预测过程解密

下面显示当前tracker的状态：

从下面的信息可以看出：

首先会使用MemozationPolicy进行预测，如果没有找到匹配的next action，那么会检查是否有可用的rule，这里找到了预先定义好的rule，然后使用RulePolicy预测对应的action 是“utter_greet”，同时也会使用TEDPolicy来基于用户输入的intent来进行预测：

因为根据RulePolicy预测出next action是”utter_greet”时所获得的confidence为1.00，超过了TEDPolicy的预测confidence，所以最后Public Ensemble选择的预测结果就是RulePolicy的预测结果：

执行action “utter_greet”：

 5.  不同阶段State的触发机制及具体内容剖析

    从下面信息可以看出，当对话机器人完成1个action之后，状态会标记1次，所以有state 1，state 2这样的信息：

接下来会运行action “utter_help”，可以看到产生了新的state 3信息，这样就实现了对话状态的精细化管理：

这是对话机器人针对用户输入而产生的输出信息：

 6.  使用Financial Bot进行transfer money操作触发form循环分析

输入信息：

输出信息：

通过预测需要执行action “transfer_money_form”来激活form，目的是收集转账需要的信息：

这是在domain里定义的form：

输入确认信息：

输出信息：

这个slot已经填充了值：

对话状态跟踪信息：

 7.  Rasa Server中的action及Rasa微服务中的action区别和联系源码剖析

     下面是Rasa server中的action的run方法，用户跟Rasa server进行交互需要使用channel，所以设置了这个参数，另外也使用了nlg这个参数来指定由哪个generator来生成发送给用户的信息：

下面是用于响应用户的action类，它继承自Rasa server的Action类：

这是具体实现的run方法：

Rasa SDK的action是指微服务的实现，首先需要导入SDK中的Action：

方法run中的参数与前面提到的Rasa server中的Action的run方法参数不一样，这里需要使用dispatcher这个参数来把微服务的处理结果返回给Rasa server：

 8.  Slots状态分析和状态管理

首先分析sqlite数据库表的内容，可以从这里取转账接收人信息：

但是查看微服务代码，发现这里已经定义了关于转账接收人的信息：

输入转账接收人信息：

这时可以看到slot “person”的值已经填充：

Requested_slot：

输入信息：

Slot已经填充：

输入确认信息：

转账完成后slots已经填充：

从rules中可以看到当form信息收集完成后会执行action “action_transfer_money”：

对应的action代码如下：

在方法run中可以看到：

首先对slots进行初始化：

-当转账完成时，会从tracker中获取slot “amount_transferred”的值，然后在这个值的基础上累加刚才转账的金额后，填充到这个slot里

-当转账取消后，会通过使用上面初始化的slots列表来创建SlotSet事件，从而把所有转账使用的slots清空