?PaperWeekly 原創(chuàng) ·?作者｜章志凌

學(xué)校｜上海交通大學(xué)碩士生

研究方向｜文本生成和知識(shí)圖譜

Clarification/clarifying question generation (CQGen)，是近年來文本生成研究領(lǐng)域興起的一個(gè)新方向。Clarification question 目前似乎還沒有很公認(rèn)的翻譯方式，而直接谷歌翻譯的結(jié)果是“澄清問題”，離它的實(shí)際含義實(shí)在相去甚遠(yuǎn)，所以自己斗膽給個(gè)譯名——闡明性問題。

自己最近在這一方向上進(jìn)行研究，有幸做出了一篇工作被 WWW 2021 錄用。不過本文旨在做一個(gè)領(lǐng)域的概覽，而不局限于本人的微小貢獻(xiàn)，幫助更多的研究者了解這一任務(wù)，并做出好的成果。?

那么闡明性問題到底是什么，為什么值得研究呢？先舉個(gè)栗子：?

▲ AskUbuntu上的CQ，圖源 [1]?

如上圖所示，很多人在問答或求助平臺(tái)上難以得到幫助，是因?yàn)樵谧约旱奶又胁]有包含足夠讓他人理解和解決問題的關(guān)鍵信息。如上例中的 ubuntu 版本信息，熟悉的人應(yīng)該都知道，不同版本的操作系統(tǒng)上很多東西都是不一樣的。好心的用戶也許會(huì)留下闡明性問題來提醒發(fā)帖人補(bǔ)充這些缺失的關(guān)鍵信息，從而使得發(fā)帖人的問題更可能得到解決。?

從上面的例子中，我們可以了解闡明性問題的含義：對(duì)上下文中缺失信息的提問。?

不過，既然我們?cè)诂F(xiàn)實(shí)生活中已經(jīng)有了人為的提問，為何我們還需要算法來生成這樣的問題呢？因?yàn)?#xff0c;提問畢竟比較耗費(fèi)精力，所以能夠得到這種提問的情況可能不會(huì)很多，更多的缺少信息的低質(zhì)量問題可能就此石沉大海。

有意思的是，即使在有人提出 CQ 的情況下，有研究發(fā)現(xiàn)，提問者往往最后也不會(huì)回答原始的問題 [2]，個(gè)人認(rèn)為原因也許是他們認(rèn)為這些問題的質(zhì)量很差，提出 CQ 并不是想要幫助解決問題，而只是一種情緒的發(fā)泄（問 ubuntu 的問題，連版本都不說？）。?

闡明性問題不止在問答平臺(tái)上存在，其形式可以很多樣，包括：?

• 淘寶，Amazon 等電商平臺(tái)上的顧客問題

• • 顧客會(huì)對(duì)商品描述中沒有講明白，而他們關(guān)心的一些具體細(xì)節(jié)提問

• 在搜索引擎中，搜索引擎通過提問指引用戶補(bǔ)充 query

• • 與下拉菜單中的搜索聯(lián)想不同，是提出了自然語(yǔ)言形式的問題來讓用戶提供反饋

• 對(duì)話系統(tǒng)乃至真人聊天中，一方說的話讓人捉摸不透，另一方可以通過提問讓 TA 闡明自己的想法或意圖

• • 通過這種方式也可以推進(jìn)現(xiàn)有話題，避免把天聊死，增加對(duì)話的長(zhǎng)度和深度

• 等等...?

這也揭示了它與傳統(tǒng)閱讀理解場(chǎng)景下的問題生成（QG）的區(qū)別：傳統(tǒng) QG 是對(duì)文章中已有答案的內(nèi)容提問（出題），從而考察做題人理解文章找到答案的能力。形式上，它是（上下文+答案）→（問題）的一個(gè)映射。

?

▲ 傳統(tǒng)QG的常用數(shù)據(jù)SQuAD的例子，Answer已經(jīng)存在于文中

而 CQGen，由于是對(duì)上下文缺失信息的提問，答案是不存在的，所以它是單獨(dú)的（上下文）→（問題）的一個(gè)映射，與最一般的文本生成相似。所以傳統(tǒng) QG 中利用 answer 的一些改進(jìn)思路在 CQGen 中不直接可用，而一般的文本生成方法在這個(gè)特定的 task 上也不能達(dá)到最好的表現(xiàn)。

CQ 的多樣內(nèi)涵使得這一任務(wù)中存在很多 domain-specific 的問題值得研究，相應(yīng)的也有很多有趣的思路被提出。?

不過在多樣的外衣下，這些研究也都會(huì)有共通之處，也就是這個(gè)問題的核心要害，只有向著這個(gè)核心進(jìn)發(fā)，才更容易做出有效的成果。我認(rèn)為，這個(gè)問題的核心就是：闡明性問題不僅只要滿足提問缺失信息，更重要的是要滿足信息需求。?

從上面的關(guān)系圖中可以看到：

• 傳統(tǒng)閱讀理解QG，只對(duì)于上下文中存在的信息進(jìn)行提問。

• 闡明性問題，根據(jù)定義，可以對(duì)于整個(gè)上下文信息的補(bǔ)集進(jìn)行提問。

