Home

📝 Table of Contents

• 대회 개요
  • 배경
  • 문제 정의
  • 평가지표: mIoU
• 대회 결과
• 접근 방법
  • 협업 방식
  • 베이스코드 개선
  • 모델 실험
  • Augmentation 기법
  • 그 외
• 회고
  • 좋았던 점
  • 아쉬웠던 점
  • 다음에 시도해볼 것

---

📖 대회 개요

배경

• 대량으로 물건이 만들어지고 소비를 하면서 심각한 쓰레기 문제를 낳고 있다.
• 쓰레기 문제를 해결하기 위해 "분리 수거"를 통해 잘 분리 배출된 쓰레기는 자원으로서 가치를 인정 받아 재활용된다.
• 그만큼 "분리 수거"가 중요하지만, "이 쓰레기가 어디에 속하는지", "어떤 것들을 분리해서 버리는 것이 맞는지" 등 정확한 분리수거 방법을 알기 어렵다는 문제점이 있다.
• 쓰레기가 찍힌 사진을 가지고 Segmentation을 진행해 위의 문제를 해결하고자 한다.

문제 정의

쓰레기가 찍힌 사진의 픽셀을 배경을 포함한 12개의 클래스로 분류하는 Segmentation 모델

• input:  쓰레기 이미지 (512, 512) 총 4109장과 COCO Format으로 이루어진 Annotation 파일

├─ images
│  ├─ id: 파일 안에서 image 고유 id, ex) 1
│  ├─ height: 512
│  ├─ width: 512
│  └─ filename: ex) batch01_vt/002.jpg
│
└─ annotations
   ├─ id: 파일 안에 annotation 고유 id, ex) 1
   ├─ segmentation: masking 되어 있는 고유의 좌표
   ├─ bbox: 객체가 존재하는 박스의 좌표 (xmin, ymin, w, h)
   ├─ area: 객체가 존재하는 영역의 크기
   ├─ category_id: 객체가 해당하는 class의 id
   └─ image_id: annotation이 표시된 이미지 고유 id

• output: 12개의 클래스
  • Background, UNKNOWN, General trash, Paper, Paper pack, Metal, Glass, Plastic, Styrofoam, Plastic bag, Battery, Clothing

평가 지표: mIoU

---

🏆 대회 결과

• 순위 62등, mIoUC 0.6472
• 제출횟수 총 22회 (팀 138회)

---

🚀 접근 방법

팀의 대회 참여 과정을 따라가면서 내가 팀에 어떤 기여를 했는지 위주로 작성하였습니다.

협업 방식

2021.04.26

첫 날 서버를 할당받지 못한 팀원들도 있었기에 이 날은 쉬고 팀 협업을 어떻게 할지를 정했다. 그라운드룰, 실험관리 등에 관한 이야기를 나눴고 개인적으로 Pull Request와 Code Review 도입을 적극적으로 건의하였다. 아직 GitHub와 Git에 익숙하지 못한 팀원들도 있었기에 공지에 Pull Request 보내는 법을 작성하였다.

피어세션나 질문은 GitHub Discussion에, 코드 관련은 Issue와 Pull Request를 통해, 실험 관리는 Google Spreadsheet, 실시간 기록용으로 Google Docs를 사용하기로 정하였다.

베이스코드 개선

2021.04.27 - 2021.04.30

대회에서 베이스코드는 따로 주어지지 않았지만 조성진 캠퍼님이 미리 py모듈로 나눠놓으셔서 그것을 베이스코드로 하여 기능을 하나씩 추가하는 방식으로 코드를 개선하였다. Pull Request로 추가된 기능은 다음과 같으며, augmentation을 제외하고 인자로 받아 명령어로 실험할 수 있도록 했다.

• smp 라이브러리로 사용하여 인자 입력으로 backbone과 method를 레고처럼 자유롭게 바꿀 수 있도록 설정했다.
• AdamP, Adam, SGD, MadGrad 등 다양한 optimizer와 CrossEntropyLoss, FocalLoss, LabelSmoothing, F1Score, DiceLoss 등 다양한 loss 추가했다.
• wandb 연결 및 env 파일로 개별 세팅을 할 수 있게 하였으며, wandb에 config, loss, mIoU 및 추론된 이미지가 올라가도록 하여 wandb에서 실험 결과를 볼 수 있도록 했다.
• LB mIoU가 inference시에 사용하는 mIoU 계산방법과 다르다는 토의 게시글을 보고 전체 이미지에 대한 mIoU를 평균내는 LB mIoU를 계산하는 코드 추가했다.
• K-fold와 Stratified K-fold 코드를 추가하여 교차검증이 가능하도록 했다. K-fold의 경우 몇 개의 폴드로 검증을 할지 설정을 할 수 있도록 인자를 추가했다.
• checkpoint를 저장할 수 있는 코드를 추가하였고 몇 interval 마다 저장할 건지에 대한 인자를 추가했다. 사용자에 따라 몇 step마다 log가 찍히도록 할지에 대한 인자도 추가했다.
• augmentation을 공통으로 적용할 것, 학습 시에 적용할 것, 추론 시에 적용할 것 3가지로 분리하여 사용자가 리스트에 다양한 augmentation을 넣다 뺐다 할 수 있도록 했다.

모델 실험

2021.04.27 - 2021.04.30

처음에는 강의에 언급된 모델들을 중심으로 DeconvNet, SegNet, DilatedNet, Deeplab v1, Deeplab v2, Deeplab V3에 대한 실험을 진행했다. optimizer, loss는 따로 정하지는 않았지만 기본 세팅으로 돌려보고 시간이 있다면 다른 세팅으로 실험을 하도록 하였다. 나는 Deeplab v3 실험을 맡았으며, LB mIoU 0.53으로 가장 좋은 성능을 보여주었다. 추가로 시간이 남아 저번 대회에서 좋은 성능을 보여준 MadGrad를 써서 학습을 시켜보았고 Adam보다는 체감상 더 빠른 학습 속도를 보여주었다.

2021년 5월 3일 기준 실험 노트에서 가장 좋은 성능을 보여준 Deeplab v3+와 efficientnet을 베이스모델로 선정하였다.

Augmentation 기법

2021.05.03 - 2021.05.06

• 여러 augmenation 기법을 적용했으나 가장 좋은 성능을 냈을 때는 적당량의 augmentation을 적용했을 때였다. Resize, RandomResizedCrop, Normalize만 적용했을 때 가장 좋은 성능을 보였다. CLAHE나 Noise, Distortion 같은 Augmentation은 객체의 재질이나 형태를 찌그러뜨리는데 아무래도 모델이 재질이나 형태를 가지고 객체를 파악해서 그런지 성능이 좋지는 않았다.
• 최재혁 캠퍼님이 Cutmix와 CopyAndPaste를 구현하셨고 CopyAndPaste 적용 시 성능 향상을 보였다. 아무래도 클래스 불균형으로 인해서 적은 클래스의 객체를 잘 예측을 못했는데 이를 사용해서 불균형을 어느 정도 해결할 수 있었던 것 같다.

그 외

2021.05.03 - 2021.05.06

• 베이스 모델이 정해지고 나서는 베이스 모델의 성능을 최대한 높일 수 있는 방법을 찾는 개인 실험을 진행했다. 각자 실험 노트에 실험 계획을 간단히 써놓고 다음 날 피어세션 때 어떤 방법이 좋았는지에 대한 의견을 나누었다.
• 저번 stage 때 efficientnet의 성능이 정말 잘 나와서 대회 끝나기 하루 전까지 efficientnet에만 집중을 했었는데, 한 팀원이 resnext101_32x4d 실험을 했고 efficientnet보다는 빠르고 더 좋은 성능을 보여주었다. 대회 하루 전 efficientnet에서 resnext101_32x4d로 베이스모델을 변경하였다.
• 기존 성능이 잘 나온 모델을 가지고 cutmix, gaussian, randomcropresize 등의 다른 augmentation을 적용한 데이터셋에 재학습시키는 방법을 실험했다. 조금 다른 데이터를 가지고 학습한 터라 조금의 성능 향상이 있었다.
• 수달님이 올려주신 stratified k-fold를 적용해 각 폴드별로 클래스 분포가 일정하도록 하였고 안현진 캠퍼님의 Pseudo Labeling을 적용하여 최대 mIoU 0.6563으로 최대 성능을 끌어냈다.
• ensemble을 시도했지만 대회 마지막날 두 시간동안 급하게 코드를 짰지만 결국 실패하여 앙상블은 적용하지 못하였고 싱글 모델로 최대 성능이 나온 결과를 최종 제출했다.

