ML strategy

개요

왜 ML 전략이 필요한가

머신러닝 학습 속도, 예측 정확도를 더 높이고 싶을 때 취할 수 있는 여러가지 방법이 있음

• 데이터를 더 모으든가, 학습을 더 오래시키든가, 정규화같은걸 해보든가

그러나 무작정 하면 그 방법이 시간만 잡아먹고 유효한 결과를 내지 못할 수 있음.
그래서 머신러닝 문제가 무엇인지 분석하고 적절한 방법을 찾기 위한 전략이 필요함.

Orthogonalization (직교화)

직교화는 각 기능이 독립적으로 조정될 수 있도록 설계하는 것이라고 할 수 있다.

하나의 요소가 하나의 역할만 담당하도록 하는 것 = 직교화된 요소

• 직교화된 선택지를 골라야 네트워크를 조정하기가 쉽다.
• e.g., 하나의 하이퍼 파라미터를 조절하면 하나의 효과만 일어나게 해야 좋다.

머신러닝 지도학습이 잘 작동하기 위한 순차적인 조건과 직교화된 해결책

• 훈련 세트가 비용함수에 잘 맞아야 함
  • 잘 안맞으면? : 더 큰 네트워크 만들기, Adam같은거 쓰기
• 데브 세트가 비용함수에 잘 맞아야 함
  • 잘 안맞으면? : 정규화하기. 더 큰 훈련 세트 구축하기
• 테스트 세트가 비용함수에 잘 맞아야 함
  • 잘 안맞으면? : 더 큰 데브 세트 구축하기
• 실제 서비스에서 잘 동작
  • 잘 안되면? : 데이터를 바꾸든가 비용함수를 바꾼다.

위의 해결책들이 직교화된 것들인 반면, Early Stopping은 그렇지 못하다. 훈련세트와 데브세트에 모두 영향을 미치기 때문.

Set up my goal

모델을 구축할 때, 데이터셋(특히 dev set)과 평가지표를 결정해야 한다.
결정한 두 가지를 갖고 idea-code-experiment 이터레이션을 돌린다.

강의에서 든 예시를 그대로 가져오면

• dev set과 metric을 결정하는 것 = 목표로 하는 과녁을 정의하는 것
• 같은 분포의 dev, test set을 얻는 것 = 과녁을 실제로 맞추는 것.

지표 결정 1 : Single Number Evaluation Metric

모델 평가 지표(메트릭)을 결정하는 첫 번째 방법

1개의 실수 지표를 정합시다.

고양이인가 아닌가를 구분하는 Classifier를 구축한다고 하자.
이 모델의 성능을 평가하는 합리적인 지표가 무엇이 있나 알아보자.

두 가지 수치로 평가 --> 귀찮다. 애매한 경우 생긴다.

• 프리시전과 리콜 두 가지로 평가한다고 가정하자.
• Precision : 고양이로 예측한 것 중, 진짜 고양이인 경우가 몇 퍼센트?
• Recall : 실제 고양이인 데이터 중, 몇 퍼센트나 고양이라고 예측되었는가?
• 발생하는 문제 : 둘 중 어떤것이 높은게 더 좋은가? 모른다.

단일 수치로 평가 --> 하나만 신경쓰면 돼서 좋다.

• F1 Score라는 단일 수치로 평가한다고 가정하자.
• F1 Score = ${2} / {\left(\frac{1}{P} + \frac{1}{R}\right)}$ (프리시전과 리콜의 조화평균)
• 장점 : 하나만 보면 돼서 편하다.
• 주의 : 그러나 F1 Score가 하나만 산출돼야 한다는 법칙도 없다.
  • 예를 들어 여러 특성별로 산출면 여러 개가 나올 수 있는데, 또 그것대로 단일 지표로 만들어 평가할 수 있다. (평균, 중간값 등)

결론

• 요약 : 하나의 지표로 모델을 평가하도록 하자
• 물론 여러 지표를 가지고 엄청많은 모델의 성능을 평가해서 최상의 것을 고르는게 좋다.
• 그러나 돈도 시간도 제한적인 현실을 고려해야 한다.
• 단일 지표로 평가하면 더 빠르게 비교하고 의사결정을 할 수 있다.

