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

정현호·2022년 11월 8일
0

AI 서비스 개발

목록 보기
2/2

1. 머신러닝 프로젝트 Flow

문제 정의와 중요성

  • 앞으로 겪을 일은 대부분 문제(problem)으로 정의할 수 있다.
  • 문제 정의 : 특정 현상을 파악하고, 그 현상에 있는 문제(Problem)을 정의하는 과정 본질을 파악하고 정의한뒤 해결하기위한 방법을 고민하는 것.
  • 문제 정의를 잘 풀기위해선 문제 정의(Problem Definition)이 매우 중요하다.

머시러닝 알고리즘, 개발 능력도 중요하나 근본적인 사고능력도 중요하다.

문제를 충분히 정의하고 고민하는 습관을 만드는 것이 중요함

머신러닝, AI, 데이터 사이언스, 개발 등 대부분 업무에서 항상 문제 정의가 선행되어야함.

How보다 Why에 집중

문제 해결 Flow

  1. 현상 파악
  2. 목적,문제 정의
  3. 프로젝트 설계
  4. Action
  5. 추가 원신 분석

1-1. 현상 파악

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

  • 어떤 일이 발생하고 있는가?
  • 해당 일에서 어려움은 무엇인가?
  • 해당 일에서 해결하면 좋은 것은 무엇인가?
  • 추가적으로 무엇을 해볼 수 있을까?
  • 어떤 가설을 만들어 볼 수 있을까?
  • 어떤 데이터가 있을까?

1-2. 구체적인 문제 정의

  • 무엇을 해결하고 싶은가?
  • 무엇을 알고 싶은가?

앞선 현상을 더 구체적으로 명확한 용어로 정리하기

앞선 현상에서 더욱 데이터를 확인해보니 다음과 같은 내용을 알 수 있었음

처음방문하는 손님들이 심하게 줄고 들고 기존 손님들도 줄고 있다. 상대적으로 처음 방문하는 손님들이 더 줄어들고 있다.

여러가지로 문제를 해결할 수 있음.

  • 가게를 SNS 등에 홍보 ⇒ 마케팅 조직에서 진행
  • 처음 방문하는 손님들이 어려움을 가지고 있을 수 있음 ⇒ 어떤 어려움인지 더 구체적으로 확인해보기

첫 방문들의 손님에게는 너무 다양한 메뉴들이 존재했고 설명해 부족해 아무렇게나 고른 메뉴가 만족도가 낮았다.

문제 상황 : 메뉴가 너무 다양해서 선정하기 어렵다.

원인 : 메뉴가 다양하다, 설명이 부족하다.

해결방안

  • 메뉴가 다양하다 → 비즈니스 상황에 따라 일시적으로 줄일 수 있지만 궁극적인 해결방안일지는 미지수
  • 설명을 늘린다 → 당장 수정 가능한 요소. 손님에게 가이드 제공 가능.

당장 진행할 수 있는 설명을 늘리는 방식을 사용하고, 병렬로 손님의 취향에 기반한 음식을 추천할 수 있지 않을까?

설명을 늘리는 방식 = 룰 베이스(만약 이런 음식을 좋아한다면 이런 음식도 추천드려요) ⇒ 당장의 문제 해결 추천 = 알고리즘 개발 ⇒ 문제 해결의 또 다른 방법

문제 정의는 결국 현상을 계속 쪼개고 그 문제를 기반으로 어떤 어려움을 겪고 있는지 파악

데이터로 할 수 있는 일을 만들어서 진행하되, 무조건 알고리즘 접근이 최상은 아니라는 방법을 제시할 수도 있어야함(간단한 방법부터 점진적인 접근) 우리는 시간의 제약을 받고 있기 때문이다.

인지해야할 내용

  • 문제를 쪼개서 파악하기
  • 문제 해결방식을 다양하다
  • 해결 방식중 데이터로 해결할 수 있는 방법을 고민해보기
  • 점진적으로 실행

1-3. 프로젝트 설계

