> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# 모델 학습 & 실험 관리

> 이 문서는 **[ML 핵심 개념](/blog/guides/ml-fundamentals/overview)** 섹션의 일부입니다.

## 3. 모델 학습 (Training)

### Databricks Runtime ML

Databricks Runtime ML은 표준 런타임에 **ML/DL 라이브러리가 사전 설치된 특수 런타임** 입니다. 직접 라이브러리를 설치하고 버전 충돌을 해결하는 고통을 없애줍니다.

주요 사전 설치 라이브러리는 다음과 같습니다.

| 카테고리              | 라이브러리                                     |
| ----------------- | ----------------------------------------- |
| **Classic ML**    | scikit-learn, XGBoost, LightGBM, CatBoost |
| **Deep Learning** | PyTorch, TensorFlow, Keras                |
| **분산 학습**         | Horovod, DeepSpeed, PyTorch Distributed   |
| **실험 관리**         | MLflow (Workspace에 자동 연결)                 |
| **데이터 처리**        | pandas, NumPy, SciPy, Spark MLlib         |
| **시각화**           | matplotlib, seaborn, plotly               |
| **GPU 지원**        | CUDA, cuDNN (GPU 클러스터 선택 시)               |

Runtime ML 버전은 Databricks Runtime 버전과 동일한 넘버링을 따르며 (예: DBR 16.x ML), 분기마다 새로운 버전이 출시됩니다.

### AutoML

**왜 등장했는가**: 데이터 사이언티스트가 새 데이터셋에 대해 적합한 알고리즘, 하이퍼파라미터, 전처리 방법을 찾는 데 수일\~수주가 걸립니다. AutoML은 이 탐색 과정을 자동화합니다.

**Databricks AutoML의 차별점**: Google AutoML, AWS SageMaker Autopilot 등 대부분의 AutoML 도구는 결과 모델만 반환하는 **블랙박스** 방식입니다. Databricks AutoML은 근본적으로 다릅니다 -- 각 시도(trial)가 **완전한 실행 가능 노트북** 으로 생성되고, 모든 전처리/학습/평가 코드가 투명하게 공개됩니다. 이 노트북을 기반으로 도메인 지식을 반영한 수정이 가능하므로, AutoML이 **출발점(starting point)** 역할을 하고 데이터 사이언티스트가 **전문성을 더하는** 워크플로가 됩니다.

**내부 탐색 과정**: AutoML은 내부적으로 다음 단계를 자동 수행합니다.

1. **데이터 프로파일링**: 각 컬럼의 타입, 분포, 결측률을 분석하여 데이터 탐색 노트북 생성
2. **전처리 자동화**: 수치형 컬럼의 결측치를 중앙값/평균으로 대체, 범주형 컬럼에 원-핫 인코딩, 날짜 컬럼에서 요일/월/시간 등 파생 피처 추출
3. **알고리즘 탐색**: LightGBM, XGBoost, RandomForest, LogisticRegression/ElasticNet 등을 순차적으로 시도
4. **하이퍼파라미터 최적화**: Hyperopt(TPE 알고리즘, Tree-structured Parzen Estimator) 기반으로 각 알고리즘의 최적 하이퍼파라미터를 탐색
5. **앙상블 시도**: 상위 모델들의 가중 투표(Weighted Voting) 앙상블도 자동 시도

아래 표는 Databricks AutoML의 주요 기능을 정리한 것입니다.

| 기능           | 설명                                                                             |
| ------------ | ------------------------------------------------------------------------------ |
| **지원 문제 유형** | 분류, 회귀, 시계열 예측 (Prophet, ARIMA 포함)                                             |
| **탐색 알고리즘**  | LightGBM, XGBoost, sklearn (RandomForest, LogisticRegression 등) + Hyperopt TPE |
| **자동 전처리**   | 결측치 처리, 범주형 인코딩, 날짜 피처 추출, 텍스트 피처 TF-IDF                                       |
| **출력물**      | 베스트 모델 노트북 + MLflow Experiment + 데이터 탐색 노트북                                    |
| **사용 방법**    | UI (Experiments > Create AutoML Experiment) 또는 Python API                      |
| **제한사항**     | 딥러닝 모델은 탐색하지 않음, 이미지/텍스트 전용 태스크 미지원, 대규모 데이터셋(수백GB 이상)에서는 샘플링 필요               |

```python theme={null}
from databricks import automl

summary = automl.classify(
    dataset=train_df,
    target_col="failure",
    primary_metric="f1",
    timeout_minutes=30
)

# 최고 성능 모델의 노트북 경로
print(summary.best_trial.notebook_path)
```

> **참고**
> AutoML은 **baseline 모델** 을 빠르게 확보하는 용도로 가장 효과적입니다. 생성된 노트북을 기반으로 도메인 지식을 반영한 피처 추가, 커스텀 전처리 등을 수행하는 것이 일반적인 워크플로입니다.

### 분산 학습

Databricks 클러스터의 분산 컴퓨팅 능력을 ML 학습에 활용하는 방법은 여러 가지입니다.

| 방법                             | 적합한 경우                        | 작동 방식                                  |
| ------------------------------ | ----------------------------- | -------------------------------------- |
| **Spark MLlib**                | 대규모 정형 데이터, 클래식 ML 알고리즘       | Spark DataFrame 기반 분산 학습               |
| **pandas UDF + Spark**         | 그룹별 독립 모델 학습 (예: 매장별 수요 예측)   | `applyInPandas()`로 그룹별 pandas 모델 병렬 학습 |
| **Horovod / TorchDistributor** | 대규모 딥러닝 모델 (CNN, Transformer) | 데이터 병렬(Data Parallel) 분산 학습            |
| **DeepSpeed**                  | 초대형 모델 (수십억 파라미터)             | ZeRO 최적화로 메모리 효율적 분산 학습                |
| **단일 노드 멀티 GPU**               | 중간 규모 DL 모델                   | PyTorch DDP 또는 Horovod 사용              |

**TorchDistributor의 동작 원리**: Spark 클러스터는 일반적으로 데이터 처리를 위해 설계되었지만, TorchDistributor는 **Spark 워커 노드를 PyTorch 분산 학습 노드로 전환** 합니다. 내부적으로 다음 과정이 일어납니다.

1. Spark 드라이버가 각 워커에 PyTorch 학습 프로세스를 시작하도록 지시
2. 각 워커에서 `torch.distributed` 백엔드(NCCL for GPU, Gloo for CPU)가 초기화되어 프로세스 간 통신 채널 구성
3. 데이터 병렬(Data Parallel) 방식으로 각 노드가 전체 모델의 복사본을 보유하고, 미니배치를 분할하여 학습
4. 그래디언트를 AllReduce 연산으로 동기화하여 모델 파라미터를 일치시킴

이 접근의 핵심 가치는 **Spark 클러스터 하나로 데이터 처리와 딥러닝 학습을 모두 수행** 할 수 있다는 것입니다. 별도의 Kubernetes 기반 학습 인프라(Kubeflow, Ray Train 등)를 구축할 필요가 없습니다.

```python theme={null}
from pyspark.ml.torch.distributor import TorchDistributor

def train_fn():
    import torch
    import torch.distributed as dist
    # torch.distributed가 자동으로 초기화됨
    # 일반 PyTorch DDP 학습 코드 작성
    ...

distributor = TorchDistributor(
    num_processes=4,       # 총 GPU 프로세스 수
    local_mode=False,      # True면 드라이버 노드만 사용
    use_gpu=True           # GPU 사용 여부
)
distributor.run(train_fn)
```

**DeepSpeed ZeRO 최적화**: 수십억 파라미터 모델(예: Llama 7B 파인튜닝)은 단순 데이터 병렬로는 단일 GPU 메모리에 모델이 들어가지 않습니다. DeepSpeed의 **ZeRO(Zero Redundancy Optimizer)** 는 3단계로 메모리 사용을 최적화합니다.

| ZeRO Stage  | 분산 대상                                       | 메모리 절감         | 통신 오버헤드         |
| ----------- | ------------------------------------------- | -------------- | --------------- |
| **Stage 1** | Optimizer States (Adam의 momentum, variance) | \~4x           | 낮음              |
| **Stage 2** | + Gradients                                 | \~8x           | 중간              |
| **Stage 3** | + Model Parameters                          | \~N배 (N=GPU 수) | 높음 (파라미터 수집 필요) |

Databricks ML Runtime에 DeepSpeed가 사전 설치되어 있으므로, TorchDistributor와 결합하여 대규모 모델의 파인튜닝을 수행할 수 있습니다.

### GPU 클러스터 활용

Databricks는 AWS(p4d, p5, g5), Azure(NC, ND 시리즈), GCP의 GPU 인스턴스를 지원합니다. GPU 클러스터 사용 시 고려사항은 다음과 같습니다.

| 고려사항            | 권장 사항                                     |
| --------------- | ----------------------------------------- |
| **인스턴스 선택**     | 학습: A100/H100 (고대역폭). 추론: T4/A10G (비용 효율) |
| **Runtime 선택**  | 반드시 ML Runtime (GPU 버전) 선택                |
| **스팟 인스턴스**     | 학습 시 비용 절감 가능. 체크포인트 저장 필수                |
| **단일 vs 멀티 노드** | 모델 크기 \< GPU 메모리이면 단일 노드로 충분              |

***

## 4. 실험 관리 & 모델 레지스트리

### MLflow Tracking

**왜 필요한가**: ML 프로젝트에서는 수십\~수백 번의 실험을 수행합니다. 어떤 하이퍼파라미터 조합이 최적이었는지, 어떤 전처리를 적용했는지를 체계적으로 기록하지 않으면 재현이 불가능합니다.

Databricks에는 **Managed MLflow** 가 내장되어 있어 별도 서버 구축 없이 바로 사용할 수 있습니다.

| MLflow 구성 요소   | 역할                                        |
| -------------- | ----------------------------------------- |
| **Experiment** | 관련 실험(Run)의 논리적 그룹. 프로젝트나 문제 단위로 생성       |
| **Run**        | 하나의 학습 실행. 파라미터, 메트릭, 아티팩트, 소스 코드를 기록     |
| **Parameter**  | 하이퍼파라미터 (learning\_rate, n\_estimators 등) |
| **Metric**     | 평가 지표 (accuracy, f1, rmse 등). 스텝별 기록 가능   |
| **Artifact**   | 모델 파일, 그래프, 데이터 샘플 등 모든 바이너리              |
| **Tag**        | 실행에 대한 메타데이터 (팀, 버전, 환경 등)                |

```python theme={null}
import mlflow

with mlflow.start_run(run_name="xgboost-v2"):
    mlflow.log_param("max_depth", 6)
    mlflow.log_param("learning_rate", 0.1)

    model = train_model(...)

    mlflow.log_metric("f1_score", 0.92)
    mlflow.log_metric("auc", 0.95)

    # 모델 + 피처 정보 함께 저장
    mlflow.sklearn.log_model(model, "model")
```

Databricks MLflow는 오픈소스 MLflow와 호환되면서도, **자동 로깅(Autolog)** 기능이 강화되어 있습니다. `mlflow.autolog()`를 호출하면 scikit-learn, XGBoost, PyTorch, TensorFlow 등의 학습을 자동으로 추적합니다.

### Unity Catalog 모델 레지스트리

**왜 등장했는가**: 기존 Workspace 레벨 모델 레지스트리는 워크스페이스 간 모델 공유가 어렵고, 데이터 거버넌스와 분리되어 있었습니다. Unity Catalog 모델 레지스트리는 모델을 **데이터와 동일한 거버넌스 체계** 로 관리합니다.

| 기능             | Workspace 레지스트리 (Legacy)    | Unity Catalog 레지스트리                   |
| -------------- | --------------------------- | ------------------------------------- |
| **네임스페이스**     | 워크스페이스 내                    | `catalog.schema.model_name` (3-level) |
| **접근 제어**      | 워크스페이스 단위                   | Unity Catalog 권한 (GRANT/REVOKE)       |
| **크로스 워크스페이스** | 불가                          | 동일 메타스토어 내 모든 워크스페이스에서 접근             |
| **Lineage**    | 제한적                         | 데이터 테이블 → 피처 → 모델 → 엔드포인트 전체 추적       |
| **스테이지 관리**    | Staging/Production/Archived | Alias (Champion, Challenger 등 자유 지정)  |

Unity Catalog 모델 레지스트리의 핵심 개념인 **Alias** 는 기존의 고정된 스테이지(Staging, Production) 대신 유연한 태그 시스템을 제공합니다. 기존 스테이지 방식은 Staging → Production → Archived라는 고정 경로만 허용했으나, Alias는 **임의의 이름** 을 자유롭게 부여할 수 있어 다양한 배포 전략을 지원합니다.

예를 들어, `Champion`(현재 프로덕션 모델)과 `Challenger`(검증 중인 후보 모델) Alias를 지정하여 A/B 테스트를 구성하거나, `region-kr`, `region-us`처럼 지역별 모델을 관리할 수도 있습니다. Model Serving Endpoint가 Alias를 참조하므로, Alias를 다른 버전으로 이동시키면 **엔드포인트가 자동으로 새 모델 버전을 로드** 합니다 -- 제로 다운타임 배포가 가능합니다.

```python theme={null}
import mlflow

# Unity Catalog에 모델 등록
mlflow.set_registry_uri("databricks-uc")
model_uri = "runs:/abc123/model"
mlflow.register_model(model_uri, "catalog.schema.fraud_detection")

# Alias 지정
from mlflow import MlflowClient
client = MlflowClient()
client.set_registered_model_alias(
    name="catalog.schema.fraud_detection",
    alias="Champion",
    version=3
)
```

### 모델 버전 관리 워크플로

아래 표는 일반적인 모델 라이프사이클에서 각 단계별 Databricks 기능 매핑을 보여줍니다.

| 라이프사이클 단계 | 활동                         | Databricks 기능                            |
| --------- | -------------------------- | ---------------------------------------- |
| **실험**    | 여러 알고리즘/파라미터 시도            | MLflow Experiment + Autolog              |
| **등록**    | 최적 모델을 레지스트리에 등록           | `mlflow.register_model()`                |
| **검증**    | Challenger 모델과 Champion 비교 | Alias + 평가 노트북                           |
| **승격**    | 검증 통과 시 Champion으로 변경      | `client.set_registered_model_alias()`    |
| **배포**    | 서빙 엔드포인트에 반영               | Model Serving (Alias 기반 자동 업데이트)         |
| **폐기**    | 더 이상 사용하지 않는 버전 정리         | `client.delete_registered_model_alias()` |