평가기준이 위에서 본 것밖에 없음? : ㄴㄴ 아님

• 프리시전, 리콜, F1스코어 뿐 아니라 실행시간 등 모든 것이 평가의 기준이 될 수 있다.

지표 결정 2 : Satisficing and Optimizing Metric

모델 평가 지표(메트릭)을 결정하는 두 번째 방법

가능한 좋게 만들 지표, 그리고 만족만 하면 되는 지표. 2가지를 갖고 평가합시다.

두 가지 Metric을 섞어 모델을 고를 수 있다.

• Satisficing Metric : 일정 기준만 만족하면 되는 지표
• Optimizing Metric : 가능한 최적화하려는 지표

e.g.,

• 만약 사진 분류기를 만드는데 유저가 100ms미만의 로딩시간이면 만족한다고 하면
  • Stisficing Metric으로 로딩시간을 잡는다 (로딩시간 < 100ms)
  • Optimizing Metric으로 정확도를 잡는다. (가장 높은 정확도를 내놓으시오)
• 즉, 로딩시간이 100ms미만이기만 하면 신경끄고, 이제부터는 정확도가 가장 좋은 모델을 고른다.

Train/Dev/Test Distributions

Dev set, Test set의 분포는 동일해야 한다.
그렇지 못하면 학습도 평가도 제대로 이뤄지지 못한다.
예를 들면

• 데이터에 여러 지역이 섞여있는 경우,
• Dev/Test set 두 데이터셋이 모든 지역을 같은 분포로 커버하도록 구성해야 한다.

잘못된 경우의 예를 들면

• 데이터에 여러 지역이 섞여있는데
• Dev set에는 아시아만 넣고, Test set에는 유럽만 넣는다.
• 그럼 망한다. (아시아 기준으로 하이퍼파라미터 다 조정해놓고, 유럽 기준으로 평가하는 대참사)

dev, test set 분포를 고르기 위한 가이드라인은

• 미래에 얻어질 것으로 예상되는 데이터로 결정
• 또, 좋은 성능(성과)를 낼 것으로 예상되는 데이터로 결정

Size of the Dev and Test Sets

요약 : 알아서 해라.

목적을 달성할 수 있는 정도로 데이터를 할당해라.

• 이전에 배운대로
  • dev set은 최상의 모델을 결정하는데,
  • test set은 그 모델을 평가하는데 사용.
• 각 목적을 달성할 수 있을 정도의 적절한 숫자를 알아서 정해서 쓰면 된다.

철지난 국룰

• 60/20/20%, 70/30%같은 데이터셋 분할 국룰이 존재하기는 했으나
• 요즘은 데이터 규모가 크기 때문에 꼭 저 비율을 따를 필요는 없다.
  • 데이터가 1만개 일 때, 1억개 일 때의 20%는 전혀 다른 숫자이기 때문.

소신을 지켜도 된다.

• train set에 데이터 많이 할당해도 된다. 그럼 더 폭넓고 올바르게 학습을 할 확률이 높으니까.
• 누가 1억개 test set이 있어야 된다고 주장해도, 내가 해결하려는 문제가 꼭 그러리라는 보장이 없다.
• 내가 1만개면 모델 검증에 충분하다고 결론 내렸으면, 그냥 1만개로 test set구성해도 된다.

When to Change Dev/Test Sets and Metrics?

머신러닝 프로젝트를 진행하기 위해서는 dev set, evaluation metric을 정해야 한다고 했었다.

• 아무리 고심끝에 두 가지를 결정한다 한들, 사람이 하는 일이다.
• 뒤늦게 잘못 골랐다는걸 알아버릴 수 있다.
• 그럼 바꿔야지 뭘 어떡하겠음..

평가 지표가 평가해야 하는 것

• 원론적인 이야기 : 여러 모델 중 어떤 것이 더 나은지 정확하게 평가해야 함.
• 정확도와 같은 성능이 높다고 무조건 좋은게 아니다
• 하지 말아야 할 일을 한다면, 정확도가 아무리 높아도 쓸모가 없다 (A)
  • 고양이 사진을 보여주기 위한 고양이 이진 분류기인데 불법적인 사진도 고양이로 분류한다면? (B)
  • 정확도가 아무리 높든간에 법적문제로 대표 감옥가는 수가 있다.
  • 정확도를 약간 버리고 불법적인 사진을 절대 통과시키지 않는 모델이 더 합리적이다.

