티스토리 뷰

- 당신이 미래에 얻길 원하고, 잘 동작하기를 원하는 성향을 잘 반영한 분포를 가지는 개발 데이터와 테스트 데이터를 취해라. 어쩌면 그 데이터들은 학습 데이터의 분포와 같지 않을 수도 있다.

- 되도록이면 개발 데이터가 테스트 데이터와 분포가 같은 것들을 취하라.

- 최적화할 수 있는 단수 형태의 평가 지표를 선정하라. 만약 신경써야할 goal이 여러 개라면, 그 값들을 하나의 공식을 통해서 결합하던가(예를 들어 여러 개의 오차 지표의 평균을 낸다던가) 혹은 만족 지표와 최적화 지표를 정의하던지의 방식을 적용해라.

- 머신러닝 자체는 매우 반복적인 작업이기 때문에 어떤 적당한 알고리즘을 찾기 전에는 수많은 알고리즘들을 시도해볼 수 있을 것이다.

- 개발/테스트 데이터를 가지고, 뭔가 단수 형태의 평가 지표를 가지게 되면 수많은 알고리즘들 평가하는 것이 빨라질 것이고, 이로 인해 매우 빠르게 반복적으로 수행할 수 있게 된다.

- 만약 새로운 어플리케이션을 만들게 된다면, 적어도 1주일 안에 정의할 수 있는 개발/테스트 데이터와 평가 지표를 빠르게 선정하라. 만약 이미 활성화된 어플리케이션을 개선하는 과정이라면 이런 과정은 조금더 길어져도 좋다.

- 과거에 일반화되어 있던 70%:30% 비율로 train set과 test set을 나누는 방식은 만약 수많은 데이터를 축적하고 있는 문제에서는 적용되지 않는다. 이런 경우에는 개발 데이터와 테스트 데이터의 비율을 전체의 30%보다 적게 구성해야 한다.

- 아마 선정한 알고리즘의 정확성 측면에서 뭔가 의미있는 변화를 감지하기 위해서는 개발데이터가 충분히 많아야 하지만, 그렇다고 엄청 많을 필요는 없다. 테스트 데이터는 실제 시스템의 최종적으로 얻을 수 있는 성능이 어느정도 신뢰성을 가질 수 있을만큼 충분히 많아야 한다.

- 만약 지금 사용하고 있는 개발 데이터와 평가지표가 현재 모델에서 바르지 않다는 것을 알았을 경우에는 빨리 그 것들을 바꿔라. 
1) 만약 개발 데이터에 대해서 overfit되는 상황이라면, 그 개발 데이터를 조금 더 수집해라
2) 만약 실제로 고려하는 데이터의 분포가 가지고 있는 개발/테스트 데이터의 분포와 다르다면 새로운 개발/테스트 데이터를 수집해라.
3) 만약 선정한 평가지표가 더이상 무엇이 중요한지 알려줄수 없다면 해당 지표를 변경해라.

< 해당 포스트는 Andrew Ng의 Machine Learning Yearning 중 chapter 12. Takeaways: Setting up development and test sets 을 번역한 내용입니다.>

댓글