2. [NLP] MRC 프로젝트

Daily 진행사항

Day1 (10.25, 월)Day2 (10.26, 화)Day3 (10.27, 수)Day4-5 (10.28-29, 목-금)Day6 (11.1, 월)Day7 (11.2, 화)Day8 (11.3, 수)Day9 (11.4, 목)

https://jonhyuk0922.notion.site/_level2_-MRC_13-7bdc5e677ff84b29ad52003f473fe625jonhyuk0922.notion.site

Team Wrapup Report

1. 개요

• 일정: 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의 위치)

Train Data for Reader Sample

WikiPedia Data Sample

2. 프로젝트 수행

2.1. EDA

1) 중복데이터 체크

• 실제로 제거가 필요한 데이터는 없음

2) 학습데이터의 부족

학습데이터 셋이 3,952건으로 매우 적어 데이터 증강의 필요성을 확인할 수 있었다.

2.2. 데이터 증강 작업

Question Generation with Pororo

• wikipedia의 title을 answer로 text를 context로 두고 학습을 진행

• wikipedia의 text로부터 NER 태깅을 활용하여 임의의 명사를 answer로 두고 학습을 진행

• 🔨Question과 Answer가 제대로 맵핑되지 않는 현상이 있어, pseudo labeling을 활용하여 answer를 다시 만들고, 정확도를 기준으로 사용할 데이터를 추출.

• 최종학습데이터를 3,952건에서 59,667건으로 약 15배 증강.

2.3. 모델 분석 및 Custom(Retrieval)

Sparse Embedding

• 주어진 질문과 문서와 연관성을 평가하는 알고리즘으로 BM25를 활용 → 엘라스틱서치에서도 기본 유사도 알고리즘으로 채택

• Bag-of-words 개념을 사용하여 질문과 문서에 같은 단어가 등장하는 빈도를 사용

• 문서에 대한 빈도계산을 진행하면, 이후에는 입력되는 질문과의 비교만 진행하기 때문에 비교적 쉽게 활용이 가능하였다.

• Top-k를 설정하여 k개의 문서를 가져와 보여주기 때문에 일정 갯수 이상 가져와야 성능이 오른다. 또한, KLUE dataset같은 경우 중복되는 단어가 많아서 sparse embedding이 더욱 효과적이었다.

Dense Embedding

• context와 question 두가지 모델을 동시에 학습시켜야 하기 때문에 메모리 비용이 큼 → roberta-small을 base로 활용

• 학습 데이터가 적어 성능이 sparse embedding 방법에 비해 떨어짐→데이터 셋 자체가 어휘 유사도 기반 방법에 더 적합하게 구성된 탓도 있는 듯 함

• RAG 논문에 따르면, context encoder와 question encoder가 가중치를 공유하면 더 학습 효과가 좋다고 함→실제 가중치를 공유해 학습한 결과 Best 성능이 약 20% 상승

Hierarchical embedding

• 데이터의 구성이 어휘 유사도 기반 방법에 잘 맞게 구성되어있기 때문에, 두 임베딩 방법을 잘 조합하면 더 좋은 후보 context들을 추출 할 수 있을 것이라 가정

• 먼저 어휘 기반(BM25)를 활용해 K개의 문서 후보를 추린후, 의미기반(Dense) 모델로 N개의 문서를 최종 선택

• Dense 임베딩과 유사한 성능을 보임 → K를 300개로 두고 실험을 진행하였는데, 300개 까지는 Sparse와 Dense retriever가 동일한 후보군들을 찾아온다고 볼 수 있다. K를 줄이면 더 효율 적인 Hierarchical embedding 구조를 만들 수 있을 것 같음

2.4. 모델 분석 및 Custom(Reader)

CNN Header 추가

• Kernel 사이즈 만큼 체크함으로써 여러개를 한번에 하여 문맥을 이해하는데 도움을 주도록 함

2.5. Model Ensemble

다양한 모델로 결과를 수집하여 약 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 결정

3. 최종 모델 및 결과

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

4. Summary

4.1. Good

• Git의 issue, pull request를 활용하며 저번대회보다 적극적으로 활용함

• 단위 Test를 통한 프로젝트 흐름파악

• Poetry를 활용한 의존성 관리

• 체계적인 실험 계획을 통한 업무 분담진행

4.2. Have to do better

• Reader 단에서 보다 다양한 실험을 해보지 못한점.

• 타대회를 병행하다보니 시간관리가 미흡했던점

  • 코드 분석에 소요된 시간이 너무 오래 걸렸던점

• EDA를 보다 다양한 방법으로 시도해 볼 것

개인적으로 아쉬움이 많이 남는 대회였다. Baseline의 Reader의 성능이 이미 상당히 높아 Reader의 성능보다 Retrival의 성능향상의 중요했었고, 주어진 코드의 구조를 이해하고 수정하기가 다소 까다롭게 되어있어서 그 부분을 이해하고, 현재 주어진 시간내에 처리하기에 너무 늦었다는 것을 깨닫기까지 오래걸렸었다. 실제로 대회에서 큰 역할을 수행하진 못했지만, EDA와 데이터 증강작업이나, 다양한 모델을 테스트하며 팀원들에게 도움이 될 수 있었고, 새로운 Task를 경험해 볼 수 있는 시간이었다.

[팀 발표 자료]

4MB

MRC 대회_자원팀(13조)_발표자료.pdf

PDF

Open

동료 평가

• 현이: 무엇을 부탁드려도 최상의 결과물을 주시는 달달함🍭에 취해보고 싶지 않은가? 슈가와 함께 해라! 누구든 그에게 중독💘될 것이다.

• 싸브레: "쉿, 소리없이 강하다" 항상 묵묵히 자신의 역할을 다해주시는 최고의 신랑감 🎉🎉

• 동긔: 핵심 적인 아이디어를 밑바닥부터 고민하는 열혈한 분석가, 구현이 모호하거나 수식이 모호하다? 앞으로 살면서 슈가와 함께하는 고민타임 만큼 군침이 나올일은 드물 것.

• 픠케:

• 로티: 그의 눈에 포착되면 도망가기는 어렵다. 빈틈없고 논리적인 사고로 문제를 하나하나 해결해나가는 그는 달콤한 AI 킬러!

• 조녁: 항상 가장 골치아픈 어려운 부분을 해결해주신다. 데이터를 찍어보는 실력이나 아이디어를 구현해주시는 능력이 매우 탁월하시다. 거기에 눈가 웃음의 농도는 2000%..