롯데ON 사례로 본 개인화 추천 시스템 구축하기, 1부 : Dynamic A/B Testing 아키텍처 구축

롯데ON은 풍부한 오프라인 쇼핑 인프라, 온라인 쇼핑 노하우로 세상에 없던 새로운 쇼핑 경험을 제공하는 온라인 쇼핑 플랫폼으로 발전하고 있습니다. 단순히 상품을 판매하는 플랫폼이 아닌 상품에 대한 경험을 제공할 수 있는 플랫폼을 목표로 고객이 원하고 만족하는 서비스를 만들기 위해 노력하고 있습니다.

롯데ON은 메인페이지, 상품상세, 검색, 장바구니, 주문완료 페이지에 이르는 롯데ON 고객의 여정 전반에 걸쳐 다양한 형태의 개인화 추천 서비스를 제공해오고 있습니다. 성능 좋은 신규 모델의 개발과 지속적인 실험을 통해 비즈니스 지표 개선에 기여하고, 고객이 찾을 가능성이 높은 상품을 적시에 제공하여 롯데ON에 방문하는 고객의 만족도를 높이고 있습니다.

비즈니스 문제 정의

신규 모델의 성능을 측정할 때 A/B 테스트 방식으로 오프라인 테스트와 온라인 테스트가 있습니다. 오프라인 테스트는 일반적으로 과거의 데이터를 기반으로 신규 모델의 성능을 평가합니다. 오프라인 테스트도 중요하지만, 모델의 과적합과 같은 문제들을 해결하고 실제 환경에서 진행하게 되는 온라인 A/B 테스트는 필수입니다.

일반적인 온라인 A/B 테스트는 성능이 떨어지는 모델과 좋은 모델을 일정한 비율(예: 5:5)로 일정 기간(예: 하루, 일주일) 동안 서비스하게 됩니다. 이럴 경우 성능이 떨어지는 모델이 지속적으로 서비스가 되기 때문에 비즈니스 손실 (클릭 효율의 손해)이 발생하여 매출에 영향을 주게 됩니다. 이런 문제를 개선하기 위해 실시간으로 모델의 성능을 평가하면서, 성능이 좋은 모델이 더욱 많이 선택될 수 있도록 하는 Dynamic A/B 테스트를 검토하였고, 실시간 최적화 알고리즘 중의 하나인 MAB (Multi-Armed Bandit) 알고리즘을 채택하였습니다.

구현한 Dynamic A/B 테스트는 최적의 모델을 서비스하기 위해 각 모델의 CTR (Click Through Rate) 지표에 기반하여 효율 좋은 모델을 서비스할 수 있게 하였습니다. AWS의 다양한 서비스를 활용하여 Dynamic A/B 테스트를 통해 공정하게 모델을 평가할 수 있는 A/B 테스트 환경을 구성하였고, AWS 서비스 간 유연한 연동으로 테스트에 소요되는 시간과 리소스를 단축할 수 있으며 데이터 과학자들은 모델 개발과 훈련에 더욱 집중할 수 있습니다. 이번 블로그에서는 롯데ON에서 Dynamic A/B 테스트를 어떻게 구현했는지 소개합니다.

솔루션 및 구현 내용

Dynamic A/B 테스트를 위해 크게 2가지 기능을 구현하였습니다.

1. MAB를 통한 Dynamic A/B 테스트

Dynamic A/B 테스트를 위해 MAB를 고려하였습니다. MAB는 카지노 슬롯머신 수익률 최적화에서 발전된 알고리즘으로 MAB을 통해 고객에게 반응이 좋은 모델을 제공하여 CTR 효율을 높이고자 했습니다. MAB 알고리즘으로는 ε-greedy, 톰슨 샘플링 등 다양한 알고리즘이 존재합니다.

먼저 ε-greedy와 톰슨 샘플링을 각각 시뮬레이션 하였으며 모델들의 노출 기회 밸런싱을 고려하여 톰슨 샘플링 알고리즘을 선택 하였습니다. 톰슨 샘플링은 각 선택지(Arm)에 대한 성공과 실패 횟수가 존재하고, 이로부터 베타 분포를 정의하여 학습하는 알고리즘으로 알파(α)와 베타(β) 클릭의 유무 여부를 통해 베타 분포를 구하여 클릭의 효율에 따른 모델로 수렴하게 됩니다.

이를 통해 결과적으로 클릭의 효율에 따른 모델을 제공할 수 있게 합니다. 톰슨 샘플링 알고리즘을 활용한 MAB를 통한 Dynamic A/B 테스트는 Dynamic A/B Testing on Amazon Personalize & SageMaker 워크샵에서도 쉽게 확인해볼 수 있습니다. 롯데ON에서는 CTR 효율이 높은 모델을 실시간으로 노출시켜 더 많이 서비스에 반영하고자 했습니다.

뉴스 또는 상품 리랭킹으로 널리 쓰이는 기존 MAB 활용 방식과 차이점을 보이는 부분은 선택(Arm) 입니다. 모델 간 비교를 위한 MAB에서의 선택지(Arm)는 “모델”이 되어야 합니다.

따라서 선택지(Arm)를 모델로 구성하고 각 모델 별 알파 값은 클릭, 베타 값은 비클릭으로 구성하였습니다. 또한 실제 서비스에 적용하기 위해서는 톰슨 샘플링을 배치 단위로 처리하는 bTS (batched Thompson Sampling) 방식을 도입하였습니다. 실제 서비스에서 유입되는 트래픽은 매우 빠르게 유입되고, 알파와 베타 파라미터 값이 순간적으로 크게 차이가 나면 대부분 하나의 모델만 선택 됩니다. 그래서 일정 시간 동안 (예: 24시간) 의 트래픽에 따른 모델들을 평가하기 위해 일정 시간 단위로 (예: 1시간) 파라미터를 업데이트 하는 bTS 방식을 선택하게 되었습니다.

AWS Lambda의 handler 부분에서 모델(Arm)별 파라미터에 따른 bTS 연산이 수행되며, 해당 시점에서 CTR 효율이 좋은 모델은 더 많은 노출의 기회를 갖게 됩니다. Dynamic A/B 테스트를 진행시에 한가지 유의할 점은 톰슨 샘플링을 바로 시작하지 않고, 충분한 탐색을 하는 Warming-Up 시간을 가져야 합니다. 이는 노출/클릭 지표 수집이 충분히 확보되어야 테스트 초반의 적은 모수로 인한 모델의 승부에 영향을 주는 편향(bias)을 감소시킬 수 있습니다.

2. 온라인 정적 A/B 테스트

첫번째 기능으로 MAB를 통해 CTR 효율에 따른 모델을 제공하였다면, 두번째로 온라인 정적 A/B 테스트는 테스트 기간 동안 두 가지 이상 모델을 일정한 비율(예: 5:5 비율) 로 노출시키는 방식입니다. 이번에 시간별 모델 성능을 평가하는 온라인 정적 A/B테스트 기능을 구현했습니다. 예를 들어, 관리자가 두 모델을 5:5 노출로 설정했을 경우 13시에 1000명의 고객이 들어왔다면 A 모델과 B모델이 각각 500명씩 동일한 비율로 노출할 수 있습니다.

앞서 MAB를 통한 동적 A/B 테스트의 경우, 배치로 파라미터를 지속적으로 업데이트 하기 때문에 고객의 클릭에 의해서 CTR에 따른 모델 노출이 결정되게 됩니다. 반면 온라인 정적 A/B 테스트 기능은 분할된 트래픽에서 모델 별 베이스 라인 지표를 사전에 파악 할 수 있어서 모델 별 성능 개선점을 찾는데 도움이 됩니다. 또한 관리자가 수동으로 세팅한 비율대로 실제 서비스가 동작하게 되어서, 온라인 A/B 테스트의 유스 케이스에 따라 선택적으로 사용할 수 있습니다.

다만 온라인 정적 A/B 테스트 기능은 A 모델이 B 모델보다 실제 상황에서 CTR 같은 비즈니스 지표가 낮게 나오더라도 실험 기간 동안 비즈니스에 끼치는 손실을 감수해야 하는 단점이 있습니다.

다음은 두 가지 기능에 대한 장점 및 단점을 요약하였습니다.

Dynamic A/B Testing 아키텍처

아래 그림은 이번에 구현한 Dynamic A/B 테스트를 위한 아키텍처입니다.

위의 아키텍처는 4개의 디커플링 (Decoupling) 컴포넌트로 구성된 Dynamic A/B 테스트의 데이터 흐름을 보여 주고 있고, 각각의 컴포넌트에 대해서 설명 드리겠습니다.

1. MAB 결과 서빙 플로우

단계 1: 유저는 롯데ON 의 추천 페이지에 접속을 합니다.

단계 2: 추천 API 는 MongoDB 에서 해당 추천 영역에 진행중인 실험 정보를 확인 후, 진행중인 실험이 있다면 회원 번호, 영역 코드를 Amazon API Gateway에 전달합니다.

단계 3: Amazon API Gateway 는 받은 데이터를 AWS Lambda 에 제공을 합니다. 만약 Amazon API Gateway 캐시에 관련 데이터가 있으면 바로 추천 API에 모델 코드를 전달합니다.

단계 4: AWS Lambda 는 MongoDB 에서 실험 유형 (예: Dynamic A/B 테스트, 온라인 정적 A/B 테스트) 을 확인 후, 알고리즘을 수행시킵니다. 실험 유형이 Dynamic A/B 테스트일 경우, MongoDB 로부터 톰슨 샘플링 알고리즘에 필요한 알파 (클릭 수), 베타 (비클릭 수) 를 조회해서, 값을 얻고 톰슨 샘플링 알고리즘을 실행합니다. 이를 통해서 선택된 모델을 Amazon API Gateway 에 전달합니다.

단계 5: Amazon API Gateway 는 추천 API 에 선택된 모델을 제공하고, 선택된 모델은 일정 시간 동안 캐싱 합니다.

단계 6: 추천 API 는 선택된 모델을 이용하여 “모델 서빙 서버” (예: Amazon SageMaker Endpoint) 에 호출하여 추천 리스트를 받아서, 유저의 추천 페이지에 제공합니다.

2. 파라미터 업데이트 플로우

단계 1: 롯데ON 추천 페이지의 시스템은 실시간 로그를 Amazon S3에 저장합니다.

단계 2: Amazon EMR 은 Amazon S3 에 저장된 로그를 다운로드 합니다.

단계 3: Amazon EMR은 데이터 프로세싱을 하여, 톰슨 샘플링 알고리즘에 사용할 알파와 베타 파라미터 값을 MongoDB 에 업데이트 합니다.

3. 비즈니스 지표 모니터링 플로우

단계 1: Streamlit 에서 MongoDB 를 조회하여, 실험 별 비즈니스 지표를 가시화합니다.

단계 2: 시간대별 효율 지표를 모니터링합니다.

4. 시스템 운영 모니터링 플로우

단계 1: 추천 API 호출이 발생하면 Amazon API Gateway와 AWS Lambda를 실행하고, Amazon CloudWatch 로그가 남게 됩니다.

단계 2: Amazon CloudWatch 로그를 바탕으로 구성된 Amazon CloudWatch, AWS X-Ray 대시보드로 시스템 운영 지표를 확인합니다.

구현 상세 1: MAB결과 서빙 API (API Gateway + Lambda)

MAB결과를 서빙 할 수 있는 API는 AWS Lambda와 Amazon API Gateway를 사용하여 서버리스로 구성하였습니다. 구현 및 설정 부분을 확인해 보겠습니다.

1. Amazon API Gateway 구성

롯데ON 사용자가 추천 상품 영역을 호출하게 되면, Amazon API Gateway에 회원번호, 영역코드 등을 GET 파라미터로 전달하게 됩니다. 전달된 파라미터를 이용하여 Amazon API Gateway의 캐시기능을 통해 일정 기간 동안 선택된 모델을 노출시킬 수 있도록 하였습니다.

2. Amazon API Gateway 캐시 설정

Amazon API Gateway에서 캐시를 설정하는 방법은 간단합니다. 캐시 설정은 스테이지의 설정 탭에서 캐시 활성화 체크 후 캐시 TTL(Time to Live)로 설정할 수 있습니다. TTL은 초단위로 설정되며 최대 설정시간은 3600초입니다.

또한 Amazon API Gateway는 GET 파라미터에 대해서만 캐시 기능을 제공하고 있습니다. 해당 파라미터에 따른 캐싱을 하기 위해서는 리소스에서 GET 메서드 요청 쿼리에 쿼리 문자열을 설정 후 API 캐시 활성화 체크박스에 체크합니다. 그리고 반드시 작업 버튼에서 API 배포를 해야 캐시가 설정이 됩니다.

캐시 설정이 되면, 지정한 TTL 시간 동안 해당 고객에게 동일한 모델이 보여지고, 그 기간이 지나거나 해당 영역이 첫 노출된 경우 Amazon API Gateway는 MAB 기능이 구현된 AWS Lambda를 호출하게 됩니다.