• • 不過首先，我們至少應(yīng)該提問與上下文相關(guān)的信息。

  • 更進(jìn)一步，只有真正能幫助參與者滿足信息需求的問題，才是好的闡明性問題。

• 通用文本生成技術(shù)，廣泛應(yīng)用于翻譯，摘要等任務(wù)，也許能夠做到給出相關(guān)的信息，卻未必能夠很有針對(duì)性的解決信息需求。

所以，筆者嘗試給闡明性問題提供一個(gè)新的更具體的定義：闡明性問題是對(duì)缺失信息提問以滿足信息需求的問題。

因此，我認(rèn)為能夠在 CQG 上做出進(jìn)步的工作，往往是：

模型在信息需求上提供了有效的先驗(yàn)知識(shí)

或者通過一些方法使得模型更容易捕捉到信息需求相關(guān)的線索

下面，我就分成各個(gè)領(lǐng)域來介紹 CQG 上的一些近年來的代表性工作，并揭示它們的成功與上述核心問題之間的聯(lián)系。

寫作助手

我們就先從最上面的 AskUbuntu 的例子講起：?

這一場(chǎng)景最初在 [1] 中被提出，不過使用的是在已有的 CQ 問題池中 ranking 來選擇新的 post 的最佳問題的方法來解決的，可以說是一種 retrieval 的方法而不是 generation，而且 retrieval 有著明顯的局限性，所以在此不展開了。

同一團(tuán)隊(duì)的作者在 [3] 中提出了一種創(chuàng)新的 generation 方法（GAN-Utility）來解決這一問題。其思想的基本出發(fā)點(diǎn)是：一個(gè)好的 CQ，應(yīng)當(dāng)使其回答最有可能補(bǔ)全上下文中的缺失信息。

也就是說，生成器應(yīng)當(dāng)要有某種程度的“先見之明”，其提問方向要朝著最有建設(shè)性的方向出發(fā)。這恰好符合了我們上面概括的核心問題，就是在能夠生成的相關(guān)問題中，盡可能選擇最能夠滿足信息需求的問題進(jìn)行提問。

但是，一般的生成模型都使用最大似然進(jìn)行訓(xùn)練，能直接學(xué)到的不過是與訓(xùn)練數(shù)據(jù)的相似，又如何引入這種“先見之明”呢？作者想到了 RL，要是能夠把答案的最終功效作為 reward 來指引訓(xùn)練過程，也許就能夠達(dá)到這個(gè)目的。其具體方法如下圖所示：?

1. 為了預(yù)計(jì)答案的效果，我們首先要有答案，但是上面已經(jīng)強(qiáng)調(diào)，CQG 在實(shí)際應(yīng)用時(shí)是沒有答案的，所以，為了得到答案，作者同時(shí)用訓(xùn)練集中收集到的答案訓(xùn)練了一個(gè)答案生成模型。

2. 為了計(jì)算答案的最終功效，對(duì)于問題 Q，作者假設(shè)訓(xùn)練集中正確配對(duì)的 A 是有用的，而隨機(jī)配對(duì)的 A 是沒用的，從而通過訓(xùn)練一個(gè)判斷 QA 是否正確配對(duì)的模型，就能夠估計(jì) A 的功效。（Utility Calculator）。

3. 為了提升模型生成好答案的能力（并相應(yīng)地改進(jìn)問題生成），作者使用了 GAN 的思想，假設(shè)人的答案比機(jī)器生成的答案會(huì)更有用，所以通過 GAN 的 objective 來使得生成器生成更接近人的回答，就能夠得到更有用的答案。?

雖然我很贊同其基本出發(fā)點(diǎn)，但在此還要對(duì)其具體方法做一些批判：?

1. 按照 CQ 的定義，答案應(yīng)當(dāng)是不能從文中直接得到的。（雖然實(shí)際數(shù)據(jù)中，不能排除有人沒仔細(xì)看上下文就提了一個(gè)其實(shí)已經(jīng)被提及的問題。）所以，是否能夠訓(xùn)得出一個(gè)靠譜的 Answer Generator 是存疑的，作者在文中也沒有給出關(guān)于答案生成質(zhì)量的評(píng)價(jià)指標(biāo)和例子。

2. 功效計(jì)算沒有太大的問題，當(dāng)然也可以說配對(duì)的答案也不一定有用，不配對(duì)的答案也可能有用，不過這個(gè)問題不大。但是按照1，如果輸入的答案本身都是不好的，那么這個(gè)功效也沒什么用處。

3. 這里的 GAN 的假設(shè)有比較大的問題。實(shí)際上，即使機(jī)器學(xué)著模仿人的生成，其學(xué)習(xí)到的也未必是其有用的方面，而更有可能是其寫作風(fēng)格等。而人的寫作風(fēng)格和機(jī)器的寫作風(fēng)格是容易區(qū)分的，比如根據(jù)我自己的操作經(jīng)驗(yàn)，最顯著的一點(diǎn)就是人寫的答案的平均長(zhǎng)度要更長(zhǎng)。那么模型也許只要升成更長(zhǎng)的答案，就能夠更好地騙過 GAN。

由于作者的開源代碼存在 bug，我無法準(zhǔn)確地復(fù)現(xiàn)其結(jié)果，也就無法證實(shí)或證偽我上面的一些論斷。但盡管給出了很多批判，我還是覺得這個(gè)工作提出了一個(gè)很有意思的想法。?

它 [3] 也同時(shí)引出了一個(gè)新的 CQ 使用場(chǎng)景——Amazon 電商中的顧客問答（國(guó)內(nèi)可以拿淘寶的問答區(qū)類比）：?

這正是我的 WWW 工作:?Diverse and Specific Clarification Question Generation with Keywords?[5] 著手的場(chǎng)景。?

之前的工作，除了上面提到的技術(shù)上的局限性，它們也沒有對(duì)其在互聯(lián)網(wǎng)中的具體使用場(chǎng)景進(jìn)行討論。而在本文中，筆者認(rèn)為其問題設(shè)置和方法在實(shí)用中存在一些局限性：?

首先，多樣性不足（Diverse）。之前的方法都假設(shè)對(duì)一個(gè)上下文（商品描述）只生成一個(gè)問題；然而現(xiàn)實(shí)中顧客的信息需求是很多樣化的，就像有個(gè)商品的問答區(qū)會(huì)有上百個(gè)問題一樣（在本文和 [3] 使用的數(shù)據(jù)集上，平均問題數(shù)量是 7）。只有一個(gè)問題顯然不足以滿足那么多的多樣化需求。

?
然后，生成的問題不夠具體（Specific）。傳統(tǒng)的 MLE 訓(xùn)練的文本生成模型往往傾向于生成簡(jiǎn)短而通用的 CQ（如：What are the dimensions？，即尺寸是多少）這類問題確實(shí)在很多情況下是有用的。

然而，更多時(shí)候，用戶的具體化的需求并不能被這類 general 的問題覆蓋，就比如上圖中的 induction compatible 的問題，就是用戶在帶電環(huán)境下使用金屬制品可能會(huì)產(chǎn)生的具體信息需求。

其不像上面的尺寸問題幾乎可以套用在所有商品上，但只要問得精準(zhǔn)，其價(jià)值也更高，因?yàn)橄癯叽邕@樣的共性問題更容易被考慮到，直接用加進(jìn)參數(shù)表要求所有商品都填一下，就能夠替代自然語(yǔ)言問題了。（事實(shí)上，現(xiàn)在 Amazon 已經(jīng)在參數(shù)表中要求填寫尺寸了。數(shù)據(jù)集中還包含大量尺寸問題，可能是因?yàn)閿?shù)據(jù)集比較老，當(dāng)時(shí)沒有類似要求）。?

再加上，前述工作只是提出了這樣一個(gè)技術(shù)問題，卻明沒有明確怎樣在實(shí)際產(chǎn)品中使用這一技術(shù)。

綜上，筆者提出了一種寫作助手的設(shè)計(jì)，其能夠在商家撰寫產(chǎn)品描述時(shí)，對(duì)于目前上下文中可能存在的缺失信息，提出多樣和具體的闡明性問題。

如上圖所示，對(duì)于出售華夫餅機(jī)的商家，當(dāng)他撰寫完一版介紹的草稿時(shí)，可以點(diǎn)擊 “Question” 按鍵向?qū)懽髦终?qǐng)求闡明性問題。而圖中已經(jīng)展示出了系統(tǒng)提出的 3 個(gè)問題，分別從電壓、尺寸和功率三個(gè)不同層面進(jìn)行了提問，且確實(shí)是上下文中沒有涵蓋到的信息，則商家可以利用各種方法（手頭的資料、通過自己的測(cè)量，或與生產(chǎn)商聯(lián)系）得到這些信息，再補(bǔ)充到描述中。直到信息完整后，按 “Confirm” 確認(rèn)。這樣的寫作助手輔助補(bǔ)充完整的產(chǎn)品描述，更可能預(yù)防因?yàn)轭櫩驼也坏阶约宏P(guān)心的信息而流失的情況。

系統(tǒng)設(shè)計(jì)完成，其背后的算法也仍需改進(jìn)。為了解決前述兩大技術(shù)難題，本文提出了基于 Keyword Prediction and keyword-Conditioned generation 的算法，簡(jiǎn)稱 KPCNet。

為了解決具體性的問題（Specificity）。我們發(fā)現(xiàn)在電商場(chǎng)景中，闡明性問題的具體成分主要是其中的關(guān)鍵詞（非停用詞的名詞、動(dòng)詞、形容詞），舉例如下（下劃線為關(guān)鍵詞，粗體為強(qiáng)調(diào)）：?

• 類別、屬性：What is the voltage of the machine?

• 產(chǎn)品的組件和部分：Is the blade of the food grinder made of stainless steel?

• 與產(chǎn)品相關(guān)的使用體驗(yàn)：Can I cook rice in the cooker?

如果能夠讓生成模型更有針對(duì)性地生成產(chǎn)品相關(guān)的具體關(guān)鍵詞，那么它就應(yīng)當(dāng)可以生成更具體的問題。?

為了得到產(chǎn)品相關(guān)的具體關(guān)鍵詞，我們訓(xùn)練了一個(gè)關(guān)鍵詞預(yù)測(cè)模型，輸入商品描述，預(yù)測(cè)它的所有 CQ 中可能會(huì)出現(xiàn)的關(guān)鍵詞（一個(gè)multi-label classification問題）。?

• 注意與前一個(gè)工作不同，此處我們預(yù)測(cè)的是 CQ 中的關(guān)鍵詞，而不是其答案。從商品描述中預(yù)測(cè)“對(duì)電壓提問”要比起預(yù)測(cè)“電壓是 220V”的答案更有可能?

得到預(yù)測(cè)結(jié)果后，我們將預(yù)測(cè)到的關(guān)鍵詞信息輸入 seq2seq 模型，使其指導(dǎo)模型的生成。這樣，以輸入的關(guān)鍵詞作為條件，模型就更可能會(huì)生成這些關(guān)鍵詞，會(huì)與這些關(guān)鍵詞有語(yǔ)義相關(guān)的內(nèi)容，從而賦予 CQ Specififity。?

為了解決多樣性的問題（Diversity）。我們利用了 KPCNet 中關(guān)鍵詞對(duì)模型的控制性，只要提供不同的關(guān)鍵詞作為條件，就能夠給出不同的生成結(jié)果。那么，多組關(guān)鍵詞從哪里來？在上述的關(guān)鍵詞預(yù)測(cè)模型中，由于同一個(gè)產(chǎn)品對(duì)應(yīng)多個(gè)問題，所以預(yù)測(cè)的關(guān)鍵詞中實(shí)際上已經(jīng)包括了出現(xiàn)在多個(gè)問題中的關(guān)鍵詞集合，所以我們只要把預(yù)測(cè)結(jié)果中的關(guān)鍵詞加以適當(dāng)?shù)木垲?#xff0c;將最可能出現(xiàn)在一個(gè)問題中的關(guān)鍵詞聚到一組中。那么再基于這幾個(gè)聚類分別生成問題，就能夠生成多樣且合理的闡明性問題了。?

結(jié)果舉例如下：?

ref 是數(shù)據(jù)集中的參考問題，下面兩個(gè)方法是 baseline，而最下面是我們的 KPCNet 方法。可以看到我們的方法在多樣性和具體性上相對(duì) baseline 具有一定的優(yōu)勢(shì)，但離人還有一定的距離。

提出方法時(shí)，筆者還沒有從上述概括的核心問題（信息需求）的角度思考。回過頭來看，KPCNet 能 work 的原因其實(shí)也與之有關(guān)。實(shí)際上，正是因?yàn)?KPCNet 中限定的關(guān)鍵詞集合（千數(shù)量級(jí)）實(shí)際上是一種關(guān)于信息需求的先驗(yàn)知識(shí)，相比于寬泛生成詞匯表（萬(wàn)數(shù)量級(jí)），它會(huì)更加專注于信息需求，所以它才能比普通的 MLE 和沒有明確“需求導(dǎo)向”的多樣生成 baseline hMup 生成更好更準(zhǔn)的問題。

但也從這個(gè)角度出發(fā)，也可以解釋本文方法的一些局限性，在此做出一些自我批判：

• 關(guān)鍵詞集合還不夠精確，其中除了信息需求，還存在一些冗余。比如 KPCNet 生成的結(jié)果中經(jīng)常會(huì)重復(fù)商品本身的類別，這固然不錯(cuò)，但也無用，甚至可能反而分散了模型應(yīng)當(dāng)分配到其他需求類關(guān)鍵詞上的“注意力”（非 attention mechanism，只是個(gè)不精確的比喻）。

• 關(guān)鍵詞的粒度較小，不能夠很好地描述詞組級(jí)、短句級(jí)的更長(zhǎng)的需求。雖然關(guān)鍵詞可以通過組合描述長(zhǎng)的需求（比如 cook rice, stainless steel），但畢竟不是最優(yōu)的方案。如 AliCoCo [5] 這樣的更加具體且直接定位需求的電商知識(shí)圖譜，也許可以成為先驗(yàn)知識(shí)的更佳來源。

再加上 keyword predictior 目前還不能做到很精確，使得本文的方法依然存在一些局限性。筆者認(rèn)為，本文類似的框架，如果有工業(yè)界的力量，能夠結(jié)合更精準(zhǔn)定位需求的知識(shí)圖譜，獲取更多的 metadata 來準(zhǔn)確預(yù)測(cè)關(guān)鍵詞/需求，還能夠大大改進(jìn)目前 CQGen 這個(gè)任務(wù)上的表現(xiàn)。因此，也希望這一研究問題得到更多關(guān)注，繼續(xù)進(jìn)步，走向?qū)嵱谩?

CQGen 在其他領(lǐng)域和任務(wù)上也有很多有意思的工作，我們接下來繼續(xù)展開。?上個(gè)章節(jié)提到：闡明性問題是對(duì)缺失信息提問以滿足信息需求的問題。

我認(rèn)為能夠在 CQG 上做出進(jìn)步的工作，往往是：

?

1. 為模型在信息需求上提供了有效的先驗(yàn)知識(shí)；

2. 或者通過一些方法使得模型更容易捕捉到信息需求相關(guān)的線索。

