티스토리 뷰
음성 인식 시스템을 만들고 있다고 가정해보자. 해당 시스템은 음성 파일 A를 입력으로 넣어줘서 동작하고, 각 출력 문장 S에 대한 점수(Score_A(S))를 계산한다. 예를 들어
$$ Score_{A}(S) = P(S|A)$$
를 계산할텐데, 이 값은 주어진 입력 음성이 A일 때 적절한 출력 문장으로 문장 S가 나올 확률을 나타내는 것이다. Score(S)를 계산하는 방법으로, 해당 값을 최대로 극대화할 수 있는 영어 문장 S를 찾아야 하고 수식으로는 다음과 같다.
$$Output = arg \max_{S}Score_{A}(S)$$
여기서 "argmax"는 어떻게 계산해야 할까? 만약 영어가 50000개의 단어로 구성되어 있다면, N개의 길이로 구성되어 있는 문장은 (50000)^N 정도가 된다.(약간 과장을 한거지만...) 그러면 Score(S)를 최적화할 수 있는(최대화할 수 있는) S를 찾기 위해서 뭔가 근사된 검색 알고리즘을 적용할 필요가 있다. 한가지 예로 들 수 있는 검색 알고리즘이 "beam search"라는 것인데, 검색과정동안 K개에 해당하는 최적의 후보만 뽑아준다.(이번 포스트에서는 beam search에 대해서 자세히 알 필요는 없다.) 이런 알고리즘은 Score(S)를 최대화시킬 수 있는 S를 찾지 못할 수 있다. 만약 누군가 "I love machine learning" 이라고 말한 음성 파일 A가 있다고 하자. 이 데이터에 대한 적절한 출력 대신에 음성 시스템은 "I love robots"라는 잘못된 결과를 내보였다. 이 시스템이 잘못 동작한 두가지 가능성이 있다.
1. 검색 알고리즘 문제
: (beam search와 같은) 근사 검색 알고리즘이 Score(S)를 최대화할 수 있는 S를 찾지 못했을 수 있다.
2. 목표(score function) 문제
: Score(S) = P(S|A)에 대한 추정치가 부정확할 수 있다. 다르게 표현하자면, Score(S)에 대한 선택이 "I love machine Learning"을 바르게 번역하는데 실패했다는 것을 의미한다.
어떤 것이 실패의 원인인지에 따라서, 신경써야 할 것의 우선 순위를 다르게 부여할 수 있다. 만약 #1이 문제라면, 검색 알고리즘을 개선하는데 집중해야 한다. 만약 #2가 문제라면, Score(S)를 추정하는 학습 알고리즘에 집중해야 한다.
이런 문제에 직면하면, 몇몇 개발자들은 무의식적으로 검색 알고리즘을 개선하려고 할 것이며, 그 외는 Score(S)를 학습시키기 위한 더 좋은 방법을 찾으려 노력할 것이다. 하지만 어디에 오류의 원인이 있는지 알지 못하는 한, 이런 노력들은 낭비될 수 있다. 어떤 것에 신경써야 할지를 시스템적으로 결정할 방법이 있을까?
S_out을 출력값("I love robots")라고 하고, S*를 적절한 결과("I love machine learning")이라고 해보자. 위에서 소개한 #1과 #2 중 무엇이 문제인지를 이해하기 위해서, 최적화 검증 테스트(Optimization Verification test)를 해볼 수 있다. 우선 Score(S*)와 Score(S_out)을 계산한다. 그러고 난 후에 Score(S*) > Score(S_out)인지 여부를 체크해본다. 그러면 두가지 가능성이 나올 것이다.
Case 1 : Score(S*) > Score(S_out)
: 이 경우, 학습 알고리즘은 주어진 S*에 대해서 S_out보다 높은 점수를 주는 정상적인 동작을 했다. 그럼에도 불구하고, 우리가 사용했던 근사 검색 알고리즘은 S*가 아닌 S_out을 선택했다. 이 건 지금 사용한 근사 검색 알고리즘이 Score(S)를 최대화하는 S를 선택하는데 실패했다는 것을 의미한다. 이런 경우에는 최적화 검증 테스트는 검색 알고리즘 문제에 신경써야 함을 알려주게 된다. 예를 들어 beam search의 경우 beam의 폭을 더 넓힐 수 있는 것이다.
Case 2 : Score(S*) ≤ Score(S_out)
: 이 경우, Score(.)를 구하는 것 자체가 잘못되었다는 것을 알 것이다. 다시 말해 부정확한 S_out보다 정확한 S*에 대해서 높은 점수를 주는데 실패했다는 것을 의미한다. 최적화 검증 테스테에서는 지금 목적(점수) 함수의 문제가 있다고 진단할 것이다. 그렇기에 이 때는, 다른 문장 S에 대해서 Score(S)를 학습시키거나 근사하는 방법을 개선하는데 초점을 맞춰야 한다.
위의 논의는 한가지 예제에 초점을 맞추고 있다. 실제 상황에서 최적화 검증 테스트를 적용하기 위해서는 개발 데이터에 대해서 오류를 검사해봐야 한다. 각 오류 별로 Score(S*) > Score(S_out) 여부를 확인해야 한다. (Score(S*) > Score(S_out))인 개발 데이터에 대해서는 최적화 알고리즘에 의해서 발생한 오류라고 체크할 것이다. 그렇지 않은 경우(Score(S*) ≤ Score(S_out))에는 Score(.)를 계산하는 데에서 문제가 발생할 것으로 체크할 것이다.
예를 들어 95%의 오류가 Score(.)를 산정하는데서 발생한 오류이고, 5%만이 최적화 알고리즘상에서 발생한 문제라고 인지했다고 치자. 그러면 이제 최적화 과정을 아무리 개선한다 할지라도, 실질적으로는 5% 이내의 오류만 개선시킬 수 있게 된다. 그렇기 때문에, 이때는 Score(.)를 개선하는데 초점을 맞춰야 한다.
< 해당 포스트는 Andrew Ng의 Machine Learning Yearning 중 chapter 44. The Optimization Verification test를 번역한 내용입니다.>
'Study > AI' 카테고리의 다른 글
[MLY] end-to-end 학습의 성장 (0) | 2018.10.11 |
---|---|
[MLY] 강화학습 예제 (0) | 2018.10.10 |
[MLY] 최적화 검증 테스트의 일반적인 형태 (0) | 2018.10.10 |
[MLY] 인위적 데이터 합성 (0) | 2018.10.05 |
[MLY] 데이터 불일치 해결하기 (0) | 2018.10.05 |
[MLY] Bias, Variance, Data mismatch 오류 확인하기 (0) | 2018.10.05 |
[MLY] 학습 데이터부터 개발 데이터까지 일반화하는 방법 (0) | 2018.10.03 |
- Total
- Today
- Yesterday
- processing
- PowerPoint
- TensorFlow Lite
- Expression Blend 4
- 딥러닝
- Variance
- windows 8
- 강화학습
- arduino
- 한빛미디어
- Kinect SDK
- RL
- Kinect
- ai
- Off-policy
- Gan
- 파이썬
- Policy Gradient
- Distribution
- SketchFlow
- ColorStream
- Offline RL
- bias
- reward
- dynamic programming
- Pipeline
- DepthStream
- Windows Phone 7
- Kinect for windows
- End-To-End
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |