백필 모범 사례

데이터 오류, 새로운 정보(예: 새로운 기능), 두 시스템 간의 데이터 조정 등 다양한 이유로 데이터를 백필해야 할 수 있습니다. 백필을 수행할 때는 이 문서의 원칙을 따라 데이터 품질과 모델 성능을 유지하세요.

백필이 필요한 경우

백필은 과거 데이터를 소급하여 데이터셋에 채우는 프로세스입니다. 일반적인 시나리오는 다음과 같습니다.

요구 사항

Decisioning Studio가 올바르게 작동하려면 모든 수신 데이터가 과거 기간에 대한 백필을 지원해야 합니다. 필요한 특정 조회 기간(월 단위)은 AI 모델의 학습 요구 사항에 따라 달라집니다. 사용 사례에 맞는 올바른 값을 확인하려면 인공지능 의사 결정 서비스 팀에 문의하세요.

과거 백필을 수행할 때 다음 표준은 필수입니다.

• 프로세스 일관성: 과거 기능 스냅샷은 라이브 스냅샷 생성과 완전히 일관된 프로세스를 사용하여 생성해야 합니다. 라이브 파이프라인에서 변환, 집계 또는 필터를 적용하는 경우, 백필 데이터에도 동일한 단계를 적용해야 합니다.
• 스키마 일관성: 백필 데이터의 스키마는 동일한 필드, 데이터 유형, 열 명명 규칙을 포함하여 일반 일일 파이프라인과 정확히 일치해야 합니다.

일반적인 실수

데이터 누출(미래 정보 편향)

데이터 누출은 가장 치명적인 백필 실수입니다. 백필 프로세스가 과거 레코드가 생성된 시점에는 사용할 수 없었을 정보를 의도치 않게 포함할 때 발생합니다.

왜 중요한가

모델이 “미래를 아는” 데이터로 학습하면 학습 중에는 성능이 좋아 보이지만, 실시간 의사 결정에서는 미래 데이터에 접근할 수 없기 때문에 프로덕션에서 좋지 않은 결과를 생성합니다.

예를 들어, 고객의 현재까지(즉, 오늘까지)의 총 지출을 사용하여 과거 “생애주기 가치” 기능을 계산한 다음, 그 값을 사용하여 몇 달 전에 발생한 행동을 예측하는 경우를 생각해 보세요. 해당 과거 이벤트 시점에는 전체 생애주기 가치가 아직 알려지지 않았습니다.

이를 방지하려면 항상 과거 타임스탬프 시점에 사용 가능했을 정보만 사용하여 과거 기능을 재구성하고, 이후에 축적된 정보는 사용하지 마세요.

스키마 및 로직 드리프트

데이터 구조와 비즈니스 정의는 시간이 지남에 따라 변화합니다. 과거 데이터와 라이브 데이터 간의 불일치는 모델 품질을 조용히 저하시킬 수 있습니다.

• 스키마 드리프트: 필드(예: zip_code)가 최근에 데이터베이스에 추가된 경우, 해당 변경 이전의 백필 레코드에는 해당 필드에 null이 포함됩니다. 파이프라인이 누락된 필드를 적절히 처리하고, 모델이 과거 데이터 범위가 희소한 필드에 과도하게 의존하지 않도록 하세요.
• 로직 드리프트: 측정기준의 정의가 특정 시점에 변경된 경우(예: “활성 사용자”가 2024년에 재정의됨), 새로운 정의를 이전 데이터(예: 2022년 레코드)에 일괄 적용하면 실제로 발생하지 않은 인위적인 급증이나 급감이 생길 수 있습니다. 가능하면 각 과거 레코드 시점에 유효했던 정의를 적용하거나, 모델이 이를 고려할 수 있도록 변경 시점을 명확히 문서화하세요.

실패한 백필 작업으로 인한 중복 레코드

중간에 실패하고 재시작된 백필 작업은 프로세스가 이를 방지하도록 설계되지 않은 경우 중복 레코드를 생성할 수 있습니다. 중복 레코드는 측정기준을 인위적으로 부풀리고 모델 학습에 노이즈를 유발합니다.

해결 방법: 모든 백필 스크립트를 멱등성(idempotent)으로 설계하세요. 동일한 작업을 두 번 실행해도 한 번 실행한 것과 동일한 결과를 생성해야 합니다. 다음 패턴 중 하나를 사용하세요.

• 업서트(업데이트 또는 삽입): 고유 트랜잭션 ID 또는 타임스탬프를 키로 사용하여, 기존 레코드를 다시 삽입하면 중복을 생성하는 대신 업데이트합니다.
• 삭제 후 삽입: 삽입 전에 대상 시간 범위의 기존 레코드를 삭제하여, 데이터셋이 항상 깔끔하게 교체되도록 합니다.