[Service] ML 프로젝트 life cycle

머신러닝 프로젝트의 라이프 사이클(Flow)에 대해 알아보자. 일반적으로 현상 파악 → 목적/문제 정의(구체화) → 프로젝트 설계 → Action → 추가 원인 분석 으로 이루어진다.

1. 현상 파악

• 어떤 현상이 발견되었는가? 현재 상황을 파악한다.

2. 문제 정의

• 파악한 현상에 있는 문제를 정의하는 과정이다.
• 풀고자 하는 문제를 잘 해결하기 위해서는 문제 정의가 매우 중요하다. 풀려고 하는 문제가 명확하지 않으면 그 이후 무엇을 해야할지 결정하기 어려워지기 때문이다. 따라서 풀려고 하는 문제를 구체화 해야 한다.
• 따라서 머신러닝, AI, 데이터 사이언스, 개발 등 대부분 업무에서 항상 문제 정의가 선행되어야 한다. How 보다 Why 에 집중하자.
• 문제 정의란 본질을 파악하는 과정이다. 해결해야 하는 문제는 무엇이고 그 문제를 해결하면 무엇이 좋을까? 어떻게 해결하면 좋을까?
• 구체적인 문제 정의
  • 무엇을 해결하고 싶은지, 무엇을 알고 싶은지를 정의하기 위해 앞선 현상을 더 구체적으로 명확한 용어로 정리해본다.
  • 이를 통해 문제 상황을 구체화시킬 수 있다. 그 구체화된 문제 상황을 일으키는 원인과 해결 방안을 고민해 볼 수 있다.
  • 데이터로 할 수 있는 일을 만들어서 진행하되, 무조건 알고리즘 접근이 최상은 아니라는 방법을 제시할 수도 있어야 한다.
  • 우리는 시간의 제약을 받고 있기 때문에 간단한 방법부터 점진적인 접근이 필요하다.
  • 인지하면 좋은 내용
    • 문제를 쪼개서 파악해보자.
    • 문제의 해결 방식은 다양하다.
    • 해결 방식 중에서 데이터로 해결할 수 있는 방법을 고민해보기
    • 점진적으로 실행하기

3. 프로젝트 설계

• 문제정의 이후 아래 예시와 같은 단계를 따를 수 있다.
• Ex. 최적화 할 Metric 선택 → 데이터 수집 및 레이블 확인 → 모델 개발 → 모델 예측 결과를 토대로 Error Analysis / 잘못된 라벨에 대한 원인 분석 → 다시 모델 학습 → 더 많은 데이터 수집 → 다시 모델 학습 → 최적화 할 Metric 이 실제로 잘 동작하지 않음을 파악하고 Metric 을 수정
• 문제 정의 후, 프로젝트의 설계를 최대한 구체적으로 하는 것이 좋다.
• 문제 정의 기반 프로젝트 설계
  • 해결하려고 하는 문제 구체화
  • 머신러닝 문제 타당성 확인
  • 얼마나 흥미로운지가 아니라 제품, 회사의 비즈니스에서 어떤 가치를 줄 수 있는지 고려
  • 머신러닝 문제는 결국 데이터로부터 어떤 함수를 학습하는 것이다.
  • 필요한 데이터의 종류와 기존 모델이 있는지 살펴보기
  • 머신러닝은 모든 문제를 해결할 수 있는 마법의 도구가 아니다.
  • 머신러닝으로 해결할 수 있는 문제지만 머신러닝 솔루션이 최적이 아닐 수도 있다.
• 머신러닝이 사용되면 좋은 경우
  • 패턴. 학습할 수 있는 패턴이 있는가?
  • 목적함수. 학습을 위한 목적 함수를 만들 수 있어야 한다. 머신러닝 알고리즘은 유용한 패턴을 학습하거나 노이즈를 패턴으로 학습하는 경우도 존재한다. 지도 학습은 정답 레이블과 예측 결과의 차이로 정의할 수 있다.
  • 복잡성. 패턴이 복잡해야 한다. ex. 주소 검색(index) vs. 집 가격 예측
  • 데이터 존재 여부. 데이터가 존재하거나 수집할 수 있어야 한다. 학습할 데이터가 없으면 프로젝트 진행 전에 데이터 수집부터 진행해야 한다. 데이터가 없으면 룰베이스 알고리즘을 만든 후, 데이터 수집 계획부터 수립해야 한다.
  • 반복. 사람이 반복적으로 실행하는 경우, 반복은 자동화를 할 수 있다는 포인트다. 작업이 반복되는 것은 패턴이 있다는 것이다. 사람의 노동력을 줄일 수 있는 관점으로 접근해보자.
