2021 CIKM

1 intro

• 根據貝恩公司（Bain & Company）2019年的一份報告，旅行者在預訂前通常會進行33至500次網頁搜索????????
  • 部分用戶會訪問超過50個旅游網站，三分之一的上網時間都用于與旅行相關的活動。
  • 在某些情況下，他們甚至會在旅游論壇上發帖，希望從其他用戶那里獲得個性化的旅游信息。
• TripAdvisor 在2016年報告稱，其旅游論壇每年新增的帖子超過90萬個。

• 論文引入了一個新的任務：使用旅游評論集合回答興趣點（POI）推薦類問題
  • 要求模型在包含諷刺、矛盾觀點等內容的評論中進行推理，同時還需處理涉及其他實體的提及（如對比性描述）
    • 因此，該任務的推理方式與典型的機器閱讀理解任務、蘊含推理任務或常識推理任務有本質不同
  • 此外，問題可能還涉及地理位置、預算、時間安排以及氛圍、服務質量等主觀因素
  • 并且，并非問題中的所有部分都與最終回答相關，使得識別信息需求本身也變得具有挑戰性。

• 可擴展性挑戰
  • 該任務的問題面臨巨大的候選答案空間，例如一個城市中可能有數千個 POI，每個 POI 都由數百條評論構成
  • 為了在 QA 任務中應對規模化推理的挑戰，現有模型通常采用“檢索器-排序器”架構，先使用 BM25 等方法過濾文檔縮小搜索空間，然后再在縮減后的集合上應用更深層的推理模型
  • 同時，一些方法也會利用文檔結構提取關鍵信息，或將文檔截斷至前 800–1000 個 token 來提升計算效率
  • 但這些策略在我們的任務中并不奏效
    • 基于 TF-IDF 的搜索空間剪枝效果不佳
      • 任務中的文檔是評論，包含大量觀點表達，因此在詞匯層面上非常相似，導致 TF-IDF 分數分布非常相近
      • 論文任務中紐約市餐廳的評論文檔之間平均 TF-IDF 余弦相似度為 0.35，而在SQuAD數據集中訓練樣本段落的相似度僅為 0.05
    • 截斷評論文檔會導致重要信息丟失：
      • 由于 POI 的評論往往是“評論包”（bag-of-reviews）形式，直接截斷或交叉注意力計算對這些文檔不適用

• 構建了一個新的數據集
  • 從在線旅游論壇中提取了 47,124 個問答對
  • 其中每個問題對應一個答案實體 ID
    • 該實體在從 Web 上收集的 超過 20 萬份實體評論文檔 中。
• 提出了基于 Cluster-Select-Rerank 的 CsrQA 模型

2 數據收集

• 目前大多數問答（QA）數據集都是通過眾包工人構建的
  • 使用人工眾包創建 QA 數據集的成本極高
  • ——>論文選擇通過旅游論壇和評論集合自動收集數據集
    • ???????首先爬取了旅游論壇上的帖子及其相應的對話，同時收集了包括發帖時間和日期在內的元數據
    • 隨后爬取了各城市中餐館和景點的評論數據，這些評論同樣來自一個主流旅游論壇
      • 酒店評論則來自一個熱門的酒店預訂網站
      • 也收集了可用的實體元數據，如地址、評分、設施等信息

2.1?問題過濾

• 除了真正的問題，論壇用戶還會發布旅行總結、旅游服務反饋、以及一些開放性但不涉及實體查詢的問題（如天氣、經濟狀況等）
  • 基于關鍵詞和元數據設計了高精度的規則來過濾這些帖子
  • 此外，移除了論壇中被顯式標注為“旅行報告”或“不當內容”的帖子
  • 過長的問題（長度超過平均長度的1.7倍）也被剔除，因為它們通常是其他類型的內容，如投訴或行程安排

2.2?答案提取

• 首先為每個城市建立了一個實體名稱列表
  • 用這個列表在用戶對論壇帖子的回復中查找實體提及
• 每個實體還會被打上一個高層類別標簽（如酒店、餐廳、景點），這些標簽依據其來源頁面自動分配
  • 如果一個實體同時屬于多個類別，例如某家因歷史意義而被歸類為景點的酒店，那么該實體會分別作為“酒店”和“景點”出現，并對應獨立的評論集合
