阐明性问题生成 (Clarification Question Generation) 概览

©PaperWeekly 原创 · 作者｜章志凌

学校｜上海交通大学硕士生

研究方向｜文本生成和知识图谱

Clarification/clarifying question generation (CQGen)，是近年来文本生成研究领域兴起的一个新方向。Clarification question 目前似乎还没有很公认的翻译方式，而直接谷歌翻译的结果是“澄清问题”，离它的实际含义实在相去甚远，所以自己斗胆给个译名——阐明性问题。

自己最近在这一方向上进行研究，有幸做出了一篇工作被 WWW 2021 录用。不过本文旨在做一个领域的概览，而不局限于本人的微小贡献，帮助更多的研究者了解这一任务，并做出好的成果。 

那么阐明性问题到底是什么，为什么值得研究呢？先举个栗子： 

▲ AskUbuntu上的CQ，图源 [1] 

如上图所示，很多人在问答或求助平台上难以得到帮助，是因为在自己的帖子中并没有包含足够让他人理解和解决问题的关键信息。如上例中的 ubuntu 版本信息，熟悉的人应该都知道，不同版本的操作系统上很多东西都是不一样的。好心的用户也许会留下阐明性问题来提醒发帖人补充这些缺失的关键信息，从而使得发帖人的问题更可能得到解决。 

从上面的例子中，我们可以了解阐明性问题的含义：对上下文中缺失信息的提问。 

不过，既然我们在现实生活中已经有了人为的提问，为何我们还需要算法来生成这样的问题呢？因为，提问毕竟比较耗费精力，所以能够得到这种提问的情况可能不会很多，更多的缺少信息的低质量问题可能就此石沉大海。

有意思的是，即使在有人提出 CQ 的情况下，有研究发现，提问者往往最后也不会回答原始的问题 [2]，个人认为原因也许是他们认为这些问题的质量很差，提出 CQ 并不是想要帮助解决问题，而只是一种情绪的发泄（问 ubuntu 的问题，连版本都不说？）。 

阐明性问题不止在问答平台上存在，其形式可以很多样，包括： 

• 淘宝，Amazon 等电商平台上的顾客问题

• • 顾客会对商品描述中没有讲明白，而他们关心的一些具体细节提问

• 在搜索引擎中，搜索引擎通过提问指引用户补充 query

• • 与下拉菜单中的搜索联想不同，是提出了自然语言形式的问题来让用户提供反馈

• 对话系统乃至真人聊天中，一方说的话让人捉摸不透，另一方可以通过提问让 TA 阐明自己的想法或意图

• • 通过这种方式也可以推进现有话题，避免把天聊死，增加对话的长度和深度

• 等等... 

这也揭示了它与传统阅读理解场景下的问题生成（QG）的区别：传统 QG 是对文章中已有答案的内容提问（出题），从而考察做题人理解文章找到答案的能力。形式上，它是（上下文+答案）→（问题）的一个映射。

 

▲ 传统QG的常用数据SQuAD的例子，Answer已经存在于文中

而 CQGen，由于是对上下文缺失信息的提问，答案是不存在的，所以它是单独的（上下文）→（问题）的一个映射，与最一般的文本生成相似。所以传统 QG 中利用 answer 的一些改进思路在 CQGen 中不直接可用，而一般的文本生成方法在这个特定的 task 上也不能达到最好的表现。

CQ 的多样内涵使得这一任务中存在很多 domain-specific 的问题值得研究，相应的也有很多有趣的思路被提出。 

不过在多样的外衣下，这些研究也都会有共通之处，也就是这个问题的核心要害，只有向着这个核心进发，才更容易做出有效的成果。我认为，这个问题的核心就是：阐明性问题不仅只要满足提问缺失信息，更重要的是要满足信息需求。 

从上面的关系图中可以看到：

• 传统阅读理解QG，只对于上下文中存在的信息进行提问。

• 阐明性问题，根据定义，可以对于整个上下文信息的补集进行提问。

• • 不过首先，我们至少应该提问与上下文相关的信息。

  • 更进一步，只有真正能帮助参与者满足信息需求的问题，才是好的阐明性问题。

• 通用文本生成技术，广泛应用于翻译，摘要等任务，也许能够做到给出相关的信息，却未必能够很有针对性的解决信息需求。

所以，笔者尝试给阐明性问题提供一个新的更具体的定义：阐明性问题是对缺失信息提问以满足信息需求的问题。

