[Full Stack Deep Learning] Lecture 5 - ML Projects

Lecture 5 | ML Projects

Full Stack Deep Learning 5강을 듣고 정리한 글입니다. 영어 강의라서 해석이 모호한 부분은 강의 내용을 영어 그대로 인용했습니다. 5강에서는 머신러닝 프로젝트를 하기 위한 필요한 모든 것에 대해 다룹니다.

1. Why do ML projects fail?

AI 프로젝트의 85%는 실패한다. ML 프로젝트는 대부분 “RESEARCH” 프로젝트이기 때문에 100%의 성공률을 목표로 해서는 안된다. ML 프로젝트는 실패하기 쉬운데, 이유는 다음과 같다.

• Many ML projects are technically infeasible or poorly scoped. 기술적으로 불가능하다.
• Many ML projects never leap production, thus getting stuck at the prototype phase. production을 뛰어넘지 못하며, 프로토타입 단계에서 정체된다.
• Many ML projects have unclear success criteria because of a lack of understanding of the value proposition. value proposition에 대한 이해 부족으로 명확한 성공 기준을 가지고 있지 않다.
• Many ML projects are poorly managed because of a lack of interest from leadership.

 

ML 프로젝트의 개요는 다음과 같다.

• Lifecycle
• Prioritizing projects
• Archetypes(원형)
• Metrics
• Baselines

2. Lifecycle of ML projects

ML 프로젝트를 구성하고 있는 모든 것들을 이해하는 것은 중요하다. 일반적으로 다음 4 단계로 구성된다.

 

1. Planning and Project Setup

We want to decide the problem to work on, determine the requirements and goals, figure out how to allocate resources properly, consider the ethical implications.

 

문제를 정의하고, 요구사항과 목표를 결정한다. 자원을 적절하게 할당하는 방법을 찾고, 윤리적 함의들을 고려한다.

 

2. Data Collection and Labeling

We want to collect training data and potentially annotate them with ground truth. We may find that it’s too hard to get the data, or it might be easier to label for a different task. If that’s the case, go back to phase 1.

 

훈련 데이터들을 수집하고, 정답 라벨을 만든다.

 

3. Model Training and Model Debugging

We want to implement baseline models quickly, find and reproduce state-of-the-art methods for the problem domain, debug our implementation, and improve the model performance for specific tasks.

 

Baseline 모델을 신속하게 구현하고, 해당 도메인의 SOTA 방법을 찾아내고 재현한다. 구현을 디버깅하고, 모델 성능을 향상시킨다. 모델 성능을 비교하기 위해서는 기준이 되는 모델이 필요하다. 이때 모델 성능의 기준이 되는 모델을 Baseline model이라고 한다.

 

We may realize that we need to collect more data or that labeling is unreliable (thus, go back to phase 2). Or we may recognize that the task is too challenging and there is a tradeoff between project requirements (thus, go back to phase 1)

 

4. Model Deploying and Model Testing

We want to pilot the model in a constrained environment (i.e., in the lab), write tests to prevent regressions, and roll the model into production. We may see that the model doesn’t work well in the lab, so we want to keep improving the model’s accuracy (thus, go back to phase 3).

 

모델을 테스트하고 모델의 정확도를 향상시킨다.

Or we may want to fix the mismatch between training data and production data by collecting more data and mining hard cases (thus go back to phase 2).

Or we may find out that the metric picked doesn’t actually drive downstream user behavior, and/or performance in the real world isn’t great. In such situations, we want to revisit the projects’ metrics and requirements (thus, go back to phase 1).

 

 

위에서 살펴본 프로젝트마다 수행하는 4단계 말고도 ML 프로젝트에서 해결해야 하는 두 가지가 있다. (1) 팀 구축 및 인력 채용, (2) ML 시스템을 규모에 맞게 구축하기 위한 인프라 및 툴링을 설정하는 것이다.

3. Prioritizing Projects

실현가능성과 프로젝트의 impact를 평가하여 우선순위를 설정한다. 작업할 프로젝트에 대해 우선순위를 매기려면 impact가 큰 문제들을 찾아서 potential cost는 평가해야 한다. 아래 그림은 impact가 높고 실현 가능성이 높은 프로젝트를 high priority로 설정하는 일반적인 틀을 보여준다.

 

1) Key points for prioritizing projects

High-impact ML projects

 

ML 프로젝트의 cost(비용)은 Data availability에 따라서 달라진다. 또한 정확한 요구사항과 문제의 본질적인 어려움을 고려해야 한다.

2) High Impact - mental models for high-impact ML projects

1. Where can you take advantage of cheap prediction?
2. Where is there friction in your product?
3. Where can you automate complicated manual processes?
4. What are other people doing?

3) Cheap Prediction - What does ML make economically feasible?

AI가 예측 비용을 줄이고 예측이 의사 결정의 중심이기 때문에, 저렴한 예측은 비즈니스 영역 전체에서 보편적인 문제가 된다. 따라서 저렴한 예측이 비즈니스에 큰 영향을 미치는 프로젝트를 찾아야 한다.

• AI reduces cost of prediction
• Prediction is central for decision making
• Cheap prediction means
• Prediction will be everywhere
  Even in problems where it was too expensive before (e.g., for most people, hiring a driver)
• Implication: Look for projects where cheap prediction will have a huge business impact

4) Product Needs - What does your product need?

Spotify Design team emphasizes the importance of building ML from a product perspective and looking for parts of the product experience with high friction. Automating those parts is exactly where there is a lot of impact for ML to make your business better.

Spotify 디자인 팀은 제품 관점에서 high friction(높은 마찰력)으로 product experience의 일부를 찾는 것의 중요성을 강조한다.

5) ML Strength - What is ML good at?

