• 팀 회고
  • 잘했던 것, 좋았던 것, 계속할 것
  • 잘못했던 것, 아쉬운 것, 부족한 것 -> 개선방향
  • 도전할 것, 시도할 것
  • 개별 키워드(공부한 것, 알게된 것, 느낀 점)

• 목차
  • 1. 프로젝트 개요
  • 2. 프로젝트 팀 구성 및 역할
  • 3. 수행한 미니프로젝트
  • 4. 최종 프로젝트 결과
  • 5. 자체 평가 의견

• 다 같이 하고 싶은 것을 했던 것 같음. 성능이 올라가지 않아 아쉬운 팀원들도 있을 것으로 보임. 실험 관리, 구현 부분에서 부담을 줄이고 아이디어에 더 집중할 수 있게 개선하면 좋을 것 같다. 결과가 좋아서 다같이 만족하는 분위기!

• 협업적인 부분에서 충분한 성과가 있었지만 역으로 그외 부분에 대한 이해? 는 조금 부족할 수 있겠다 라는 생각이 있어 코드 리뷰를 좀 더 신경써서 해야겠다라는 개인적인 생각이 좀 있지만 또 학습과 점수의 트레이드 오프 관계속에서 잘 모르겠다.

• 76점. 팀적으로 깃허브를 마음에 들 정도로 사용했다. 코드 사용이 그대로 제출 가능할 정도로 깔끔했다. 마지막 주사위를 믿지 못한 것이 아쉽기는 하지만 그냥 아쉬운 정도이다. 실질적인 지식에 대한 토의는 부족했던것 같다.

• 깃헙의 다양한 기능을 사용해보고 프로젝트를 체계적으로 진행한것 같아서 좋았다. 그리고 팀원들과의 소통이 잘 된것 같아 다양한 이야기를 나누고 아이디어 공유도 할수 있어서 다양한 실험을 할수 있어 좋았다.

• 깃헙을 적극 활용한 점, 근거를 기반으로 실험을 진행한 점이 좋았다. 점수를 목적으로 프로젝트를 진행하지 않아서 점수 다른 부분에서도 만족스러웠다.

• github를 협업 용도로써 사용한 것은 처음이었는데 효율적인 의사소통을 할 수 있어서 좋았다.

• 팀원분들의 협업 능력을 볼 수 있어서 좋았고, 다 같이 역할을 나눠서 모델을 돌려본 것이 좋았다

• 실험용 코드가 모든 팀원에 대해 일치되어 있어서, 개발과 실험이 잘 분리되었음

• 기발한 아이디어나 발견 등이 있다면 토론게시판을 통해 더 많은 사람과 의견을 주고받아야겠다.

• 학습적인 측면에서 다같이 코드 리뷰를 좀 더 열심히 하면 좋을 것이다.

• AEDA, TAPT와 같은 기법들을 스스로 찾을 수 있도록 하면 좋을 것 같다.

• klue/bert-base (62.32, 68.51)/(EM, ROUGE) 이 세팅으로 고정하고 시작하면 어떨까?
• 튜닝은 나중에. hyper parameter 최적화 툴 사용하기.

• 프로젝트 초기에 모델 이해를 더 깊이 했다면 주도적인 실험이 가능했을 것 같다.

• 경험이 정말 큰 무기라는거 특히 AI 분야 쪽에서... 그러니까 공부하자 공부공부

• 이상적으로 옳다고 해서 기계학습이 이상적으로 되는 건 아니다. 개인 관리와 개인 학습에 더 신경써야겠다.

• 모델을 먼저 깊이있게 공부하지 않고 대회를 진행해서 조금 아쉬웠다. 하지만 토크나이저와 NLP Task가 어떤식으로 진행되는지에 대한 감은 잡은것 같다.

• 토크나이저와 모델의 기본적인 작동 방식에 대한 공부를 하지 못한 것이 아쉬웠어서, 어떤 식으로 학습이 되고 결과가 전달되고 special token이 사용되는 것인지 공부해야 할 것 같다.

• huggingface를 사용하는 데 익숙해져야 할 필요성을 느꼈다. 기본적인 것을 몰라서 시간을 소모하는 상황을 줄이기 위해 기본적인 내용 공부를 소홀히 하지 말아야 겠다.

• 대회 기간동안 깃헙, cli환경에 익숙해지지 못했던 것이 정말 아쉬었던 것 같다. 또한 저번 스테이지와 다르게 전체적인 코드 이해가 부족해서 잘 따라가지 못했던 것 같다. 여러모로 아쉬움이 많은 대회였던 것 같다

• 문장 속 두 단어의 관계를 추론하는 모델 학습.
• 모델은 두 단어와 문장을 입력으로 받고, 지정된 두 단어의 관계를 30가지 class 중 하나로 예측한다.

• *(Park, Sungjoon, et al. "KLUE: Korean Language Understanding Evaluation." arXiv preprint arXiv:2105.09680 (2021))

Gantt Chart

분석

• 탐색적 분석
  • subject_entity type은 per, org 로 2가지로 분류된다.
  • relation 는 subject_entity의 entity에의해 단체 또는 사람으로 시작한다
    • 단, 데이터에서 예외가 존재
      1. 잘못 표기된 경우
         • 소녀시대 등의 org Label 이 per 인 경우
         • 도시명 등의 지명이 subject_entity 로 나와 subject_entity 가 잘못 나온 경우
    • 다른 예외 사항은 확인하지 못함.
• 접근 방법, 발상
  • 논문에서 좋은 결과를 낸 모델을 선정.
  • 기존의 Pretraining과 최대한 비슷한 입력을 주기 위한 입력 형태 변형
  • 데이터 불균형 해결 및 증강을 위한 augmentation

모델 선정

• 제공된 모델 중 접근이 쉽고, 관련 논문에서 성능이 좋았던 모델을 선정하였다.
• KLUE 벤치마크에서 제시한 파라미터들을 통해 결과를 구현하였다.

적용 사항

1. Typed Entity Marker (punct)

   • An Improved Baseline for Sentence-level Relation Extraction 논문을 기반으로 진행
   • data로 주어지는 sentence에 entity의 type과 함께 entity marker를 추가하되 marker로 special token대신 문장부호를 사용하는 방법이다.
   • 성능이 향상되었다. entity type과 함께 entity를 mark하여 모델에게 더 많은 정보를 제공해줌으로써 성능이 향상된 것으로 여겨진다.

2. Adaptation

   • 방법 설명 : pretrain 된 모델(ex bert등)을 Masked language modeling을 통해 사전학습 시킨 후 Finetuning 하는 방법이다.

   • 적용 사유 : Domain 또는 Task에 대한 언어 모델을 한번 더 학습 시키는 것이 당연히 더 각 단어간 관련도가 높을 것이라 생각했다. (참고 Don’t Stop Pretraining: Adapt Language Models to Domains and Tasks)

   • 적용 방안

     • 우선 해당 Task에서는 Domain을 한정할 수 없어서 DATP는 사용이 힘들 것이라 판단하였다.
     • Dataset을 통한 TATP(Task-Adaptive PreTraining )을 진행

   • 적용 결과

     1. Train set 을 통한 진행
        • Submission F1 score가 오히려 떨어짐
     2. Train + Test set을 통한 진행
        • Submission F1 score가 증가

3. EDA

   • 기존의 EDA에서는 동의어를 넣는 방식으로 학습 데이터를 확보하였다. 이와 유사하게 동의어는 아니더라도 per, dat, org, loc의 type에 대해 subject entity와 object entity의 단어를 대체했다.
   • 성능은 오히려 하락했다. 아무래도 문장 구조가 주요 단어를 제외하고는 동일해서 생기는 과적합 문제로 보인다. 특히 원래 라벨이 적었다면 생성된 동일 구조의 문장이 많기 때문에 해당 라벨을 더 엄격하게 따지는 경향성을 보이게 되어 오히려 점수가 하락한 것으로 보인다.

