프로젝트 주제 | 문장 내 개체간 관계 추출(KLUE RE): 문장의 단어(Entity)에 대한 속성과 관계를 예측하는NLP Task |
---|---|
프로젝트 구현내용 | 1. Hugging Face의 Pretrained 모델과KLUE RE 데이터셋을 활용해 주어진 subject, object entity간의 30개 중 하나의 relation 예측하는 AI 모델 구축2. 리더보드 평가지표인 Micro F1-Score와AUPRC 높은 점수에 도달할 수 있도록 데이터 전처리(Entity Representation), 데이터 증강, 모델링 및 하이퍼 파라미터 튜닝을 진행 |
개발 환경 | GPU: Tesla V100 서버 4개 (RAM32G) /Tesla V4 (RAM52G) /GeForce RTX 4090 로컬 (RAM 24GB)개발 Tool: PyCharm, Jupyter notebook, VS Code [서버 SSH연결], Colab Pro +, wandb |
협업 환경 | Github Repository: Baseline 코드 공유 및 버전 관리Notion: KLUE 프로젝트 페이지를 통한 역할분담, 대회 협업 관련Ground Rule 설정, 아이디어 브레인 스토밍, 대회관련 회의 내용 기록 SLACK, Zoom: 실시간 대면/비대면 회의 |
- 모더레이터 외에도 Github 관리자를 두어 베이스라인 코드의 버전 관리를 원활하게 하고, 같은 분야라도 다른 작업을 진행할 수 있도록 분업을 하여 협업을 진행하였다.
이름 | 역할 |
---|---|
강민재 | EDA(길이, 레이블, 토큰, entity편향 확인), Error Analysis, 데이터 증강(단순 복제, class inverse관계 교체 증강), 데이터 전처리(subject, object entity 스페셜 토큰 처리) |
김태민 | 모델 실험(Attention layer 추가 실험, Linear/LSTM layer 추가 실험, Loss, Optimizer 실험), 데이터 전처리(Entity Representation – ENTITY, Typed Entity) |
김주원 | 모델 튜닝, 프로젝트 매니저(노션관리, 회의 진행), EDA, 모델 앙상블(Hard Voting, Soft Voting, Weighted Voting), Error Analysis(Error Analysis 라이브러리 개발) |
윤상원 | Github 베이스라인 코드 관리(코드 리팩토링, 버그 픽스, 코드 버전 컨트롤), 모델 실험(TAPT 적용), 데이터 전처리(Entity Representation – ENTITY, Typed Entity), EDA(UNK 관련 EDA), 모델 튜닝 |
신혁준 | EDA(데이터 heuristic 체크, Label 별 관계 편향 조사), 데이터 증강 (동일 entity start_idx, end_idx 교체, Easy Data Augmentation – SR 기반 증강, 클래스 Down Sampling) |
팀 협업을 위해 개선점 파악을 위해 지난 NLP 기초 프로젝트 관련한 회고를 진행하였다. 회고를 바탕으로 프로젝트의 팀 목표인 “함께 성장”과 “실험 기록하기”를 설정했다. 그리고 목표를 이루기 위한 Ground Rule을 설정하여 프로젝트가 원활하게 돌아갈 수 있도록 팀 규칙을 정했다. 또한, 날짜 단위로 간략한 목표를 설정하여 협업을 원활하게 진행할 수 있도록 계획을 하여 프로젝트를 진행했다.
3.1 협업 관련 Ground Rule
-a. 실험 & 노션 관련 Ground Rule: 본인 실험을 시작할 때, Project 대시보드에 본인의 작업을 할당한 뒤 시작한다. 작업은 ‘하나의 아이디어’ 단위로 생성하고 Task, 진행상태를 표시한다. 작업이 마무리되면 실험 결과가 성능의 향상에 상관없이 ‘실험 대시보드’에 기록하고 상태를 완료 표시로 바꿔 마무리한다. 작업 단위로 관리하되 그 실험을 어떤 가설에서 진행하게 되었는지, 성공했다면 성공했다고 생각하는 이유, 실패했다면 실패한 원인에 대해 간략하게 정리한다.
-b. Commit 관련 Ground Rule:
- 1. 전체 main branch Pull Request 관련 Rule : main branch에 대한 pull request는 Baseline Code를 업데이트할 때마다 진행한다. commit message에는 점수, 데이터, 버전 내용이 들어가도록 작성하고 push 한다
- 2. 개인 Branch Commit 관련 Rule : git commit & push는 코드의 유의미한 변화가 있을 때마다 진행한다. Commit message에는 코드 수정 내용(추가/변경/삭제)이 들어가도록 작성하고 push 한다.
-c. Submission 관련 Ground Rule: 사람별로 submission 횟수는 2회씩 할당한다. 추가로 submission을 하고 싶으면 SLACK 단체 톡방에서 다른 캠퍼에게 물어봐 여유 횟수를 파악한 뒤 추가 submission을 진행한다. Submission을 할 때 다른 팀원이 어떤 실험의 submission인지 파악할 수 있도록 사용한 모델, 데이터, 기법, 하이퍼파라미터 등이 들어갈 수 있도록 Description을 기재한다.
-d. 회의 관련 Ground Rule: 전원이 진행하지 않는 Small 회의는 다양한 방식(Zep, Google Meet, Zoom)으로 진행하고 회의 내용을 기록한다.
3.2 프로젝트 진행 Time line
- 세부적인 대회 진행 절차는 아래와 같다.
순위 | 분류 | micro_f1 | auprc | 제출 횟수 |
---|---|---|---|---|
7 | Public Score (대회 진행) | 75.5115 | 80.5521 | 53 |
8 | Private Score(최종) | 73.9434 | 82.7705 | 53 |
지난번 대회에서 나왔던 피드백인 다음 대회에서는 모델을 직접 커스터마이징을 해보자는 의견에 따라, 기존 huggingface trainer로 짜여 있던 베이스라인 코드에서 상대적으로 모델을 커스터마이징하기 용이한 pytorch lightning으로 리팩토링을 진행했다.
-a. 문제점 해결: 기존의 baseline에서 subject와 object를 파싱하는 부분에서 딕셔너리 형태의 값을 문자열로 읽어와서 ‘,’와 ‘:’를 구분자로 하여 분리하고 있기 때문에 ‘,’ 또는 ‘:’가 객체 안에 들어가 있는 경우, 객체의 값을 잘못 파싱한다는 문제점이 있다는 것을 파악하고, 해당 부분의 버그를 수정했다.
- b. 기록 방식 보안: f1 score와 loss, learning rate, confusion matrix와 같은 다양한 지표들을 로그로 남겨 학습 진행 상황을 실시간으로 확인할 수 있게 하였고, wandb와 연동하여 이를 시각적으로 확인하고, 기록을 남길 수 있게 했다.
- c. 수정이 쉬운 코드: 베이스라인과 달리config parser와 yaml파일을 이용하여 팀원들이 수정하기 쉽고, hard coding시 발생할 수 있는 부분들을 최소화할 수 있도록 베이스라인 코드를 배포하여 팀원이 실험을 원활하게 진행할 수 있도록 하였다.
코드에 대한 깊은 이해 없이, 의도치 않은 방식으로 코드가 동작하는 상황이 없게끔 pytorch lightning의 공식 문서[1]와 소스 코드를 확인하며 구현했다. 또한, 팀원 모두가 사용하는 베이스라인 코드이다 보니, 팀원들이 코드를 확장하기 쉽도록, 토크나이저에 special token을 추가할 수 있도록 구성하고, 모델의 embedding layer의 크기를 토크나이저의 크기와 맞추는 등 예외 상황들을 고려하여 코드를 구현했다.
4.2. EDA(Exploratory Data Analysis)
주어진 데이터의 문장의 길이 관련, 클래스 분포, 데이터 Entity와 관련된 데이터 분석을 진행했고, 이를 통해 문제 해결 전략을 수립하였다. 분석을 바탕으로 가설을 세웠다.
4.2.1 라벨 분포 관련 EDA
train data의 정답(label) 클래스가 총 30개이며, 각 클래스별 데이터 개수를 확인하였다. no-relation을 비롯한 3개 클래스가 유독 많은 데이터를 차지함을 확인하였다. 이번 task의 평가 지표인 micro-f1 점수를 구할 때 제외되는 no-relation을 차치하더라도, 아래의 그래프에서 확인 할 수 있듯이 가장 적은 데이터를 갖는 per:place_of_death와 가장 많은 데이터를 갖는 org:top_members/employees의 데이터 개수 차이가 100배 이상임을 확인하였다. 따라서 train data에서 class imbalance를 발견하였고, validation data가 주어지지 않은 상황에서 적절한 데이터 split과 증강이 필요하다고 판단하였다.
4.2.2문장 길이/Tokenizing 관련 EDA
Train data의 원본 문장의 길이 분포를 확인하였고, 원본 문장에 대해서 sentence length가 250을 초과하는 데이터를 outlier로 설정하였다. 분석 결과 sentence length에 대한 outlier가 존재함을 발견하였다. 추가로 베이스라인 모델인 klue/bert-base의 토크나이저로 토큰화한 문장에 대한 길이 분포도 원본 문장과 유사함을 확인하였다.길이 편향에 대한 가설을 설정하기 위해서는 전체 데이터에 존재하는 문장 길이에 대한 outlier의 개수보다는, 각 클래스별로 outlier의 비율을 확인하는 게 의미가 있다고 판단하였다.
org:political/religious_affiliation를 제외하고는 길이가 긴 문장의 비율이 특히 높은 클래스는 없었다. sentence length에 대한 outlier 비율이 높은 ‘org:political/religious_affiliation’ 클래스에 대해서는 길이에 대한 편향이 발생할 수 있다고 판단하였다.
Description automatically generated](Aspose.Words.4e3426ec-b5cf-4d77-8968-6af129d00693.007.png)
분류 | 문장 |
---|---|
원본 데이터 | 결국, 대한민국 정부의 반대에도 불구하고 주한미군은 약 500명의 군사고문단만 남기고 마지막 남아 있던 부대가 1949년 6월 29일 철수하였다. |
학습데이터의 Masking 예시 | 결국, 대한민국 정부의 [MASK] 불구하고 주한미군은 약 500명의 군사고문단만 남기고 마지막 남아 있던 부대가 1949년 6월 29일 철수하였다. |
증강이전 데이터의 Masking 예시 | 결국, 대한민국 정부의 반대에도 불구하고 주한미군은 [MASK] 약 500명의 군사고문단만 남기고 마지막 남아 있던 부대가 1949년 6월 29일 철수하였다. |
증강 이후 데이터 | 결국, 대한민국 정부의 반대에도 불구하고 주한미군은 당시 약 500명의 군사고문단만 남기고 마지막 남아 있던 부대가 1949년 6월 29일 철수하였다. |
- a. 구현 방법: 아래와 같이 학습할 때는 아래와 같이 train과 test 데이터의 기존 문장에 랜덤하게 MASK 토큰을 씌워 klue/roberta-large 모델을 이용하여MLM 학습을 2 epoch만큼 진행한다. 이후에 데이터 증강을 진행할 때는 train data에 대해서만 증강하고, 랜덤하게 Mask 토큰을 을 단어에 씌우는 게 아닌 단어와 단어 사이에 배치한다. 그리고 모델에서 mask에 대한 확률적으로 높은 n개의 예측 토큰을 뽑아낸 뒤, 디코딩을 진행한다. 따라서 새롭게 증강된 모델은 기존 train 데이터에서 관계가 바뀌지 않은 채 원본 문장 하나에서 하나의 토큰이 추가된 n개의 문장 데이터를 생성한다.
문장을 생성한 뒤 분포가 이미 풍부히 많고 error analysis 결과 확인 된 f1-score가 높은 여섯 개의 class (no_relation, per:title, org:place_of_headquarters, per:employee_of, per:date_of_birth, org:member_of)를 제외한 나머지 클래스 데이터를 랜덤하게 sampling하여 2만개의 데이터를 증강하여 아래와 같은 분포를 띄는 증강 데이터를 만들었다.
- b. 구현 이유(가설) :. 해당 기법으로는 증강시 문장 안에 있는 띄어쓰기 수만큼 마스킹을 진행할 수 있고, 각 Masking마다 확률적으로 높은 토큰의 단어를 여러 개를 선택하여 조합할 수 있어서 많은 양의 데이터를 증강하여 분포를 맞출 수 있다고 생각했다. 따라서 해당 기법으로 앞서 EDA를 통해 살펴보았던 데이터의 class 불균형 문제를 해소하여 성능 향상을 가져올 것이라고 판단했다. 또한 BERT는 positional Embedding을 통해 구조를 학습하게 되기 때문에 이러한 방식으로 증강을 할 경우 문장에 작지만 일부 구조적인 변화를 가지고 올 수 있기 때문에 학습을 할 경우 더 어려운 데이터로 학습하게 되지만, 그 만큼 성능이 오를 것이라고 판단했다.
- c. 결과: klue/bert-base 모델에서 public score가 64.5점에서 66점으로 1.5점 상승했다.
-a. 가설: An Improved Baseline for Sentence-level Relation Extraction 논문[2]을 참고하면 아래와 같이 새로운 Entity Representation를 적용할 경우 두 개체 간의 관계를 더 정확하게 추론하는 RE Task에서 성능 향상을 이뤄낸 것을 확인 할 수 있었다. 따라서 논문[2]에 제시된 Entity Marker, Punct Entity marker, Typed Entity Marker 등을 적용한다면 성능의 향상이 이뤄진다고 생각했다.
-b. 구현 내용 & 결과 : 아래와 같은 example이 출력될 수 있도록 Entity Marker, Typed Entity, SUB/OBJ marker, Punct Entity Marker를 구현하고 klue/roberta-large, klue/bert-base에 적용하였다. 모든 entity에서 0.8~3.4점 정도의 성능 향상이 이루어졌다.
Method | Input Example | bert(base) | RoBerta(large) |
---|---|---|---|
Baseline | 〈Something〉는 ‘조지 해리슨’이 쓰고 ‘비틀즈’가 1969년 앨범 《Abbey Road》에 담은 노래다. | 64.5 | 67.1 |
Entity marker | 〈Something〉는 [Entity]조지 해리슨[/Entity]이 쓰고 [Entity]비틀즈[/Entity]가 1969년 앨범 《Abbey Road》에 담은 노래다. | 66.5(+2.0) | - |
Typed entity marker | 〈Something〉는 [PER]조지 해리슨[/PER]이 쓰고 [ORG]비틀즈[/ORG]가 1969년 앨범 《Abbey Road》에 담은 노래다. | 66.7(+2.2) | - |
SUB,OBJ marker | 〈Something〉는 [OBJ]조지 해리슨[/OBJ]이 쓰고 [SUB]비틀즈[/SUB]가 1969년 앨범 《Abbey Road》에 담은 노래다. | 65.3(0.8) | - |
punct(한글) | 〈Something〉는 @*사람*조지 해리슨@이 쓰고 @*단체*비틀즈@가 1969년 앨범 《Abbey Road》에 담은 노래다. | - | 70.8(+3.4) |
* ‘-‘ 로 체크 된 부분은 시간 관계상 실험이 진행되지 못한 부분임
* punct에서는 논문[2]에서는 영어로 표기 되지만, 한국어 데이터임으로 한국어 데이터에 맞게 수정하여 구현하였음.
4.5.1 CLS-Entity Attention
-a. 가설 : CLS Token은 문맥의 모든 정보를 담아내고 있으며 각 토큰의 객체 정보만을 남겨서 Attention을 진행해주어 이를 최종 입력에 더해줌으로써 조금 더 문맥에서 집중해야 할 객체 정보를 표기할 경우 모델이 객체를 보다 더 잘 인식할 것이다.
-b. 구현 방법 : 객체 토큰만 1이고 나머지가 0인 index_ids라는 텐서를 만들고 torch.zeros를 통해 Attention 입력과 동일한 사이즈의 텐서를 만들어준다. 이를 index ids와 결합하여 객체 토큰의 정보만 1이고 나머진 0인 텐서를 만든다. 추후 객체 토큰 텐서(0,1만있는 output size와 동일한 tensor)와 기존 모든 토큰(roberta output token)을 곱셈하여 객체 토큰 텐서의 정보만 유지해주고 이를 CLS token과 Attention을 진행해 최종 입력에 더해준다.
-c. 결과 : 기존 Typed Entity 적용된 klue/roberta-large 모델이 70점이었으나, 해당 모델에 CLS-Attention을 적용한 기법은 71점으로 1점 정도의 성능향상을 이뤄냈다.
-a. 가설: 기존 RE task 말고 NER task도 함께 수행하여 BIO 태깅 정보까지 학습에 활용한다면. 각 토큰의 태깅 명까지 유추함으로 모델이 조금 더 객체에 집중할 것이라고 가설을 세웠다.
-b. 구현방법: 각 토큰 SUB, OBJ 토큰들을 기준으로 type을 BIO 태깅으로 한 라벨을 생성해낸다. 이를 모델 학습 코드에서 활용하여 최종적인 기존 RE task의 loss와 NER task의 loss를 서로 더하여 역전파를 시켜준다.
-c. 결과: klue/roberta-large 모델에 CLS-Token Attention과 함께 적용하여 72.7점의 f1-score가 나왔고, 기존 CLS-Token Attention 모델의 71점보다 1.7점 상승하였다.
- a. 가설: Enriching Pre-trained Language Model with Entity Information for Relation Classification 논문[3]에서 나온 R-BERT의 경우 모든 토큰의 정보를 취합하여 새로운 Linear layer를 정의한다. 논문[3]의 내용과 마찬가지로 한글 task에서도 성능 향상이 있을 것이라고 생각하였다.
- b.구현방법: CLS Token 그리고 각 객체 토큰들은 Average 하여 Fully Connected layer 와 tanh 활성화 함수를 통과시킨다. 추후 마지막 차원으로 모든 토큰을 concat 시켜 이를 Fully Connected layer 에 넣어준다. klue/bert-base는 256차원의 FC layer를 이용했고, klue/roberta-large는 512 차원의 FC layer를 이용했다.
- c. 결과 :klue/bert-base 모델과 klue/roberta-large에 적용하였고 적용 전후로 각각 아래와 같이 성능이 향상하였다.
klue/bert-base | klue/roberta-large | |
---|---|---|
Baseline 모델 | 64.5 | 67.1 |
FC Layer 적용 이후 | 66.0(+1.5) | 67.4(+0.3) |
4.5.3. TAPT
- a. 가설: Don't Stop Pretraining: Adapt Language Models to Domains and Tasks 논문[4]에서 Task에 특화된 적은 양의 데이터를 한번 더 사전 학습시킴으로써 모델의 성능이 올랐다는 내용을 참고하여 문장 내 개체 간 관계 추출 task에 특화된 데이터를 사전 학습시키면 해당 유형의 문장들에 대한 이해도가 높아져 모델의 성능이 좋아질 것이다 라는 가설을 세웠다.
-b.구현 방법: 이번 대회에서 주어진 train 데이터와 test 데이터를 데이터 셋으로 활용하여 사전 학습된 모델에 추가로 Masked Language Modeling을 실시했다. 1 epoch 학습을 진행하였고, learning rate는 모델을 제안한 논문[4]을 조사하여 사전 학습에서 사용된 learning rate의 1/10 값을 사용했다.
- c. 결과 : klue/bert-base 모델의 경우, public f1 score 기준 TAPT를 적용한 이후 64.5점에서 65.4점으로 올라 0.9점가량 상승하였고, klue/roberta-large 모델의 경우, public f1 score 기준 TAPT를 적용한 이후 67.1점에서 68.7점으로 올라 1.6점 가량 상승했다.
4.5.4 Optimizer, Loss 수정
- a. AdaBelief Optimizer: Adapting Stepsizes by the Belief in Observed Gradients 논문[5]에서 AdamW대신Adabelief 를 사용하여 BLEU score를 0.2점 정도 높인 것을 확인하였다. 따라서 이 optimizer를 활용한다면 성능 향상을 이뤄낼 수 있을 것이라고 생각하여 adabelief-pytorch의 라이브러리를 활용하여 optimzer를 Adablief로 교체했고, 기존 klue/bert-base베이스라인에서 public이 64.5이었던 점수를 Adabelief는 66.9로 약 2.4 점 가량 성능을 향상시켰다.
-b. Focal Loss: 기존의 Cross Entropy 함수는 클래스 불균형에 대해 약한 경우가 있다. Focal Loss for Dense Object Detection 논문[6]에서 해당 경우에 Loss 함수를 Focal Loss함수로 클래스 불균형에 강하다는 실험 결과를 확인하였다. 따라서, 데이터셋이 클래스 불균형이 심해 효과가 있을 것이라고 생각하였고, 이를 적용하였다. 그 결과 성능 향상은 미비하지만 R-BERT 모델에서 66.4에서 66.5로 성능이 0.1점 상승함을 확인하였다.
4.6 모델 앙상블
앙상블은 다음과 같은 총 3가지 테크닉을 이용해서 진행했다.
- a. Hard Voting 앙상블: 여러 개의 모델 중 가장 많은 모델이 예측한 class를 최종적으로 선택하는 방식으로 앙상블을 진행했다. 동점 클래스가 발생하여 가장 많이 예측한 클래스가 2개 이상일 경우 최종 후보군의 클래스 들 중 확률이 더 높은 값을 선택하여 앙상블을 진행했다.
- b. Soft Voting 앙상블: 모델들의 예측 확률을 클래스 별로 모두 더해 평균을 구해 가장 높은 평균을 가진 클래스를 선택하는 방식으로 앙상블을 진행했다.
- c. F1-Score Weighted 앙상블: 각 모델들의 f1-score을 softmax값을 취해 각 모델의 확률에 곱하여 가중치를 부여한다. 이후 해당 모델들의 클래스 별로 합을 구하고, 평균을 취해 가장 높은 확률을 가진 class를 추가하여 모델의 점수를 구했다.
위의 모델 기법 및 증강데이터를 선택하여 적용한 모델들을 세가지 앙상블을 적용해 여러 번 실험을 진행했다. 최종적으로 klue/roberta-large 모델에서 TAPT를 적용한 모델 들 중 Punct Entity Marker가 적용된 모델, 일반 Entity Marker가 적용된 모델, label smoothing과 증강 데이터가 적용된 모델 총 세개의 모델을soft voting기법으로 만든 앙상블을 진행했고, private micro-f1 score가 73.9434이고, AUPRC가 82.7705점의 점수를 얻을 수 있었다.
- 베이스라인 코드를 pytorch lightning으로 리팩토링하여 모델을 직접 커스터마이징해 볼 수 있었다.
- 노션에 모든 실험을 기록하며 대회를 진행했다.
- 파트장을 통한 깃허브 버전 관리가 우수했다.
- 실험 기록에 대한 체계를 구체화하였고, 팀원들이 모두 대회 시작 이전에 정한 룰에 따라서 각자의 역할을 수행하였다
5.2 실험에서 실패한 증강 실험
-a. 단순 복제 증강: EDA 과정에서 길이에 대한 편향의 발생 가능성을 확인했음에도 불구하고, 심각한 label imbalane로 다른 증강 기법의 한계로 인해 단순 복제 증강을 수행하였다. 따라서 일부 클래스는 같은 문장이 20번 이상 반복되었고, 이에 따라 길이에 대한 편향이 발생하여 성능이 저하되었다고 생각한다.
-b. SUB/OBJ Entity swap을 통한 증강: org:members 와 org:members와 같이 역관계에 있는 entity의 데이터를 Entity swap을 통해 데이터를 증강하고 관계가 달라진 부분을 반영해 대응하는 클래스로 label을 변경한느 방식으로 증강하였다.또한, subject와 object에 대한 학습이 원활하게 이루어지도록 데이터 피딩 방식을 변경하였다. 이 과정에서 스페셜 토큰을 총 24개 추가하였는데, 너무 많은 스페셜 토큰을 추가한 데 비해 일부 클래스에서 학습 데이터가 충분하지 않았기 때문에 오히려 모델 학습에 방해가 되었다고 생각한다. 추가로 데이터 증강 섹션에 첨부한 figure에서 확인할 수 있듯이, 일부 클래스를 대상으로만 증강이 적용되어, 여전히 label imbalance 문제가 남아있는 상태였기 때문에 증강 기법의 완성도 측면에서도 문제가 있었다고 생각한다.
-c. Downsampling: Label 분포 비율이 높은 'no_relation', ‘org:top_members/employees', 'per:employee_of'를 1500까지 줄여 분포를 맞췄다. Downsapling 이후 Public Micro F1 Score가 62.18에서 58.43으로 하락했다.
5.3 프로젝트 협업 프로제스에서 아쉬웠던 점
- log를 wandb뿐만 아니라, 파일로도 확인할 수 있도록 python의 기본 라이브러리인 logging을 사용해서 실험 결과를 확인할 수 있도록 해야될 것 같다.
- 그리고 베이스라인을 수정하고 파이토치 라이트닝을 써보면서 라이트닝만의 장단점을 알 수 있었다.
- wandb 그리고 노션을 통한 기록이 중요하다고 생각된다.
5.4 프로젝트를 통해 배운점 또는 시사점
- 직접 loss function, optimizer, lr scheduler 등을 수정하면서 이러한 요소들이 모델 학습에 미치는 영향을 더 직관적으로 느낄 수 있었다.
- Data 증강할 때는 구체적으로 가설을 나누어서 세우고 증강해야겠다. 단순히 Data 분포를 맞추겠다는 목표보다 error anslysis를 기반으로 조금 더 세밀하게 증강해야겠다.
- 문제를 해결할 때, 주어진 문제를 단계별로 쪼개어 적절한 문제정의를 단계별로 해석하는 것이 중요하다는 점을 깨달았다. 또한 필요에 따라서는 ML/DL 기법 뿐만이 아닌 사람이 직접 데이터를 살펴보고 rule base 알고리즘을 적절히 적용하는 것도 모델 성능을 향상할 수 있는 방법임을 배웠다.
[1] Pytorch Lightning 공식 Document, https://lightning.ai/docs/pytorch/latest/
[2] Wenxuan Zhou, Muhao Chen, An Improved Baseline for Sentence-level Relation Extraction, ACL (pp161–168), Feb 2021
[3] Shanchan Wu, Yifan He, Enriching Pre-trained Language Model with Entity Information for Relation Classification, CIKM '19: Proceedings of the 28th ACM International Conference on Information and Knowledge Management, Pages 2361–2364, May 2019
[4]Suchin Gururangan, Ana Marasović, Swabha Swayamdipta, Kyle Lo, Iz Beltagy, Doug Downey, Noah A. Smith. Don't Stop Pretraining: Adapt Language Models to Domains and Tasks. ACL, April 2020.
[5] Juntang Zhuang, Tommy Tang, Yifan Ding, Sekhar Tatikonda, Nicha Dvornek, Xenophon Papademetris, James S. Duncan, AdaBelief Optimizer: Adapting Stepsizes by the Belief in Observed Gradients ,NeurlPS2020,Oct 2020
[6] Tsung-Yi Lin, Priya Goyal, Ross Girshick, Kaiming He, Piotr Dollár, Focal Loss for Dense Object Detection, ICCV, Aug 2017
NLP KLUE 프로젝트(Relation Extraction Project Report) NLP-08조 팀 회고
1. 나는 내 학습 목표를 달성하기 위해 무엇을 어떻게 했는가?
이번 대회는 저번 대회와는 달리 각 파트를 집중적으로 나누어 진행하였다. 저번 대회는 모델의 전체적인 총괄을 맡았지만 그 대신 이번 대회에서 모델링에 기법에 대해 집중적으로 탐색하고 파고들었다. 이번 대회에 내가 맡은 파트인 모델링을 달성하기 위해 각종 논문과 지금까지 해온 모델링 기법으로 나만의 모델을 만들며 NLP task에 대한 모델링에 대해 집중적으로 파고들 수 있었다.
2. 마주한 한계는 무엇이며, 아쉬웠던 점은 무엇인가?
개인적으로 모델로는 점수 향상이 있었지만 데이터에서의 유의미한 큰 점수 향상은 존재하지 않았다고 볼 수 있다. 모든 대회의 기본은 모델보다 데이터가 중요한 것은 알고 있었다. 또한 모델로는 성능을 올리는데 어느 정도 한계점이 분명하며 한국어는 더욱 그렇다. 데이터가 아쉬운 부분과 또 아쉬운 점으로는 모델링은 성공적이었지만 모든 모델을 학습에 사용할 때 통합된 환경을 갖추지 못한 것과 모델은 만들었어도 쉽게 불러다쓰지못하고 하드코딩으로 진행한 방식이 아쉬운 부분으로 남았다.
3. 한계/교훈을 바탕으로 다음 프로젝트에서 시도해보고 싶은 점은 무엇인가?
부스트 캠프의 슬로건인 함께 성장하자는 마인드와 같이 이번에는 모델링을 담당하였지만 다음 대회에는 데이터를 담당할 예정이다. 기존 다른 외부 대회에서 모든 부분을 혼자서 처리하였는데 점수의 직접적인 데이터 파트만 시도해본다면 데이터 분석의 실력이 향상 될 것이라고 생각된다.
4. 나는 어떤 방식으로 모델을 개선했는가?
기존의 논문에 나와 있는 모델들을 가장 먼저 구현하였다. RBERT와 같은 모델들을 기반으로 백본 모델을 교체하거나 임베딩 레이어의 추가 등등 가장 확실하게 성능 향상이 입증된 부분부터 차례대로 구현하였다. 추후 커스터마이징하게 나만의 모델을 구성하였는데 처음 허깅페이스의 모델 레이어를 수정하여도 기존에 입증된 모델들을 먼저 구현하여 보다 쉽게 나만의 모델을 만들 수 있었다. 구현된 모든 모델은 위에 나와 있다.
5. 내가 해본 시도중 어떠한 실패를 경험 했는가? 실패의 과정에서 어떠한 교훈을 얻었는가?
모델링과 전처리의 시도 중에서 점수의 실패보단 순서의 실패가 가장 눈에 보였다. 논문에서 가장 높은 점수에 해당하는 전처리 방법이 있음에도 불구하고 모든 방법을 구현하고 2번째로 높은 방법을 기준으로 추후 전처리 코드와 모델들을 연결한 점이 실수였다. 각 모델별로 수행해야 할 전처리 방법이 다른데 최종적으로 제일 높은 점수의 모델은 1번째로 높은 전처리 방법에 기본 Base 모델을 강제적으로 사용할 수밖에 없었다. 2번째 높은 방법과 기존 모델들을 연결해 만들었던 점이 1번째 방법에 가장 높은 성능의 모델을 연결할 수 없었단 부분이 실패였다. 2번쨰로 높은 방법을 기준으로 한 이유는 val score를 보고 결정하였는데 각 seed 별로 다를 수 있는 점을 간과하였다. 추후 방식부터는 방법이 의미가 있는지 없는지에 대한 검증과 score는 보다 엄격하게 여러 번을 수행하여 평균을 내야 한다고 경험하였다. 또한 다양한 모델들을 항상 언제 어디서든 통합적으로 관리해야 할 필요성을 많이 느꼈다.
6. 협업 과정에서 잘된점/아쉬웠던점은 어떤것이 있는가?
협업은 저번 대회와 비교하여 많은 부분에서 원활하게 진행하였다. 우선으로 git hub으로 코드를 관리하였으며 이를 통해 저번에는 손수 코드를 고쳐야 했지만 직접적인 git hub 코드 관리자를 두어 merge 등 보다 편하게 코드 관리를 실시할 수 있었으며 약 일주일에 한 번씩 코드 버전 컨트롤을 하여 리더보드 등수에 집중하기보다는 전체적인 코드의 통합성과 관리를 진행하였다는 점이 단순한 등수 높이는 것보다 많은 인사이트를 얻어갈 수 있었다. 또한 이번 협업에서는 각 파트를 명백하게 나누어 수행하였는데 비록 잘하는 사람이 모든 것을 관리하는 게 가장 높은 점수를 얻을 수 있겠지만 아직은 교육이다 보니 각 파트를 맡아서 각자가 스스로 생각하여 서로 많은 것을 배운다는 점에서 함께 성장한다는 슬로건에서 의미가 있었다고 생각된다. 아쉬운 점으로는 각 파트를 명백하게 나누었을 경우 한 사람은 데이터 한 사람은 모델만 배우는 단점이 있다. 하지만 다음 대회부터는 순환되게 진행하여 문제가 없을 것이라고 생각하지만 대신 리더보드의 등수는 많이 낮을 것이라고 생각된다.