티스토리 뷰
- 새로운 프로젝트를 시작할 때, 특히 해당 분야에 대해서 전문가가 아니라면, 뭔가 가장 확신을 줄 수 있는 방향을 올바르게 선정하기는 어렵다.
- 그렇기 때문에 시작할 때부터 완벽한 시스템을 설계하고 만들 생각을 하지마라. 대신 가장 기본적인 시스템부터 될수 있으면 빠르게 만들어라(대략 며칠동안 만들수 있는 정도?) 그리고 오류 평가를 활용해서 가장 확신을 줄수 있는 방향을 선정하고, 거기서부터 알고리즘을 반복적으로 개선할 수 있도록 해보자.
- 100여개의 잘못 분류된 데이터를 일일이 확인해보고 주요 오류가 발생하는 카테고리를 파악하는 것과 같은 방식으로 오류 평가를 수행해라. 그리고 이 정보를 활용해서 수정해야 할 오류의 종류별로 우선순위를 정하자.
- 개발 데이터를 수동적으로 확인해볼 Eyeball dev set과 확인을 전혀 하지 않는 Blackbox dev set으로 나눠보자. 만약 Eyeball dev set 상에서의 성능이 Blackbox dev set에서보다 더 좋게 나온다면, 그건 Eyeball dev set에서 overfitting되는 상황이므로, 그 문제를 해결하기 위해서 데이터를 좀 더 모아라.
- Eyeball dev set은 알고리즘이 잘못 평가한 오류들을 일일이 확인해보기에 충분할 만큼 충분히 커야 한다. Blackbox dev set은 1000~10000여개 정도가 충분하다.
- 만약 개발 데이터가 위와 같이 나누기 충분하지 않다면, 해당 개발 데이터를 모두 Eyeball dev set으로 정해서 오류 평가와 알고리즘 평가, hyperparameter 설정을 하는데 사용하라.
< 해당 포스트는 Andrew Ng의 Machine Learning Yearning 중 chapter 19. Takeaways: Basic error analysis을 번역한 내용입니다.>
'Study > AI' 카테고리의 다른 글
[MLY] 이상적인 오류율과의 비교 (0) | 2018.09.11 |
---|---|
[MLY] Bias와 Variance의 예시들 (0) | 2018.09.10 |
[MLY] Bias와 Variance: 오류를 발생시키는 두개의 요인 (0) | 2018.09.10 |
[MLY] Eyeball 데이터와 Blackbox 데이터는 얼마나 커야 할까? (0) | 2018.09.09 |
[MLY] 개발 데이터가 많은 경우, 두 집합으로 나누고 하나에서만 확인하기 (0) | 2018.09.08 |
[MLY] 개발 데이터상에 잘못 라벨링된 것 정리하기 (0) | 2018.09.08 |
[MLY] 오류 평가 간에 여러개의 아이디어를 병렬로 평가하기 (0) | 2018.09.06 |
- Total
- Today
- Yesterday
- ai
- 딥러닝
- Variance
- RL
- Offline RL
- Distribution
- Gan
- End-To-End
- Pipeline
- ColorStream
- SketchFlow
- Kinect SDK
- DepthStream
- 한빛미디어
- dynamic programming
- Off-policy
- Kinect for windows
- windows 8
- Windows Phone 7
- TensorFlow Lite
- Kinect
- bias
- 강화학습
- 파이썬
- Expression Blend 4
- arduino
- reward
- PowerPoint
- processing
- Policy Gradient
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |