Aiffelthon의 기록

주어진 시간은 딱 4주. 

지금까지의 결과는 없다.

그 시간동안 어떤 것을 바로 잡았어야 했는지 잊기 전에 기록해본다.

 

1. 대략적인 타임라인에 너무 벗어났다.

2. 꿈과 현실간의 조율이 어려웠다.

3. 주어진 자원을 잘 파악하지 못했다.

4. 주어진 자원을 잘 활용하지 못했다.

5. 실력이 부족했다.

 

1. 대략적인 타임라인에서 너무 벗어났다.

처음 시작할때만 하더라도 내 머릿속에 어느정도의 타임라인이 있었다. 1주차에는 아이디어 회의 및 리서치, 역할분담을 끝내고, 2주차에는 대략적인 모델 아키텍쳐를 구성하고, 데이터셋을 만들 것. 3주차에는 모델 베이스라인 구축 및 fine-tuning, 4주차에는 결과 도출 및 수정할 시간을 그렸다. 하지만 그러지 못했다. 우리는 3주차를 훨씬 넘어 대략적인 모델 아키텍쳐를 구성하기 시작했고, 실질적으로 코드를 만지며 모델링 한 시간이 4/28 - 5/6(오늘까지 8일차) 이다. 8일동안의 치열했던 work-flow는 하기에 기술하기로 한다.

 

2. 꿈과 현실간의 조율이 어려웠다.

너무 그린것이 컸다. 그리고 기술적인 접근이 심각하게 되지 않았다. 허공에 뜬 구름마냥 기술적으로 구현할 수 있는지를 논하기 보다는 너무 먼 미래만 놓고 이것도 저것도 하고싶어하며 방향성만 정하는데 2주가 넘는 시간을 허비하였다. 이 시간이 쓸모없었던 것은 아니지만, 1달의 프로젝트 기간을 감안하면 하지말았어야 하는 일이었다. 주어진 시간내에 완성할 수 있는 부분만 추려내는 작업을 더 냉철하게 했어야 했다. 나중에 필요하다고 끊어내지 않고 논의하던 시간이 독이 되었다. 좀 더 엔지니어링한 시각으로 어떠한 기능을 구현하기 위해 필요한 리소스와 접근 방식에 대해 더 많이 뜯어 생각해봤었다면 더 좋았을 것이다. 이때까지 일하던 방식의 경영학적인 방향성이나 미래확장성은 코드앞에 처참히 깨졌다.

 

3. 주어진 자원을 잘 파악하지 못했다.

우리에게 있었던 자원은 더할나위 없이 훌륭하신 멘토님과, 돌려볼 기회가 흔치않은 v100이라는 장비, 그리고 나와 다른 팀원 둘 뿐이었다. 이 중 가장 큰 실수는 팀원이 둘이 아니라고 생각했던 것. 번외로 함께하고 있던 다른 팀원이 아이펠톤의 모델링을 함께 논의하고 기술적인 부분을 담당하고 있어서 팀원이 둘이 아닌 셋으로 계산했던 것이 가장 큰 오류였다. 아이펠톤에서는 CLAP모델의 encoder만 구현하게 되면서 번외 팀원이 방향이 갈렸고, 우리는 팀원 둘이서 해야하는 상황이 오늘로부터 9일전에 정해졌다. 그리고 그 다음날부터 나는 바로 모델링에 착수하게 되었다. 

 

4. 주어진 자원을 잘 활용하지 못했다.

그러다보니 스타트가 늦었다. 그리고 우리는 장비를 쓸 시간이 짧을 수 밖에 없었다. 당장 쓰고 싶었지만 가진것이 없었다. 

 

5. 실력이 부족했다. 

- 8일전 (금) : 역할분담을 했다. 나는 모델링을, 다른팀원은 데이터셋 형성을 맡기로 하였다. 둘 뿐이어서 역할분담이 금방 되었다. 다음날 있을 세번째 멘토링에 어떻게든 CLAP 모델의 베이스라인을 만들어 가져가고 싶었다. 논문을 읽고 코드를 봤다. 하지만 코드가 눈에 들어오지 않았다. 내가 이때까지 보던 코드와 구조도 다르고, 무슨말인지도 모르겠더라. 그래서 퍼실님께 냅다 뛰어갔다. git에 있는 코드를 주피터 환경에서 실행하는 것도 쉽지 않았는데, GCP 환경설정도 잘 되지 않았다. 이 날은 GCP 설정을 마치고, base-line을 만들었다. pretrained에 사용된 하나의 데이터가 잘 구분되는지 검증했고, 결과는 좋았다. 이미 날은 새서 해가 떴고, 데이터셋도 일부 만들어졌음을 확인하고 잤다.

