Extraction-based MRC

pre-preocessing 단계에서 context와 question을 각각 word embedding한다. 모델은 context안에서 제일 확률이 높은 position을 예측한다. 후에 정답으로 변환할때는 start/end position의 span을 가져오면 될 것이다.

extraction-based mrc에서는 답변을 생성하는 것이 아니라 정답의 위치를 예측하도록 학습된다.

1. Preprocessing

가장 먼저 tokenization을 거친다. 요즘은 Out Of Vocabulary를 해결하기위해 Byte Pair Encoding 방법론 중 하나인 WordPiece를 많이 사용한다. 자주 나오는 단어는 단어별로 쪼개질테지만 덜 자주 나오는 단어는 subword로 쪼개진다.

 

[cls] 질문 [sep] 본문 [sep] [pad] [pad] ....

질문과 본문으로 구성된 입력값을 모델에게 넣어줄때 special token을 활용한다. 

 

만약에 context길이가 너무 길어서 max_seq_length를 넘어가면 어떡할까? 그런 경우에 doc_stride라는 파라미터를 활용할 수 있다.

 

doc_stride = 128

max_seq_length = 384

context 500길이인 상황을 생각해보자.

context를 두개를 쪼개고 두 문서가 공유하는 토큰의 길이가 128이 되도록 한다. 각 문서에서 답변을 구한 다음에 답변들을 취합하여 높은 확률의 정답을 가져간다.

tokenized_examples.pop("overflow_to_sample_mapping")
// [0, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15]

예를들어 
쪼개진 첫번째 문서 
(0, 0), (0, 4), (4, 5), ...

쪼개진 두번째 문서
(0, 0), (459, 460), (460, 461), ...

예를들어 총 16개의 context 중에 0번 context가 너무 길다면 아래처럼 0, 0으로 쪼개져서 리스트로 들어간다. 

tokenized_examples.pop("offset_mapping")

ex)
(0, 0), (0, 1), (1, 2), (2, 3), (3, 4), (5, 6), (6, 7), (7, 8), (9, 10), (10, 12),
[CLS]', '바', '##그', '##너', '##는', '괴', '##테', '##의', '파', '##우스'

만약 강감찬 이라는 단어가 [강, ##감찬]으로 쪼개졌다면 문서를 나누는 과정에서 저 둘 사이로 나누었을 때 문제가 된다. 정답을 각 문서에서 찾을 수 없기 때문이다. 이런 경우에는 정답 start/end로 cls_index를 반환해준다. 이 작업을 위해서 offset_mapping을 활용한다.

그렇지 않다면 재구성한 input sequence에 맞게 정답 위치에 해당하는 start/end idx도 다시 계산해서 한쌍으로 모델에게 준다.

*구체적인 동작 방식은 코드에서 살펴보자 week14/Extraction_based_MRC

 

2. fine-tuning BERT

질문의 정답이 포함된 context를 구성하는 단어들의 embedding을 linear transformation 하여 숫자를 내뱉도록 한다.

3. Post-processing

1. 모델의 예측값들에서 score가 가장 높은 N개의 정답을 찾는다.

2. 예측한 위치가 context를 벗어나는 경우, end point가 start point를 앞지르는 경우, max_answer_length를 벗어나는 경우 등을 제외해준다.

3. 후보군 중 가장 높은 score순으로 예측값을 내보낸다.