清华、剑桥、UIC联合推出首个中文事实核查数据集：基于证据、涵盖医疗社会等多个领域
- WBOY转载
- 2023-04-09 19:31:011686浏览
- 论文地址：https://arxiv.org/pdf/2206.11863.pdf
- 数据集CHEF Dataset链接：https://github.com/THU-BPM/CHEF
1. 介绍
我们先来看看任务的定义，举一个相对比较简单的例子：
比如上海封控期间，某自媒体就声称“李立群偷下楼买肉被抓”。单凭这个声明（Claim）本身，我们其实没法判断他有没有偷偷下楼买肉然后被抓。为了验证这个声明的真实性，最直观的思路就是要寻找证据（Evidence），证据就是你能够搜集得到的，同时能够帮助我们验证一个声明真实性的信息。比如下图，本人直接下场手撕就可以作为证据了。
上面举的这个声明是比较简单的，只需要简单的证据，也不需要基于证据进行推理。下面我们来看一个相对复杂一点的例子。比如有声明：2019 年，共有 12.08 万人参加成都中考，但是招生计划只有 4.3 万。要验证这个声明相对就困难一些了，假如我们找到报告 2019 年成都中考的相关文档：
......今年共有 12.08 万人参加中考，这个是成都全市, 包括了 20 个区，高新区和天府新区的总参考人数。月前，教育局公布了 2019 年的普高招生计划。招生计划数进一步增加，上普高的机会更大了。......
2019 年，中心城区（13 个区）招生计划为 43015 人。
这个文档中包含了非常多和声明相关的信息，但是直接相关的，能够帮助我们验证声明的，就是上述的第二段话的后半部分，还有隔了很多段话之后的第一句话。根据这几个证据，我们可以知道成都全市 20 个区的确有 12.08 万人参加中考，而中心城区（只包含了 13 个区）的招生计划确实也是只有 4.3 万。虽然数字都对，但是这里偷换了概念，在讨论参加中考人数时使用了 20 个区的人数，而在讨论招生计划时却将 20 个区的范围缩小成为 13 个区，从而误导读者。验证这种声明很多时候我们需要从一个或者多个文档当中抽取直接相关的证据，同时基于抽取的证据进行推理。为了促进中文的事实核查机器学习系统，于是我们提出了这样一个基于证据的中文数据集。
2. 相关工作
根据事实核查的综述[1]，目前事实核查的数据集大致可以分为两类：人工的（Artificial）和天然的 （Natural）。
人工的（Artificial）：就是请标注者按照维基百科上的句子进行改写作为声明，文档里面相关的段落可以作为证据验证这个声明。如果是同义转换，那么这个声明就是被证据所支持（Supported），如果替换了句子里面的实体，或者加了否定等一系列修改，那么这个声明就是被证据所反对（Refuted）。
这种标注范式最开始就是 FEVER[2]，后面很多有名的数据集比如：TabFact[3]也是沿用了这种范式。这类型的人工数据集的好处就是可以规模化，请标注者标注上 10 万的声明，非常适宜训练神经网络。另一方面，相关的证据也容易获得。缺点就是，这些声明并不是日常生活中我们会遇到的，广大人民群众喜闻乐见的声明，比如你不会基于李立群的维基百科改写出 “他偷偷下楼买肉被抓” 的声明。另一方面，这类型的数据集假设维基百科包含了验证声明所有的知识，这是一个比较强的假设。在现实场景里面往往不满足这个假设。最简单的一个问题就是维基百科会存在时间上的滞后性。
天然的 （Natural）：就是从事实核查的平台上面直接爬取下来的声明，外国比较有名的机构就是 PolitiFact，经常核查特朗普讲的话。这类型的数据集的好处就是，他是广大群众日常会碰到的，想要知道真相的声明。也是人类事实核查者需要去进行甄别的声明。
假如我们最终是要构建一个能够一定程度上替代人类核查者的系统，这个系统的输入就需要是这类型的声明。这类数据集的缺点也很明显，就是人类核查过的声明数量是非常有限的。如表格所示，大部分的数据集其实都要比人工构造的小一个数量级。
另一方面就是，寻找证据是一个非常困难的问题。现有的数据集一般就是直接使用事实核查的文章 [4] 作为证据，要么就是用声明输入给谷歌搜索进行查询[5][6]，然后用返回的搜索摘要（如红框所示）作为证据。
这些寻找证据的方法有两个问题：
- 使用事实核查文章本身作为证据：在真实场景里面，这种做法是不切合实际的，假如我们要上线一个事实核查系统，系统需要去核查新的声明的时候，往往还没有事实核查的文章出现。这样系统就没法学会如何搜集证据了。
- 使用谷歌摘要作为证据：这种做法克服了上述的问题，更加贴近真实场景，事实核查者往往需要依赖搜索引擎寻找相关的信息。但是这种方法也有弊端，就是信息量严重不足，如上图所示，谷歌的基于规则的摘要基本没法提供充分的信息，来帮助我们判断声明的真实性。
针对以上提到的问题，我们构建了 CHEF，CHEF 有以下几个特点：
- 使用真实世界的声明，同时是中文的，填补了中文事实核查数据集的空白。
- 使用搜索引擎返回的文档作为原始证据，更加贴近真实场景。
- 使用人类标注返回文档的相关句子作为细粒度的证据，可以用于训练核查系统学会如何搜集证据。
3. 数据集构建
数据集的构建包含 4 个部分：数据收集，声明标注，证据检索和数据验证。
3.1 数据收集
原始声明主要从四个中文的事实核查网站上面爬取（根据杜克新闻平台 ），其中简体中文有两个：中国辟谣中心和腾讯较真。繁体中文是来自于台湾的两个平台：MyGoPen 和台湾事实核查中心。由于从事实核查网站中爬取的声明绝大部分（90%+）都是不实的，其实很直观，大部分流行的谣言 / 声明都是不实的，才会被核查平台辟谣 / 验证。参考前人的方法（PublicHealth[7]），我们爬取中国新闻网的标题作为真实的声明，构造一个标签相对平衡的数据集。
3.2 声明标注
和国外相对成熟的事实核查机构相比，中国的核查平台发布的文章相对没有那么规范。比如 PolitiFact 会明确告诉你声明是什么，核查摘要是什么，证据和推理细节是什么（如上图所示）。但中文的文章一般不会明确指出，所以我们请标注者阅读文章之后抽取出文章验证的声明。同时也对声明进行清洗，降低其含有的偏差（bias）。
之前有工作表明[8]，事实核查数据集里面的声明含有比较强的 bias（比如不实的声明一般带有否定词），BERT 等 PLM 可以通过直接捕捉这些 bias，不需要证据就可以验证声明。清洗的方法包括将反问句改为陈述句，去掉一些可能带有 bias 的词语，比如：重磅，震惊等等。抽取出声明之后，我们还要求标注根据事实核查的文章给声明打标签。我们采取和 FEVER 等一系列工作类似的分类，使用 Supported，Refuted 和 Not enough information（NEI）的三分类。其中 Refuted 是最多的，NEI 的数量是最少的。
3.3 证据检索
我们使用声明作为查询语句去查询谷歌搜索，然后过滤掉部分文档，一部分是声明发表时间之后的文档，另一部分是来自于不实消息传播平台的文档，最后保留 Top 5 的文档。然后要求标注者针对每个声明，选择最多 5 个句子作为证据。
数据集中的声明和证据的统计数据如下所示：每个声明返回文档的平均长度为 3691 个词，其中标注者抽取出最后细粒度证据的句子包含 126 个词，假如使用谷歌基于规则的摘要则平均包含 68 个词。简单地从数字上面进行比较，使用返回的文档和标注的句子，要比直接使用摘要提供了更多的上下文信息。
3.4 数据验证
为了保证标注一致性，我们添加了一轮数据验证，随机抽取了 3% 已标注的声明，一共 310 个分给 5 个标注者进行标签再标注。Fleiss K score 达到了 0.74，比 FEVER 的 0.68 和 Snopes[5]的 0.70 略高一些，说明了数据标注的质量不逊色于前人构建的数据集。CHEF 中声明主要分为 5 个主题：社会，公卫，政治，科学和文化。和欧美的事实核查平台关注在政治领域不同，中文平台更加关注公共卫生议题，比如：新冠病毒，养生，医疗等。另一个主要议题是社会，比如：诈骗，升学，社会事件等。
验证声明主要有四方面的挑战：
- 证据搜集：将近 70% 的声明都要求搜寻到相关的证据才能验证。
- 专家咨询：将近 40% 的声明需要通过咨询专家才能得到相关的信息。
- 数值推理：18% 的声明验证需要进行数值上的推理才能得出结论。
- 多模态：约 8% 的声明需要图片，视频等非文本的证据。
4. 基线系统
和之前经典的事实核查数据集（比如 FEVER）类似，机器学习系统需要先在给定的文档里面选择相关的句子作为证据（证据检索），然后再根据证据对声明进行验证（声明验证）。
本文根据千人的工作，提出了两大类的基线系统：流水线（pipeline）和联合（joint） 系统。流水线（pipeline）：即证据检索和声明验证是两个分开的模块，先使用证据检索器抽取出证据，再联合声明一起交给声明验证模块进行分类。
- 证据检索部分：我们使用了 4 种不同的抽取器从返回的文档当中抽取句子作为细粒度的证据。第一种就是基于字符特征匹配：TF-IDF；第二种是基于语义特征匹配：我们使用中文 BERT，然后计算余弦相似度。第三种是混合特征：采取上述两种特征，然后在用 rankSVM 排序。最后一种基线系统就是经典的谷歌返回的摘要。
- 声明验证部分：我们使用 3 种不同的模型。第一种就是基于中文 BERT，将声明和上面得到的证据拼接起来丢给 BERT 进行三分类。第二种是基于注意力的模型，基于声明赋予证据不同的权重之后进行分类。第三种是基于图的模型：我们使用了 FEVER 上面的 SOTA 图模型 KGAT[9]，可以更好地在综合不同的证据进行推理。
联合（joint）：证据检索和声明验证模块联合进行优化。使用了三种不同的模型，第一种是 FEVER 上面 SOTA 的联合模型[10]，使用了多任务学习的框架，同时学习给证据和声明打标签。第二种是把证据抽取作为隐变量进行处理[11]，给返回的文档的每个句子打 0 或者 1 的标签，打了 1 标签的句子将会留下作为证据和声明一起进行分类，使用 REINFORCE 进行训练。第三种方法和第二种类似，只不过使用 HardKuma 和重参数的方法进行联合训练[12]，而不是使用策略梯度。
5. 实验结果
5.1 主要结果
实验主要结果如下图所示：
- 从证据检索的角度来看：联合模型要比流水线模型表现总体要好一些，主要原因是证据检索模块可以被优化，从而能够找到更加能够帮助验证声明的证据。另一方面，使用返回的文档总比使用谷歌摘要效果要好，主要因为是文档包含更加丰富的信息。最后就是直接使用人类标注的证据效果远远超过了目前的两大类基线模型。和其他事实核查的数据集类似（FEVEROUS），证据检索是验证声明的一个难点。怎么根据人类标注的证据去优化证据检索模块是未来值得研究的方向。
- 从声明验证的角度来看：基于图的模型（KGAT）的表现比基于简单的 BERT 和基于注意力的模型要好一些，通过构造图来捕捉证据推理链是有效的方法。但另一方面，图模型的提升并没有特别明显，可能还需要针对数据集本身做一些因地制宜的优化。
5.2 细粒度证据的数量
细粒度证据的数量并不是越多越好，如下图所示，当我们选择 5 个句子作为细粒度证据的时候，流水线系统里面的证据抽取器取得了最好的效果，当抽取 10 个和 15 个句子作为证据的时候，效果越来越差，我们猜测是抽取的句子里面引入了比较多的噪声，影响了声明验证的模型进行判断。
5.3 声明长度的影响
绝大部分的声明都大于 10 个词，其中长度越长模型效果越好，我们猜想主要原因是声明比较详细，比较容易搜集到的详尽的证据帮助模型进行判断。在声明长度比较短的时候，集中基线模型的差距不是很大，当长度比较长的时候，拿到的证据越好，声明验证的效果越好，也说明了证据检索这一环节的重要性。
5.4 声明领域的影响
来自于科学领域的声明最难被验证，模型效果基本都不超过 55。一方面是比较难搜集到相关的证据，另一方面是关于科学议题的声明相对比较复杂，往往需要隐式的推理才能得到结果。
5.5 声明类别的影响
如图所示，即使我们引入了部分 Supported 的声明，但是整个数据集仍然存在类别不平衡的问题。模型在 NEI 这个类别上的效果要远远弱于 Supported 和 Refuted 这两个类别。未来的工作可以研究如果针对类别不平衡的事实核查数据集，调整声明验证的模型，或者使用数据增强的方法，在训练过程中随机增加 NEI 的数量，比如 FEVEROUS[13]在训练过程中就随机针对一些声明扔掉对应的证据，然后将这些声明的类别改为 NEI。
以上是清华、剑桥、UIC联合推出首个中文事实核查数据集：基于证据、涵盖医疗社会等多个领域的详细内容。更多信息请关注PHP中文网其他相关文章！