HoVer: A Dataset for Many-Hop Fact Extraction And Claim Verification

TL;DR

HoVer presents a large, human-curated dataset for many-hop fact extraction and claim verification, requiring evidence from up to four Wikipedia articles and enabling diverse reasoning graphs. The authors implement a three-stage data collection (claim creation, mutation, labeling) with rigorous quality controls, merging Refuted and NotEnoughInfo into a Not-Supported category to reduce labeling ambiguity. Baseline systems combining TF-IDF and BERT-based retrieval and verification reveal sharp declines in performance as hop count increases, with humans outperforming models by wide margins, underscoring the dataset’s difficulty. By releasing 26k claims and providing a full evaluation framework, HoVer aims to catalyze research in robust, multi-hop evidence retrieval and factual verification in open-domain settings.

Abstract

We introduce HoVer (HOppy VERification), a dataset for many-hop evidence extraction and fact verification. It challenges models to extract facts from several Wikipedia articles that are relevant to a claim and classify whether the claim is Supported or Not-Supported by the facts. In HoVer, the claims require evidence to be extracted from as many as four English Wikipedia articles and embody reasoning graphs of diverse shapes. Moreover, most of the 3/4-hop claims are written in multiple sentences, which adds to the complexity of understanding long-range dependency relations such as coreference. We show that the performance of an existing state-of-the-art semantic-matching model degrades significantly on our dataset as the number of reasoning hops increases, hence demonstrating the necessity of many-hop reasoning to achieve strong results. We hope that the introduction of this challenging dataset and the accompanying evaluation task will encourage research in many-hop fact retrieval and information verification. We make the HoVer dataset publicly available at https://hover-nlp.github.io

Figures (8)

• Figure 1: Data Collection flow chart for HoVer. In the first stage, we create claims from HotpotQA, validate them and extend to more hops. In the second stage, we apply a variety of mutations to the claims performed by crowd-workers and automatic methods. In the final stage, we ask crowd-workers to label the resulting claims.
• Figure 2: Baseline system with the 4-stage architecture.
• Figure 3: The average token length of our 2, 3, 4-hop claims.
• Figure 4: A 2-hop Simple Claim Creation example using HotpotQA pair.
• Figure 5: Bert Mutation Procedure. We first randomly select 1-2 non-entity words from a range of Choices and mask them. Then the BERT model predict the masked token and provides the mutated claim.