문제 정의후, 프로젝트 설계를 최대한 구체적으로 하지 않으면 처음으로 돌아가서 다시 해야할 수도 있다.

1. 해결하려고 하는 문제 구체화

2. 머신러닝 문제 타당성 확인

머신러닝 문제를 고려할 때는 얼마나 흥미로운지가 아니라 제품, 회사의 비즈니스에서 어떤 가치를 줄 수 있는지 고려해야 함

  • 머신러닝 문제는 결국 데이터로부터 어떤 함수를 학습하는 것
  • 머신러닝 문제 타당성 평가하기 : 복잡도를 평가하는 방법은 필요한 데이터의 종류와 기존 모델이 있는지 살펴보기 SOTA에서 비슷한 모델 검색해보기 → 없을 경우 훌륭한 insight거나 존재 가치가 없는 것이다.
  • 머신러닝은 모든 문제를 해결할 수 있는 마법의 도구가 아님
  • 머신러닝으로 해결할 수 있는 문제지만 머신러닝 솔루션이 최적이 아닐 수도 있음

머신러닝이 사용되면 좋은 경우

패턴 : 학습할 수 있는 패턴이 있는가?

생성되는 방식에 패턴이 없다면 학습할 수 없음 ( ex : 복권 )

주식 가격에서 가격이 완전히 무작위라고 믿으면 모델을 만드는 게 불필요. 데이터를 탐색해서 패턴을 발견하면 진행

목적함수 : 학습을 위한 목적 함수를 만들 수 있어야 함

머신러닝 알고리즘은 유용한 패턴을 학습하거나 노이즈를 패턴으로 학습하는 경우도 존재

지도 학습은 정답 레이블과 예측 결과의 차이로 정의할 수 있음

복잡성 : 패턴이 복잡해야 함

주소 검색 문제 → 우편 번호에 기반해서 정렬되어 있으면 머신러닝이 필요하지 않음

집 가격을 예측할 경우 복잡한 패턴이 필요할 수 있음 : 동네의 평균 가격, 공원 유무, 침실 수, 건축 연식, 학교 수, 자연 재해 등

데이터 존재 여부 : 데이터가 존재하거나 수집할 수 있어야 함

학습할 데이터가 없으면 프로젝트 진행 전에 데이터 수집부터 진행해야 함

데이터가 없다면 룰베이스 알고리즘을 만든 후, 데이터 수집 계획부터 수립

반복 : 사람이 반복적으로 실행하는 경우

사람은 반복에 능숙함. 아이에게 고양이 사진을 보여주고 고양이를 알아보게 할 수 있음

작업이 반복 ⇒ 패턴

사람의 노동력을 줄일 수 있는 관점

머신러닝이 사용되면 좋지 않은 경우

  • 비윤리적인 문제
  • 간단히 해결할 수 있는 경우
  • 좋은 데이터를 얻기 어려운 경우
  • 한번의 예측 오류가 치명적인 결과를 발생할 경우
  • 시스템이 내리는 모든 결정이 설명 가능해야 할 경우
  • 비용 효율적이지 않은 경우

3. 목표 설정, 지표 결정

프로젝트의 목표
Goal : 프로젝트의 일반적인 목적, 큰 목적
Objectives : 목적을 달성하기 위하 세부 단계의 목표

4. 제약 조건(Constraint & Risk)

- 일정 : 프로젝트에 사용할 수 있는 시간
- 예산 : 사용할 수 있는 최대 예산은?
- 관련된 사람 : 이 프로젝트로 인해 영향을 받는 사람은?
- Privacy : Storage, 외부 솔루션, 클라우드 서비스 등에 대한 개인정보 보호 요구
- 기술적 제약
    
    기존에 운영하고 있던 환경 : 레거시 환경(인프라)가 머신러닝 적용할 때 큰 제약일 수 있음
    
- 윤리적 이슈 : 윤리적으로 어긋난 결과

성능

  • Baseline : 새로 만든 모델을 무엇과 비교할 것인가? 기존에 사람이 진행하던 성능 or 간단한 회귀
  • Threshold: 확률값이 0.5 이상일 경우 강아지? 0.7이상일 경우 강아지?
  • Performance Trade-off : 속도가 빠른데 정확도 Acc 0.91 속도가 느린데 Acc 0.93 중 어떤 것을 사용해야하는가?
  • 해석 가능 여부 : 결과가 왜 발생했는지 해석이 필요할까? 해석이 필요한 사람은?
  • Confidence Measurement : False Negative가 있어도 괜찮은지? 오탐은 있으면 안되는지?

5. 베이스라인, 프로토타입

모델이 좋아졌다고 판단할 수 있는 Baseline이 필요

- 꼭 모델일 필요는 없음
- 자신이 모델이라 생각하고 어떻게 분류할지 Rule Base 규칙 설계

간단한 모델부터 시작하는 이유

  • 어떻게든 모델의 위험을 낮추는 것이 목표가 되어야 함
  • 가장 좋은 방법은 최악의 성능을 알기 위해 허수아비 모델로 시작하는 것
  • 초기엔 단순하게 사용자가 이전에 선택한 행동을 제안할 수도 잇고 추천 시스템에선 제일 많이 구매한 것을 추천할 수도 있음

유사한 문제를 해결하고 있는 SOTA 논문 파악해보기 ⇒ 우리의 문제에선 어떤 시도를 해볼 수 있을까?

베이스라인 이후에 간단한 모델을 만들어 피드백을 들어보면 좋음
회사의 동료들에게 모델을 활용할 수 있는 환경 준비
프로토타입을 만들어서 제공
Input을 입력하면 Output을 반환하는 웹페이지
이욍이면 좋은 디자인을 가지면 좋지만, 여기선 모델의 동작이 더 중요
HTML에 집중하는 것보다, 모델에 집중하는 게 중요
이를 위해 Voila, Streamlit, Gradio 등을 활용

6. 평가(Evaluation) 방법 설계

  • 앞에서 Objectives를 구해서 모델의 성능 지표를 확인한다.
  • 모델의 성능 지표와 별개로 비즈니스 목표에 영향또한 파악해야 한다.

작게는 모델의 성능 지표(RMSE)일 수 있고, 크게는 비즈니스의 지표(고객의 재방문율, 매출 등) 등.

지표를 잘 정의해야 우리의 Action이 기존보다 더 성과를 냈는지 파악할 수 있다.

( 이를 위해 AB Test를 진행하기도 함 )

  • 개발 및 배포 중에 시스템 성능은 어떻게 판단할 수 있을까?
  • 정답 레이블이 필요한 경우 사용자 반응에서 어떻게 레이블을 추론할 수 있을까?
  • 모델 성능을 비즈니스 Goal과 Objectives를 어떻게 연결할 수 있을까?

1-4. Action(모델 개발 후 배포 & 모니터링)

앞서 정의한 지표가 어떻게 변하는지 파악하기

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

1-5. 추가 원인 분석

새롭게 발견한 상황을 파악해 어떤 방식으로 문제를 해결할지 모색

그 과정에서 앞서 진행한 과정을 반복

2. 비즈니스 모델

2-1. 비즈니스 모델 파악

회사는 비즈니스 모델을 만들고, 비즈니스 모델을 통해 매출이 발생함

해당 비즈니스 모델에서 어떤 데이터가 존재하고, 그 데이터를 기반으로 어떤 것을 만들 수 있는 지 생각

  1. 회사의 비즈니스 파악하기

    회사가 어떤 서비스, 가치를 제공하고 있는가?

    • 보통 기업의 홈페이지에 보면 제품 라인업이 있음
  2. 데이터를 활용할 수 있는 부분은 어디인가?(Input)

  3. 모델을 활용한다고 하면 예측의 결과가 어떻게 활용되는가?(Output)

이 글은 커넥트 재단 Naver AI Boost Camp 교육자료를 참고했습니다.

profile
반갑습니다.

0개의 댓글