실시간(Real-time) 머신 러닝: challenges and solutions

원문: Real-time machine learning: challenges and solutions
원글: January 2, 2022 9:00 AM
번역: January 23, 2022

---

요약 🔗

• Online Prediction 향하는 단계 설명
  • 1단계 Batch prediction: 예측 결과를 저장하고 서빙
  • 2단계 Batch features + Online Prediction: item의 임베딩을 미리 생성하고, 이벤트가 발생하면 해당 이벤트의 임베딩을 조회하고 모델 입력으로 사용하여 실시간 예측 실행(=Session Based 예측)
  • 3단계 Complex streaming + batch features를 사용한 Online prediction: 미리 계산된 Batch feature(ex, 과거 이 식당의 평균 준비 시간 )와 실시간으로 변하는 스트리밍 데이터(ex, 이 순간 얼마나 많은 다른 주문이 있는지)를 활용하여 온라인 예측 실행
• Bandits을 사용하면 AB Test보다 더 효율적으로 온라인 모델을 평가 할 수 있음
• Continual Learning으로 향하는 단계 설명
  • 1단계 Manual, Stateless Retraining: 수동으로 모델을 처음부터 다시 학습
  • 2단계 Automated Retraining: 고정된 일정(개발자 직감으로 설정) + 자동 + 모델을 처음부터 다시 학습
  • 3단계 Automated, Stateful Training: 고정된 일정(개발자 직감으로 설정) + 자동 + 신규 데이터만 모델을 이어서 학습
  • 4단계 Continual Learning: 모델 성능이 저하 되거나, 데이터 분포 변화가 확인되면 자동으로 신규 데이터만 모델을 이어서 학습 (모델 학습 트리거 메커니즘 개선)
• Log and wait (Feature Reuse) 서빙 입력에 사용한 데이터를 저장해서 훈련에서 다시 사용하는 방식
• Stream processing 와 Batch processing의 효율성 비교
  • 스트림 처리의 강점은 stateful, continuous 및 unbounded data processing에 있음. 적절하게 사용하면 Stateless Batch 처리에 비해 비용이 적게 드는 경우가 있음
  • 단, 스트림 처리는 대규모 bounded data 처리에 최적화되어 있지 않으며 대용량 historical 데이터 처리(예: backfill)에서는 성능이 현저히 떨어짐

---

[ 트위터 토론 , LinkedIn ]

1년 전 저는 머신 러닝이 실시간으로 진행 되는 방식에 대한 게시물을 작성했습니다. 이 게시물은 많은 데이터 과학자들의 고충을 포착했을 것입니다. 게시물 이후에 많은 회사들이 저에게 연락하여 고충을 공유하고 파이프라인을 실시간으로 이전하는 방법에 대해 논의했기 때문입니다. 이러한 대화를 통해 저는 실시간 머신 러닝 기반 회사를 시작하게 되었습니다. 여러분과 공유하고 싶은 흥미진진한 소식이 있습니다. 하지만 그건 다른 시간을 위한 이야기입니다 :-)
작년에 저는 다양한 산업 분야의 ~30개 회사와 실시간 머신 러닝의 문제점에 대해 이야기했습니다. 또한, 저는 해결책을 찾기 위해 꽤 많은 사람들과 협력했습니다. 이 게시물은 (1) 온라인 예측 및 (2) 지속적인 학습을 위한 솔루션을 설명하며 각 레벨에 필요한 단계별 사용 사례, 고려 사항 및 기술을 제공합니다.

경험에 따라 일부 단계는 기본적으로 보일 수 있습니다. 건너뛰어도 괜찮습니다 !

또한, 보다 정확한 관점을 위해 귀사의 ML 워크플로에 대해 자세히 알고 싶습니다. 다음은 5분 설문조사 링크 입니다. 결과는 집계후 요약되어 커뮤니티와 공유됩니다. 감사합니다!

Online Prediction을 향하여 🔗

Continual learning이 주류로 채택되기까지는 아직 몇 년이 남았다고 생각하지만 온라인 추론으로 전환하기 위해 기업에서 상당한 투자를 하고 있습니다. 이 글에서 우리는 배치 피쳐를 사용하는 심플한 온라인 시스템을 위해서 어떤 것들이 필요한지 논의할 것 입니다. (e.g. 웹사이트나 모바일 앱에서 유저 활동 내역을 기반한 유저 예측 제공). 그런 다음 복잡한 스트리밍 + Batch 피쳐 모두를 활용하는 보다 성숙한 온라인 예측 시스템으로 이동하는 방법에 대해 계속 논의할 것입니다.

1단계. Batch prediction 🔗

이 단계에서 모든 예측은 Batch 처리로 미리 계산되어 특정 간격(예: 4시간마다 또는 매일)마다 생성됩니다. Batch 예측의 일반적인 사용 사례는 collaborative filtering, content-based 추천입니다. Batch 예측을 사용하는 회사의 예시로는 DoorDash의 레스토랑 추천, Reddit의 서브레딧 추천, 2021년경 Netflix의 추천 시스템 등이 있습니다. 이 게시물을 기준으로 Netflix는 예측을 온라인으로 옮기고 있습니다.

Batch 예측에는 이전 게시물에 설명된 대로 많은 제한 사항이 있습니다. 여기에서 한 가지 예를 빠르게 살펴보고자 합니다. 방문자의 절반이 신규 사용자이거나 로그인하지 않는 e-커머스 사이트라고 생각해보세요. 이러한 방문자들은 신규 방문자이기 때문에 미리 계산된 개인화 추천 결과가 없습니다. 다음 추천 Batch가 생성될 때 이 신규 방문자는 관련 항목을 찾지 못했기 때문에 구매하지 않고 이미 떠났을 수 있습니다.

일반적인 Batch 예측 워크플로

Batch 예측은 온라인 예측의 전제 조건이 아닙니다. Batch 예측은 대부분 레거시 시스템의 산물입니다.

지난 10년 동안 빅 데이터 처리는 MapReduce 및 Spark와 같은 Batch 시스템에 의해 지배되었으며, 이를 통해 대량의 데이터를 매우 효율적으로 주기적으로 처리할 수 있습니다. 기업에서 기계 학습을 시작할 때 기존 Batch 시스템을 활용하여 예측을 수행했습니다.

💡 지금 새로운 ML 시스템을 구축하고 있다면 온라인 예측으로 바로 시작할 수 있습니다.

2단계. Batch features 사용한 Online Prediction 🔗

이 단계의 회사는 요청이 도착하기 전에 예측을 생성하는 대신 요청이 도착한 후에 예측을 생성합니다. 그들은 앱에서 실시간으로 사용자의 활동을 수집합니다. 그러나 이러한 이벤트는 세션 임베딩을 생성하기 위해 미리 계산된 임베딩을 조회하는 데만 사용됩니다. 스트리밍 데이터에서 실시간으로 계산되는 피쳐는 없습니다.

이전 단계의 동일한 e-커머스 웹사이트 예시를 생각하십시오. 새로운 방문자가 웹사이트를 방문하면 모두에게 일반적인 항목을 제안하는 대신 사용자의 활동을 기반으로 항목을 표시한다면 어떻겠습니까? 예를 들어, 키보드와 컴퓨터 모니터를 본 적이 있다면 재택근무 환경 셋팅을 보고 있을 가능성이 높으므로, 알고리즘은 HDMI 케이블이나 모니터 받침대와 같은 관련된 항목을 추천해야 합니다.

그렇게 하려면 이 방문자의 활동이 발생하는 대로 수집하고 처리해야 합니다. 이 방문자가 항목 1, 항목 10 및 항목 20을 본 경우 데이터 웨어하우스에서 항목 1, 10 및 20에 대한 임베딩을 가져옵니다. 이 임베딩들은 결합(예: 평균)되어 이 방문자의 현재 세션 임베딩이 됩니다.

이 세션 임베딩과 가장 관련성이 높은 아이템을 찾고 싶습니다. 단순하게(Naively) 사이트에 있는 모든 항목의 순위(ranking)를 지정하고 방문자에게 가장 높은 점수를 받은 항목을 표시하는 모델을 만들 수 있습니다. 그러나 사이트에 수백만 개의 항목이 있을 수 있고, 모든 항목의 점수를 매기는 데 너무 오래 걸릴 수 있습니다. 나는 방문자가 추천을 보기 위해 영원히 기다리지 않기를 바랍니다. 대부분의 회사는 item-item collaborative filtering 및 k-nearest neighbors과 같은 다른 알고리즘을 사용하여 점수를 매길 소수의 후보(candidate) 항목(예: 1000개)을 생성합니다. 이러한 후보 항목 생성 프로세스를 "candidate generation" 또는 "retrieval"이라고 합니다. 관심 있는 독자는 Eugene Yan의 session-based recommendations 와 Google’s free crash course를 확인하십시오.

세션 기반 추천을 위한 예시 파이프라인

item 임베딩은 랭킹 모델과 별도로 또는 함께 학습할 수 있습니다. 개별적인 경우 시스템은 임베딩 학습용, 검색용, 랭킹용등 3개 이상의 모델로 구성됩니다.

여기에서 온라인 예측 2단계를 설명하기 위해 추천 시스템을 예로 들었지만, 광고 CTR, 모든 검색 작업을 포함한 다른 작업에도 적용될 수 있습니다.

세션 기반 예측의 목표는 전환(conversion, 예: 최초 방문자를 신규 사용자로 전환) 클릭률 및 리텐션을 높이는 것 입니다.

Netflix, YouTube, Roblox, Coveo 등을 포함하여 이미 온라인 추론을 수행 중이거나 2022년 로드맵에 온라인 추론을 포함한 회사가 늘어나고 있습니다. Online Inference를 적용한 모든 회사에서 나에게 기존 메트릭보다 좋아졌다고, 나에게 행복하게 말했습니다. 나는 앞으로 2년 동안 대부분의 추천 시스템이 session-based가 될 것으로 예상합니다. 모든 클릭, 뷰, 거래는 (거의) 실시간으로 신선(fresh)하고 관련성 있는 추천을 생성하는 데 사용될 수 있습니다.

요구 사항

이 단계에서는 다음을 수행해야 합니다.

1. Batch 예측에서 Session-based 예측으로 모델을 업데이트

   새 모델을 추가해야 할 수도 있음을 의미합니다. 담당 팀: 데이터 과학/ML.

2. Session 데이터를 Prediction 서비스에 적용

   일반적으로 다음 두 가지 요소로 구성된 스트리밍 인프라를 사용하여 이 작업을 수행할 수 있습니다.

   • 스트리밍 전송 (예: Kafka/AWS Kinesis/GCP Dataflow), 스트리밍 데이터(사용자 활동 정보)를 전송(transfort). 대부분의 회사는 관리형 실시간 전송 서비스를 사용합니다. 자체적으로 Kafka를 서비스 하는 것은 매우 어렵습니다.
   • 스트리밍 계산(computation) 엔진 (예: Flink SQL, KSQL, Spark Streaming), 스트리밍 데이터 처리(Processing). In-session adaption 경우 스트리밍 계산 엔진은 사용자의 활동을 세션으로 나누고, 각 세션 내에서 정보를 추적하는 역할을 합니다(State keeping; 상태 유지). 앞서 언급된 세 가지 스트리밍 계산 엔진 중 Flink SQL과 KSQL은 업계에서 더 인정받고 있으며 데이터 과학자에게 멋진 SQL 추상화를 제공합니다.

많은 사람들은 예측을 Batch으로 처리하는 것이 예측을 하나씩 처리하는 것보다 효율적이기 때문에 Online 예측이 Batch 예측보다 비용 및 성능 면에서 비효율 적이라고 생각합니다. 이것은 이 글의 부록에서 논의 된 것처럼 반드시 사실은 아닙니다.

온라인 예측을 사용하면 사이트를 방문하지 않는 사용자에 대한 예측을 생성할 필요가 없습니다. 사용자의 2%만 매일 로그인하는 앱을 생각해 보세요. 실제 예를 들어, 2020년에 Grubhub의 사용자는 3,100만 명 이었고 일일 주문 은 622,000 건 이었습니다 .

매일 모든 사용자에 대한 예측을 생성하면 예측의 98%는 계산 낭비가 됩니다.

회사에서 이미 로깅을 위해 스트리밍을 사용하는 경우 이 변경 사항이 너무 급격하게 진행하지 않아야 합니다. 이는 스트리밍 인프라에 더 많은 워크로드를 부과할 수 있으며, 더 효율적이고 확장 가능하도록 인프라를 업그레이드해야 할 수도 있습니다.

담당 팀: 데이터/ML 플랫폼.

**참고 사항 : 내가 이야기한 소수의 사람들은 예측을 위해 스트리밍 인프라를 활용하는 시스템을 지칭하기 위해 "streaming prediction"라고 부르며, 그렇지 않은 시스템을 지칭하기 위해 "online prediction"이라고 합니다. 이 게시물에서 "온라인 예측"은 "스트리밍 예측"을 포함합니다.

Challenges

이 단계의 과제는 다음과 같습니다.

• Inference latency

  : Batch 예측을 사용하면 추론 지연에 대해 걱정할 필요가 없습니다. 그러나 온라인 예측에서는 Inference latency가 중요합니다.

• 스트리밍 인프라 셋팅

  : 많은 엔지니어들은 스트리밍에 대한 도구가 성숙하고 있음에도 불구하고 스트리밍에서 SQL과 같은 Join을 수행하는 것을 여전히 두려워 합니다.

• 고품질 임베딩 생성, 특히 다양한 항목의 유형을 다루는 경우

3단계. Complex streaming + batch features를 사용한 Online prediction 🔗

• Batch 피쳐는 Batch 처리를 통해 과거 데이터에서 추출된 피쳐입니다. 정적(Static) 피쳐 또는 기록(historical) 피쳐이라고도 합니다.
• Streaming 피쳐는 스트리밍 데이터에서 추출한 피쳐로, 종종 스트림 처리(processing)을 사용합니다. 동적(Dynamic) 피쳐 또는 온라인 피쳐 라고도 합니다.

2단계에 있는 회사는 스트림 처리가 거의 필요하지 않지만, 3단계의 회사는 훨씬 더 많은 스트리밍 피쳐을 사용합니다. 예를 들어, Doordash에서는 사용자 주문한 후, 배달 시간을 예측(estimate)하기 위해 다음 피쳐가 필요할 것 입니다.

• Batch features: 과거 이 식당의 평균 준비 시간
• Streaming features: 이 순간, 얼마나 많은 다른 주문이 있는지, 얼마나 많은 배달 사람이 사용 가능한지

2단계에서 논의한 session-based 추천의 경우, 3단계에서는 item 임베딩만 사용하여 세션 임베딩을 생성하는 대신, 사용자가 지난 24시간 동안 사이트에서 보낸 활동 시간, 항목 구매 횟수와 같은 스트림 피쳐를 사용할 수 있습니다.

스트리밍 피쳐 및 Batch 피쳐을 통한 온라인 예측

Stripe, Uber, Faire 같은 회사들의 사기 감지, 신용 점수 예측, 운전 및 배달 시간 추정, 추천 시스템 등이 3단계의 대표적인 사용 예시 입니다.

각 예측에 대한 스트림 피쳐의 수는 수천은 아니더라도 수백이 될 수 있습니다. 스트림 피쳐 추출 로직에는 서로 다른 차원(dimensions)을 따라 join 및 aggregation이 포함된 복잡한 쿼리가 필요할 수 있습니다. 이러한 피쳐을 추출 하려면 효율적인 스트림 처리 엔진이 필요합니다.

요구 사항

ML 워크플로를 이 단계로 이동하려면 다음 요소가 필요합니다.

1. 모든 스트리밍 피쳐을 허용 가능한 지연 시간(acceptable latency)안에 계산할 수 있는 효율적인 스트림 처리 엔진을 갖춘 성숙한 스트리밍 인프라. 다음 요청이 도착하기 전에, 스트리밍에서 요청을 받아와 예측을 충분히 빠르게 처리할 수 있어야 합니다.
2. 피쳐 저장소(feature store) 구체화된(materialized) 피쳐 관리를 통해 훈련 및 예측 동안 스트리밍 피쳐 일관성 보장해야 합니다. 참고: 현재 피쳐 저장소는 구체화된 스트리밍 피쳐을 관리하지만 피쳐 계산이나 피쳐에 대한 소스 코드는 관리하지 않습니다 .
3. 모델 저장소. 스트림 피쳐를 만든 후에는 유효성 검사를 해야 합니다. 새 피쳐가 실제로 모델의 성능에 도움이 되도록 하려면 새 피쳐를 모델에 추가하여 새 모델을 효율적으로 생성해야 합니다. 이상적으로는 모델 저장소가 새로운 스트리밍 피쳐로 생성된 모델을 관리하고 평가하는 데 도움이 되어야 하지만 모델을 평가하는 모델 저장소는 아직 존재하지 않습니다. 이 중 일부 역할을 피쳐 저장소에 잠재적으로 위임할 수 있습니다.
4. 더 나은 개발 환경을 선호합니다. 데이터 과학자는 현재 스트리밍 피쳐가 생성되고 있음에도 과거(historical) 데이터를 사용하여 일하고 있다면, 새로운 스트리밍 피쳐을 제안하고 검증하기가 어렵습니다. 데이터 과학자들이 새로운 스트림 피쳐를 사용하여 빠르게 실험하고 검증할 수 있도록 데이터 스트림에 대한 직접 액세스 권한을 부여할 수 있다면 어떨까요? 데이터 과학자가 과거 데이터에만 액세스하는 대신 노트북에 바로 들어오는 데이터 스트림에도 액세스할 수 있다면 어떨까요?

토론: bandits 과 contextual bandits에 대한 온라인 예측 🔗

온라인 예측을 사용하면 모델이 보다 정확한 예측을 할 수 있을 뿐만 아니라 온라인 모델 평가 및 예측 생성을 위한 탐색 전략을 위한 bandits를 사용할 수 있습니다. 이는 A/B 테스팅보다 더 흥미롭고 강력합니다.

이러한 익숙하지 않은 bandit 알고리즘은 도박에서 시작되었습니다. 카지노에는 지불금이 다른 여러 슬롯 머신이 있습니다. 슬롯 머신은 one-armed bandit으로도 알려져 있으므로 여기서 이름을 따왔습니다. 어떤 슬롯 머신이 가장 높은 지불금을 제공하는지 모릅니다. 당신은 지불금을 최대화려면 어떤 슬롯 머신이 가장 좋은지 알아보기 위해 시간이 지남에 따라 실험할 수 있습니다.

Multi-armed bandits는 exploitation(과거에 가장 많은 비용을 지불한 슬롯 머신 선택)과 exploration(더 많은 비용을 지불할 수 있는 다른 슬롯 머신 탐색) 사이의 균형을 맞출 수 있는 알고리즘입니다.

모델 평가를 위한 Bandits 🔗

현재 업계의 온라인 모델 평가 기준은 A/B 테스팅입니다. A/B 테스트는 예측을 위해 트래픽을 각 모델에 무작위로 라우팅하고, 어떤 모델이 더 잘 작동하는지 측정합니다.

A/B 테스트는 stateless 입니다. 현재 성능에 대해 알 필요 없이 각 모델에 트래픽을 라우팅 합니다. Batch 예측으로도 A/B 테스팅을 할 수 있습니다.

평가할 모델이 여러 개인 경우 각 모델은 지불금(payout, 예: 예측 정확도)이 얼마인지 모르는 상태의 슬롯 머신으로 간주할 수 있습니다. Bandits를 사용하면 사용자에게 표시되는 잘못된 예측을 최소화하면서 최상의 모델을 결정하기 위해 어떻게 트래픽을 각 모델로 라우팅 해야할지 결정할 수 있습니다.

Bandits는 stateful입니다. 요청을 모델로 라우팅하기 전에 모든 모델의 현재 성능을 계산해야 합니다.

Bandits은 학계에서 잘 연구되었으며 A/B 테스트보다 데이터 효율성이 훨씬 높은 것으로 나타났습니다. 많은 경우에 Bandits은 최적의 방법이기도 합니다.

Bandits은 어떤 모델이 가장 좋은지 결정하는 데 필요한 데이터가 적으며, 동시에 트래픽을 더 나은 모델로 더 빠르게 라우팅하므로 기회 비용이 줄어듭니다.

구글의 Greg Rafferty의 이 실험에서 A/B 테스트는 630,000개의 필요한 샘플을 통해 95%의 신뢰 구간을 얻을 수 있었습니다 . 그러나 간단한 Bandits 알고리즘 (톰슨 샘플링)은 특정 모델이 다른 모델보다 5% 더 나은 것을 결정하는데 12,000개 이하의 샘플이 필요했습니다.

LinkedIn, Netflix, Facebook, Dropbox 및 Stitch Fix의 Bandits에 대한 토론을 참조하세요. 보다 이론적인 관점은 강화 학습 책 (Sutton & Barton, 2020)의 2장을 참조하십시오.

요구 사항

모델 평가를 위해 bandits를 수행하려면 시스템에서 다음 세 가지 요구 사항이 필요합니다.

1. 온라인 예측

2. 짧은 피드백 루프를 선호합니다. 모델의 현재 성능을 계산하려면 모델의 예측이 좋은지 아닌지에 대한 피드백을 받아야 합니다. 피드백은 예측을 위한 레이블을 추출하는 데 사용됩니다.

   짧은 피드백 루프가 있는 작업의 예는 추천 시스템과 같이 사용자의 피드백에서 레이블을 결정할 수 있는 작업입니다. 사용자가 추천을 클릭하면 좋은 추천 예측입니다. 피드백 루프가 짧으면 각 모델의 성능을 빠르게 업데이트할 수 있습니다. 루프가 길어도 여전히 Bandits을 할 수 있지만 사용자에게 추천을 한후 모델의 성능을 업데이트하는 데 시간이 더 오래 걸립니다.

3. 피드백을 수집하고, 각 모델의 성능을 계산 및 추적하고, 현재 성능을 기반으로 다른 모델로 예측 요청을 라우팅하는 메커니즘입니다.

이러한 요구 사항 때문에 밴딧은 A/B 테스트보다 구현하기가 훨씬 더 어렵습니다. 따라서 산업에서는 일부 대형 기술 회사 이외에 널리 사용 되지는 않습니다.

탐색 전략(Exploration Strategy)으로서의 Contextual(상황별) Bandits 🔗

모델 평가를 위한 Bandit의 경우 각 모델의 지불금(payout, 예: 예측 정확도)을 결정하지만, Contextual Bandits은 각 액션의 지불금을 결정합니다. 추천의 경우 액션은 사용자에게 보여줄 항목이고 지불금은 사용자가 클릭할 가능성입니다.

면책 조항 : 일부 사람들은 모델 평가를 위해 bandits를 "contextual bandits"라고 부르기도 합니다. 이것은 대화를 혼란스럽게 만들 수 있으므로 이 글에서의 Contextual *Bandits은 예측의 지불금을 결정하기 위한 탐색 전략을 말합니다.*

이를 설명하기 위해 10,000개 항목에 대한 추천 시스템을 고려하십시오. 매번 사용자에게 10개의 항목을 추천할 수 있습니다. 10개의 표시된 항목은 사용자의 피드백을 받습니다(클릭 여부). 그러나 다른 9,990개 항목에 대한 피드백은 받지 못했습니다.

사용자에게 클릭할 가능성이 가장 높은 항목만 계속 표시한다면, 인기 있는 항목만 표시하고 덜 인기 있는 항목에 대해서는 피드백을 받지 못하는 피드백 루프에 빠질 것 입니다.

Contextual Bandits은 상황별(context) 정보를 활용하여 사용자에게 그들이 좋아할 항목을 노출하는 것(exploitation)과 아직 많이 알지 못하는 항목을 표시하는 것(exploration) 사이의 균형을 유지하면서 차선책 액션의 비용을 최소화합니다.

Contextual bandits은 잘 연구되었으며 모델의 성능을 크게 향상시키는 것으로 나타났습니다(Twitter, Google 보고서 참조). 그러나, 탐색(exploration) 전략은 ML 모델의 아키텍처(예: decision tree인지 neural network인지 여부)에 따라 달라지므로 use-case 전반에 걸쳐 일반화할 수 없기 때문에 contextual bandits은 Model bandits보다 구현하기가 훨씬 더 어렵습니다.

Continual Learning(지속적인 학습)을 향하여 🔗

지속적인 학습을 들을 때 사람들은 5분마다 매우 자주 모델을 업데이트하는 것을 상상합니다. 많은 사람들은 다음과 같은 이유로 대부분의 회사에서는 모델 업데이트를 자주 할 필요없다고 주장합니다.

1. 그들은 retraining 스케쥴링이 필요를 이해할 수 있는 트래픽이 없습니다.
2. 그들의 모델은 그렇게 빨리 성능 저하(decay)되지 않습니다.

나는 그들에게 동의합니다. 그러나 Continual Learning은 재훈련 빈도가 아니라 모델이 재훈련되는 방식(manner)에 관한 것 입니다.

대부분의 회사에서는 stateless retraining을 수행 합니다. 모델은 매번 처음부터 훈련됩니다. 지속적인 학습은 stateful training을 ****허용하는 것을 의미 합니다. 모델은 새 데이터에 대해서만 훈련을 이어서 합니다 (fine-tuning).

한번 stateful training을 수행하도록 인프라가 설정되면 교육 빈도는 간단히 수정하면 됩니다. 한 시간에 한 번, 하루에 한 번 모델을 업데이트하거나 시스템이 분포 이동을 감지할 때마다 모델을 업데이트할 수 있습니다.

모델 업데이트에는 두 가지 유형이 있습니다.

• Model iteration

  : 기존 모델 아키텍처에 새로운 피쳐을 추가하거나 모델 아키텍처를 변경합니다.

• Data iteration

  : 동일한 모델 아키텍처 및 피쳐이지만 새로운 데이터를 훈련 해야합니다.

현재 stateful training은 Data iteration을 의미합니다. 모델 아키텍처를 변경하거나 새 피쳐을 추가하는 경우에는 새 모델을 처음부터 교육해야 합니다. 모델 아키텍쳐가 변경되도 Continual Learning을 할 수 있는 흥미로운 연구도 있습니다. knowledge transfer (구글, 2015) 및 model surgery (OpenAI 2019) : "모델의 어떤 부분이 변경되지 않고 어떤 부분을 다시 초기화해야 하는지 결정하기 위해 선택한 후에 한 Network에서 다른 Network로 훈련된 가중치를 이전(transfer)합니다.” 몇몇의 거대한 연구실에서 이를 실험했습니다만, 저는 업계의 명확한 결과를 알지는 못합니다.

Manual retraining으로 시작하는 첫 번째 단계는 재훈련 프로세스를 자동화하는 것 입니다. 그런 다음 stateless retraining에서 stateful training으로 이동합니다. 마지막으로 continual learning에 대해 논의할 것입니다.

1단계. Manual, Stateless Retraining 🔗

처음에 ML팀은 사기 탐지, 추천, 배송 추정 등 가능한 한 많은 비즈니스 문제를 해결하기 위해 ML 모델을 개발하는 데 중점을 둡니다. 팀이 새 모델 개발에 집중하고 있기 때문에 기존 모델 업데이트는 뒷전입니다. 다음 경우에만 기존 모델을 업데이트합니다.

• 모델의 성능이 득보다 실이 많을 정도로 저하되었습니다.
• 팀에서 모델을 업데이트할 시간이 있습니다.

일부 모델은 6개월에 한 번씩 업데이트 됩니다. 일부는 분기별로 업데이트됩니다. 일부는 1년 동안 야생에 있었고 전혀 업데이트되지 않았습니다.

모델 업데이트 프로세스는 수동이며 임시입니다. 일반적으로 데이터 플랫폼 팀의 누군가가 데이터 웨어하우스에 새 데이터를 쿼리합니다. 다른 누군가가 이 새 데이터를 정리하고, 그 데이터에서 피쳐을 추출하고, 이전 데이터와 새 데이터 모두 사용하여 처음부터 해당 모델을 다시 학습시킨 다음, 업데이트된 모델을 바이너리 형식으로 내보냅니다. 그런 다음 다른 사람이 해당 바이너리 형식의 업데이트된 모델을 배포합니다. 종종 피쳐/모델/처리 코드는 모델 재학습 중에 수정 되지만 변경 사항이 프로덕션에서 복제(replicated)되지 않아 추적하기 어려운 버그가 발생합니다.

이 과정이 당신에게 고통스럽게 들린다면, 당신은 혼자가 아닙니다. 기술 산업 외부의 대다수 회사(예: ML을 도입한 지 3년 미만이고 ML 플랫폼 팀이 없는 회사)가 이 단계에 있습니다.

2단계. Automated Retraining 🔗

임시 방식으로 수동으로 모델을 재훈련하는 대신 재훈련 프로세스를 자동으로 실행하는 스크립트가 있습니다. 이것은 일반적으로 Spark와 같은 Batch 프로세스에서 수행됩니다.

어느 정도 성숙한 ML 인프라를 갖춘 대부분의 회사가 이 단계에 있습니다. 일부 정교한 회사는 최적의 재훈련 빈도를 결정하기 위해 실험을 실행합니다. 그러나 대부분의 회사에서 재교육 빈도는 직감에 따라 설정됩니다(예: "하루에 한 번 정도가 적당할 것 같습니다." 또는 "매일 밤 유휴 컴퓨팅이 있을 때 재훈련 프로세스를 시작합시다.").

파이프라인의 서로 다른 모델에는 각각의 재훈련 스케쥴이 필요할 수 있습니다.

위의 session-based 추천의 경우 임베딩 모델이 랭킹 모델과 별개인 경우 임베딩 모델은 랭킹 모델보다 훨씬 적은 빈도로 재학습해야 할 수도 있습니다. 예를 들어, 임베딩을 일주일에 한 번 재교육하고, 하루에 한 번 랭킹 모델을 재교육할 수 있습니다. 임베딩을 학습해야 하는 새로운 항목이 매일 많다면 이야기가 달라집니다.

모델 간에 종속성이 있으면 상황이 훨씬 더 복잡해집니다. 예를 들어, 임베딩이 변경되면 랭킹 모델이 임베딩에 따라 달라지므로 랭킹 모델도 업데이트해야 합니다.

요구 사항

회사에 프로덕션 환경에 ML 모델이 있는 경우 자동화된 재훈련에 필요한 대부분의 인프라가 이미 회사에 있을 수 있습니다. 아직 없는 경우 필요한 유일한 새 조각은 모델을 재현하는 데 필요한 모든 코드/아티팩트를 자동으로 버전화하고 저장하는 모델 저장소 입니다.

가장 간단한 모델 저장소는 아마도 구조화된 방식으로 직렬화된 모델 Blob을 저장하는 S3 버킷일 것입니다. 좀 더 성숙한 모델 스토어를 원하신다면 제가 자주 듣는 솔루션은 SageMaker(관리형 서비스)와 MLFlow(오픈 소스)입니다. SageMaker는 사용하기 더 어렵고 모델의 코드와 아티팩트를 저장하지 않습니다. MLFlow는 오픈 소스이며 더 많은 피쳐가 있지만 본인의 ML플랫폼에 특이사항(quirks)이 많은 경우 작동하기 어려울 수 있습니다.

워크플로를 자동화하는 스크립트를 작성하고 데이터를 자동으로 샘플링하고, 피쳐를 추출하고, 재훈련을 위해 레이블을 처리도록 인프라를 구성해야 합니다. 이 프로세스에서 소요되는 시간은 여러 요인에 따라 다르지만 다음은 두 가지 주요 요인입니다.

1. 스케줄러. Airflow, Argo와 같은 CRON 스케줄러가 이미 있는 경우 스크립트를 함께 연결하는 것이 그렇게 어렵지 않을 것입니다.
2. 데이터 액세스 및 가용성. 필요한 모든 데이터가 이미 데이터 웨어하우스에 수집되어 있습니까? 여러 조직의 데이터를 결합해야 합니까? 처음부터 많은 테이블을 만들어야 합니까? Stitch Fix의 ML/데이터 플랫폼 관리자인 Stefan Krawczyk은 대부분의 사람들이 이곳에서 많은 시간을 보내고 있을 수도 있다고 생각한다고 말했습니다.

Bonus: Log and wait (feature reuse) 🔗

새 데이터에 대해 모델을 재학습할 때 새 데이터가 이미 예측 서비스를 거쳤을 가능성이 있습니다. 즉, 예측을 위해 특성이 이미 한 번 추출되었음을 의미합니다. 일부 회사는 이러한 추출된 피쳐을 모델 업데이트에 재사용하여 계산을 절약하고 예측과 훈련 간의 일관성을 허용합니다. 이 접근 방식을 log and wait 라고 합니다. 이는 프로덕션 환경과 개발 환경 간의 불일치로 인해 발생하는 버그인 training-serving 편향(Skew)을 줄이기 위한 고전적인 접근 방식입니다.

이것은 아직 대중적인 접근 방식은 아니지만 점점 더 대중화되고 있습니다. 곧 표준이 되리라 기대합니다. Faire는 log and wait 접근 방식의 장단점을 논의 하는 훌륭한 블로그 게시물을 보유하고 있습니다.

3단계. Automated, Stateful Training 🔗

Stateful training은 모델을 처음부터 다시 훈련하는 대신 새 데이터로만 모델을 이어서 훈련할 때 사용한다는 점을 기억하십시오. Stateful retraining을 사용하면 더 적은 데이터로 모델을 업데이트할 수 있습니다. 한 달에 한 번 모델을 업데이트하는 경우 지난 3개월 동안의 데이터에 대해 처음부터 모델을 다시 학습시켜야 할 수 있습니다. 그러나 매일 모델을 업데이트하는 경우 마지막 날의 데이터에 대해서만 모델을 fine-tune 하면 됩니다.

Grubhub는 stateless daily retraining에서 stateful daily retraining으로 전환한 후 훈련 비용을 45배 절감 했습니다 (2021년).

Stateless vs. Stateful 훈련

Incremental learning의 또 다른 좋은 속성은 각 데이터 샘플을 최대 두 번(예측 중에 한 번, 모델 훈련 중에 한 번)만 볼 필요가 있다는 것입니다. 데이터 프라이버시가 걱정된다면 데이터 샘플을 사용한 후 폐기할 수 있습니다.

요구 사항

이 단계에서 가장 필요한 것은 더 좋은 모델 스토어입니다.

• Model lineage

  : 모델의 버전을 지정하는 것뿐만 아니라 계보(lineage)를 추적하기를 원합니다. 어떤 모델에서 fine-tune 되었는지 확인.

• Streaming features reproducibility

  : 과거의 스트리밍 피쳐을 추출하기 위해 시간 여행(time-travel)을 할 수 있고 어떤 일이 발생하여 디버그해야 하는 경우 과거의 어느 시점에서든 모델에 대한 훈련 데이터를 다시 생성할 수 있기를 원합니다.

내가 아는 한, 이 두 가지 피쳐을 모두 갖춘 모델 스토어는 없습니다. 스트리밍 피쳐 재현성(reproducibility)을 피쳐 스토어에 위임할 수 있지만 솔루션을 사내에서 구축해야 할 수 있습니다.

4단계. Continual Learning 🔗

내가 노력하고 있고 많은 회사들이 궁극적으로 채택하기를 바라는 것은 Continual Learning 입니다.

고정된 일정에 따라 모델을 업데이트하는 대신 데이터 분포가 변경되고 모델의 성능이 떨어질 때마다 모델을 지속적으로 업데이트 하십시오.

성배는 지속적인 학습과 에지 배포를 결합할 때입니다. 새 장치와 함께 기본 모델을 배송할 수 있고 해당 장치(Ex, phone, watch, drone, etc)의 모델이 계속해서 환경에 맞게 업데이트되고 조정될 것이라고 상상해 보십시오. 중앙 집중식 서버 비용이 없으며 장치와 클라우드 간에 데이터를 주고받을 필요가 없습니다!

요구 사항

3단계에서 4단계로의 전환이 가파릅니다. 다음이 요소들이 필요할 것 입니다.

• 모델 업데이트를 트리거하는 메커니즘 입니다. 이 트리거는 time-based(예: 5분마다), performance-based(예: 모델 성능이 급락할 때마다) 또는 drift-based(예: 데이터 분포가 이동할 때마다)일 수 있습니다.

  오늘날 대부분의 모니터링 솔루션은 피쳐 분석에 중점을 두고 있습니다. 즉, 피쳐의 요약 통계(예: 평균, 분산, 최소값, 최대값)를 분석하고 이러한 통계에서 중요한 변경이 발생하면 알려줍니다. 그러나 모델에는 수천 개 까지는 아니더라도 수백 개의 피쳐가 있을 수 있습니다. 대부분의 피쳐 통계 변경 사항은 무해합니다. 문제는 이러한 변경 사항을 감지하는 방법이 아니라 실제로 주의가 필요한 변경 사항을 아는 방법입니다.

• 모델을 지속적으로 평가하는 더 나은 방법. 모델을 업데이트하는 함수를 작성하는 것은 3단계에서 하는 것과 크게 다르지 않습니다. 어려운 부분은 업데이트된 모델이 제대로 작동하는지 확인하는 것입니다. 변화하는 환경에 적응하도록 모델을 업데이트하고 있기 때문에 고정 테스트 세트로는 더 이상 충분하지 않습니다. 백테스트, 점진적 평가(progressive evaluation), 섀도 배포를 포함한 프로덕션 테스트인 A/B 테스트, 카나리아 분석 및 bandits을을 고려할 수 있습니다.

• 기존 예측 서비스를 중단하지 않고 모델을 업데이트하고 평가하기 위해 인스턴스를 자동으로 스핀업하는 오케스트레이터.

결론 🔗

실시간 머신 러닝은 주로 인프라 문제입니다. 이를 해결하려면 DS/ML 팀과 플랫폼 팀이 협력해야 합니다.

Online Prediction과 Continual Learning 모두 성숙한 스트리밍 인프라가 필요합니다. 지속적 학습의 훈련 부분은 Batch로 수행할 수 있지만 온라인 평가 부분은 스트리밍이 필요합니다. 많은 엔지니어들은 스트리밍이 어렵고 비용이 많이 든다고 걱정합니다. 3년 전만 해도 사실이었지만 스트리밍 기술은 그 이후로 눈에 띄게 발전했습니다. Spark Streaming, Snowflake Streaming, Materialize, Decodable, Vectorize 등을 포함하여 기업이 스트리밍으로 쉽게 이동할 수 있도록 하는 솔루션을 점점 더 많은 회사에서 제공하고 있습니다.

업계에서 실시간 ML의 채택과 과제를 더 잘 이해하기 위해 저희 팀과 저는 설문 조사를 진행하고 있습니다. 귀하의 생각을 공유해 주시면 감사하겠습니다. 소요 시간은 약 5분입니다. 결과는 집계되고 요약되어 커뮤니티와 공유됩니다. 감사합니다!

저와 제 팀이 온라인 예측, 온라인 모델 평가 및 자동화된 Stateful training을 어떻게 도울 수 있는지 논의하려면 연락하십시오.

감사의 말 🔗

이 게시물은 워크플로에 대한 내 질문에 매우 인내심 있는 많은 엔지니어 목록의 도움 없이는 불가능했을 것입니다.

또한 Stefan Krawczyk , Zhenzhong Xu , Max Halford , Goku Mohandas , Alex Egg , Jacopo Tagliabue , Luke Metz 의 사려 깊은 의견으로 이 게시물을 개선한 데 에도 감사드립니다 .

Ammar Asmro, Alex Gidiotis, Aditya Soni, Shaosu Liu, Deepanshu Setia, Bonson Sebastian Mampilli, Sean Sheng 및 Daniel Tan에게 설문에 대한 피드백을 주셔서 감사합니다!

부록 🔗

Stream processing 와 Batch processing의 효율성 비교 🔗

전반적인 비용 효율성, 컴퓨팅 성능 효율성, 인재 효율성이라는 세 가지 차원에서 효율성을 비교할 것입니다. 이 사려 깊은 분석에 대해 Zhenzhong Xu에게 감사드립니다!

1. 비용 효율성

   불행히도 Stream processing 과 Batch processing 사이에 보편적인 비용 효율성 공식은 없습니다. latency requirement, data size, late arrival tolerance, failure tolerance, statefulness 등과 같은 많은 변수에 따라 달라집니다. 스트림 처리의 강점은 stateful, continuous 및 unbounded data processing에 있습니다. 적절하게 사용하면 Stateless Batch 처리에 비해 비용이 적게 드는 경우가 많습니다. 예를 들어, 30일 평가판 사용 기간 동안 사용자 참여를 스코어링하기 위해 슬라이딩 윈도우를 계산해야 하는 경우 Batch 처리는 매번 Batch에서 30일 분량의 데이터를 다시 계산해야 하는 반면 Stateful streaming workload는 모든 중복 처리를 피할 수 있기 때문에 컴퓨팅 비용이 적게 듭니다. 반면에 매우 큰 데이터셋을 일회성으로 처리하는 경우 Batch가 여전히 최고의 선택이 될 것 입니다.

2. 성능 효율성

   스트림 처리는 오늘날 매우 정교한(sophisticated) 기술입니다. Apache Flink와 같은 프레임워크는 확장성이 뛰어나고 완전히 분산된 것으로 입증되었습니다. 스트림 처리는 speed와 unbounded data에 최적화되어 있습니다. 성능은 운영자당 처리량으로 측정되며 가용성 SLA는 종종 특정 지연 허용 범위 내에서 처리되는 이벤트의 백분율로 정의됩니다. 그러나 스트림 처리는 대규모 bounded data 처리에 최적화되어 있지 않으며 대용량 historical 데이터 처리(예: backfill)에서는 성능이 현저히 떨어집니다. 즉, 스트리밍과 Batch의 장점을 모두 활용하는 응집력(cohesive) 있고 통합된 아키텍처를 찾는 것은 현재 활발한 개발 영역입니다. 여기서 기억해야할 점은 Stream 처리와 Batch 처리에는 모두 장단점이 있다는 점 입니다. 궁극적으로 데이터 처리 사용자들은 현재의 스트리밍/배치 구분에 대해 걱정할 필요가 없을 것입니다. 추상화가 불가피하게 증가함에 따라 이 격차는 몇 년 안에 좁혀질 것입니다.

3. 인재(Talent) 효율성

   오늘날에도 스트리밍은 사내에서 관리하기 어렵다는 것이 일반적인 합의입니다. 기술적 깊이와 운영 모두에 정통한 매우 강력한 인프라 엔지니어 팀이 필요합니다. 그러나 데이터 처리가 점점 더 일반화 되면서 많은 기업이 자체 구축보다 구매를 고려하기 시작할 것입니다. 여기에서 비유하자면, 전기를 더 높은 가치로 만들기 위해서 원자력 과학자가 필요하지는 않습니다. (오 만약, 당신이 원자력 발전 회사를 운영하고 있지 않다면요 :) - 그 경우, 당신은 가능한 최고의 사람들을 얻을 준비가 되어 있어야 합니다!)

Feature stores는 무엇을 합니까? 🔗

이 분석에 대해 Stefan Krawczyk에게 감사드립니다.

Tecton 및 FEAST와 같은 피쳐 저장소는 일부 스트리밍 피쳐 계산을 수행하지만 조인이 필요하지 않은 데이터에서만 작동하므로 전체 feature computation flow를 오케스트레이션하지는 않을 것입니다.

Sagemaker의 피쳐 저장소는 구체화된 데이터만 저장하며 실제 계산을 수행할 파이프라인에 연결해야 합니다. 그런 다음 사람들은 시스템의 구체화된 피쳐을 참조(reference)하고 사용 합니다, 이는 계산하는 실제 코드가 아닙니다.