[네이버 부스트캠프 5기] Object Detection 프로젝트 리뷰

이번 글에는 Level 2 팀과 함께하는 Object Detection 프로젝트 리뷰를 진행해 보려고 한다. 까먹기 전에 Data Centric도 쓰고 다시 열심히 포스팅 해야겠다.

Object Detection이란 말 그대로 물체를 찾는 문제이다. 사진이 주어지면 물체가 존재하는 공간을 찾는 것. 그 물체가 고양이인지 강아지인지 알아보는 것은 아니다. 그래서 이번 프로젝트는 엄밀하게 Object Recognition이 더 맞지 않나 싶긴 하지만.. 이것저것 섞어서 쓰는 모양이다.

부스트캠프에서 진행한 프로젝트는 쓰레기가 있는 사진 데이터에 대해서, 쓰레기의 위치를 검출해야 하고, 그 쓰레기가 주어진 10개의 라벨 중 어떤 값을 가지는지 판별해야 한다. 5월 3일부터 5월 18일까지 진행했고, 역시 하루에 10회 제출이 가능했다.

이번에도 역시 부캠에서 베이스 코드를 제공해 주었다. 베이스 코드의 종류는 mmdetection, detectron2, faster_rcnn 세가지가 주어졌다. 앞의 두가지는 꽤 유명한 코드인 것 같다. 상당히 체계적이기도 하고. 대신 코드가 엄청나게 많아서 뭐가 어떻게 돌아가는지 분석하는 것도 시간이 꽤 많이 들었다. 우리 팀은 이번 대회의 목표를 리더보드 점수 대신 코드에 대한 전체적인 이해로 잡았다. 그래서 주어진 베이스 코드를 사용하는 것 보다 간단한 코드를 바탕으로 조금 개량하여 사용하는 것을 선택했는데, 오류도 엄청 많이 생겼었고, 어찌저찌 돌아가도 성능이 상당히 낮았다. 일주일쯤 그렇게 코드를 수정하다가 이대로는 오류만 해결하다 끝나겠다는 생각이 들어 mmdetection을 공부하고, 사용했다. 사실 성능이 나오거나 말거나 그냥 직접 수정하는게 더 많이 배울 수 있을 것 같았는데, 남은 시간 안에 정상궤도로 올릴 자신이 없었다.

EDA : 클래스 불균형 문제가 꽤 심각했다. 배터리가 되게 적었던 걸로 기억한다. 그리고 한 이미지에 최대 71개?의 물체가 존재하는 경우가 있었다. 대부분 10개 이하의 object를 가지고 있었는데, object가 많은 사진을 잘 구별하는 것 역시 중요해 보였다. 또한 클래스간 상관관계 분석도 실시해 보았는데 상관계수가 커봐야 0.1? 정도로 유의미한 결과가 나타나진 않았다. 작은 상관계수라도 적용해서 클래스 예측에 사용하면 도움이 될까 생각이 들기도 했다.

Augmentation : 이론을 배웠을 때에는 Augmentation이 상당히 유용하게 쓰일 줄 알았는데 생각보다는 아니다. 물론 데이터에 맞는 Augmentation을 적절하게 적용하지 못한 탓이겠지만.. mosaic?가 성능 향상에 도움이 되었다.

Backbone : 여러 실험을 했는데 Swin, Cascade RCNN이 정석인 것 같다. 주어진 Task가 어떤 특징을 가지고 있는지 잘 분석하여 Transformer 계열과 CNN 계열 사이에서, 그리고 Deep한 모델과 Shallow한 모델 사이에서 선택할 필요가 있다. 멘토님은 1. class imbalance보다는 general한 애매모호함. 여러 객체의 overlapping이 문제라고 판단 → 2. 이런 정보를 뽑기 위해서는 Deep 모델, 혹은 넓은 영역을 바라보는 Transformer가 효과 → 3. swin tiny보다 swin large가 잘 작동한 이유가 아닐까.. 라고 말씀하셨다.

