머신러닝 프로젝트 Flow
문제 정의의 중요성
특정 현상을 파악하고 그 현상에 있는 문제를 정의하는 과정
풀려고 하는 문제가 명확하지 않으면 그 이후 무엇을 해야할 지 결정하기 어려움
문제를 해결하기 위한 flow
- 현상 파악 → 목적, 문제 정의 → 프로젝트 설계 → action → 추가 원인 분석
현상 파악
-
어떤 현상이 발견되었는가?와 같은 현재 상황 파악
-
어떤 일이 발생하고 있는가, 해당 일에서 어려움은 무엇인가
-
e.g., 레스토랑 매출이 3달 연속 감소하고 있으며, 전체적인 손님 수가 줄고 있다.
-
구체적인 문제 정의
- 무엇을 해결하고 싶은지, 무엇을 알고 싶은지 구체적으로 문제를 정의
-
e.g., 데이터를 확인해보니 처음 방문하는 손님이 심하게 줄어들고 있다.
→ 가게를 SNS에 홍보, 처음 방문하는 손님들의 어려움을 더 구체적으로 확인
→ 메뉴가 너무 다양하고 설명이 부족해 선정에 어려움이 있었음
→ 당장 진행할 수 있는 설명을 늘리는 방식 (룰 베이스) + 손님 취향에 기반한 음식 추천 (알고리즘) 으로 문제 해결
⇒ 문제 정의는 현상을 계속 쪼개고, 그 문제를 기반으로 어떤 어려움을 겪고 있는지 파악
-
데이터로 할 수 있는 일을 만들어서 진행하되, 알고리즘 접근이 무조건 최상은 아님
-
-
인지하면 좋은 내용
-
문제를 쪼개서 파악
-
문제 해결 방식은 다양
-
해결 방식 중 데이터로 해결할 수 있는 방법 고민
-
점진적으로 실행
-
프로젝트 설계
-
해결하려고 하는 문제 구체화
-
머신러닝 문제 타당성 확인
-
제품, 회사의 비즈니스에서 어떤 가치를 줄 수 있는지 고려
-
필요한 데이터의 종류와 기존 모델이 있는지 살펴보기
-
머신러닝 솔루션이 최적이 아닐 수 있음을 인지하기
-
머신러닝이 사용되면 좋은 경우
-
학습할 수 있는 패턴이 있는 경우
- e.g., 복권 당첨번호 예측은 패턴이 없음
-
학습을 위한 목적 함수를 만들 수 있어야 함
-
패턴이 복잡한 경우
- e.g., 주소 검색 문제는 머신러닝이 필요하지 않지만, 집 가격 예측 문제는 복잡
-
데이터가 존재하거나 수집할 수 있어야 함
-
사람이 반복적으로 실행하는 경우
- e.g., 아이에게 고양이 사진을 보여주고 고양이를 알아보게 하는 작업
-
-
머신러닝이 사용되면 좋지 않은 경우
-
비윤리적인 문제
-
간단히 해결할 수 있는 경우
-
한 번의 예측 오류가 치명적인 결과를 발생할 경우
-
-
-
목표 설정, 지표 결정
-
Goal : 프로젝트의 일반적인 큰 목적,
Objective : Goal 달성을 위한 세부 단계 목표 (구체적인 목적)
-
e.g., 랭킹 시스템에서 고객의 참여를 최대화하고 싶은 goal이 있는 경우,
objective로는 컨텐츠 필터링을 통해 사용자 불쾌감 줄이기,
참여에 따른 게시물 랭킹 선정 등이 있다.
-
-
목표를 설정하며 데이터를 확인해야 함
-
정확히 찾으려는 데이터가 없는 경우 여러 시나리오를 고려
-
Label을 가진 데이터가 있으면 바로 사용
-
유사 Label을 가진 데이터가 있는 경우 유사 label 사용
-
Label이 없는 경우 직접 labeling 또는 labeling이 없는 학습 방법 찾기
-
데이터가 아예 없는 경우 데이터 수집 방법부터 고민
-
-
-
Objective가 여러 개인 경우 분리하는 것이 좋음
-
학습하기 쉬워야 함
-
모델을 재학습하지 않도록 모델 분리
-
-
-
제약 조건
-
프로젝트에 사용할 수 있는 시간, 예산, 관련된 사람 고려
-
개인정보 보호 요구
-
기술적 제약
- 기존에 운영하고 있던 환경
-
성능
-
새로 만든 모델을 비교할 baseline 제작
-
Threshold 확립
-
Performance Trade-off 고려
-
해석 가능 여부
- 결과가 왜 발생했는지 해석이 필요한가, 해석이 필요한 사람인가
-
-
-
베이스라인, 프로토타입
-
모델이 더 좋아졌다고 판단할 수 있는 baseline이 필요
- 꼭 모델이 아닌 Rule base 규칙 설계도 가능
-
간단한 모델부터 시작하는 이유
- 최악의 성능을 알기 위해 허수아비 모델로 시작
-
Input 입력 - Output 반환하는 웹페이지 제작
- 디자인보다 모델 동작에 초점
-
-
평가 방법 설계
-
작게는 모델 성능 지표, 크게는 비즈니스 지표(매출)일 수 있음
-
Action이 기존보다 더 성과를 냈는지 아닌지 파악을 위한 AB Test 진행
-
개발 및 배포 중 시스템 성능은 어떻게 판단할 수 있을지 고려
-
Action (모델 개발 후 배포 & 모니터링)
-
앞서 정의한 지표가 어떻게 변하는지 파악
- 잘못된 예측의 문제 파악
추가 원인 분석
-
새롭게 발견한 상황을 파악해 어떤 방식으로 문제를 해결할 지 모색
-
앞서 진행한 과정 반복
비즈니스 모델
-
비즈니스에 대한 이해도가 높을수록 문제 정의를 잘 할 수 있음
-
비즈니스 모델에서 어떤 데이터가 존재하고 어떤 것을 만들 수 있을 지 생각
비즈니스 모델 파악하기 (Uber Case Study)
Uber은 차량 서비스, 음식 배달 서비스, 대중교통 개선 지원 등 다양한 서비스 제공
-
차량 서비스의 핵심 : 수요와 공급을 매칭시켜 손님과 드라이버가 만날 수 있는 플랫폼
-
많은 드라이버 → 손님의 대기 시간 감소 → 손님 증가 → 수입 증가 → 많은 드라이버 순환
-
많은 드라이버가 결국 비즈니스 플라이휠의 시작
-
데이터를 활용할 수 있는 부분 탐색
모델을 활용한다고 하면 예측 결과가 어떻게 활용되는가?
※ 모든 이미지 및 코드 출처는 네이버 커넥트재단 부스트캠프 AI Tech 5기입니다. ※
