티스토리 뷰
보통 새로운 프로젝트를 시작할 때, 나는 빠르게 개발 데이터/테스트 데이터를 선정한다. 이를 통해서 우리가 추구하는 잘 정의된 목표를 찾을 수 있기 때문이다.
나도 보통 우리팀한테 초기의 개발/테스트 데이터와 초기 평가 지표를 찾아내는데 1주일을 넘지 않게 준다. 한가지 주제에 대해서 과도하게 생각하기 보다는 뭔가 완벽하지는 않지만 빠르게 얻어내는게 조금더 낫기 때문이다. 하지만 이 1주일이라는 시간은 우리가 만들고 있는 것을 발전시키는데 반영되지는 않는다. 예를 들어 스팸차단 시스템은 이미 발전된 형태의 딥러닝 시스템이다. 이렇게 발전된 형태의 시스템도 더 좋은 개발/테스트 데이터를 얻기 위해서 몇달을 쓰곤한다.
만약 나중에라도 초기에 잡은 개발/테스트 데이터나 평가 지표가 뭔가 초점에서 어긋났다는 것을 인지했다. 제발 그 것들을 빨리 바꿨으면 한다. 예를 들어, 너의 개발 데이터와 평가 지표가 분별기 A가 분별기 B보다 더 좋다고 매기지만, 실제로 분별기 B가 더 당신이 만들고자 하는 제품에 좋다고 생각한다면, 이건 어쩌면 지금 사용하고 있는 개발/테스트 데이터나 지금 사용하고 있는 평가 지표를 바꿀 필요가 있다는 것을 알려주는 신호가 될 수 있다.
보통 위와 같이 분별기 A가 더 좋다고 개발데이터나 평가 지표가 잘못 평가하는 이유가 크게 3가지가 있다.
1. 정말로 필요한 것의 실제 데이터 분포가 개발/테스트 데이터의 분포와 다르다.
만약 당신이 가지고 있는 초기 개발/테스트 데이터가 다큰 고양이의 사진을 주로 가지고 있다고 가정해보자. 그리고 이걸 바탕으로 만든 앱을 출시하고, 예상했던 것보다 아기 고양이의 사진을 많이 올리는 사람을 찾게 된다. 그렇게 되면 이전에 썼던 개발/테스트 데이터의 분포는 우리가 실제로 필요로 하는 데이터들의 분포들을 전혀 대표하지 못하게 된다. 이같은 경우에는 사용했던 개발/테스트 데이터들을 조금더 대표성을 띄겠끔 변경해줘야 한다.
2. 지금 사용하고 있는 개발 데이터가 overfitting되어 있다.
개발 데이터에 대해서 계속 반복적으로 평가하다보면 궁극적으로 사용하고 있는 알고리즘이 개발 데이터에 대해 "overfitting"되는 현상을 야기할 수 있다. 개발을 다 하고 난후에 이제 테스트 데이터를 가지고 만든 것을 평가하게 될텐데, 만약 개발 데이터상에서 측정한 결과가 테스트 데이터의 결과보다 더 좋게 나온 것을 확인했다면, 이건 어쩌면 지금 만든 것이 개발 데이터에 대해서 "overfitting"되고 있다는 신호일 수 있다. 이 경우에는 새로운 개발 데이터를 찾아야 한다.
만약 개발팀이 만든 성과에 대한 진척도를 확인하게 되면 아마 만든 시스템도 주기적으로 테스트 데이터를 활용해서 1주일에 한번이던 한달에 한번이던 평가를 하게 될것이다. 그런데 뭔가 알고리즘에 변화를 주는데 이 테스트 데이터를 쓰면 안된다. 여기에는 이전 시스템을 완전 뒤엎는 것도 포함해서 말이다. 만약 이렇게 한다면 테스트 데이터에 대해서도 overfit 하기 시작할 것이고, 이제 더이상 만든 시스템의 성능을 평가하는데 있어 완전히 어느쪽에 치우치지 않는 것으로 볼수 없게 된다.(예를 들어 논문을 쓴다던가 이것을 활용해서 중요한 비지니스 결정을 내리던지 이런 것으로 활용할 수 없게 되는 것이다)
3. 평가 지표는 프로젝트에서 최적화되어야 할 것을 찾는다기 보다는 단순히 뭔가를 측정하는 것이다.
앞에서 언급한 고양이 앱을 놓고 봤을때, 평가지표는 분류 정확성이라고 할 수 있다. 이 평가지표는 현재 분류기 A가 분류기 B보다 좋다는 것을 보여주고 있다. 그런데 만약 여러 알고리즘을 시도해봤을 때 분류기 A가 가끔 포르노 이미지를 보여줄 수도 있다고 생각해보자. 이렇게 되면 비록 분류기 A가 더 정확할 지라도, 포르노 이미지로 인한 나쁜 인상을 주게 되고, 결국 이 성과가 의미가 없게 된다. 이러면 어떻게 할 수 있을까?
위의 예시에서는 평가 지표가 당신 제품에선 알고리즘 B가 실제로는 알고리즘 A보다 좋다는 것을 판별하는데 실패했다. 이렇게 되면 더이상 최고의 알고리즘을 가리는데 해당 평가 지표를 신뢰할 수 없게 된다. 이때는 평가 지표를 바꿔야 한다. 예를 들어 포르노 이미지를 통과시켰을 때는 강하게 패널티를 줄수 있도록 평가 지표를 바꿀 수도 있다. 나는 보통 신뢰할 수 있는 평가 지표를 배제하고 오랫동안 돌려본다던가, 분류기 들간에 수동적으로 선택되는 것을 뒤집던지 같은 방식보다는 새로운 모표를 명확히 정의하고 그것에 대한 새로운 평가 지표를 선택할 수 있도록 강력하게 권한다.
프로젝트를 진행하는 동안 개발/테스트 데이터를 바꿔본다던가 평가 지표를 바꿔보는 것 자체가 매우 흔하다. 초기 데이터나 평가 지표를 사용하면 빠르게 돌릴 수는 있다. 하지만 이런 데이터나 지표가 팀이 나아가야 할 바른 방향을 제시하지 못한다면 이는 소용없는 것이다. 한번 그런 것들을 바꿔보고 팀이 어디로 나야갈지 방향을 결정할 수 있도록 하자.
< 해당 포스트는 Andrew Ng의 Machine Learning Yearning 중 chapter 11. When to change dev/test sets and metrics 을 번역한 내용입니다.>
'Study > AI' 카테고리의 다른 글
[MLY] 오류 평가: 아이디어 검증을 위한 개발 데이터 예제 탐색 (0) | 2018.09.06 |
---|---|
[MLY] 빠르게 구현하고 나서 반복하기 (0) | 2018.09.05 |
[MLY] 개발 환경과 테스트 데이터를 설정하는 데 있어 고려해야 할 사항들 (0) | 2018.09.05 |
[MLY] 개발 데이터와 지표는 반복작업을 빠르게 해준다. (0) | 2018.09.03 |
[MLY] 최적화 지표와 만족 지표 (0) | 2018.09.02 |
[MLY] 최적화를 위해서는 단수 형태의 평가 지표를 취해라 (0) | 2018.09.02 |
[MLY] 개발 데이터와 테스트 데이터는 얼마나 많이 수집해야 할까? (0) | 2018.09.02 |
- Total
- Today
- Yesterday
- Kinect for windows
- End-To-End
- windows 8
- reward
- DepthStream
- Offline RL
- RL
- Off-policy
- ColorStream
- Windows Phone 7
- PowerPoint
- 파이썬
- arduino
- ai
- Expression Blend 4
- Gan
- Pipeline
- Kinect SDK
- TensorFlow Lite
- bias
- processing
- Policy Gradient
- 딥러닝
- Variance
- dynamic programming
- 한빛미디어
- Distribution
- Kinect
- SketchFlow
- 강화학습
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |