Feature Views로 실시간 사기 탐지

실시간 사기 탐지는 고객이 몇 초 전에 한 행동, 평소 지출 패턴, 그리고 현재 결제 건의 비교라는 세 가지 유형의 특성에 따라 달라집니다. 이러한 특성은 모델 학습과 라이브 서빙에서 동일한 방식으로 계산되어야 합니다. 그렇지 않으면 데이터 유출과 학습-서빙 간 편향으로 인해 모델 품질이 서서히 저하됩니다. Databricks Feature Store의 일부인 Feature Views는 이 문제를 해결합니다. 각 특성을 한 번만 정의하면, 해당 정의가 시점 정확성이 보장되는 학습 데이터와 온라인 추론을 위한 관리형 파이프라인을 모두 생성합니다.

900달러의 결제는 어떤 고객에게는 일상적일 수 있지만 다른 고객에게는 비정상적일 수 있습니다. 결제 요청이 들어오면 사기 탐지 모델은 이것이 정상인지, 검토가 필요한지, 아니면 차단해야 하는지 판단할 시간이 잠시밖에 없습니다. 정상적인 사기 거래를 승인하면 고객에게 금전적 손실이 발생할 수 있습니다. 합법적인 거래를 차단하면 결제 경험이 훼손되고 플랫폼에 대한 신뢰가 떨어집니다.

거래 내역만으로는 전체 상황을 파악할 수 없습니다. 모델은 또한 이 고객이 평소에 어떻게 거래하며 몇 초, 몇 분, 몇 일 또는 몇 주 전에 무엇을 했는지 알아야 합니다. 학습 과정에서 특성은 각 결제가 발생했을 때 사용 가능한 정보만 사용해야 합니다. 라이브 서빙 중에는 의심스러운 활동을 잡아낼 수 있을 만큼 빠르게 최근 거래를 반영해야 합니다. 두 경로가 로직을 별도로 구현하면 미세한 차이가 발생하게 됩니다.

이 가이드는 Kafka 스트림의 900달러 결제 건부터 Model Serving에서 제공하는 사기 점수까지 각 단계의 코드와 함께 추적합니다. 핵심 아이디어는 학습과 서빙을 모두 구동하는 하나의 특성 정의를 통해 시점 정확성이 보장되는 학습 데이터와 일관된 온라인 특성을 얻을 수 있다는 것입니다. 각 경로마다 별도의 파이프라인을 구축할 필요가 없습니다.

Feature View란 무엇인가요?

Feature View는 특성의 소스, 엔티티 키, 시간 의미론 및 변환을 지정하는 Databricks Feature Store 정의입니다. 동일한 정의가 학습을 위한 과거 값을 계산하고 서빙을 위해 특성을 최신 상태로 유지하는 관리형 파이프라인을 구동합니다. 하나의 API가 배치, 스트리밍 및 온디맨드 특성을 모두 지원합니다. Unity Catalog가 이들의 정의, 권한 및 리니지를 관리합니다.

이 디자인이 고안된 이유는 두 가지 실패 모드 때문입니다:

• Training-serving skew는 특성이 학습 시와 프로덕션 시에 서로 다르게 계산될 때 발생합니다. 이 경우 추론 시점에 모델은 학습한 내용과 일치하지 않는 입력을 보게 됩니다.
• Data leakage는 학습 데이터에 예측 시점에 사용할 수 없었던 정보가 포함될 때 발생합니다. 시점 정확성이 보장되는 특성은 예측 시점 이전에 발생한 이벤트만 사용하여 이를 방지합니다.

Feature Views를 사용하면 스트리밍 특성 계산을 과거 학습 및 라이브 서빙과 동일한 데이터 과학 워크플로에 통합할 수 있습니다. 과거 거래를 바탕으로 특성을 평가한 다음, 동일한 정의를 사용하여 라이브 의사 결정을 위해 고객 컨텍스트를 최신 상태로 유지할 수 있습니다.

실시간 사기 탐지 모델에는 어떤 특성이 필요할까요?

목표는 합법적인 결제에 대해 오탐을 발생시키지 않고 의심스러운 결제가 들어오는 즉시 잡아내는 것입니다. 900달러 결제 자체는 무해해 보일 수 있습니다. 하지만 5분 내에 10번째 결제라면 의심스러운 급증의 일부일 수 있습니다. 해당 급증을 인식하는 데 지연이 발생할수록 손상된 계정에 접근한 사람이 추가 결제를 할 수 있는 시간이 늘어납니다.

Databricks Apps로 구축된 사기 탐지 애플리케이션은 금융 거래 스트림을 처리합니다. 각 이벤트에는 고객 ID, 금액, 결제 유형, 타임스탬프, 출발지 및 도착지 국가가 포함됩니다. 애플리케이션은 각 거래를 Model Serving 엔드포인트로 보냅니다. 그런 다음 라이브 거래량, 플래그가 지정된 거래, 국가 간 흐름과 함께 해당 거래의 위험 점수를 표시합니다.
 

모델은 세 가지 유형의 컨텍스트를 결합합니다:

• 최근 활동: RollingWindow를 사용하여 계산된 5분 거래 건수와 10분 총 금액으로 고객의 결제 빈도와 지출 규모를 포착합니다.
• 지출 기준선: SawtoothWindow로 유지되는 30일 평균 및 표준 편차로 고객의 일반적인 결제 금액과 변동 폭을 설명합니다.
• 거래 세부 정보: 현재 결제의 금액, 결제 유형, 출발지 및 도착지 국가가 의사 결정을 위한 컨텍스트를 제공합니다.

이 아키텍처에는 학습을 위한 과거 경로와 추론을 위한 온라인 경로가 있습니다. 두 경로 모두 Unity Catalog의 동일한 특성 정의에서 시작됩니다. 과거 경로는 Stream의 수집 테이블을 읽어 시점 정확한 학습 세트를 빌드합니다. 온라인 경로는 집계 값을 Online Feature Store에 구체화하고, Model Serving은 요청 시점에 이를 읽습니다.

Kafka에서 스트리밍 특성을 정의하는 방법

서빙할 특성을 결정하기 전에 과거 거래를 기준으로 대안을 테스트할 수 있습니다. 5분 거래 건수가 15분 건수보다 더 강력한 신호를 제공할까요? 현재 금액을 고객의 지출 변동성과 비교하는 것이 평균만 사용하는 것보다 도움이 될까요?

이 예시에서 고객 거래 이벤트는 Kafka 스트림으로 들어옵니다. 등록된 Stream은 연결, 스키마 및 수집 설정을 유지하며, StreamSource는 이를 참조하여 실시간 특성을 계산합니다. Kafka 토픽은 모델 학습에 필요한 만큼의 과거 데이터를 유지하지 않습니다. 따라서 Databricks는 수집 테이블에서 스트림의 오프라인 복사본을 관리합니다. 학습이나 온라인 스토어 백필을 위해 Databricks는 수집 테이블에서 과거 값을 계산하고 최신 데이터에는 라이브 Kafka 피드를 사용합니다.

수집 시 transformation_sql는 Kafka 값 페이로드의 중첩된 필드를 특성에 필요한 스키마로 재구성합니다. 이 프로젝션은 소스 정의의 일부가 되므로 별도의 전처리 파이프라인을 배포할 필요가 없습니다. 우리의 결제 건에 대해 Kafka 값 페이로드에는 다음이 포함됩니다:

데모에서는 demo_user_id을 customer_id과 함께 사용하여 서로 다른 앱 사용자의 고객 기록을 분리합니다.

 RollingWindow를 사용하여 5분 건수를 정의합니다. 동봉된 노트북에는 임포트, 설정 및 전체 소스 프로젝션이 포함되어 있습니다.

