2. [NLP] MRC 프로젝트
Last updated
Last updated
일정: 10.11 (월) ~ 11.04 (목) 19:00
팀: CLUE (7명)
활용장비
[OS] Linux version 4.4.0-59-generic
[CPU / GPU] Intel(R) Xeon(R) Gold 5220 CPU @ 2.20GHz / Tesla V100-SXM2-32GB 총 7대
[협업툴] Git-hub / Slack / Notion / Wandb
[IDE] VSCode / Jupyter lab
주요내용
기계 독해란 인공지능 알고리즘이 스스로 문제를 분석하고 질문에 최적화된 답안을 찾아내는 기술을 의미한다. 이를 활용한 Task 중 이번 대회에서는 ODQA (Open-Domain Question Answering)를 구현하는 것을 목표로 하고 있다.
ODQA란, 주어지는 지문이 따로 존재하지 않고 사전에 구축되어있는 Knowledge resource 에서 질문에 대답할 수 있는 문서를 찾고, 그 안에서 질문에 대한 답을 찾는 문제이다.
주어진 wikipedia 데이터 셋으로부터 질의에 답변하는 모델을 만드는 것을 목표로 한다.
평가방법
Exact match (EM) - 1순위
F1 score - 2순위
데이터 셋
Wikipedia Document: 56,737건
Reader 학습 데이터
input: Question , Context
output: start_index , end_index (context 내 question에 대한 answer의 위치)
실제로 제거가 필요한 데이터는 없음
학습데이터 셋이 3,952건으로 매우 적어 데이터 증강의 필요성을 확인할 수 있었다.
wikipedia의 title을 answer로 text를 context로 두고 학습을 진행
wikipedia의 text로부터 NER 태깅을 활용하여 임의의 명사를 answer로 두고 학습을 진행
🔨Question과 Answer가 제대로 맵핑되지 않는 현상이 있어, pseudo labeling을 활용하여 answer를 다시 만들고, 정확도를 기준으로 사용할 데이터를 추출.
최종학습데이터를 3,952건에서 59,667건으로 약 15배 증강.
주어진 질문과 문서와 연관성을 평가하는 알고리즘으로 BM25를 활용 → 엘라스틱서치에서도 기본 유사도 알고리즘으로 채택
Bag-of-words 개념을 사용하여 질문과 문서에 같은 단어가 등장하는 빈도를 사용
문서에 대한 빈도계산을 진행하면, 이후에는 입력되는 질문과의 비교만 진행하기 때문에 비교적 쉽게 활용이 가능하였다.
Top-k를 설정하여 k개의 문서를 가져와 보여주기 때문에 일정 갯수 이상 가져와야 성능이 오른다. 또한, KLUE dataset같은 경우 중복되는 단어가 많아서 sparse embedding이 더욱 효과적이었다.
context와 question 두가지 모델을 동시에 학습시켜야 하기 때문에 메모리 비용이 큼 → roberta-small을 base로 활용
학습 데이터가 적어 성능이 sparse embedding 방법에 비해 떨어짐→데이터 셋 자체가 어휘 유사도 기반 방법에 더 적합하게 구성된 탓도 있는 듯 함
RAG 논문에 따르면, context encoder와 question encoder가 가중치를 공유하면 더 학습 효과가 좋다고 함→실제 가중치를 공유해 학습한 결과 Best 성능이 약 20% 상승
데이터의 구성이 어휘 유사도 기반 방법에 잘 맞게 구성되어있기 때문에, 두 임베딩 방법을 잘 조합하면 더 좋은 후보 context들을 추출 할 수 있을 것이라 가정
먼저 어휘 기반(BM25)를 활용해 K개의 문서 후보를 추린후, 의미기반(Dense) 모델로 N개의 문서를 최종 선택
Dense 임베딩과 유사한 성능을 보임 → K를 300개로 두고 실험을 진행하였는데, 300개 까지는 Sparse와 Dense retriever가 동일한 후보군들을 찾아온다고 볼 수 있다. K를 줄이면 더 효율 적인 Hierarchical embedding 구조를 만들 수 있을 것 같음
Kernel 사이즈 만큼 체크함으로써 여러개를 한번에 하여 문맥을 이해하는데 도움을 주도록 함
다양한 모델로 결과를 수집하여 약 40개의 모델로 앙상블 진행
reader model: roberta-large, bert-base, koelectra, t5, sentence-bert
retrieval model: bm25, EM_sparse, dense
epoch: 3, 5, 10
Hard Voting
자연어 기반으로 voting
Probability base voting
모델이 추출한 n-best 답안의 probability를 활용해 최종 answer 결정
Retriever
BM25 (Sparse)
Sentence Bert (Dense)
Joint (Sparse + Dense)
Reader
Roberta-large
Roberta-CNN
Bert-base
Electra-base
Ensemble
Hard voting
Public EM: 70.420 / Private EM: 68.330
Git의 issue, pull request를 활용하며 저번대회보다 적극적으로 활용함
단위 Test를 통한 프로젝트 흐름파악
Poetry를 활용한 의존성 관리
체계적인 실험 계획을 통한 업무 분담진행
Reader 단에서 보다 다양한 실험을 해보지 못한점.
타대회를 병행하다보니 시간관리가 미흡했던점
코드 분석에 소요된 시간이 너무 오래 걸렸던점
EDA를 보다 다양한 방법으로 시도해 볼 것
개인적으로 아쉬움이 많이 남는 대회였다. Baseline의 Reader의 성능이 이미 상당히 높아 Reader의 성능보다 Retrival의 성능향상의 중요했었고, 주어진 코드의 구조를 이해하고 수정하기가 다소 까다롭게 되어있어서 그 부분을 이해하고, 현재 주어진 시간내에 처리하기에 너무 늦었다는 것을 깨닫기까지 오래걸렸었다. 실제로 대회에서 큰 역할을 수행하진 못했지만, EDA와 데이터 증강작업이나, 다양한 모델을 테스트하며 팀원들에게 도움이 될 수 있었고, 새로운 Task를 경험해 볼 수 있는 시간이었다.
[팀 발표 자료]
현이: 무엇을 부탁드려도 최상의 결과물을 주시는 달달함🍭에 취해보고 싶지 않은가? 슈가와 함께 해라! 누구든 그에게 중독💘될 것이다.
싸브레: "쉿, 소리없이 강하다" 항상 묵묵히 자신의 역할을 다해주시는 최고의 신랑감 🎉🎉
동긔: 핵심 적인 아이디어를 밑바닥부터 고민하는 열혈한 분석가, 구현이 모호하거나 수식이 모호하다? 앞으로 살면서 슈가와 함께하는 고민타임 만큼 군침이 나올일은 드물 것.
픠케:
로티: 그의 눈에 포착되면 도망가기는 어렵다. 빈틈없고 논리적인 사고로 문제를 하나하나 해결해나가는 그는 달콤한 AI 킬러!
조녁: 항상 가장 골치아픈 어려운 부분을 해결해주신다. 데이터를 찍어보는 실력이나 아이디어를 구현해주시는 능력이 매우 탁월하시다. 거기에 눈가 웃음의 농도는 2000%..
