[AI 서비스 개발 개론] 머신러닝 프로젝트 라이프 사이클

AI 서비스 개발 개론

1. 머신러닝 프로젝트 라이프 사이클

---

머신러닝 프로젝트 Flow

1) 문제 정의의 중요성

• 앞으로 겪을 일의 대부분(회사 업무, 인생에서 겪는 일 등등..)은 문제(Problem)로 정의할 수 있다.
• '문제 정의'란 특정 현상을 파악하고 -> 그 현상에 있는 문제를 정의하는 과정,
  즉 본질을 파악하는 과정이다.
• 풀려고 하는 문제가 명확하지 않으면 그 이후 무엇을 해야할 지 결정하기 어려워진다.
• 따라서 문제를 잘 풀기 위해서는 문제 정의가 매우 중요하다.
• 해결해야 하는 문제는 무엇이고, 그 문제를 해결하면 무엇이 좋을까?
  어떻게 해결하면 좋을까?를 생각하자.
• How 보다 Why에 집중하자.

2) 문제 해결 Flow

• 2-1) 현상 파악
  • 어떤 현상이 발생하고 있는가?
  • 해당일에서 어려움은 무엇인가?
  • 해당 일에서 해결하면 좋은 것은 무엇인가?
  • 추가적으로 무엇을 해볼 수 있을까?
  • 어떤 가설을 만들어 볼 수 있을까?
  • 어떤 데이터가 있을까?
  • ex) 레스토랑 매출이 감소하고 있다. 3달 연속으로 감소되고 있으며, 전체적인 손님 수가 줄고 있다.
• 2-2) 구체적인 문제 정의
  • 무엇을 해결하고 싶은가?
  • 무엇을 알고 싶은가?
  • 앞선 현상을 더 구체적으로 명확한 용어로 정리해보기
  • ex) 처음 방문하는 손님들이 심하게 줄어들고 기존 손님들도 줄고 있다. 상대적으로 처음 방문하는 손님들이 더 줄어들고 있다.
  • 여러가지로 문제 해결책을 제시할 수 있다.
    • 가게를 sns에 홍보한다. -> 마케팅 조직에서 진행하면 됨
    • 처음 방문하는 손님들이 어려움을 가지고 있을 수 있다.
      -> 어떤 어려움인지 조금 더 구체적으로 확인하기
  • 처음 방문하는 손님들을 대상으로 데이터를 확인해보고, 인터뷰를 진행한다.
  • 그 결과, 가게의 메뉴가 너무 다양하고 설명이 부족해서
    메뉴를 선정하기 어려워서 아무렇게나 선택하기에 만족도가 낮았다고 함.
  • 문제 상황 : "메뉴가 너무 다양해서 선정하기 어렵다"
  • 원인과 해결 방안 고민하기
  • 원인
    • 메뉴가 다양하다
    • 설명이 부족하다
  • 해결 방안
    • 메뉴를 줄인다 -> 비즈니스 상황에 따라 줄이기는 쉽지만 궁극적인 해결책이 아닐 수 있음
    • 설명을 늘린다 -> 당장 수정이 가능하고 음식에 대한 가이드를 줄 수 있음
  • '당장 진행할 수 있는 설명을 늘리는 방식을 선택하고, 병렬로 손님의 취향에 기반한 음식을 추천할 수 있지 않을까?'
    • 설명을 늘린다 = 룰 베이스(이런 음식을 좋아하면 이런 메뉴를 추천) => 당장의 문제 해결
    • 추천 = 알고리즘 개발 => 또 다른 문제 해결 방법이 될 수 있다.
  • key point
    • 문제를 쪼개서 보자 : 문제 정의는 결국 현상을 계속 쪼개고, 그 문제를 기반으로 어떤 어려움을 겪고 있는지를 파악
    • 문제의 해결 방식은 다양하다 : 데이터로 할 수 있는 일을 만들어서 진행하되, 무조건 알고리즘이 최선의 방법은 아니다. 간단한 방법부터 점진적으로 접근하기.(우리는 시간의 제약을 받는다)
    • 해결 방식 중에서 데이터로 해결할 수 있는 방법을 고민하기
    • 원인을 계속 파고들면, 해결 방법이 구체적으로 나올 수 있다.

3) 프로젝트 설계

• 3-1) 프로젝트 설계 개요
  • 프로젝트 설계 상상편

문제정의 -> 데이터 수집 -> 모델 개발 -> 모델 배포 -> 수익 획득!

• • 프로젝트 설계 현실편

문제 정의 -> 최적화할 Metric 설계 -> 데이터 수집, 레이블 확인
-> 모델 개발 -> 모델 예측 결과 오류 분석 -> 다시 모델 학습
-> 더 많은 데이터 수집 -> 다시 모델 학습
-> 2달전 테스트 데이터는 성능이 좋았는데
어제 데이터에서는 성능이 안좋음
-> 다시 모델 학습 -> 모델 배포
-> 최적화할 Metric이 실제로 잘 동작하지 않아 수정
-> 다시 시작..