노트북에서 compute_features(features=[recent_transaction_count])을 사용하여 과거 값을 검사할 수 있습니다. 10분 총계는 동일한 소스와 키를 사용하며, 10분 RollingWindow에 대해 Sum을 적용합니다.

톱니바퀴 창(Sawtooth window)은 가장 오래된 경계가 매일 단계적으로 전진하는 장기 룩백 집계입니다. 배치로 계산된 과거 데이터와 최근 활동에 대한 스트리밍 업데이트를 결합합니다. 900달러 결제 건의 경우, SawtoothWindow은 짧은 롤링 윈도우에 30일 지출 기준선을 추가합니다. 두 종류의 윈도우 모두 최근 활동을 최신 상태로 유지합니다. 톱니바퀴 창의 가장 오래된 경계가 지속적으로 움직이지 않고 매일 이동하기 때문에, 유효한 룩백 기간은 30일보다 약간 더 깁니다. 기준선은 동일한 톱니바퀴 창의 결제 금액에 대해 기본 제공되는 Avg, StddevPop 및 Count 집계를 사용합니다.

Databricks는 Stream이 생성될 때 관리형 수집 파이프라인을 시작하고 수신되는 이벤트를 수집 테이블에 유지합니다. Stream이 존재하기 전의 이벤트도 필요한 경우, StreamBackfillSource을 사용하면 Stream 설정 중에 고유한 기록을 제공할 수 있습니다. 테이블이 전체 룩백을 커버하게 되면, 새로운 Sawtooth 특성은 이벤트가 쌓일 때까지 30일을 기다릴 필요 없이 즉시 사용할 수 있습니다.

실시간 결제 금액과 고객의 기준치 비교 방법

주문형(on-demand) 피처는 스코어링 요청 시점의 값과 저장된 피처를 결합하여 요청 시점에 계산됩니다. 실시간 거래를 고객의 과거 기준치와 비교하는 것은 비정상적인 행동을 찾아내는 일반적인 방법입니다. Feature Views에서는 추론 시점의 정보가 RequestSource(여기서는 애플리케이션 요청의 transaction_amount)으로 표현됩니다.

두 고객 모두 결제당 평균 $300를 기록하더라도 소비 패턴은 크게 다를 수 있습니다. 표준편차가 각각 $100와 $600일 때, 동일한 $900의 결제는 한 고객의 평균에서 표준편차 6배 위에 위치하지만 다른 고객의 평균에서는 단 1배 위에 위치합니다. 모델은 이러한 비교를 최근 활동 및 결제 세부 정보와 결합하여 사기 위험을 예측합니다.

Sawtooth 집계는 30일 평균과 표준편차를 유지합니다. 주문형 피처는 이를 현재 금액과 결합하여 (current_amount - average) / standard_deviation을(를) 계산합니다. 우리는 Unity Catalog에 등록된 Python UDF로 이 계산을 구현합니다:

피처 정의는 등록된 업스트림 Feature 객체를 사용합니다. FeatureViewSource은(는) 현재 금액과 세 가지 30일 통계를 결합하고, CustomUDF은(는) 함수를 호출합니다:

사용 가능한 이력이 충분하지 않은 경우, 함수는 대체 값(fallback)으로 0을 반환합니다. 별도의 지표를 통해 모델은 해당 대체 값을 결제가 고객의 평균과 일치함을 의미하는 진정한 0과 구분할 수 있습니다. 동일한 파생 피처는 학습 중에는 과거 입력 데이터를 대상으로, 추론 중에는 현재 요청과 검색된 통계를 대상으로 평가됩니다.

배포 전에 피처 후보를 테스트하는 방법

피처 개발 과정에서 compute_features()을(를) 사용하여 노트북에서 피처 정의를 검사할 수 있습니다. 이는 입력 데이터가 전적으로 과거 소스 데이터에서 비롯된 파생 피처에 작동합니다.  amount_deviation과(와) 같이 요청에 종속된 비교의 경우, 대신 create_training_set()을(를) 사용하세요. 이 도구는 레이블이 지정된 예시에서 현재 결제 필드를 제공합니다. Unity Catalog 함수가 존재해야 하지만, 후보를 테스트하는 동안 피처 정의는 등록되지 않은 상태로 둘 수 있습니다.