• 對用戶的回答進行詞性標注，并對識別出的名詞使用模糊匹配方法在實體列表中進行查找（以適應拼寫錯誤）
  • 這一過程生成了一組帶噪聲的“銀標準”答案實體（silver answer entities），即從自由文本中自動提取的潛在答案
  • 接下來對這些銀標準答案進行一系列精度提升步驟，最終生成“金標準”問答對（gold QA pairs）

2.3?銀標準答案實體過濾

2.3.1?基于類型的過濾

• 首先使用多句理解組件來識別問題中可能表示目標實體“類型”或“屬性”的短語
  • 
  • 在圖1的問題中，“place to eat”會被標記為 entity.type，“has vegetarian options as well” 被標記為 entity.attribute。
• 從論壇中收集的所有實體都帶有標簽（總共約210種）
  • 餐廳標注了菜系
  • 景點標注為博物館、公園等
  • 酒店則標注為“酒店”。

• 將這些標簽手動歸類為11個簇（clusters）
  • 在一個問題中，提取出表示 entity.type 的短語，并通過嵌入表示找到其最相近的簇
    • 即將（"place to eat"）用 句向量?表示，然后與那11個預定義簇的表示向量進行比較，選出最相近的一個簇
  • 同樣地，對于每個銀標準實體，根據其元屬性中命中的標簽頻率確定其所屬簇
    • response中被提取出來的“銀標準實體”（比如 “Promenade Mall”），都有一些元屬性標簽（如 "shopping mall", "entertainment", "family-friendly"）；
    • 這些標簽原本屬于那210種中的若干
    • 統計它的標簽分別命中了哪個簇中的標簽最多，比如：
      ?

      • Promenade Mall → 命中 “mall” 類標簽較多 → 屬于 mall 簇；

      • PLATE 餐廳 → 命中 “restaurant” 標簽 → 屬于 restaurant 簇。

• 如果問題類型簇與實體類型簇不匹配，該 QA 對將被丟棄。
  • 例如，在圖1中，答案實體 Promenade Mall 和 Ambience Mall 類型不匹配，因而被剔除。
    • 用戶的問題是想找一個**“place to eat”（吃飯的地方），也就是他們想找的是一個餐廳類（restaurant）**的 POI
    • 而系統在處理論壇回復、自動提取候選答案時，發現一些用戶提到的實體（如 Promenade Mall 和 Ambience Mall）雖然出現在回答中，但它們的類型是購物中心（mall），不是餐廳。

2.3.2?基于同類比較的過濾（Peer-based filtering）

• 每個實體都含有類型信息（如“餐廳”、“景點”或“酒店”）
• 對于某個問題的所有候選答案實體，我們統計它們的類型分布，并移除那些不屬于多數類型的實體
  • 例如，在圖1中，實體 Grand Hotel 被標為“酒店”，但其余答案多為“餐廳”，因此 Grand Hotel 被移除
  • 如果沒有明顯的多數類型（如類型分布非常分散），則整條問題（及其答案）被丟棄
  • 【這個是說一個回復中，當多個實體被提取出來時，如果大多數都是一個類型（比如餐廳），那極少數是其他類型的實體（比如酒店）就被認為是“異類”，于是被剔除。】

2.3.3?去除通用名稱實體

• 有些實體的名稱非常通用，如“Cafe”、“Spa”或城市名，這些在答案提取過程中容易造成誤匹配
  • 參考 Google Places 提供的實體類型，收集了一批通用實體名，移除名稱與這些詞條匹配的實體。

2.3.4?去除連鎖品牌/加盟店

• 有些答案是餐飲或酒店連鎖品牌名稱，如“Starbucks”、“Hilton”
  • 由于我們無法區分具體是哪一家門店，因此無法關聯其評論數據
  • 在這種情況下，系統會提取城市中所有同名實體，導致誤匹配，因此我們直接丟棄這些 QA 對

2.3.5?去除錯誤候選（spurious candidates）

