首先给出智能问答系统中的两个场景：（1）FAQ问题中能否直接用Query-Answer匹配？（2）给定对话历史语料，如何自动化构建问题-答案知识库（QA库）？

对于问题（1），一般的问答系统会通过Query-Question匹配（QQ匹配），然后将Question对应的Answer作为Query的请求返回。其实，似乎更直接的方式是Query-Answer匹配，这里的“Query”可以是“一个特定Query”，也可以是“上下文”，但是这样的匹配方式从我们的实践结果来看，并不容易做好。本质上，QQ匹配解决的是”Query和Question的相似性”问题，QA匹配解决的是”Query和Answer的相关性”问题，而“相似”和“相关”并不满足充要关系，并且多数时候，“相关”比“相似”更加主观，导致量化难度较高，客观化的结果并不理想。

具体体现在实现技术上，

（1）由于QA匹配的主观性问题较大，导致标注的不一致性较高，例如低于80%的一致性，这是这一任务困难的核心原因

（2）建模上对相似和相关，并不做显式的区分。比如，常用的siamese和cross-encoder结构，将二者不加显式区别的当做一个匹配问题来做。为此，《FAQ Retrieval using Query-Question Similarity and BERT-Based Query-Answer Relevance》中整合了两个概念。

在《A Deep Look into Neural Ranking Models for Information Retrieval》中，作者指出：

The notion of relevance is relatively clear in QA, i.e., whether the target passage/sentence answers the question, but assessment is challenging. Ranking models need to capture the patterns expected in the answer passage/sentence based on the intent of the question, such as the matching of the context words, the existence of the expected answer type, and so on.

给定一个Q，可能相对容易找到多个A，但是实际场景下，我们更想要的是最好的一个或者三个A。什么是好带来了评估上的挑战性。（值得一提的是，匹配问题做检索的同学做了很多不错的工作，具体可以参照SIGIR的相关工作，不一定要只盯着NLP或者更具体问答系统相关方向的工作）

但是这个任务是有价值的，

（1）在多轮对话中作为候选回复的打分器

（2）自动化问答库构建

而（2）就是这篇博客接下来要讨论的有趣的问题。该问题的输入是对话历史语料，比如电商领域的一个3C行业的店铺对话历史数据（包含多个Session），输出是一个从该对话语料中挖掘的问答对。

我们会有一个假设，“针对一个店铺，给定当前用户询问的问题，答案大概率存在于对话历史语料中。”，既然存在于对话历史语料中，那么就可以构建问答库，用于回答用户问题。在场景上，和检索式对话系统有相似之处，但不完全一致。主要是应用场景的区别：

（1）用户输入一个Query，问答库中存储的是Question-Answer的pair，这个时候通常做QQ匹配，直接返回答案

（2）在多轮对话过程中，给定一个上下文（多轮次对话历史），找到当前用户Query下的一个回复，比如这里的做法

（1）和（2）的主要区别是“Query”的含义不同。

要构建问答库，整体的逻辑是：候选集+筛选策略（QA匹配机制）。其中，不考虑Query的具体含义，候选QA对的组合方式如下：

候选QA对组合方式 优点 缺点 备注
分轮次 减小候选空间 不一定满足假设 当前方式
不分轮次 扩大候选空间，是分轮次后候选空间的超集 过大的候选空间，带来存储和计算的压力  

显然，一个基于经验的假设，选择分轮次可能是一个更好的方案。两种方案如下：

（1）标注Q-A数据，训练一个二分类模型。QA-score可以直接作为排序的依据，或者作为下游任务的一个重要信号（实际上，在初版答案推荐中，使用的正是该信号）

（2）基于Rank的方案。给定一个Q和一个A的list，其中有一个或者多个A是匹配的，其余的A是不匹配的，基于Margin损失，希望匹配的A与Q的距离尽可能近，同时不匹配的A与Q的距离尽可能远。相关工作

方案（2）和方案（1）相比，显著提升了QA对的召回。为啥？QA匹配二分类模型解决三个子问题：给不合法的Q打负标签，给不合法的A打负标签，给不合法的Q-A打负标签。而基于Rank的方案理论上不对不合法的Q做过滤，同时会给所有的Q匹配一个答案（Rank的最高分）。实测对比结果：在QA库的质量上，（2）并不显著弱于（1）。

从上述的分析可以看到，在QA匹配任务中研究对象有三个：Q, A和QA。QA总是需要显式建模在自己的方案中，但是Q和A其实是可选的，（2）中只考虑了A过滤，那么很容易顺推出，可以只考虑Q过滤。这种方案的优点在于：保留了所有的Q，但是会带来不同A，相同Q的问题。而（2）会存在不同Q，相同A的问题

从上下文的主线展开来看，上述的三个想法的上下文都比较单一，只有一个Q或者一个A，承接上文讨论过的内容，有没有更多可以利用的上下文？

（1）多轮次对话历史作为Q

（2）基于阅读理解的方案。抽取出所有的Q，Session作为MRC中的Document，找A的start_position/end_position

除此之外，开个脑洞，

（1）基于百度问答语料，预训练问答模型能否有助于QA库的构建？如果有，可迁移的能力是啥？如果没有，为啥？

（2）在QA匹配任务上，有没有更好的理解相关性和相似性的角度？

因此，无论从具体研究对象，还是从可利用上下文来看，QA匹配都有诸多玩法，但是QA匹配的难点依然存在，除了之前在博客中讨论过的答案推荐，QA匹配的应用场景还有许多。

因为难，所有有趣，有价值。

（雨一直下，约的稿终于写完了。）