20221226월-movie11

wandb와 logger

어제 돌리기 시작한 것이 아직도 돌고 있다. 이게 맞냐.. 데일리 스크럼 때 아예 wandb sweep을 통해 관리를 해보는게 어떻냐는 말이 나와서 차라리 그게 낫겠다는 생각이 들었다. 

찾아보니 nohup으로 만들어진 명령어는 프로세스를 kill시켜야 한다고 하길래 그리했는데,

죽여도 쉘스크립트로 작성해둔 다음 명령어가 계속 실행된다.. 이걸 일일히 kill 하라고..?

그러면 뭐 어떡하냐 다 죽여야지.. 다 죽이고 wandb와 logger를 조금 더 활용해봐야겠다. 좋은 활용처가 있을지도 모른다.

음. logger는 진작부터 활용할 걸 그랬다. 굳이 내가 파일 뜯어가면서 print를 할 필요는 없었네. 어쩐지 왜 주피터 파일에서는 중간 중간 지표가 잘 나오는데 여기에서는 안 나오나 했다.

위는 터미널에 출력되는 것이었다면 이것은 로그 파일로 남는 것이다. 두 쪽으로 전부 출력이 되도록 로거를 설정해둔 모양이다. 중복해서 코드를 작성하지 않은 것을 확인했으니, 뭔가 둘다 표시가 되도록하는 무언가가 있는 것이라고 생각해볼 수 있겠다.

로거 관련 설정이 잘 되어 있어 내가 추가적으로 만질 것은 별로 없을 듯하다. 그보다는 완드비쪽이 조금 문제인데.. 일단 자체적으로 있는 wandb를 보았을 때 기능이 제한적인 것이 조금 느껴진다. 결국 보여주는 게 이 정도밖에 안되는 것이라면, 구태여 이들이 만들어둔 wandb를 활용할 필요는 없겠다. 분명 에폭마다 지표 체크가 되는 것은 장점이기는 한데..

sweep은 어떤가 하고 보는데, yaml 파일에 있던 설정들, 그러니까 config에 들어가는 값들이 전부 올라와 있는 것은 확인할 수 있었다. 근데 final이 있고 file이 있고 internal이 있고 아주 중구난방이다. 이게 문제인 것이다. FISM에는 alpha라는 하파가 있는데, 그것에 대한 sweep 선택지가 없다. 그러면 그냥 에폭마다 보는 것은 포기하고 순수하게 스윕 용도로만 사용하는 것으로 해보자.

나를 가장 애먹게 만들었던 사항. reg_weights는 두 개의 값을 받는데, 이거를 어떻게 표현해야 yaml 파일에서 제대로 인식되는지 모르겠더라고. 결국에는 새로운 타입을 만들었다. 해당 코드는 문자열을 리스트로 인식하게 만들어준다고 한다. 대신 이제부터는 인자를 쓸 때도 정확하게 리스트 형태로 써야만 한다.

일단 내가 원하는 대로 되고 있는 것 같다.

노가다

이제부터는 모든 모델을 적용해보기 위해 간단하게 노가다하는 시간. 아마 모델에 따라 되는 게 있고 안 되는 게 있을 텐데, 각각을 파헤쳐 나가보자고. 

어마무시한 노가다였고만.. ray tune을 사용할 수 있었더라면 구태여 argparse를 이렇게까지 할 일이 없었을 것이라 생각한다. 하지만, 내가 부족해서 이 노가다를 뛰어야만 했다. 팀이 어련히 sweep 돌릴 수 있게 하기 위해서는 내가 이 정도 세팅은 해둬야 한다고 생각한다.

 sweep 이 놈은 왜 가짓수보다 더 많이 도는 것인가? 나올 수 있는 경우의 수가 곱의 법칙으로 딱 6 * 3이면 18개으 ㅣ결과가 나와야만 하는데, 이 놈은 계속 모든 경우를 고려하지도 않으면서 중복되는 인자 조합을 계속 도는 것 같다.

위에 저걸 다 돌았으면 이런 모양이 나올리가 없다. 난감하고만.. bayes로 경우를 구한다고 했던 것 같은데, full이나 랜덤으로 했어야 했나? 간단하게만 생각해도 오른쪽의 각 지점에서 세 갈래의 선이 나왔어야만 했다.

오호. 문서를 뒤지다보니까 찾게 됐다. 결국 무한히 돌게 돼있는 게 맞다는 것이다. 그럼 그냥 내가 어련히 멈추는 것도 당연한 일이구만! 일단 k는 적당히 작은 정도가 좋은 듯하다. 이웃을 적게 두라는 것이다.

일단 정리하자. 오늘 recbole에 대해서 나는 무얼 했는가? log 찍는 것을 더 좋은 방식으로 바꿨고, wandb로 스윕이 가능하도록 바꾸었다. 그리고 모델들의 인자를 추가했다. 
모델로는 ItemKNN, BPR을 돌렸다.
그럼 무엇을 해야 하나? 이제 context-aware 모델을 손을 대봐야 한다. 손을 대는 건 대는 거고, 그 사이에 내 서버는 열심히 내가 만들어둔 모델들을 돌아봐야지!

예제랍시고 들어가있는 파일을 열어보니 결측값이 존재하지 않는다. 그러나 다른 팀에서 공유해준 EDA 정보에 따르면 분명하게 우리는 결측값이 존재한다. 이런 것에 대해 어떻게 좋게 처리할 방법이 없을까? 내가 이전에 파일을 대충 뜯어본 바로는, 결측이 있는 행을 제거하는 식으로 작동했던 것 같다. 결측치를 결측된 채로 둬도 되는 것이 맞는지도 아직은 잘 모르겠다.
근데 얘가 알아서 잘 해주지 않을까 싶기도 하다. 그정도도 못하면서 다 될 것 마냥 만들지는 않지 않았을까..?

회고 및 다짐

이력서를 쓰다보니 새삼 내가 취업 준비를 하고 있다는 게 실감이 났다. 쓸 것 하나 없는 초라한 이력서라는 게 새삼 슬펐다. 정말 기록으로서 남을 것을 한 게 없는 것이다. 일자리 찾을 생각 없이 탱자탱자 놀았던 지난날의 업보라는 거겠지. 사실 정말 놀았냐 하면 내 삶은 분명 그보다는 밀도 있었지만, 그럼에도 결국 취업을 항한 발걸음은 조금도 없었던 것이다.
그렇기에 더더욱 무엇이든 될 수 있고, 무엇이든 할 수 있다고 생각해야겠다. 여태 모난 구석만 길러왔다면 지금부터 그걸 다듬어 견고한 뿔이 되게 하리라.

요지는 이력서 쓰느라 코드를 많이 잡지 못했다는 것. 이런 글을 거의 써본 경험이 없으니 정말 어려웠다. 그러고보면 도대체 나는 부캠을 어떻게 합격한 걸까 다시금 궁금해진다. 다른 사람들 이력서를 보면 다들 무언가 있던데, 나보다 이력으로 뛰어난 사람은 많았을 텐데 왜 내가 뽑힌 걸까?! 다시금 전산 상의 오류가 아니었을까 의심해보지 않을 수가 없는 구석.. AI tech니까 AI를 통해 지원자를 뽑았는데 우연찮게 나를 뽑는 쪽으로 선별했다던가..!

이러고 자자! 항상 나는 자도 서버는 돌아가게 하고 싶다던 꿈을 이제서야 편히 이루는 것 같다.