Loss : 이것저것 Loss를 바꾸며 실험을 했다. 베이스코드에서 바꿀 수 있는 loss는 RPN Head loss_cls, RPN Head loss_bbox, RoI Head loss_cls, RoI Head loss_bbox 4가지였다. 특정 모델에서는 loss가 무한대로 발산하는 경우가 있었다. log0, epsilon, 뭐 그런 문제인 것 같다. Cross Entropy, L1이 기본으로 사용되고, IoU, CIoU, GIoU, DIoU를 실험했는데 DIoU가 가장 좋더라.

Ensemble : 앙상블은 기적을 만든다. 다만 실험을 통한 성능 향상은 아니라 내 능력으로 올라간 점수라는 생각은 안 들었다.

이 외에도 streamlit을 이용해 serving을 했었는데 내가 한 분야는 아니라 패스..

이번 프로젝트는 개인적으로 아쉬운 점이 많았다. 개인 회고는 다음과 같이 작성하였다.

이번 프로젝트는 전반적으로 아쉬움이 많이 남는 대회였습니다. 협업 과정이나 EDA는 이전보다 발전된 형태였지만, 그 외에 모델 제작이나 실험 과정에서는 부족한 점이 많았던 것 같습니다. 또한 처음에는 많은 것을 배우고 시도해 볼 생각에 의욕이 충만했으나 코드 작동에서 문제가 생기는 등의 시행착오를 겪으며 나름의 번아웃을 경험한 것 같기도 합니다.

프로젝트 진행에 앞서 팀에서 자체적으로 세운 목표는 성능 그 자체에 매몰되기 보다는 서빙을 시도해 보는 것이었습니다. 또한 config를 수정하며 성능을 올리는 것 보다 코드 전체에 대한 이해가 더욱 중요하다고 생각했습니다. 위의 목표를 고려하면, 주어진 베이스라인 코드를 사용하는 것은 배울 점이 부족하다고 생각하여 처음에는 간단한 코드를 바탕으로 자체적으로 개량하는 방법을 선택하여 프로젝트를 진행하였는데, 모델을 바꾸는 과정에서 생기는 오류들이 많았고, 성능 역시 저조하여 주어진 시간 내에 에러가 고쳐지지 않는다면 큰일이기에 mmdetection을 사용하기로 결정하였습니다. 직접 모델을 구성해보는 과정에서 학습할 수 있는 부분이 많다고 생각하기에 좋은 기회를 놓치게 되어 아쉽게 느껴졌습니다. 이후 mmdetection으로 실험을 진행하는 과정에서도 Bounding Box에 대한 시각화 등에 집중하여 Dataset을 Train, Valid로 분할하는 것과 Validation Dataset에 대한 성능 확인이 필수적임에도 불구하고 코드 추가가 늦어져 다양한 실험을 진행하지 못하였습니다. 뿐만 아니라 Object Detection이 Classification보다 더 고차원적인 문제이기에 모델을 학습하는 시간이 오래 걸려 실험을 하기 전에 가설을 세우고 검증하는 과정이 필수적인데 그러한 부분에서도 부족함이 있었습니다.

이러한 아쉬움도 있었지만, GitHub로 Branch를 만들고, Pull Request를 올리는 등 협업의 첫 걸음을 뗄 수 있었고, Bounding Box와 Confidence Score를 시각화하여 현재 모델의 성능과 문제점을 파악하고, 모델을 눈으로 볼 수 있게 만드는 작업이 얼마나 중요한지 깨달을 수 있었습니다. 최종 프로젝트에서는 더욱 발전된 형태로 팀원들과 협업하여 Validation Dataset을 신속하게 처리하고, 더욱 다양한 가설을 세움과 동시에 실험을 설계하고 검증하며 이번 프로젝트에서 느낀 부족한 점들을 보완하고 싶습니다.

Level 1에서는 잘 진행했던 validation dataset에 대한 성능 확인을 제대로 하지 않았던 것이 가장 아쉬운 점이었다. 당연히 해야 하는 부분인데 왜 그랬을까.. 개인 회고 첫 부분에 번아웃이라고 썼지만 정말 하기 싫었다. 몇달째 하루종일 집에서 공부하는 것도 싫고.. Level 1 팀원들과 있다가 새로운 팀에 와서 어색하기도 했고.. 그런데 돌아보니 아쉬움이 많이 남아서 다음 프로젝트에는 조금 더 집중할 수 있는 계기가 되었다.