S1_Model_nozeroshot_genre.ipynb

0.10MB

clap_baseline(ESC50).ipynb

0.10MB

- 7일전 (토) : 오전에 멘토님을 만났다. 모델에 대한 코멘트는 따로 없으셨지만, 사실 코멘트를 주실것도 없었다. 논문대로 구현해놓은 베이스라인에 코멘트하실 것이 없지 않은가. 하지만 데이터셋이 충분치 않다는 사실에 코멘트를 받았다. 지금 속도로 하면 어림도 없다는 말씀이 맞았다. 코멘트를 받은 뒤 바로 팀원과 만났다. 뒤죽박죽인 데이터를 클리닝하여 데이터셋을 만들어 내는것이 급선무였다. 긴 시간 고민끝에 [장르]와 [악기소리] classifier 만들어보자는 것고, 중구난방인 데이터를 살려가는 것보다 형식이 정리된 데이터만 추려가져가는 것이 시간적으로 더 빠를 것이라는 결론을 내고 각자 집으로 돌아갔다.  집에와서 우리의 데이터셋 1개로 baseline에 넣어 zero-shot을 했다. 결과가 처참히 좋지 않았다. 장르도, 악기소리도 맞추지 못했다. 원인을 분석했다. pretrained 된 데이터셋은 범용적이고 자연적인 소리들이었지만, 우리의 데이터셋은 너무 edm에 특화되어 있었고, 여기에 대해 미리 학습이 되었을 것이라고 예상되는 데이터셋이 전혀 없었다. 심지어 장르에 대한 학습 데이터가 있었지만 그들의 라벨링에 EDM자체가 없었다. 결론적으로 우리의 데이터셋이 너무 nitch하다는 생각이 들었고, 조금 더 많은 데이터셋으로 accuracy를 봐야할 필요가 있었다. 아직은 데이터셋이 나온것이 없어 zip형식을 푸는 코드를 완성할 수 있도록 S2이라는 2개의 wav-json pair dataset으로 형식이 맞는지를 체크했다. 그리고 평가했고, 장르에 대해서는 힘들겠다는 느낌이 들었다. 그나마 악기소리는 조금 맞는 부분이 있었다. 하지만 어쿠스틱한 악기를 완전 제외하고 midi sound 중 더 세분화된 소리로 나눠져서 너무 범위가 넓었다. 나중에 쓰일 finetuning용 데이터셋을 먼저 부탁해야 했기 때문에 고민끝에 drum만 추려보기로 했다. drum 안에도 clap, snare, kick, hihat, tom,cymbals 등 총 6개의 카테고리가 나왔다. 다른 팀원이 가진 사운드 중, 이에 해당하는 wav파일만 모았다. 데이터셋 작업만 4시간이 걸렸고, 1440개의 파일을 모았다. 또 해가 떴다. drum dataset의 csv 파일과 json 파일은 다른팀원에게 맡기기로 하고 잤다.

S2_Model_sc,genre.ipynb

0.15MB

  - 6일전 (일) : 데이터셋이 나와야 했다. 어느정도 나온 300개의 데이터셋으로 S300 모델을 다시 구축했다. 이미 만들어진 코드에 경로만 바꿔 넣으면 되는데 이상하게 에러가 뜨면서 해결이 안됐다. 반나절을 헤매면서 찾아낸 결론은 zip을 열 때 json 형식이 맞지 않아서, zip파일에 다른 확장자 파일이 섞여 있어서였다. 팀원과 소통하며 데이터를 계속해서 다시 받았다. 그리고 S300이 돌아갔고, 시각화한 결과로 봤을 때 장르보다는 악기소리쪽이 더 나았다. 하지만 drum의 세부영역까지 맞추지는 못했다. 핑퐁도 있었고, 오류를 해결하는데 많은 시간이 소요되었다.

그리고 멘토님의 새로운 코멘트가 추가되었다. audio와 text emb간의 cos similarity를 구해보았고, 결과적으로 audio와 text 중 하나만 사용할 수는 없을 정도의 유사성이었다. 

S300_Model_sc,genre,cos_similarlity.ipynb

0.17MB

- 5일전 (월) : 데이터셋을 정비했다. S300에서 조금 모자란 데이터셋을 보충하고, 다시 로딩하고, 드럼 데이터셋을 만들기 위해 계속적으로 회의했다. 마지막으로 팀원이 준 drum 1440개의 pair dataset로 fine-tuning 하려고 audio, text emb을 각각 뽑기 위해 코드를 다시 만졌다. 하지만 임베딩을 받아올 수가 없었다. oom 문제가 계속되었고, 해결이 어려웠다. 이때까지의 상황을 slack으로 멘토님께 공유했다. 계속된 밤샘으로 체력의 한계가 왔다. 

finetuning_drum1440_OOMproblem (1).ipynb

0.13MB

- 4일전 (화) : 이제 혼자만의 싸움이었다. 다른 팀원의 역할은 끝났다. 그리고 방향을 잃었다. 더이상 뭘 어떻게 해야하는지 감이 안왔다. chatGPT의 도움으로 pickle과 batch를 주는 방법을 시도해봤지만 계속된 에러로 패닉이 왔다. oom에만 꽂혀서 멍했던 것 같다. 지금 생각해보면 이 때 pickle로 해도 왜 안됐었는지, batch로 한다면 어느부분을 만졌어야 했는지 더 파고들어서 공부했어야 했다. 나는 내가 하고 있는 주피터파일 하나만 보고 있었다. ipynb 말고는 아무 파일도 만져본 적이 없었다. 

- 3일전 (수) : 멘토님의 코멘트와 퍼실님의 코멘트는 동일한 부분이 있었다. 이제는 하이퍼 파라미터를 만질 차례였다. 하지만 나는 주피터 파일 하나로만 실습해왔기 때문에 여러 디렉토리로 나눠져 있는 git의 python 파일들이 너무 어색했다. 어디서부터 해야될지 몰라서 뭘 찾아봐야될지를 몰랐다. 퍼실님을 괴롭혔다. ipynb를 .py로 만들어서 쉘에서 실행해보면 좋겠다는 코멘트를 받았다. 그래픽카드가 아니라 주피터의 메모리 용량에 걸린 것 같다는 추측이었다. 하지만 GCP 서버가 말썽이었다. 이때까지 google에게 실망해본 적이 없는데, gcp는 자꾸 끊기고, 가동도 안되어서 진심 실망했다. 새벽녘에는 가동이 되기 시작했다. 사용자가 적어서 그런가보다. 기대하면서 돌렸으나 py도 oom에 막혔다.

- 2일전 (목) : GCP 사용시간은 오늘로써 끝이었다. oom을 해결하지 못하고 gcp의 파일을 백업하여 lms로 환경을 옮겼다. 잘돌아가던 S300도, 심지어 S2도 돌아가지 않았다. CLAP이라는 모델이 엄청 무거웠다는 사실이 너무 체감되는 순간이었다. 그리고 transfer학습에 있어서 성능이 좋고 풍부한 대기업의 모델들을 얼마나 가볍게 가져올 것인지가 중요하다는 사실을 깨달았다. oom이 발생한 이 상태로 발표자료를 마무리했다. 아직 시간이 있어서 포기할 수는 없었지만, 이리저리 해도 별 소득이 없는 하루였다.

- 1일전 (금) : 마음이 앞서는 하루였다. 이미 열두시가 지나 지금은 토욜이지만 나에게 오늘은 참 길었다. 찾아보다가 내가 지금 하려는 transfer 학습의 범위가 엄청 넓다는 사실과 나의 상황이 최악이라는 것을 알게되었다. 나는 지금 Quadrant 3이다. 가지고 있는 데이터셋도 너무 작고, pretrained dataset과도 너무 다르다. weight를 freeze하라는 것도 어떻게 하는지 모르는데, 그 안의 layer 중에 일부만 freeze 해야한다는 말에 절망했다. 차라리 1440개로 쌩으로 학습한 classifier가 더 빠를 것 같았지만, 찾아볼 수록 그래도 이미 학습되어 있는 model에게 학습효과를 기대해봄이 더 좋다는 말들이 많았다.

