[12주차] 개인 회고 (Level2_KLUE_프로젝트 정리)

 이번 주는 프로젝트 기간으로 강의없이 온전히 프로젝트를 진행하는 데에만 시간을 썼다. 프로젝트의 결과와는 별개로 많은 것을 배울 수 있었던 기회였다. 일일리포트를 통해서 하루하루 무엇을 했는지는 간단하게 적어뒀었고, 오늘은 프로젝트를 돌아보면서 내가 했던 내용들을 회고해보고자 한다. 

Goal

 이번 프로젝트에서 우리 팀의 목표는 이전 기수의 1등 score를 넘자는 것이었다. 그리고 경쟁이지만 늦더라도 많은 것을 배우자는 것이었다. 협업의 과정을 제대로 경험해보자는 생각을 해서 git이나 프로젝트 칸반보드, wandb 등 실험 공유 tool을 최대한 사용하고자 했다. 

 개인적인 목표로는 이전 팀원분의 피드백을 통해 '내가 하는 실험이 왜 필요한 지 설명할 수 있도록 정리'하고자 했다. 그리고 맡은 일은 끝까지 완수하고, 완수하지 못한다면 왜 못했는지에 대해서 이유를 설명하고자 했다. 그리고 저번 프로젝트와 같이 내 성장이 아닌 팀원이 같이 성장할 수 있는 일이 무엇일지 생각하고 도움이 될 수 있는 Task를 우선적으로수행하고자 했다. 마지막으로 저번 프로젝트에서 수행하지 못했었던 Ensemble이나 하이퍼파라미터 튜닝 등을 해보고자 했다.  

Task

• 협업 툴 관리 (Github, CanbanBoard)
• 코드 리팩토링 작업(실험 편리를 위한 config파일 구현, 모듈화 작업)
• 모델 실험 (Input Tagging 작업, MultiSentence Input, 논문 구현)
• 모델 앙상블