이를 통해 라이브 스코어링을 위해 배포하기 전에 피처가 사기 탐지 모델의 오프라인 성능을 향상시키는지 확인할 수 있습니다. 예를 들어, 이후의 홀드아웃(held-out) 결제 데이터를 대상으로  amount_deviation의 포함 여부에 따른 모델을 비교할 수 있습니다. 이러한 실험은 거래 이력에 대한 배치 컴퓨팅에서 실행되므로, 온라인 실체화(materialization)를 설정하지 않고도 각 후보를 평가할 수 있습니다. 피처를 선택한 후에는 그 정의를 등록하고 서빙을 위한 롤링 및 Sawtooth 집계를 실체화하세요.

point-in-time이 올바른 학습 데이터를 구축하는 방법

각각의 과거 학습 예시는 해당 결제의 타임스탬프 기준으로 계산된 피처가 필요합니다. 오전 10:00에 발생한 $900 결제의 경우, 5분 카운트에는 오전 9:55부터 오전 10:00까지(오전 10:00 미포함)의 거래가 포함되어야 합니다. 오전 10:03에 검색된 카운트에는 원래 결제가 스코어링될 때 사용할 수 없었던 오전 10:02의 결제가 포함될 수 있습니다. 이는 데이터 누수(data leakage)에 해당합니다. 모델이 미래의 활동으로부터 학습하게 되며 오프라인 성능이 실제보다 더 좋아 보이게 됩니다. Feature Views는 각 예시의 고객 키와 타임스탬프를 사용하여 Stream의 인테이션 테이블에 있는 이벤트로부터 올바른 과거 윈도우를 계산합니다.

선택한 피처를 등록한 후, create_training_set()이(가) 모델의 학습 데이터를 구축합니다. 레이블이 지정된 DataFrame은 고객 키, 이벤트 시간, 현재 결제 필드 및 is_fraud을(를) 제공합니다. 이 발췌문은 30일 기준치를 포함하여 연습용으로 등록된 피처를 선택하고, 학습을 위해 지정된 컷오프 이전의 행을 사용합니다:

키와 타임스탬프는 고객 이력을 선택하지만 모델 입력에서는 제외됩니다. 요청 필드는 피처 계산에 공급되며, 분류기는 그 결과로 생성된 명명된 피처를 사용합니다. 이후의 행들은 동일한 정의를 사용하여 검증 세트를 형성합니다.

랜덤 포레스트(random-forest) 분류기를 학습시키고 후자 데이터에 대해 평균 정밀도(average precision)와 ROC AUC를 평가합니다. 그런 다음 Feature Engineering 클라이언트를 통해 모델을 로깅합니다. training_set=train_set을(를) 전달하면 서빙에 필요한 피처 종속성이 기록됩니다:

온라인 추론을 위해 실시간 피처를 서빙하는 방법

위에서 선택한 피처를 라이브 스코어링으로 이동하려면 스트리밍 집계를 유지 관리하고, 과거 데이터를 처리하며, 온라인 스토어를 최신 상태로 유지하는 파이프라인이 필요합니다. 이러한 파이프라인을 구축하고 운영하는 것은 사기 탐지 모델을 개발하는 것 외에도 수개월의 데이터 엔지니어링 작업을 추가합니다. Feature Views를 사용하면 등록된 피처 정의가 이 프로세스를 구동합니다. 즉, materialize_features()을(를) 호출하면 Lakebase가 지원하는 Databricks Online Feature Store에서 집계를 사용할 수 있도록 관리되는 파이프라인이 생성됩니다.