因此，我认为能够在 CQG 上做出进步的工作，往往是：

1. 模型在信息需求上提供了有效的先验知识

2. 或者通过一些方法使得模型更容易捕捉到信息需求相关的线索

下面，我就分成各个领域来介绍 CQG 上的一些近年来的代表性工作，并揭示它们的成功与上述核心问题之间的联系。

写作助手

我们就先从最上面的 AskUbuntu 的例子讲起： 

这一场景最初在 [1] 中被提出，不过使用的是在已有的 CQ 问题池中 ranking 来选择新的 post 的最佳问题的方法来解决的，可以说是一种 retrieval 的方法而不是 generation，而且 retrieval 有着明显的局限性，所以在此不展开了。

同一团队的作者在 [3] 中提出了一种创新的 generation 方法（GAN-Utility）来解决这一问题。其思想的基本出发点是：一个好的 CQ，应当使其回答最有可能补全上下文中的缺失信息。

也就是说，生成器应当要有某种程度的“先见之明”，其提问方向要朝着最有建设性的方向出发。这恰好符合了我们上面概括的核心问题，就是在能够生成的相关问题中，尽可能选择最能够满足信息需求的问题进行提问。

但是，一般的生成模型都使用最大似然进行训练，能直接学到的不过是与训练数据的相似，又如何引入这种“先见之明”呢？作者想到了 RL，要是能够把答案的最终功效作为 reward 来指引训练过程，也许就能够达到这个目的。其具体方法如下图所示： 

1. 为了预计答案的效果，我们首先要有答案，但是上面已经强调，CQG 在实际应用时是没有答案的，所以，为了得到答案，作者同时用训练集中收集到的答案训练了一个答案生成模型。

2. 为了计算答案的最终功效，对于问题 Q，作者假设训练集中正确配对的 A 是有用的，而随机配对的 A 是没用的，从而通过训练一个判断 QA 是否正确配对的模型，就能够估计 A 的功效。（Utility Calculator）。

3. 为了提升模型生成好答案的能力（并相应地改进问题生成），作者使用了 GAN 的思想，假设人的答案比机器生成的答案会更有用，所以通过 GAN 的 objective 来使得生成器生成更接近人的回答，就能够得到更有用的答案。 

虽然我很赞同其基本出发点，但在此还要对其具体方法做一些批判： 

1. 按照 CQ 的定义，答案应当是不能从文中直接得到的。（虽然实际数据中，不能排除有人没仔细看上下文就提了一个其实已经被提及的问题。）所以，是否能够训得出一个靠谱的 Answer Generator 是存疑的，作者在文中也没有给出关于答案生成质量的评价指标和例子。

2. 功效计算没有太大的问题，当然也可以说配对的答案也不一定有用，不配对的答案也可能有用，不过这个问题不大。但是按照1，如果输入的答案本身都是不好的，那么这个功效也没什么用处。

3. 这里的 GAN 的假设有比较大的问题。实际上，即使机器学着模仿人的生成，其学习到的也未必是其有用的方面，而更有可能是其写作风格等。而人的写作风格和机器的写作风格是容易区分的，比如根据我自己的操作经验，最显著的一点就是人写的答案的平均长度要更长。那么模型也许只要升成更长的答案，就能够更好地骗过 GAN。

由于作者的开源代码存在 bug，我无法准确地复现其结果，也就无法证实或证伪我上面的一些论断。但尽管给出了很多批判，我还是觉得这个工作提出了一个很有意思的想法。 

它 [3] 也同时引出了一个新的 CQ 使用场景——Amazon 电商中的顾客问答（国内可以拿淘宝的问答区类比）： 

这正是我的 WWW 工作: Diverse and Specific Clarification Question Generation with Keywords [5] 着手的场景。 

之前的工作，除了上面提到的技术上的局限性，它们也没有对其在互联网中的具体使用场景进行讨论。而在本文中，笔者认为其问题设置和方法在实用中存在一些局限性： 

首先，多样性不足（Diverse）。之前的方法都假设对一个上下文（商品描述）只生成一个问题；然而现实中顾客的信息需求是很多样化的，就像有个商品的问答区会有上百个问题一样（在本文和 [3] 使用的数据集上，平均问题数量是 7）。只有一个问题显然不足以满足那么多的多样化需求。

 
然后，生成的问题不够具体（Specific）。传统的 MLE 训练的文本生成模型往往倾向于生成简短而通用的 CQ（如：What are the dimensions？，即尺寸是多少）这类问题确实在很多情况下是有用的。