筆者重點(diǎn)介紹了改進(jìn)文章的寫作助手這一防線。我認(rèn)為其中的 GAN-Utility [7] 的思路可以歸到上述的 (2)，而本人的 KPCNet [8] 則屬于 (1) 的思路。CQGen 在其他領(lǐng)域和任務(wù)上也有很多有意思的工作，這些工作的優(yōu)點(diǎn)也與上述 CQ 的核心問題密切相關(guān)，下面繼續(xù)展開：

信息檢索/搜索引擎?

搜索引擎的使用場(chǎng)景中，由于完整表達(dá)需求比較困難和麻煩，用戶輸入的 query 往往是很短的。這就使得 query 指向的意圖往往是有歧義的，需要我們來做闡明。?

實(shí)際上，搜索引擎已經(jīng)有搜索詞補(bǔ)充推薦，還有頁(yè)底的相關(guān)搜索等方式來幫助用戶闡明其實(shí)際需求，但卻沒有直接自然語(yǔ)言提出問題的例子（在下面這篇研究之前）。?

那么搜索引擎中的 CQGen 到底如何做，如何融入產(chǎn)品設(shè)計(jì)，做了又有什么用？讓我們來看看微軟 bing 團(tuán)隊(duì)的這篇工作 [9]：?

2.1 Generating Clarifying Questions for Information Retrieval

Bing 團(tuán)隊(duì)設(shè)計(jì)了如上圖所示的 clarification panel。其中有根據(jù)搜索內(nèi)容（query）生成的闡明性問題，且為了交互的方便，還提供了幾個(gè)可以直接點(diǎn)擊選擇的答案。選擇了答案以后，相應(yīng)的詞就被擴(kuò)展到現(xiàn)有的搜索框中，下方的搜索結(jié)果也就相應(yīng)的變得更加精準(zhǔn)。?

為了驗(yàn)證這種設(shè)計(jì)的收益，研究者進(jìn)行了找到了一些志愿者進(jìn)行用戶測(cè)試，結(jié)果發(fā)現(xiàn)用戶對(duì)這一設(shè)計(jì)的評(píng)價(jià)很高。他們認(rèn)為這個(gè)設(shè)計(jì)一方面能夠指導(dǎo)他們更精確的找到自己的需求（看來用戶在搜索的時(shí)候可能有時(shí)候也不知道自己想搜什么）。

另一方面，心理上也讓用戶感覺搜索引擎更懂他們的需求，對(duì)其更加放心。比如想要通過搜索對(duì)電器進(jìn)行比較時(shí)，他們可以依賴上述 CQ 的推薦出來的電器的各個(gè)屬性去搜索，而不用擔(dān)心自己遺忘了比較哪個(gè)方面。?

這一設(shè)計(jì)與搜索引擎的其他功能在一起讓用戶評(píng)分，結(jié)果發(fā)現(xiàn)它是最受歡迎的功能，超越了功能上相近的相關(guān)搜索和實(shí)體卡片等（見下圖）。?

那么，這樣的問題和答案又是如何生成的呢？下面我們來討論其方法：?

為了挖掘出有歧義的短 query 背后可能的明確意圖，他們使用了 query reformulation 的數(shù)據(jù)。即，用戶發(fā)現(xiàn)第一次搜索的結(jié)果不夠理想，然后接著對(duì)原 query 進(jìn)行的修改。

如想要搜女款跑鞋的用戶先搜了“running shoes”，然后又加上了“woman”一詞，這就是一次 query reformulation，記為 running shoes -> woman（還可以包括總體的頻率，刻畫這種變換是否常見）。

由于 reformulation 中的更新詞往往是原始 query 實(shí)體（entity）的一個(gè)方面，其被記為 aspect，它們將成為 entity 觸發(fā)的問題的答案。?

有了上面的 query 和 entity，他們首先設(shè)計(jì)了若干問題模板用于生成：?

其中 QUERY_ENTITY_TYPE 和 ASPECT_ENTITY_TYPE 從網(wǎng)絡(luò)語(yǔ)料中使用信息抽取方法獲得。這樣就可以生成一些固定模式的問題了。然而這些固定模式的 CQ 還是有些生硬，并且由于不是每個(gè)實(shí)體都能找到合適的類別名，限制了其泛化能力。所以他們又進(jìn)一步提出了一種使用神經(jīng)網(wǎng)絡(luò)的生成方法，把上述模板生成的問題作為一種弱監(jiān)督方式（即學(xué)習(xí)目標(biāo)），以 query 和對(duì)應(yīng)的若干 Aspect 作為輸入，組成一種 seq2seq 模型。其結(jié)構(gòu)如下圖：?

由于這個(gè)模型在訓(xùn)練中能夠見到未被 ENTITY/ASPECT_TYPE 覆蓋到的 aspect，所以他們認(rèn)為這個(gè)模型能夠從存在類型名和實(shí)體/方面配對(duì)的訓(xùn)練數(shù)據(jù)中學(xué)習(xí)，更好地泛化到類型名不可得的情況。?

為了進(jìn)一步提升答案的可能功效，他們還借鑒了 [7] 的思想，使用 RL 來提升訓(xùn)練結(jié)果的 Utility，從而進(jìn)一步提升了生成質(zhì)量。具體細(xì)節(jié)較為復(fù)雜，在此不加以展開。?

