• 원문제목: 11. When to change dev/test sets and metrics
• 최종 업데이트: 2018년 06월 08일
• 목차이동: Machine Learning Yearning 목차
• 저자: Andrew NG
• 원문: http://www.mlyearning.org
• 분류: Setting up development and test sets

새로운 프로젝트를 시작할 때, 필자는 개발 세트와 테스트 세트를 빨리 선정하려 합니다. 그 이유는 이것이 팀에 잘 정의된 지향할 목표를 제공하기 때문입니다.

필자는 일반적으로 1주일 안에 개발팀에 초기 개발/테스트 세트와 측정 항목을 제시할 것을 요청합니다. 개발/테스트 세트를 확보하는 것과 목표를 반영한 평가 지표 선정을 오랫동안 고민하는 것보다는 불완전한 무엇인가를 제시하고 빨리 시작하는 것이 더 좋습니다. 그러나 이런 첫 일주일 패턴이 성숙한 애플리케이션 분야에도 적용되는 것은 아닙니다. 예를 들어서, 스팸 방지는 성숙한 딥러닝 애플리케이션 분야입니다. 이미 성숙한 딥러닝 애플리케이션 분야에서 작업하는 팀의 경우에는 더 좋은 개발/테스트 세트를 만들기 위해서 몇 달을 투자하는 경우도 있습니다.

여러분들이 만든 초기 개발/테스트 세트 혹은 목표 지표에 중요한 것이 삐졌다는 것을 파악했다면, 신속하게 변경하면 됩니다. 예를 들어서 개발 세트와 평가 항목이 분류기 A를 분류기 B보다 우수하다고 평가했지만, 개발팀은 분류기 B가 분류기 A 보다 실제로 더 우수하다고 생각한다면, 이것이 바로 개발/테스트 세트 혹은 평가 항목을 변경해야 한다는 신호입니다.

개발 세트와 평가 항목이 분류기 A를 잘못 평가한 이유는 다음 3가지 원인에서 찾을 수 있습니다.

1. 잘 동작해야 할 실제 데이터 분포가 개발/테스트 세트와 다르다.

초기 개발/테스트 세트가 주로 성장을 마친 고양이 사진으로 만들어졌다고 가정해 보겠습니다. 고양이 앱을 배포했는데, 사용자들이 예상과 달리 새끼 고양이 이미지를 더 많이 올리고 있음을 알게 되었습니다. 이것은 개발/테스트 세트 분포가 실제 환경에서 수행해야 하는 실제 데이터 분포와 다르다는 것을 의미합니다. 이 경우에 개발팀은 개발/테스트 세트가 현실 데이터를 더 잘 표현하도록 업데이트해야 합니다.

2. 개발 세트에 과적합 된 상태다.

개발 세트를 이용하여 알고리즘을 반복적으로 평가하는 과정에서, 알고리즘은 개발 세트에 점진적으로 과적합되는 경향을 보입니다. 개발이 완료된 다음 알고리즘을 테스트 세트로 평가합니다. 만약 개발 세트 성능이 테스트 세트 성능보다 훨씬 더 좋은 상황이 발생한다면, 이것은 알고리즘이 개발 세트에 과적합 되었다는 신호입니다. 이 경우 새로운 개발 세트를 만들어야 합니다.

팀의 진행 상황을 추적해야 하는 경우 시스템을 정기적으로 평가할 수도 있습니다. 예를 들어, 테스트 세트로 일주일에 한 번 또는 매월 한 번씩 시스템을 평가할 수 있습니다. 그러나 지난주의 시스템으로 롤백할지 여부와 같은 알고리즘과 관련된 결정을 내릴 때 테스트 세트를 사용하면 안 됩니다. 만약 이런 결정에 테스트 세트를 사용하게 된다면, 시스템은 테스트 세트에 과적합 하기 시작할 것이고, 더 이상 시스템 성능에 대한 공정한 평가 지표를 제공할 수 없을 겁니다. (이런 부분은 연구 논문을 발표해야 하거나, 아마도 비즈니스 의사 결정을 내릴 때 이런 측정 항목을 사용해야 하는 상황에서만 필요합니다)

3. 프로젝트 최적화와 상관없는 평가항목을 측정하고 있다.

고양이 애플리케이션의 평가 항목은 분류 정확도라고 가장합시다. 이 측정 항목은 현재 분류기 A가 분류기 B보다 우수하다고 평가합니다. 그러나 여러분이 두 분류기를 모두 사용해 보니, 분류기 A가 가끔 포르노 이미지를 통과시켰다는 사실을 발견했습니다. 분류기 A가 더 정확하기는 하지만, 분류기 A 성능을 수용할 수 없습니다. 포르노 이미지가 서비스에 등록 된다면 서비스 사용자는 고양이 앱에 대한 나쁜 인상을 받게 될 것이기 때문입니다.

여기에서 사용한 평가 항목은 알고리즘 B가 실제로 알고리즘 A보다 우수하다는 사실을 식별하지 못했습니다. 따라서 최상의 알고리즘을 선택하는 평가 항목으로 현재 지표를 신뢰할 수 없습니다. 이런 상황이 바로 평가 항목을 변경해야 하는 시점입니다. 예를 들어, 포르노 이미지를 허용하는 시스템에 높은 불이익을 부과하도록 평가 항목을 변경할 수 있습니다. 신뢰할 수 없는 평가 항목을 사용하면서 수작업으로 분류기를 선택고 되돌리는 방식을 계속 사용하면 안 됩니다. 이보다는 새로운 평가 항목을 선정하고, 팀에 새로운 목표를 명시적으로 정의하는 것이 바람직합니다.

프로젝트를 진행하면서 개발/테스트 세트와 평가 항목을 변경하는 것은 일반적인 모습입니다. 초기에 개발/테스트 세트 및 평가 항목을 사용하여, 개발 주기를 빠르고 신속하게 반복할 수 있습니다. 현재 사용하는 개발/테스트 세트와 평가 항목이 더 이상 프로젝트에 적합하지 않다는 것 자체가 문제가 되지 않습니다. 이런 문제를 파악했다면 적합한 개발/테스트 세트와 평가 항목을 재정의 하면 됩니다. 데이터와 평가 지표를 재정의 했다면, 팀이 새로운 데이터와 목표에 대해서 알고 있는지 반드시 확인해야 합니다.