Gavin老师Transformer直播课感悟 - Rasa项目实战之电商零售Customer Service智能业务对话机器人系统行为分析及项目总结(四十九)

    本文继续围绕工业级业务对话平台和框架Rasa，对Rasa项目实战之电商零售Customer Service智能业务对话机器人系统行为进行分析并对项目进行总结。

一、Rasa项目实战之电商零售Customer Service智能业务对话机器人系统行为分析及项目总结

1. 电商零售Customer Service的config内容逐行分析

     Recipe是Rasa3.x提出的概念，其核心是根据pipeline和policies定义了一个对话机器人由哪些过程及组件来构成，相当于一个“配方”，这样的概念也是为未来运行多个对话机器人打下基础：

每个组件都需要使用recipe进行注册，譬如WhitespaceTokenizer的注册代码如下：

在上面的配置里可以看到使用的语言是en，当然Rasa也提供了基于中文的版本（https://github.com/crownpku/Rasa_NLU_Chi）。在实际使用中文时，可以使用官方自带的支持中文的tokenizer：

Rasa在理论上可以支持任意的语言。

关于pipeline部分：

RegexFeaturizer：这是loop up相关正则表达式操作的featurizer，用途是使用正则表达式把用户信息转换为一个向量表示，输出为sparse_features和tokens.pattern

LexicalSyntacticFeaturizer：针对用户消息创建词汇和句法相关的features来支持entity提取，输出为sparse_features

CountVectorFeaturizer：这里有两个，一个用于tokenizer级别的（one house encoding），另一个用于character级别的（n-gram）

使用DIETClassifier对用户输入意图进行预测并设置训练时使用的epochs：

如果训练数据不是很充分的情况下，可以使用同义词技术把不同表达形式转换为同一种形式：

对于常见问答faq和闲聊内容采用ResponseSelector通过计算两个向量相似度的高低来进行问题和response的匹配：

设定触发fallback处理的threshold，当一个intent预测得到的confidence低于这个threshold时就会触发fallback，另外一种情况是，排名前2位的预测结果的confidences之间的差值如果小于ambiguity_threshold，也会触发fallback处理：

使用DucklingEntityExtractor来获取entities的值：

DucklingEntityExtractor是一个开源的entity extractor（https://github.com/facebook/duckling），它提供了很多类型的entities的提取，以下是一些样例，由于它是预训练好的模型，所以在使用时不需要太多的训练数据，你可以直接把输入信息传入它来提取相关的entities信息：

关于policies部分：

MemoizationPolicy：如果对话turns的内容能够和stories.yml里的训练数据进行匹配，那么就会使用这种policy来预测action

TEDPolicy：基于机器学习模型TED进行预测的policy

RulePolicy：如果逻辑规则是固定的，就可以使用这种policy进行预测

core_fallback_threshold：当一个policy的预测confidence低于这个threshold时，就会触发fallback action

 2.  Rasa 3.x Graph Architecture剖析

    从上面的Rasa DAG图可以看到，Rasa3.x统一了NLU和policies，无论是NLU部分还是policies都是一个个的组件而已（graph components）。在这些组件之间存在依赖关系，从图中可以看到，CountVectorFeaturizer1和CountVectorFeaturizer2都依赖于组件Tokenizer，而DIETClassifier依赖于CountVectorFeaturizer1和CountVectorFeaturizer2，CountVectorFeaturizer1，CountVectorFeaturizer2和RegexFeaturizer在训练和加载时可以同时进行处理，这可以极大地加快处理速度。

DIETClassifier输出的是intents和entities，DAG图中的各种policies在进行预测时是并行操作的方式，最终使用Policy Ensemble来决定由哪一个policy来做出预测action。

 3.  项目实战之电商零售Customer Service的Domain内容逐行分析

    定义了session的配置，如session超时时间，以及是否在启动一个新的session时自动带入前一个session已有的slots：

关于intents定义部分，定义了业务流程需要使用的intents，faq和chitchat的intents，以及超出处理范围的out_of_scope intent等：

在nlu.yml可以看到相关intents的训练数据，当在生产环境中运行时，理论上每个intent需要有100-200条相关的训练数据：

譬如intent “product_stock”的数据：                                               

关于常见问答faq各个路径(intent+路径名)对应的训练数据：

关于entities定义部分：

关于forms的定义部分：

关于actions定义部分：

关于slot mapping中的type “custom”，表示可以使用任意自定义的验证action来控制slot “verified_email”的填充：

关于responses定义部分，这些都是基于模板的actions：

 4.  项目实战之电商零售Customer Service的rules内容逐行分析

     关于rules的定义，譬如常见问答和闲聊内容等，一般情况下都会使用rules，对于faq里的问题来说，都是对应intent faq下面的路径，然后通过ResponseSelector来选择与当前用户问题匹配的response。另外关于out_of_scope这个rule的定义，使用了or的条件，即满足任意一个intent都会触发设置的action “utter_default”：

     关于form的激活或者提交一般会使用rule，譬如下面这个rule的定义，当识别到intent时会触发form “order_status_form”，然后会进入active loop的状态，接下来提交form时需要设定conditions来指定当前运行的form，这是为了防止有多个form时造成状态信息的混乱。在steps中可以看到会判断active loop是否是null，在实践中最好是通过检查requested_slot是否为空来判断是否form已经收集完信息，从而可以提交form。另外也要注意下面定义中关于条件”slot_was_set”的使用，如果是False则接下来会从form “order_status_form”切换到另一个form “survey_form”以继续收集用户的反馈信息：

触发action来提交survey_form：

 5.  项目实战之电商零售Customer Service的数据操作代码逐行分析

  导入sqlite3，获取数据库连接，并通过连接取得cursor：

通过cursor执行SQL语句来创建数据库中的表orders：

定义数据集合，然后通过cursor来执行插入数据的SQL语句：

通过cursor执行SQL语句来创建数据库中的表inventory：

定义数据集合：

通过cursor来执行插入数据的SQL语句：

最后提交数据库操作并关闭连接：

 6.  chitchat及faq在Rasa Interactive下的测试及行为分析

    关于chitchat和faq，会使用rules.yml文件里定义的rules来预测并使用在domain.yml文件里定义的responses，

譬如输入信息：

这时会运行模板action “utter_chitchat”，可以看到输出了信息：unfortunately…：

继续输入信息，识别到intent为out_of_scope：

这时会运行模板action “utter_default”，可以看到输出了信息：um, what did you…

输入信息：

这时运行action “utter_faq”：

    下面是关于buttons的定义，需要注意这里的payload的值表示用户输入的信息（通过选择对应的选项来发送这个信息，通过对这个信息进行NLU处理来识别intent，如果在payload的值前面加上符号”/”，则表示直接发送intent）：

输入信息hi之后会提供以下的选项供用户选择：

可以直接选择选项：

 7.  项目实战之电商零售Customer Service项目总结

      这个项目提供了关于电商业务流程的一些基本的功能，譬如产品库存查询，订单状态跟踪及修改，用户满意度调查等等，可以基于它扩展更多的功能点来满足实际业务需求，从技术实现看都是类似的，只不过是业务数据和执行的逻辑不一样。基于这个项目，理论上可以做出基于任意业务的对话机器人，当然这背后还涉及到如何与第三方API及Rasa微服务进行整合的问题。