네이버 부스트캠프/LEVEL-2

[부스트캠프][P-stage][WK10] P-stage level2 KLUE RE 결산 및 개인회고

프로젝트 목표

  • 3위 안의 성적 거두기
  • 가능한 많은 실험, 제출 해보기
  • 앞으로를 위해 팀원들과 호흡 맞추기
  • 새로운 기법을 다양하게 적용해 의미 있는 커밋 하기
  • wandb로 실험 관리 및 효율적으로 제출횟수 활용

나는 내 학습목표를 달성하기 위해 무엇을 어떻게 했는가?

개인 학습

  • 1주차
    • 데이터를 살펴보고 성능의 향상을 위해 어떤식으로 처리해야 할지 고민 및 팀원들에게 공유
    • 매일 1회 이상의 제출을 하며 wandb로 실험 관리
    • Hyperparameter search를 위한 OPTUNA를 구현
    • roberta, electra 등의 모델을 튜닝하고 confusion matrix를 찍어보며 모델이 잘 맞추지 못하는 취약점 파악
    • Relation Extraction 관련 SoTA 방법론들을 사용하는데 entity type이 필요한데, 이를 위해 eda 과정에서 찾은 부적절한 entity pair에 대한 서치 및 수정 작업 진행
  • 2주차
    • Entity type pair에 대한 서치 마무리 및 예외처리, rule base 수정을 통한 새로운 데이터셋 버전 생성에 기여
    • 모델의 다양성을 위해 Roberta, XLM Roberta의 classifier head를 Linear -> LSTM 구조로 변경
    • k-fold cross validation을 통한 단일모델 앙상블, focal loss 사용, augmentation data 버전별 사용 및 비교, 팀원이 TAPT로 새로 학습한 모델 사용 등 여러 실험 적용
    • 결과물을 종합해 앙상블(soft voting)

공동 학습

  • 슬랙, 줌, Github, 카카오톡 등 다양한 방식을 활용한 소통 및 협업
  • 각 실험별 브랜치 생성으로 작업 후 final-result 브랜치에 결합
  • 슬랙을 통한 매일 아침 인사 및 TODO list 공유
  • 정규 시간 이후의 모각공 타임을 통해 서로의 작업을 돕고 모르는 것을 알려주며 소통(TMI는 덤)
  • 데이터 처리, 모델링 등에서 팀을 나누어 관련 분야 협업

나는 어떤 방식으로 모델을 개선했는가?

  • 사전학습된 모델을 가져와 finetuning 하는 방식으로 여러 모델을 실험(Electra, Roberta)
  • OPTUNA를 활용한 hyperparameter search
  • Entity type에 대한 예외처리, Rule base 수정으로 각각 141, 4320건의 데이터 수정
  • LSTM classifier를 사용하여 기존의 모델과는 다른 경향의 output 생성
      micro F1 auprc
    적용 전 68.320 73.354
    적용 후 68.548 72.673
  • 팀원들이 구현한 k-fold, focal loss, augmentation data, TAPT 등을 모두 적용해 성능 향상

내가 한 행동의 결과로 어떤 지점을 달성하고, 어떠한 깨달음을 얻었는가?

  • 팀원과의 소통이 잘 되었을 때와 잘 되지 않았을 때의 업무 효율성의 차이에 대해 다시 한 번 깨닫게 되었습니다.
  • 정리가 잘 되지 않은 실험으로 의미없는 시간, 제출횟수의 낭비가 생길 수 있다는 사실을 알았습니다.
  • 지난 컴피티션에 비교하여 IDLE 환경을 사용한 구조화, 확장성에 대해 더 신경쓰게 되었으며 쉘스크립트 뿐 아니라 yaml 파일을 이용한 실험을 경험했습니다.
  • 데이터를 자세히 살펴보고 가설을 세워 그에 맞는 적절한 실험과 리서치가 중요하다는 사실을 알았습니다.
  • 좋은 성능을 위해서는 좋은 질의 데이터셋이 중요하다는 사실을 다시 한 번 깨달았습니다.

이전과 비교해서, 내가 새롭게 시도한 변화는 무엇이고, 어떤 효과가 있었는가?

  • wandb를 활용해 실험 관리를 해 보았는데, 다른 팀원들의 결과를 함께 살펴보며 공유할 수 있었고 기록을 남겨 실험을 더 효율적으로 하는데 도움이 되었습니다.
  • 단순 IDLE 환경을 통해 실험을 진행하는 것이 아닌 더 확장성 있는 코드를 작성하기 위해 노력했고, 이는 코드를 정리할 때 더 수월해지는 효과가 있었습니다.
  • 프로젝트 시작 전 전반적인 대회의 흐름에 대한 계획을 팀원들과 함께 세우고 이를 지키기 위해 노력했으며 그 결과 컴피티션 기간을 더 효율적으로 쓸 수 있었습니다.
  • 아직 부족하기는 하지만 팀원간의 역할 분담을 해 최대한 겹치는 일 없이 프로젝트를 진행했습니다.
  • 단순히 기존 모델의 architecture를 사용하지 않고 classification head이기는 하지만 구조를 변경하려는 시도를 했으며 성능 향상에 기여했습니다.

마주한 한계는 무엇이며, 아쉬웠던 점은 무엇인가?

  • Merge Rule에 대한 합의가 잘 이루어지지 못했습니다.
  • Optimizer, Scheduler, Curriculum learning 등 적용하지 못한 고려와 적용을 하지 못했습니다.
  • 리더보드에 매몰되어 논문을 읽고 가설을 세워 새로운 기법을 적용하는데 소홀했습니다.
  • 다른 조의 발표를 보며 단순 모델 뿐 아니라 Entity Representation과 같이 넣어주는 데이터의 형태 자체를 고려하지 못한 점이 아쉽습니다.

한계/교훈을 바탕으로 다음 P-Stage에서 새롭게 시도해볼 것은 무엇일까?

  • 모델 버전 관리(hugging face hub), 실험 버전 관리(wandb sweep)를 직접 적용해보고 싶습니다.
  • Github을 활용한 협업에서 조금 더 기준을 명확히하고 진행할 것입니다.
  • 컴피티션 시작 전 또는 초반에 리더보드에 매몰되지 않고 조금 더 큰 그림을 볼 것 입니다. 데이터를 살펴보고 가설을 세우고 논문을 읽으며 컴피티션 자체가 아닌 스스로의 성장에 더 도움이 될 수 있도록 할 것 입니다.
  • 모델링 뿐만 아니라 근본적으로 모델이 데이터와 task를 잘 이해할 수 있도록 입력 데이터의 형태에 대해 고민해볼 것입니다.