?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 上做出進步的工作，往往是：

模型在信息需求上提供了有效的先驗知識

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

下面，我就分成各個領域來介紹 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 的有區分力的詞組，套入具體值來生成問題。?

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

任務型對話系統中預定義的意圖集合為信息需求提供了限制范圍的先驗知識，這個小范圍內的問題更容易處理。

挑選有判別力的一對問答這一步，為生成最有可能解決滿足信息需求的問題提供了基礎。因為本文中的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 的交流群里。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。