MLOps 를 위한 인프라와 도구

여기서는 ML 개발과 유지보수, 개선과 관련한 도구들과 인프라에 대해서 살펴보는 시간임

 

각 회사가 사용하는 ML 수준에 따라 인프라와 도구들의 요구사항은 다를거임:

• 그냥 단순히 내년 고객 예측을 하는데 ML 을 쓴다면 그냥 주피터 노트북으로만 사용해도 됨.
• 그러나 테슬라와 같은 자율주행 어플리케이션을 만들고 엄격한 정확도와 레이턴시를 요구하는 ML 이라면 인프라가 제대로 되어있어야 할 것.

 

여기서 MLOps 를 위한 인프라는 총 4개의 레이어로 구분함:

• 스토로지와 컴퓨팅: 데이터가 수집되고 저장되는 스토로지와 모델 훈련, 피처 생성, 피처 연산 등을 이용하는 컴퓨팅 레이어
• 자원 관리: ML 개발을 위한 워크 플로우의 일정 조절과 오케스트레이션을 할 수 있는 레이어를 말함. (e.g Airflow, Kubeflow, Metaflow 등을 말한다.)
• ML 플랫폼: ML 개발을 위한 편리한 도구들을 말한다. 모델 스토어, 피처 스토어, 모니터링 도구 등 (e.g SageMaker, MLFlow 등)
• 개발 환경: IDE 같은 개발 환경을 말함.

 

클라우드가 들어오게 되면서 주어진 자원에서 최대의 효율을 내는 것보다 비용 효율적을 추구하는 방향으로 좀 바뀜:

• 엔지니어의 생산성을 올릴 수 있다면 좀 더 많은 클라우드 비용을 내는 건 괜찮다는 의미인듯.

 

 

스토로지와 컴퓨팅

별 내용 없음. PASS

 

 

개발 환경

• 코드 버전 관리로 Git
• 데이터 버전 관리로 DVC (Data Version Control)
• 개발 중 실험 추적을 위해 웨이츠 앤 바이어시스 (Weight & Biasis) 또는 Comet.ml
• 배포 시 모델 아티팩트 추적을 위해 MLflow
• CI/CD 테스트를 위해 Github Actions 또는 CircleCI
• 똑같은 파이썬 언어 버전
• 똑같은 클라우드 개발 IDE (클라우드에서 개발 IDE 를 사용하고 로컬에서 연결해서 쓸 수 있다는듯.)
• 컨테이너로 도커, 컨테이너 오케스트레이션으로는 K8s

 

 

Q) 웨이츠 앤 바이어시스 (Weight & Biasis) 또는 Comet.ml 이 무엇인가?

 

머신러닝 실험 관리와 모델 성능 추적을 위한 플랫폼임.

 

데이터 과학자와 개발자가 모델 실험을 조직하고, 비교하고, 시각화하는 데 도움을 주어 머신러닝 프로젝트의 효율성과 재현성을 향상시킴.

 

Weights & Biases (W&B):

• 머신러닝 실험을 추적하고 모델을 최적화하기 위한 플랫폼임
• 사용자는 실험 설정, 하이퍼파라미터, 훈련 손실 및 기타 중요 메트릭스를 기록할 수 있음.
• 이 데이터는 클라우드 기반 대시보드에서 접근 가능하며, 프로젝트 진행 상황을 팀원과 공유하거나 협업할 수 있다.

 

 

자원 관리

크론, 스케줄러, 오케스트레이터

ML 워크 플로우 관리에서 중요한 특징:

• 반복성 (특정 시간/주기마다 작업을 실행하도록 하는 것)
• 종속성 (특정 작업이 끝난 후 새 작업을 시작하도록 하거나, 특정 작업이 실패했을 때 어떤 작업을 수행하도록 하는 것)

 

대략적인 ML 워크 플로우:

• 1. 데이터 웨어하우스에서 데이터를 가져옴.
• 2. 가져온 데이터에서 피처를 추출함.
• 3. 추출한 피처로 두 모델 A 와 B 를 비교함.
• 4. 테스트 세트에서 A 와 B 를 비교함.
• 5. A 가 더 나으면 A 를 배포하고, B 가 더 나으면 B 를 배포한다.

 

크론의 역할:

