Source-linked AI summary
HotpotQA: A Dataset for Diverse, Explainable Multi-hop Question Answering
Zhilin Yang, Peng Qi, Saizheng Zhang, Yoshua Bengio, William W. Cohen, Ruslan Salakhutdinov, Christopher D. Manning
TL;DR
기존 QA 데이터셋은 multi-hop reasoning과 explainable prediction을 제한적으로만 지원한다. HotpotQA는 여러 문서에 걸친 질문과 문장 수준의 supporting fact를 포함한 다양한 Wikipedia 데이터셋으로 이를 보완하며, supporting-fact supervision이 성능을 향상시키지만 full-wiki QA는 여전히 인간 성능에 크게 미치지 못함을 보인다.
문제
기존 QA 데이터셋은 multi-hop reasoning을 충분히 검증하지 못하고 distant supervision만 제공하므로, reasoning process와 explainable prediction 학습이 제한된다.
방법
HotpotQA는 여러 supporting document에 걸친 다양한 Wikipedia 질문을 crowdsource하고 sentence-level fact를 제공하며, 모델은 이를 answer와 함께 jointly predict한다.
결과
Supporting fact를 사용하지 않는 경우보다 10+ F1 improvement를 얻지만, full-wiki 성능은 여전히 인간 성능에 크게 미치지 못한다.
시사점 및 한계
HotpotQA는 다양한 자연어 문서에 걸쳐 explainable multi-hop reasoning을 수행하는 QA system 개발을 위한 benchmark를 제공한다.
Abstract
from arXiv · showhide
Existing question answering (QA) datasets fail to train QA systems to perform complex reasoning and provide explanations for answers. We introduce HotpotQA, a new dataset with 113k Wikipedia-based question-answer pairs with four key features: (1) the questions require finding and reasoning over multiple supporting documents to answer; (2) the questions are diverse and not constrained to any pre-existing knowledge bases or knowledge schemas; (3) we provide sentence-level supporting facts required for reasoning, allowing QA systems to reason with strong supervision and explain the predictions; (4) we offer a new type of factoid comparison questions to test QA systems' ability to extract relevant facts and perform necessary comparison. We show that HotpotQA is challenging for the latest QA systems, and the supporting facts enable models to improve performance and make explainable predictions.
1 서론
기존 QA 데이터셋은 다중 문서 추론을 충분히 평가하지 못하고, 질문의 다양성이 제한적이며, 추론을 학습하고 설명하는 데 필요한 감독을 충분히 제공하지 못한다. HOTPOTQA는 자연스러운 multi-hop 질문과 supporting evidence를 중심으로 구축한 crowdsourced Wikipedia 데이터셋을 통해 이러한 공백을 해소한다.
- 기존 데이터셋의 한계: 기존 데이터셋은 단일 문단 내 추론을 평가하는 경우가 많아, 여러 문단에 걸친 복잡한 추론의 필요성을 제한한다.SQuAD가 그 예로 제시되며, SQuAD의 질문은 대개 한 문단에서 인접한 문장을 매칭해 답할 수 있다.
- 기존 데이터셋의 한계: knowledge-base 기반 multi-hop 데이터셋은 기반 knowledge base의 schema를 통해 질문과 답변의 다양성을 제약한다.서론에서는 QAngaroo (Welbl et al., 2018)와 COMPLEXWEBQUESTIONS (Talmor and Berant, 2018)를 그 예로 제시한다.
- 데이터셋의 기여: distant supervision만 제공하는 기존 데이터셋과 달리, HOTPOTQA는 각 답변을 뒷받침하는 텍스트를 식별해 모델이 의미 있고 설명 가능한 추론을 학습하도록 하는 것을 목표로 한다.데이터셋 설계는 답변이 어떤 텍스트에서 도출되는지에 관한 강한 감독을 제공한다.
- 데이터셋의 기여: HOTPOTQA는 여러 supporting documents를 포함한 Wikipedia 자료를 crowdsourcing하여, 기존 knowledge-base schema에 의존하지 않는 자연스러운 multi-hop 질문을 생성한다.Crowd worker들에게 여러 supporting context documents를 제시하고, 그 문서 전체에 대한 추론이 필요한 질문을 만들도록 명시적으로 요청했다.
2 데이터 수집
데이터 수집 파이프라인은 multi-hop reasoning이 필요한 다양하고 설명 가능한 텍스트 기반 질문을 대상으로 한다. Wikipedia 하이퍼링크와 선별된 entity 목록을 사용해 bridge-entity 질문과 비교 질문을 생성하고, supervision과 evaluation을 위해 supporting facts를 수집한다.
- 파이프라인 설계: 이 파이프라인은 임의의 문단 집합을 작업자에게 제시하는 대신 candidate paragraph generation을 신중하게 설계해 의미 있는 텍스트 기반 multi-hop 질문을 수집하기 어려운 문제에 대응한다.Pilot study에서는 임의의 문단 집합 대부분이 의미 있는 multi-hop 질문을 뒷받침하지 못해 오히려 역효과를 낳는 것으로 나타났다.
- Wikipedia Hyperlink Graph 구축: Wikipedia의 hyperlink graph는 연결된 entity들이 multi-hop reasoning을 뒷받침할 수 있는 candidate paragraph pair를 제공하며, 문서 도입부는 질의에 적합한 정보를 제공한다.corpus는 전체 English Wikipedia dump이며, 하이퍼링크는 서로 구분된 entity 간의 관계를 함의하는 경우가 많다.
- Candidate Paragraph Pair 생성: Bridge-entity 질문에서는 작업자가 한 문단에서 중간 entity를 추론한 다음 연결된 문단에서 그 entity의 답을 찾아야 한다.Radiohead 예시에서 작업자는 생일을 확인하기 전에 Thom Yorke를 bridge entity로 식별한다.
- 비교 질문: 비교 질문은 서로 유사한 entity로 구성된 42개의 수작업 선별 목록에서 표본 추출한 pair로 수집되며, 두 문단 모두에 대한 reasoning을 요구한다.저자들은 텍스트 기반 비교 질문을 새로운 유형으로 설명하며, 출생일에서 나이를 계산해 비교하는 것처럼 산술적 비교가 필요한 경우가 많다고 지적한다.
- 비교 질문: 비교 subset에는 질문의 다양성을 넓히면서 시스템이 두 문단 모두를 대상으로 reasoning하도록 요구하는 yes/no 질문이 포함된다.수집 절차에서는 비교 질문 내 yes/no 비율을 0.5로 설정한다.
- Supporting Facts 수집: Crowd worker는 각 답을 결정하는 문장도 식별해 attention supervision과 explainability evaluation을 위한 supporting facts를 제공한다.이러한 facts는 답에 도달하는 데 필요한 증거를 나타내도록 의도되었다.
3 처리 및 벤치마크 설정
데이터셋에는 112,779개의 유효한 예제가 포함되며, 대부분 단일 홉 질문을 분리하고 어려운 multi-hop 사례에 대한 개발과 테스트에 집중하도록 분할된다. 평가는 distractor 및 full-Wikipedia 설정을 사용해 검색 요구가 증가하는 상황에서 supporting-fact retrieval과 추론을 평가한다.
- 데이터 수집: ParlAI interface를 사용해 Amazon Mechanical Turk를 통해 112,779개의 유효한 예제를 수집했다.수집 과정은 Appendix A에 설명되어 있다.
- 데이터 분할: train-easy split에는 상위 기여 turker들의 질문을 샘플링해 식별한, 대부분 단일 홉인 18,089개의 예제가 포함된다.샘플링된 질문 중 압도적인 비율이 단 하나의 문단에 대한 추론만 요구할 때 해당 질문을 train-easy에 할당했다.
- 데이터 분할: 나머지 어려운 예제는 train-hard, dev, test-distractor, test-fullwiki로 나눴으며, dev와 test는 당시 기법으로 답할 수 없었던 질문으로 제한했다.세 training split을 결합해 학습에 사용하고, distractor 및 full-Wikipedia 설정에서는 서로 다른 test set을 사용하므로 full-Wikipedia 평가에서는 정답 문단을 알 수 없다.
- 벤치마크 설정: distractor 설정은 2개의 gold 문단과 bigram tf-idf로 검색한 8개의 Wikipedia distractor를 섞고, 이를 무작위로 섞은 뒤 noise 속에서 supporting fact를 식별하는지 평가한다.질문을 retrieval query로 사용한다.
- 벤치마크 설정: full-Wikipedia 설정은 Wikipedia 전체의 첫 문단들에서 답을 찾아야 하며, 관련 fact의 위치 파악과 추론을 모두 평가한다.따라서 이 설정에서는 고정된 distractor 문단 retrieval 구성을 제거한다.
- Split 분석: Train-medium은 dev와 유사한 multi-hop 비율을 가지지만 Type II 질문이 더 많아 32.0% versus 15.0%이며, 이는 모델의 강한 성능을 설명하는 데 도움이 된다.이에 대응하는 multi-hop 비율은 train-medium에서 93.3%, dev에서 92.0%다.
4 데이터셋 분석
HotpotQA는 다양한 질문 및 답변 유형을 포괄하며, 개체 중심의 질문과 답변이 주를 이룬다. 질문 대부분은 문단 간 multi-hop reasoning을 요구하고, 특히 bridge entity를 통한 chain reasoning이 많으며, single-hop 또는 답변 불가능한 질문은 소수에 불과하다.
- 질문 유형: HotpotQA는 개체, 위치, 사건, 날짜, 수, 그리고 개체 간 yes/no 비교에 관한 다양한 질문을 다룬다.이러한 질문 유형은 휴리스틱하게 식별한 뒤 Figure 2에 시각화했다.
- 답변 유형: 표본 답변의 68%는 개체이고, 9%는 날짜, 8%는 수, 4%는 형용사에 해당한다.답변 유형 분석에서는 데이터셋 예시 100개를 표본으로 추출했으며, 폭넓은 답변 유형을 확인했다.
- Multi-hop 추론 유형: 표본 질문의 42%는 답변에 앞서 bridge entity를 식별한 뒤 두 번째 hop으로 진행하는 chain reasoning을 요구하며, 대부분은 각 문단의 supporting facts를 필요로 한다.추론 분석에 따르면 수집된 supporting facts는 답변에 필요한 문단들을 연결하므로 품질이 높다.
- Multi-hop 추론 유형: train-medium과 train-hard에서는 추론 유형이 Type I 38%, Type II 29%, Comparison 20%, Other 7%, Type III 2%, single-hop 2%, unanswerable 2%로 구성된다.별도로 추출한 예시 100개에서 이러한 비율이 도출됐다.
- Multi-hop 추론 유형: 표본 질문의 약 6%는 한 문단만으로 답할 수 있으며, 2%는 답변 불가능한 것으로 판단된다.Multi-hop 분석에서는 이를 주요 추론 유형에 속하지 않는 나머지 사례로도 보고한다.
5 실험
실험 결과, 문맥이 distractor paragraph에서 전체 wiki로 확장되면 HotpotQA는 여전히 challenging하며, supporting-fact supervision은 QA 성능을 높이고 부분적으로 explainable한 prediction을 가능하게 한다. Ablation, question-type 분석, human 비교를 통해 retrieval, modeling, annotation 요인이 성능을 좌우함을 확인한다.
- Benchmark 결과: 전체 wiki 평가에서는 distractor 설정에 비해 성능이 크게 낮아져, retrieval 기반 question answering이 특히 challenging해진다.모델은 먼저 최대 5,000개 paragraph를 retrieval하고, 최종 candidate 10개를 선택한 뒤 answer 및 supporting-fact metric으로 평가한다.
- Explainability: 모델은 supporting-fact prediction F1 60+와 joint F1 약 40을 달성하며, explainability를 개선할 여지가 있음을 보여준다.Joint metric은 answer-span과 supporting-fact 성능을 모두 요구하므로, 어느 한 task에서든 성능이 낮은 system을 penalize한다.
- Question Type: Comparison question은 bridge-entity question보다 distractor 설정의 F1이 낮지만, 두 entity가 대개 문맥에 나타나므로 전체 wiki 성능은 미미하게만 하락한다.Bridge-entity 성능은 전체 wiki 설정에서 크게 하락하며, question-type별 behavior가 retrieval difficulty와 연결됨을 보여준다.
- Ablation Study: Supporting fact에 대한 strong supervision은 QA 성능을 높이며, self-attention과 character-level modeling도 distractor 설정 성능에 유의미하게 기여한다.Supporting-fact supervision을 제거하면 성능이 하락한다. Supporting fact를 도입하면 이를 사용하지 않을 때보다 10+ F1 향상되며, 모델의 direct supervision gain은 약 2 F1 point다.
- Human Performance: Crowd worker는 answer와 supporting-fact 성능에서 매우 높은 수준을 달성하지만, baseline은 gold paragraph가 주어지면 supporting fact에서는 parity에 도달해도 answer에서는 여전히 뒤처진다.Distractor가 있으면 두 task 모두에서 baseline과 crowd worker의 격차가 커지며, human upper-bound metric은 대부분 100%에 가깝다.
6 관련 연구
기존 QA dataset은 single-document, multi-document, KB-based multi-hop, free-form answer-generation 설정을 아우르지만, 각각 reasoning depth, question diversity, answerability, evaluation reliability 측면에서 한계를 지닌다.
- Single-document dataset: SQuAD (Rajpurkar et al., 2016, 2018)는 일반적으로 한 문단의 한 문장 이내에서 답을 찾아야 하므로, 질문이 비교적 단순하다.
- Multi-document dataset: TriviaQA (Joshi et al., 2017)와 SearchQA (Dunn et al., 2017)는 여러 context document를 사용하지만, retrieval-based support만으로는 문서 간 reasoning을 보장하지 못한다.
- KB-based multi-hop dataset: QAngaroo (Welbl et al., 2018)와 COMPLEXWEBQUESTIONS (Talmor and Berant, 2018)는 KB-based multi-hop reasoning을 평가하지만, 고정된 schema가 diversity를 제한하고 불완전한 KB로 인해 질문이 한 문장만으로도 answerable해질 수 있다.
- Free-form answer-generation dataset: MS MARCO 는 사람이 생성한 free-form answer를 사용하고 ROUGE-L과 BLEU-1로 평가하지만, 이 metric은 human judgment와 상관이 낮아 신뢰성에 의문이 있다 (Novikova et al., 2017).
7 결론
HOTPOTQA는 다양한 자연어에 대한 설명 가능한 다중 홉 추론을 대규모로 발전시키기 위해 설계된 데이터셋이다. 또한 시스템이 텍스트에서 엔터티 속성을 추출하고 비교해야 하는 사실형 비교 질문을 도입한다.
- 7 결론: HOTPOTQA는 다양한 자연어에 대한 설명 가능한 다중 홉 추론을 대규모로 다룬다.이 데이터셋은 이러한 추론이 가능한 QA 시스템의 개발을 촉진하기 위한 것이다.
- 7 결론: 텍스트에서 다양한 엔터티 속성을 추출하고 비교하는 능력을 평가하는 사실형 비교 질문을 도입한다.
A 데이터 수집 세부 사항 … A.3 Crowd Worker Interface
데이터 수집 pipeline은 선별한 Wikipedia page pair, token 및 sentence를 고려한 preprocessing, incentive 구조, dialog 기반 crowd-worker interface를 결합했다. 이러한 선택은 직관적인 multi-hop question 작성, 유효한 answer span 확보, 효율적인 고품질 annotation, task 내 worker guidance를 지원하도록 설계됐다.
- A.1 데이터 전처리: Wikipedia 전처리에는 October 1, 2017 영어 덤프, WikiExtractor, 그리고 문장 및 토큰 경계 설정을 위한 Stanford CoreNLP 3.8.0이 사용됐다.문장 경계는 supporting fact 수집을 뒷받침했으며, 토큰 경계는 무의미한 부분 단어 span을 포함하는 답변을 제외하는 데 도움을 줬다.
- A 데이터 수집 세부 사항: 전체적으로 collection details는 data collection process 안에서의 page curation, linguistic preprocessing, worker incentive, interface-level guidance를 포괄한다.이 구성 요소들은 candidate material이 어떻게 준비됐고 crowd annotation이 어떻게 통제 및 지원됐는지를 함께 설명한다.
- A.2 추가 데이터 수집 세부 사항: Pipeline은 591개 WikiProject category를 선별하고, graph로 연결된 page pair 표본이 직관적인 multi-hop question을 뒷받침하는지 수동으로 확인했다.각 category에서 b가 해당 category에 속하도록 page를 pair (a, b)로 sampling한 뒤 수동으로 검증했다.
- A.2 추가 데이터 수집 세부 사항: Crowd worker는 200개 example마다 가장 많은 example을 생성하거나 더 높은 시간당 productivity를 달성한 경우 bonus를 받았다.두 설정은 data collection 중 혼합되어 효율적이고 더 높은 품질의 annotation을 유도했다.
- A.3 Crowd Worker Interface: Worker interface는 ParlAI를 system-oriented dialog workflow로 변형해 question-answer pair를 수집했다.이를 통해 연구자는 Turker의 input을 더 잘 통제하고, in-the-loop feedback과 task completion을 앞당기는 유용한 hint를 제공할 수 있었다.
- A.3 Crowd Worker Interface: Data collection interface는 Amazon Mechanical Turk worker interface로 구현됐다.논문은 collection process 중 촬영한 screenshot으로 interface를 보여준다.
B 추가 데이터 분석 · C 전체 Wiki 설정 세부사항 · C.1 Inverted Index Filtering Strategy
분석 결과 HotpotQA 질문은 길이에서 상당한 편차를 보이며, 이는 복잡성과 세부 수준이 서로 다름을 반영한다. 전체 Wiki 설정에서는 inverted-index filtering strategy가 candidate paragraph를 효율적으로 검색하지만, gold paragraph가 누락되면 보고된 retrieval metric은 상한값이 된다.
- B 추가 데이터 분석: 질문은 길이에서 큰 편차를 보이며, 이는 HotpotQA에서 다루는 복잡성과 세부 수준이 서로 다름을 나타낸다.이는 dataset의 질문 유형 다양성을 보완한다.
- C.1 Inverted Index Filtering Strategy: 전체 Wiki 설정에서는 control threshold N = 5000으로 preliminary candidate paragraph retrieval을 수행하기 위해 효율적인 inverted-index-based strategy를 사용한다.이 strategy는 Algorithm 2에 명시되어 있다.
- C.1 Inverted Index Filtering Strategy: filter는 각 질문에서 unigram과 bigram 집합을 추출하고, candidate 수가 N 이하가 될 때까지 n-gram overlap criterion을 반복적으로 높인다.Candidate document는 ngram-to-Wikidoc inverted index에서 수집된다.
- C.1 Inverted Index Filtering Strategy: 이 절차는 각 iteration에서 크기를 갱신한 뒤 filtered candidate set Scand를 반환한다.Algorithm은 Ncands가 control threshold를 초과하는 동안 계속된다.
- C.1 Inverted Index Filtering Strategy: gold paragraph가 Scand에서 누락되면 evaluation rank를 |Scand| + 1로 설정하므로, 보고된 MAP와 Mean Rank는 실제 값의 upper bounds가 된다.이 한계는 관련 gold paragraph가 output candidate pool에 포함되지 않을 때 적용된다.
C.2 train-medium Split과 Hard Ones 비교
full-wiki 설정에서 train-medium은 retrieval metric에서 dev 및 test와 유사한 성능을 보여, retrieval 기반 처리의 난도가 비슷함을 나타낸다.
- C.2 train-medium Split과 Hard Ones 비교: full-wiki 설정에서 train-medium은 dev 및 test와 retrieval 성능 격차가 작아, 비슷한 난이도임을 시사한다.Table 9는 MAP, mean rank, answer-containing paragraph rank를 사용해 각 split에서 무작위로 추출한 1,000개 샘플을 비교한다.
- C.2 train-medium Split과 Hard Ones 비교: 이 비교에서는 full-wiki 설정의 첫 번째 처리 단계로 retrieval model이 필요하다.