[P3] ODQA Wrap-up Report

점수 및 순위

Private LB / EM : 70.00%, F1 : 79.78% / 1위

Public LB / EM : 72.92%, F1 : 81.52% / 1위

Final Submit의 Options

Inference and Ensemble

Fine Tuning을 다르게 한 Model과 Retrieval의 Option을 다르게 한 결과를 Hard Voting

Retrieval

최적화 된 Elastic Search을 Main으로 사용 (불용어 처리, Tokenizer 등 최적화)

DPR을 활용한 Retrieval을 Sub로 사용

전체 Passage가 저장된 Wiki Data의 개행문자와 특수문자 등 제거

특정 길이를 넘어가는 Passage는 여러 개의 Passage로 처리

Sentence Transformer를 활용해서 Passage를 Sentence 단위로 구분하고, Reader에 전달

Reader Model

xlm-roberta-large 기반의 Model을 Backbone으로 사용

Question에 해당하는 Sentence의 Embedding을 활용하는 Attention 구조 추가

다양한 Filter 크기를 갖는 Convolution 연산을 활용하여, N-gram의 Idea 추가

Training

Multi Task 기반의 Model 구조로 학습 수행

Sub Task로 활용할 수 있는 대량의 Data를 활용해 Pre-training 수행

기존의 Data에 Pseudo Labeling 활용해, Question Type Classification Task 수행

성능 향상을 위해 시도한 실험

다양한 Idea와 설정으로 실험을 수행했다.

실험 List

음절단위 Tokenizing

Length에 따른 성능 실험

Pre-training에 따른 성능 실험

Question Attention Model 실험

Multi-task Learning에 대한 실험

Question Attention Conv Model 실험

실험의 근거와 의의

음절단위 Tokenizing
Baseline의 Logic을 살펴보니, End Position에 대한 Label이 엄밀하게 정확한 위치를 찾지 않음을 알게 되었다. 한국어의 특징 상 조사가 함께 Tokenizing되는 것에 착안하여, 음절단위를 순회하면서 Tokenizing하도록 구현하고 싶었다. 후처리보다는, 학습 단계에서 정확한 토큰을 학습하기를 원했기 때문이다.
해당 Code를 구현하는 것부터 매우 긴 시간이 걸렸고, 시간이 흐를수록 이 방법이 성능을 향상시킬 수 없을 것 같다는 생각이 들었다. 그 이유는, 각 음절 단위로 Tokenizing할 경우, 기존에 모델이 학습한 형태와 다른 형태로 Tokenizing되는 것이며, 이 경우에는 PLM을 사용하는 의미가 희미해지기 때문이었다.
결국, 나는 이 Logic을 완성하지 않았고, 다음 실험을 준비했다. 오수지 팀원이 이 Code를 끝까지 구현해주었고, 이에 대한 실험을 진행할 수는 있었다.
최종적으로 사용한 모델에는 이 아이디어가 포함되지 못했으나, 이를 구현하고 실험한데에 큰 의의가 있었다.

Length에 따른 성능 실험
각종 Length에 따라 성능이 변할 것 같다는 생각이 들었다. 먼저 Context를 Feature로 구분하는 Length에 대한 실험을 진행했다. 가설은 다음과 같았다.
짧은 Passage는 한 Sample내에서 정답 외의 정보를 절삭할 수 있고, 많은 Sample을 통해 학습을 진행할 수 있다는 장점이 있다.
긴 Passage는 한 Sample내에 정답과 관련된 정보가 없어지는 경우가 적을 것이고, Negative Sample이 적어져 Data의 분포를 지킬 수 있다는 장점이 있다.
위와 같은 가정을 가지고 Passage의 Length를 바꿔가며 실험을 진행했다. 결과적으로는, 무조건 짧은 것도, 무조건 긴 것도 성능에 악영향을 끼쳤다. 즉, 적당한 길이의 Feature를 만드는 것이 중요하다는 것을 알 수 있었다.
이외에도, Max Answer에 해당하는 Length와, Retrieval 단계에서 Wiki Data를 잘라내는 실험 등을 진행했다. 최종적으로 사용한 Option은 Sentence Transformer를 활용해 문장 단위로 Passage를 구분하여 Reader에 전달하도록 했다.

Pre-training에 따른 성능 실험
우리가 가진 Data가 우리의 Model을 충분히 학습시킬만한 양이 아니라고 판단했다. 이에, KorQuAD와 AI Hub에 있는 QA Data를 활용해 사전학습을 시켰다.
Custom Model은 초기화된 Parameter가 많았기에, KorQuAD로 학습을 시켰고, 이를 통해서 성능 개선을 얻을 수 있었다.
최종적으로 사용한 QAConvModel은 Multi Task Learning을 기반으로 하고 있었기 때문에, 우리가 원하는 Task의 Label을 가진 Data를 필요로 했다. AI Hub에서 제공하는 QA Data에 이와 같은 정보가 있었고, 이를 정제하여 Pretrain에 활용할 수 있었다.

Question Attention Model 실험
KLUE에서 사용했던 R-BERT처럼, Question에 해당하는 Sentence Embedding을 활용하면, 조금 더 명시적으로 Attention을 구할 수 있으리라는 생각이 들었다.
이에, Question에 해당하는 Token Embedding을 하나의 Embedding으로 바꾸고, Attention 구조를 활용하는 Model을 구현했다.
이 자체로도 큰 성과는 있었으나, 당시 사용하던 최고 모델인 Conv Model보다는 성능이 떨어졌다.

Multi-task Learning에 대한 실험
멘토님의 도움을 통해서, 이에 대한 아이디어를 얻을 수 있었다. 위 구조는 사실상, Attention을 한번 더 구하는 것에 불과하니, 추가적인 정보를 통해 Query Embedding을 더 잘 만들 수 있도록 하는게 어떠냐는 이야기였다. 이에, Question의 Type을 예측하는 Branch를 새로 구성할 수 있었다.
AI Hub를 통해 Pretrain하고, 기존의 Data로 Fine Tuning 함으로써 성능향상을 할 수 있었다.

Question Attention Conv Model 실험
최종적으로 활용한 모델은 위 아이디어와 N-gram의 아이디어를 모두 활용한 QAConvModel이었다.
위에서 사용한 Multi Task와, Pretrain을 모두 수행했고, 실제로 큰 성과를 얻을 수 있었다. 구현한 Code는 GitHub등으로 첨부하겠습니다.

P3을 통해 얻은 교훈

개선해야 할 점

조금 더 꼼꼼하게 연산을 확인하고 구현할 필요가 있겠다.

논문을 조금 더 보려고 노력하고, 아이디어에 대한 검토가 필요하다.

팀원이 실험 한 내용도 나의 것으로 만들 수 있도록 정리하고 이해해야 하겠다.

느낀 점

이번 대회를 진행하면서, 많이 좌절하고 자책감을 느꼈다. 솔직히 이전의 대회만큼 집중하지 못한 것도 사실이고, 개인의 프로젝트를 수행할 때만큼 긴장하지 않았다. 최종적으로는 좋은 성과를 냈고, 성능에 어느정도 기여한 것은 사실이나, 내가 집중하지 못했던 것도 사실이다. 내가 조금 더 많이 신경쓰고, 집중했다면 분명 더 좋은 성과를 냈으리라 생각한다.

내가 구현한 Code에 자부심도 느꼈고, 환멸도 느꼈다. 좋은 성과가 나왔을 때는 뛸듯이 기뻤고, 연산에 문제가 있던 것을 느꼈을 때는 너무나도 실망스러웠다. 너무 당연하게 생각했던게 당연하지 않았고, 돌아간다고 문제가 없던 것도 아니었다. 이 경험을 잘 간직하고, 앞으로는 더 꼼꼼하게 확인하고 사용할 수 있어야하겠다.

Uploaded by Notion2Tistory v1.1.0

[P4] Day 80 (21.05.25) (0)	2021.06.26
[P4] Day 79 (21.05.24) (0)	2021.06.26
[P3] Day 78 (21.05.21) (0)	2021.06.26
[P3] Day 77 (21.05.20) (0)	2021.06.26
[P3] Holiday 19 May (21.05.19) (0)	2021.06.26

까짓 거 해보죠!