Boostcamp AI Tech 4기 12주차 회고록(12/11)

dkt 대회 종료 & 대회 전체적인 개인 회고

대회 Wrap-Up report

• 이전 대회에서 느낀점 데이터의 버전관리가 원활해야 한다, 데이터를 더 자세히 들여봐야 한다. 모델별로 깊은 이해가 있어야 한다. 데이터가 어떻게 들어가서 어떻게 처리되는지 이해해야 한다. Github 잘 사용하면 너무나 편리하다. 부스팅 모델의 힘이 상당히 좋다.
  

• 이번 프로젝트에서 나의 목표는 무엇이었는가?

  • 사용하고자 하는 모델의 이해도를 높이자 (△)
  • 부스팅 모델에서 hyperparameter tuning 툴을 이용해보자 (O)
  • Github를 잘 활용하려고 했다. (O)
  • 데이터를 들여다보는데에 시간을 많이 투자해보자 (O)
  • 한 모델을 잡고 좋은 성능(리더보드 기준 3등이내)을 내보자 (X)

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

  • 팀원의 추천으로 부스트캠프 내 다른 트랙의 강의를 들으며 Transformer와 Sequence data를 다루는 모델들에 대해 익숙해지려고 노력했다. 특히 NLP강의에서 RNN 계열의 모델들을 다시 한 번 숙지하면서 프로젝트 전반적인 흐름과 모델의 구조를 파악했다.
  • 사소한 작업단위마다 팀단위에서 통일된 commit convention에 맞춰 message를 상세히 적어둬 버전관리에 신경썼다.
  • 주어진 미션들을 참고 하면서 데이터를 많이 들여다보고 나만의 feature를 만들어내기 위한 고민을 많이 했다.

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

  • Feature engineering EDA를 통해 어느 feature가 정답 여부에 어느정도 영향을 줄 수 있을지에 대해 고민해봤고, 0과1의 이진분류 모델을 만들어내기 위해 feature별 라벨(0,1)의 분포를 확인하며 가능성이 높은 feature들로 다양한 feature를 만들어내려는 노력을 했다. 프로젝트 데이터의 특성 상 test data와 train data를 통합하여 하나의 새로운 train data를 만들 수 있었기 때문에, 새로운 train data를 만들고 그 정보를 이용해 test data의 새로운 컬럼을 만드는데에 활용했다. 예를 들어 해당 문제를 푸는데 얼마나 걸렸는지 계산해주는 elapsed time 변수와 같은 경우, test data는 각 유저의 마지막 문제이기 때문에(다음 문제를 푼 기록이 없기 때문에) 0초로 대치되게 되고 그렇다면 의미없는 변수가 될 가능성이 크기 때문에 train data에서 해당 문제를 푸는데 걸렸던 시간들의 중앙값을 이용해 대치하였다.
    
  • LSTM 모델 wandb sweep 한 번 LSTM 모델에 대한 최적의 hyperparameter들을 정의하고 나니, 이후 비슷한 계열의 모델(GRU)의 hyperparameter의 방향을 쉽게 잡을 수 있었다.
  • Catboost optuna 적용 드라마틱한 효과는 없었지만 약간의 성능개선이 있었다.
    
  • valid set을 새롭게 정의 (sub_lb 정의)
    1. train data에서 8:2로 떼어서 valid data 정의했다. (기본)
    2. test data의 마지막 시퀀스를 예측하는 문제에서, 그 직전 시퀀스를 하나의 sub inference set으로 활용하여 리더보드에 제출하기 전 모델의 성능이 어느정도임을 예측하고 활용할 수 있게끔 했다.
    3. test data의 마지막 시퀀스를 제외한 데이터들을 valid data로 정의했다.

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

  • 추가적인 Feature engineering을 통해 LSTM, GRU에서 최고 성능을 기록했다. feature engineering이 부족해서 성능이 덜 올랐던 것은 아닌지 아쉽기도 했다. feature engineering을 통해 성능을 올렸을 때에는 확실히 데이터에서 많은 인사이트를 얻고자 하는 노력은 배신하지 않는다는것을 깨닫기도 했다.
    
  • LSTM 모델의 parameter를 우선적으로 이해하고, 그 이해도를 바탕으로 wandb sweep에 적용시켜 최적 parameters를 찾았다. 이후 비슷한 계열의 모델인 GRU에도 적용시켜 최고 성능 결과물을 뽑아낼 수 있었다.
  • valid set을 정의하는게 굉장히 어려웠는데, 우선 test data와 사이즈를 맞춰주는 것이 유효한 것 같았다. 이번 데이터 특성상, 어느정도 train data와 test data간의 data leakage가 발생하는 것이 당연했고, 그렇기에 test data의 일부도 학습에 사용하면 효과가 좋을 것 같았다.
  • 실제 inference를 위한 data set과 크기가 유사한 sub data set을 정의하여 성능을 측정해보면서 align 하는 것이 좋은 방법일 수도 있겠다고 생각했다.

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

  • Github 버전관리 저번 대회에서는 Github를 버전관리의 관점 보다는 팀 협업의 관점에서 많이 사용했었는데, 이번에는 버전관리의 측면에서도 활용했던 것 같다. 예를들어 Catboost를 계속해서 개발하던 도중에 예전 성능을 이기지 못하자, 예전 버전으로 돌아가 현재 추가했던 기능을 추가해서 시도해보기도 했다.
    
  • 모델 최적화 툴 사용 모델 최적화 부분에서, wandb sweep과 optuna를 활용하여 최적의 hyper parameters를 찾는 방법을 시도했었다. 결과를 떠나 새로운 툴에 대한 숙련도를 높일 수 있는 과정이어서 개인적으로는 좋았다.

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

  1. 항상 시간이 부족했다. 또한, 모델의 베이스라인을 직접 구현하지 못했다. 실패하더라도 도전해보고 싶지만, 대회라는 특성상 시간의 제약을 받는다는 점에서 자신이 없었던 것 같다. 또한 팀 프로젝트라는 면에서 내가 빠르게 내 역할을 마무리하고 팀원들에게 공유해야한다는 생각에 자신감이 줄었고, 비교적 자신있는 부분을 우선적으로 시도하려고, 담당하려고 했던 것 같다.

  2. valid set 확보 전략이 실패한 것 같다. 실제 리더보드와 우리의 valid set간 지표가 많이 차이났다. 팀원들과 해당 부분에 대해 얘기해봤을 때, 오버피팅을 제대로 해소하지 못한 문제인 것으로 추정되었다.

     실제 리더보드의 Public과 Private에서의 지표 차이가 심했던 만큼 (Public에서 1등이 Private에서 12등으로 떨어지기도 했다.) 얼마나 좋은 valid set으로 오버피팅을 잘 잡을 수 있는지가 관건이었던 것 같다.

  3. gcn 모델을 이론적으로만 이해하고 실제로 구현해보지 못했던 것이 아쉽다. 이는 내가 한 모델에만 거의 묶여있었던 또 다른 문제와 복합적으로 결합된 문제인데, Catboost에서 원하는 성능이 나오지 않자 각종 문제에 대해 가설을 세우고 실험해보는 과정에서 많은 시간을 잡아먹혔고,(ex. valid set을 조정한다, 최적의 hyperparameter를 찾는다, …) 결과론적으로는 실패한 전략이었다.

  4. 중간 중간 생기는 문제점들에 대해 모두 최적화를 하려고 하다 보니 앞으로 나아가지 못하고 제자리를 반복하는 상황들이 생겼다. 물론 잘못되거나 나쁘다고는 생각되지 않지만, 대회를 하고 있는 입장에서는 좋은쪽을 더 개발하고, 잘 되지 않은쪽은 과감하게 버리는 결단도 필요하다고 생각한다.

     3번 문제도 비슷한 맥락에서 발생하게 되었는데, 한 우물을 너무 깊게 파다보니 단점이 보이고 그 단점을 메꾸려고 노력하다보니 시간을 과투자하게 된 것 같았다.