最后再?gòu)男畔⑿枨蟮慕嵌葋砜疾爝@個(gè)方法。實(shí)際上，這一方法中至關(guān)重要的地方就是：利用 query reformulation 的數(shù)據(jù)，提供了模糊 query 對(duì)應(yīng)的具體需求的一種先驗(yàn)知識(shí)。?

除了傳統(tǒng)搜索引擎以外，語(yǔ)音/對(duì)話搜索也面臨著歧義 query 的挑戰(zhàn)，因?yàn)橐痪湓捘軌虬男畔⒁彩怯邢薜摹Ｏ旅孢@篇文章重點(diǎn)討論了這種場(chǎng)景：

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

上圖中，兩人提供的搜索詞都是 dinosaur，但是其真實(shí)需求（Information Need/Facet）不盡相同，這一對(duì)話式搜索系統(tǒng)能夠通過提問闡明性問題和用戶的反饋（一段話，可能有答案，也可能是不確定），探明用戶的實(shí)際需求，并給出相關(guān)結(jié)果。?

這一問題相當(dāng)困難，本文實(shí)際上只給出了一個(gè)簡(jiǎn)化的設(shè)定，建立了一個(gè)有人工標(biāo)注的（query，information need，相關(guān)/不相關(guān)問題）配對(duì)的數(shù)據(jù)集，然后給定算法可見的 query 和算法不可見的 information need，讓算法在給定的候選問題集 rank 出能夠闡明實(shí)際信息需求的問題，在此不展開敘述了。但這也是一個(gè)很有趣和有用的場(chǎng)景，期待能夠看到這方面的更多進(jìn)展。?

對(duì)話系統(tǒng)?

上面的語(yǔ)音搜索已經(jīng)很接近對(duì)話的概念。實(shí)際上，對(duì)話系統(tǒng)中需要闡明信息的情況也非常普遍。?

對(duì)話系統(tǒng)可以分為任務(wù)型對(duì)話系統(tǒng)（Task-oriented Dialogue System）和開放域?qū)υ捪到y(tǒng)（Open-domain Dialogue Systems, Chatbot）。其中前者被限制在完成特定的任務(wù)中，一般的實(shí)現(xiàn)方式是，把用戶的 query 解析到預(yù)定義的一些意圖和槽中，然后系統(tǒng)根據(jù)這些解析的信息調(diào)整對(duì)話狀態(tài)，并作出相應(yīng)的行為。而開放域?qū)υ捪到y(tǒng)則可以自由閑聊。?

在二者中，闡明性問題都是其中的重要組成部分。有的工作把 CQGen 的生成包括在了整體系統(tǒng)中而不加以單獨(dú)討論（大體來說，就是一個(gè)通用的文本生成系統(tǒng)就可以生成陳述句和問題，其中的一部分生成結(jié)果可能就是 CQ；或者 CQ 只是很多種預(yù)定義的回復(fù)類型的其中一種）；而有的工作則是將其作為單獨(dú)的部分來討論，我們主要來聊聊后者。?

先是任務(wù)型對(duì)話系統(tǒng)，主要介紹這篇工作?[11]。

3.1 Resolving Intent Ambiguities by Retrieving Discriminative Clarifying Questions?

上圖顯示了一個(gè)銀行對(duì)話系統(tǒng)對(duì)歧義輸入的處理。紅框中，系統(tǒng)錯(cuò)把用戶想開 checking account 的意圖當(dāng)成了開 saving account，使得用戶很不滿意。而一個(gè)理想的系統(tǒng)應(yīng)該像綠框中一樣，如果發(fā)現(xiàn)輸入中存在歧義，就先提出闡明性問題來解決它，然后再給出正確的服務(wù)。這樣的系統(tǒng)顯然能夠更準(zhǔn)確的解決用戶的需要，并且和上面搜索引擎的例子一樣，可以讓系統(tǒng)顯得更智能，讓用戶信任。?

那么這樣的系統(tǒng)如何實(shí)現(xiàn)呢？它可以拆分為如下的步驟（如下圖所示）?

1. 訓(xùn)練一個(gè)意圖分類器，能夠把用戶的輸入分類到某種預(yù)定義的意圖上

與傳統(tǒng)模型不同的是，這里的分類器還將用來判斷問題是否存在歧義。如果輸入本身已經(jīng)足夠清晰，那么當(dāng)然沒有必要進(jìn)行提問。這樣就實(shí)現(xiàn)了準(zhǔn)確性和效率的平衡。

不過其判斷歧義的方法并不復(fù)雜：如果預(yù)測(cè)概率最高的一類意圖的概率小于某個(gè)給定的閾值，則認(rèn)為這個(gè)輸入是存在歧義的，而如果概率最高的兩類意圖之間的概率差小于某個(gè)給定閾值（即模型對(duì)二者的預(yù)測(cè)都不自信），則認(rèn)為在這兩類之間存在歧義。?

2. 基于意圖類對(duì)應(yīng)的訓(xùn)練語(yǔ)料中的用戶輸入，使用規(guī)則方法生成問題-答案對(duì)

訓(xùn)練集中已經(jīng)存在著一些（無歧義的）用戶輸入，被人工標(biāo)注了對(duì)應(yīng)的意圖。比如“I want to open a checking account.“ 的意圖就是”opening_a_checking_account”。?