• • 문제 정의 후, 프로젝트의 설계를 최대한 구체적으로 하는 게 좋다.
  • 문제 정의에 기반한 프로젝트 설계 과정
    • 해결하려고 하는 문제 구체화
    • 머신러닝 문제 타당성 확인
    • 목표 설정, 지표 결정
    • 제약 조건 확인
    • 베이스라인, 프로토 타입 설계
    • 평가 방법 설계
• 3-2) 머신러닝 문제 타당성 확인
  • 머신러닝 문제를 고려할 때에는 얼마나 흥미로운지가 아니라
    제품, 회사의 비즈니스에서 어떤 가치를 줄 수 있는지 고려
  • 머신러닝은 결국 데이터로부터 어떤 함수를 학습하는 것
  • 필요한 데이터 종류와 기존 모델이 있는지 살펴보기
  • 머신러닝은 마법 도구가 아니다. 머신러닝으로 문제를 풀어야 하는 이유 찾기.
    
    
  • 머신러닝이 사용되면 좋은 경우
    • 학습할 수 있는 패턴이 있는 경우
    • 학습을 위한 목적함수를 만들 수 있는 경우
    • 패턴이 복잡한 경우 (사실 룰 베이스로도 해결할 수 있는 문제면 룰베이스가 훨씬 간단할 수 있음)
    • 데이터가 존재하거나 수집할 수 있는 경우
    • 사람이 반복적으로 실행해야 하는 task일 경우
  
  
  • 머신러닝이 사용되면 좋지 않은 경우
    • 비윤리적인 문제
    • 간단히 해결할 수 있는 경우
    • 좋은 데이터를 얻기 어려운 경우
    • 한 번의 에측 오류가 치명적인 결과를 발생시키는 경우
    • 시스템이 내리는 모든 결정이 설명가능해야 할 경우
    • 비용 효율적이지 않은 경우

• 3-3) 목표 설정, 지표 결정
  • 프로젝트의 목표
    • Goal : 프로젝트의 일반적인 목적, 큰 목적
    • Objectives : 목적을 달성하기 위한 세부 단계의 목표(구체적인 목적)
    • ex ) Goal : 랭킹 시스템에서 고객의 참여를 최대화하고 싶다.
             Objectives: 컨텐츠 필터링을 통해 사용자 불쾌감 줄이기, 참여에 따른 게시물 랭킹 선정하기 
    • 목표를 설정하면서 데이터를 확인해야 함(지표와 연결됨)
      • 데이터셋이 레이블링 되지 않은 경우도 존재
      • 데이터 소스 찾아보기
      • 정확히 찾는 데이터가 없는 경우에는 여러 시나리오를 고려해야 함
        • Label이 있는 데이터가 존재 -> 바로 사용
        • 유사 Label이 있는 경우 -> 유사 label의 타당성 확인 후 사용
        • Label이 없는 경우 -> 직접 레이블링 / 레이블 없이 학습할 방법 찾기
        • 데이터가 아예 없는 경우 -> 데이터 수집 방법부터 고민, 데이터 셋을 만드는 일은 반복적인 작업이므로 self-supervised learning을 이용해 유사 레이블을 만드는 방법도 존재
      • Multiple Objective Optimization
        • 최적화하고 싶은 목적함수가 여러 개 있는 경우, 서로 충돌할 수 있음
        • ex) 품질에 따른 게시물 랭킹 선정 vs 참여에 따른 게시물 랭킹 선정
          -> 게시물이 매우 매력적이지만 품질이 의심스러울 땐 어떻게 해야 할까?
        • 방법 1
          • 단일 모델
          • 두 loss를 하나의 loss로 결합하고, 해당 loss를 최소화하기 위해 알파와 베타를 필요에 따라 조정해야 함
          • loss=α∗quality_loss+β∗engagement_loss
          • 알파와 베타를 조정할 때마다 모델을 다시 학습시켜야 함
        • 방법 2
          • 2개의 모델 사용
          • 각각의 loss를 최소화
          • quality_loss를 최소화하고 예상 품질을 반환하는 quality_mdoel
          • engagement_loss를 최소화하고 예상 클릭수를 반환하는 engage_model
          • Rank = α∗quality_model(post) + β∗engage_model(post)
          • 방법2의 경우 모델을 재학습하지 않아도 알파 베타를 조정할 수 있음
        • Objective가 여러 개인 경우 분리하는 것이 좋다.
          • 이 때, 학습하기 쉽게 분리해야 한다
          • 하나의 objective를 최적화하는 것이 여러 objectives를 최적화하는 것보다 쉽다
          • 모델을 재학습하지 않도록 모델을 분리한다.
          • 특히 Objectives는 수정해야 하는 유지보수 일정이 모두 다를 수 있기 때문에 objective 별로 모델을 분리하는 것을 추천

