머신러닝 실무 프로젝트

p.27

 

머신러닝 프로젝트 과정

 

1. 비즈니스 문제를 머신러닝 문제로 정의한다

2. 논문을 중심으로 유사한 문제를 조사한다.

3. 머신러닝을 사용하지 않는 방법은 없는지 검토한다.

4. 시스템 설계를 고려한다.

5. 특징량, 훈련 데이터와 로그를 설계한다.

6. 실제 데이터를 수집하고 전처리한다.

7. 탐색적 데이터 분석과 알고리즘을 선정한다.

8. 실제 데이터를 수집하고 전처리한다.

9. 시스템에 통합한다.

10. 예측 정확도, 비즈니스 지표를 모니터링한다.

 

p.27

머신러닝으로 해결한 문제 사례를 찾으려면 다음 세 가지 사항을 중점적으로 살펴보는 것이 좋다.

 

1. 어떤 알고리즘을 사용했는가?

2. 어떤 데이터를 특징량으로 사용했는가?

3. 머신러닝 부분을 어떻게 통합했는가?

 

p.28

일반적인 비즈니스 문제를 해결할 때와 마찬가지로 문제를 어떻게 해결할 것인지 정의한다. 이 때 목적을 명확히 정의해야 한다. 해결하고자 하는 문제의 가설 수립과 무엇을 해야할지 명확하게 하는 것도 중요하다. 시스템을 만들 때는 매출 개선, 유료 회원 증가, 제품 생산 비용 절감과 같이 비즈니스 목적이 있다. 제품 생산 비용 절감이 목적이라면 수율을 개선해야만 한다. 수율을 개선하려면 '머신러닝을 사용해 불량이 발생하는 원인(지점)을 찾는다'처럼 구체적이고 실천할 수 있는 수준까지 목표를 세분화해야 한다.

 

이 과정에서 매출 목표나 일별 유료 회원 증가와 같은 비즈니스 지표인 KPI가 결정된다. KPI는 예측 모델의 성능과는 다른 관점에서 중요하다. KPI자체는 비즈니스 단계에 따라 달라질 수 있지만 처음 구체화해나갈 때 임시로라도 한 가지를 정해놓는 것이 좋다. KPI를 정하는 방법이나 목적과 문제를 설명하는 방법은 [린 스타트업]이나 [린 분석] 같은 책을 참조하는 것이 좋다.

 

머신러닝 문제 설정을 예로 들면 '온라인 쇼핑 사이트의 매출 향상을 위해서 사용자별로 추천 상품을 제시한다' 또는 '공장 전력 소비량을 최적화하기 위해 소비 전력을 예측한다'처럼 프로젝트의 목적이나 해결 방법을 함께 고려한다. '유료 회원을 늘리고 싶다'처럼 결과를 바로 확인할 수 없는 것이나 '딥러닝으로 대단한 일을 하자'처럼 목적을 알 수 없는 것은 좋지 않은 문제 설정의 예다. 설사 경영진이 이러한 요구를 해도 현장에서는 더 구체화해야 한다.

 

p.30

동일한 예측 모델을 계속해서 오래 사용하면 임력 데이터 경향이 변화해 정확도가 낮아져 의도하지 않는 동작을 할 수 있다. 이를 방지하려면 정기적으로 새로운 데이터를 사용해 예측 모델을 업데이트하거나 필요에 따라 특징량을 다시 검토해야 한다. 즉 에측 모델을 계속해서 유지보수해야 한다.

 

p.32

머신러닝에서 100% 정확한 알고리즘은 없다. 시스템이 전체적으로 어떻게 오류에 대처하는지, 사람이 직접 확인하거나 수정해야 하는지, 필요하다면 대처해야 할 지점이 어디인지 고려하는 것도 머신러닝 시스템 설계에 포함해야 한다. 이를 이해하고 시스템 전체에서 리스크를 통제할 방법을 결정한다. 예를 들어 예측 결과를 사람이 직접 확인하는 단계를 마련하거나 예측 결과가 큰 악영향을 받지 않았다는 것을 전제로 애플리케이션에 이용하는 방법 등을 채택할 수 있다. 

 

p.38

예측 모델 개발에 몰두하면 원래 목표를 잊기 쉽다. 예측 모델을 만드는 본래 이유는 매출 목표나 일간 유료 회원 증가 수와 같이 비즈니스 상의 지표, 다시 말해 KPI를 개선하고자 하는 요구가 있었기 때문이다. 이 지표들의 추이를 보면서 필요에 따라 성능을 개선해야 한다.

 

p.42

https://developers.google.com/machine-learning/guides/rules-of-ml?hl=ko 

Rules of Machine Learning:  |  ML Universal Guides  |  Google Developers

p.48

https://scikit-learn.org/stable/tutorial/machine_learning_map/

Choosing the right estimator

p.58

로지스틱 회귀는 이름과 달리 분류 알고리즘이다. 로지스틱 회귀는 간단하면서도 파라미터가 많지 않아 빠른 예측이 가능해 다양한 머신러닝 알고리즘을 비교할 때의 기준점(baseline)으로 많이 사용된다. 예르 ㄹ들어 구글 지도에서는 주차장의 빈자리를 추정할 때 로지스틱 회귀를 추가 특징량과 함께 사용한다.

 

https://ai.googleblog.com/2017/02/using-machine-learning-to-predict.html

Using Machine Learning to Predict Parking Difficulty

 

p.59

로지스틱 회귀의 구조

 

퍼셉트론과 달리 활성화 함수로 시그모이드 함수(sigmoid function 혹은 logistic sigmoid function), 손실 함수로 교차 엔트로피 오차 함수(cross-entropy error function)를 사용하며 정규화항(regularization term) (또는 벌칙항 penalty term)을 추가함으로써 퍼셉트론보다 과적합을 방지하기 쉽고 온라인 및 배치 학습 모두가 가능하다.

 

p.65~66

SVM의 특징은 크게 두 가지다.

 

첫 번째 특징은 마진 최대화(margin maximization)다. 정규화항과 마찬가지로 과적합을 억제한다. 

 

두 번째 특징은 커널이라고 불리는 기법이다. 커널은 선형 분리 불가능한 데이터라도 커널 함수를 사용해서 유사한 특징량을 추가해 데이터를 더욱 고차원의 벡터로 만들어서 선형 분리 가능하게 만드는 방법이다. 

 

p.81

데이터 분포가 극단적으로 치우친 특성 때문에 이상 탐지에는 비지도 학습을 사용한다. 이 주제는 범위가 매우 넓은데 대부분 데이터 점이 많이 모인 부분에서 떨어진 부분을 이상값으로 검출하는 형태를 사용한다. 사이킷런을 사용한다면 SVM 기반의 One Class SVM 등으로 이상탐지를 할 수 있다.

 

p.85

정밀도와 재현율은 상충관계에 있으며 문제 설정에 따라 중시하는 쪽이 달라진다.

 

놓치는 데이터 수가 많더라도 더욱 정확한 예측이 필요하다면 정밀도를 중시한다. 스팸 메일 판정에서는 중요한 메일을 스팸으로 잘못 판정하는 것보다 가끔 스팸을 놓치는 편이 낫다. 즉 가끔은 스팸 메일을 봐도 좋으니 꼭 수신해야 하는 메일이 스팸 메일로 걸러지지 않도록 하는 것에 해당한다.

 

다소 잘못 걸러내는 비율이 높더라도 데이터 누락을 최소화하고자 할 때는 재현율을 중시한다. 이는 모든 데이터에 대한 누락 최소화를 중요하게 생각하는 방법이다. 예를 들어 발생 빈도가 낮은 질병이라면 병에 걸렸다고 오진을 하더라도 재검사를 받으면 문제가 없다고 하는 경우이다. 스팸 메일 분류에서는 재현율을 중시하는 것이 그리 달갑지는 않다.

 

p.93~94

모델의 성능을 비교할 때는 데이터 분포에 차이가 있다는 것을 가정한 후 F값을 기준으로 비교한다. 실제 문제를 풀 때는 정밀도나 재현율 중 무엇을 중시할지 고려해 최소한의 성능을 보장하는 방향으로 튜닝하는 방법이 바람직하다.

 

잘못된 판단을 허용하지 않는 문제, 예를 들어 '정밀도가 0.9 미만인 모델은 채용하지 않는다'와 같은 최저 수준의 조건을 정하고 그 수준보다 F값이 높아지도록 파라미터를 조정한 뒤 모델을 선택하는 것이 좋다. 다양한 분류 모델을 비교할 때는 AUC도 자주 사용한다.

 

분류 성능은 어디까지나 비즈니스에 적용할 수 있는 최저 품질 보증 기준이다. 성능 조절에 몰두하다 보면 그 자체가 목적이 되기 쉽다. 학습 모델의 성능이 높은 것과 비즈니스 목표를 달성하는 것은 별개의 문제이다. 모델을 활용하는 목적이 무엇이었는지 항상 기억해야 한다. 그러기 위해서는 제품 출시에 필요한 성능을 결정한 뒤에도 최종 목표 수치를 만족하는지 측정하고 지속적으로 개선할 수 있는 구조를 갖춰야 한다.

 

p.95

파이썬에서 for문으로 계산하는 것이 아니라 수치 계산에 특화된 numpy나 scipy와 같은 라이브러리를 사용하면 훨씬 빠르게 계산할 수 있다. 수치 계산용 라이브러리는 타입을 지정한 배열을 만들거나 내부적으로 C나 포르탄으로 최적화된 처리를 이용해 행렬을 고속으로 계산한다. 수치 계산을 할 때는 가능한 넘파이 등의 라이브러리에 계산을 맡기는 것이 속도에 유리하다.

 

p.100

머신러닝에서 '배치'의 의미는 특별하다. 배치 처리와 어원은 같지만 머신러닝 문맥에서 배치는 대부분 '배치 학습'을 의미한다. '배치 학습'과 일반적인 '배치 처리'는 어떻게 다를까? 

 

이번 장에서는 배치 처리와 대치하는 개념을 '실시간 처리'라고 부른다. 배치 처리는 일괄적으로 어떤 처리를 하는 것 또는 그러한 처리 자체를 의미한다. 이에 비해 실시간 처리는 실시간으로 전송되는 센서 데이터나 로그 데이터를 순차적으로 처리하는 것이라 정의한다.

 

또한 이번 장에서는 '배치 처리'와 혼동을 피하기 위해 이후 배치 학습은 일괄 학습, 온라인 학습은 순차 학습으로 표현한다.

 

일괄 학습과 순차 학습은 모델을 학습할 때 데이터를 저장하는 방법이 다르다. 일괄 학습에서는 최적의 가중치 계산을 위해 모든 훈련 데이터가 필요하다. 일반적으로 훈련 데이터가 늘어날수록 메모리양도 그만큼 늘어난다. 

 

p.101

일괄 학습과 순차 학습은 학습 시 필요한 데이터 덩어리의 크기, 즉 학습에서의 최적화 정책이 다르다.

 

p.102

배치 처리로 수집한 데이터를 일괄 처리하기는 해도 최적화 과정에서는 순차 학습을 할 수 있다.

 

예측 단계에서는 학습 단계의 최적화 정책이나 처리 방법에 관계없이 배치 처리와 실시간 처리를 이용한 예측이 모두 가능하다. 실제 학습을 할 때는 데이터를 유지할 수 없는 경우를 제외하면 배치 처리를 적용하는 것이 시행착오를 줄이는 데 유리하다.

 

계속해서 배치 처리에서 학습을 수행하는 세 가지 예측 패턴과 실시간 처리 패턴을 살펴보겠다. 패턴 구성은 다음과 같다.

 

- 배치 처리로 학습과 예측, 예측 결과를 DB에 저장하고 서비스를 제공

- 배치 처리로 학습, 실시간 처리로 예측, 예측 결과를 API 경유로 제공

- 배치 처리로 학습, 최종단 클라이언트에서의 실시간 처리로 예측

- 실시간 처리로 학습, 예측, 서비스를 제공

 

p.107

https://tecton.ai/blog/devops-ml-data

Why We Need DevOps for ML Data | Tecton

 

p.108

실시간 처리로 학습해야 하는 상황은 무엇일까?

 

슬롯 머신 알고리즘 등의 일부 알고리즘이나 실시간 추천이 필요하다면 파라미터를 실시간으로 즉시 업데이트해야 한다. 이때는 메시지 큐 등을 사용해 입출력 데이터를 주고받는 등 구성이 한층 복잡하다. 그러나 분류나 회귀 작업에서 모델을 즉각적으로 업데이트해야 하는 경우는 많지 않다.

 

비교적 짧은 간격으로 모델을 업데이트해야 한다면 임의의 간격 동안 쌓인 데이터는 배치 처리로 학습하고 최적화는 추가 학습이 가능한 미니 매치 학습 방법을 적용하는 것이 좋다.

 

p.114

대규모 데이터를 이용한 머신러닝에서는 데이터 전송 시간이 가장 큰 병목이다. 필자의 경험으로 봤을 때 1GB를 넘는 로그를 일괄로 내려받아 그대로 메모리에 올려 관리하는(on-memory) 방법은 포기하는 것이 좋다.

 

사이킷런을 사용해 학습할 때는 반드시 머신러닝 배치 처리 서버로 데이터를 전송해야 한다. 전송 시간을 줄이기 위해서는 분산 RDBMS를 사용해 데이터 웨어하우스에 MySQL과 같은 온라인 트랜잭션 처리(OLTP) 서버와 데이터를 동기화하고 가능한 분산 RDBMS에서 SQL로 전처리되도록 구성하는 것이 좋다.

 

대규모 데이터에 복잡한 전처리를 정기적으로 수행해야 한다면 아마존 S3에 저장된 데이터를 AWS 글루로 가공하는 등 되도록 로컬 머신으로 다운로드하지 않는 방법을 고려해야 한다.

 

p.127

머신러닝 시스템에서는 예측 모델을 다뤄 발생하는 어려움이 있다. 즉 하나의 실험 결과를 계속해서 재현하기 어렵다. 머신러닝 예측 모델은 주어지는 데이터에 따라 변화한다. 데이터도 끊임없이 변한다. 그렇기 때문에 머신러닝 시스템에서는 조금이라도 (좋은 방향이든 그렇지 않은 방향이든) 변경하면 시스템 전체의 행동이 바뀐다. 이 특성을 CACE(Change Anything, Change Everything) 원칙이라 부른다. 

 

머신러닝 시스템에서 예측할 때 학습 시와 동일한 행동을 얻기 힘든 구체적인 원인은 다음과 같다.

 

- 대규모 데이터에서 과거 특정 시점의 데이터를 사용자 정보 같은 마스터 데이터가 바뀌는 등의 문제가 있어 동일한 형태로 준비하기 어렵다.

- 다른 실행 환경의 라이브러리나 버전, 하드웨어 같은 의존 관계를 재현하기 어렵다.

- 실험 환경과 실제 환경의 파이프라인에서 사용하는 언어나 코드가 다르다.

- 학습 환경과 실제 환경의 입력 데이터 분포나 가정이 모두 다르다.

 

동일한 학습 모델을 얻기 어려운 이유는 다음과 같다.

- 하이퍼파라미터 등의 설정을 기록해두지 않는다.

- 학습에 시간이 오래 걸리고 비용이 높아 경제적 이유로 재실험을 하기 어렵다. 최근에는 주피터 노트북의 등장으로 과거보다 쉽게 동일한 실험을 재현할 수 있다. 그러나 동일한 데이터 준비나 라이브러리 의존 관계, 환경을 재현하기 어려워 상당한 수정을 해야 한다.

 

p.129

https://cloud.google.com/architecture/mlops-continuous-delivery-and-automation-pipelines-in-machine-learning?hl=ko 

MLOps: 머신러닝의 지속적 배포 및 자동화 파이프라인  |  Google Cloud

p.131

