호기심 많은 분석가
[BoostCamp] Week4_Day19. 팀 병합의 날 본문
🕵🏻♂️마스크착용 분류 대회
- 멘토링한 결과를 토대로 여러가지를 변화시켜봄
1. Argparse 사용
- argparse를 통해 hyperparameter나 file_path들을 설정해주면서 좀 더 다양한 실험들이 편하게 가능해짐. 일일이 적다보면 헷갈리거나 작업이 꼬일 때가 있었는데 argparse라는 좋은 라이브러리를 알게 되면서 적용이 용이해졌다.
2. Commit 규칙 정하기
- 하나의 기능을 구현하거나 (앙상블, 테스트 코드 등), 대략 —줄을 작성했을 때 커밋한다라는 규칙을 정하고 습관을 만들면 더 효율적일 것이다
- Commit 이름의 말머리를
[기능추가] [오류수정] [테스트코드] [코드정리]
와 같은 나름의 규칙을 정하는 것도 좋다.- 아직 정확한 규칙을 정하지도, 깔끔하지도 않지만 비교적 보기 좋은 Commit이 되었다. 멘토님이 알려주신 규칙들을 기반으로 나만의 규칙을 생성해보자
3. 프로젝트 템플릿 사용
- 우리가 쓰는 프로젝트 템플릿이 config.json도 사용하고 꽤 복잡해서 따르지 않고 있었는데, 그런 복잡한걸 제외하고 템플릿에 맞춰 코드를 수정해봤다.
- 남들이 알아보기 더 쉬워지고 코드가 간결해지고, 찾기 편해져서 이러한 기준을 정해놓고 따르는 프로세스를 앞으로의 대회에서도 적용할 것이다.
4. 시도한 것
- 좀 더 무거운 모델 돌려봄
- 한 epoch 당 성능이 올라가는 폭이 너무 낮아서 여러 epoch을 돌려야 할 듯
- 기존 모델에서 Epoch 증가 → 10 Epoch이 가장 적절한 것으로 판단
- Batch_size 256 Test → 우리 모델과 데이터에는 128이 가장 좋은 듯하다
- Augmentation → GaussianBlur, RandomRotation
- GaussianBlur를 적용하면 시간이 훨씬 많이 들고, 중년층과 노년층을 잘 구분 못하는 것으로 판단
5. 코드 리뷰
멘토님께서 코드 리뷰도 해주시고, 질문도 해결해주셨다
- 숫자가 포함된 변수를 만들기 위해 global을 이용하고, 그것을 반환하였는데 어차피
리스트만 필요하니까 할당하지말고 list에 append하라는 조언을 받음- 너무 훌륭한 조언이셨음. 내 생각이 갇혀 있었는 데 그 혈을 뚫어주셨다.
- 다른 .py를 불러와서 실행시킬 때 if name=='main': 부분은 왜 실행이 안되는가?
- 그 명령어 자체가 이 파일을 실행시킬 때만 작업을 하라는 의미
- 파일을 실행시키면 지금 파일의 이름이 main이 되는데, 다른 파일을 불러온 것이므로 당연히 그 파일의 이름은 main이 아니고, if문이 실행되지 않음
- 코드리뷰
- 이슈로 조언해주셔서 그 부분 수정하고 closed
📙개인학습
(9강) Ensemble
- 모델마다 특성이 다르다, 잘 잡는 클래스가 다를 것
- 여러 실험을 하다보면 여러가지 모델로 여러 결과를 만들었을 것이다. 그 결과들을 결합해서 성능을 높이는 방법
- 현업에서는 주로 사용하지는 않음. 성능은 높아질 수 있으나 무거워지기 때문에 프로덕트 관점에서 좋지 않다.
- Competition이나 성능이 굉장히 중요한 도메인에서 사용
1. Ensemble(앙상블)
- 싱글 모델보다 더 나은 성능을 위해 서로 다른 여러 학습 모델을 사용하는 것
Ensemble of Deep NN
- Low Bias, High Variance → Overfitting
- 딥러닝의 경우 깊은 학습을 하기 때문에 오버피팅이 날 가능성이 더 높다.
- Bias가 높은 쪽에 있는 모델들에 취해주는 방법이 부스팅
- 모델을 순차적으로 학습하는 방향을 더 나은 방향으로 계속해서 진행해주는 것
- LGBM, XGboost,...
- High variance에는 배깅을 주로 씀
- 각각의 데이터셋에 대한 모델의 결과를 취합해서 평균 냄
- RandomForest,...
2. Model Averaging(Voting)
- 일반적인 경향에서 딥러닝에는 Model Averaging이라는 ensemble 기법을 활용해줌
The reason that model averaging works is that different models will usually
not make all the same errors on the test set
Averaging이 좋은 효과를 보이는 이유는 다른 모델이 같은 에러를 거의 발생시키지
않기 때문이다
- Hard Voting - 다수결, 애매한 class를 맞추기 어려울 수 있음, 그래서 Soft voting 방식을 주로 사용
- Soft Voting - 각각의 class 확률을 모두 봄, 일반적으로 Soft Voting이 성능이 좋음
3. Cross Validation
- 훈련 셋과 검증 셋을 분리를 하되, 검증 셋을 학습에 활용할 수는 없을까?
3-1. Stratified K-Fold Cross Validataion
- 가능한 경우를 모두 고려 + Split시에 Class 분포까지 고려
4. TTA (Test Time Augmentation)
- 테스트할 때 Augmentation을 어떻게 한단거야?
- 테스트 셋에 augmentation을 줘서 결과가 어떻게 되는지 지켜봄, 그 결과들을 합쳐서 점수를 뽑아내는 것
성능과 효율의 Trade-off
- 앙상블 효과는 확실히 있지만 그만큼 학습, 추론 시간이 배로 소모됨
Hyperparameter Optimization
- Hyperparameter : 시스템의 매커니즘에 영향을 주는 주요한 파라미터
- Learning rate, Batch size, Hidden layer 갯수, Loss 파라미터, Optimizer 파라미터,
k-fold, Dropout, Regularization
- Learning rate, Batch size, Hidden layer 갯수, Loss 파라미터, Optimizer 파라미터,
- 파라미터를 변경할 떄마다 학습을 해야하니 힘들다. 시간과 장비가 충분하다면 해볼만함 → 그래서 딥러닝에서는 잘 사용하지 않음
Optuna
- 파라미터 범위를 주고 그 범위 안에서 trials만큼 시행
(10강) Experiment Toolkits & Tips
1. Training Visualization
1-1. Tensorboard
- 학습 과정을 기록하고 트래킹하는 것도 중요하다.
- 사용법
1-2. Weight and Bias (wandb)
- 딥러닝 로그의 깃허브 같은 느낌
- init, log 설정
2. Some tips
2-1. 분석 코드보다는 설명글을 유심히 보세요
- 필자가 생각하고 있는 흐름을 읽을 수 있습니다.
2-2. 코드를 볼 때는 디테일한 부분까지
- 언제든 활용할 수 있을 정도로..
2-3. Paper with Codes
- 최신 논문과 그 코드까지
2-4. 공유하는 것을 주저하지 마세요
- 새로운 배움을 기회가 될 수 있습니다.
👨👨👦👦피어세션
😏굿모닝세션
- 팀 병합 완료
- 원상님 가중치를 조금 줘보니 결과가 괜찮았다. 조정해볼 것
- 10번 제출을 어떻게 할까?
- 인 당 1번씩은 자유롭게하고 나머지 4번은 합의하에 ! 누군가 제출을 안할 시 미리 공지해주면 다른 사람이 더 실험해볼 수 있게
- focal loss를 도입해보자!
- 작업 방향성은 이따 1시에 멘토님한테 여쭤보기로 함
😄굿애프터눈세션
- 베이스라인을 짜서 진행해보자 → 결과 제출을 기반으로 피드백을 할 것인가, 트레인 셋 중 테스트 셋을 따로 분리할 것인가에 대한 깊은 토론 → 투표 → 사다리
- 테스트 셋을 분리한 채로 작업을 진행하기로 함, 원상님께서 내 모델을 기반으로 baseline 코드를 짜주신다고 함
👨🏻🏫멘토링
- 각자 일주일 어떻게 보냈는지 이야기하고 작업 진행에 필요한 argparse, commit 규칙 정하기, Q&A, 코드 리뷰 등등 정말 많은 것을 도와주심
- Day19 참고!!
- 깔끔한 코드 작성을 위한 책도 추천해주심
✍🏻학습회고
EarlyStopping 코드를 짜다 오류가 나서 여러번 번복했는데, 실험은 짧게 걸리는 코드에서 해야함을 뼈저리게 느꼈다. 실험과 실패에 많은 시간이 걸렸고, 결국 완성시키면서 EarlyStopping과 checkpoint, 무거운 model 등을 실험해봤지만 좋은 성과를 거두진 못했다.
오늘부터 팀 병합이었기 때문에 앞으로의 방향성에 대해 정말 심도 깊은 토론을 나눴다. 하루 10번의 제출 기회를 각자 1번과, 남은 4번은 공통의 코드로 진행하기로 했는데, 공통의 코드를 train set에서도 test set을 분리해두고 작업을 해야하느냐, train과 val만 나누고 submission으로 피드백해야하느냐에서 토론이 이어졌다.
Product 관점에서는 전자가 좋겠지만, 학습 데이터 셋이 충분하지 않았기에 Competition에서는 후자가 낫다고 생각했다. 오랜 토론 끝에 투표를 했는데 3대 3이 나와서 결국은 사다리로 전자의 방법을 따르기로 했다. 그 외 StratifiedKFold를 사람이 섞이지 않게 할 것인지, 섞이게 할 것인지, model은 어떤 것을 쓸건지 등은 Option으로 두기로 하고 실험적으로 결론을 내기로 결정했다.
가장 결과가 좋았던 내 모델을 base로 팀원분이 baseline을 작성해주시기로 하였고, 그걸 위해 멘토님의 조언과 템플릿에 맞춰 코드를 가독성 좋게 만드는 작업을 오래 했다. 그 작업 속에서 마찬가지로 하면서 점점 익숙해지고 템플릿의 효율을 느꼈고, 협업 능력이 더 향상되었다. 대회 초반에 빠른 baseline을 만들기 위해 작성했던 가독성 나쁜 코드들을 upgrade 시키면서 뿌듯했고, 앞으로도 이러한 방향으로 코드를 짜야겠다.
'Coding > BoostCamp' 카테고리의 다른 글
[BoostCamp] Week5_Day21. 실수를 통한 발전 (0) | 2021.09.02 |
---|---|
[BoostCamp] Week5_Day20. 6일만의 상승 (6) | 2021.09.01 |
[BoostCamp] Week4_Day18. 여러가지 실험들 (0) | 2021.08.31 |
[BoostCamp] Week4_Day17. 여러번의 실패와 깊은 이해 (0) | 2021.08.30 |
[BoostCamp] Week4_Day16. 모델의 완성 (0) | 2021.08.27 |