然而，更多时候，用户的具体化的需求并不能被这类 general 的问题覆盖，就比如上图中的 induction compatible 的问题，就是用户在带电环境下使用金属制品可能会产生的具体信息需求。

其不像上面的尺寸问题几乎可以套用在所有商品上，但只要问得精准，其价值也更高，因为像尺寸这样的共性问题更容易被考虑到，直接用加进参数表要求所有商品都填一下，就能够替代自然语言问题了。（事实上，现在 Amazon 已经在参数表中要求填写尺寸了。数据集中还包含大量尺寸问题，可能是因为数据集比较老，当时没有类似要求）。 

再加上，前述工作只是提出了这样一个技术问题，却明没有明确怎样在实际产品中使用这一技术。

综上，笔者提出了一种写作助手的设计，其能够在商家撰写产品描述时，对于目前上下文中可能存在的缺失信息，提出多样和具体的阐明性问题。

如上图所示，对于出售华夫饼机的商家，当他撰写完一版介绍的草稿时，可以点击 “Question” 按键向写作助手请求阐明性问题。而图中已经展示出了系统提出的 3 个问题，分别从电压、尺寸和功率三个不同层面进行了提问，且确实是上下文中没有涵盖到的信息，则商家可以利用各种方法（手头的资料、通过自己的测量，或与生产商联系）得到这些信息，再补充到描述中。直到信息完整后，按 “Confirm” 确认。这样的写作助手辅助补充完整的产品描述，更可能预防因为顾客找不到自己关心的信息而流失的情况。

系统设计完成，其背后的算法也仍需改进。为了解决前述两大技术难题，本文提出了基于 Keyword Prediction and keyword-Conditioned generation 的算法，简称 KPCNet。

为了解决具体性的问题（Specificity）。我们发现在电商场景中，阐明性问题的具体成分主要是其中的关键词（非停用词的名词、动词、形容词），举例如下（下划线为关键词，粗体为强调）： 

• 类别、属性：What is the voltage of the machine?

• 产品的组件和部分：Is the blade of the food grinder made of stainless steel?

• 与产品相关的使用体验：Can I cook rice in the cooker?

如果能够让生成模型更有针对性地生成产品相关的具体关键词，那么它就应当可以生成更具体的问题。 

为了得到产品相关的具体关键词，我们训练了一个关键词预测模型，输入商品描述，预测它的所有 CQ 中可能会出现的关键词（一个multi-label classification问题）。 

• 注意与前一个工作不同，此处我们预测的是 CQ 中的关键词，而不是其答案。从商品描述中预测“对电压提问”要比起预测“电压是 220V”的答案更有可能 

得到预测结果后，我们将预测到的关键词信息输入 seq2seq 模型，使其指导模型的生成。这样，以输入的关键词作为条件，模型就更可能会生成这些关键词，会与这些关键词有语义相关的内容，从而赋予 CQ Specififity。 

为了解决多样性的问题（Diversity）。我们利用了 KPCNet 中关键词对模型的控制性，只要提供不同的关键词作为条件，就能够给出不同的生成结果。那么，多组关键词从哪里来？在上述的关键词预测模型中，由于同一个产品对应多个问题，所以预测的关键词中实际上已经包括了出现在多个问题中的关键词集合，所以我们只要把预测结果中的关键词加以适当的聚类，将最可能出现在一个问题中的关键词聚到一组中。那么再基于这几个聚类分别生成问题，就能够生成多样且合理的阐明性问题了。 

结果举例如下： 

ref 是数据集中的参考问题，下面两个方法是 baseline，而最下面是我们的 KPCNet 方法。可以看到我们的方法在多样性和具体性上相对 baseline 具有一定的优势，但离人还有一定的距离。

提出方法时，笔者还没有从上述概括的核心问题（信息需求）的角度思考。回过头来看，KPCNet 能 work 的原因其实也与之有关。实际上，正是因为 KPCNet 中限定的关键词集合（千数量级）实际上是一种关于信息需求的先验知识，相比于宽泛生成词汇表（万数量级），它会更加专注于信息需求，所以它才能比普通的 MLE 和没有明确“需求导向”的多样生成 baseline hMup 生成更好更准的问题。