• 한계/교훈을 바탕으로 다음 프로젝트에서 스스로 새롭게 시도해볼 것은 무엇일까?
  1. 조금은 실패를 두려워하지 않고 싶다. 특히 필요하다면 베이스라인 코드를 수정하거나, 재구성하거나, 직접 개발하는 부분까지 도전해보고 싶다. 특히 pytorch 코드를 많이 만져봐야 할 것 같다는 생각이 들었다.
  2. 너무 최적의 솔루션을 찾으려고 하다보니 진전이 안되는 프로세스가 있었는데, 안좋은 점을 보완하려는 생각 때문에 이미 좋은 점을 더 개발하지 못했다고 생각한다. 다음 프로젝트에서는 같은 딜레마에 처했을 때, 이번 프로젝트 처럼 한 우물에 매달려있기 보다는 다른 선택을 할 것이다.

느낀점 (조금 더 private한 이야기)

바뀐 팀원들과 합을 맞추며 첫 프로젝트를 하며 지냈던 4주가 순식간에 지나갔다. 확실히 이번 팀원과의 프로젝트는 소통, 협업이 전 프로젝트보다 활발하게 이뤄졌던 것 같다. 전 프로젝트에서도 비교적 활발한 소통과 협업이 이루어졌다고 생각했는데, 아무래도 이번 팀원들과는 일주일에 최소 한 번 씩 오프라인 모임을 통해 상황을 공유하는 과정이 영향이 컸다고 생각한다. 줌으로 온라인에서만 소통하다가 직접 얼굴을 맞대고 대화를 하다보니 조금 더 소통이 원활했다.

이번에는 한 팀원이 대부분의 딥러닝 베이스라인 코드 구현을 하고, 나머지 팀원들은 세부적인 부스팅 모델링, Feature Engineering, EDA등에 집중했다. 지식 공유는 활발하게 이루어졌지만, 코드 리뷰나 코드 공유는 조금 부족했다고 느끼기도 했다. 따라서 다음 대회인 Movie Recommendation 프로젝트에서는 개인이 최대한 다양하고 도전적인 태스크를 맡을 수 있고, 지식 동기화와 공유가 더더욱 활발할 수 있도록 업무 분담 방식을 바꾸기로 했다.

결과가 그렇게 상위권이지는 않았지만, 상위권 모델과의 성능 차이가 크지 않았다. 또한, 전 대회에서 개인적으로 부스팅 모델을 다뤄보고 싶었던 부분을 해소한 것 같아서 만족스러웠다. 반대로 딥러닝 모델 구현 부분은 조금 부족했던 것 같아서 아쉬웠고, 다음 프로젝트 때는 난이도가 조금 있더라도 도전해보고 싶다.

주말이 없을 정도로 바빴던 4주였지만, 돌이켜보니 시간이 부족했다고 느껴질 정도이다. 조금은 더 시간을 알차게 활용할 수 있도록 해야겠다. (다행인것은 마음이 꺾이지 않았다는 점 ㅎㅎ 오히려 1등 조의 발표를 듣고 나니 잘하고 싶은 의욕이 불탔다.)

다음 프로젝트도 화이팅!💪🏻