一、概述

title：WEBCPM: Interactive Web Search for Chinese Long-form Question Answering

论文地址：https://arxiv.org/abs/2305.06849

代码：https://github.com/thunlp/WebCPM

1.1 Motivation

1. 开发一个类似于WebGPT一样的中文版本的数据集，用于检索相关事实，并基于这些事实生成最终回答，并发布一个baseline模型。
2. LFQA：旨在回答复杂的、开放式的问题，并带有详细的、段落长度的回答，一般有两个步骤，information retrieval：信息检索，检索出相关信息。information synthesis：信息合成，集成信息合成最终的答案。

1.2 Methods

1. 本文发布了WebCPM，第一个中文LFQA数据集，它的information retrieval信息检索数据是基于网络搜索的交互信息拿到的。
2. 和WebGPT一样，也开发了一个搜索引擎的interface，招募标注人员使用该interface搜索相关信息然后回答问题，同时web search的行为会被记录下来。

• interface特点：可以搜索相关事实，记录相关事实，同时记录大约10个交互action行为信息。

1. 本文提到的LFQA pipeline框架：

• web search：执行一系列action，取收集相关的信息，主要包括action prediction，search query generation，supporting fact extraction三个模块，如果action模块预测为Search作为当前操作，则它会调用query生成模块来生成查询内容，如果action模块预测Quote作为当前操作，则会调用Quote模块来抽取相关事实，总共大概有十个左右的action。
• 各部分实现方法：

• • Action Prediction：预测下一个action，大概10个左右的action，建模成一个多分类任务，预测每一个action的概率，并把它用生成的方法来实现，例如search的概率就是P(search|St)，St为t时刻的状态。
  • Search Query Generation：生成搜索的query，也是用文本生成来实现，P(Qt+1|St)

• • Supporting Fact Extraction：直接预测所有的事实数据太慢，先预测start和end位置少量的token，然后用text matching匹配start和end位置，检索出所有的事实文档。

• • Synthesis Model：组织相关事实依据，生成最终的回复，搜索出来的数据会存在噪音：随机构造了不相关样本，补充到数据集中，让模型预测理想的结果，通过这种方法来降低噪声对模型的影响

1.3 Conclusion

1. 收集了5500个高质量的QA对，基于15372个支持的事实，以及125954个搜索action。
2. 构建了一个中文long-form QA网络搜索交互数据的benchmark，同时一个开源的interface。我们将任务分解为4个子任务，并设计了一个模块化的pipeline。通过对具有代表性的plm进行微调，我们对每个模块进行单独的评估，并对pipeline进行整体评估。
3. 利用预训练模型去模拟人类的搜索行为，并基于搜索的事实生成答案，分别在我们的数据集和DuReader上的数据集有32.5%和47.5%的情况下生成的答案并不比人工编写的答案差。
4. 我们进行了深入的分析，以理解我们的框架的核心设计元素。我们希望我们的interface、数据集、框架和分析能够促进这一领域的更多探索。

• 特点：基于公开数据，基于long-form QA长文本，段落的回答，有自由形式的回答，并且有网络搜索行为，平均问题长度29，平均事实长度555，平均回答长度257，比其他数据都高不少。

1.4 limitation

1. 评估表明，我们的pipeline方法在信息检索和合成过程中的表现比人类差67.5%，这仍有改进的空间。

二、详细内容

1 LFQA数据样例

• 特点：

• • 记录搜索过程的action
  • 记录抽取出来的多条事实依据，有标注的事实的label
  • 基于事实依据生成最终答案

2 各子模块在三类典型的中文生成式PLM实验表现

• 建模方法：search阶段分为三个子任务，Action预测，Query生成，Fact抽取，都是用生成模型来实现
• 在8种支持中文的典型生成式PLM做了实验，涵盖3种架构。
• 不同模型在Action预测，Query生成，Fact预测的效果都不太一致，不过最大的CMP10B模型效果确实是最好的。

3 pipeline方法消融实验

1. 图（a）：对比不同方法收集的fact效果对比

1. 1. pipeline-collected：指本文提到的Action预测，Query生成，Fact预测三个模块组成pipeline提取事实的方法，该方法可能会带来噪声，整体不落败的比例为19.0+13.5=32.5
   2. human-collected：指人工标注收集到的事实fact，最为准确，整体不落败的比例为16.0+29.5=45.5，对比pipeline方法，效果还是好不少，说明事实抽取的噪音确实会影响效果
   3. Non-interactive Search：指利用非交互式方法收集的fact，没有pipeline式可能拆分复杂的问题到简单的问题，搜索其他变种等方法，效果差的非常多，说明pipeline方法的优越性。
   4. 总结：人工fact > pipeline fact >> Non-interactive Search方法

1. 图（b）：对比pipelie方法在DuReader数据集上和真实answer的效果差异

1. 1. search：在该数据集上，比真实人工标注的answer要差一些
   2. ZhiDao：在改数据集上，居然比真实人工标注的answer效果还要好，说明本文方法的有效性。
   3. 其他：相等的为0，因为他们搜集到的事实fact完全不同，所以基本都不相等

1. 图（c）：合成模型消融实验

1. 1. 背景：因为交互式搜索不可避免引入不相关的fact会影响效果，本文通过在训练集引入不相关的fact来提升合成模型消除噪声的能力，这里对比不引入噪声数据和引入噪声数据的效果对比。【具体方法是随机挑选不相关的数据到fact中，让模型学习预测准确的answer，提升模型忽略不相关噪声的能力】
   2. 结论：本文采用的合成模型的策略优于baseline模型。

4 当前状态特征消融实验

目的：当前状态有非常多特征，例如上一个时间Action，上一个时间的fact一句，窗口特征windows等，哪些特征对各个子模块最有用呢？

• 实验说明：尝试去掉各个特征，比较各个子模块与之前的效果差异。
• 结论1：对于Action模型，去掉上一个时间的Action At-1，效果差的非常多，说明这个特征对Action模型非常重要。
• 结论2：对于Fact模型，去掉上一个收集的Fact Ft，效果也差的非常多，说明当前需要收集的fact还是会去参考之前的fact。

5 Query Generation模块在干啥？

• 方法总结：主要基于原始问题做一拓展，搜集更多准确的，相关的依据fact，用于生成更好的answer

• • copy：复制原始问题
  • decomposing question into multiple sub-question：拆成多个子问题
  • rephrasing question with related terms：利用相关术语重新构造问题

6 各类Action占比统计

• 结论：我们在图7中记录了我们收集的数据集中不同的预定义动作的比例。可以看出，向下滚动、引用和搜索是最常用的操作。加载页面<1>的比例大于<2>和<3>的比例。这是因为搜索引擎根据它们与查询的相关性对搜索结果进行排序。人类倾向于根据搜索引擎推荐的顺序来访问这些链接。如果人类在第一页上收集了足够的支持事实，或者发现它无关紧要，他们可能不会继续浏览当前查询的其他网页。

三、个人总结

1. 提出了一个不错的中文LFQA数据集，特点是包含人类和搜索引擎交互的数据，并且问题比较复杂。
2. 提供了一个比较强的baseline方法：引入了交互式搜索，对原始的问题做拓展，在搜索引擎上收集充分多的事实，提升检索方法收集依据fact的效果，同时合成答案阶段，也采用了一些策略来优化不相关fact噪声带来的影响。
3. 同时开源了整个web搜索框架，值得其他地方借鉴。
4. 这个方法可以和langchain等方法结合，进一步提升本地知识检索和生成的效果。