협업 툴 관리

 우선 팀의 협업을 위해 프로젝트 초기에 협업 Tool을 제시하고 사용법과 Commit Rule이나 Branch 관리 규칙 등을 설정했다(참고: Git Commit Rule (깃허브 커밋 룰). 그리고 Github 프로젝트 칸반보드를 이용해 To-do, In-progress, Understand, Done으로 프로젝트 진행상황을 공유했다. 해당 방법을 먼저 제시했었기에 프로젝트 기간동안 협업 tool 관리를 맡아서 진행했다. 

 또한 실험 기록을 위해 WandB를 활용했으며, 다른 팀원들의 Task를 한 번에 알기 쉽게 Naming룰을 정해서 실험관리를 수월하게 하고자 했다. 

프로젝트 진행 시 팀원들과 설정한 Github Commit Rule

프로젝트 기간 Commit Rule을 지켜 log를 남김

프로젝트 칸반보드 활용 예 (대략 40개의 작업을 수행)

코드 Refactoring

 프로젝트 초기 다양한 코드가 제작되어 사용이 어려워지고, train과 inference간 장기적으로 코드를 동일하게 수정해야하는 부분이 있어 실수가 발생했다. 따라서 사용성을 높이기 위해 Refactoring 작업을 진행했다. 팀원들의 실험 관리를 위해 실험에 사용되었던 파라미터 Setting값을 자동적으로 저장해주는 파일을 작성했다. 또한, config 파일을 통해 train과 inference의 값을 한 번에 수정할 수 있게 Refactoring을 진행했다.

 해당 코드들을 구현함으로써 사용 편이성을 증대시키고자 했다. 해당 수정 내용을 프로젝트 칸반보드에 정리해 팀원들에게 공유했으며, 실험 관리에 기여할 수 있었다.   

• Function Extaction: 모듈화를 할 수 있는 함수들에 대해 Refactoring 진행
• Modify Code LIne: 유사한 동작을 하는 코드끼리 모으고, 주석을 달아 코드 가독성 향상
• config파일 생성: Train과 Inference과정에서 동일한 기능을 사용하기 위해 config파일을 사용한 코드 작성

config파일에서 설정할 수 있는 변수

모델 실험 (Multi Sentence / Typed Entity Tagging)

 모델의 성능 향상을 위해 모델의 Input 형태를 변형하는 실험을 진행했다. Sub, Obj 태깅에 대한 부분부터 실제 Sentence에 추가적인 정보를 넣어주는 방법(Multi Sentence) 등 다양한 실험을 진행했다. 해당 실험들을 진행하며 논문[An Improved Baseline for Sentence-level Relation Extraction]을 참고해 정보를 얻기도 하고, 구현된 코드를 보면서 인사이트를 얻을 수 있었다. 해당 실험 내용은 일일리포트에 정리한 내용으로 대체하겠다.

(참고링크) [일일리포트] Day 50 (Level2_PStage_6, GPT, Chatbot)

(참고링크) [일일리포트] Day 51 (Level2_PStage_7)

 

WandB Sweep 구현

 모델 성능 향상을 위한 하이퍼 파라미터 튜닝을 위해 Sweep을 사용하고자 했다. 기존 Ray를 구현했지만, Batch-size 32로 학습이 되지 않았고 시각화 및 공유에 어려움이 있어서 WadnB의 Sweep을 사용하고자 했다. HuggingFace에서 Sweep을 사용한 경우가 흔치 않아 자료를 구하기 어려웠지만, 여러 Document의 정보를 모아서 어렵게 구현할 수 있었다. 조금 더 구체적인 실험 내용과 구현 방법은 이전 정리글로 대체하겠다.

(참고링크) [일일리포트] Day 52 (Level2_PStage_8) 

[일일리포트] Day 52 (Level2_PStage_8)

(참고링크) [WandB] Huggingface 라이브러리에서 Sweep 사용하기

 

앙상블 모델 실험

 프로젝트 마지막 날 성능 향상을 하기 위해 모델 앙상블을 진행했다. 앙상블은 submission 파일들의 확률값을 이용해서 평균을 내는 방법을 수행했다. 앙상블 방법의 특성 상 모델 선정에 명확한 기준이 없었기에, 최대한 설명 가능한 가설을 세워서 앙상블을 진행했다.  다양한 앙상블 실험을 통해서 우리 팀 내 SOTA 성능을 달성할 수 있었으며, 최종 Private 4등을 달성할 수 있었다. 결과를 분석했을 때, Ensemble을 진행하며 예측 결과가 Unbiased해지면서 좋은 성적이 나올 수 있었다고 생각한다.

 

기준 Model에서 약간씩 서로다른 변화를 준 모델들로 Ensemble 진행

 Result

 이번 프로젝트에서 Git과 칸반보드 등을 모든 팀원이 잘 활용해서 협업을 진행할 수 있었던 것 같다. 초반에 Git을 사용하기에 두려워하셨던 팀원분들도 프로젝트 중간쯤 가서는 높은 만족도를 보이며 사용할 수 있게 됐다. 그리고 프로젝트 칸반보드 등을 활용해서 전체적은 프로세스를 관리했기 때문에 업무 분배를 효율적으로 할 수 있었다.

 코드 Refactoring을 함으로써 실험 시 실수를 대폭 줄일 수 있었으며, 추가적으로 test_parameter에 대해 json파일로 자동저장해주는 코드를 만들었기에 실험 Setting 값들을 쉽게 공유할 수 있었다. 이를 통해 기준이 되는 모델을 쉽게 구현할 수 있었고, 이를 Base로 다양한 실험과 develop을 진행할 수 있었다.

 모델 실험과 Ensemble을 통해서 매 Task마다 우리 팀 모델의 성적을 단계적으로 향상시킬 수 있었으며, 최종 모델의 경우 다음과 같은 성적을 얻을 수 있었다.

• public 

• private

  프로젝트를 진행하기 전에 팀원과 같이 성장할 수 있도록 하고, 수행하는 일에 대해 이유를 생각하고, 이전 프로젝트에서 하지 못했던 것들을 해보자고 생각했었다. 그리고 이번 프로젝트에서 앞서 생각했던 것들을 다 해볼 수 있었다.

 git과 같은 협업툴의 사용을 제안해서 같이 규칙을 정하고 이를 지킬 수 있게 도와주면서, 마지막에는 팀원들에게 도움이 됐다는 얘기를 들을 수 있었다. 그리고 Refactoring을 수행해 팀원들의 실험에 도움이 될 수 있도록 했다. 실험을 진행하기 전에 해당 실험을 진행하는 이유와 목적 등에 대해서 정리하고, 실패와 성공에 대해 이유와 결과를 잘 정리해서 팀원들에게 공유했다. 그러다보니 나도 헷갈리지 않고 실험을 잘 진행할 수 있었다. 그리고 이전 프로젝트에서 하지 못했던 Ensemble이나 하이퍼파라미터 튜닝 구현 등도 해봤고, 이를 활용해 성능 향상에 기여할 수 있었다.

 이번 프로젝트는 계획했었던 것들을 다 해볼 수 있었던 시간이었고, 좋은 팀원들 덕분에 즐겁게 참여했던 것 같다. 이제 2주 뒤 다른 프로젝트가 끝나면 최종 프로젝트를 진행하게 될텐데 두렵기도 하지만, 이 팀원들과 함께라면 또 재밌을 것 같다는 기대도 된다.

Improvment

 이번 프로젝트에서는 좋았던 부분과 배웠던 부분이 많았었지만, 더 발전하면 좋을 것 같은 부분을 몇 가지 적어보고자 한다.

• 맡은 일을 완성하는 것이 제일 좋겠지만, 너무 오래 걸릴 수도 있다면 팀원들과 공유하기. 이번에는 다행히 구현을 했지만, 그렇지 못할 경우 팀적으로 봤을 때 공백이 생길 수 있음. 이를 방지하기 위해 Task에 대한 위험도를 제대로 이해하고 수행해야할 필요가 있음.
•  정보를 찾는데 귀찮아하거나 두려워하지 않기. 이번에도 실험을 2~3일 동안 진행했을 때보다 논문을 참고했을 때 더 빠르게 모델 성능향상을 할 수 있었다. 내가 생각한 것은 다른 분들이 이미 해봤던 것일 수 있다는 생각을 가지고, 초기에 들어가는 실수나 노력을 줄일 수 있는 부분이 있을 수 있다는 생각하기. (단, 이전 기수의 정보를 보는 것은 최대한 자제, 이번 프로젝트에서는 그렇게 안 했기 때문에 더 많이 배울 수 있었던 것 같다)
• 아이디어 등을 제안하거나 할 때, 전달을 더 효율적으로 할 수 있는 방법 생각하기. 괜히 추가적인 설명이 덧붙여지면서 회의 시간이 길어지는 경우도 발생했던 것 같음. 미리미리 준비하거나 간단한 PPT를 만들어 설명하는 방법 등 고려

MnM팀 모두 고생 많으셨습니다~!