스트리밍 경로는 Spark Real-Time Mode (RTM)을(를) 사용하여 들어오는 이벤트를 지속적으로 처리하고 도착하는 대로 롤링 집계를 업데이트합니다.

롤링 및 Sawtooth 집계를 실체화합니다. 30일 Sawtooth 기준치의 경우, Databricks는 배치 컴퓨팅으로 과거 부분을, 스트리밍으로 최근 활동을 유지 관리합니다. 두 경로는 읽기 시점에 단일 피처로 병합되며, StreamingMode()은(를) 별도의 배치 호출 없이 이 하이브리드 경로를 관리합니다. 서빙하기 전에 Catalog Explorer에서 두 실체화 경로를 모두 확인하세요. Sawtooth 가이드에서는 프로덕션 환경에서 사용하기 전에 온전한 이틀을 기다릴 것을 권장합니다.

RequestSource은 각 스코어링 요청에서 값을 제공하며, 파생 피처는 온디맨드로 계산됩니다. 모델이 배포되면 애플리케이션은 고객 키와 현재 결제 필드를 엔드포인트로 보냅니다. Model Serving은 최신 고객 피처를 가져와 온디맨드 편차를 평가한 다음, 입력값을 사기 탐지 모델로 전달합니다. 스코어러의 SDK 호출을 사용한 앱 요청 형식의 $900 결제 건은 다음과 같습니다:

앱은 이 요청에서 event_time을(를) 전송하지만, 온라인 조회는 해당 타임스탬프가 선택한 과거 스냅샷이 아닌 사용 가능한 최신 고객 피처를 사용합니다. 이 데모에서 앱은 각 결제를 Kafka에 발행하기 전에 스코어링합니다. 이렇게 하면 현재 결제가 자체 기록에 포함되지 않으므로, 학습 윈도우에서 해당 결제를 제외하는 방식과 일치하게 됩니다. 피처 업데이트와 스코어링은 여전히 비동기식으로 실행되므로, 다음 결제가 스코어링될 때 다른 이벤트가 진행 중일 수 있습니다.

엔드포인트는 fraud_probability에 확률을, fraud_prediction에 플래그를 반환합니다. 애플리케이션은 스코어링된 트랜잭션을 대시보드용 Lakebase에 저장합니다.

Unity Catalog에서 ML 피처를 거버넌스하는 방법

프로덕션 사기 탐지 모델은 어떤 모델이 피처를 사용하고, 피처가 어디에서 오며, 누가 읽을 수 있는지와 같은 거버넌스 관련 질문을 제기합니다. Unity Catalog는 피처 정의, 권한, 리니지를 하나로 모아 이러한 질문에 답합니다. MLflow는 각 모델이 사용하는 피처를 기록하며, Model Serving은 추론 요청을 처리할 때 이러한 종속성을 사용합니다.

피처 권한은 라이프사이클을 제어합니다:

• CREATE FEATURE은(는) 등록을 제어합니다.
• READ FEATURE은(는) 피처 메타데이터에 대한 액세스 권한을 부여합니다.
• MANAGE은(는) 구체화(materialization) 같은 작업을 승인합니다.

피처 권한은 학습 및 서빙을 위해 소스 또는 구체화된 테이블에 필요한 SELECT 권한을 대체하지 않습니다.

Catalog Explorer에서 Feature Views는 정의, 소스 링크, 구체화된 테이블, 상태와 함께 Functions 아래에 표시됩니다. 스트리밍 구체화는 검사를 위해 시스템 관리형 Lakeflow 파이프라인에 연결됩니다. 구체화 태그를 사용하면 팀이 파이프라인 또는 작업 컴퓨팅 비용을 특정 팀이나 프로젝트에 귀속시킬 수 있습니다.

실시간 사기 탐지를 위한 주요 시사점

이제 $900 결제에 맥락이 부여됩니다. 즉, 최근 활동, 장기적인 기준선, 현재 요청입니다. 다음 세 가지 관행이 이를 가능하게 했습니다:

