11 When to change dev/test sets and metrics

새로운 프로젝트를 시작할 때, 최대한 빨리 개발/테스트 데이터셋을 선택 하려고 노력하곤 한다. 왜냐하면 이 데이터셋들에 대한 빠른 선택은 잘 정의된 목적(타겟)이나 방향성을 제시 해 주기 때문이다.

나는 보통 첫번째로 선택 될 개발/테스트 데이터셋과 측정지표(metric)을 1주 이내로 생각해달라고 팀에게 요청한다. 완전하지 않는 것을 생각해낸 후, 다음 수순으로 빠르게 움직이는 것이 필요 이상으로 과하게 생각하는 것 보다 더 낫기 때문이다. 하지만, 그 한주 동안의 시간을 보내는 것은 이미 성숙된 어플리케이션에 대한 개발에는 적용되지 않는다. 예를 들어서, 스팸 차단기는 이미 꽤나 성숙된 딥러닝 어플리케이션이다. 이와같은 성숙한 시스템에 대해서 일을 하는 팀들을 많이 봐 왔고, 나는 그들이 더 나은 개발/테스트 데이터셋을 구하기 위해서 수개월의 시간을 보내곤 하는 것을 목격한 바가 있다.

만약에 첫번째 로 선택한 개발/테스트 데이터셋과 평가 지표가 뭔가 잘못되었음 을 알게 된다면, 이는 단순히 그 데이터셋들과 평가지표를 빨리 바꿔야 함을 의미할 뿐이다. 예를 들어서, 만약 개발 데이터셋과 평가지표가 A 라는 분류 알고리즘이 B 라는 분류 알고리즘보다 더 좋다고 순위를 매겼지만, 팀은 분류 알고리즘 B가 사실상 개발 대상이 되는 상품에서는 더 나은 성능을 보여준다고 생각하는 경우가 있을 수 있다. 이러한 현상은 개발/테스트 데이터셋 또는 평가 지표를 변경해야 한다는 시그널이라고 판단할 수도 있겠다.

분류 알고리즘 A가 더 낫다는 잘못된 판단을 하는데에는, 개발 데이터셋과 평가지표에 관한 기본적인 세 가지 발생 가능한 원인 이 있을 수 있다.

1. 실제로 좋은 성능을 보여주길 원하는 데이터의 분포가 설정된 개발/테스트 데이터셋과 다르다.

2. 개발 데이터셋에 과적합 되는 경우가 있을 수 있다.

3. 측정 지표가 프로젝트가 최적화 해야하는 것 이외의 것을 측정 하는 경우가 있을 수 있다.

개발/테스트 데이터셋 또는 평가 지표를 프로젝트 진행 도중에 변경하는 것을 꽤나 흔한 일이다. 최초에 고른 개발/테스트 데이터셋과 평가지표는 프로젝트 개발 사이클을 더 빠르게 돌 수 있도록 도와줄 것이다. 만약 개발/테스트 데이터셋 또는 평가 지표가 더이상 당신의 팀이 향해야 하는 방향을 가이드 하지 못한다는 것을 발견한다면, 그렇게 심각하게 고민할 필요 없다. 그냥 새로운 방향을 제시할 수 있는 데이터셋과 평가 지표로 바꿔서 당신의 팀원들에게 명쾌한 방향을 제시하면 된다.