• 모델	에러율	불법적인 사진도 통과시킴
  A	1%	예
  B	2%	아니요

• 이 경우의 해결 방법 : 불법적인 사진을 고양이라고 하는 경우 큰 가중치$w^{(i)}$를 준다.
  • 기존 : $\text{Error} = \frac{1}{m} \sum_{i=1}^{m} I({y_{pred}}^{(i)} \neq y^{(i)})$
    • $I$ : Indicator함수. 조건식 평가 결과 (참 거짓)
    • ${y_{pred}}^{(i)}$ : 0또는 1.
  • 해결 : $\text{Weighted Error} = \frac{1}{\sum_{i=1}^{m} w^{(i)}} \sum_{i=1}^{m} w^{(i)} I({y_{pred}}^{(i)} \neq y^{(i)})$
    • $w^{(i)}$ : i번째 example이 불법사진인 경우 큰 숫자 부여
    • e.g., i번째 example이 불법사진이 아니면 1, 불법사진이면 100
    • 나누는건 왜 가중치 합으로 나눔? : 정규화하려고.

Dev/Test set을 바꿔야 할 경우

• Dev/Test set으로 아무리 모델을 잘 만들어놨다고 해도, 실제 프로덕션 환경에서 주어지는 데이터는 다를 수 있다.
• 이 경우 Dev/Test set을 실제 프로덕선 환경에서 주어지는 데이터의 특징을 잘 반영하도록 바꿔야 한다.
• e.g., Dev/Test set은 고화질인데 실제 사용자가 던지는 데이터는 저화질인 경우.

그럼 메트릭과 데이터셋을 결정하는데 많은 시간을 들여야 할까?

• 아니요 적당히 정하고 빨리 일이나 하셈
• 그러다가 문제가 발견돼서 변경의 필요성이 느껴지면 그 때 해도 된다.
• 단, 직교화를 언제나 잘 하도록 하자.

Comparing to human-level performance

Why Human-level Performance?

최근 많은 경우에 머신러닝의 성능을 인간 수준에 비교하기 시작함. 이유는

• 딥러닝 발전으로 머신러닝이 좀 잘돌아가니까 인간수준에 도달하는 경우가 나옴
• 인간이 할 수 있는 작업을 모방하는 것을 목표로 하면 시스템 설계와 구축이 효율적.

Bayes optimal error

• x에서 y로의 매핑함수의 이론적인 최고 성능 (가능한 가장 낮은 오차)
  • 학습을 시키고 최적화를 할 수록 점점 정확도가 올라간다.
  • 처음에 비교적 빨리 오르다가, 인간수준에 도달한 이후에는 상승률이 점점 감소.
• 정확도는 100%가 될 수 없다. 베이지안 최적오류를 넘을 수 없다.
• 인간수준의 성능은 많은 경우에 베이지안 최적오류에 가깝다.
  • 인간수준을 초과하는 머신러닝 성능을 만들기가 어려운 이유.
  • (인간수준 성능을 베이지안 최적오류의 추정치로 삼을 수 있다.)

인간수준보다 낮은 성능을 보이는 모델은 어떻게 개선할 수 있나

• 데이터 라벨링
• 수동 오류 분석
• bias, variance 분석.

인간 수준의 성능이 베이지안 최적오류 언저리라는 것을 알면, 머신러닝 알고리즘을 개선하는데 필요한 전략을 세울 수 있음. (오류율 어디까지 개선할 것인가? 편향이 문제인가 분산이 문제인가?)

Avoidable Bias

머신러닝 모델의 오류율이 낮다고 해서 성능이 좋다고 단정지을 수는 없다.
인간 수준의 오류율, 즉 베이지안 최적 오류 언저리에 맞추면 된다.

어떤 문제에 대한 인간 수준의 오류율이 10%라고 가정하자

• 모델의 학습데이터에 대한 오류율이 1%라면 좋은 것일까?
  • 데브셋 오류가 50%라면 아니다.
  • note : 보통 인간수준의 오류율보다 낮은 오류의 모델은 과적합으로만 얻을 수 있다.
• 트레이닝셋 오류 10.5%, 데브셋 오류 20%인 경우는?
  • 트레이닝셋 오류가 인간수준에 근접했으니 이만하면 됐다
  • 데브셋 오류만 높은걸 보니 고분산 문제가 있다. 정규화를 해서 데브셋 오류를 낮추자.
• 트레이닝셋 오류 12%, 데브셋 오류 12.5%인 경우는?
  • 고편향이 나타난 것으로 보고 문제해결 전략을 세울 수 있다.
  • avoidable bias : 인간수준 오류율과 트레이닝셋 오류율의 차이 (여기서 2%)
  • variance : 트레이닝셋 오류와 데브셋 오류의 차이 (여기서 0.5%)

즉, 두 가지 기준으로 해결책이 무엇인지 판단해볼 수 있다.

• 인간수준의 오류율과 train/dev set 오류율은 어느정도 차이가 있는가?
• avoidable bias와 variance 중 무엇을 해결하는 것이 더 효과적인가?

정리하면 아래와 같다.

• 인간 수준의 오류율
  • 위아래의 차이 = avoidable bais
• train set의 오류율
  • 위아래의 차이 = variance
• dev set의 오류율

Understanding Human-level Performance

어떤 문제는 사람마다 보이는 오류율이 다를 수 있다. 요인의 예로는 숙련도가 있다.
이 경우 가장 낮은 오류율을 인간수준 오류율로 삼는다.

• 고숙련자가 0.5%의 오류율
• 저숙련자가 3%의 오류율
• 이 경우 고숙련자를 기준으로 인간수준 오류율을 0.5%로 결정

Surpassing Human-level Performance

만약 머신러닝의 성능이 인간 수준을 초과한다면 성능 개선의 방법을 찾기가 어려워진다.

• 인간수준 오류율이 0.5, train set 오류율 0.3, dev set 오류율 0.4라면
  • 오버피팅된 케이스라고 단정 지을 수 있는가? 그럴 확률이 있긴 하지만 알 수 없다.
  • 따라서 bias, variance를 통해 판단하던 방법을 적용하기가 어려워진다.

그러나 어쨌든 인간성능을 머신러능이 넘어서는 경우가 있다.
아래의 경우가 특히 그렇다. 넘어서는 경우는 보통 structured data가 대량으로 있는 경우다.

• 온라인 광고, 상품 추천, 물류, 대출 승인

그 외에 자연어, 컴퓨터 비전, 의료 진단 등도 인간성능을 머신러닝이 넘는 경우가 있다. 그러나 구조화된 데이터보다는 그러기가 아주 어렵다. 애초에 사람이 자연인지를 잘한다.

Improving your Model Performance

위에서 살펴본 내용들을 토대로 모델 성능을 개선할 수 있다.

학습 알고리즘의 주요한 목표

• 먼저, 모델이 train set을 잘 처리해야 한다. (avoidable bias 최소화)
• 그 다음 모델이 dev, test set도 잘 처리해야 한다. (일반화. variance 줄이기.)

avoidable bias를 줄이기 위해서는

• 더 큰 모델 사용
• 더 오래, 더 좋은 최적화 알고리즘 사용 (adam, momentum ....)
• NN아키텍쳐 변경, 하이퍼파리미터 탐색(변경)

variance를 줄이기 위해서는 (혹은 일반화를 잘 하기 위해서는)

• 더 많은 데이터 확보
• 정규화
• NN아키텍쳐 변경, 하이퍼파라미터 탐색(변경)

이 때, 언제나 직교화하면 인생이 편해질 수 있다는 점을 유념해야 한다.

Error Analysis

에러 분석 수행

사람이라면 할 법한 작업인데 모델이 못 하는 일이 있다면 사람이 수동으로 에러를 분석해볼 수 있다.

먼저 dev set에서 잘못된 결과를 낸 example들을 모아서 분석한다.