• 머신러닝이 사용되면 좋지 않은 경우
  • 비윤리적인 문제, 간단히 해결할 수 있는 경우, 좋은 데이터를 얻기 어려울 경우, 한번의 예측 오류가 치명적인 결과를 발생시킬 경우, 시스템이 내리는 모든 결정이 설명 가능해야 할 경우, 비용 효율적이지 않은 경우
• 목표 설정, 지표 결정
  • Goal : 프로젝트의 일반적인 목적, 큰 목적 (최종적으로 달성하고자 하는 목표)
  • Objectives : 목적을 달성하기 위한 세부 단계의 목표(구체적인 목적)
  • 목표를 설정하면서 데이터를 확인해야 한다. 이는 지표와 연결되는 내용이기 때문이다.
  • 데이터 소스를 찾아보고, 정확히 찾으려는 데이터가 없는 경우, 여러가지 시나리오 고려한다.
  • 데이터셋이 레이블링이 되지 않은 경우도 존재한다.
  • 레이블이 없을 때 self supervised learning 등을 사용해서 유사 레이블을 만드는 방법도 존재한다.
• Multiple objective optimization
  • 최적화하고 싶은 목적 함수가 여러가지 있는 경우, 서로 충돌할 수 있다.
  • loss 를 어떻게 정하고 그 loss 를 어떻게 최소화시킬 것인가 가 중요하다. 품질에 따른 게시물 랭킹 선정 vs. 참여에 따른 게시물 랭킹 선정으로 예시를 들어보자.

  • 첫번째 방법은 단일 모델을 사용하는 방법이다. 두 loss 를 하나의 loss 로 결합하고, 해당 loss 를 최소화하기 위해 모델을 학습시킨다.

    \[\text{Loss} = \alpha \; \text{quality_loss} + \beta \; \text{engagement_loss}\]
  • 이 방법은 $\alpha$ 와 $\beta$ 를 필요에 따라 조정해야 한다.
  • 두번째 방법은 2 개의 모델로 각각의 loss 를 최소화시키는 방법이다.

  • quality_loss 를 최소화하고 예상 품질을 반환하는 quality_model 과 engagement_loss 를 최소화하고 게시물의 예상 클릭 수를 반환하는 engage_model 을 만든다.

    \[\text{Rank} : \alpha \; \text{quality_model(post)} + \beta \; \text{engagement_model(post)}\]
  • objective function 이 여러 개인 경우 분리하는 것이 좋다. 하나의 objective 를 최적화하는 것이 여러 objective를 최적화하는 것보다 학습하기 쉽기 때문이다.
  • 또한 모델, objective function 을 분리하면 재학습하지 않아도 된다. 그러나 2 개 모델의 학습 시간, 학습 패턴을 고려해야 한다. objective 에 따라 수정해야 하는 유지보수 일정이 모두 다를 수 있다.
• 제약 조건 점검(Constraint & Risk)
  • 일정, 예산, 관련된 사람 등 현실에선 항상 관리해야 할 것들이 많다.
  • Privacy(개인정보 보호 요구), 기술적 제약, 윤리적 이슈
• 성능
  • Baseline : 새로 만든 모델을 무엇과 비교할 것인가
  • Threshold
  • Performance Trade-off
  • 해석 가능 여부
  • Confidence Measurement
• 지표 결정
  • 베이스라인, 프로토타입 제작
  • 모델이 더 좋아졌다고 판단할 수 있는 Baseline 필요하다. 이는 꼭 모델일 필요는 없고, Rule Base 혹은 사람이어도 괜찮다.
  • 간단한 모델부터 시작하는 이유
    • 어떻게든 모델의 위험을 낮추는 것이 목표가 되어야 한다.
    • 가장 좋은 방법은 최악의 성능을 알기 위해 허수아비 모델로 시작하는 것이다.
    • 초기엔 단순하게 사용자가 이전에 선택한 행동을 제안할 수도 있고, 추천 시스템에선 제일 많이 구매한 것을 추천할 수도 있다.
  • 유사한 문제를 해결하고 있는 SOTA 논문 파악해보기
  • 베이스라인 이후에 간단한 모델을 만들고 피드백을 들어보면 좋다.
  • 회사의 동료들에게 모델을 활용할 수 있는 환경 준비
  • 프로토타입을 만들어서 제공
    • input 을 입력하면 output 을 반환하는 웹페이지.
    • 여기서는 좋은 디자인 보다는 모델의 동작이 더 중요하다.
    • HTML 에 집중하기 보다 모델에 집중하는 것이 중요하다.
    • 이를 위해 Voila, Streamlit, Gradio 등 활용하여 프로토타입을 제작해 볼 수 있다.

    

• 평가(Evaluation) 방법 설계
  • Metric Evaluation
  • 앞에서 Objectives 를 구해서 모델의 성능 지표는 확인할 수 있다.
  • 모델의 성능지표와 별개로 비즈니스 목표에 영향을 파악하는 것도 중요하다.
  • 문제를 해결할 경우 어떤 지표가 좋아질까를 고민해야 한다. 작게는 모델의 성능지표(RMSE 등), 크게는 비즈니스의 지표(고객의 재방문율, 매출 등)일 수 있다.
  • 지표를 잘 정의하고 어떻게 평가할지를 잘 정하면 우리의 Action 이 기존보다 더 성과를 냈는지 아닌지를 파악할 수 있다. 이를 위해 AB Test 를 진행하기도 한다.
  • 머신러닝 프로젝트는 궁극적으로 수익을 높이는 것이 목표다. 전환율 증대, 반복 업무 자동화 등으로 간접적으로 기업의 이익 극대화에 영향을 미칠 수 있다.
  • 개발 및 배포, 운영 중에 시스템의 성능은 어떻게 판단할 수 있을까에 대해서는 따로 정리해보자.

4. Action

• 모델 개발 후 배포하고, 모니터링에 해당하는 단계다.
• 앞서 정의한 지표가 어떻게 변하는지 파악한다.

5. 추가 원인 분석

• 새롭게 발견한 상황을 파악해서 어떤 방식으로 문제를 해결할지 모색한다. 이 과정에서 앞서 진행한 과정을 반복한다.

비즈니스 모델

• 회사에서 중요한 것은 비즈니스다. 즉 비즈니스에 대한 이해도가 높을수록 문제 정의를 잘 할 가능성이 존재한다.
• 회사는 비즈니스 모델을 만들고, 비즈니스 모델을 통해 매출이 발생한다. 해당 비즈니스 모델에서 어떤 데이터가 존재하고 그 데이터를 기반으로 어떤 것을 만들 수 있을지를 생각해야 한다.
• 비즈니스 모델 파악하기
  • 회사의 비즈니스 파악하기
    • 누군가 산업에 대해서 정리해둔 Paper 가 있는지 찾아보기. ex. awesome mobility machine learning github
    • 해당 산업군에서 사용하는 기술, 해당 비즈니스에 어떻게 적용할 수 있을까 등의 추가 가치 발견. 머신러닝, AI 가 비즈니스에 영향을 주는 과정을 이해하면 좋다.
  • 데이터를 활용할 수 있는 부분은 어디인가? (Input)
    • 데이터가 존재한다면 어떤 데이터?
    • 데이터는 신뢰할만 한가? 데이터 정합성? 레이블링?
  • 모델을 활용한다고 하면 예측의 결과가 어떻게 활용되는가? (Output)
    • 고객에게 바로 노출?
    • 내부 인원이 수동으로 진행해야 하는 업무를 자동화할 수도 있다.

맨 위로 이동 ↑