Feature Store로 기계 학습 개발 간소화

존 토마스

UFC 에서 선수들은 강도 높은 훈련을 통해 옥타곤에서의 시간을 준비합니다. 파이터와 팀은 상대의 스타일을 분석하여 악용할 수 있는 약점이 있는지 분석하고 신체와 기술을 미세 조정하여 최상의 경기를 제공합니다.

UFC의 모조직인 Endeavour 의 데이터 과학자들은 결단력을 가지고 기계 학습 예측에 접근합니다. 선수들이 카메라 앞에서 투구하는 동안 경기를 지켜보는 팬들과 관련된 데이터도 비판적으로 분석됩니다. 시청자를 유치하고 유지하기 위한 경쟁이 치열합니다. 고객은 고객의 관심을 끌 수 있는 매력적인 경험이 필요하며 Endeavour는 머신 러닝과 디지털 전문 지식을 활용하여 문제를 해결하는 데 있어 떠오르는 리더가 되었습니다. 아래에서 UFC에서 머신 러닝 개발을 간소화하는 기능 저장소를 구현하여 시청자 통찰력을 극대화하는 Endeavour의 작업에 대해 자세히 알아봅니다.

이 글을 읽는 많은 데이터 과학자들은 기계 학습 모델을 구축하는 작업의 대부분이 기능 생성에서 나온다는 것을 알고 있습니다. 집계된 특성(예: 마지막 구매 이후 날짜 또는 고객 거주 국가)과 같은 기능(예: 예측자 또는 속성)은 예측 기계 학습 모델의 필수 부분입니다. 모델이 정확한 예측을 하려면 출력의 충분한 변동을 설명할 수 있는(즉, 예측이 속한 범주를 결정하는) 고품질 기능이 필요합니다. 그러나 기계 학습 작업을 확장하면 ML 생태계를 유지하는 것이 어렵거나 반복적이라는 것을 알 수 있습니다. 또한 팀은 동일한 노력을 반복하여 코드베이스 전체에서 정의 불일치의 위험을 감수할 수 있습니다. Endeavour는 Feature Store 를 통해 이 문제를 해결했습니다.일관성, 검색 가능성 및 재사용성을 보장하기 위해 기능을 표준화하고 중앙 집중화합니다.

계산의 복잡성에 따라 기능을 개발하는 데 상당한 시간이 걸릴 수 있습니다. 가지고 있는 원시 데이터를 모델에 적합한 소화 가능한 형식으로 집계하는 데 몇 주를 보낼 수 있습니다. 일부 기능은 예를 들어 평생 티켓 판매 또는 가장 많이 사용되는 스트리밍 장치와 같은 여러 사용 사례에서 공통적일 수 있으며, 이는 거래 및 브라우징 행동 모델 모두에 대해 예측할 수 있습니다. 여러 데이터 과학자가 동일한 소스를 사용하여 모델에 대해 작업하는 경우 서로 다른 목적 함수(예: 대답하려는 예측 질문)에 대해 동일한 기능이 여러 번 생성될 때 정의 불일치와 같은 문제가 발생할 수 있습니다. 여러 클라이언트와 여러 모델에서 사용할 수 있는 기능의 공통 허브를 사용하여 데이터 엔지니어링 노력을 간소화할 수 있습니다.

기능 저장소를 입력하십시오.

기능 저장소는 여러 기여자가 모델 개발을 위해 기능을 정의할 수 있는 공통 코드 리포지토리입니다.

기능 저장소에서 여러 기능 테이블로 구성된 스키마를 가질 수 있으며 각 기능 테이블은 예측하려는 공통 식별자를 한 눈에 볼 수 있습니다. Endeavour Streaming 으로 수행한 작업을 사용하여 예제를 살펴볼 수 있습니다.Endeavour Streaming은 선도적인 기술과 디지털 미디어 전문 지식을 스트리밍 세계에 제공하고 스포츠 스트리밍 거대 기업을 위한 다양한 분석 기능을 제공합니다. Endeavour Streaming은 각 클라이언트(컨텐츠를 스트리밍하기 위해 비즈니스 Endeavour 파트너로 정의됨)와 함께 스트리밍 및 트랜잭션 동작에 대한 데이터를 효과적으로 수집하여 고객 경험을 향상할 수 있습니다. 그런 다음 우리 팀의 데이터 과학자는 이러한 원시 데이터 스트림을 사용하여 고객에게 기계 학습 예측을 제공합니다. 비디오 스트리밍 데이터의 데이터 소스에 대해 기계 학습을 수행하는 경우 예를 들어 다음과 같은 분류가 있을 수 있습니다.

잠재적 목적 함수:

• 이탈 — 고객이 구독을 취소할 가능성은 얼마나 됩니까?
• Pay-Per-View 재구매 -Pay-Per-View 라이선스를 구매한 고객이 다시 라이선스를 구매할 가능성은 얼마나 됩니까?
• 고객 재참여 -고객이 특정 콘텐츠를 스트리밍할 가능성은 얼마나 됩니까?

표 1: UFC의 시청률 원시 데이터 스트림 예

Endeavour는 Snowflake 데이터베이스를 활용하여 데이터를 저장하고 DBT 모델을 활용하여 관련 데이터 집계의 쿼리를 저장함으로써 효율성을 극대화합니다. DBT를 사용하여 고객 수준에서 테스트 및 추론 데이터 세트를 구축할 수 있었습니다(고객의 목적 함수에 응답하기 위해 customer_EXID로 식별됨).

이러한 데이터 세트에서 파생될 수 있는 일부 기능은 다음과 같습니다.

• 고객이 사용하는 장치
• 고객이 본 시간(분)
• 고객별 시청 국가
• 고객이 본 콘텐츠
• 첫 번째 메인 카드 콘텐츠 보기

이것은 "작동합니다." 두 클라이언트에 대한 시청률 데이터의 데이터 조작 단계는 각 목적 함수(3)에 대해 두 개의 데이터 프레임(테스트 및 추론)을 생성할 수 있습니다. 이것은 우리에게 12개의 서로 다른 모델을 제공하며, 모두 유사한 소스에서 가져오고 유사한 출력을 생성합니다. 모든 기능이 모든 모델에서 사용되는 것은 아니므로 이는 DBT를 통한 각 개별 모델 생성에서 특별히 설명됩니다. 그러나 이것은 다음과 같은 몇 가지 이유로 비효율적입니다.

• 기능 정의 드리프트 - 이러한 각 모델에 대해 동일한 기능이 재생성되므로 해당 기능의 정의가 모델 간에 일관성을 유지하기 위한 메커니즘이 없습니다.
• 반복 - 새로운 클라이언트가 도입되면 해당 클라이언트에 대해 이러한 정확한 모델을 다시 만드는 프로세스를 반복해야 합니다.
• 모델 유지 — 데이터가 변경되거나 대상 변수의 새로운 깊이가 시간이 지남에 따라 노출됨에 따라 가장 작은 변경 사항은 모든 모델에서 하나씩 수동으로 구현되어야 합니다.

이제 한 곳에서 기능 개발을 중앙 집중화하여 위의 우려 사항을 중재할 수 있습니다. 사용 사례에 관계없이 모든 기능은 기능 저장소에 있습니다. 한 모델은 단순히 행 수준 식별자(고객)에 조인하여 상점에서 원하는 기능을 "확인"할 수 있습니다. 이 디자인의 아름다움은 여기서 그치지 않습니다. 이후에 추가되는 모든 클라이언트는 기능을 생성하기 위해 통과한 이전 클라이언트의 논리를 따릅니다. 데이터베이스에 들어오는 원시 시청률 데이터 구조가 동일하기 때문에 새로운 "클라이언트 3"이 온보드된 경우 기존 클라이언트와 동일한 논리를 적용하고 상대적으로 적은 노력으로 클라이언트 3에 대해 동일한 기능을 생성할 수 있습니다. 또한 이러한 신규 고객을 위한 모델(테스트 및 추론)을 신속하게 구축할 수 있습니다.

이는 여러 가지 이유로 유용합니다.

• 기능 개발 작업은 다른 데이터 과학자가 쉽게 액세스할 수 있습니다.
• 기능 계산은 이제 모든 사용 사례에 대해 자동화됩니다.
• 교육 및 추론 데이터 세트는 기능이 일관됩니다.
• 다양한 사용 사례에 걸쳐 모델 복제를 신속하게 확장 가능

Endeavour Streaming이 서비스하는 고유한 클라이언트에서 처리되는 데이터는 동일한 Feature Store에 존재하지만, 클라이언트를 기반으로 Feature Store를 필터링하는 것만으로 모델 개발에서 데이터가 연합됩니다. UFC 예에서 머신 러닝 모델은 UFC 특정 훈련 세트가 생성 된 후에 만 개발될 수 있으므로 클라이언트 간 데이터 유출이 없음을 보장합니다. 데이터 보안은 설계에 내장되어 있으며 여기 Endeavour Digital의 기능 저장소의 또 다른 이점임이 입증되었습니다.

우리는 모든 테이블을 공통 행 수준 집계로 가져오고 싶고, Endeavour Streaming 작업의 사용 사례에서 로 표시된 고객 수준으로 요약하는 데 관심이 CUSTOMER_EXID있습니다. 시청 시작 시간/종료 시간의 집계는 매우 유용할 수 있으며 매장의 기능 테이블에 적합합니다.

WITH minutes AS (
  SELECT 
    customer_exid, 
    DATEDIFF(
      'minute', session_start, session_end
    ) AS session_length, 
    DATE(session_start) AS session_date 
  FROM 
    viewership
) 
SELECT 
  customer_exid, 
  AVG(session_length) AS avg_session_length, 
  COUNT(DISTINCT session_date) AS distinct_days_active 
FROM 
  minutes 
GROUP BY 
  customer_exid

반대로 스트리밍에 사용하는 장치에 대한 지식을 위해 동일한 작업을 수행할 수 있습니다.

SELECT 
  customer_exid, 
  MODE(device) AS most_used_device 
FROM 
  viewership 
GROUP BY 
  customer_exid

Endeavour Streaming의 데이터 스트림은 구조가 일관되기 때문에 이러한 기능이 생성되면 이러한 기능 테이블을 사용하여 자동으로 계산할 수 있습니다.

Churn을 사용하면 이전 고객의 하위 집합( 로 표시 CUSTOMER_EXID) 목록과 구독을 취소했는지 또는 구독을 취소했는지 여부(현재 활성 상태)에 대한 식별자를 가질 수 있습니다.

표 4: 이탈 상태의 고객 테이블(churn_status)

이 목적 함수의 목표는 고객의 상태를 활성 또는 만료로 가장 잘 분류할 수 있는 품질 예측 변수를 찾는 것입니다. 마법의 이 부분은 실제 기계 학습에서 발생하지만 데이터 세트를 만들어야 합니다. 그러나 기능 저장소의 장점은 실제로 이미 가지고 있는 테이블을 기반으로 교육할 데이터 세트를 매우 빠르게 만들 수 있다는 것입니다. 이 테이블을 만들기 위해 복잡한 쿼리를 만들 필요는 없으며 원하는 모든 기능을 함께 조인하면 됩니다.

SELECT 
  A.customer_exid, 
  A.status, 
  COALESCE(B.avg_session_length, 0) AS avg_session_length COALESCE(B.distinct_days_active, 0) AS distinct_days_active, 
  COALESCE(C.most_used_device, 'Invalid') AS most_used_device 
FROM 
  churn_status A 
  LEFT JOIN feature_minutes B ON A.customer_exid = B.customer_exid 
  LEFT JOIN feature_devices C ON A.customer_exid = C.customer_exid

보시다시피 이제 status모든 기능을 수준에서 예측자로 사용하여 예측할 수 있는 데이터 세트가 있습니다 CUSTOMER_EXID . 여기에서 중요한 사실을 알 수 있습니다. 모든 고객이 각 기능 테이블에 표시되는 것은 아닙니다. 계정이 있지만 콘텐츠를 본 적이 없는 고객은 viewership테이블 또는 여기에서 파생된 모든 기능 테이블에 나타나지 않습니다. 결과적으로 COALESCE()이러한 null 값을 설명하기 위해 모든 조인은 아니지만 대부분의 조인에 추가해야 합니다.

다른 데이터 과학자가 Pay-Per-View 라이선스를 구매한 고객이 라이선스를 다시 구매할 가능성을 예측하려는 경우 목적 함수에 대해 이탈 사용 사례에서 이미 생성된 기능을 확인할 수 있습니다. 이렇게 하면 모델 개발 시간이 크게 단축되고 기능 정의가 모델 간에 공통적으로 적용됩니다. 또한 모델을 생산할 때가 되면 추론 세트를 구축할 때 특성 저장소에서 다시 가져올 수 있습니다. 기능 저장소를 사용하면 ML 교육 개발을 최적화하고 데이터 과학 팀이 효과적이고 효율적으로 이동할 수 있는 강력한 생태계를 만들 수 있습니다.

작성자와 데이터에 대해 더 많은 대화를 나누고 싶습니까? LinkedIn 에서 직접 John Thomas에게 연락 하십시오!