• 어떤 유형의 문제가 많은 오류(잘못된 결과)를 내는지 확인한다.
  • 많은 오류를 내는 문제를 해결한다. (그러면 같은 시간을 투자해서 가장 많은 성능향상을 기대할 수 있다.)
  • 작은 오류를 내는 유형의 문제는 우선순위가 아니다.
• 한 문제를 해결해서 얻어낼 수 있는 성과의 상한을 천장(ceiling)이라고 한다.

즉, 수동 에러분석을 통해 해야 할 일의 우선순위를 정해볼 수도 있다.

잘못 라벨링된 데이터 정리

잘못 라벨링된 데이터의 라벨을 수정할 가치가 있는지 판단하는 기준은 어떻게 되는가.

train set에 대해

• 딥러닝의 특징
  • 딥러닝은 기본적으로 random error에 둔감하다.
  • 그러나 systemical(구조적인) error에 대해서는 비교적 민감하다.
• 무작위로 발생하는 개별 오류 비율과 오라벨로 발생하는 오류의 비율을 비교해본다
  • 비슷하다면 그냥 놔둬도 된다.
  • 혹은 전체 오류비율에서 오라벨로 발생하는 오류 비율이 현저히 적다면. 역시 그냥 놔둬도 된다.
• 그러나 전체 데이터에 걸쳐 일관되게 오라벨이 발생한다면? 오라벨이 오류의 많은 부분을 차지한다면?
  • 그럼 고쳐야지..

dev, test set에 대해

• 오라벨이 전체 오류의 큰 비중을 차지한다면 고쳐야된다.
  • dev set 고쳤으면 test set도 고쳐야 된다.
• 잘못된거 고쳤으면 잘 맞춘 것도 들춰서 진짜 잘 학습돼서 맞춘건지 확인해봐야 한다.
  • 운좋게 올바른 결과를 냈을 수도 있다.
  • 물론 말만 쉽다. 98%정확도 모델에서 98%를 보는건 쉽지 않다.

dev, test set을 고쳤으면 train set도 고쳐야 하나?

• random error수준이면 그냥 놔둬도 된다. 고치려면 고치든지..
• 그러나 앞서 train set에서 본 대로 전체 데이터에 대해 라벨링을 일관되게 잘못해서 오류가 많이 나는 경우라면 고쳐보는 것을 고려할 수 있겠다.

첫 시스템 빌드는 빠르게하고 이터레이션 돌리기

처음부터 너무 복잡한 시스템을, 너무 잘 만들려고 하지 말아라.
어차피 딥러닝은 경험적으로 해야되는거라 이터레이션이나 빨리빨리 돌리는게 좋다.

1. 첫 번째 시스템은 일단 간단하고 빠르게 만들어라
2. 그 다음 개선점을 도출하고 우선순위를 설정해서 수행한다.
   1) bias variance 잡고
   2) 오류분석 해서 뭐 잡고 뭐 잡고...
3. 계속 이터레이트 하자.

이런식으로 프로젝트를 진행하는게 효율적이고, 경험이 없는 문제를 다룰 때 특히 잘 먹힌다.

Mismatched Training and Dev/Test Set

다른 분포의 데이터로 학습, 테스트 하기

이미지에 대한 이진 분류기 모델을 만들다고 하자.
데이터를 아래와 같이 얻었을 수 있다.

• 웹 크롤링 고해상도 데이터 100만장
• 유저가 제공할법한 저해상도 데이터 1만장

이 경우 모든 데이터를 섞어서 같은 분포로 1만장 크기의 dev, test set을 구성하면

• dev set : 고해상도 99만개 + 저해상도 1만개
• test set : 고해상도 99만개 + 저해상도 1만개
• 이렇게 되어버린다. 유저가 제공할법한 사진이 조금 들어가있으니 실제 프로덕션에서 제대로 작동할 확률이 그렇게 높지 않다.

그러니 좀 극단적이지만, 차라리 이렇게 하자.

• train set : 고해상도 100만장
• dev set : 저해상도 0.5만장
• test set : 저해상도 0.5만장
• 이렇게 하면 구축된 모델이 실제 서비스 환경에서 잘 돌아갈 확률이 높다.
• 단점은, train set과 dev,test set의 분포가 다르다. 귀찮은 일이 일어난다. (아래)

