致哀东航客机坠毁事故遇难同胞，本篇不放音乐了。

前沿重器

栏目主要给大家分享各种大厂、顶会的论文和分享，从中抽取关键精华的部分和大家分享，和大家一起把握前沿技术。具体介绍：仓颉专项：飞机大炮我都会，利器心法我还有。

近期，我再次总结了我的历史文章，累积起来有50w字，百余篇文章了，有兴趣可以拿来看看，获取方式：七夕清流，百余篇累计50w字文章合集发布。

往期回顾

• 前沿重器[17] | 美团搜索ner技术启示（下）

• 前沿重器[18] | KDD21-淘宝向量检索

• 前沿重器[19] | 预训练在美团搜索广告中的应用

• 前沿重器[20] | 文本分类和意图识别调研思考

• 前沿重器[21] | 聊聊对话系统：概述

上一篇和大家讨论了对话系统的一些基础场景，让大家对对话系统有一些初步的了解，尤其是在基本任务和一些类型的差异，今天给大家介绍一下对话系统常见的技术架构以及其技术架构的范式，方便大家更宏观地了解整个系统是怎么运作的。

这个小系列的文章记录：

• 概述。对整个对话系统有一个比较完整的综述，聊聊他的概念和一些核心技术点等。

• 技术架构——对话系统是怎么运转和处理的。（就这篇）

• 内容理解——理解对方说什么，也就是NLU。

• 内容输出——回复对方的内容是怎么产生的，

• 多轮对话——多轮的信息处理和对话策略。

懒人目录：

• 先来几个案例

• 对话系统的架构

• 架构背后的考量

• 架构和项目阶段的关系

先来几个案例

架构是一个抽象的概念，而实际的落地应用则是架构的现实体现，所以相比直接把结论喂出来，我更想先和大家讨论下现在业界的一些架构和设计思路。

平安智能问答

之前有写过文章讨论过：前沿重器[3] | 平安智能问答系统。这里再抽出关键点讲一下。平安的技术架构可以用这个图来解释：

这个架构图是按照处理流程来画的，即预处理、检索、知识图谱和信息处理、排序、结果输出等。整个对话系统就覆盖了这些内容。

• 预处理：包括分词、词性、实体推荐、纠错、多意图、句子匹配等等，在别的领域可能更多叫query理解了，就是对句子进行一些预处理，并且提取一些关键信息。

• 检索。这里的检索包括ES的检索和孪生网络，说白了就是文本检索和语义检索。

• 知识图谱和信息处理。说白了也是一种检索的过程，只是这里涉及到语料和图谱的管理罢了。

• 排序。针对多路召回的答案，根据语义、关键词、编辑距离等因素进行综合排序，最后甚至还有一些利用用户画像的操作。

微软小冰

这篇文章其实我也讲过，甚至更早：前沿重器[1] | 微软小冰-多轮和情感机器人的先行者，文章中我对小冰的评价非常高。主要是因为小冰起步的真的挺早的，而且现有很多技术和思想也很前沿，撑得起“先行者”之名吧，我们可以参考一下小冰的技术架构：

这个是按照模块划分的，告诉了我们他们是怎么切分的。

首先是有客户端，接受各个入口来的用户信息，主要是query，但这里看其实还有很多多模态的输入，声音、文本、图片、视频等，这个入口无疑也是多元化的。

中间是我们非常关心的对话系统层，里面包括了闲聊、技能、情感计算、和对话管理模块。

• 即使是闲聊，也按照通用闲聊和领域闲聊，拆解比较细致，领域闲聊里无疑还有很多知识维护的工作，有知识支撑的闲聊应该也是现在比较潮的技术话题了。

• 技能是为了让小冰具有完成特定任务和需求的能力，这里包括任务完成等很实用的技能，能帮助人完成一些基础工作。

• 情感计算应该是小冰比较特色的能力，一方面能理解用户的情感，另一块能有一定的社交能力，形成小冰自己的“人设”，从而产生一定的情感“反馈”，这个到现在也还是比较牛的场景落地。

• DM是多轮对话标志性的模块，要对整个对话管理起来，细分下，就是对话状态跟踪和对话策略，说白了就是一个处理输入和生成输出。

最底层，就是对话层，数据的重要性毋庸置疑，对我们算法来说这点我们更有感触，而小冰的底层数据，除了我们熟知的基础物料（知识），还有比较有特色的小冰画像（人设知识）、用户画像（用于个性化）。

美团智能问答技术

美团智能问答技术这块我没写文章讲解，原文在这里：https://mp.weixin.qq.com/s/IN-xzbrjjV2XgrGLPS5wRw

这个图也比较简单，对于对话系统本身，对话系统主要就是对应问题理解和问题解决，问题推荐属于另一个业务问题，这里先不聊。

在问题理解模块，主要覆盖了意图识别、实体识别等基础的NLU理解为，也有一些澄清这种对话系统比较特色的技术（模糊意图下形成向用户澄清的话术，例如“你说的啥？”），也有一些类似时效识别之类的场景特色的技术点。

至于问题解决，就是根据问题理解的结果，去生成回复，这个生成的方式很多，可以走图谱，可以走阅读理解，可以走任务型多轮，可以从社区问答里面找，甚至还有非常直观能够想到的文本生成，最终就是从多个回复中进行筛选和排序甚至是融合，最终解决问题。

案例小结

看完这几个工业界大厂的技术设计，其实大家都能从中找到一些共性，无论是计算流程，还是模块拆解划分，都有一个初步的了解，也能发现一些共性，对话系统在工业界的使用，思路就明确了。

