티스토리 뷰
새로운 문제를 딱 접했을 때, 어떤 접근 방식이 가장 잘 동작하는지 미리 아는 것은 매우 어려운 일이다. 많은 경험이 쌓인 머신러닝 엔지니어라도 만족스러운 결과를 얻을 때까지 다양한 아이디어들을 시도해본다. 머신러닝을 적용한 시스템을 만들때, 나는 보통 이렇게 한다.
1. 시스템을 어떻게 만들 수 있는지 몇가지 아이디어를 내본다.
2. 그런 아이디어들을 코드로 구현해본다.
3. 어떤 아이디어가 동작하는지 실험을 해본다.(종종 몇몇 아이디어들은 잘 동작하지 않는다.) 이런 학습을 통해서 다시 아이디어를 내보고, 반복해본다.
이건 일종의 반복 작업이다. 이런 반복 과정을 빠르게 수행할수록, 일의 진척이 빨라진다. 이게 바로 개발 데이터/테스트 데이터를 가져야 하고, 평가 지표가 중요한 이유이다. 매번 새로운 아이디어를 시도해볼 때, 개발 데이터 상에서 아이디어의 성능을 측정함으로써, 지금 진행하고 있는 방향이 옮은 방향인지를 빠르게 확인할 수 있다.
반대로 개발 데이터나 평가 지표가 없다고 가정해보자. 매번 새로운 분별기를 개발했을 때, 이걸 실제 사용 케이스에 넣어봐야 한다. 그리고 적어도 몇시간동안 그걸 동작시켜보면서 만든 분별기가 정말 잘 만든 건지를 확인해봐야 한다. 이런 과정은 정말 느리다. 또 새로운 감별기의 정확성을 기존의 95%에서 95.1%로 높였을때, 0.1%의 증가폭은 실제 해보는 것으로는 확인할 수 없다. 물론 시스템을 만드는데 있어 수많은 진전이 다양한 개선을 통한 0.1%의 성능 향상들이 계속적으로 누적됨으로써 이뤄지는 것이다. 개발 데이터를 가지고, 평가 지표를 가지는 것 자체가 적은 개선을 통해서도 빠르게 아이디어가 좋은지 나쁜지를 결정할 수 있게 해주고, 결과적으로 어떤 아이디어를 계속 정제할 것이고, 버릴 것인가를 빨리 결정할 수 있게 해준다.
< 해당 포스트는 Andrew Ng의 Machine Learning Yearning 중 chapter 10. Having a dev set and metric speeds up iterations 을 번역한 내용입니다.>
'Study > AI' 카테고리의 다른 글
[MLY] 빠르게 구현하고 나서 반복하기 (0) | 2018.09.05 |
---|---|
[MLY] 개발 환경과 테스트 데이터를 설정하는 데 있어 고려해야 할 사항들 (0) | 2018.09.05 |
[MLY] 개발/테스트 데이터와 평가 지표를 바꿔야 하는 경우 (0) | 2018.09.05 |
[MLY] 최적화 지표와 만족 지표 (0) | 2018.09.02 |
[MLY] 최적화를 위해서는 단수 형태의 평가 지표를 취해라 (0) | 2018.09.02 |
[MLY] 개발 데이터와 테스트 데이터는 얼마나 많이 수집해야 할까? (0) | 2018.09.02 |
[MLY] 개발 데이터와 테스트 데이터는 같은 분포를 가지고 있어야 한다. (0) | 2018.09.02 |
- Total
- Today
- Yesterday
- 딥러닝
- Off-policy
- Kinect for windows
- windows 8
- TensorFlow Lite
- bias
- SketchFlow
- Distribution
- ColorStream
- 파이썬
- Kinect
- processing
- Offline RL
- Windows Phone 7
- PowerPoint
- RL
- 강화학습
- ai
- reward
- End-To-End
- 한빛미디어
- DepthStream
- arduino
- Variance
- Policy Gradient
- Expression Blend 4
- Gan
- Pipeline
- dynamic programming
- Kinect SDK
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |