Rasa对话机器人之HelpDesk (五)

一、HelpDesk智能对话机器人业务流程中的验证功能解析

在HelpDesk智能对话机器人运行业务流程时，需要对用户输入的信息进行验证，验证通过后才能继续调用后台微服务，如果验证不通过，对话机器人可以继续让用户提供正确的信息，直到所有需要收集的信息都通过验证后才提交form。下面通过Rasa提供的interactive模式演示对话机器人如何验证用户输入信息。当用户查询已经创建的incident的状态时，输入以下信息：

NLU模型正确识别用户意图，继续执行：

继续按照提示运行这个form：

这时对话机器人要求用户提供email信息，输入123：

NLU模型把用户意图识别为out_of_scope，并且提示无法提取email，这里的NLU模型就是指NLU pipeline配置文件中使用的duckling，输入信息123显然不符合email格式，所以duckling无法提取email。

如果输入以下信息，即使不是一个有效的email地址：

这时看起来模型能够提取到这个email信息，继续执行：

Slot “email”已经填充了刚才输入的值，查看action server的输出日志：

可以看到Rasa action server收到了Rasa server发过来的验证请求，然后成功执行了验证微服务validate_incident_status_form，我们在domain中可以看到配置了以下两个验证action:

前面提到了HelpDesk对话机器人的主要业务流程包括根据用户输入创建incident和查询已经创建的incident的状态，在这两个流程中会分别使用open_incident_form和incident_status_form来收集用户信息，所以针对每个form都会定义一个validate action来验证每个form需要收集的信息是否符合要求。

二、HelpDesk对话机器人业务流程验证微服务代码解析

1. 创建incident验证微服务

下面是微服务类，继承自Rasa SDK的form验证框架类FormValidationAction

在name方法中需要返回在domain配置中定义的action name:

下面是form的定义：

在验证微服务中可以根据上面定义中需要收集的slots信息提供相应的验证方法，在这里只提供了两个重要的slot信息的验证方法。

这个方法会调用内部方法_validate_email执行具体的验证逻辑：

首先对传入的参数值进行检查：

根据用户提供的email从第三方incident管理系统中获取当前用户的身份id：

-如果caller_id有效则同时返回caller_id和email

-如果不能返回单个的caller_id，则说明email无效，这时需要把slot的值设为None

-如果出现报错信息，也需要把slot的值设为None：

下面的方法验证priority是否有效：

如果priority有效则返回值，否则需要把slot的值设为None，并调用模板方法utter_no_priority输出信息给用户：

 2.  查询incident状态验证微服务

下面是微服务类，继承自Rasa SDK的form验证框架类FormValidationAction，按照命名规范，这个微服务类的名称前面应该加上”Validate”：

在name方法中需要返回在domain配置中定义的action name:

下面是form的定义：

这个form只需要收集email信息，所以验证方法也只有一个：

实际上就是调用同一个内部方法_validate_email来实现email的验证逻辑。