• 用戶在論壇回答中經常提及多個實體，其中有些并非答案，而是用于地理參照如“在 Starbucks 對面”）或觀點比較（如“Wendy's 不如 A 餐廳”）

  • 通過一套簡單規則剔除這些情況中提取出的實體，如：

    • 若一句話中提取出多個實體，則全部丟棄；

    • 若實體名鄰近“next to”、“opposite”等短語，也予以剔除。

• 此外，我們人工審核了提取的實體名集合，刪除了一些常見英語單詞或短語作為名稱的實體（如“August”、“Upstairs”、“Neighborhood”等餐廳），它們容易導致錯誤匹配。總共移除了322個此類實體名稱。

• 這一步是整個數據收集流程中唯一包含人工標注的步驟。

2.4?數據收集：誤差分析

• 我們對訓練集中約 1% 的數據（450 個 QA 對）進行了誤差分析，以評估自動數據收集流程的準確性
  • 結果表明，高精度過濾規則在該子集上的答案抽取準確率為 82%

  • 出現錯誤的原因主要可歸結為以下五類

    • （16%）實體名稱為通用英語詞匯（例如 “The Park”），容易產生歧義

    • （27%）實體匹配到了回答中另一個非目標實體（例如，“next to Starbucks” 中的 Starbucks，并非真正答案）

    • （31%）實體名稱相似，但屬于不同類別（如與問題目標類型不同，例如匹配到同名酒店而不是餐廳）

    • （13%）未能識別否定句或負面情緒（例如帖子中說 “我不會去那家吃飯”）

    • 剩余 13% 錯誤來自無效問題（非實體類查詢）或論壇用戶本身提供的錯誤答案

2.5?眾包清洗

• 為了實現高質量的驗證與測試集評估，對驗證集與測試集進行了眾包清洗
  • ???????使用 Amazon Mechanical Turk（AMT）進行眾包

  • 工作者會看到一個 QA 對，包括：

    • 原始問題；

    • 通過規則抽取出的答案實體；

    • 實體出現的原始論壇帖子及回復內容；

  • 工作者被要求判斷：該實體是否確實在論壇中被作為回答提到

  • 每個 QA 對的審核費用為 $0.05，共審核了約 $550 的數據

2.6?數據特征

• 每個問題的平均長度為約 73 個 token，這與一些現有 QA 任務中的文檔長度相當；
• 每個實體文檔平均包含 3,266 個 token，遠大于多數 QA 數據集中的文檔長度
• 回答一個問題通常需要考慮該城市中的所有可能實體，平均每個問題對應的候選實體數超過 5,300 個，突顯了規模化處理的挑戰。
• 數據集覆蓋 50 個城市，總計包含 216,033 個實體
• 平均而言，每個問題被抽取出 2 個金標準答案
  • ??????????????

• 問題內容可能涉及以下限制條件：

  • 實體的地理位置

  • 預算

  • 時間安排

  • 以及關于氛圍、服務質量等主觀偏好

3 相關工作

• 給定一個 POI 推薦類問題，其目標類別（例如“餐廳”）、所屬城市（例如“德里”）、該城市中該類別的候選 POI 實體，以及每個實體對應的一組評論文檔，任務目標是：根據問題對每個候選實體進行相關性評分。

3.1?POI 推薦任務

• 查詢通常是結構化語句，或者由簡單關鍵詞或短語組成
  • 而論文將該問題建模為一個問答任務
    • ???????用戶通過提出詳細的問題來表達偏好和約束條件，而不提供任何歷史行為記錄
    • 系統需要分析用戶的問題以及與每個 POI 相關聯的非結構化評論集合來返回推薦答案（POI）
  • 這是首個將 POI 推薦任務構建為一個非結構化 QA 任務，并基于真實旅游問題和 POI 評論進行建模與實驗的工作

3.2?QA 與信息檢索任務

3.2.1 和QA的關系

• 閱讀理解類的 QA 任務通常假設答案顯式出現在文檔中，可以通過單跳或多跳推理在句子中直接抽取
  • 而論文提出的任務，答案是由一份評論文檔表示的實體（POI），而不是出現在文本中的具體句子。