对话系统的架构

流程架构针对的是整个对话系统的处理流程，即用户从提交query到最终获取回复的流程，基本流程就是这些：

• Query理解。覆盖意图识别、实体识别/提槽、语义表征等共性的NLP处理技术，也有一些涉及拒识、澄清、盘全等技术。

• 对话管理。针对多轮对话，需要将历史的对话内容甚至是用户画像构造并维护起来，并根据现在的现状，总结出当前最优的对话策略。

• 结果生成。根据Query理解和对话管理的结果，获取特定的答案，这里有检索、排序等和推荐系统还比较相似的操作。

针对Query理解，相信大家在读我的公众号多的情况下，已经有一些了解了，有兴趣可以翻翻我的历史文章。

对话管理，虽说学术界在这块研究的还算前沿，但是在工业界的发展并没有想象中顺利，无论是技术实现上，还是用户需求的复杂性上，都为多轮的落地实施带来巨大挑战，一方面多轮的信息的存储和处理，另一方面是根据先有信息和状态进行对话策略的生成，从而为下游答案筛选和排序提供依据，当然了，一些复杂的功能，例如主动对话、对话是推荐这种比较新潮也比较智能的技术，都需要依赖对话策略的设计来实现，如果策略做的不好，用户很可能会认为这是“答非所问”。

结果生成，这个过程其实和搜索非常类似，即是根据上游得到的结果，进行结果的召回，这里的召回思路打开，可以有很多：

• 文本召回。检索式对话那套最简单的模式，进行q-q，q-a匹配做结果召回。

• 语义向量召回。对query进行语义向量表征，进行向量召回。

• 知识图谱的识别和推理。

• 文本生成。很多多种信息进行受控的结果生成，生成特定的回复。

多路召回后，结合多种信息进行排序，这里的排序的学问也不少，相比搜索，会多很多对话相关的信息，相比推荐，也有很多的query处理的信息。

架构背后的考量

技术架构的设计背后其实就是一个系统工程，一个合理的架构和模块拆解能让系统在运行、维护、迭代过程更加流畅。我们在理解了对话系统整体架构的设计之后，可以进一步探索一下。

首先，Query理解成为比较稳定的独立模块。我们知道，对句子本身的理解，虽说部分内容可能会涉及人的认知会有些偏差，但是总体其实是比较固定的，把用户的内容充分理解后，也可以做很多事，特别的其实很多不同类型的文本都需要做理解，很多细节其实是业务无关的，那么Query理解就有必要独立化，另外在迭代上，他的迭代更多不来源于产品需求，而是一些意图召回、实体召回的效果提升，独立出来有利于降低对其他模块的影响。这点其实和搜索也非常类似，意图识别、NER任务独立化以后，能独立确定迭代的节奏。

第二个关键点，对话管理模块的设计，在现实落地的场景下，对话管理需要单独维护起来，主要原因是在计算机网络架构下，多轮对话背后其实对应用户的多次请求，多次请求但是对应多一批对话需要依赖类似sessionid的方法是实时维护，这不仅是算法的活，还需要大幅度依赖工程和数据方面的技术，形成一个综合的，交叉最多的技术点。诚然多轮的技术非常复杂，很多步骤其实都可以需要多轮信息，但是把各种多轮的操作都集中在这，显然是有大量的工程操作考虑的，举个例子，用户意图大都是上下相关的，如果把多轮信息的处理放在Query理解了，那工作量会骤然增大（想想打断、转移之类的凑在哦），加上多意图，这里的处理逻辑会很多，所以适当拆解，Query理解只负责把多种可能算出来，在对话管理模块再来筛选，会更合适。

第三，召回和排序的处理。对话系统的答案生成技术逐步多元化，让我们有了很多答案生成的模式，然而我们知道，不同的结果产生方案会对应很多场景，他们不是完全意义的平替关系，例如客服系统其实更倾向于检索式，毕竟答案可维护而且可控，生成的使用会比较谨慎，所以我们会把答案获取得到这个模块做成和搜索推荐相似的多路召回思路，所有可能得到答案的路径都会尝试去查查。这里，一方面是算法需要构造合理的表征进行计算，另一方面是工程需要在这里去搭建多种不同的数据中间件以满足不同的搜索需求，因此有了这种召回层的设计，而紧接着，就需要一个综合排序来找出最合适的方案。

架构和项目阶段的关系

当然了，抛开需求谈架构绝对是不合适的，这3个案例其实都建立在流程比较完善，业务也比较稳定的情况下了，但是初期，其实我们并没有太大必要切分那么细。来举个例子吧。

• 例如，做检索式问答系统，那召回的链路就会比较简单，甚至只有一个，此时我们完全没必要把召回和排序拆开，只需要在查回结果后，直接根据相似度等因素进行排序即可。

• 再例如，在系统比较简单的情况下，甚至是不需要很重的query理解的，例如意图识别，甚至可以不做，直接去进行检索排序都行。这里要明确意图识别存在的意义，主要是在用户需求非常分散的情况下，通过意图识别识别用户意图，从而方便进行一些不一样的设计，例如百科知识和音乐播放，最终给的结果形式都不同，此时有一个意图识别，能为下游做不同的操作提供一定的空间。

所以，上面的架构只是提供技术上的一些拆解思考，做出一些设计建议，也让大家了解到对话系统中涉及的算法技术有哪些，从而对对话系统在技术层面有一个宏观的认识。