假設(shè)模型預(yù)測(cè)其中一個(gè)歧義意圖就是“opening_a_checking_account”，則提問 CQ 后，與數(shù)據(jù)集中的同類意圖下的現(xiàn)有用戶輸入（Open a checking account）相似的回答會(huì)是對(duì)我們的消歧很有幫助的信息。

為了讓用戶針對(duì)這些要點(diǎn)進(jìn)行回答，我們?cè)谶@句無歧義的話上使用一種傳統(tǒng) QG 技術(shù)生成問題-答案對(duì)。這里使用的是 SynQG [12]，基于句法解析，規(guī)則映射和模板的一套無監(jiān)督問題生成方法。這樣無需任何訓(xùn)練語(yǔ)料，我們就能生成類似（What do you want to do? Open a checking account）這樣的問答對(duì)。?

每類意圖中的每句話都使用上述方法生成問答對(duì)，形成對(duì)應(yīng)問答集，備用于下一步。?

3. 對(duì)于一對(duì)存在歧義的意圖，在其對(duì)應(yīng)的問答集中，選擇其中與輸入最相關(guān)且最有判別力的一對(duì)問答?

其中的評(píng)分依據(jù)包括：

• 兩個(gè)意圖的對(duì)應(yīng)問題越接近越好

• 兩個(gè)意圖的對(duì)應(yīng)問題的答案越有區(qū)別越好

• 兩個(gè)意圖的對(duì)應(yīng)問題都與當(dāng)前用戶輸入越接近越好

以上的相似度都可以用預(yù)訓(xùn)練的 sentence-encoder 得到的 sentence embedding 計(jì)算 cosine similarity 得到。

4. 將選擇的一對(duì)問答進(jìn)行組合，形成最終的闡明性問題

由于 SynQG 生成的問題的上下文與當(dāng)前的上下文不完全匹配，所以作者設(shè)計(jì)了一系列的規(guī)則對(duì)其加以調(diào)整以適用于當(dāng)前上下文，并使用了 back-translation 改進(jìn)問題語(yǔ)法質(zhì)量。

?
而當(dāng)規(guī)則也不能覆蓋時(shí)，作者使用了模板方法，有一系列例如“Are you talking about DP_j or DP_k？”的模板，其中 DP_i 是意圖 i 的有區(qū)分力的詞組，套入具體值來生成問題。?

從信息需求/意圖的角度來看，本文同時(shí)做好了兩件事情：

任務(wù)型對(duì)話系統(tǒng)中預(yù)定義的意圖集合為信息需求提供了限制范圍的先驗(yàn)知識(shí)，這個(gè)小范圍內(nèi)的問題更容易處理。

挑選有判別力的一對(duì)問答這一步，為生成最有可能解決滿足信息需求的問題提供了基礎(chǔ)。因?yàn)楸疚闹械腃Q簡(jiǎn)化設(shè)定都是二選一式的疑問句，所以在這里，找最可能滿足信息需求的問題的任務(wù)，可以被規(guī)約到找最有判別力的一對(duì)問答。

綜上，我認(rèn)為本文的方法在這里的 CQGen 任務(wù)上效果應(yīng)該是挺不錯(cuò)的。不過本文的問題設(shè)定，無論是任務(wù)式對(duì)話系統(tǒng)本身，還是 CQ 的選擇疑問句形式，相對(duì)于 DSTC 類的經(jīng)典設(shè)定都是比較簡(jiǎn)化的，這可能會(huì)限制其應(yīng)用范圍。?

在開放域?qū)υ捪到y(tǒng)中，CQ 一般不被單獨(dú)討論，但是實(shí)際上其中的問題大部分可以認(rèn)為是 CQ。我們使用 [13] 中的例子來討論一下：?

上圖展示了兩個(gè)閑聊場(chǎng)景。第一個(gè)例子中，用戶可能對(duì)自己的身材體重不是很滿意（所以可能會(huì)有減肥的想法 不，減肥是不可能的），而對(duì)話系統(tǒng)就提出了一起登山運(yùn)動(dòng)的提議。這一提議并沒有出現(xiàn)在上下文中，但是卻“可能”迎合了減肥的需求。第二個(gè)例子也類似，用戶提起 KTV 這個(gè)事件，可能沒有明確提及、或者沒有想到自己的需求，但潛意識(shí)里也許就是想要分享唱歌的感受，需要一個(gè)情商高的捧哏 bot 把話題延續(xù)下去~?

CQ 在對(duì)話系統(tǒng)中一般不被單獨(dú)討論的原因，個(gè)人認(rèn)為，一方面是這個(gè)名詞的認(rèn)知度不是很高，更重要的另一方面單獨(dú)研究這一個(gè)模塊可能沒有很大的意義，尤其是與近年來流行的 end2end 對(duì)話系統(tǒng)（Meena, Blender, Plato-2 等）對(duì)比:?

首先，以單獨(dú)的問題生成模塊來處理問題，意味著要把它應(yīng)用于對(duì)話系統(tǒng)，就必須使用多模塊的流水線系統(tǒng)，其中還要包括一個(gè)判斷是否需要 CQ 的模塊，這在工程實(shí)踐上是比較復(fù)雜的。而 end2end 系統(tǒng)能夠在無限制的自然語(yǔ)言生成時(shí)自動(dòng)、隱式地選擇是否進(jìn)行提問。