• 另一類開放域 QA 任務則要求模型首先從一個大型語料庫中檢索可能包含答案的文檔，再從中抽取或生成答案
  • 這些任務的模型通常采用基于稀疏向量表示（如 TF-IDF 或 BM25 排名）的“檢索-排序器（retriever-ranker）”架構，先選出候選文檔，然后進行深層推理以提升可擴展性
  • 但是，在這個任務中，BM25 等傳統檢索策略效果極差，難以有效縮小候選空間。
    • 每個實體由一個長篇、無結構的“評論包”文檔表示，以往為了控制文檔長度而任意截斷的方式在此并不適用，因為評論本身缺乏結構性。
    • 使用 TF-IDF 等方式來縮小候選范圍效果不佳，原因在于評論通常表達對類似方面/主題的主觀觀點，而非 QA/IR 任務中常見的具有辨識度的主題內容
  • 此外，每個問題需要處理的文檔數量是這些開放域 QA 任務的 500 倍，每份文檔本身也包含大量主觀、噪聲信息。
    • 傳統 QA 模型（如 BiDAF 或基于 BERT 的模型 ）幾乎不可行
      • BiDAF 在 4 張 K80 GPU 上訓練一個 epoch 就需 43 小時
• 本任務與“社區問答（Community QA, CQA）”任務相關
  • 但 CQA 的目標通常是從已有的論壇回復中找答案或尋找類似問題
  • 在本任務中，旅游類 POI 推薦問題的答案來源是與實體相關的評論集合，而非現有的論壇回復

3.2.2? 和IR的關系

• IR 任務的目標是：根據查詢檢索相關文檔
  • ???????但這個任務的挑戰不只是語義匹配，而是還要對主觀評論信息進行推理和聚合，才能評估實體文檔的相關性

4 方法

提出的強基線模型，CsrQA由三個主要模塊組成：

1. Cluster：聚類模塊 —— 生成更小的代表性實體文檔；

2. Select：篩選模塊 —— 使用神經檢索器縮小候選實體空間；

3. Rerank：重排序模塊 —— 深度推理模型對篩選出的候選實體打分排序。

4.1?聚類模塊：構建代表性實體文檔

• 數據集中每個實體的原始文檔（即所有評論的集合）比現有 QA 數據集中所使用的文檔要大得多
• 為了讓神經網絡模型能有效訓練，CsrQA 首先將每個實體的評論壓縮為一個“代表性文檔”。
  • 使用預訓練的 Universal Sentence Encoder（USE）對評論中的每句話進行編碼，生成句向量；
  • 對每個實體文檔中的所有句子進行 k-means 聚類
  • 從每個簇中選擇離質心最近的前 k 個句子，作為代表
  • 在實驗中，我們設置簇數為 10，每簇選 10 句話，總計每個實體文檔保留 100 句話
    • ??????????????這相當于將文檔長度縮短了約 70%，但仍比多數 QA 任務中的文檔大得多

4.2?篩選模塊：選出候選答案實體

• CsrQA訓練一個神經檢索模型，將問題視為查詢，將代表性實體文檔視為文檔庫
• 使用Duet 網絡，這是一個基于交互的神經網絡，通過將問題與文檔中的不同部分進行匹配，再聚合證據來判斷其相關性。
  • 結合了詞面匹配（local features）和語義匹配（distributed features）
  • 架構基于 CNN，因此在大規模檢索任務中具備較好擴展性
• 詞面匹配
  • ???????生成包含 TF-IDF 分數的詞項矩陣（term-document matrix）
  • 輸入 CNN → 全連接層 → 輸出評分
• Distributed（語義）部分
  • 使用 GloVe 詞向量編碼問題與文檔中的詞
  • 使用卷積層 + max-pooling 處理；
  • 問題向量送入全連接層，實體文檔繼續使用另一層卷積處理；
  • 問題向量與實體文檔向量合并后，送入多層全連接層 → 輸出最終評分
  • 最終評分為 local 與 distributed 兩個通路的分數之和。

• Duet 的作用是為每個問題對所有實體文檔打分并排序；

• 最后選出得分最高的 Top-30 個實體 進入下一階段的深度推理。

4.3?重排序模塊：對篩選出的候選實體進行推理

5 實驗