• 3-4) 제약 조건 고려하기
  • 일정: 프로젝트에 사용할 수 있는 시간
  • 예산: 사용할 수 있는 최대 예산
  • 관련된 사람: 이 프로젝트로 인해 영향을 받는 사람들
  • Privacy : storage, 외부 솔루션, 클라우드 서비스 등에 대한 개인정보 보호
  • 기술적 제약 : 기존에 운영하고 있던 환경
  • 윤리적 이슈 : 윤리적으로 어긋난 결과가 나오는 지 검토해야 함
  • 성능
    • Baseline : 새로 만든 모델을 무엇과 비교할 것인지 (ex. 기존에 사람이 진행하던 성능 / 간단한 회귀 등)
    • Threshold : 확률값이 0.5이상일 경우 강아지라고 할 것인지, 0.7 이상일 경우 강아지라고 할 것인지
    • Performance Trade-off : 속도가 빠른데 정확도가 0.93 vs 속도가 느린데 정확도가 0.99
    • 해석 가능 여부 : 결과가 왜 발생했는지 해석이 필요할까? 해석이 필요한 사람은 누구인가?
    • Confidence Measurement: False Negative가 있어도 괜찮은지? 오탐이 있으면 안되는지?

• 3-5) 베이스라인 프로토 타입
  • 모델이 더 좋아졌다고 판단할 수 있는 베이스라인이 필요
    • 꼭 모델일 필요는 없음
    • 자신이 모델이라 생각하고 어떻게 분류할 지 rule base 규칙 설계
  • 간단한 모델부터 시작하는 이유
    • 어떻게든 모델의 위험을 낮추는 것이 목표가 되어야 함
    • 가장 좋은 방법은 최악의 성능을 알기 위해 허수아비 모델로 시작하는 것
    • 초기에는 단순하게 사용자가 이전에 선택한 행동을 제안할수도 있고, 추천 시스템에서는 제일 많이 구매한 것을 추천할 수도 있음
  • 유사한 문제를 해결하고 있는 SOTA 논문 찾아보기 => 우리의 문제에서는 어떻게 시도해볼 수 있을까?
  • 베이스라인 이후에 간단한 모델을 만들면 피드백을 들어보기
    • 회사 동료들에게 모델을 활용할 수 있는 환경 준비
  • 프로토 타입을 만들어서 제공하기
    • Input을 입력하면 Output을 반환하는 웹페이지
    • 이왕이면 좋은 디자인을 가지면 좋지만, 여기선 모델의 동작이 더 중요
    • HTML에 집중하는 것보다, 모델에 집중하기
    • Volia, Streamlit, Gradio 등의 툴을 활용할 수 있음
• 3-6) Metric Evaluation
  • 앞의 objectives를 통해 모델의 성능 지표는 확인함
  • 모델의 성능 지표와 별개로 비즈니스 목표에 영향을 파악하는 것도 중요
  • 문제를 해결할 경우 어떤 지표가 좋아질까를 고민해야 함
    -> 이 지표는 작게는 모델의 성능 지표가 될 수도 있고,
    크게는 비즈니스의 지표일 수 있음(고객의 재방문율, 매출)
  • 지표를 잘 정의해야 우리의 action이 기존보다 어떤 성과를 냈는지 아닌지를 파악할 수 있음(이를 위해 AB Test를 진행하기도 함)
    
    
  • 대부분의 기업 : 이익 극대화를 목표
  • 따라서 머신러닝 프로젝트는 궁극적으로 수익을 높이는 것이 목표이다.
  • 꼭 직접적이지 않더라도 간접적으로도 이익 극대화에 영향을 줄 수 있음
    • 전환율 증대 => 매출 증대
    • 반복 업무 자동화 => 비용 절감
    • 간접적으로 더 높은 고객 만족도 창출, 사이트에서 머무르는 시간 증가
    • 개인화된 솔루션 제공
  • 생각해야 할 것
    • 개발 및 배포 중에 시스템의 성능은 어떻게 판단할 수 있을까?
    • 정답 레이블이 필요한 경우 사용자 반응에서 어떻게 레이블을 추론할 수 있을까?
    • 모델 성능을 비즈니스 Goal과 Objectives와 어떻게 연결할 수 있을까?

 

4) 모델 개발 후 배포, 모니터링

• 앞서 정의한 지표가 어떻게 변하는지 파악하기
  • 현재 만든 모델이 어떤 결과를 내고 있는가?
  • 잘못 예측하고 있다면 어떤 부분이 문제일까?
  • 어떤 부분을 기반으로 예측하고 있을까?
  • Feature의 어떤 값을 사용할 때 특히 잘못 예측하고 있는가?

 