• 시간 주기별로 작업을 실행하는 것이 다임. (반복성만 있는 것.)
• 물론 종속성도 크론에서 넣어줄 수 있으나, 복잡한 종속성은 넣기 힘들다.

 

스케줄러의 역할:

• ML 워크 플로우는 작업이 DAG (방향성 그래프) 로 구성되어 있는데 해당 작업들을 실행시킬 수 있는 것. + 반복성 특성도 있는 걸 말한다.
• 특정 이벤트가 발생했을 때도 작업을 실행할 수도 있다.
• 작업을 실행할 때 필요한 자원을 할당하는 것도 스케줄러의 역할이다. 영리한 스케줄러는 사용자가 명시한 자원이 활용되지 않고 있을 때 이를 회수해서 다른 곳에 자원을 쓰기도 한다. 구글의 보그 (Borg) 가 이렇게 함.

 

슬럼 (Slurm) 스케줄러 예시:

#! /bin/bash
#SBATCH -J JobName
#SBATCH --time=10:00:00        # 작업을 시작할 시간 
#SBATCH --mem-per-cpu=4096     # CPU 당 할당할 메모리 
#SBATCH --cpus-per-tasks=4     # 작업 당 코어 개수 

 

오케스트레이터:

• 스케줄러는 자원을가지고 정기적으로 작업을 실행한다면, 오케스트레이터는 해당 총 자원을 관리하는 역할을 한다. 그래서 가용한 인스턴스 보다 더 많은 작업이 존재한다면 인스턴스를 늘리기도 한다.
• 스케줄러는 정기적으로 실행하는 느낌이라면 오케스트레이터는 요청과 응답을 주고 받고, 장기적인 서버 실행과도 관련이 있다.
• 오케스트레이터는 좀 더 넓은 의미를 가지고 있음. 서버를 스케일링 하는 기능, 복구하는 기능도 가지고 있다.

 

 

Q) Kubeflow 와 Airflow 는 스케줄러인가?

 

Airflow:

• 일단 Airflow 는 스케줄러로 분류할 수 있다.
• Airflow는 데이터 파이프라인을 관리하고, 정기적으로 실행되어야 하는 데이터 처리 작업을 스케줄링하는 데 사용된다.
• 즉 이는 복잡한 데이터 흐름을 위한 DAGs (Directed Acyclic Graphs)를 사용하여 작업의 종속성을 설정하고 실행 순서를 관리한다.
• Airflow는 ETL 작업, 데이터 보고서 생성, 데이터베이스 유지 관리 등 다양한 데이터 중심 작업의 자동화와 스케줄링에 사용할 수 있다.

 

Kubeflow:

• Kubeflow 는 오케스트레이터에 가깝다.
• Kubeflow는 쿠버네티스(Kubernetes) 위에서 운영되며, 머신러닝 워크플로를 효율적으로 배포하고 관리한다. k8s 위에서 동작하긴 하나 전체 머신러닝 파이프라인을 자동화하고 자원을 관리하는 역할을 하기 때문에 오케스트레이터에 가까움.
• 이건 머신러닝 모델의 학습, 평가, 배포 및 모니터링 등을 포함한 전체 머신러닝 파이프라인을 조정하고 자동화하는데 사용된다.

 

 

자원 관리 도구들 (Airflow -> 프리팩트 -> Argo, Kubeflow, Metaflow)

Airflow 가 가장 먼저 만들어진 스케줄러 도구이다. 파이썬 코드로 작성할 수 있으며 코드로서의 설정 원칙 (Configuration as Code) 을 따른다.

 

Airflow 특징 또는 단점:

• Airflow 워크플로우는 일반적으로 하나의 스크립트 내에 정의된다.
• 사용자 매개변수를 DAG 에 넣는게 어렵다. 그래서 비슷한 류의 작업에 설정만 약간 달라지는 거라면 독립적인 워크 플로우 파일을 작성해야함.
• DAG 는 정적인 형태라서 작업 내부에서 일어나는 일들을 가지고 새로운 작업을 만드는 건 어렵다. 그나마 BranchPythonOperator와 같은 조건부 분기를 사용하여 사전에 정의된 작업을 가지고 작업을 실행하도록 만들 수 있을 뿐.
• Airflow 에서 작업을 각기 다른 컨테이너 환경에서 실행하는 것은 DockerOperator 를 통해 가능하긴 하지만 복잡한 문제가 있긴하다. (e.g Docker 이미지 관리, 네트워킹, 볼륨 마운트 문제 등. 이게 어려운건가 싶긴하네.)

 

프리팩트(Prefect) 는 Airflow 의 컨테이너 문제 빼고 해결함:

 

아고(Argo) 는 컨테이너 문제도 해결함. Yaml 로 워크 플로우를 작성하면 됨.

• Argo 는 K8s 에서만 실행할 수 있다.

 

Kubeflow 는 Argo 를 관리하고 실행하도록 해주는 도구임.

 

 

Q) Airflow 는 전체 워크 플로우를 모놀리식으로 패키징해서 전달한다고 하는데 그러면 이 패키징에서는 워크 플로우를 실행하는데 필요한 자원을 모두 할당해줘야해?

 

Airflow 자체는 작업을 실행할 때 필요한 컴퓨팅 자원을 직접 관리하거나 할당하지 않는다.

 

대신, Airflow는 작업 스케줄링과 워크플로 관리에 초점을 맞추며, 작업 실행은 대개 다음과 같은 외부 실행 환경애 따라 달라진다.

• 로컬 실행기(Local Executor): 각 작업을 로컬 머신의 별도 프로세스로 실행한다. 이 경우, 로컬 머신의 자원을 사용하게 된다.
• Kubernetes 실행기(Kubernetes Executor): 각 작업을 쿠버네티스의 별도 파드로 실행한다. 이 실행기를 사용하면 쿠버네티스 클러스터의 자원을 활용하여 필요에 따라 자동으로 스케일링할 수 있다.
• Celery 실행기(Celery Executor): Celery를 사용하여 분산된 작업 큐 시스템을 통해 여러 머신에 걸쳐 작업을 분산시킬 수 있다. 이 설정에서 각 작업에 대한 리소스 사용은 각 작업이 실행되는 머신의 리소스에 의존한다.

 

 

Q) 워크 플로우는 하나의 스크립트 내에서 설정되며 이건 하나의 컨테이너로서 실행이 된다는거지? 쿠버네티스 실행기를 이용하면 워크플로우는 하나의 파드로만 실행이 될 수 있다는 의미인가?

 

아니다.

 

Kubernetes 실행기를 사용하는 경우, 각 Airflow 작업은 쿠버네티스 클러스터 내에서 독립적인 파드로 실행된다.

 

이는 전체 워크플로우가 하나의 파드로 실행되는 것이 아니라, 워크플로우를 구성하는 각각의 단계(작업)가 각각의 파드로 실행된다는 의미임.

 

 

머신러닝 플랫폼

머신러닝 개발과 유지 보수에서 사용되는 공통된 도구들에 대해서 보자.

 

모델 배포

모델 배포는 모델과 모델이 사용하는 의존성들을 배포하고 엔드포인트를 노출해서 예측을 수행하도록 만드는 과정임.

 

모델 배포를 위한 다양한 도구들이 있음:

• AWS SageMaker
• GCP Vertex AI
• Azure Azure AI

배포 도구를 이용할 떈 중요한 건 온라인 예측과 배치 예측이 얼마나 쉬운지임. 온라인 예측이 좀 더 쉽다고 함.

 

그리고 모델을 배포할 땐 품질도 신경써야한다. 그래서 프로덕션 테스트를 잘 해야함.

 

 

Q) AWS SageMaker 를 통해 모델을 배포하는 과정을 직접 예시를 통해서 보고 싶다. 어떻게 되는거임?

 

1. 모델 준비하기

 

SageMaker에 배포할 모델을 준비하는 과정. Python을 사용한 모델 트레이닝 예시는 다음과 같다:

 

여기서는 TensorFlow 모델을 사용했지만, SageMaker는 PyTorch, MXNet, XGBoost 등 다양한 머신러닝 프레임워크를 지원한다.

import sagemaker
from sagemaker import get_execution_role
from sagemaker.tensorflow import TensorFlow

