🌍

ba2.5.2.2. title: 모델 학습을 위한 데이터 전처리와 서빙되는 모델을 위한 데이터 전처리 파이프라인이 다르다는 문제가 있다. 이를 학습-서빙 왜곡이라고 한다. 전처리를 독립시켜 두는 방법, 모델에게 책임을 전가하여 전처리 파이프라인을 모델에 묶는 방법, 데이터에게 책임을 전가하여 전처리가 모두 완료된 데이터를 보장하는 방법이 있다.

생성

🚀 prev note

mlops.1_3.1__1. title: 머신러닝 모델 서빙 시 모델뿐 아니라 적절한 버전의 모델 전처리 후처리 과정 혹은 아티팩트를 함께 불러올 수 있어야 한다.

mlops.1_3.1__1__1. title: 전처리-예측 패턴(‣)이 제안하는대로 전처리 후처리 과정을 아티팩트로 다운로드받는 것이 아니라 마이크로서비스로 쪼개어 API 로 통신하도록 만들 수 있다.

deer.a7.3_5_2. title: 케라스의 preprocessing 레이어가 추구하는 것처럼, 전처리과정을 모델의 레이어 하나로 취급한다면 전처리와 모델을 별도로 관리할 필요가 없어 관리 및 서빙이 간단해진다.

♻️ prev note

ba2.5.2.2. title: 모델 학습을 위한 데이터 전처리와 서빙되는 모델을 위한 데이터 전처리 파이프라인이 다르다는 문제가 있다. 이를 학습-서빙 왜곡이라고 한다. 전처리를 독립시켜 두는 방법, 모델에게 책임을 전가하여 전처리 파이프라인을 모델에 묶는 방법, 데이터에게 책임을 전가하여 전처리가 모두 완료된 데이터를 보장하는 방법이 있다.

🚀 next note

♻️ next note

ba2.4.1. title: 피처 저장소(‣)는 모델에 입력될 수 있는 형태의 전처리 결과물 등을 재활용할 수 있도록 만들어둔 저장소이다.

14 more properties

모델 학습을 위한 데이터 전처리와 서빙되는 모델을 위한 데이터 전처리 파이프라인이 다르다는 문제가 있다. 이를 학습-서빙 왜곡이라고 한다(참고1). 모델에게 책임을 전가하여 전처리 파이프라인을 모델에 묶는 방법(TFT 프레임워크(참고2), Keras Preprocessing 레이어 사용), 데이터에게 책임을 전가하여 전처리가 모두 완료된 데이터를 보장하는 방법(피처 스토어 도입) 등이 있다(참고3).

물론 TFT, 피처 스토어 등을 도입하기 전에 반드시 이것들이 필요한지 고민해볼 필요가 있다. 훨씬 단순하고 간단하게 처리가 가능한 부분을 복잡하게 풀지 말자. 가장 린한 방법은 전처리를 독립된 함수(참고4) 혹은 마이크로서비스로 독립시켜 두는 방법이다(참고5).

parse me : 언젠가 이 글에 쓰이면 좋을 것 같은 재료들.

None

from : 과거의 어떤 생각이 이 생각을 만들었는가?

mlops.1_3.1__1. title:
머신러닝 모델 서빙 시 모델뿐 아니라 적절한 버전의 모델 전처리 후처리 과정 혹은 아티팩트를 함께 불러올 수 있어야 한다.

•

문제를 처음 발견하게 된 시점은 위 프로젝트를 진행하면서라고 볼 수 있다.

•

모델 서빙에서 발생하는 문제라고 바라볼 수 있다.

ba2.4.1. title:
피처 저장소(‣)는 모델에 입력될 수 있는 형태의 전처리 결과물 등을 재활용할 수 있도록 만들어둔 저장소이다.

•

피처 스토어는 머신러닝 엔지니어 입장에서 ‘곧바로 모델에 입력될 수 있는 형태’로 데이터가 저장된 최고의 데이터 원천이다.

deer.a7.3_5_2. title:
케라스의 preprocessing 레이어가 추구하는 것처럼, 전처리과정을 모델의 레이어 하나로 취급한다면 전처리와 모델을 별도로 관리할 필요가 없어 관리 및 서빙이 간단해진다.

•

케라스의 preprocessing 레이어

mlops.1_3.1__1__1. title:
전처리-예측 패턴(‣)이 제안하는대로 전처리 후처리 과정을 아티팩트로 다운로드받는 것이 아니라 마이크로서비스로 쪼개어 API 로 통신하도록 만들 수 있다.

supplementary : 어떤 새로운 생각이 이 문서에 작성된 생각을 뒷받침하는가?

None

opposite : 어떤 새로운 생각이 이 문서에 작성된 생각과 대조되는가?

None

to : 이 문서에 작성된 생각이 어떤 생각으로 발전되고 이어지는가?

None

참고 : 레퍼런스

109p, 모델 학습 중에 사용한 전처리 단계가 추론 중에 사용한 단계와 일치하지 않는 것을 ‘학습-서빙 왜곡’이라고 한다. 모델을 학습시킬 때 사용하는 데이터는 판다스, 파이썬 노트북, 스파크 환경에서 처리된다. 모델이 배포되면 API단에 전처리 단계가 구현된다. 이 두 프로세스들의 단계들이 항상 일치하도록 조정해야 (양쪽을 모두 관리해야) 한다.

108p, TFT를 이용해 데이터 전처리를 표준화해야 하는 이유는 다음과 같습니다. (1) 전체 데이터셋의 콘텍스트에서 데이터를 효율적으로 처리합니다. (2) 전처리 단계를 효과적으로 확장합니다. (3) 잠재적인 학습-서빙 왜곡을 방지합니다.

Skew: we may have different pipelines for generating features for training and serving which can introduce skew through the subtle differences. Solution: create features using a unified pipeline and store them in a central location that the training and serving pipelines pull from.

Skew: … if our transformations can be tied to the model or as a standalone function, then we can just reuse the same pipelines to produce the feature values for training and serving.

Duplication: if we don't have too many ML applications/models, we don't really need to add the additional complexity of a feature store to manage transformations. All the feature transformations can be done directly inside the model processing or as a separate function. We could even organize these transformations in a separate central repository for other team members to use.