Andrej Karpathy의 유명한 포스트 “Software 2.0,”에 Software1.0과 Software2.0을 비교하는 내용이 나온다. Software 2.0 프로그래머는 최적화를 통해 컴파일되는 데이터셋을 이용하고, 이는 더 잘 작동하고, 더 일반적이며, 계산 비용도 덜 든다. 따라서 규칙을 직접 프로그래밍하는 대신 이를 학습할 수 있는 복잡한 규칙 기반 소프트웨어를 찾아야 한다.

• Software 1.0 = traditional programs with explicit instructions (python / c++ / etc)
• Software 2.0 = humans specify goals, and algorithm searches for a program that works
• 2.0 programmers work with datasets, which get compiled via optimization
• Why? Works better, more general, computational advantages
• Implication: look for complicated rule-based software where we can learn the rules instead of programming them

6) Inspiration From Others - What are other people doing?

새로운 것을 창조하는 대신, 다른 회사들이 무엇을 하고 있는지 볼 수 있다. 특히 대형 회사들의 논문이나 earlier-stage 회사들의 블로그 게시물을 확인하면 좋다.

7) High Feasibility - Assessing feasibility of ML projects

ML 프로젝트에서 주요 Cost driver는 다음 3가지가 있다.

• Data availability
• Accuracy requirement
• Problem difficulty - What’s still hard in machine learning?
  일반적으로 비지도 학습과(unsupervised learning) 강화 학습(reinforcement learning)은 여전히 어렵다.

4. Archetypes

앞에서 ML 프로젝트의 lifecycle과 프로젝트의 impact에 대해 알아보았다. 궁극적으로 우리는 이러한 ML 프로젝트나 응용 프로그램이 유용하기를 바란다. ML을 product에 적용할 수 있는 방법을 생각할 때, ML product의 원형과 반복적인 패턴이 있다는 점을 알고 있는 것은 도움이 된다. 이것을 “metal models”라고 하고, 이는 프로젝트를 평가하고, 필요한 자원들의 우선순위를 정하는 데 사용될 수 있다. ML 프로젝트의 공통적인 원형으로 다음 세 가지가 있다.

• Software 2.0
• Human-in-the-loop
• Autonomous systems

 

1) Software 2.0

이전에 Karpathy 포스트에서 언급 되었던 소프트웨어 2.0은 "확률론적 접근 방식인 머신 러닝으로 기존의 규칙 기반 또는 결정론적 소프트웨어를 보강하는 것(augmenting existing rules-based or deterministic software with machine learning, a probabilistic approach)"으로 정의된다. 예를 들어 IDE에서 코드 완성자를 선택하고 ML 구성 요소를 추가하여 사용자 경험을 개선하는 것이다. 프로그래머가 작성한 선행 문자만을 기반으로 하는 명령을 제안하는 대신 프로그래머가 작성한 이전 명령을 기반으로 하는 명령을 제안하는 모델을 추가할 수 있다.

 

소프트웨어 2.0 프로젝트를 구축할 때 data flywheel의 개념을 적극적으로 고려하면 좋다. 특정 ML 프로젝트의 경우 모델을 개선하면 제품이 향상되고 더 많은 사용자가 제품에 참여하게 되어 모델이 훨씬 더 향상될 수 있도록 더 많은 데이터를 생성할 수 있다. 그것은 classic한 선순환이며 ML 프로젝트의 gold standard라고 한다.

 

2) Human-in-the-loop (HIL)

HIL 시스템은 실제 세계에서 실행되기 전에 모델에 대한 출력이 사람에 의해 review 되는 기계 학습 시스템으로 정의된다.

3) Autonomous systems

자율 시스템은 시스템 자체가 결정을 내리거나 사람이 거의 review 과정에 참여하지 않는 머신 러닝 시스템으로 정의된다.

Archetypes와 Project Priority

5. Metrics

1) Choosing a metric

실제 생산 환경에서, 성능의 여러 척도(정확도, 속도, 비용 등)를 신경 쓴다. 문제는 모든 가능한 평가 방법을 ML 시스템이 single number를 최적화하는 데 가장 잘 작동하는 현실과 조화시키는 것이다. ML 제품을 만들 때 이러한 요구의 균형을 맞추기 위해 먼저 정밀도, 정확도, 리콜 등과 같은 single metric을 선택한다. 그 다음 신경 써야 하는 metric들을 합치는 공식을 만들 수 있다. 모델이나 제품의 요구 사항이 변경될 때 이 공식을 업데이트 해야 한다.

2) Combining metrics

metric을 합치는 방법으로 averaging과 thresholding이 있다.

 

평균화(averaging)는 덜 일반적이지만, 쉽고 직관적이다. 모델의 metric의 단순 평균 또는 가중 평균을 취해 가장 높은 평균을 선택할 수 있다.

 

분계점 평가(threshold evaluation)는 좀 더 현실적인 방법이다. n개의 평가 메트릭 중 n-1개의 임계값을 설정하고 n번째 메트릭을 최적화한다. 임계값을 설정할 메트릭과 임계값을 설정할 대상을 선택할 때는 도메인별 요구 사항 및 메트릭의 실제 값(얼마나 좋은/나쁜지)을 고려해야 한다.

6. Baselines

유용한 baselines을 정의하는데 외부 기준선(다른 사용자가 정의한 기준선)과 직접 정의할 수 있는 내부 기준선이 있다. 특히 내부 기준선을 사용하면 너무 복잡한 것이나 ML을 사용할 필요가 없다. 데이터셋 전체의 평균화와 같은 간단한 테스트를 통해 모델이 의미 있는 성능을 달성하고 있는지 파악할 수 있다. 이러한 기준선을 만들 때 기준선의 품질과 데이터 수집의 용이성 사이는 대개 반비례 관계가 있다.