3. Amazon API Gateway 매핑 템플릿 추가

AWS Lambda에서 lambda handler 함수가 호출될 때, event 파라미터로 Amazon API Gateway에서 생성한 HTTPS 요청과 세부 정보들을 전달할 수 있습니다. 세부 정보를 AWS Lambda로 전달하기 위해서는 리소스에서 통합요청에 매핑 템플릿에서 추가하여 전달할 수 있습니다.

그러면 사용자가 지정한 파라미터가 AWS Lambda의 event 파라미터로 전달 됩니다. 아래 코드는 AWS Lambda에서 event 파라미터를 활용하는 소스코드 예시입니다.

def lambda_handler(event, context):
        event_param = event["name"]
        return { 
            ‘message’ : event_param
         }

4. Dynamic A/B Test를 위한 AWS Lambda

AWS Lambda에서 이벤트 파라미터 값으로 회원번호와 영역코드를 전달 받아옵니다. 받아온 영역코드를 통해 해당 영역의 실험유형이 온라인 정적 A/B 테스트 인지, MAB 실험인지를 체크합니다. MAB 실험일 경우 모델(Arm)설정과 집계 정보를 읽어와 Dynamic A/B 테스트를 수행하게 됩니다. 집계 정보를 읽어 올 때 bTS에 맞게 알파와 베타 값을 갱신 후, 아래 베타 분포 코드 통해 모델 별 확률을 구하여 최대 값을 갖는 모델을 반환합니다. 결론적으로 모델 A, 모델 B 가 있을 경우에 CTR 이 더 높게 나올 모델을 계산하여, 모델 A 혹은 모델 B를 반환하게 됩니다.

def select_variant(self):
	probs = []
	for v in self.variant_metrics:
		success = v["mab_alpha"]
		failure = v["mab_beta"]
		probs.append(AlgorithmBase.random_beta(1 + success, 1 + failure)) 

	variant_index = AlgorithmBase.argmax(probs)
	
	return (self.variant_metrics[variant_index]["variant_name"], probs )

위 코드를 포함하여 bTS 알고리즘을 활용한 전반적인 구현은 Dynamic A/B Testing for machine learning models with Amazon SageMaker MLOps projects 블로그 내용을 참조했고, AWS의 솔루션즈 아키텍트(SA)와 AI/ML 스페셜리스트 SA가 고객과 협업하여 진행하였습니다.

구현 상세 2: 모델 별 베타분포 파라미터 갱신

롯데ON 사용자들에게 웹/앱 페이지에서 (1) “상품 추천 리스트” 가 보여 지고 (Impression) , (2) 이 “추천 리스트에서 특정 상품을 클릭(Click)” 이 되는 것을 로그로 수집하여, 데이터 전처리 후에 MongoDB 에 저장하는 단계 입니다.

아래 그림과 같이 Apache Spark 기반의 빅데이터 워크로드를 관리형으로 실행할 수 있는 AWS EMR을 사용하여 Spark Job 배치를 주기적으로 수행하여 Amazon S3에 적재된 노출, 클릭, 주문 등 로그를 MongoDB에 노출 수, 클릭 수, CTR 등 실험 수행 및 분석에 필요한 값을 MongoDB 내 업데이트 할 수 있도록 구현하였습니다.

본 단계에서 만들어지는 결과가 MAB에서 활용되는 분포를 결정하는데 핵심적인 역할을 하기 때문에 소스 데이터인 로그 데이터를 가공하고 검증하는 작업은 매우 꼼꼼하게 진행되어야 합니다. 이를 통해 아래 2가지 항목에 대해서 세밀하게 점검을 했습니다.

Impression & Click 데이터
소스 데이터인 로그 데이터에서 실험 영역의 Impression과 Click 데이터가 누락 없이 잘 연결이 되는지 사전에 체크하는 것이 필요합니다. 롯데ON 사용자가 해당 영역을 본 후, 클릭하는 동작이 빠르게 이루어질 때에도 데이터가 잘 수집이 되는지 확인하고 그에 맞게 조치하여, 데이터 분석에 안좋은 영향을 미칠 만한 요소를 사전 제거합니다.

분기 처리 점검
온라인 정적 A/B 테스트로 지정하였을 때, 분기 처리가 일정한 비율(예: 5:5)로 수행되어 정상적으로 노출되고 있는지 집계를 통해 사전 점검해야 합니다. 분기 비율을 반드시 체크해야 공정성이 확보되므로, A/B 테스트를 진행했을 때 결과를 신뢰할 수 있게 됩니다.

구현 상세 3: 비즈니스 지표 모니터링

비즈니스 지표 모니터링 : Streamlit 으로 대시보드 구현 (Amazon EC2)

Dynamic A/B 테스트를 진행하면서 롯데ON 사용자들에게 어떤 모델이 효과적인지 판단할 수 있는 척도를 확인하기 위해서는 비즈니스 지표 모니터링이 필요 합니다. 이를 위해 Amazon EC2 환경에 Streamlit을 설치하여 대시보드를 구축하였습니다.

Streamlit은 데이터 분석과 같은 웹 앱을 쉽게 만들어주는 파이썬 라이브러리 입니다. 대시보드 구성에 필요한 파이썬 패키지 정보들을 requirements.txt에 streamlit ==1.14.1과 같이 추가 후 아래 와 같이 설치해줍니다.

$ python3 -m pip install --upgrade pip
$ pip3 install -r requirements.txt

Streamlit이 제공하는 디폴트 포트는 8501이므로 사용자 지정 TCP 포트 범위 8501로 설정하여 Streamlit 웹 브라우저에 접속 가능하도록 합니다. Amazon EC2는 기본적으로 보안그룹을 통해 외부 접근을 차단하므로 Streamlit을 외부에서 접근하기 위해서는 EC2 인스턴스 세부 정보 내 보안 탭에서 보안그룹의 인바운드 규칙을 편집하여 8501 포트를 외부에서 접근 가능하도록 설정해야 합니다.

해당 설정이 완료되었다면 Streamlit 라이브러리를 추가한 파이썬 코드를 실행하면 됩니다. 실행 방법은 터미널에서 streamlit run pythoncode.py 명령어를 실행하는 것으로 간단하게 웹을 구성할 수 있습니다. 아래는 실행파일 예시입니다.

import streamlit as st

st.title(‘streamlit 예시’)

이렇게 구성한 대시보드의 기능으로는 아래 그림과 같이 시간별 모델의 추이, 일자별 & 실시간 Winner 모델 등 간단한 비즈니스 지표를 모니터링 할 수 있도록 하였습니다.

대시보드를 통해 데이터 과학자는 해당 모델의 비즈니스 지표를 분석하기 위해 들이는 시간을 줄일 수 있으며, 실시간으로 서비스 상황을 확인 가능하고 모델의 버전 갱신 효과에 대한 모니터링과 반복되는 재학습 파이프라인 수행에 따른 서비스 영향도를 확인할 수 있게 되었습니다.

아래는 “두 모델 (EXP-01-APS002-01à 모델 A, EXP-01-NCF-01 à 모델 B) 의 실험 당일의 누적 CTR ”을 확대해서 보여 주고 있습니다. 의미를 해석 해보겠습니다. 모델 A는 고객들에게 29,274 번의 추천리스트의 제공의 기회를 얻었고, 1,972 번의 클릭을 얻어 CTR이 6.7% (1972 / 29274) 얻었습니다.

반면에 모델 B는 7,390 번의 추천 리스트 제공의 기회를 얻었고, 430 번의 클릭을 얻어서 CTR이 5.8% (430 / 7390) 를 얻었습니다. 모델 A는 알파 파라미터(클릭 수, 1972) , 베타 파라미터(비클릭 수, 27,752 [29724 – 1972]) 를, 모델 B는 알파 파라미터(클릭 수, 430), 베타 파라미터(비클릭 수, 6960) 값을 톰슨 샘플링의 핵심 구성요소인 베타분포의 파라미터로 사용하여 분포를 구하게 됩니다. 베타분포 그래프의 봉우리에 해당하는 X축 값이 클수록 더 좋은 성능(CTR)의 모델로 해석이 됩니다.

아래는 모델 A (EXP-01-APS002-01) 가 X축 기준으로 더 오른쪽에 있기에 더 좋은 성능을 보여 주고 있습니다. 이는 위의 CTR 비율 6.7% 와 5.8% 의 결과 와도 일치 합니다.

구현 상세 4: 시스템 운영 모니터링 (Amazon CloudWatch, AWS X-Ray)

Amazon API Gateway의 메뉴 내 로그/추적 탭에서 Amazon CloudWatch 설정 및 사용자 지정 액세스 로깅, AWS X-Ray 추적 기능을 활성화 시킬 수 있습니다.

CloudWatch 설정 및 사용자 지정 액세스 로깅

설정 단계에서 CloudWatch Logs 유형을 변경하여 로깅 수준을 정하고, 세부 지표 활성화 후, 400에러, 500에러 등 세부 지표를 확인할 수 있습니다. 사용자 지정 액세스 로그를 활성화하면, 어떤 IP에서 어떠한 방법으로 API에 액세스 했는지 등을 확인할 수 있습니다.

또한 CloudWatch Logs의 보존기한은 Amazon CloudWatch 페이지에서 별도로 지정해야 무기한 저장하지 않고, 스토리지 관리를 할 수 있습니다.

Amazon CloudWatch 탐색기 리스트 중에서 Amazon API Gateway를 선택하면, API 호출 수, 지연 속도, 캐시 Hit/Miss 수 등을 대시보드로 보는 것이 가능합니다. 아래의 수식과 같이 “캐시 Hit 비율” 을 구하여 대시보드에서 캐시의 효용에 대해서 확인합니다.

캐시 Hit 비율 = CacheHitCount / (CacheHitCount + CacheMissCount)

CloudWatch Logs Insights 메뉴의 로그 그룹을 AWS Lambda로 선택하여, MAB가 수행되는 “AWS Lambda가 반환하는 실제 모델코드를 집계해보면서, 샘플링 로직이 잘 동작하고 분기처리가 잘 수행되고 있는지를 확인”할 수 있었습니다.

fields @timestamp, @message, @logStream, @log
| filter @message like ‘모델A’ or message like '모델B’
| stats count(*) by @message

위 그림의 아래쪽을 보면 LF001-01 모델이 600번, NCF-02 모델이 589번이 람다 함수에서 모델을 제공을 했다는 것을 알 수 있습니다.

AWS X-Ray

AWS X-Ray Trace 기능을 활성화시키면, 활성화시킨 AWS 서비스로부터 AWS X-Ray로 Trace 데이터가 전송되고, Amazon CloudWatch 페이지의 X-Ray섹션의 서비스 맵 메뉴에서 시각화 된 API 서비스 플로우를 모니터링할 수 있습니다.

위 그림과 같이 같이 직관적으로 Amazon API Gateway 아이콘과 AWS Lambda 노드 별로 클릭해가면서 지연속도, 호출 수, HTTP 호출코드 등을 서비스 구간 별로 추적 모니터링 할 수 있어서 편리합니다.

AWS Lambda 함수에 대한 성능 지표는 대부분 일주일 이내에 분석되고, 그 이후에는 활용하지 않기 때문에 장기간 보관할 필요는 없었습니다. AWS X-Ray의 데이터는 기본적으로 30일 간 저장되어 지표를 활용하기에 충분한 기간이므로 별도로 보관주기를 변경하지 않고 사용했습니다. (참조: https://thinkwithwp.com/ko/xray/faqs/)

결론

롯데ON에서 Dynamic A/B 테스트 환경을 어떻게 구축하여 사용하고 있는지에 대해 설명하였습니다. 이번 프로젝트를 통해 롯데ON에서는 Dynamic A/B 테스트를 MAB 기능과 온라인 정적 A/B 테스트를 구성하여 모델의 성능을 다양하게 온라인 테스트할 수 있었습니다. 또한 딥 러닝 모델과 머신러닝 모델에 상관없이 다양한 형태의 추천 모델 비교가 가능하고, 모델의 버전 별로도 비교가 가능하게 설계되어 있기 때문에 다양한 각도로 온라인 테스트가 가능하게 되었습니다.

그 뿐 아니라 시스템 모니터링과 비즈니스 지표도 즉각적으로 확인할 수 있도록 하여 데이터 과학자들이 모델 성능 개선과 훈련에 집중할 수 있게 되었습니다. 이를 토대로 모델 비교 외 영역 자동화 및 상품 리랭킹 등으로 확장 계획에 있으며, 다양한 온라인 테스트로 활용될 수 있을 것으로 기대하고 있습니다. Dynamic A/B Testing 실습은 aws workshop – Dynamic A/B Testing on Amazon Personalize & SageMaker 에서도 확인 해보실 수 있습니다.

이어서 2부에서는 NCF(Neural Collaborative Filtering) 추천 모델을 MLOps 파이프라인으로 구축한 사례를 소개합니다.

AWS 기술 블로그