但也从这个角度出发，也可以解释本文方法的一些局限性，在此做出一些自我批判：

• 关键词集合还不够精确，其中除了信息需求，还存在一些冗余。比如 KPCNet 生成的结果中经常会重复商品本身的类别，这固然不错，但也无用，甚至可能反而分散了模型应当分配到其他需求类关键词上的“注意力”（非 attention mechanism，只是个不精确的比喻）。

• 关键词的粒度较小，不能够很好地描述词组级、短句级的更长的需求。虽然关键词可以通过组合描述长的需求（比如 cook rice, stainless steel），但毕竟不是最优的方案。如 AliCoCo [5] 这样的更加具体且直接定位需求的电商知识图谱，也许可以成为先验知识的更佳来源。

再加上 keyword predictior 目前还不能做到很精确，使得本文的方法依然存在一些局限性。笔者认为，本文类似的框架，如果有工业界的力量，能够结合更精准定位需求的知识图谱，获取更多的 metadata 来准确预测关键词/需求，还能够大大改进目前 CQGen 这个任务上的表现。因此，也希望这一研究问题得到更多关注，继续进步，走向实用。 

CQGen 在其他领域和任务上也有很多有意思的工作，我们接下来继续展开。 上个章节提到：阐明性问题是对缺失信息提问以满足信息需求的问题。

我认为能够在 CQG 上做出进步的工作，往往是：

 

1. 为模型在信息需求上提供了有效的先验知识；

2. 或者通过一些方法使得模型更容易捕捉到信息需求相关的线索。

笔者重点介绍了改进文章的写作助手这一防线。我认为其中的 GAN-Utility [7] 的思路可以归到上述的 (2)，而本人的 KPCNet [8] 则属于 (1) 的思路。CQGen 在其他领域和任务上也有很多有意思的工作，这些工作的优点也与上述 CQ 的核心问题密切相关，下面继续展开：

信息检索/搜索引擎 

搜索引擎的使用场景中，由于完整表达需求比较困难和麻烦，用户输入的 query 往往是很短的。这就使得 query 指向的意图往往是有歧义的，需要我们来做阐明。 

实际上，搜索引擎已经有搜索词补充推荐，还有页底的相关搜索等方式来帮助用户阐明其实际需求，但却没有直接自然语言提出问题的例子（在下面这篇研究之前）。 

那么搜索引擎中的 CQGen 到底如何做，如何融入产品设计，做了又有什么用？让我们来看看微软 bing 团队的这篇工作 [9]： 

2.1 Generating Clarifying Questions for Information Retrieval

Bing 团队设计了如上图所示的 clarification panel。其中有根据搜索内容（query）生成的阐明性问题，且为了交互的方便，还提供了几个可以直接点击选择的答案。选择了答案以后，相应的词就被扩展到现有的搜索框中，下方的搜索结果也就相应的变得更加精准。 

为了验证这种设计的收益，研究者进行了找到了一些志愿者进行用户测试，结果发现用户对这一设计的评价很高。他们认为这个设计一方面能够指导他们更精确的找到自己的需求（看来用户在搜索的时候可能有时候也不知道自己想搜什么）。

另一方面，心理上也让用户感觉搜索引擎更懂他们的需求，对其更加放心。比如想要通过搜索对电器进行比较时，他们可以依赖上述 CQ 的推荐出来的电器的各个属性去搜索，而不用担心自己遗忘了比较哪个方面。 

这一设计与搜索引擎的其他功能在一起让用户评分，结果发现它是最受欢迎的功能，超越了功能上相近的相关搜索和实体卡片等（见下图）。 

那么，这样的问题和答案又是如何生成的呢？下面我们来讨论其方法： 

为了挖掘出有歧义的短 query 背后可能的明确意图，他们使用了 query reformulation 的数据。即，用户发现第一次搜索的结果不够理想，然后接着对原 query 进行的修改。

如想要搜女款跑鞋的用户先搜了“running shoes”，然后又加上了“woman”一词，这就是一次 query reformulation，记为 running shoes -> woman（还可以包括总体的频率，刻画这种变换是否常见）。

由于 reformulation 中的更新词往往是原始 query 实体（entity）的一个方面，其被记为 aspect，它们将成为 entity 触发的问题的答案。 

有了上面的 query 和 entity，他们首先设计了若干问题模板用于生成： 