4. AEDA

   • 임의의 문장부호를 입력 문장의 단어 사이에 무작위로 삽입하였다.
   • 문장부호 : (, . ; : ? !)
   • 총 삽입 개수 : 원본 문장의 단어 수 대비 0%(미적용과 동일) ,30%, 100%로 실험했다.
   • 결과 : 유의미한 차이가 발생하지 않았다.
   • 논문 결과와 실험 결과를 볼 때, 더 적은 데이터셋에 대해 효과 있는 방법으로 보임.

5. Entity Swap Augmentation

   • object entity를 subject entity로 subject entity를 object entity로 바꾸어도 30개의 label 중 해당하는 label이 있는 data들에 대해서만 entity swap을 진행하여 데이터를 늘리는 방법이다.
   • 데이터가 상대적으로 많은 label에 대해서 진행할 경우 데이터 불균형이 더 심해질 것이므로 데이터가 상대적으로 부족한 label들에 대해서만 진행했다.

6. Random OverSampling

   • 수가 적은 label에 대해서 데이터를 중복으로 넣어 데이터 불균형을 극복하려 했다.
   • 성능은 오히려 하락했다. 데이터가 적은 라벨이 중복이 많이 되며 해당 데이터에만 overfitting 됐던 것이 아닌가라는 생각을 했다.

7. train 데이터 구조 만들기

   • BERT는 Pretraining할때 2개의 문장에 대한 관계를 [CLS] 토큰을 통해 추론하는 방식이므로, 이번 Relation Extraction task에서는 [CLS] original Sentence [SEP] 이 문장에서 {Subject Entity}와 {Object Entity}와의 관계는 무엇일까? [SEP] 와 같은 구조로 Data를 구성하여 실험을 진행하였다.
   • BERT는 Pretraining할때 2개의 문장에 대한 관계를 [CLS] 토큰을 통해 추론하는 방식이므로, 이번 Relation Extraction task에서는 [CLS] {Subject Entity} [SEP] {Object Entity} [SEP] 관계 [SEP] 정보 Sentence [SEP] 와 같은 구조로 Data를 구성해서 관계와 cls토큰이 attention을 학습하도록 실험을 진행하였다.

8. hyperparameter 실험적 결과 선정

• Typed Entity Marker (punct), TAPT, Entity Swap Augmentation, train 데이터 구조 만들기
• soft voting ensemble (best model에 대해 1.2배 가중치 반영)

• 72.710 (TAPT+ added data + entity marker, tokenization modify)
• 73.950 (TAPT+ entity marker, tokenization modify)
• 74.034 (added data + entity marker + tokenization modify + k-fold)
• 72.991 (entity marker + tokenization modify)
• 70.724 (TAPT (epoch 30)+ added data + entity marker, tokenization modify)

• Public micro_f1 score : 75.962
• Private micro_f1 score : 73.794

잘한 점

• 깃허브 사용이 만족스러웠다. -> 프로젝트 관리가 되는 느낌이었다.
• task관련 paper를 기반으로 실험을 분할 진행한 것.

아쉬웠던 점들

• 실험 관리 좀 불편했음 (이름 짓기, wandb에서 내 모델 찾기)
  • arg 가 너무 많아서 오히려 힘들었음..
  • 다음에는 <김캠퍼> 1, 2, 3, 4, 5 <이부캠> 1,2,3,4 등으로 작성해보자.
• 모델을 분할 하여 Task를 나누는 방법을 고려하였으나 실제 적용하지 못한 점이 아쉽다.
  • 생각한 Task 분할은 데이터의 subject_entity가 2가지이며 no_relation,'org','per' label의 비율이 매우 비슷하여 3가지로 분류 후 'org','per'은 각자 Task를 한번 더 진행하는 것을 생각해 봄
• 모델 성능 향상에 기여할 수 있는 방법(논문)을 직접 찾지 못한 점.
• tokenizing부터 커스텀 모델 작성하기.
• BERT모델 위에 층을 더 쌓아서 실험해보지 못한것.
• wandb를 좀 더 체계적, 실용적으로 사용하지 못한 점.
• hyperparameter 최적화 툴을 사용해보지 못한 점.