배부른데 배고프다
최근 논문 작성하면서 뼈저리게 느낀 부분이 몇 가지 있는데 드디어 이걸 갈아엎을 심판의 시간이 왔다. 고질적인 문제는 수두룩 하지만 그 중 대표적인 거 두 가지는
- 이중 configuration 사용 및 easydict
- 독립된 코드짜기
이다. 이를 해결하기 위해 (아직 해결못함) 머리 굴리는 회고.
Configuration
왜 마음에 드는 configuration이 없는걸까. 내가 못 쓰는건가. 서드파티 라이브러리를 사용하면... 업데이트될 때마다 긴장을 해야하기 때문에 걱정된다. Hydra랑 Fire는 먼소린지1도몰으겟고 (사실 제대로 공부할 마음이 없는 것) argparse 쓰자니 parser.add_argument가 너무 못생겼다 (참을 수 없어). 현재까지는 dataclass를 사용하는게 제일 마음에 드는데 문제는 얘도 argument로 사용하려면 라이브러리가 필요하다는 것! class로 짜면 깔끔하고 설명도 많이 붙어있어서 좋긴한데 argument parser 형태로 쓸 수 있는게 built-in에서 지원되는 게 없다보니 설정값 하나 바꾸려면 코드를 바꿔야하는데 이것도 불편하다. (프로불편러) CLI에서 argument로 집어넣는 방식을 선호하는 이유는 wandb에서도 내가 어떤 argument 넣었는지 기록이 되기 때문이다! 일단 Huggingface에서 사용하는 argument가 내가 고집하는 방식으로 돌아가는데 얘네의 argparser를 긁어왔다. 원래 같으면 긁어올 생각을 안했는데 built-in만 사용하길레 끄덕 하고 가져왔다.
https://huggingface.co/transformers/v4.3.3/_modules/transformers/hf_argparser.html
transformers.hf_argparser — transformers 4.3.0 documentation
© Copyright 2020, The Hugging Face Team, Licenced under the Apache License, Version 2.0
huggingface.co
이중 Configuration 문제 같은 경우는 기존에 yaml 파일을 사용해서 안에 중첩으로 config 넣어놓은 것들을 말한다. 굳이 이렇게 사용한 이유는 설정값이 갈수록 종류가 많아져서 묶어서 나눠 보낼 필요가 있었다... (예를 들면 dataloader나 trainer에 들어가는 얘들은 분리해서 들어가도되니까) 일단 HF 방식으로 사용하면 처음부터 다른 class로 만들어서 합치는 구조이기 때문에 가능하기도 하고 __post_init__에서 추가로 건드려도 될 것 같아서 이 방법을 채택하기로 했다.
독립된 코드짜기
내 연구가 애초에 돌리기만하고 끝-이 아니라 결과분석을 굉장히 많이 해야하는데 처음 코드 짤 때 이 생각을 안하고 너무 막짰더니 코드가 점점 개판이다. 당장 연구는 내야하니까 급하게 땜빵식으로 막아놨던 코드들이 스노우볼이 되어서 나를 덮치고...... (아찔) 기존에 domain generalization 분야 코드도 한 번에 섞어서 할 생각에 점점 더 짬뽕으로 치닫는 코드들을 확실히 정리할 필요가 생겼다. 특히 모델을 불러오는 부분이 많이 더러운데 config에서 모델을 받음 > 모델에 맞춰서 config 설정 > 모델에 보냄 이 구조인데 중간에서 하는 일이 너무 많기도하고 의존성도 생겨서 더럽다. 빨리 치워야지.