其中 QUERY_ENTITY_TYPE 和 ASPECT_ENTITY_TYPE 从网络语料中使用信息抽取方法获得。这样就可以生成一些固定模式的问题了。然而这些固定模式的 CQ 还是有些生硬，并且由于不是每个实体都能找到合适的类别名，限制了其泛化能力。所以他们又进一步提出了一种使用神经网络的生成方法，把上述模板生成的问题作为一种弱监督方式（即学习目标），以 query 和对应的若干 Aspect 作为输入，组成一种 seq2seq 模型。其结构如下图： 

由于这个模型在训练中能够见到未被 ENTITY/ASPECT_TYPE 覆盖到的 aspect，所以他们认为这个模型能够从存在类型名和实体/方面配对的训练数据中学习，更好地泛化到类型名不可得的情况。 

为了进一步提升答案的可能功效，他们还借鉴了 [7] 的思想，使用 RL 来提升训练结果的 Utility，从而进一步提升了生成质量。具体细节较为复杂，在此不加以展开。 

最后再从信息需求的角度来考察这个方法。实际上，这一方法中至关重要的地方就是：利用 query reformulation 的数据，提供了模糊 query 对应的具体需求的一种先验知识。 

除了传统搜索引擎以外，语音/对话搜索也面临着歧义 query 的挑战，因为一句话能够包含的信息也是有限的。下面这篇文章重点讨论了这种场景：

2.2 Asking Clarifying Questions in Open-Domain Information-Seeking Conversations 

上图中，两人提供的搜索词都是 dinosaur，但是其真实需求（Information Need/Facet）不尽相同，这一对话式搜索系统能够通过提问阐明性问题和用户的反馈（一段话，可能有答案，也可能是不确定），探明用户的实际需求，并给出相关结果。 

这一问题相当困难，本文实际上只给出了一个简化的设定，建立了一个有人工标注的（query，information need，相关/不相关问题）配对的数据集，然后给定算法可见的 query 和算法不可见的 information need，让算法在给定的候选问题集 rank 出能够阐明实际信息需求的问题，在此不展开叙述了。但这也是一个很有趣和有用的场景，期待能够看到这方面的更多进展。 

对话系统 

上面的语音搜索已经很接近对话的概念。实际上，对话系统中需要阐明信息的情况也非常普遍。 

对话系统可以分为任务型对话系统（Task-oriented Dialogue System）和开放域对话系统（Open-domain Dialogue Systems, Chatbot）。其中前者被限制在完成特定的任务中，一般的实现方式是，把用户的 query 解析到预定义的一些意图和槽中，然后系统根据这些解析的信息调整对话状态，并作出相应的行为。而开放域对话系统则可以自由闲聊。 

在二者中，阐明性问题都是其中的重要组成部分。有的工作把 CQGen 的生成包括在了整体系统中而不加以单独讨论（大体来说，就是一个通用的文本生成系统就可以生成陈述句和问题，其中的一部分生成结果可能就是 CQ；或者 CQ 只是很多种预定义的回复类型的其中一种）；而有的工作则是将其作为单独的部分来讨论，我们主要来聊聊后者。 

先是任务型对话系统，主要介绍这篇工作 [11]。

3.1 Resolving Intent Ambiguities by Retrieving Discriminative Clarifying Questions 

上图显示了一个银行对话系统对歧义输入的处理。红框中，系统错把用户想开 checking account 的意图当成了开 saving account，使得用户很不满意。而一个理想的系统应该像绿框中一样，如果发现输入中存在歧义，就先提出阐明性问题来解决它，然后再给出正确的服务。这样的系统显然能够更准确的解决用户的需要，并且和上面搜索引擎的例子一样，可以让系统显得更智能，让用户信任。 

那么这样的系统如何实现呢？它可以拆分为如下的步骤（如下图所示） 

1. 训练一个意图分类器，能够把用户的输入分类到某种预定义的意图上

与传统模型不同的是，这里的分类器还将用来判断问题是否存在歧义。如果输入本身已经足够清晰，那么当然没有必要进行提问。这样就实现了准确性和效率的平衡。

不过其判断歧义的方法并不复杂：如果预测概率最高的一类意图的概率小于某个给定的阈值，则认为这个输入是存在歧义的，而如果概率最高的两类意图之间的概率差小于某个给定阈值（即模型对二者的预测都不自信），则认为在这两类之间存在歧义。 

