[X-Diary 10월 2주차 조원]

이달 내로 졸업논문을 완성해야 하기에 시간이 애매해서, 그 전까지 X review를 X diary로 대체하려고 하며, 간단히 이번주 했던 일들에 대해 공유하고자 합니다.

새로운 논문의 투고를 위한 실험

이전에 AAAI에 떨어졌던 “VVS: Video-to-Video Retrieval With Irrelevant Frame Suppression” 논문의 아픔을 이겨내고, 내용을 보충하여 졸업 논문 및 CVPR에 투고하고자 실험을 진행했습니다. 해당 방법은 anchor, positive, negative로 구성된 triplet으로 학습되는데, AAAI 제출을 위해 실험한 당시 학습에 사용하던 triplet 구성 방식엔 성능 향상 폭의 한계가 있었습니다. Triplet 구성 방식이 contribution은 아니기도 하고, 한계가 있긴 해도 성능이 SOTA 였던 지라 (시간이 얼마 없기도 했고) 그대로 두었었는데, 이번엔 이 한계를 풀어보자는 생각에 triplet 구성을 다른 방식으로 바꿔보았습니다. 그래서 타 논문 중 VRAG라는 방식의 구성 방식을 차용했고, 결론적으로는 얼추 한계를 풀어서 베이스라인의 성능과 저희의 방식으로 인한 성능 향상 폭 모두 높아지게 되었습니다. 물론, 아직 필요한 실험이 더 있긴 해서 다음 주부터는 이 구성 환경을 베이스로 실험을 계속하고자 합니다.

첫 자소서 작성

이번에 박사 진학한다고 자소서를 처음 써보았습니다. 수능도 정시로 들어온터라 한 번도 자소서를 써본 적이 없어서 난감했는데, 김형준 연구원과 유튜브의 도움을 받아 어떻게 마무리할 수 있었습니다. 자소서 작성을 하며 느꼈던 가장 중요한 점은 특정 경험에 대해 어필할 때 두괄식으로 써야 한다는 점입니다. 이때 두괄식으로 쓰는 방법은 “관찰 혹은 특정 동기부여로부터 온 나의 행동” + “행동으로부터 얻은 수치적/정량적 결과”를 매 문단 첫 줄에 쓰고 자세한 건 그 뒤에 쓰는 것이라고 알게 되었는데, 실제로 작성을 마친 뒤에도 이 방식대로 쓴 것이 좀 더 눈에 들어왔습니다. 다른 연구원 분들도 혹시 자소서를 쓰게 되신다면 이 부분을 고려하여 써보시면 좋을 것 같습니다.

여담..?

이 글을 보시는 분들께 실험할 때 도움이 될만한 말씀을 드리자면, 최대한 디버깅/실험 시간을 줄이는 것이 중요하다는 것을 말씀드리고 싶습니다. 코드 돌리면서 “이 코드는 다 도는데 1시간 걸리네? 근데 방법이 어쩔 수 없지” 라고 생각하시면서 그대로 두시는 분이 많은 것으로 알고 있고, 저도 과거에는 이런 생각을 하곤 했습니다. 그러나, 이런 생각이 들어도 계속 디버깅/실험 시간 줄일 방법을 찾는 것을 추천드립니다. 왜냐하면, 만약 1분 만에 도는 A 라는 코드와 1시간 만에 도는 B라는 코드가 있을 때, 누구나 A라는 코드를 돌릴 기회가 B 대비 동일 시간 안에서는 60배 많다는 것을 알 수 있습니다. 그러나, 간단하지만 더 생각해야 할 만한 한 가지는, A라는 코드를 돌렸을 때가 B라는 코드 돌렸을 때보다 실험적인 측면에서 최대 60배 많은 결과를 낸다는 것입니다. 실제로 하나의 논문에는 대략 3~6 (혹은 그 이상) 개 정도의 실험이 들어가는 것으로 알고 있습니다. 이 때 한 실험의 결과가 나오기 위해서 20번의 실험 시도가 필요하다고 가정했을 때 A 코드로는 2시간 안쪽으로 한 논문에 들어갈 실험을 끝낼 수 있는 반면, B 코드로는 일주일이 걸리게 됩니다. 그리고 실험만 고려하여 1년에 작성할 수 있는 논문을 생각해보면, A 코드로는 B 코드와 비교할 수 없이 많이 쓸 수 있게 됩니다. 물론, 이 시간에 대한 수치가 정확하진 않고 모든 실험에 동일한 시도 횟수가 요구되진 않기도 하며 논문을 쓰는 것에는 여러 변수가 작용하기는 하지만, 대략적으로 디버깅/실험에 걸리는 시간이 1년이라는 기간 동안 낼 수 있는 결과물에 생각보다 큰 영향이 미쳐진다는 것을 말씀드리고 싶었습니다.

그럼 “시간을 줄여야하는 것은 알겠고, 어떻게 줄여야 하는가”에 대해서도 생각이 드실텐데, 내용이 너무 길어질까봐 간단히 제가 경험했던 것을 말씀드리자면, IO 시간을 줄이는 것이 가장 중요합니다. 먼저, 코드 내 data loader 내부에서 걸리는 각 함수 별 걸리는 시간을 측정해보고, 시간이 많이 걸리는 함수 내부로 들어가서 그 안에서 라인 별 시간을 측정해내야 합니다. 특정 메써드가 문제였다면, 구글에 “~ faster than [메써드]” 요런 식으로 검색해서 대안을 찾아봐야합니다. 또한, 특정 메써드 문제가 아니라 단순히 저장소에서 이미지를 읽어오는 게 느린 거라면, 데이터가 저장된 위치의 파일 시스템 상 특이점이 있진 않은지 확인해보고 혹은 가지고 있는 저장소 (ex: raid, data1, data2, …) 별 io read 속도를 측정해보시길 바랍니다. 사실 매 경우마다 해결책이 달라 경험적으로 하나씩 늘어가는 부분이긴 하지만, 어찌 되었던 실험을 하시기 전에 최대한 실험 시간을 최적화 시켜놓고 하는 것을 추천드리고 싶습니다. 졸업 논문 기간이 끝나고 여유가 좀 되면 한 번 제가 디버깅/실험 시간을 줄였던 방식에 대해 모두 작성해보도록 하겠습니다. (귀찮지 않으면..?)