在上篇文章中介绍了在转账交易时，业务对话机器人提示用户首先需要输入转账接收人信息，在用户输入信息后，Rasa框架会调用运行于action server的对应的form验证微服务类来对输入信息进行验证，验证通过后才能进入转账流程的下一步，那么假设用户多次输入信息均验证失败，这时如何设计对话系统来更优雅地处理这种情况呢？在本项目中，对话机器人会根据验证失败次数达到设定条件后，调用预定义的方法来响应用户，下面的示例演示了这种效果。
上面演示了转账过程，用户输入信息表示要执行转账操作，之后对话机器人提示用户需要输入转账接收人，用户第1次输入“Bob”，对话机器人提示不在该用户已知的转账接收人列表中，这时用户继续尝试输入另外一个接收人，对话机器人仍然提示在列表中没有找到这个人，然后就输出了当前用户的已知可转账人员名单，意味着只要用户按照已知转账接收人信息选择一个输入就可以通过验证了。如果没有设计这样的机制，那么验证重复失败后，用户不得不尝试使用其它的方式来先获取自己的转账接收人信息，或者不得不像转账给新的接收人那样还得输入对方的账号信息等，这无疑会降低用户在与业务对话机器人交互时的体验感，所以在设计一个符合实际使用场景的智能业务对话机器人时，这些都是需要考虑的重要因素。
一、Rasa项目实战之银行金融Financial Bot智能业务对话机器人微服务解析与调试
- Financial Bot转账交易验证微服务多次验证失败场景解析与调试
首先运行rasa interactive命令进入交互式模式：
运行rasa run actions –debug以调试模式启动action server，即运行注册的微服务：
输入信息：May I transfer money? 询问对话机器人是否可进行转账：
这时对话机器人正确识别了用户意图，确认继续执行：
可以看到slot “currency”预设为$，其它的slots目前为空，运行提示的transfer_money_form进入收集信息状态：
当前需要收集信息的slot为“AA_CONTINUE_FORM”，继续执行：
如果选择1，则会填充AA_CONTINUE_FORM的值为yes：
继续执行form：
这时注意观察输出了另外两个slots：
-repeated_validation_failures，值为0，这个slot的作用是累计验证slot “PERSON”失败的次数，
-PERSON，这个是转账接收人，所以接下来就是对话机器人向用户收集这个信息了
根据提示输入Bob，确认继续执行：
这时检查action server的输出日志：
虽然完成了验证微服务执行，但是并不知道是否验证通过。所以切换到交互式对话，可以看到对话机器人给出了回复：
Sorry, Bob is not in your list of known recipients.
说明验证没有通过，并且提示用户需要再次输入接收人信息。需要注意的是这时slot “repeated_validation_failures”的值已经由0变为了1。
这次用户选择输入另一个接收人Mike：
继续执行：
再次运行form，这次验证微服务就会对刚才输入的slot 值“Mike”进行验证了。
这时对话机器人给出回复：
Sorry, Mike is not in your list of known recipients.
接下来并没有像第一次那样再次要求用户输入接收人信息，而是直接给出了该用户已知的转账接收人列表：
These are your known recpients to whom you can send money:
- Kyle Gardner
- Katy Parrow
- Percy Donald
- Evan Oslo
再次观察slot “repeated_validation_failures”的值，已经重置为0。
2. Financial Bot验证微服务多次验证失败处理机制解密
首先来看这个form验证微服务类：
除了正常的验证slot “PERSON”的方法validate_PERSON之外，还定义了方法explain_PERSON，在这个方法中定义了连续多次验证失败后，对话机器人应该操作的逻辑。在转账这个环节中，如果用户连续输入转账接收人信息都被告知验证失败后，很有可能期望对话机器人能够自动提供已知转账接收人列表来方便用户快速进行选择。下面的代码演示了通过当前用户的身份ID（即在Rasa 对话跟踪器tracker中保存的sender_id）来查询该用户的已知转账接收人列表。
前面提到使用了slot “repeated_validation_failures”来累计验证失败次数，form验证类是继承自这个自定义的CustomFormValidationAction的，在这个类中加入了处理连续验证失败的机制。
首先需要定义以下两个slots来存储处理连续失败时需要的信息：
这两个slots必须定义在domain中：
读取配置文件：
在这个配置文件中定义了参数max_validation_failures，这里显示当失败累计次数达到2时就会触发自动处理机制：
下面这个方法使用了Python的coroutine机制，在这个方法中会根据验证微服务类在验证slot “PERSON”失败后更新slot “repeated_validation_failures”的值来判断是否需要启动连续验证失败处理机制。
下面这段代码首先从tracker中获取slot “repeated_validation_failures”的值，如果非零，则取整数值，否则设为0：
设置变量validation_failed为True：
循环遍历验证微服务执行后返回的events，注意验证失败后是不会设置slot的值的，所以下面的逻辑是判断如果当前事件类型为slot，并且事件名称是当前正在收集信息的slot的名称而且有值，则表示验证成功，这时会把上述变量设为False：
接下来更新slot “repeated_validation_failures”的值：
如果当前slot “repeated_validation_failures”的值大于等于在配置中所设定的阈值，那么就会触发explain_{slot}方法的调用，在这里如果当前请求的slot是PERSON，那么就会调用相应的explain_PERSON方法：
Rasa 3.x 源码高手之路：系统架构、内核算法、源码实现详解：
Rasa 3.x 源码高手之路：基于Transformer的对话机器人RasaPolice：
星空NLP对话机器人论文班：NLP领域10篇最高质量的对话机器人经典论文解密：
Rasa 3.X 智能对话机器人案例开发硬核实战高手之路 （7大项目Expert版本）：
Advanced Python硬核实力高手实战之路：架构、算法、源码、案例（81讲）：
NLP on Transformers 高手之路137课Pro版：
446
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