---

👀 회고

좋았던 점

• Pull Request와 Review를 통한 협업이 생각 이상으로 잘 되어서 좋았다. Pull Request를 승인/거절할 시 칭찬 혹은 피드백을 무조건 해서 좋은 피드백은 반영하여 코드를 개선시켜 나갔다.
• 공통 베이스 코드를 만들어서 공유한 것도 좋았다. 조성진 캠퍼님 덕분에 기능을 쉽게 추가할 수 있었고 일주일 동안 베이스코드를 완성시킨 이후 코드를 고칠 일은 거의 없었고 모델을 바꾸며 다양한 실험을 할 수 있었다.
• wandb를 써서 시각화 및 로깅을 해서 좋았다. 스프레드 시트에 기록을 하여도 과정이 없으니 결과밖에 믿을 수 없었는데, wandb에 기록된 그래프를 보면서 어떤 모델을 최종 모델로 쓸지 결정하는데 큰 기여를 했다. 특히 시각화의 경우 모델이 무엇을 헷갈리는지를 파악할 수 있었다.

아쉬웠던 점

Team

• 개인적인 실험을 어디서 해야할지 헷갈렸었다. 로컬에서 자신이 원하는 대로 돌릴 때 어떻게 해야할지 몰라서 어떤 사람은 sohyun/experiment에서 작업하고, 어떤 사람은 sohyun 이렇게 따서 code에서 작업해서 일관성이 없었다.
• Pull Request시 승인 최소 인원을 5명으로 두었는데, 모두 코드를 한번 씩 확인 한다는 점에서는 좋았지만 승인되기까지 많은 시간이 걸려서 master 브랜치에 반영되기까지 시간이 걸렸다.
• 실험결과는 잘 관리가 되는데, 실험계획은 잘 세워지지 않는 것 같다. 그래서 그런지 중복 실험을 한 경우도 종종 발생했고 다시 돌아보면 다양한 실험을 하지 못했던 것 같다.

Personal

• 코드를 짜는 데 주저함이 있었다. 그래서 Pull Request에 기여를 많이 하지 못한 것이 아쉬웠다. 약간 코드를 파악하지 못했는데 잘못 기여했다가 잘못된 코드를 보내면 어쩌지 하는 두려움이 있었던 것 같다.

다음에 시도해볼 것

Team

• 앞서 segmentation에서 했던 것처럼 sohyun/experiment로 따로 폴더를 파서 브랜치도 따로 파고 해서 하거나 아니면 개인 브랜치에서 merge는 하지 않되 계속 실험하는 식으로 하든 둘 중 하나 정하는 게 좋을 것 같다.
• Pull Request는 다수결로 3명 정도 승인하면 머지하는 게 좋을 것 같다. 5명은 너무 많고 3명이 Approve 했으면 "최소 3명이 코드를 검사했다"는 뜻이니 3명 정도가 적당할 것 같다.
• 실험계획은 노션을 파서 따로 관리해보자. 실험 결과는 스프레드시트를 쓰되 실험계획은 노션에 미리 어떤 실험을 할 건지 써두어 실험이 중복되지 않게 할 수 있을 것 같다.

Personal

• 코드와 실험에 주저함을 갖지 말고 괜찮다면 Pull Request를 보내보자. 정말 잘못된 코드라면 팀원이 리뷰하면서 피드백을 보내줄 것이다. 또한 베이스코드를 받는 날은 무조건 코드 파악부터 해서 필요한 기능이 무엇인지 파악하자!