本文继续围绕工业级业务对话平台和框架Rasa,对Rasa项目实战之Helpdesk Assistant中Domain、Action逐行解析及Rasa Interactive运行过程进行剖析。
一、Rasa项目实战之Helpdesk Assistant中Domain、Action逐行解析及Rasa Interactive运行过程剖析
- 对Helpdesk Assistant中的Domain内容逐行解析
关于session配置:
-session_expiration_time:如果设置为0.0,表示永远不会超时
-carry_over_slots_to_new_session:当设置为True时,表示如果session超时而启动一个新的session时,会把之前session已有的slots带入到新的session中
关于intent部分的定义:
除了常规打招呼使用的intents之外,还定义了业务相关的intents如password_reset,inform,help,problem_email,open_incident,incident_status等。这里需要注意的是在nlu.yml中inform和problem_email这两个intents各自使用的训练数据中都包含了email相关内容,这就会很容易造成这两个intents预测获得的confidences的区分度太低的问题。
-关于inform使用的训练数据如下:
-关于problem_email使用的训练数据如下:
针对区分度太低造成fallback的情况,在config.yml文件里有如下配置:
关于entities定义:
关于slots定义:
如confirm,定义了type,mappings等内容,在mappings中指定了conditions,即当form “open_incident_form”被激活时才会把slot “confirm”放入requested_slot中,从而让用户提供输入。当满足conditions时:
-如果当前从用户输入识别到的intent为affirm,则设置slot “confirm”的值为true
-如果当前从用户输入识别到的intent为deny,则设置slot “confirm”的值为false
使用conditions设置的一个重要原因在于,如果有很多不同form或者逻辑需要操作,那么就会使用很多slots,在这些slots中可能存在一个slot在多个地方使用的情况或者存在同样名称的slots的情况,这时就必须说明这个slot在什么条件下需要被填充。
关于下面这个slot,type设置为custom,表示可以使用任意自定义的方式来控制这个slot的填充:
关于email这个slot,同样也设置了conditions来控制在什么条件下才能通过从用户输入提取的entity的值来填充这个slot:
关于slot “incident_title”,在mappings里的type设置为”from_trigger_intent”,这是slot填充值的一种方式,当输入信息Problem resetting password与key “value”中的定义匹配时,会触发intent “password_reset”,然后再判断是否满足conditions定义的条件,如果满足就会填充slot “incident_title”。另外需要注意的是,这里也定义了通过”from_text”的方式来填充slot的方式,在”not_intent”里的这些intent不会触发这个slot “incident_title”的填充。
关于slot “handoff_to”,这通常用于当对话机器人进入fallback状态而无法继续处理时,需要移交人工处理或者其它智能化程度更高的对话机器人来处理等情况。
关于responses部分,定义了模板化的actions,其中比较特殊的有”utter_ask_priority”,它输出的是一组按钮选项,可以让用户进行选择,这里的/inform表示直接触发intent “inform”而不会经过NLU处理:
下面是在response中使用placeholder的例子:
在下面的微服务代码中会操作这个placeholder:
-当对priority的值验证后发现和预定义的值不匹配时,则调用模板action “utter_no_priority”,并把placeholder替换为None来输出信息:
在下面的response中也使用了placeholder “{email}”,email是从slot中提取的,然后输出两个按钮并直接发送对应的intent:
关于form的定义部分,这里定义了两个form:
关于actions的定义:
2. Helpdesk Assistant中的Action微服务代码逐行解密
关于第三方微服务中心SnowService,在这个自定义action里配置使用local模式:
这是自定义的action,用来向用户请求email信息:
方法run首先从tracker中通过”previous_email”获取email:
-如果找到,则询问用户是否使用这个email
-如果没有找到,则调用模板action “utter_ask_email”要求用户提供email
下面是验证email的内部方法,它会被其它validation方法所调用:
如果是local模式,则直接返回tracker中取得的email,否则会通过API调用snow服务中心获取caller_id,并根据caller_id的值设置相应的email:
下面这个类用于验证创建incident时需要使用的信息,如email和priority:
下面这个类用于创建一个incident:
-首先从tracker中获取创建incident需要的信息,如priority,email,problem_description等
-如果用户没有confirm,那么取消incident的创建并调用模板action输出信息给用户
-如果需要创建,对于local模式,则构建incident创建信息
这个action是用于通过调用第三方微服务来检查incident的状态。在run方法中首先从tracker中获取当前session中保存的email address,由于没有远程连接第三方微服务,所以定义了incident_states来模拟查询。
如果是local mode,则执行:
如果是远程调用,则执行:
使用dispatcher输出对话机器人的response给对应的channel:
方法run返回时需要重设所有的slots状态,这是因为在调用action “action_check_incident_status”之后对话就结束了,所以需要返回到对话初始状态:
然后调用下面这个类的方法apply_to来重设所有的slots:
3. 通过Rasa Interactive纠正Helpdesk Assistant中的NLU错误全程演示
输入email信息后得到以下输出信息,可以看到email的值已经被正确识别,但是提示intent为”nlu_fallback”:
由于intent不是我们所预期的,所以在这里输入No,之后对话机器人给出了下面的intents list供我们手动选择,分析这些intents可以看出:
-intents “problem_email”和”inform”的confidence都低于设定的fallback的threshold值0.70
-intents “problem_email”和”inform”的confidences的差值为0.04,小于区分度threshold值0.1
这时我们期望的intent是”inform”,所以需要选择这个intent:
4. 通过Rasa Interactive纠正Helpdesk Assistant中的Prediction错误全程演示
运行form “incident_status_form”之后,可以看到requested_slot为”email”,但是从当前slots设置信息看,slot “previous_email”并没有填充email,对话机器人提示是否运行action “action_default_fallback”:
由于这不是我们期望的action,所以输入No,得到的输出信息如下:
实际上需要执行的action是”action_check_incident_status”,选择执行这个action后输出如下:
然后继续执行action “incident_status_form”:
这时根据提示输入email信息,可以看到intent为”inform”,说明已经修正过来了:
继续执行action “incident_status_form”,可以看到slot “email”已经填充了值:
继续执行action,得到以下信息:
然后导出训练数据,重新进入interactive模式,当运行form “open_incident_form”时,可以看到slots正确填充了值,由此可见,对于开发对话机器人来说,状态的维护是一个核心问题:
输入Yes触发intent affirm来创建一个incident:
需要注意的是上面slot “email”的值被设为true,这显然是不对的,这是一个bug,但是继续操作后可以看到通过微服务可以正确设置slot “email”的值: