데이터 분포 시프트에 모델을 적응시키려면 ML 모델을 지속적으로 업데이트해야 한다. 이 장에서는 연속 학습이 무엇이며 어떤 난제가 있는지 알아본다. 그리고 연속 학습을 현실화하기 위한 4단계 계획을 세운다.

이어서 모델을 얼마나 자주 재훈련해야 하는지 알아본다.

모델이 변화하는 환경에 적응하도록 재훈련했다면, 이를 고정 테스트 세트에서 평가하는 것만으로는 충분하지 않다. 따라서 어렵지만 꼭 필요한 개념인 프로덕션 테스트를 다룬다.

프로덕션에서 모니터링과 테스트의 목표는 모델 성능을 이해하고 업데이트 시기를 파악하는 것이다. 그리고 연속 학습의 목표는 업데이트를 안전하고 효율적으로 자동화하는 것이다.

9.1 연속 학습

파괴적 망각(catastrophic forgetting), 훈련 비용 등의 이유로 모델이 프로덕션에서 들어오는 모든 샘플로 스스로를 업데이트하지는 않는다.

프로덕션에서 연속 학습을 사용하는 회사는 모델을 마이크로 배치로 업데이트한다.

업데이트된 모델은 평가가 완료될 때까지 배포해서는 안 된다. 일반적으로 기존 모델을 복제한 후 신규 데이터로 업데이트된 도전자(challenger) 모델과 기존 챔피언(champion) 모델을 비교한 후 배포 여부를 판단한다.

많은 사람이 대부분의 회사에서 모델을 자주 업데이트할 필요가 없다고 주장한다. 재훈련 일정이 타당할 만큼 충분한 트래픽(충분한 신규 데이터)가 없고, 모델 성능이 그렇게 빨리 떨어지지는 않기 때문이다. 재훈련 일정을 더 짧게 잡더라도 수익이 나지 않고 오버헤드가 발생한다면 모델을 자주 업데이트할 필요가 없다.

9.1.1 무상태 재훈련 vs. 상태 유지 훈련

연속 학습은 상태 유지 훈련을 허용함을 의미하며 모델은 신규 데이터로 훈련을 지속한다. 미세 조정(fine-tuning), 증분 훈련(incremental training)이라고도 한다.

상태 유지 훈련을 하면 모델이 더 빠르게 수렴하며 필요한 연산 비용도 훨씬 적다.

기존 데이터를 완전히 저장하지 않는 것도 가능하다.

훈련 빈도 조정이 쉽다.

상태 유지 훈련은 멋진 개념이지만, 모델에 신규 피처나 다른 레이어를 추가하고 싶다면 두 가지 모델 업데이트 유형을 구별해야 한다.

• 모델 반복(Model iteration): 기존 모델 아키텍처에 새로운 피처가 추가되거나 모델 아키텍처가 변경된다.
• 데이터 반복(Data iteration): 모델 아키텍처와 피처는 동일하게 유지되지만 신규 데이터로 모델을 갱신한다.

모델 반복의 경우 구글의 ‘knowledge transfer‘와 오픈 AI의 ‘model surgery’ 같은 기법을 사용해 처음부터 훈련을 우회할 수 있다는 연구 결과가 있다.

9.1.2 연속 학습의 필요성

특별 이벤트로 인해 갑자기 발생하는 시프트에 대응하기 위해서 필요하다.

희귀한 사건에 적응하기 위해 필요하다.

오늘날 ML 프로덕션의 주요 난제인 지속 콜드 스타트(continuous cold start) 문제에는 연속 학습이 도움이 된다. 콜드 스타트 문제는 모델이 과거 데이터 없이 신규 사용자를 예측해야 할 때 발생한다. 지속 콜드 스타트는 신규 사용자뿐 아니라 기존 사용자에게도 발생하는 콜드 스타트를 말한다. 사용자의 기기가 달라지거나, 서비스에 오랫동안 방문하지 않아 보유한 사용자의 과거 데이터가 오래됐을 때 발생한다.

모델을 사용자 방문 세션 내에서 각 사용자에 맞게 조정할 수 있다면 모델은 사용자가 처음 방문했을 때도 정확하고 관련 있는 예측을 수행할 것이다. (틱톡이 대표적인 사례, 틱톡은 연속 학습을 성공적으로 적용해 몇 분 안에 추천 시스템을 각 사용자에 맞게 조정한다.)

연속 학습은 배치 학습의 상위 개념이다. 배치 학습이 할 수 있는 모든 것을 하며 배치 학습만으로는 불가능한 유스 케이스에도 적용이 가능하기 때문이다.

9.1.3 연속 학습의 난제

연속 학습에는 여러 난제가 있다. 주요 난제인 신규 데이터 액세스, 평가, 알고리즘을 살펴보자.

신규 데이터 액세스 난제

신규 데이터를 확보하는 일이다.

데이터 웨어하우스에 저장되기 전에 실시간 전송에서 직접 데이터를 가져오면 최신 데이터에 액세스할 수 있다.

신규 데이터를 가져오는 것만으로는 충분하지 않다. 레이블링된 데이터가 필요한 경우 신규 데이터도 레이블링해야 한다.

짧은 피드백 루프로 자연 레이블을 얻을 수 있는 작업이 연속 학습에 적합하다.

레이블을 추출하기 위해 로그를 다시 살펴보는 프로세스를 레이블 계산이라고 한다.

스트리밍 도구는 아직 초기 단계이므로 효율적인 스트리밍 우선 인프라, 즉 최신 데이터에 액세스하고 실시간 전송에서 빠른 레이블을 추출하기 위한 인프라를 설계하는 일은 엔지니어링 집약적이고 비용이 높다. 좋은 소식은 관련 도구가 빠르게 성장하고 있다는 점이다.

평가 난제

연속 학습의 가장 큰 난제는 모델 업데이트가 모델을 배포하기에 충분한 수준인지 확인하는 일이다.

연속 학습은 파괴적 실패(ex. 소수 집단이 부당하게 대출을 거부 당함, 자동 운전 장치로 운행되는 자동차의 치명적인 충돌 사고)의 리스크를 증폭한다.

연속 학습은 조정된 조작과 적대적 공격에 더 취약하게 만든다(ex. 챗봇 테이 사례).

이러한 사고를 방지하려면 업데이트를 배포하기 전 각 모델 업데이트를 철저히 테스트해 성능과 안정성을 확인해야 한다.

알고리즘 난제

특정 알고리즘은 연속 학습에 적합하지 않다(ex. 협업 필터링).

신경망 모델은 하나의 데이터 샘플에 대해서도 업데이트가 가능하지만 협업 필터링 모델을 업데이트하려면 차원 축소를 수행하기에 앞서 전체 데이터셋을 사용해 사용자-아이템 행렬을 구축해야 한다. 샘플이 너무 크면 차원 축소 단계가 너무 느려 자주 수행하기에는 비용이 높다.

9.1.4 연속 학습의 네 단계

연속 학습의 난제를 극복하고 연속 학습을 수행하는 방법을 알아본다.

1단계: 수동 무상태 재훈련

모델 업데이트 프로세스가 수동이며 임시방편적인 상태이다.

2단계: 자동 재훈련

재훈련 단계를 자동으로 실행하는 스크립트가 존재한다. 스크립트는 스파크 같은 배치 프로세스를 사용해 주기적으로 실행된다.

대부분의 기업이 이 단계에 머물러 있다. 최적의 재훈련 빈도를 결정하기 위해 실험을 진행하기는 하나, 실무자의 직감으로 결정된다.

재훈련 프로세스를 자동화하는 스크립트를 생성할 때는 시스템 내에 있는 각 모델마다 필요한 재훈련 일정이 다르다는 점을 고려해야 한다.

모델 간에 종속성이 있으면 자동화 스크립트가 훨씬 복잡해진다.

요구 사항

스크립트를 작성하는 데 걸리는 시간은 스크립트 작성자의 역량을 비롯한 여러 요인에 따른다.

일반적으로 스크립트의 실행 가능성에 영향을 미치는 주요 요소 세 가지는 스케줄러, 데이터, 모델 스토어이다.

스케줄러: 스케줄러는 기본적으로 작업 스케줄링을 처리하는 도구이다. 스케줄러가 없다면 설정하는 데 시간이 필요하다.

데이터의 가용성과 접근성: 데이터 처리에 복잡성이 증가할수록 스크립트를 설정하는 데 드는 시간이 많다.

모델 스토어: 모델을 재현하는 데 필요한 모든 아티팩트를 자동으로 버전화하고 저장한다.

3단계: 자동 상태 유지 훈련

2단계에서는 모델을 재훈련할 때 매번 처음부터 모델을 훈련한다. 3단계에서는 상태 유지 훈련을 위해 자동 업데이트 스크립트를 재구성한다.

요구 사항

가장 필요한 것은 데이터 및 모델 계보를 추적할 방법이다. 신규 데이터로 업데이트되는 모델, 데이터 버전을 관리하는 일이 중요하다.

스트리밍 인프라가 충분히 성숙하지 않았다면 스트리밍 파이프라인을 변경해야 한다.

4단계: 연속 학습

3단계에서는 설정한 일정에 따라 모델이 업데이트된다.

반면 4단계에서는 업데이트 일정을 고정하는 대신 데이터 분포가 변하고 모델 성능이 떨어질 때마다 모델이 자동으로 업데이트되도록 한다.

최종 목표는 연속 학습과 에지 배포를 결합할 때이다. 디바이스에 있는 모델을 중앙 집중식 서버와 동기화할 필요 없이 환경에 따라 지속적으로 업데이트하고 적응해야 한다.

요구 사항

모델 업데이트를 트리거하는 매커니즘이 필요하다.

• 시간 기반: 예컨대 5분 마다 업데이트한다.
• 성능 기반: 예컨대 모델 성능이 떨어질 때마다 업데이트한다.
• 볼륨 기반: 예컨대 레이블링된 데이터 총량이 5% 증가할 때마다 업데이트한다.
• 드리프트 기반: 예컨대 주요 데이터 분포 시프트가 감지될 때마다 업데이트한다.

이러한 매커니즘이 작동하기 위해서 견고한 모니터링 솔루션이 필요하다. 이때 어려운 부분은 드리프트를 감지하는 일이 아니라 어느 드리프트가 중요한지 결정하는 일이다.

모델 업데이트를 지속적으로 평가하려면 견고한 파이프라인이 필요하다.

9.1.5 모델 업데이트 빈도

모델을 신규 데이터로 업데이트했을 때 성능이 얼마나 향상되는지 파악해야 한다. 성능 향상이 클수록 자주 재훈련해야 한다.

신규 데이터의 가치

성능 향상을 파악하는 한 가지 방법은 과거 여러 시간대의 데이터로 모델을 훈련하고 현재 시점 데이터로 평가해 성능이 어떻게 변하는지 확인하는 것이다.

정교한 ML 인프라를 갖춘 회사는 재훈련 파이프라인 주기를 몇 분 단위로 전환할 만큼 충분한 성능 향상을 발견했다.

모델 반복 vs. 데이터 반복

데이터 반복으로도 성능이 크게 향상되지 않는다면 더 나은 모델을 찾는 데 자원을 사용해야 한다. 반면 더 나은 아키텍처를 찾기 위해 연산 자원을 100배 사용하는데 성능이 단 1%만 향상되는 한편, 지난 3시간 데이터로 동일 모델을 업데이트하기 위해 연산 자원을 1배만 사용하고 성능이 똑같이 1% 향상된다면 데이터를 반복하는 편이 좋다.

9.2 프로덕션에서 테스트하기

오프라인 평가의 주요 테스트 유형은 테스트 분할과 백테스트가 있다.

모델이 신규 데이터 분포에 맞게 업데이트된 경우, 기존 테스트 데이터로 평가하는 것은 충분하지 않다. 현재 분포에서 추출될 가능성이 더 높다고 가정할 때, 액세스할 수 있는 가장 최근 데이터로 모델을 평가하는 것이 낫다. 이렇듯 과거 특정 기간의 데이터(ex. 직전 1시간의 데이터)로 예측 모델을 테스트하는 방법을 백테스트라고 한다.

데이터 분포는 시간이 지나면서 변화할 수 있으므로, 모델이 지난 시간의 데이터로 잘 작동한다고 해서 향후 데이터로도 계속해서 잘 작동한다는 의미는 아니다. 모델이 프로덕션 환경에서 잘 작동하는지 알 수 있는 유일한 방법은 모델 배포이다. 이는 매우 번거롭지만 필수적인 개념인 프로덕션 테스트로 이어진다. 관련하여 섀도 배포, A/B 테스트, 카나리 배포, 인터리빙 실험, 밴딧을 알아본다.

9.2.1 섀도 배포(shadow deployment)

모델 혹은 소프트웨어 업데이트를 배포하는 가장 안전한 방법이며 다음과 같이 작동한다.

1. 기존 모델과 병렬로 후보 모델을 배포한다.
2. 들어오는 요청을 두 모델로 라우팅해 예측하되 기존 모델의 예측 결과만 사용자에게 제공한다.
3. 분석을 위해 새 모델의 예측 결과를 기록한다.
4. 새 모델의 예측 결과가 만족스러울 때만 기존 모델을 새 모델로 교체한다.

다만 비용이 단점이다.

9.2.2 A/B 테스트

A/B 테스트는 한 객체의 두 가지 변형을 비교하는 방법으로, 일반적으로 두 변형에 대한 응답을 테스트하고 둘 중 어느 것이 더 효과적인지 결정한다. 사전 정의된 몇 가지 지표에 따라 어떤 모델이 더 나은지 판단한다.

A/B 테스트는 다음과 같이 작동한다.

1. 기존 모델과 함께 후보 모델을 배포한다.
2. 트래픽 중 일정 비율을 새 모델로 라우팅하고 나머지 트래픽은 기존 모델로 라우팅한다. 일반적으로 두 변형이 동시에 예측 트래픽을 처리하지만 때때로 한 모델의 예측 결과가 다른 모델의 예측 결과에 영향을 미치기도 한다. 이럴 때는 변형을 번갈아 실행해야 한다.
3. 두 모델의 예측 결과와 사용자 피드백(있다면)을 모니터링하고 분석해 두 모델의 성능 차이가 통계적으로 유의한지 확인한다.

A/B 테스트는 무작위 실험으로 구성되야 한다. 각 모델로 라우팅되는 트래픽이 무작위여야만 한다.

충분한 신뢰도를 얻기 위해 테스트가 실행되는 샘플 수가 충분해야 한다.

알파는 귀무가설이 참인데 기각할 확률(1종 오류), 베타는 귀무가설이 거짓인데 채택할 확률(2종 오류)

A/B 테스트와 기타 통계 개념을 자세히 알고 싶다면 마이클 바버의 블로그를 읽어보기를 추천한다.

9.2.3 카나리 배포(Canary Release)

신규 소프트웨어 버전을 프로덕션 환경에 도입할 때 위험을 줄이는 기술로, 변경 사항을 전체 인프라에 롤아웃해 모든 사용자가 사용하기 전에 소수의 사용자에게 천천히 롤아웃한다.

다음과 같이 작동한다.

1. 기존 모델과 함께 후보 모델을 배포한다. 후보 모델을 카나리라고 한다.
2. 일부 트래픽은 후보 모델로 라우팅한다.
3. 성능이 만족스러우면 후보 모델에 라우팅하는 트래픽을 늘린다. 만족스럽지 않다면 카나리를 중단하고 모든 트래픽을 기존 모델로 다시 라우팅한다.
4. 카나리가 모든 트래픽을 처리하거나(기존 모델을 대체하거나) 카나리가 중단되면 중지한다.

꼭 트래픽을 무작위화할 필요는 없다. 덜 중요한 시장에 후보 모델을 먼저 롤아웃하는 것도 괜찮다.

카나리 배포 관련 넷플릭스와 구글이 공동으로 기고한 블로그 글을 참조하면 업계에서 카나리 배포를 어떻게 사용하는지 확인할 수 있다.

9.2.4 인터리빙 실험

두 가지 추천 시스템 모델을 비교하는 상황을 가정해보자. 인터리빙 실험은 사용자에게 두 모델의 추천 사항을 모두 노출하고 어떤 모델의 추천 사항을 선택하는지 확인하는 방법이다. 실제 사용자 선호도를 기반으로 모델을 선택한다.

사용자 선호도가 더 나은 핵심 지표로 이어진다는 보장은 없다.

여러 모델의 추천 사항을 표시할 때 추천 사항의 위치가 클릭 여부에 영향을 미친다는 점을 유의해야 한다.

9.2.5 밴딧(bandit)

밴딧 알고리즘은 도박에서 유래했다. 카지노에는 지급액이 각기 다른 여러 슬롯머신이 있다. 슬롯머신은 원-암드 밴딧이라고도 하므로 그 이름을 따왔다.

어느 슬롯머신이 가장 높은 보상을 주는지는 모른다. 따라서 여러 번의 실험을 통해 슬롯머신의 보상을 최대화하는 동시에 어떤 슬롯머신이 가장 좋은지 알아낸다. 멀티-암드 밴딧은 활용(exploitation, 과거에 보상을 가장 많이 준 슬롯머신 선택)과 탐색(exploration, 향후 보상을 더 많이 줄 수 있는 다른 슬롯머신 선택) 사이에서 균형을 맞추는 알고리즘이다.

평가할 모델이 여러 개일 때 각 모델은 보상(ex. 예측 정확도)를 모르는 슬롯머신처럼 생각할 수 있다. 밴딧을 사용하면 예측을 위해 트래픽을 각 모델로 라우팅해 최상의 모델을 결정하는 동시에, 사용자에 대한 예측 정확도를 최대화하는 방법을 결정한다. 밴딧은 상태 유지이다. 요청을 모델로 라우팅하기 전에 모든 모델의 현재 성능을 계산해야 한다. 이때 다음 세 가지가 필요하다.

• 모델이 온라인 예측을 수행할 수 있어야 한다.
• 짧은 피드백 루프가 바람직하다. 예측이 좋은지 아닌지에 대한 피드백을 받아야 한다. 피드백 루프가 짧으면 각 모델의 보상을 빠르게 업데이트할 수 있다.
• 피드백을 수집하고, 각 모델 성능을 계산 및 추적하고, 현재 성능을 기반으로 다른 모델에 예측 요청을 라우팅하는 매커니즘이 필요하다(널리 사용되는 알고리즘으로는 톰슨 샘플링과 신뢰 상한(UCB)가 있다).

밴딧은 학계 연구를 통해 A/B 테스트보다 훨씬 더 데이터 효율적인 것으로 나타났다. 보다 자세한 내용은 넷플릭스 기술 블로그의 링크드인/넷플릭스/페이스북/드롭박스 발표 자료, 질로우 기술 블로그 글 그리고 스티치 픽스 기술 블로그 글을 참조하기 바란다.

탐색 전략으로서의 컨텍스트 밴딧

모델 평가를 위한 밴딧이 각 모델의 보상(예측 정확도)을 결정한다면, 컨텍스트 밴딧은 각 행동의 보상을 결정한다. 추천 및 광고에서 행동은 사용자에게 보여줄 아이템 및 광고이며 사용자가 클릭할 확률이 얼마나 되는지에 따라 보상이 결정된다.

컨텍스트 밴딧 알고리즘은 사용자가 좋아할 아이템을 보여주는 것과 피드백을 원하는 아이템을 보여주는 것 사이에서 균형을 유지하는 데 도움이 된다.

컨텍스트 밴딧은 오랫동안 연구됐으며 모델 성능을 크게 향상하는 것으로 나타났다.

하지만 탐색 전략은 ML 모델 아키텍처에 따라 달라지므로 컨텍스트 밴딧은 모델 밴딧보다 구현하기 훨씬 더 어렵다.

9.3 정리

변화하는 데이터 분포에 적응하기 위해 프로덕션 환경에서 모델을 지속적으로 업데이트하는 방법을 다뤘다.

모델 업데이트 빈도에 대해 논의했다.

연속 학습에는 성숙한 스트리밍 인프라가 필요하다. 연속 학습의 훈련 부분은 배치 단위로 수행할 수 있지만 온라인 평가 부분에서 스트리밍이 필요하다.