진짜 유저에게 제공할 서비스에 가까운 데이터를 최대한 dev, test에 넣어줘야된다.

mismathced 데이터 분포를 가진 bias와 variance

bias, variance 분석을 통해 개선방향을 찾고자 한다.
train, dev, test가 같은 분포에서 왔다면 원래 알고있던 그대로 하면 된다.

하지만 train set의 분포가 dev, test set의 분포와 다르다면?

• train set오류가 1%, dev set 오류가 10%일 때
• 이것이 high variance에 의한 것이라고 볼 수 있느냐?
• 아니요. 애초에 분포가 다른데 그걸 알 수가 없지. dev set사진이 유별날 수 있으니까.

그러니 train,dev,test set에 이어 새로운 데이터셋, 'training-dev set'을 만든다.

• train set에서 일부를 랜덤하게 가져와서 'training-dev set'이라고 한다.
• train set에서 가져왔으니 당연히 train set과 동일한 분포를 가진다.
• training-dev set에 해당하는건 학습에 쓰지 않는다.

그럼 이제 총 네 가지로 분할된 데이터 셋을 갖고 있다.

• train
• training-dev
• dev
• test

이제 variance, bias 분석을 할 수 있다.

• 인간수준의 오류율
  • 위아래의 차이 = avoidable bias
• train set의 오류율
  • 위아래의 차이 = variance
• training-dev set의 오류율
  • 위아래의 차이 = data mismatch
• dev set의 오류율
  • 위아래의 차이 = dev set에 대한 오버피팅 정도
• test set의 오류율

addressing data mismatch

데이터 불일치 자체가 잠재적인 문제가 될 수도 있다.
그렇다면 데이터 불일치를 어떻게 해결하는가. (물론 항상 먹히는 완벽한 대책은 없음)

오류분석을 해봤더니 데이터 불일치로 인한 오류율이 높은 비중을 차지하는 경우

• 가 문제가 된다.

그럼 해볼 수 있는 일은

• 수동 오류 분석
  • 분석을 한다 : train set, dev set의 차이점을 이해한다. (대체 뭐가 다른거냐?)
  • 데이터 유사성 향상 : dev,test set과 유사한 데이터 더 많이 모으기

데이터 유사성 향상을 위해 데이터를 진짜 모을 수도 있지만

• 인공 데이터 합성을 할 수도 있다. 아마 더 싸게 먹힐거다.
• 주의 : 다양한 소스를 사용하지 않으면 오버피팅 되는 수가 있다.

Learning from Multiple Tasks

Transfer Learning (전이 학습)

어떤 목적을 위해 학습된 모델을, 다른 문제에 갖다가 써먹는 것.
e.g., object detection을 배운 모델을 x-ray 진단 모델에 쓰기

앞선 문제를 A, 새로운(뒤) 문제를 B라고 하자.

방법

• A문제에 대해 네트워크 학습 : "Pre-training"이라고 함
• 네트워크에서 출력 레이어 삭제.
  • 출력 레이어로 들어가는 가중치 없애고 새로 초기화된 가중치 생성
• B를 위한 새로운 출력 노드(레이어) 생성
• B에 대한 데이터로 새롭게 학습 : "Fine-tuning"이라고 함.
  • B 데이터가 적다면 : 새로운 레이어만 학습
  • B 데이터가 많다면 : 모든 네트워크 재학습

하면 좋은 경우 :

• A에 대한 데이터가 많고 B에 대한 데이터가 적을 때
• A와 B의 입력 데이터가 유사할 때
  • e.g., 둘 다 이미지, 둘 다 오디오
• A에 대해 학습한 저수준 특징이 B학습에 도움이 될 때
  • e.g., 이미지 인식으로 얻은 가장자리 감지 능력이 x-ray진단에 도움이 되는 경우

해도 별로 안좋은 경우

• A에 대한 데이터가 B에 대한 데이터보다 적을 때
  • e.g., 허접한 이미지 인식 능력으로 하는 X-RAY 진단이 뭔 의미가 있나

Multitask Learning

한 개 신경망이 여러 작업을 수행하도록 (여러 출력을 뱉도록) 학습시키는 것.
작업의 개수가 4개라면 출력은 4차원벡터.