• 한 번 정의하고 두 번 사용하기. 학습과 서빙에 공유 피처 정의를 사용하면 별도의 구현으로 인해 발생하는 학습-서빙 간극(skew)을 줄일 수 있습니다.
• 시점(point-in-time) 계산. 미래 이벤트를 제외하는 학습 윈도우는 데이터 누수를 방지하고 오프라인 지표를 신뢰할 수 있게 유지합니다.
• 플랫폼이 파이프라인을 실행하도록 하기. 구체화와 온라인 조회가 관리되므로, 더 나은 사기 탐지 신호를 선택하는 작업에 집중할 수 있습니다.

동일한 패턴이 이 연습을 넘어 확장됩니다. LastN은(는) 고객의 최근 10개 결제 건의 목적지 국가와 같은 시퀀스를 유지하여 모델이 결제 경로의 변경 사항을 파악하는 데 도움을 줍니다. 배치 피처는 또한 생애 주기 집계를 사용하여 엔티티의 전체 기록을 요약할 수 있습니다.

1초 미만의 스트리밍 신선도 뒤에 숨겨진 인프라를 자세히 알아보려면 Databricks Feature Store가 1초 미만의 신선도로 피처를 서빙하는 방법을 읽어보세요. 구현 세부 정보는 다음 문서를 참조하세요: Feature Views API, 구체화, 그리고 Unity Catalog에서 Feature Views 탐색하기.

FAQ

Databricks Feature Views란 무엇인가요?

Feature Views는 ML 피처를 한 번 정의하고 학습과 프로덕션 모두에서 사용할 수 있는 Databricks Feature Store의 기능입니다. 각 정의는 소스, 엔티티 키, 시간 의미론(time semantics), 변환을 지정합니다. 동일한 API가 배치, 스트리밍, 온디맨드 피처를 모두 다루며 Unity Catalog가 이를 거버넌스합니다.

Feature Views는 사기 탐지 모델을 학습할 때 데이터 누수를 어떻게 방지하나요?

Feature Views는 각 학습 예시의 타임스탬프를 기준으로 해당 예시의 피처를 계산합니다. 오전 10:00 결제의 경우, 5분 트랜잭션 카운트에는 오전 9:55부터 오전 10:00 "직전"까지의 결제가 포함됩니다. 이를 통해 미래 활동이 학습 데이터에 들어가지 않도록 하여 오프라인 성능이 부풀려지지 않게 합니다.

학습-서빙 간극(skew)이란 무엇이며 Feature Views는 이를 어떻게 줄이나요?

학습-서빙 간극은 학습용으로 피처를 계산하는 방식과 실시간 추론용으로 계산하는 방식이 다를 때 발생합니다. Feature Views는 과거 계산과 온라인 구체화 모두에 하나의 등록된 정의를 사용하여 이를 줄입니다. 팀이 프로덕션을 위해 피처 로직을 다시 구현할 필요가 없습니다.

Feature Views는 Kafka 스트림에서 피처를 계산할 수 있나요?

네. 등록된 Stream은 Kafka 연결, 스키마, 수집 설정을 유지하며, StreamSource은(는) 피처 정의에서 이를 참조합니다. Databricks는 학습 및 백필을 위해 수집 테이블에 스트림의 오프라인 복사본을 유지합니다. Real-Time Mode는새 이벤트가 도착할 때마다 스트리밍 집계를 업데이트합니다.

프로덕션 환경의 사기 탐지 모델에 실시간 피처가 어떻게 서빙되나요?

materialize_features()을(를) 호출하면 Lakebase로 구동되는 Online Feature Store에서 집계가 최신 상태로 유지되도록 관리되는 파이프라인이 생성됩니다. 모델이 log_model()(으)로 로깅되고 Model Serving에 배포되면, 엔드포인트는 최신 고객 피처를 가져와 요청에서 온디맨드 피처를 계산합니다. 그런 다음 사기 확률을 반환합니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)