论文笔记：Answering POI-Recommendation Questions using TourismReviews

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 实验