另外，問題生成模塊單獨(dú)訓(xùn)練，其可以利用的語(yǔ)料也不如 end2end 的考慮所有情況的語(yǔ)料來得豐富，所以其效果可能也不夠好。

綜上，我認(rèn)為僅考慮單獨(dú)的問題生成模塊的問題設(shè)定，在 chatbot 系統(tǒng)中可能不太利于實(shí)踐。?

不過，在開放域?qū)υ捴猩申U明性問題也還是可能構(gòu)成一個(gè)有挑戰(zhàn)性的技術(shù)問題，作為對(duì)話系統(tǒng)的部分，其解決問題的思路還是可以為改進(jìn)整體對(duì)話系統(tǒng)提供啟發(fā)。

按照 CQGen 核心問題的思路，要想在這里利用知識(shí)提供信息需求方面的先驗(yàn)。那么應(yīng)用的知識(shí)就要足夠廣泛和普遍，我認(rèn)為近年來得到大量關(guān)注的常識(shí)知識(shí)（本人所在的 ADAPT 實(shí)驗(yàn)室有過一些整理）大概就是一個(gè)很好的選項(xiàng)。近年來也有利用常識(shí)知識(shí)的相關(guān)工作，比如 [14]，是將其應(yīng)用在一個(gè)整體的對(duì)話系統(tǒng)中，效果也很好。

總結(jié)

本文中，筆者嘗試概括了闡明性問題生成的核心問題，并基于此引出一個(gè)定義：闡明性問題是對(duì)缺失信息提問以滿足信息需求的問題。然后，基于此視角考察了寫作助手，信息檢索，對(duì)話系統(tǒng)中 CQGen 的方法與應(yīng)用。

這些例子都向我們說明，CQGen 中能夠做出進(jìn)步的工作，一般是為模型在信息需求上提供了有效的先驗(yàn)知識(shí)，或者通過一些方法使得模型更容易捕捉到信息需求相關(guān)的線索。

所以，我認(rèn)為未來有希望的研究方向，是找到 CQGen 可以適當(dāng)應(yīng)用的場(chǎng)景，深入考察其中涉及的信息需求，并相應(yīng)構(gòu)建知識(shí)來提供有用的先驗(yàn)；或者探索一些技術(shù)方法來讓模型能更好地理解信息需求。?

篇幅所限，還有一些 CQ 相關(guān)的文章不能詳加論述，在此再附上一些，有興趣的讀者可以參考：

• 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

參考文獻(xiàn)

[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

更多閱讀

#投 稿?通 道#

?讓你的論文被更多人看到?

如何才能讓更多的優(yōu)質(zhì)內(nèi)容以更短路徑到達(dá)讀者群體，縮短讀者尋找優(yōu)質(zhì)內(nèi)容的成本呢？答案就是：你不認(rèn)識(shí)的人。

總有一些你不認(rèn)識(shí)的人，知道你想知道的東西。PaperWeekly 或許可以成為一座橋梁，促使不同背景、不同方向的學(xué)者和學(xué)術(shù)靈感相互碰撞，迸發(fā)出更多的可能性。?

PaperWeekly 鼓勵(lì)高校實(shí)驗(yàn)室或個(gè)人，在我們的平臺(tái)上分享各類優(yōu)質(zhì)內(nèi)容，可以是最新論文解讀，也可以是學(xué)習(xí)心得或技術(shù)干貨。我們的目的只有一個(gè)，讓知識(shí)真正流動(dòng)起來。

?????來稿標(biāo)準(zhǔn)：

? 稿件確系個(gè)人原創(chuàng)作品，來稿需注明作者個(gè)人信息（姓名+學(xué)校/工作單位+學(xué)歷/職位+研究方向）?

? 如果文章并非首發(fā)，請(qǐng)?jiān)谕陡鍟r(shí)提醒并附上所有已發(fā)布鏈接?

? PaperWeekly 默認(rèn)每篇文章都是首發(fā)，均會(huì)添加“原創(chuàng)”標(biāo)志

?????投稿郵箱：

? 投稿郵箱：hr@paperweekly.site?

? 所有文章配圖，請(qǐng)單獨(dú)在附件中發(fā)送?

? 請(qǐng)留下即時(shí)聯(lián)系方式（微信或手機(jī)），以便我們?cè)诰庉嫲l(fā)布時(shí)和作者溝通

????

現(xiàn)在，在「知乎」也能找到我們了

進(jìn)入知乎首頁(yè)搜索「PaperWeekly」

點(diǎn)擊「關(guān)注」訂閱我們的專欄吧

關(guān)于PaperWeekly

PaperWeekly 是一個(gè)推薦、解讀、討論、報(bào)道人工智能前沿論文成果的學(xué)術(shù)平臺(tái)。如果你研究或從事 AI 領(lǐng)域，歡迎在公眾號(hào)后臺(tái)點(diǎn)擊「交流群」，小助手將把你帶入 PaperWeekly 的交流群里。

總結(jié)

以上是生活随笔為你收集整理的阐明性问题生成 (Clarification Question Generation) 概览的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。