그리고 내가 뭘 하고 있는지 자꾸 길을 잃었다. 넋이 나간것처럼 이상한 곳에서 늪에 빠져 허우적 거렸다. 어떻게든 결과를 빼고 싶었고, 가볍게 가져올 수 있는 방법들을 찾았다. 그러면서 깨달았다. 나는 lms를 통해 기본만 알았고, git clone 한 번 해본적이 없었고, python 파일로 연결되어 있는 모델구조도 다뤄본 적이 없다. pytorch도 처음이었다. 어디가 어떻게 연결되는건지 정리가 안되었다. 그런데 또 맘이 급하니까,, hugging face로 넘어가봤다. 하지만 hugging face도 어떻게 쓰는지 몰랐다. 이래저래 방황하다가 뚜렷히 내가 공부해야하는 것이 무엇인지 알았다. transfer learning 하는 방법을 배워야 했다. 어떻게 끌어오는지 기본부터 공부해야 했다. .sh파일이 무엇인지, .pt가 무엇인지도 알게 되었다. 만져보고 저장하고 불러와봤지만 잘 되지 않았다. 내가 불러오려는 .py는 2.19 GB이다. 그나마 diffusion은 빠진 건데도 이렇게 크다. 이것저것 해보다가 또 oom이 터진 주피터파일로 돌아갔다. drum dataset으로 일단 X_train, y_train 및 val, test 데이터셋을 만들어 피클로 저장해두었다. 또 밤을 샜다. 열심히는 아무 위로가 되지 않았다. 결과가 없다는 사실만 마음에 남았다.

Huggingface.ipynb

0.02MB

Finetuning.ipynb

0.55MB

 

- 0일전 (토) : 멘토님을 만나고 현재 상황에서 할 수 있는 부분으로 방향을 수정했다. classifier를 만들어 성능을 평가해보는 것. 원래 하려던 Description 형성을 위해서는 labeling 작업도 많은 시간이 필요하고, transformer 모델을 뒷단에 붙이기에 시간이 부족했다. 그래서 자체 데이터셋으로 트레이닝한 분류기로 성능을 평가해보기로 했다. 한가지 의문이었던 사항은 과연 CLAP의 emb가 유용한가. general, speech한 오디오의 임베딩값이 우리가 하고자 하는 작업에도 transfer learning으로써의 역할을 해줄 수 있을까. 

분류기를 만들었다. drum과 synth안의 세부악기를 구분해내는 분류기이다.

1) 우리의 데이터셋을 CLAP에 zero-shot 하여 emb을 뽑아 피클로 저장한 후에,

2) 만들어놓은 분류기 모델에 input으로 emb tensor를 넣어

3) 얼마나 잘 분류해내는지 결과를 봤다.

처음엔 synth의 세부악기 3개를 분류해내는 것을 시도했는데, 데이터셋이 300개 뿐이라 학습이 잘 되진 않았다.

그래서 drum의 세부악기 5개를 분류해내는 것을 1440개의 데이터로 시도했고, 결과가 괜찮았다.

synthset_classification (1).ipynb

0.06MB

drumset_classification (2).ipynb

0.04MB

 

6. 결론

1) 데이터 수가 너무 적었음에도 불구하고 이정도 결과가 나왔다는 것은 CLAP으로 transfer learning한 emb 값이 있었기 때문이라는 결론이다.  만약 처음부터 맨땅에 헤딩하듯 분류기 모델에 넣었다면 이보다는 훨씬 더 많은 데이터셋이 필요했을 것이다. 역시 공부를 한 번 해본 학생을 가르치기가 쉬웠다. 

2) 이미지의 영역 안에 많은 세부 카테고리가 있듯, 오디오의 영역 안에도 많은 세부 카테고리가 있다. 그리고 우리가 만들고자 했던 것은 사실 누가 얼마나 많은 데이터셋을 생성해 내느냐가 key였다고 생각한다. 하지만 현실적인 한계로 인해 그럴 수 없기 때문에, 이를 해결하는 것이 중요하다고 느꼈다. 다 아는 얘기였지만 직접 겪으니 달랐다. 

3) 그래서 unsupervised하게 라벨을 떼고 contrastive learning으로 input값과 코사인 유사도가 비슷한 음악을 찾아 뱉어주는 모델 정도는 가능하지 않을까, 혹은 음악에 대한 충분한 형용사 라벨링만 있으면 음악으로 사람의 기분을 표현해 줄 수 있는 모델도 가능하지 않을까라는 생각을 해봤다. 

 

7. 많은 시간이 소요되었던 부분들 / 더 공부해야 하는 부분들

- git의 readme에 있던 코드를 어떻게 써야하는지 이해하는 과정

- 내 데이터셋을 연결하는 과정에서 unzip하는 부분

- json 파일의 [ ] 가 있어서 형식이 맞지않아 로딩되지 않던 부분

- oom 문제

- py 로 연결된 pytorch의 자료구조의 이해

- batch 사이즈를 어떻게 조정하는지의 부분

- transformer learning 하는 방법

- huggging face 사용하는 방법