5) 추가 원인 분석

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

---

비즈니스 모델 파악하기

1) 비즈니스 모델의 중요성

• 결국 회사에서 중요한 것은 비즈니스이므로, 비즈니스에 대한 이해도가 높을수록 문제 정의를 잘 할 가능성이 높다.
• 회사는 비즈니스 모델을 만들고, 비즈니스 모델을 통해 매출이 발생한다.
• 따라서 회사의 비즈니스 모델에서 어떤 데이터가 존재하고 그 데이터를 기반으로 어떤 것을 만들어낼 수 있을지 생각하기

2) 비즈니스 모델

• 회사가 어떤 서비스, 가치를 고객에게 제공하고 있는가?
• 보통 기업의 홈페이지에 있는 제품 라인업을 참고하면 회사가 제공하는 서비스를 파악할 수 있음

3) 예시 - Uber

• Uber가 제공하는 서비스 : 차량 서비스, Uber Eats, 수익 올리기, 도시 발전 촉진, 기업 대상 서비스
• Uber의 비즈니스 모델의 핵심 : 수요와 공급을 매칭시켜 손님과 드라이버가 만날 수 있는 플랫폼 역할
• 비즈니스 모델을 분석하면 문제가 보일 수 있다!
  • 문제 1: 많은 드라이버가 결국 비즈니스 플라이휠의 시작이다. -> 어떻게 드라이버들을 유입할 수 있을까? -> 드라이버가 많은 수익을 올릴 수 있게 하자 -> 수요보다 공급이 적어지는 시기에는 그 시기에 일하는 드라이버가 더 많은 수익을 얻게 하자 -> Dynamic Pricing
  • 문제 2: 라이더가 드라이버를 호출했을 때 대기 시간을 줄여야 한다 -> 어떤 차량을 어떤 고객에게 배정해야 드라이버의 시간 당 수익이 증가하고 라이더는 덜 기다릴까? -> 라이더에 가장 가까이 있는 드라이버 배정 알고리즘
  • 문제 3 : Uber Eats에서 고객이 음식을 주문하는 데 고민하거나 음식을 검색하는 시간이 오래 걸린다. -> 고객에게 각자 취향에 맞게 음식을 추천해줘야겠다. -> 음식 추천 시스템 개발 (graphic learning)

4) 비즈니스 모델 파악 팁

• 기업 엔지니어링 블로그에서 간접적으로 파악할 수 있다.
  • ex) Uber Engineering blog
• 누군가 관련 산업에 대해 정리해둔 논문이 있는지 찾아보기
• 질문하기
  • 회사 비즈니스 파악
    • 회사가 어떤 서비스, 가치를 제공하고 있는가
  • 데이터를 활용할 수 있는 부분은 어디인가?(Input)
    • 데이터가 존재한다면 어떤 데이터가 존재하는가?
    • 데이터로 무엇을 할 수 있을까?
    • 해당 데이터는 신뢰할만 한가? 데이터 정합성은 맞는가? 레이블이 잘 되어 있는가? 계속 받을 수 있는가?
  • 무엇을 해 볼 수 있는가?
    • 왜 해야 하는가?
  • 모델을 활용한다고 하면 예측의 결과가 어떻게 활용되는가?(Output)
    • 고객에게 바로 노출(ex. 추천, 얼굴 필터)되어 더 좋은 가치를 제공해서 매출을 증대하는가?
    • 내부 인원이 수동으로 진행해야 하는 업무를 자동화하여 효율성을 높이는가?
• 다양한 팀에 있는 분들과 직접 인터뷰를 하는 것도 좋은 방법이다.

---

 

회고

학부를 다니면서 교내 창업 지원 단체에서 활동하며 비즈니스 모델에 대해 많이 공부했고, 학생들을 대상으로 비즈니스 모델 설계 강의도 했었다.

또한 교내에서 창업도 여러 차례 시도했기 때문에 비즈니스 설계에 대해 최소한 이론적으로는 자신이 있었는데, 개발자를 하게 되면 과연 이런 것들이 필요할까라는 생각을 하곤 했었다.

하지만 오늘 수업을 들으면서 '비즈니스 모델의 이해'가 프로젝트 문제 정의의 시작임을 다시금 깨닫게 되었다. 어찌보면 프로젝트도 현재의 문제 상황을 개선하기 위해 진행하는 것이기 때문에 비즈니스 모델과 연결되는 게 당연한 것인데, 깨닫지 못하고 있었다.

내가 경험한 모든 것들은 정말 쓸모가 있다. 배울 수 있는 한 많은 것을 배우고 경험할 수 있는 한 많은 것을 경험하자.