对话管理

对话管理不仅要能够完成对话，还要“漂亮”的完成对话。这个漂亮一方面让提取器尽量提对，没有太多错误。

另一方面对话要多种多样，在完成功能的基础上把话说的漂亮。所以应该在对话MDP模型里应该有对对话多样性的度量。

对话多样性1.同一个意思应该有多种表述2.不应该在同一个问题上“纠结”太长时间。

因为马氏决策过程只根据当前的系统对话状态去决策，过去的状态并不考虑进来。

而对话系统是需要一定的memory,最直观的解释就是人与人在对话过程中当前说的话可能会考虑到上几轮的对话内容。

如果仍然在马氏决策过程的这个框架内，应该如何改进MDP模型让它具有一定的memory。

目前的想法是在state里添加特征，因为state表征的就是多轮对话后造成的影响到现在是一个什么样子的状态。

那么解决方法就应该是这样： 1.同一个意思应该有多种表述：生成许多个对话模板，随机选择。

2.不应该在同一个问题上，“纠结”太长时间： 在state里添加上一次对话的动作，这样当同一个动作出现2次，就暂时不让它再出现。 因为重复询问主要集中在“re_requeset”这个动作上，所以没必要把所有的上一次动作都加入进去。

只需记录上一次动作是不是re_request动作即可。

另一种方法也可以通过增加槽的activity来实现：1 request_activity 2 confirm_activiyt 3.re_request_activity

而不用大范围的修改上层MDP的逻辑

StateSlot_stateIf_Activityfetch_infouser_attitudehistory_info==fetch_infouser_action0000anyanyrequest1001anyanyconfirm2010anyanyRe_request3011anyanyconfirm4100anyanyconfirm5101any==done6101any!=Re_confirm7120disanyDis_request8120agranydone9121dis!=Re_confirm10121dis==Done11121agr!=re_confirm12121agr==done132anyanyanyanyok

只需要在底层添加两个状态，上层mdp的逻辑不用大改

StateSlot_stateIf_Activityfetch_infouser_attitudehistory_info==fetch_infouser_action14030anyanyrequest15031anyanyconfirm