对话系统中的多路召回和排序

最近和一些和对话系统不太了解的朋友聊了一下，发现其实很多人会把对话系统误解为一个简单、单一的系统，然而实际上对话系统内部的结构可以很复杂，这个原因很多吧，可能被一些文章给误导吧，其实一个比较成熟的对话系统，内部的结构和组件是可以很多的，比较突出的就是多路召回以及其对应的排序系统。这一期给大家介绍一下这两个模块。

在工业界，可能会因为各种原因，我们需要采用多路召回的方式来处理对话系统，即分头考虑多种答案的可能性，然后再筛选出最优的回答。这一期就给大家介绍多路召回和排序的来龙去脉，以及常见的解决方案。

多路召回的原因

上一期（心法利器[78] | 端到端任务的拆解设计）我们有提到，对于一个任务，如果比较复杂，我们是希望把任务进行拆解的，拆解之后各个击破然后组装回来，那么对于一个完整的对话系统也是如此，当然这也是它能被称之为“系统”的理由，一般情况，我们会因为这些原因，把整个内容回复部分做拆解，形成多路召回：

回复内容的来源比较多样。如一些问答类的，可能是问天气、百科，这些资源的来源可能都不一样，此时我们肯定是需要拆分多路召回逐个获取的，甚至有些内容就是生成的，例如闲聊之类的。

不同内容的数据结构不同，要构造不同的存储和检索方案，例如结构化的内容，用mysql，文本检索用ES，向量检索可以用faiss，还有图谱等。

有些可能是因为检索内容和对象不同，例如QQ和QA匹配，例如改写前后的匹配等。

一些回复需要特别的构造，如追问（你要问的是XXX吗）、疑似问（你要问的问题是否在下面）、风控兜底（你说的这话不合适，对不起我还在学习）等。

因为很多原因，我们需要做多路召回，把多种不同内容、不同数据结构的资源，分路进行各自的召回，各自处理好后再排序。

多路的召回形式

由于上述原因，我们需要对对话系统进行多路召回，那么召回上，主要有哪些召回的链路呢。

检索式

首先，是比较经典的检索技术，这个其实对应的比较经典的检索式对话，其实现在仍旧被广泛使用，一些依赖数据、依赖知识背景的场景，这种检索来找到合适的答案的方式是非常重要的，例如一些人物问答“鲁迅的生卒年份”，客服场景“冰箱维修”，非常依赖检索式，一般比较常用的检索工具，有这些，大家可以根据实际情况进行选择。当然，篇幅和时间原因，这里我只会提一些名词，一些只是细节欢迎根据我提到的关键词进行更加深入的学习。

对于结构化的知识，就是能形成关系表的那种，mysql是一个比较好的选择，毕竟结构化查询语言比较成熟，各种处理会比较简单。

对于长文本、非结构化的检索，技术上用的就是传统搜索中的倒排索引，工具上，单机其实可以自己写，也可以用，python写个dict就可以了，具体的可以参考之前我写的词典匹配的这篇（把后面dict中的value改成长文本id即可），但是由于一般资源会比较多，所以更倾向于用分布式的方式，Elasticsearch是很好的选择。

向量检索，应该是现在比较潮流的玩法，在我们有一套比较好的向量的时候，就要做向量检索，这个向量检索的工具，单机推荐annoy，分布式推荐faiss，另外前面说的elasticseatch加上一些插件，如hnswlib也是可以用的。

另外还有一些更加前言的技术，例如知识图谱，这个我具体没有接触，听到比较多的是neo4j，其他的有熟悉这个的伙伴欢迎在评论区补充。

生成式

当然，除了经典的检索式对话，还有大家比较喜欢聊起来的生成式，其实我的视角，工业界对生成式一直是比较谨慎的，主要原因有这么几个：

生成式虽然非常直接，但是内容不可控，很多时候会有一些不太合适的回答，作为面向用户的产品，可控性要求很高，例如一些不小心的涉黄涉暴，其实风险很高的，甚至有一些问句和答句分别看着很合适但是放一起就不合适的情况，虽然不多，但是一旦出现被封号下架没了就很血亏了。

生成式其实也会有很多领域以来知识支撑，一旦没有知识，是会出现“一本书正经的胡说八道”的情况。

写到这，发现自己之前的对话系统系列文章写过类似的文章，有关内容生成的，在这里：前沿重器[24] | 聊聊对话系统：内容输出。

多轮

但说到这里，仍旧还有一种比较特殊的召回情况，需要说，就是多轮。多轮是一种对话系统一种特有的形式，另外这里会分强多轮和弱多轮，简单解释下：

强多轮是进入到一个比较狭窄的多轮通道，基本都会限制在这个对话链路里，一般是一些任务型的对话可能会这么做，例如定机票，多半需要将对话封闭起来做多轮的追问。一般无明确的打断，都更倾向于封闭处理，不大会和其他链路一起排序。

弱多轮是做对话内容的信息继承，在聊天过程可能会根据上轮信息给出进一步的回复，这种情况多半会比较宽松，通常都会参与和其他召回链路一起排序。

因此，如果是弱多轮，其实就是增加一个多轮的链路处理就好了，而对于强多轮，一般会增加一个打断判断，如果不打断，就这一路多轮召回就好了，如果需要打断，再让位给其他链路即可。

值得注意的是，多轮只是一个对话系统里的特殊情况，多轮里面的内容，多半也逃不开检索式和生成式这样的形式。

多路召回下的排序

既然要分，后续肯定要合，多路召回对半就需要进行了排序。因为不同系统的不太一样，所以简单取一些情况简单聊聊。

有用户反馈

类似搜索和推荐系统，有些场景的推荐系统，是可以有用户反馈的，例如一些客服系统之类的，用户会给回复打分，例如“满足”or“未满足”，那就可以根据情况进行调整。既然有用户的反馈，就可以开始利用起来，甚至是有些类似搜索的精排模型可以做。

因为不同系统中，用户的反馈的占比、形式、可靠程度不同，采取的策略不太一样，有些质量比较差或者比例比较低的，甚至直接抛弃，这个其实很考验算法对现状和自己手里方案的理解，因为资料看的还不太够，我先不展开吧，后面有机会展开聊。我可以明确的是，直接套用搜索或者推荐那一套，很多时候是真不可行。

无用户反馈

无用户反馈往往是对话系统中最常见的情况，一般有这几个原因：

产品原因，很多产品没有明确的用户回复，一般给了答案用户就走了。

多答案的问题，一个提问可能有很多的回答方式，可能都是合理的，但用来做模型训练也不好评估。

答案形式的丰富性，多种答案类型做统一表征存在困难，本身表征建模也不好做。

因此，大部分对话系统很难有用户反馈和有监督的方式，这点真的得靠评测产品运营来做综合评估然后来优化的，在多链路的合并时，往往是使用比较简单的规则和简单的认为评分进行分级排序，根据每个链路的质量、可靠性来进行综合评估打分排序似乎是一个比较常规而且成本不高的方法。

这点不要以为非常罕见或者非常low，对于比较早起的搜索和排序系统，也是用的类似的方式来做综合排序的，毕竟这个方式可靠简单。

审核编辑 ：李倩