만약 데이터과학자가 도커 이미지를 만들기 어려워한다면 cookiecutter(https://github.com/cookiecutter/cookiecutter) 또는 cookie-docker-science(https://github.com/docker-science/cookiecutter-docker-science) 등의 도구를 활용해 도커 이미지 템플릿을 만드는 것도 좋다.

p.132

많은 AI 스타트업에서 실험 관리용 OSS를 개발하고 있다. 2021년 2월 기준으로 아파치 스파크 개발로 알려진 데이터브릭스에서 개발한 MLFlow의 인기가 가장 높다. 노트북에서는 기존 실험 결과를 덮어쓰는 등의 오류가 발생하기 쉬우나 실험 관리 도구를 활용하면 실험 재현성을 높일 수 있어 협업도 쉬워진다. 이와 함께 Hydra 등을 활용해 설정 파일로 다양한 파라미터를 관리하면 더욱 쉽게 실험을 재현할 수 있다. 설정 관리를 지원하는 도구를 사용하면 반복되는 실험에 따라 명령어 파라미터 수가 늘어나 관리가 어려워지는 문제 해결도 쉬워진다.

 

p.136~137

새로운 모델의 재학습과 배포를 자동화하기 위해 갖춰야 할 구조는 다음과 같다.

- 특징량 엔지니어링 로직 단위 테스트

- 학습 시의 손실 수렴 여부 테스트

- 파이프라인의 산출물 생성 확인 테스트(모델 등)

- 예측 시 초당 쿼리 수

- 예측 정확도의 임곗값 초과 여부 테스트

- 스테이징 환경으로의 풀 리퀘스트 병합 등을 트리거로 하는 모델 배포 테스트

- 스테이징 환경에서의 파이프라인 동작 검증 테스트

 

일반적인 웹 애플리케이션과 마찬가지로 모델 및 예측 시스템 개발에서도 개발 환경, 스테이징 환경, 운영 환경과 같은 여러 단계를 거친다. 다음 환경으로 배포할 때 수작업을 간으한 줄이는 것은 모델 개발의 CI/CD에 매우 중요하다. 풀 리퀘스트 승인이나 특정한 브랜치로의 병합이 일어났을 때 다음 환경에 자동으로 배포하도록 하는 수작업과 자동화를 조합해 기민함을 달성하는 동시에 제반 장치를 확보하는 것이 좋다.

 

p.138~139

특히 모델의 성능이 노화되었을 때 웹 애플리케이션에서 'CPU의 처리가 느리니 코어를 늘리자'처럼 명확한 대책을 즉시 찾아내기 어렵다. 그렇다면 어떤 지표를 추적해야 할까? 다음 두 가지 지표로 나누어 생각해보자.

 

- 예측 결과 서빙 시 지표

- 학습 시 지표

 

예측 결과 서빙 시 지표에는 다음을 고려할 수 있다.

 

- 메모리/CPU 등 하드웨어 리소스 사용량

- 예측 응답 시간

- 예측값이 존재하는 윈도우의 평균값, 중앙값, 최댓값, 최솟값, 표준편차 등 통계값이나 분포

- 입력값의 통곗값, 특히 결손값 또는 NaN의 빈도

 

첫 두 지표는 일반적인 웹 애플리케이션 서버와 크게 다르지 않다. 그러나 예측 응답 시간은 예측 서빙 지연과 직결된다. 머신러닝 개발자나 데이터 과학자는 예측 정확도가 높은 모델을 사용하기를 원한다. 예측 처리가 오래 걸리는 무거운 모델을 사용해 전환율이 낮아질 위험이 있다는 것에 주의해야 한다. 부킹닷컴이 KDD 2019에서 발표한 논문에 따르면 예측 지연이 30% 상승했을 때 사용자 전환율이 0.5% 감소해 이를 보완하기 위해 다양한 고속화를 추진하고 있다고 한다.

 

머신러닝 시스템의 예측 지연관련 구글 클라우드 포스팅

https://cloud.google.com/architecture/minimizing-predictive-serving-latency-in-machine-learning?hl=ko 

머신러닝에서 실시간 예측 제공 지연 최소화  |  클라우드 아키텍처 센터  |  Google Cloud

 

입력값이나 예측값의 통곗값은 예측 결과가 가정한 범위 안에 있는지 검증하는 것이다. 실험할 때의 예측값과 실제 데이터에서의 예측값이 상당히 다르다는 것을 나타내는 표준편차나 분산을 활용해 경고를 발생시키는 등의 구조도 고려해야 한다.

 

실험의 예측 결과 분포는 결과를 만족하는지 여부를 판단할 때까지 지연이 발생하는 경우에도 중요하다. 예를 들어 부킹닷컴의 논문에서 다룬 예약 데이터에 기반해 리뷰 작성 여부를 예측하는 등 실제 정답 레이블을 구입하는 행위에서 며칠, 몇 주, 몇 개월이 지나야 얻을 수 있는 문제가 있다고 보자. 이 문제에 대해 예측 결과 히스토그램이 쌍봉형 패턴(double top and bottom patterns)을 보이면 2 클래스 분류가 잘 이루어지고 있다고 휴리스틱에 기반해 품질 예측 결과를 확인한다. 신규 예측 결과의 정답 레이블을 얻기 전에 휴리스틱으로 검증할 수 있다는 점이 중요하다.

 

이 외에도 다음의 두 가지 지표를 얻을 수 있다.

 

- 모델 학습일 기준 경과일

- 학습 시 예측 정확도와 학습 시간

 

너무 오래된 모델은 새로운 데이터에 적응하지 못할 가능성이 높다는 가설에 따라 학습일을 기준으로 경과일을 모니터링한다. 임곗값을 적용해 예측 정확도를 모니터링해도 시간이 오래 지나 성능이 떨어지는 것은 파악하지 못하기도 한다. 이때는 모델 학습일에서 경과한 일수를 활용해 모델을 재검토할지 결정할 수 있다. 

 

p.139

 

광고 송출 서비스의 지표 모니터링 예

 

- 예측 정확도 지표 : AUC, log loss, 상대적 정보 획득(relative information gain), 상대 오차

- 훈련 데이터 지표 : 훈련 데이터 수, 목적 변수의 평균값 E(Y), 훈련 데이터의 새로운 부분과 오래된 부분의 E(Y)의 차

- 시스템 지표 : 데이터 다운로드, 전처리 및 훈련 시간, 배포 모델의 파일 크기 

 

p.141

실제 데이터에서 예측 정확도를 얻는 것은 중요하지만 실시간성도 낮아지기 때문에 예측 결과 서빙 시의 입력한 데이터 품질이나 건전성을 테스트하는 것으로 모델의 유효성을 검증한다. 머신러닝 시스템의 동작은 입력된 데이터에 따라 달라진다. 입력 데이터 품질을 확인하는 것은 예기치 못한 사태를 방지하는 데 중요하다. 텐서플로 데이터 벨리데이션(https://www.tensorflow.org/tfx/guide/tfdv) 참고문헌(https://research.google/pubs/pub46484/, https://mlsys.org/Conferences/2019/doc/2019/167.pdf) 또는 deequ(https://aws.amazon.com/ko/blogs/big-data/test-data-quality-at-scale-with-deequ/), 참고문헌(https://www.vldb.org/pvldb/vol11/p1781-schelter.pdf)처럼 이를 지원하는 기법이 논문 또는 오픈소스 등으로 공개되어 있다. 

 

p.142

그렇다면 검증은 어떻게 해야 할까? 실제 예측 결과를 계산한 입력 데이터에 두 가지를 검증한다.

- 입력 데이터의 '스키마' 검증

- 입력 데이터의 편차나 변화(drift) 검증

 

입력 데이터의 스키마란 구글이 TFX 논문을 통해 제안한 개념이다. 특징량의 특성을 사전에 스키마로서 학습 데이터에서 정의하고 스키마에서 벗어난 값이 입력되면 경고를 보내는 방식으로 사용한다. 다음과 같은 사항을 확인하는 구조로 미리 준비한다.

 

- 데이터가 예상한 범위에 포함되는가?

- 범줏값은 즉시 알 수 있는가?

- NaN/Inf 값이 생성되는가?
- 특징량의 고차원 배열의 요소 수가 같은가?

- 특징 입력이 누락되지 않았는가?

 

 

p.146

사업 총 이익 또는 매출 같은 수치를 책임지는 사람에게는 각 예측기의 성능보다 '얼마나 이익을 높였는지'가 중요해 비즈니스 지표를 활용해 커뮤니케이션하는 것이 좋다. 데이터 과학 팀 내부에서 공유할 때는 '이 기능을 출시하면 예측 정확도가 향상된다'정도로 충분하지만 팀 외부로 보고할 때는 예측 정확도가 향상되면 무엇이 좋아지는지 설명해야 한다. 예를 들어 머신러닝 예측을 마케팅 예산 배분에 활용하는 경우라면 다음과 같다.

 

상황	지면 및 인터넷, TV광고 등 마케팅 채널별 매출 결과를 예측하여 마케팅 예산을 배분하고 싶다
출시 내용	중단 데이터 처리를 개선해서 매출 지연 효과를 예측에 반영될 수 있또록 했다.
좋지 않은 보고의 예	예측 정확도가 향상되었다
좋은 보고의 예	매출 지연 효과를 반영할 수 있게 되어 지금까지 과소평가된 마케팅 채널 A에 예산을 늘린다. 결과적으로 1개월 단위의 매출이 증가한다. 증액 초반에는 현재와 마찬가지로 안 좋아 보일 수도 있다.

실제로 넷플릭스의 추천 시스템은 해지율을 낮췄고 연간 약 10억 달러의 비용을 절감한 것으로 알려졌다.

 

이 값은 추천 정확도만으로는 도출하기 어렵다.

 

p.147

검증에 이용할 수 있는 지표는 매우 다양하다. 동영상 시청 서비스의 추천 기능을 생가해보자. 유료 회원 지속 기간, 평균 세션 시간, 세션당 동영상 시청 수, 추천 아이템 클릭률 같은 다양한 지표를 손에 꼽을 수 있다. 제품의 장기적인 목표에 가까운 지표를 선택하는 것이 가장 좋지만 고객 생애 가치 같은 후행 지표는 검증하는 데 많은 시간이 소요된다. 이러한 지표 대신 사용할 수 있는 지표를 대체지표(proxy metrics)라고 한다. 넷플릭스에서는 '신규 사용자 중 처음 세션에 시청 리스트 세 개 이상을 등록한 사용자 비율'을 하나의 지표로 적용했다.

 

p.149~150

인터넷 광고의 효과를 생각해보자. 인과 추론에서는 광고를 보여주는 것을 개입(cause), 구매 행동을 결과 변수(outcome), 개입한 표본은 개입군 또는 실험군(treatment group), 개입하지 않은 표본을 대조군 또는 통제군(control group)이라고 한다. 

 

광고 효과는 광고를 봤을 때와 보지 않았을 때 발생하는 구매 행동의 차이라고 생각할 수 있다. 개인 단위에서는 측정 가능한 결과 변수는 개입 여부로 한정된다. 광고에 접촉한 A가 동시에 광고에 접촉하지 않은 경우는 반사실(counter factual)이기 때문에 관측할 수 없다.

 

여기에서 루빈의 인과 모델에서는 관측할 수 없지만 잠재적으로 존재해 얻을 수 있는 결과의 수를 가정한 것을 잠재적 결과 변수라고 부른다.

 

 

p.151

개인이 대상일 때는 Y_1 - Y_0을 측정할 수 없다. 그러나 알고자 하는 것은 표본이 아닌 모집단에서의 효과다. 모집단에서의 효과는 개인의 구매 결과 차의 기댓값 E(Y_1 - Y_0)라고 볼 수 있다. 이를 평균 처리 효과(Average Treatment Effect)라고 한다.

 

식 7.1   =>    ATE = E(Y_1 - Y_0) = E(Y_1) - E(Y_0)

 

이게 평균 처리 효과를 어떻게 구하는지 설명한다.

 

p.151

개입 여부와 결과 변수에 상관관계가 있으면 식 7.1과 일치하지 않는다. 특히 결과 변수 Y를 기반으로 개입했을 때 그렇다. 인터넷 광고 예시로 돌아가보자. 구매 행동으로 이어질 것 같은 사용자를 타깃으로 개입하는 것이 일반적이다. 따라서 일반적인 관측 결과를 보면 원래 구매의욕이 높은 집단이 되어 개입군과 대조군에 차이가 발생한다. 선택

 

p.166

표본 크기가 클수록 판단은 쉽다. 테스트 결과를 빠르게 판단하는 것은 좋은 정책을 빠르게 적용할 수 있어 그만한 가치가 있다. 효과가 좋지 않은 정책은 테스트를 빨리 중단해야 한다. A/B테스트에서 쉽게 간과하는 점이 종료 시기를 정하지 않은 채 테스트를 방치하는 점이다. 테스트 실시 기간을 제한하는 것도 좋은 방법이다. A/B 테스트 플랫폼인 옵티마이즐리(Optimizely)는 p값을 지속적으로 관찰한 후 조기 판정하는 방법을 제안했다.

 

https://dokumen.tips/documents/peeking-at-ab-2017pdfsp1517pdf-2017-07-14-ramesh-joharia-stanford-university.html

Peeking at A/B 2017/pdfs/p1517.pdf · PDF file 2017-07-14 · Ramesh Johari∗ Stanford University ... We provide always valid

 

https://www.youtube.com/watch?v=AJX4W3MwKzU&ab_channel=StanfordOnline 

 

p.166

선택 편향을 없애기 위해 무작위 추출로 개입 여부를 결정하는 방법이 RCT다. 웹 서비스에서 사용자 단위로 효과를 제공하는 정책이라면 무작위로 사용자를 추출해 개입 여부를 결정한다. 무작위 추출에 따라 품질이 같은 두 그룹을 얻었는지 확인하는 것이 A/A테스트다. 두 그룹을 추출한 다음 시간을 두고 두 그룹의 차이가 있는지 확인한 후 한쪽에 개입한다. 또는 과거 데이터를 사용해 차이가 없는 것을 확인할 수 있다면 즉시 테스트를 시작할 수 있다.

 

p.167

https://www.exp-platform.com/Documents/2016-12PavelUPittNR.pdf

p.169

효과 검증에서 중요한 점은 예측 모델의 출력 자체가 아니라 예측으로 어떤 행동을 하는 시스템 관점에서의 성능이다. 과거의 다른 정책에 따라 생성한 로그에 기반해 행동 결정 정책을 평가하는 것을 Off Policy Evaluation(OPE)라고 한다. 앞서 설명한 것처럼 과거 정책과 다른 행동을 얻게 되는 경우의 평가가 문제가 되고 있지만 불연속적인 행도엥 적용할 수 있는 정책 성능 평가 기법으로 많이 사용하고 있다. 

 

https://realworldml.github.io/files/cr/9_camera-ready_-_A_Large-scale_Open_Dataset_for_Bandit_Algorithms.pdf

 

p.170

모델 훈련에 사용하는 손실 함수에 비즈니스 설정을 반영할 수도 있다.

 

거짓 음성과 거짓 양성의 영향이 다르면 정답 레이블에 따라 훈련 데이터의 레코드별 중요도가 다르다. 이때는 훈련 시 손실 함수 및 평가 함수에 레코드별 가중치를 반영할 수 있다. 일반적인 머신러닝 라이브러리에서는 훈련 시 표본 가중치(sample weight)로 설정한다. 광고 송출에서 이용하는 예측기에서는 특징량으로 광고 ID를 주로 사용하며, 광고별 매출의 영향도를 가중치로 손실 함수에 반영한 가중치 로그 손실(weighted log loss)을 사용하기도 한다.

 

https://arxiv.org/pdf/1603.03713.pdf

손실 함수 자체를 평균 제곱근 오차나 교차 엔트로피 오차가 아니라 독자적인 것으로 치환한 경우도 있다. 예측값을 이용해 행동했을 때의 기대 이익 계산식에서 손실 함수를 도출해 훈련에 이용한 사례에 관한 문헌(https://arxiv.org/pdf/1803.02194.pdf)도 있다. LightGBM처럼 머신러닝 라이브러리에 따라서 직접 구현한 함수를 손실 함수로 지정할 수도 있다. 이러한 방법으로 비즈니스 지표를 직접 향상시키도록 예측 모델을 훈련할 수 있다.

 

p.171

자주 사용되는 차이의 차이 기법(difference in differences)을 소개한다. 실험군과 유사한 경향을 나타내는 그룹의 결과 변수의 시간 변화를 활용해 개입 전후를 비교하는 기법이다. 지역 A에 한정해 지역 광고를 송출했을 때의 제품 매출에 대한 효과 검증 상황을 가정해보자. '지역 광고를 송출하지 않은 다른 지역의 일반적인 매출 변화 경향이 A와 유사한 지역'을 지역 B로 선택한다. 지역 광고 송출 전후에 발생한 지역 B의 매출 변화를 기반으로 지역 A에 광고 송출을 하지 않았을 때의 매출 추정값을 구할 수 있다. 이 추정값과 실적의 차이가 인과 효과가 된다. 

 

p.173

무조건 성공하는 A/B 테스트는 어떻게 만들 수 있을까? 간단하다. '대부분이 0이고, 음의 값을 갖지 않는 KPI'를 A/B 테스트의 평가 지표로 삼으면 된다. 다음 예에서는 B그룹을 대성공이라 판단할 수밖에 없다.

 

- A그룹 : 전환율 0.0% / 매출 0원

- B그룹 : 전환율 1.0% / 매출 1,000원

 

대부분 0이고 음의 값을 갖지 않는 지표는 0 이하로 내려가지 않는다. 어떤 실험을 해도 현재 상황과 크게 달라지지 않거나 오히려 좋아진다. 비즈니스 현장에서는 매출이나 전환율처럼 음의 값을 가질 수 없는 지표가 매우 많다. 0이라는 값을 갖는 모집단을 잘 선택하면 무조건 성공하는 A/B 테스트를 구현할 수 있다.

 

p.235

업리프트 모델이란 역학 통계나 다이렉트 마케팅에서 활용되는 머신러닝 기법이다. 이 기법은 무작위 비교 시험 데이터를 분석해 약이 어떤 환자에게 효과가 있는지, 다이렉트 메일은 어떤 고객에게 보내면 효과가 있는지 등을 예측한다.

 

p.235

일반적인 A/B 테스트가 단순히 반응하는지 여부를 확인하는 것과 달리 업리프트 모델링은 실험군과 대조군에서 어떤 특징량을 가진 표본이 반응하는지 여부를 확인한다. 이를 통해 개입 행위에 대해 특정한 표본이 얼마나 반응할지를 예측하며 효과를 보이는 것으로 예측되는 대상에만 개입 행위를 할 수 있게 된다. 반대로 개입하면 역효과가 예상되는 대상에는 개입하지 않을 수 있다.

 

p.236~237

업리프트 모델링에서는 개입 유무와 전환을 기준으로 대상을 네 그룹으로 나눈다. 전환은 전환함과 전환하지 않음으로 나눈다.

개입 안 함	개입함	범주	대응방안
전환하지 않음	전환하지 않음	무관심	비용이 드는 개입은 자제한다.
전환하지 않음	전환함	설득 가능	가능한 개입 대상에 포함시킨다.
전환함	전환하지 않음	청개구리	개입 대상에 절대로 포함시키지 않는다.
전환함	전환함	잡은 물고기	비용이 드는 개입은 자제한다.

 

무관심(do not disturbs / sleeping Dogs) 은 개입 여부와 관계없이 전환하지 않는 부류다. 예를 들어 과거 3년간 구매 이력이 없는 고객은 다이렉트 메일을 보내도 구매로 이어지지 않을 가능성이 높다. 이러한 고객들은 휴면 고객으로 분류해 광고 대상에서 제외하는 편이 비용을 아낄 수 있다.

 

설득 가능(persuables)은 개입을 하면 비로소 전환하기 시작하는 부류다. 업리프트 모델링을 활용해 찾아내고자 하는 부류이기도 하다. 예를 들어 '웹 사이트를 수차례 방문했고 타사 웹 사이트에서도 가격 비교를 하며 결정을 내리지 못하는'고객이라면 할인 쿠폰 등을 보내 구매 전환으로 유도할 수 있다.

 

청개구리(lost causes)는 개입하지 않는다면 전환하지만 개입하면 전환하지 않는 부류다. 예를 들어 매장에서 점원이 접근하면 고객이나 대출 상환현황을 안내하면 조기 상환하는 고객이 해당한다. 이러한 유형은 개입ㅇ르 시도하면 오히려 매출이 줄어든다.

 

잡은 물고기(sure things)는 개입 여부에 관계없이 전환하는 부류다. 예를 들어 슈퍼마켓 계산대 앞에 줄을 선 고객에게는 할인 쿠폰을 주지 않아도 구매를 하기 때문에 개입을 한다고 매출 증가로 이어지지 않는다. 오히려 쿠폰이 매출을 감소시킨다. 개입에 대한 반응률이라는 관점에서는 매우 좋은 지표를 얻을 수 있어 KPI를 높이고자 종종 개입 대상에 포함시키기도 한다. 그러나 쿠폰 발급이나 광고 송출처럼 개입에 비용이 든다면 개입을 자제해야 한다.