Loss function 정의하는 방법

• 각 작업의 예측별로 손실함수 값 구한다.
• 각각의 손실함수 값을 다 더한다 = 전체 신경망의 손실을 구한다.
• 즉, $\text{Cost} = \frac{1}{m} \sum_{i=1}^m \sum_{j=1}^4 L(y_j^{(i)}, \hat{y}_j^{(i)})$
• 문제가 되는 상황 : 만약 어떤 example에 특정 작업에 대한 레이블이 아예 없으면( $? 표시$ ) 어떡함?
  • $y^{(i)} = \begin{bmatrix} y_{\text{pedestrian}}^{(i)} \\ y_{\text{car}}^{(i)} \\ y_{\text{stop sign}}^{(i)} \\ y_{\text{traffic light}}^{(i)} \end{bmatrix}$ $= \begin{bmatrix} 0 \\ ? \\ 1 \\ ? \end{bmatrix}$
  • 그럼 있는 값 (첫 행 0, 셋째 행 1)만 더해서 손실값을 구하자.

하면 좋은 점

• 여러 작업에 저수준 특징 공유 가능
  • 각 작업별로 따로 신경망 훈련시키는 것 보다 큰 신경망을 만들 수 있음
  • 그럼 성능이 좋아질 수도
• 각 작업에 대한 데이터 양이 비슷하면, 한 작업이 학습한 내용이 다른 작업에 도움이 될 수 있음.

쓰이는 경우

• 자율주행차, CV 오브젝트 디텍션

보통은 다중작업 학습보다는 전이학습을 많이 쓴다.
특정 사례에서 다중작업 학습을 쓰고는 함.

End-to-end Deep Learning

그게뭔데

입력X를 받아 출력Y를 내는 방법은 오래도록 연구되어왔다.
예를 들어, 말하는 오디오파일 X를 받아 대본 Y를 뱉는 프로그램을 짠다고 하자

전통적인 단계별(파이프라인) 방법은

• X를 받고
• 끝내주는 알고리즘으로 feature를 뽑아서
• 음소로 나누고
• 음소를 연결해서 단어를 만들고.....
• Y를 뱉는다.

그에 반해 딥러닝을 사용하는 End-to-end 방법은

• X를 받고
• Y를 뱉는다
• 중간과정은 없다. 신경망이 알아서 한다. 단, X->Y의 충분한 학습 데이터가 있다면 말이다.

장단점을 살펴보면

	파이프라인	end-to-end
장점	데이터 적아도 잘 동작	단순한 시스템. 더 좋은 성능.
단점	각 단계가 상당한 연구를 필요로 함(feature engineering 등)	대량 데이터 필요 / 유용한 hand-design요소 배제

쓸지 말지 결정하는 방법

데이터에 따라서, 풀려고 하는 문제에 따라 다르겠다.

데이터가 적다는 것의 특이한 사례를 보면 : 카메라 얼굴인식 기능

• 입력데이터 X는 카메라에 찍힌 사람 사진이다.
  • 근데 사람은 카메라에 다양한 각도와 환경에서 얼굴을 들이민다
  • 너무 다양한 케이스가 있다.
• 그러니 X->Y로 바로 매핑하기보다는
  • X에서 얼굴부분만 잘라낸다. = $X'$
  • 그 다음 $X'$ -> Y로 매핑해준다.
• 그러니 얼굴인식의 경우는 End-to-end보다는 파이프라인식이 더 잘 동작한다.

자율주행도 마찬가지로 다단계의 파이프라인 방식이 더 잘 동작한다

그러니.
딥러닝, 파이프라인은 언제나 상호 배타적으로 선택해야 하는 것이 아니다.
복합적으로 쓰는 것이 end-to-end보다 효과적인 경우도 분명 존재한다.

둘 중 하나만 쓰는게 맞다면 그렇게 하는 것이고
섞어 써야된다면 섞는다. 파이프라인에 딥러닝이 들어갈 수도 있는거다.

• e.g., 자율주행에서 오브젝트 디텍션에 딥러닝 쓰고, 로봇공학적인 과정으로 실제 제어명령 뱉기.