上一期谈到，query理解很大程度上是为后续的结果生成服务的，这一期就来讲讲，在系统理解了用户query后，是怎么处理产生回复发送到用户手里的。
这个小系列的文章记录：
对话系统最为独特的，就是这个多轮的问题，我自己本身对这块不熟，也是在努力的学习下，有一些自己的感受和思考。
人能够进行多轮对话，很大程度和我们能记住并且使用沟通过程产生的信息和共识，这里值得注意的是，有两个关键的能力，一个是记住，另一个是使用。而现有的大量技术也都是围绕着这两点来搭建的，甚至，比较统一的形成了一个“对话管理模块”，即Dialog Management，DM。
对话管理承担了多轮对话中信息的记录和使用，所谓的记录，就是对话过程的跟踪，一般被称为'Dialog State Tracking'，'DST'对话状态跟踪，而所谓的使用，有一个跟有意思的说法，叫做对话策略，'Dialog Policy'，DP。这点和我们日常的聊天很像，我们在对话过程中，一方面是能接收双方交换的信息，另一方面也会根据自己的目标或者想法制定不同的对话策略，从而达到自己的目标。
当然了，这里的拆解的部分，在现实应用中并不一定是独立拆分开的，可能是组合而成的端到端形式，也可能是拆解分开的形式，这个是根据现实情况来进行选择的。
因为把整个对话管理模块进行了拆解，因此整个对话从信息的梳理存储到对话策略的制定都会很明确，大家看起来也会非常好理解，这里先讲这个。
先用最常见的就是任务型对话作为例子，这个例子前面是提到过的：
Q：我要订机票。
A：要订从哪里出发的机票呢？
Q：从深圳，到北京的。
A：好的。希望什么时候出发？
Q：明天上午10点左右吧。
A：好的，系统给你找到XXX航班，明天10点05分起飞，预计13点到达，请问是否合适？
Q：可以的。
A：已经为您预定XXX航班，请点击付款完成最终操作。记得提前办理值机手续哟。
这是一段订机票的任务型对话，这段任务型对话其实并不复杂，目标很明确，就是要引导用户把所有信息都填充清楚后，进行订机票的操作，列举下来就这几件事：
显然，这种方式是非常规则化简单化的，而随着逐渐复杂，对话策略也就会逐步复杂，逐步迭代为一些类似类似用树或者用有限状态自动机来对这些规则进行合理化管理。
既然是拆解，那我们就拆解来看这些任务怎么做。
DST主要用于对对话过程中的内容就进行管理维护，这是为了下一步对话策略进行分析做基础的，最简单的方式其实就是直接用缓存把对话内容记下来，形成可解释的部分，如下面一个格式，只列举部分字段：
{
'destination': '北京',
'originator': '深圳',
'takeoff_time_date': ''
}
而后对话策略根据缺失的信息进行追问即可。
而后，随着内容逐渐丰富，场景逐渐复杂，甚至因为轮数增加部分信息也有了更新和变化，这种固定格式的并不一定能够满足我们的需求，于是有了更多的改进措施，也逐步向模型、泛化的方式进行。
首先是对话状态的表示，不难看出对话状态数跟意图和槽值对的数成指数关系，因此需要考虑构造合理的模式来实现，例如隐含信息状态、贝叶斯更新等。然后是状态的更新和转移，这种随着任务逐步复杂，是最快进行模型化的，从CRF到RNN，甚至用到迁移学习等，也从单一任务或者槽位的跟踪逐步升级为多任务多目标的跟踪，在DSTC大型赛事中被验证具有很好的效果。此处已经是一个非常完整的体系了，我也并不专业，这里不展开，大家可以看看其他大佬的博客，我这里列举一些好文章吧：
DP就是对话策略，对话策略是根据现有的query理解和DST，制定对话返回策略的部分，这部分一旦敲定，其实最终的回复也就差不多了，所以重要性也可想而知。
常见的对话策略都还比较简单，例如上面的任务型，其实就是比较简单的用一些规则，根据缺失的信息制定回复策略进行追问即可，这里甚至不需要很多复杂的操作，规则即可，但这也就仅限在一些比较简单任务了，对于复杂的任务，进行复杂的策略分析和预测就显得非常必要，DPL（对话策略学习）应运而生。
考虑到很多对话策略的文章直接就本着强化学习去聊了，但是我个人其实并不太想直奔那块，而是想把对话策略先当成分类来去聊（虽然我也知道，强化学习某种意义上其实和分类问题很像），即在现有信息下，我们把策略的选择当成是一个分类问题来去看，有了消息，我们该采取哪种策略，这点来看他实打实就是一个分类问题，主要原因是，它涉及的信息很多，最重要把他们综合起来，在各种策略中找到一个比较好的，这无疑就是一个分类问题，再升级一下，可能就是一个召回+TOP1排序的问题：
毫无疑问，想到这里，分类问题很合适，甚至适合在这里构造一个完整的分类系统，从模型分类到召回-排序的模式来做，都没有问题。
而后，由于本身DP就是一个决策问题，甚至是一个多次决策的问题，因此把问题交给强化学习可能更好，于是强化学习就开始成为DP的重要手段了。说到强化学习，必须提到的就是强化学习本身需要的元素，即状态、动作、奖励，在多轮对话里，状态就可以理解为DST中的信息，动作就是采取的对话策略，奖励就是采取行动会得到的奖励，我们所希望的就是全局，也就是整次对话下来，奖励最高，多轮对话无疑是符合这个模式的。
和DST一样，我这里不展开说，有兴趣大家可以自己进行深入阅读，我这里放一些我觉得比较好的文章吧：
端到端式的对话管理大部分出现在学术界中，用过特定的模型完成多轮信息的整合和对话策略的决策，甚至从输入开始进行串联，从输入直接到输出完成全局的端到端结果回复。
没错，检索式其实也有多轮，也能做多轮，而且其实研究还不少，其本质就是把历史的对话信息和当前的回复都放到模型的输入中，形成端到端的模式，不过从社区目前的关注度来看，关注度其实并不太高，列出一些文章供大家参考下：
与检索式对应的生成式多轮，生成式的灵活性可想而知。简单的方案其实很早就有了，seq2seq就是最经典的操作，直接将这些对话信息放入模型，这种操作方式和编码器类似，能直接生成一些基本的多轮回复，这种方式虽然简单，但终究算是一个可行的方法。
而后，考虑到对话信息的存储和处理，以及对知识的录入，其实慢慢的开始有用大模型、知识图谱的趋势，开始构造出更加顺滑，具有一定知识性的回复结果，GPT、BERT的始祖Transformer做的是机器翻译，而这本质其实还是文本生成，结合对抗生成模型的介入，这种模式为生成式多轮带来了新的发展。
除了上面聊的东西，其实很多场景都面临很多复杂多样的问题，这些我经常有听说过的，列举一下，有兴趣的也可以多查查资料学习，也欢迎各位大佬推荐文章深入学习和阅读。
文章写完了，但是总感觉意犹未尽，还有很多细节感觉无法写完，否则这就奔着一本书之类的去了，先到此为止吧。对话系统，和推荐系统、搜索系统一样，都是一些很复杂的系统，而且系统还会受到各种场景问题的外因（客服、智能助手、闲聊等）、系统内运转的内因（多轮信息的存储、知识库的挖掘存储、多意图处理）影响，从而产生了其实并不一致的各种解决方案，目前虽有大体统一的趋势，但是内部结构其实都有对自己面对的问题做了很多权衡，如果要变得更为深入，那就需要自己多实践+多阅读，多看看更多的方案和论文，才能有更好的提升。
这里，列举一些比较好的材料供大家参考学习吧：
另外大家也可以关注几个大厂的对话系统，技术都相对成熟了，部分会需求和应用的原因，会有些技术领域的限制，主要包括几个语音助手（小布助手、小爱同学、siri、天猫精灵、小度等），几个大厂（美团、平安、阿里小蜜、58等都有不少对话系统的分享）。
联系客服