2. 基于意图类对应的训练语料中的用户输入，使用规则方法生成问题-答案对

训练集中已经存在着一些（无歧义的）用户输入，被人工标注了对应的意图。比如“I want to open a checking account.“ 的意图就是”opening_a_checking_account”。 

假设模型预测其中一个歧义意图就是“opening_a_checking_account”，则提问 CQ 后，与数据集中的同类意图下的现有用户输入（Open a checking account）相似的回答会是对我们的消歧很有帮助的信息。

为了让用户针对这些要点进行回答，我们在这句无歧义的话上使用一种传统 QG 技术生成问题-答案对。这里使用的是 SynQG [12]，基于句法解析，规则映射和模板的一套无监督问题生成方法。这样无需任何训练语料，我们就能生成类似（What do you want to do? Open a checking account）这样的问答对。 

每类意图中的每句话都使用上述方法生成问答对，形成对应问答集，备用于下一步。 

3. 对于一对存在歧义的意图，在其对应的问答集中，选择其中与输入最相关且最有判别力的一对问答 

其中的评分依据包括：

• 两个意图的对应问题越接近越好

• 两个意图的对应问题的答案越有区别越好

• 两个意图的对应问题都与当前用户输入越接近越好

以上的相似度都可以用预训练的 sentence-encoder 得到的 sentence embedding 计算 cosine similarity 得到。

4. 将选择的一对问答进行组合，形成最终的阐明性问题

由于 SynQG 生成的问题的上下文与当前的上下文不完全匹配，所以作者设计了一系列的规则对其加以调整以适用于当前上下文，并使用了 back-translation 改进问题语法质量。

 
而当规则也不能覆盖时，作者使用了模板方法，有一系列例如“Are you talking about DP_j or DP_k？”的模板，其中 DP_i 是意图 i 的有区分力的词组，套入具体值来生成问题。 

从信息需求/意图的角度来看，本文同时做好了两件事情：

1. 任务型对话系统中预定义的意图集合为信息需求提供了限制范围的先验知识，这个小范围内的问题更容易处理。

2. 挑选有判别力的一对问答这一步，为生成最有可能解决满足信息需求的问题提供了基础。因为本文中的CQ简化设定都是二选一式的疑问句，所以在这里，找最可能满足信息需求的问题的任务，可以被规约到找最有判别力的一对问答。

综上，我认为本文的方法在这里的 CQGen 任务上效果应该是挺不错的。不过本文的问题设定，无论是任务式对话系统本身，还是 CQ 的选择疑问句形式，相对于 DSTC 类的经典设定都是比较简化的，这可能会限制其应用范围。 

在开放域对话系统中，CQ 一般不被单独讨论，但是实际上其中的问题大部分可以认为是 CQ。我们使用 [13] 中的例子来讨论一下： 

上图展示了两个闲聊场景。第一个例子中，用户可能对自己的身材体重不是很满意（所以可能会有减肥的想法 不，减肥是不可能的），而对话系统就提出了一起登山运动的提议。这一提议并没有出现在上下文中，但是却“可能”迎合了减肥的需求。第二个例子也类似，用户提起 KTV 这个事件，可能没有明确提及、或者没有想到自己的需求，但潜意识里也许就是想要分享唱歌的感受，需要一个情商高的捧哏 bot 把话题延续下去~ 

CQ 在对话系统中一般不被单独讨论的原因，个人认为，一方面是这个名词的认知度不是很高，更重要的另一方面单独研究这一个模块可能没有很大的意义，尤其是与近年来流行的 end2end 对话系统（Meena, Blender, Plato-2 等）对比: 

首先，以单独的问题生成模块来处理问题，意味着要把它应用于对话系统，就必须使用多模块的流水线系统，其中还要包括一个判断是否需要 CQ 的模块，这在工程实践上是比较复杂的。而 end2end 系统能够在无限制的自然语言生成时自动、隐式地选择是否进行提问。

另外，问题生成模块单独训练，其可以利用的语料也不如 end2end 的考虑所有情况的语料来得丰富，所以其效果可能也不够好。

综上，我认为仅考虑单独的问题生成模块的问题设定，在 chatbot 系统中可能不太利于实践。 

不过，在开放域对话中生成阐明性问题也还是可能构成一个有挑战性的技术问题，作为对话系统的部分，其解决问题的思路还是可以为改进整体对话系统提供启发。

