Lakehouse AI가 실시간 계산을 통해 모델 정확도를 향상시키는 방법

December 15, 2023 in 플랫폼 블로그

이 포스트 공유하기

머신 러닝 모델의 예측 품질은 주로 모델을 훈련하고 운영하는 데 사용된 데이터의 품질에 직접적으로 의존합니다. 보통은 모델의 입력 데이터인 피처(Feature)들이 미리 계산되어 저장되고, 추론을 위해 필요할 때 조회되어 모델에 전달됩니다. 모델 성능은 종종 피처 계산에 사용되는 데이터의 최신성과 직접적인 상관관계가 있기 때문에 이러한 피처를 미리 계산할 수 없는 경우 문제가 발생할 수 있습니다. 이러한 특정 유형의 피처를 제공하는 도중 발생하는 어려움을 간단히 처리하기 위해, 데이터브릭스 온디맨드 피처 계산(On Demand Feature Computation)을 발표하게 되어 기쁘게 생각합니다.

추천, 보안 시스템, 이상거래 탐지와 같은 사용 사례는 모델을 평가하는 동안 필요에 따라 온디맨드 방식으로 피처를 계산해야 합니다. 이에 관련된 시나리오들은 다음과 같습니다.

피처에 대한 입력 데이터가 모델 서빙 시점에만 사용 가능한 경우. 예를 들어, distance_from_restaurant는 모바일 장치에서 마지막으로 확인된 사용자의 위치가 필요합니다.
피처의 값이 사용되는 맥락에 따라 달라지는 상황. 예를 들어, device_type이 모바일인 경우와 데스크톱인 경우에는 참여 지표(engagement metrics)를 매우 다르게 해석해야 합니다.
피처의 사전 계산, 저장 및 갱신이 경제적으로 불가능한 경우. 예를 들어, 비디오 스트리밍 서비스는 수백만 명의 사용자와 수만 개의 영화를 보유할 수 있으므로 avg_rating_of_similar_movies와 같은 피처를 미리 계산하는 데 비용이 너무 많이 듭니다.

이러한 사용 사례를 지원하기 위해 피처는 추론 시점에 계산되어야 합니다. 그러나 모델 학습을 위한 피처 계산은 일반적으로 Apache Spark(™)와 같이 비용 효율적이고 처리량에 최적화된 프레임워크를 사용하여 수행되며, 피처가 실시간 스코어링에 필요한 경우 두 가지 주요 문제가 발생합니다.

엔지니어 리소스, 지연, 훈련/서빙 왜곡: 아키텍처는 피처 계산을 Java 또는 C++과 같은 서버 측의 대기 시간 최적화된 언어로 다시 작성해야 하는 경우가 빈번합니다. 이로 인해 피처가 두 가지 다른 언어로 생성되어 훈련-서빙 왜곡이 발생할 가능성이 있을 뿐만 아니라, 머신러닝 엔지니어는 오프라인 및 온라인 시스템 간에 피처 계산 로직을 관리하고 동기화해야 합니다.
복잡한 아키텍처: 피처을 계산하고 모델에 제공하기 위한 아키텍처가 복잡합니다. 피처 엔지니어링 파이프라인 시스템은 제공되는 모델과 함께 배포 및 업데이트되어야 하며, 새 모델 버전이 배포되면 새로운 피처 정의가 필요합니다. 이러한 아키텍처는 불필요한 배포 지연을 야기합니다. 머신러닝 엔지니어는 신규 피처 계산 파이프라인 및 엔드포인트가 운영 중인 시스템과 독립적이며 요율 제한, 리소스 제한 및 네트워크 대역폭에 부딪히지 않도록 보장해야 합니다.

Architecture — A common architecture requiring synchronization of offline and online featurization logic. An update of feature definitions is shown in gray.

위의 아키텍처에서 피처 정의를 업데이트하는 것은 거대한 작업일 수 있습니다. 업데이트된 피처화 파이프라인은 이전 피처 정의를 사용하여 훈련 및 배치 추론을 계속 지원하는 원래의 파이프라인과 동시에 개발 및 배포되어야 합니다. 모델은 업데이트된 피처 정의를 사용하여 재학습 및 검증되어야 합니다. 배포 전에 엔지니어는 먼저 피처 서버에서 피처 계산 논리를 다시 작성하고 프로덕션 트래픽에 영향을 미치지 않도록 독립적인 피처 서버 버전을 배포해야 합니다. 배포 후에는 수많은 테스트를 실행하여 업데이트된 모델의 성능이 개발 중에 보았던 것과 동일한지 확인해야 합니다. 그리고 모델 오케스트레이터를 업데이트하여 트래픽을 새 모델로 리디렉션해야 합니다. 마지막으로, 안정화를 위한 일정 기간이 지난 후에 이전 모델 및 이전 특징 서버를 중지할 수 있습니다.

이러한 아키텍처를 간소화하고 엔지니어링 속도를 향상시키며 가용성을 높이기 위해 데이터브릭스에서는 온디맨드 피처 계산을 지원하는 기능을 출시 했습니다. 이 기능은 Unity Catalog에통합되어 모델을 생성하고 배포하는 엔드투엔드 사용자 여정을 간소화합니다.

온디맨드 기능은 피처 엔지니어링 파이프라인의 복잡성을 크게 줄이는 데 도움이 되었습니다. 온디맨드 기능을 사용하면 각 고객마다 고유한 복잡한 변환을 관리하는 번거로움을 피할 수 있습니다. 대신 기본 피처 세트로 시작하여 훈련 및 추론 중에 필요에 따라 고객별로 피처를 변환할 수 있습니다. 온디맨드 기능 덕분에 차세대 모델을 구축할 수 있는 진정한 능력을 갖추게 되었습니다. - Chris Messier, Senior Machine Learning Engineer at MissionWired

Machine Learning Model에서의 함수 사용

Feature Engineering in Unity Catalog을 사용하여 데이터 과학자는 테이블에서 미리 생성된 피처를 검색하고 함수를 사용하여 온디맨드 피처를 계산할 수 있습니다. 온디맨드 계산은 Unity Catalog에서 관리되는 엔티티인 Python 사용자 정의 함수(UDF)로 표현됩니다. 함수는 SQL로 생성된 다음 SQL 쿼리, 대시보드, 노트북 등 레이크하우스 전반에서 사용할 수 있으며, 이제 실시간 모델에서 피처를 계산하는 데도 사용할 수 있습니다.

Unity Catalog Lineage 그래프는 데이터와 함수에 대한 모델의 종속성을 기록합니다.

CREATE OR REPLACE FUNCTION main.on_demand_demo.avg_hover_time(blob STRING)
RETURNS FLOAT
LANGUAGE PYTHON
COMMENT "Extract hover time from JSON blob and computes average"
AS $$
import json

def calculate_average_hover_time(json_blob):
    # Parse the JSON blob
    data = json.loads(json_blob)

    # Ensure the 'hover_time' list exists and is not empty
    hover_time_list = data.get('hover_time')
    if not hover_time_list:
        raise ValueError("No hover_time list found or list is empty")

    # Sum the hover time durations and calculate the average
    total_duration = sum(hover_time_list)
    average_duration = total_duration / len(hover_time_list)

    return average_duration

return calculate_average_hover_time(blob)
$$

모델에서 함수를 사용하려면 create_training_set 호출 시 함수를 포함합니다.

from databricks.feature_store import FeatureStoreClient

fs = FeatureStoreClient()

features = [
    FeatureFunction(
        udf_name="main.on_demand_demo.avg_hover_time",
        output_name="on_demand_output",
        input_bindings={"blob": "json_blob"},
    ),
 ...
]

training_set = fs.create_training_set(
    raw_df, feature_lookups=features, label="label", exclude_columns=["id"]
)

함수는 Spark에 의해 실행되어 모델의 훈련 데이터를 생성합니다.

또한 함수는 네이티브 Python과 pandas를 사용하여 실시간 서빙에서도 실행됩니다. Spark는 실시간 프로세스에 관여하지는 않지만, 훈련 시에 사용된 것과 동일한 계산이 보장됩니다.

간소화된 아키텍처

모델, 함수, 데이터가 모두 Unity Catalog 내에 공존하므로 통합된 거버넌스를 가능케합니다. 데이터 과학자는 공유 카탈로그를 통해 피처와 함수를 모델링에 재사용할 수 있으므로 조직 전체에서 피처가 계산되는 방식에 일관성을 유지할 수 있습니다. 서빙 시, 모델 리니지를 사용하여 모델에 대한 입력으로 사용될 함수 및 테이블을 결정하므로, 훈련-서빙의 왜곡 가능성을 제거합니다. 이로 인해 전반적으로 아키텍처가 현저하게 간소화됩니다.

Lakehouse AI는 모델 배포를 자동화합니다. 모델이 배포되면 Databricks Model Serving이 필요한 모든 함수를 자동으로 배포하여 피처의 실시간 계산을 가능케 합니다. 요청 시점에 Online Store에서 미리 생성된 피처를 조회하고, 온디맨드 피처는 Python UDF를 실행하여 계산합니다.

기초 예제 - Average hover time

이 예제에서는 온디맨드 피처가 JSON 문자열을 파싱하여 웹 페이지에서의 호버 시간 목록을 추출합니다. 이 시간들의 평균을 구한 다음, 그 평균이 모델에 피처로 전달됩니다.

모델에 쿼리를 보내려면 호버 시간을 포함한 JSON 레코드를 전달하세요. 예를 들면:

curl \
  -u token:$DATABRICKS_TOKEN \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "dataframe_records": [
      {"json_blob": "{\"hover_time\": [5.5, 2.3, 10.3]}"}
    ]
  }' \
  <host>/serving-endpoints/<endpoint_name>/invocations

모델은 온디맨드 방식으로 평균 호버 시간을 계산한 다음, 평균 호버 시간을 피처로 사용하여 모델을 스코어링합니다.

Simple Demo

고급 예제 - Distance to restaurant

이 예제에서는 레스토랑 추천 모델이 사용자의 위치와 레스토랑 ID가 포함된 JSON 문자열을 사용합니다. 레스토랑의 위치는 Online Store에 게시된 미리 생성된 피처 테이블에서 조회되며, 온디맨드 피처는 사용자와 레스토랑 간의 거리를 계산합니다. 이 거리는 모델에 입력으로 전달됩니다.