role = get_execution_role()
# TensorFlow를 사용하는 경우의 모델 정의
tensorflow_estimator = TensorFlow(entry_point='train.py', # 트레이닝 스크립트 파일
                                  role=role,
                                  instance_count=1, # 트레이닝에 사용할 인스턴스 수
                                  instance_type='ml.m5.large', # 인스턴스 타입
                                  framework_version='2.3.0', # TensorFlow 버전
                                  py_version='py37') # Python 버전

tensorflow_estimator.fit('s3://your-bucket-name/path/to/training/data')

 

 

2. 모델을 SageMaker로 업로드

 

트레이닝이 완료되면, 트레이닝된 모델은 자동으로 S3 버킷에 저장된다. 이 모델을 사용하여 SageMaker에 모델을 생성하고, 배포 준비를 하면 된다.

model_data = tensorflow_estimator.model_data
sagemaker_model = sagemaker.tensorflow.serving.Model(model_data=model_data,
                                                     role=role,
                                                     framework_version='2.3.0')

 

 

3. 모델 배포

 

마지막으로, 준비된 모델을 SageMaker 서비스에 배포한다. 이 과정은 모델을 실시간으로 예측 서비스할 수 있는 엔드포인트를 생성한다.

 

deploy 메소드를 호출할 때 HTTP 엔드포인트 즉 모델이 예측하는 uri 는 생성되는거임.

predictor = sagemaker_model.deploy(initial_instance_count=1, # 인스턴스 수
                                   instance_type='ml.m5.large') # 인스턴스 타입

 

 

4. 예측 수행

 

클라이언트에서는 HTTP 요청을 보내서 모델에 대한 예측을 받을 수 있다.

import requests
import json

# 엔드포인트 URL
url = 'https://<엔드포인트 URL>/v1/models/your-model:predict'

# 예측하고자 하는 데이터
data = {
    "instances": [1.0, 2.0, 5.0]
}

# 요청 헤더 설정
headers = {"Content-Type": "application/json"}

# POST 요청 보내기
response = requests.post(url, data=json.dumps(data), headers=headers)

# 응답 결과 출력
print(response.json())

 

 

 

Q) AWS SageMaker 를 통해 모델을 배포할 경우 모델이 사용하는 리소스 관리는 어떻게 되는거야?

 

EC2 인스턴스를 이용해서 관리됨.

 

모델을 배포할 때 선택하는 인스턴스 유형에 따라 CPU, GPU, 메모리, 네트워킹 성능 등의 리소스가 결정됨.

 

SageMaker는 다양한 유형의 인스턴스를 제공하며, 모델의 크기와 예측 요구 사항에 맞게 선택할 수 있다.

 

예를 들어, GPU를 요구하는 딥 러닝 모델의 경우 ml.p3.2xlarge 같은 GPU 인스턴스를 선택할 수 있음.

 

 

Q) SageMaker 를 이용하는 경우에는 온라인 예측은 쉬우나 왜 배치 예측은 힘들어?

 

SageMaker 에서는 배치 예측도 지원한다. 배치 예측에 사용할 데이터를 저장하고, 모델을 배치 모드로 변경시키면 된다.

 

예시는 다음과 같음.

• output 경로에 배치 예측의 결과가 저장된다고 알면된다.

import sagemaker

# 세션 및 역할 설정
sagemaker_session = sagemaker.Session()
role = sagemaker.get_execution_role()

# 모델 초기화
model = sagemaker.model.Model(
    image_uri='container-image-uri-for-inference',
    model_data='s3://your-bucket/path/to/model.tar.gz',
    role=role,
    sagemaker_session=sagemaker_session)

# 배치 변환 작업 생성
transformer = model.transformer(
    instance_count=2,
    instance_type='ml.c5.2xlarge',
    strategy='MultiRecord',
    assemble_with='Line',
    output_path='s3://your-bucket/path/to/output')

# 배치 변환 작업 실행
transformer.transform(
    data='s3://your-bucket/path/to/input/data.csv',
    content_type='text/csv',
    split_type='Line')

 

 

Q) 배치 예측을 위해서는 Databricks 를 이용해야 한다는데 이게 뭐야?

 

Databricks는 빅데이터 분석, 기계 학습, 데이터 과학 및 관련 데이터 처리 작업을 위한 통합 플랫폼임.

 

Apache Spark를 기반으로 구축된 이 플랫폼은 클라우드 환경에서 대규모 데이터 세트를 처리하고 분석하는 데 특화되어 있다.

 

Databricks는 데이터 파이프라인 구축, 데이터 탐색, 실험적 모델링, 프로덕션 모델 배포 등 데이터의 전체 라이프사이클 관리가 가능함.

 

Databricks에서 배치 예측을 위한 예시:

• 아래 코드는 PySpark 및 MLflow를 사용한 예시이며, Databricks 환경에서 작업을 자동화하고 클러스터 리소스를 활용해 대규모 데이터에 대한 배치 예측을 수행하는 방법을 보여줌.
• Databricks 는 주피터 노트북 인터페이스 환경을 제공해준다. 그리고 여기서 PySpark, MLflow 등 ML 플랫폼 도구를 이용할 수 있음. Spark 같은 거 설치하지 않아도 됨.

 

1. 데이터 로드

데이터는 일반적으로 Databricks의 DBFS(Databricks File System)나 외부 클라우드 스토리지(S3, Azure Blob Storage 등)에서 로드한다.

# PySpark를 사용하여 데이터 로드
data = spark.read.csv("/mnt/your-storage/data.csv", header=True, inferSchema=True)

 

 

2. 데이터 전처리

 

필요한 데이터 변환, 결측치 처리, 특성 공학 등의 작업을 수행한다.

from pyspark.sql.functions import col

# 예시로 나이 데이터의 결측치를 평균 나이로 대체
mean_age = data.select(mean(col("age"))).collect()[0][0]
data = data.fillna(mean_age, subset=["age"])

 

 

3. 모델 로드

 

MLflow를 사용하여 저장된 모델을 로드하거나, 학습된 모델을 직접 불러온다.

import mlflow.pyfunc

model_uri = "runs:/<run_id>/model"
model = mlflow.pyfunc.load_model(model_uri)

 

 

4. 예측 실행

 

모델을 데이터에 적용하여 예측을 수행한다.

# PySpark UDF를 사용하여 예측 수행
from pyspark.sql.functions import udf
from pyspark.sql.types import FloatType

udf_predict = udf(lambda x: float(model.predict([x])[0]), FloatType())
predictions = data.withColumn("prediction", udf_predict(col("feature_column")))

 

 

5. 결과 저장

 

예측 결과를 DBFS, 외부 스토리지, 또는 데이터베이스에 저장한다.

predictions.write.format("csv").save("/mnt/your-storage/predictions/")

 

 

Q) K8s 에서도 모델을 개발하고 배포해서 예측에 사용하는 경우 예시도 보여줘.

 

K8s 에서만 모델을 개발하고 배포해서 예측에 사용하는 예시: (Kubeflow 미사용)

 

1. 모델 개발 및 컨테이너화

• 모델 개발: 사이킷런, 텐서플로우 등의 라이브러리를 사용하여 모델을 개발한다.
• 모델 학습: 학습 데이터를 사용하여 모델을 훈련시킨다.
• 모델 저장: 훈련된 모델을 파일 형태로 저장한다. (예: model.pkl).

import joblib
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris

# 데이터 로드 및 모델 학습
data = load_iris()
model = RandomForestClassifier()
model.fit(data.data, data.target)

# 모델 저장
joblib.dump(model, 'model.pkl')

 

 

2. Docker 이미지 생성: 모델을 실행할 Python 스크립트와 함께 Docker 이미지를 생성한다.

# Dockerfile
FROM python:3.8-slim
RUN pip install numpy scikit-learn joblib flask
COPY . /app
WORKDIR /app
EXPOSE 5000
CMD ["python", "app.py"]

 

 

3. Python 서버 스크립트 (app.py): Flask를 사용하여 모델을 로드하고 웹 서버를 실행한다.

from flask import Flask, request, jsonify
import joblib

app = Flask(__name__)
model = joblib.load('model.pkl')

@app.route('/predict', methods=['POST'])
def predict():
    data = request.get_json()
    prediction = model.predict([data['features']])
    return jsonify({'prediction': prediction.tolist()})

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

 

4. Kubernetes에 배포

• Docker 이미지 푸시: 생성된 이미지를 Docker Hub 또는 개인 레지스트리에 푸시한다.

# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ml-model-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: ml-model
  template:
    metadata:
      labels:
        app: ml-model
    spec:
      containers:
      - name: ml-model
        image: username/ml-model:latest
        ports:
        - containerPort: 5000

# service.yaml
apiVersion: v1
kind: Service
metadata:
  name: ml-model-service
spec:
  selector:
    app: ml-model
  ports:
  - protocol: TCP
    port: 80
    targetPort: 5000
  type: LoadBalancer

 

 

Kubeflow 를 이용하는 예시:

 

1. Kubeflow 설치 및 설정

• Kubernetes 클러스터에 Kubeflow를 설치한다. 주로 kfctl 도구를 사용하여 설치할 수 있다.

 

2. 프로젝트 설정:

• 프로젝트 디렉토리 생성: 필요한 모든 파일을 저장할 디렉토리를 생성한다.

mkdir my-kubeflow-project
cd my-kubeflow-project

 

 

3. 모델 개발 및 훈련 파이프라인 생성

• 훈련 파이프라인 생성: Kubeflow Pipelines를 사용하여 ML 워크플로우를 정의한다.

# pipeline.py
import kfp
from kfp import dsl

def train_model_op():
    return dsl.ContainerOp(
        name='Train Model',
        image='python:3.7',
        command=['python', 'train.py']
    )

@dsl.pipeline(
    name='Training pipeline',
    description='An example pipeline that trains a model.'
)
def train_pipeline():
    """
    Pipeline for training an ML model.
    """
    train_model = train_model_op()

compiler.Compiler().compile(train_pipeline, 'train_pipeline.yaml')

 

 

4. 모델 훈련 스크립트 (train.py): 훈련 스크립트를 작성하여 모델을 학습시킬 수 있다.

import joblib
from sklearn.ensemble import RandomForestClassifier
from sklearn.datasets import load_iris

data = load_iris()
model = RandomForestClassifier()
model.fit(data.data, data.target)

joblib.dump(model, '/mnt/output/model.pkl')

 

 

5. Kubeflow 파이프라인 실행

• 파이프라인 업로드 및 실행: Kubeflow 대시보드를 사용하여 생성된 파이프라인 (train_pipeline.yaml)을 업로드하고 실행하면 된다.

 

 

6. 모델 배포 및 예측 서비스 생성

• KFServing을 사용한 모델 서빙: KFServing을 사용하여 훈련된 모델을 서빙한다. 이를 통해 예측 서비스를 생성하고, Kubernetes 서비스로 배포할 수 있다.

# kfserving.yaml
apiVersion: "serving.kubeflow.org/v1alpha2"
kind: "InferenceService"
metadata:
  name: "iris-model"
spec:
  default:
    predictor:
      sklearn:
        storageUri: "pvc://your-pvc-path/model.pkl"

 

 

모델 스토어

모델만 단순하게 S3 만 올려서 서빙을 한다면 문제가 생겼을 때 해결하기 쉽지 않을 것.

 

문제는 다양한 원인이 있을 수 있으니까:

• 현재 프로덕션에서 사용하고 있는 모델이 내가 알고 있는 것과 다른 경우
• 피처 목록이 다를 수도 있고
• 피처화 코드가 (= 원시 데이터를 피처로 변경하는 코드) 가 옛날 코드일 수도 있고
• 데이터 처리 파이프라인에 문제가 발생했을 수도 있다.

이렇게 문제의 원인이 많기 때문에 모델을 저장할 때 여러 정보를 같이 저장해줘야한다. 이렇게 저장되는 장소가 모델 스토어임.

 

모델 스토어에는 다음과 같은 정보가 저장된다:

• 모델 정의: 모델이 어떻게 구성되어 있는지에 대한 정보를 포함한다.
  • 모델의 구조: 모델이 사용하는 레이어(layers)와 레이어 간의 연결 구조
  • 활성화 함수(Activation Functions): 각 레이어에서 사용되는 활성화 함수의 종류
  • 하이퍼파라미터(Hyperparameters): 학습률(learning rate), 배치 크기(batch size), 에폭 수(epoch number) 등 학습 과정에서 설정되는 파라미터들
  • 학습 알고리즘: 모델을 학습시키는 데 사용된 최적화 알고리즘(예: SGD, Adam 등)
  • 모델이 사용한 손실 함수
  • 모델 아키텍처에 대한 정보
• 모델 매개변수: 모델 매개변수는 학습 과정에서 결정되는 모델의 가중치(weights)와 편향(biases) 등을 말한다. 이 매개변수들은 모델의 학습된 상태를 나타내며, 예측을 수행할 때 필요하다.
  • 가중치(Weights): 각 레이어에서 입력에 적용되는 가중치 값들
  • 편향(Biases): 각 레이어에서 추가되는 편향 값들
  • 상태 정보(State Information): RNN 같은 일부 모델들에서 이전 상태를 기억하기 위해 필요한 매개변수들
• 종속성: 모델을 실행하는데 필요한 종속성
• 데이터: 모델이 학습한 데이터. DVC 와 같은 도구를 이용해서 데이터 버전을 지정한다.
• 피처화: 피처화는 원시 데이터를 모델이 이해하고 사용할 수 있는 형태의 데이터로 변환하는 과정읆 말한다. 피처화 로직은 모델 스토어에 저장되어, 데이터를 모델이 예측 가능한 형태로 일관되게 변환하는 데 사용된다.
  • 데이터 정제: 결측치 처리, 이상치 제거 등 데이터의 품질을 향상시키는 작업
  • 데이터 변환: 로그 변환, 정규화, 표준화 등 데이터의 스케일을 조정
  • 피처 추출: 중요한 속성을 추출하거나 새로운 피처를 생성
• 예측 함수 (Prediction Function): 예측 함수는 모델이 피처화된 데이터를 받아서 최종적인 예측을 수행하는 함수임.
  • 모델 로드: 저장된 매개변수와 모델 정의를 사용하여 모델을 메모리에 로드
  • 데이터 입력: 피처화된 데이터를 모델의 입력으로 사용
  • 출력 계산: 모델을 통해 입력 데이터에 대한 예측 결과를 계산
  • 결과 반환: 예측 결과를 반환하거나 후속 처리를 수행
• 모델 생성 코드:
  • 사용한 프레임워크: 모델을 개발할 때 사용한 머신러닝 라이브러리나 프레임워크의 정보임. 예를 들어, TensorFlow, PyTorch, Scikit-learn 등이 있다.
  • 훈련 방법: 모델을 어떻게 훈련시켰는지에 대한 세부 정보를 포함한다. 이는 배치 크기, 에포크 수, 사용된 최적화 알고리즘, 손실 함수 등을 포함할 수 있다.
  • 데이터셋 정보:
    • 훈련, 검증, 테스트 데이터셋: 데이터의 분할과 사용된 각 데이터셋에 대한 정보
    • 데이터 분할 방법: 데이터를 어떻게 분할했는지에 대한 방법론, 예를 들어 무작위 분할, 시간 기반 분할 등.
    • 세부 정보: 각 데이터셋의 특성, 예를 들어 각 클래스의 샘플 수, 데이터셋의 크기 등.
  • 실험 실행 횟수:
    • 모델을 개발하는 동안 수행된 실험의 총 횟수와 각 실험의 구성을 포함한다. 이 정보는 모델 선택과정에서의 다양한 시도를 문서화하는 데 유용하다.
  • 하이퍼파라미터의 범위:
    • 모델 훈련에 사용된 하이퍼파라미터의 탐색 범위임.
  • 최종 모델이 사용한 하이퍼파라미터의 실제값:
    • 최종적으로 선택된 모델에서 사용된 하이퍼파라미터의 구체적인 값들이다.
  • 실험 아티팩트:
    • 훈련된 모델 파일:
      • 모델의 가중치와 구조를 포함하는 파일임. 이 파일은 모델을 재로드하고 다른 환경에서 동일한 결과를 재현하기 위해 사용된다.
    • 학습 로그와 메트릭:
      • 훈련 과정 중에 생성되는 로그 파일과 메트릭이다. 에포크 별 손실 값, 정확도, 기타 성능 지표들이 이에 포함된다. 이 데이터는 모델의 학습 곡선을 분석하고, 과적합 여부 등을 판단하는 데 유용하다.
    • 코드와 스크립트:
      • 모델을 훈련시키고 평가하는 데 사용된 코드와 스크립트이다. 이 정보는 모델의 재현을 위해서 필수적이며, 수정이나 확장을 용이하게 한다.
    • 하이퍼파라미터 설정:
      • 훈련에 사용된 하이퍼파라미터의 설정값들이다. 이는 최적화 탐색 과정에서의 선택들을 기록하며, 향후 실험의 재현 또는 개선을 위한 기초 자료로 사용된다.
    • 테스트 결과와 평가 보고서:
      • 최종 모델에 대한 테스트 결과와 평가 보고서이다. 모델의 성능을 종합적으로 평가하는 다양한 메트릭과 분석 결과가 포함됨.
    • 데이터 샘플:
      • 모델 훈련에 사용된 데이터의 샘플 또는 전체 데이터셋에 대한 참조. 이는 데이터의 특성을 이해하고, 모델의 입력과 출력을 검증하는 데 사용된다.
    • 구성 파일과 환경 설정:
      • 모델을 훈련하고 실행하는 데 필요한 모든 외부 라이브러리와 환경 설정을 포함한 구성 파일이다.
  • 태그: 모델을 소유한 사람이나 팀 또는 테스크 (모델이 해결하려는 문제) 와 같이 모델 검색 필터링에 도와주는 정보를 포함시켜야한다.

 

피처 스토어

피처 스토어의 역할은 다음과 같이 3가지가 있다:

• 피처 관리
• 피처 연산
• 피처 일관성 보장

 

피처 관리

여러 팀에서 사용한 ML 모델의 유용한 피처를 공유하기 위한 목적, 피처 재사용 목적

 

피처 연산

피처를 연산하는데 비싼 연산 비용이 들어간다면 피처를 미리 계산해놓고 저장해두는 식으로 사용할 수 있을 거임.

 

피처 일관성 보장

배치 피처와 스트리밍 피처의 일관성을 보장하기 위해서 사용함. 서로 다른 파이프라인에서 피처를 동일하게 유지하기 위해서 사용한다.

 

피처의 정의나 계산 방식이 시간에 따라 변경될 수 있는데 피처 스토어는 이러한 변경사항을 추적하고 버전 관리를 제공한다.

 

 

Q) 그래서 피처는 어떤 식으로 저장되는건데?

 

피처 스토어에 피처를 저장하는 방식은 조직의 특정 요구와 기술 스택에 따라 다를 수 있지만, 일반적인 접근 방식을 여기서는 설명:

 

피처 저장 예시:

• 상황: 온라인 쇼핑 플랫폼에서 사용자의 구매 예측 모델을 개발하기 위해 여러 피처를 저장하려고 하는 상황

 

피처 정의:

• 사용자 평균 구매 금액: 과거 구매 데이터를 기반으로 한 사용자별 평균 구매 금액.
• 사용자 방문 빈도: 지난 달 동안의 사용자 방문 횟수.
• 최근 구매 카테고리: 사용자가 가장 최근에 구매한 제품 카테고리.

 

데이터 파이프라인 구성:

• 데이터 추출: 거래 데이터베이스와 웹 로그에서 필요한 데이터를 추출한다.
• 데이터 처리 및 피처 계산:
  • 사용자 평균 구매 금액: 모든 거래를 사용자 ID별로 그룹화하고, 각 사용자의 평균 구매 금액을 계산한다.
  • 사용자 방문 빈도: 웹 로그 데이터를 사용자별로 집계하여, 각 사용자의 월간 방문 횟수를 계산한다.
  • 최근 구매 카테고리: 사용자별로 최근 구매 거래를 확인하고, 해당 거래의 제품 카테고리를 추출한다.
• 피처 저장: 계산된 피처를 피처 스토어의 데이터베이스나 데이터 웨어하우스에 저장한다. 각 피처는 사용자 ID를 키로 사용하여 저장된다.

 

피처 접근:

• 배치 처리: 매일 새로운 피처 값이 계산되어 피처 스토어에 업데이트된다. 모델 훈련이나 배치 예측 작업 시 이 데이터에 접근할 수 있습니다.
• 실시간 처리: 사용자가 웹사이트에 로그인할 때 실시간으로 피처 값을 조회하여, 즉각적인 사용자 맞춤형 제안을 제공할 수 있다.