按照 CQGen 核心问题的思路，要想在这里利用知识提供信息需求方面的先验。那么应用的知识就要足够广泛和普遍，我认为近年来得到大量关注的常识知识（本人所在的 ADAPT 实验室有过一些整理）大概就是一个很好的选项。近年来也有利用常识知识的相关工作，比如 [14]，是将其应用在一个整体的对话系统中，效果也很好。

总结

本文中，笔者尝试概括了阐明性问题生成的核心问题，并基于此引出一个定义：阐明性问题是对缺失信息提问以满足信息需求的问题。然后，基于此视角考察了写作助手，信息检索，对话系统中 CQGen 的方法与应用。

这些例子都向我们说明，CQGen 中能够做出进步的工作，一般是为模型在信息需求上提供了有效的先验知识，或者通过一些方法使得模型更容易捕捉到信息需求相关的线索。

所以，我认为未来有希望的研究方向，是找到 CQGen 可以适当应用的场景，深入考察其中涉及的信息需求，并相应构建知识来提供有用的先验；或者探索一些技术方法来让模型能更好地理解信息需求。 

篇幅所限，还有一些 CQ 相关的文章不能详加论述，在此再附上一些，有兴趣的读者可以参考：

• Controlling the Specificity of Clarification Question Generation

• ClarQ：A large-scale and diverse dataset for Clarification Question Generation

• ConvAI3：Generating Clarifying Questions for Open-Domain Dialogue Systems (ClariQ) 

• Asking Clarification Questions in Knowledge-Based Question Answering

• LEARNING THROUGH DIALOGUE INTERACTIONS BY ASKING QUESTIONS

• A Context-aware Attention Network for Interactive Question Answering

• AMBIGQA：Answering Ambiguous Open-domain Questions

参考文献

[1] Learning to Ask Good Questions: Ranking Clarification Questions using Neural Expected Value of Perfect Information  
[2] What Do You Mean Exactly? Analyzing Clarification Questions in CQA  
[3] Answer-based Adversarial Training for Generating Clarification Questions 
[4] Tackling the story ending biases in the story cloze test 
[5] Diverse and Specific Clarification Question Generation with Keywords 
[6] AliCoCo: Alibaba E-commerce Cognitive Concept Net

[7] Answer-based Adversarial Training for Generating Clarification Questions 
[8] Diverse and Specific Clarification Question Generation with Keywords 
[9] Generating Clarifying Questions for Information Retrieval 
[10] Asking Clarifying Questions in Open-Domain Information-Seeking Conversations 
[11] Resolving Intent Ambiguities by Retrieving Discriminative Clarifying Questions 
[12] SynQG: Syntactic and shallow semantic rules for question generation 
[13] Learning to Ask Questions in Open-domain Conversational Systems with Typed Decoders 
[14] Diverse and Informative Dialogue Generation with Context-Specific Commonsense Knowledge Awareness

更多阅读

#投 稿 通 道#

 让你的论文被更多人看到 

如何才能让更多的优质内容以更短路径到达读者群体，缩短读者寻找优质内容的成本呢？答案就是：你不认识的人。

总有一些你不认识的人，知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁，促使不同背景、不同方向的学者和学术灵感相互碰撞，迸发出更多的可能性。 

PaperWeekly 鼓励高校实验室或个人，在我们的平台上分享各类优质内容，可以是最新论文解读，也可以是学习心得或技术干货。我们的目的只有一个，让知识真正流动起来。

???? 来稿标准：

• 稿件确系个人原创作品，来稿需注明作者个人信息（姓名+学校/工作单位+学历/职位+研究方向） 

• 如果文章并非首发，请在投稿时提醒并附上所有已发布链接 

• PaperWeekly 默认每篇文章都是首发，均会添加“原创”标志

???? 投稿邮箱：

• 投稿邮箱：hr@paperweekly.site 

• 所有文章配图，请单独在附件中发送 

• 请留下即时联系方式（微信或手机），以便我们在编辑发布时和作者沟通

????

现在，在「知乎」也能找到我们了

进入知乎首页搜索「PaperWeekly」

点击「关注」订阅我们的专栏吧

关于PaperWeekly

PaperWeekly 是一个推荐、解读、讨论、报道人工智能前沿论文成果的学术平台。如果你研究或从事 AI 领域，欢迎在公众号后台点击「交流群」，小助手将把你带入 PaperWeekly 的交流群里。