> ## 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)** 섹션의 일부입니다.

## 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()` |

***

## 5. 모델 배포 (Serving)

### Model Serving Endpoints (실시간 추론)

**왜 등장했는가**: ML 모델을 프로덕션 API로 노출하려면 컨테이너 이미지 빌드, 로드 밸런서 구성, 오토스케일링 설정 등 인프라 작업이 필요합니다. Databricks Model Serving은 이 복잡성을 **완전 관리형 서비스** 로 추상화합니다.

| 기능           | 설명                                                               |
| ------------ | ---------------------------------------------------------------- |
| **원클릭 배포**   | Unity Catalog 모델을 선택하면 REST API 엔드포인트 자동 생성                      |
| **오토스케일링**   | 트래픽에 따라 인스턴스 자동 확장/축소. Scale-to-zero 지원                          |
| **A/B 테스팅**  | 하나의 엔드포인트에 여러 모델 버전을 트래픽 비율로 라우팅                                 |
| **GPU 서빙**   | GPU 인스턴스를 선택하여 DL 모델 서빙 가능                                       |
| **피처 자동 조회** | Feature Spec이 등록된 모델은 서빙 시 Online Table에서 피처를 자동 조회              |
| **환경 버전 관리** | 모델이 기록된 시점의 Python 환경(conda.yaml)을 자동으로 재현하여 "내 로컬에서는 됐는데" 문제 방지 |

```python theme={null}
import requests

# 서빙 엔드포인트 호출 예시
endpoint_url = "https://<workspace-url>/serving-endpoints/<endpoint-name>/invocations"
headers = {"Authorization": f"Bearer {token}"}

payload = {
    "dataframe_records": [
        {"device_id": "sensor-001", "temperature": 85.2, "pressure": 1.2}
    ]
}

response = requests.post(endpoint_url, json=payload, headers=headers)
print(response.json())
```

### Batch Inference (대규모 배치 추론)

실시간 응답이 필요하지 않은 경우, **배치 추론** 이 비용 효율적입니다. Databricks에서 배치 추론을 수행하는 대표적인 방법은 다음과 같습니다.

| 방법                                | 적합한 경우                     | 장점                            |
| --------------------------------- | -------------------------- | ----------------------------- |
| **`mlflow.pyfunc.spark_udf()`**   | 대규모 데이터 (수백만\~수십억 건)       | Spark 병렬 처리, Delta 테이블에 직접 쓰기 |
| **MLflow `predict()`**            | 소규모 데이터 (pandas DataFrame) | 간단한 코드, 로컬 테스트 용이             |
| **Feature Store `score_batch()`** | 피처 테이블 조인이 필요한 경우          | 피처 자동 조회 + 추론 한 번에            |

```python theme={null}
import mlflow

# Spark UDF로 대규모 배치 추론
model_uri = "models:/catalog.schema.fraud_detection@Champion"
predict_udf = mlflow.pyfunc.spark_udf(spark, model_uri)

predictions = (
    spark.table("catalog.schema.transactions")
    .withColumn("prediction", predict_udf())
)
predictions.write.mode("overwrite").saveAsTable("catalog.schema.predictions")
```

### Foundation Model APIs

**왜 등장했는가**: LLM을 사용하려면 모델을 직접 호스팅하거나 외부 API를 호출해야 합니다. Databricks **Foundation Model APIs** 는 오픈소스 LLM을 Databricks 인프라에서 최적화된 상태로 제공하는 서버리스 API입니다.

아래 표는 두 가지 제공 유형의 차이와 각각 적합한 시나리오를 비교합니다.

| 구분         | Pay-per-token                         | Provisioned Throughput            |
| ---------- | ------------------------------------- | --------------------------------- |
| **과금 방식**  | 입출력 토큰 수 기반 종량제                       | 시간당 처리량(토큰/초) 단위 예약               |
| **지원 모델**  | 사전 배포된 인기 모델 (DBRX, Llama, Mixtral 등) | Foundation 모델 + **커스텀 파인튜닝 모델**   |
| **레이턴시**   | 공유 인프라이므로 피크 시 변동 가능                  | 전용 GPU 할당으로 **일관된 레이턴시 보장**       |
| **적합한 경우** | PoC, 개발/테스트, 간헐적 호출                   | 프로덕션 워크로드, SLA가 중요한 서비스, 높은 동시 요청 |
| **콜드 스타트** | 없음 (항상 준비됨)                           | 최초 배포 시 수분 소요 후 즉시 응답             |
| **비용 효율**  | 낮은 사용량에서 유리                           | 지속적/대량 호출에서 유리 (토큰당 단가가 낮아짐)      |

> **참고**
> **선택 기준**: 월 토큰 사용량이 수백만 토큰 이하이면 Pay-per-token이 경제적입니다. 프로덕션 서비스에서 초당 수십\~수백 요청을 처리하거나, 파인튜닝한 커스텀 모델을 서빙해야 한다면 Provisioned Throughput을 선택하세요.

Foundation Model APIs는 **OpenAI 호환 API** 를 지원하므로, 기존 OpenAI SDK 코드를 최소한의 변경으로 마이그레이션할 수 있습니다.

```python theme={null}
from openai import OpenAI

client = OpenAI(
    api_key=databricks_token,
    base_url="https://<workspace-url>/serving-endpoints"
)

response = client.chat.completions.create(
    model="databricks-meta-llama-3-1-70b-instruct",
    messages=[{"role": "user", "content": "매출 하락 원인을 분석해주세요."}]
)
```

### External Models

**External Models** 는 Azure OpenAI, Anthropic Claude, Amazon Bedrock 등 **외부 LLM 제공자를 Databricks 엔드포인트로 프록시** 하는 기능입니다.

| 이점                | 설명                                    |
| ----------------- | ------------------------------------- |
| **중앙 집중 거버넌스**    | 모든 LLM 호출을 Unity Catalog 권한으로 제어      |
| **사용량 추적**        | AI Gateway를 통해 토큰 사용량, 비용, 레이턴시를 모니터링 |
| **Rate Limiting** | 사용자/팀별 호출 한도 설정                       |
| **API 키 관리**      | 개별 사용자가 아닌 플랫폼 수준에서 API 키를 안전하게 관리    |
| **폴백(Fallback)**  | 한 제공자가 실패하면 다른 제공자로 자동 전환             |

이 아키텍처의 핵심 가치는 **모델 제공자를 추상화** 하는 것입니다. 애플리케이션 코드에서는 Databricks 엔드포인트만 호출하고, 실제로 어떤 LLM이 뒤에서 동작하는지는 엔드포인트 설정에서 변경할 수 있습니다.

**AI Gateway의 실제 역할**: External Models 기능의 핵심은 **AI Gateway** 레이어입니다. 이것은 단순 프록시가 아니라, 엔터프라이즈 환경에서 LLM 사용을 통제하고 관찰하기 위한 핵심 인프라입니다.

| AI Gateway 기능     | 동작 방식                                               | 실전 가치                |
| ----------------- | --------------------------------------------------- | -------------------- |
| **트래픽 라우팅**       | 하나의 엔드포인트에 여러 제공자(예: GPT-4o + Claude)를 설정하고 가중치로 분배 | A/B 테스트, 점진적 마이그레이션  |
| **Rate Limiting** | 사용자/그룹/엔드포인트별 분당/시간당 토큰 한도 설정                       | 비용 폭주 방지, 공정한 리소스 배분 |
| **Fallback**      | 주 제공자 실패(timeout, 5xx) 시 자동으로 백업 제공자로 전환            | 서비스 가용성 보장           |
| **Guardrails**    | 입력/출력에 안전성 필터 적용 (PII 마스킹, 유해 콘텐츠 차단)               | 규정 준수, 보안            |
| **사용량 로깅**        | 모든 요청/응답의 토큰 수, 레이턴시, 비용을 시스템 테이블에 자동 기록            | 비용 최적화, 감사(Audit)    |

***

## 6. 모델 모니터링

### Lakehouse Monitoring

**왜 필요한가**: 프로덕션에 배포된 모델은 시간이 지남에 따라 성능이 저하됩니다. 입력 데이터의 분포가 변하거나(Data Drift), 입력과 출력 간의 관계가 변하면(Concept Drift) 모델의 예측 정확도가 떨어집니다.

Databricks **Lakehouse Monitoring** 은 테이블 단위의 모니터링 솔루션으로, 데이터 품질과 모델 성능을 자동으로 추적합니다.

| 모니터링 유형          | 대상             | 감지 항목                       |
| ---------------- | -------------- | --------------------------- |
| **Snapshot**     | 정적 테이블 (현재 상태) | 프로필 통계, 컬럼별 분포              |
| **TimeSeries**   | 시계열 데이터        | 시간에 따른 분포 변화 (Drift)        |
| **InferenceLog** | 모델 추론 결과 테이블   | 예측 분포 변화, 입력 드리프트, 모델 성능 지표 |

**드리프트 감지 메커니즘**: Lakehouse Monitoring은 단순 통계 비교를 넘어, 통계적 검정(statistical test)에 기반한 체계적인 드리프트 감지를 수행합니다.

| 데이터 유형  | 검정 방법                      | 의미                                              |
| ------- | -------------------------- | ----------------------------------------------- |
| **수치형** | KS 검정 (Kolmogorov-Smirnov) | 두 분포 간 최대 차이를 측정. p-value \< 0.05이면 분포가 유의하게 변화 |
| **범주형** | 카이제곱 검정 (Chi-squared)      | 범주별 빈도 분포의 차이를 측정                               |
| **공통**  | Jensen-Shannon Divergence  | 두 확률 분포 간 거리를 0\~1 사이 값으로 수치화                   |

Lakehouse Monitoring이 생성하는 **두 개의 출력 테이블** 을 이해하는 것이 중요합니다.

| 출력 테이블                    | 내용                                            | 활용                     |
| ------------------------- | --------------------------------------------- | ---------------------- |
| **Profile Metrics Table** | 각 윈도우(시간 구간)별 컬럼 프로파일 (평균, 분산, null 비율, 분포 등) | 시간에 따른 데이터 품질 추이 확인    |
| **Drift Metrics Table**   | 현재 윈도우 vs 기준(baseline) 윈도우 간 드리프트 통계량         | 알림 설정, 재학습 트리거 조건으로 활용 |

이 테이블들은 일반 Delta 테이블이므로, SQL로 쿼리하거나 Databricks Jobs에서 드리프트 임계값을 확인하여 **재학습 파이프라인을 자동 트리거** 하는 것이 가능합니다.

Lakehouse Monitoring이 생성하는 **자동 대시보드** 에서는 다음을 확인할 수 있습니다.

* 각 컬럼의 분포 변화를 시각화한 히스토그램
* 드리프트 감지 통계량과 p-value
* 모델 성능 지표의 시간별 추이 (InferenceLog 프로필)

### Inference Table (추론 테이블)

Model Serving Endpoint에 **Inference Table** 을 활성화하면, 모든 요청(입력)과 응답(출력)이 자동으로 Delta 테이블에 기록됩니다.

| 기록 항목     | 설명              |
| --------- | --------------- |
| **요청 본문** | 입력 피처 값         |
| **응답 본문** | 모델 예측 결과        |
| **타임스탬프** | 요청 시각           |
| **레이턴시**  | 응답 시간           |
| **모델 버전** | 어떤 모델 버전이 응답했는지 |
| **상태 코드** | 성공/실패 여부        |

이 테이블에 Lakehouse Monitoring의 InferenceLog 프로필을 연결하면, **실시간 추론 모니터링 파이프라인** 이 완성됩니다.

> **참고**
> Inference Table의 데이터는 **Ground Truth 라벨링** 에도 활용됩니다. 시간이 지나 실제 결과가 확인되면, Inference Table에 라벨을 조인하여 모델의 실제 성능을 계산할 수 있습니다.

***

## 7. GenAI & Agent 기능

### Foundation Model APIs

앞서 5장에서 설명한 Foundation Model APIs는 GenAI 워크로드의 기반이 됩니다. 추가로 GenAI 특화 기능을 정리합니다.

| 기능                   | 설명                                     |
| -------------------- | -------------------------------------- |
| **Chat Completions** | 대화형 LLM 호출 (system/user/assistant 메시지) |
| **Embeddings**       | 텍스트를 벡터로 변환 (RAG, 유사도 검색용)             |
| **Completions**      | 텍스트 생성 (레거시 API)                       |

### Vector Search

**왜 필요한가**: RAG(검색 증강 생성) 파이프라인에서 관련 문서를 빠르게 검색하려면 벡터 유사도 검색이 필수입니다. 별도의 벡터 DB(Pinecone, Weaviate 등)를 운영하면 **데이터 이중 관리** 문제가 발생합니다 -- 원본 문서가 업데이트되면 벡터 DB도 수동으로 동기화해야 하고, 삭제된 문서의 임베딩이 남아 "유령 검색 결과"를 반환하는 문제가 생깁니다.

Databricks **Vector Search** 는 Delta 테이블을 **Single Source of Truth** 로 유지하면서 자동 동기화되는 벡터 인덱스를 제공합니다. 원본 Delta 테이블에서 행이 추가/수정/삭제되면 인덱스가 자동으로 반영되므로, 데이터 정합성이 보장됩니다.

| 인덱스 유형                         | 설명                                                            |
| ------------------------------ | ------------------------------------------------------------- |
| **Delta Sync Index**           | Delta 테이블의 변경 사항을 자동으로 임베딩하고 인덱싱. 소스 테이블이 업데이트되면 인덱스도 자동 업데이트 |
| **Direct Vector Access Index** | 사전 계산된 임베딩 벡터를 직접 업로드. 커스텀 임베딩 파이프라인 사용 시 적합                  |

Delta Sync Index는 두 가지 모드를 지원합니다.

| 모드                          | 동작                                      |
| --------------------------- | --------------------------------------- |
| **Managed Embeddings**      | 소스 텍스트 컬럼을 지정하면 Databricks가 자동으로 임베딩 생성 |
| **Self-managed Embeddings** | 사용자가 미리 계산한 임베딩 컬럼을 사용                  |

### Agent Framework (ChatAgent)

Databricks **Agent Framework** 는 LLM 기반 AI Agent를 개발, 테스트, 배포하기 위한 통합 프레임워크입니다.

**ChatAgent 인터페이스가 왜 중요한가**: MLflow 3.0에서 도입된 `ChatAgent`는 Agent 생태계의 **표준 계약(contract)** 역할을 합니다. 기존에는 LangChain으로 만든 Agent, LlamaIndex로 만든 Agent, 순수 Python Agent가 각각 다른 입출력 형식을 가져서, 배포/평가/모니터링 도구를 프레임워크별로 따로 만들어야 했습니다.

ChatAgent는 **OpenAI Chat Completions 형식** (`messages` 리스트, `role`/`content` 구조)을 표준으로 채택하여, 어떤 프레임워크로 내부를 구현하든 동일한 인터페이스로 배포하고 평가할 수 있게 합니다. 이 덕분에 다음이 가능해집니다.

* **프레임워크 교체 투명성**: LangChain에서 순수 Python으로 Agent 내부를 교체해도 배포 엔드포인트, 평가 코드, UI가 변경 없이 동작
* **통합 평가**: `mlflow.evaluate()`가 모든 ChatAgent에 동일하게 적용
* **AI Playground 호환**: ChatAgent 인터페이스를 구현한 Agent는 AI Playground에서 즉시 테스트 가능
* **Streaming 지원**: `predict_stream()` 메서드를 구현하면 토큰 단위 스트리밍 응답 자동 지원

| 구성 요소                | 역할                                                                              |
| -------------------- | ------------------------------------------------------------------------------- |
| **ChatAgent 인터페이스**  | Agent의 표준 입출력 인터페이스. `predict(messages)` + `predict_stream(messages)` 메서드 구현    |
| **Agent 도구 (Tools)** | Vector Search 검색, SQL 실행, Genie Space 질의 등 Agent가 사용하는 도구. UC Function으로도 정의 가능 |
| **MLflow를 통한 로깅**    | Agent를 MLflow 모델로 기록하여 버전 관리 및 배포                                               |
| **Model Serving 배포** | Agent를 REST API 엔드포인트로 배포. Review App으로 SME 피드백 수집 가능                           |

```python theme={null}
import mlflow
from databricks.agents import ChatAgent

class MyRAGAgent(ChatAgent):
    def predict(self, messages, context=None):
        # 1. 사용자 질문에서 검색 쿼리 추출
        query = messages[-1]["content"]

        # 2. Vector Search로 관련 문서 검색
        docs = vector_search.similarity_search(query, num_results=5)

        # 3. LLM에 컨텍스트와 함께 질문
        response = llm.chat(
            system="검색된 문서를 기반으로 답변하세요.",
            context=docs,
            question=query
        )
        return response

# Agent를 MLflow에 기록
with mlflow.start_run():
    mlflow.pyfunc.log_model("agent", python_model=MyRAGAgent())
```

### Agent Evaluation (MLflow 기반)

Agent의 품질을 객관적으로 측정하기 위한 **mlflow\.evaluate()** 기반 평가 프레임워크입니다. 단순히 메트릭 숫자를 보여주는 것을 넘어, **어떤 기준으로 왜 그 점수가 나왔는지** 를 추적할 수 있는 체계적인 Scorer 시스템을 제공합니다.

**Scorer 시스템**: Agent Evaluation은 **내장 Scorer(Built-in Scorer)** 와 **커스텀 Scorer** 를 조합하여 평가합니다. 각 Scorer는 독립적으로 동작하여, 필요한 평가 항목만 선택적으로 사용할 수 있습니다.

아래 표는 주요 내장 Scorer의 역할과 평가 방식을 정리한 것입니다.

| Scorer              | 평가 대상                                   | 방식        | Ground Truth 필요 여부 |
| ------------------- | --------------------------------------- | --------- | ------------------ |
| **Correctness**     | 답변이 정답(expected\_response)과 의미적으로 일치하는지 | LLM Judge | 필요                 |
| **Groundedness**    | 답변이 검색된 문서(retrieved\_context)에 근거하는지   | LLM Judge | 불필요                |
| **Relevance**       | 검색된 문서가 질문과 관련 있는지                      | LLM Judge | 불필요                |
| **Safety**          | 답변에 유해하거나 부적절한 내용이 포함되었는지               | LLM Judge | 불필요                |
| **Chunk Relevance** | 검색된 각 청크(chunk)가 개별적으로 관련 있는지           | LLM Judge | 불필요                |
| **Latency**         | 응답 시간 (초 단위)                            | 측정        | 불필요                |
| **Token Count**     | 입출력 토큰 사용량                              | 측정        | 불필요                |

평가는 **LLM-as-a-Judge** 방식으로 자동화됩니다. Databricks가 제공하는 강력한 Judge LLM이 Agent의 답변을 채점하며, 각 점수에 대한 **이유(rationale)** 도 함께 반환하여 디버깅이 가능합니다.

```python theme={null}
import mlflow

results = mlflow.evaluate(
    model="runs:/abc123/agent",
    data=eval_dataset,            # 질문 + (선택) 정답 + (선택) 검색 문서
    model_type="databricks-agent"  # Agent 전용 평가 모드 활성화
)

# 전체 메트릭 확인
print(results.metrics)

# 개별 행 단위 상세 결과 (점수 + 이유)
display(results.tables["eval_results"])
```

> **참고**
> Ground Truth가 없는 초기 단계에서도 **Groundedness, Relevance, Safety** 는 평가 가능합니다. 이후 사용자 피드백이나 SME 리뷰를 통해 Ground Truth를 점진적으로 구축하면 Correctness 평가를 추가할 수 있습니다.

### AI Playground

**AI Playground** 는 Databricks UI에서 다양한 LLM을 즉시 테스트할 수 있는 대화형 인터페이스입니다. Foundation Model APIs, External Models, 파인튜닝한 커스텀 모델 등 Model Serving에 배포된 모든 모델을 별도 코드 없이 비교 테스트할 수 있습니다.

| 활용 시나리오          | 설명                                                |
| ---------------- | ------------------------------------------------- |
| **모델 비교**        | 동일 프롬프트로 여러 모델의 응답 품질을 나란히 비교                     |
| **프롬프트 튜닝**      | System prompt, temperature 등을 실시간으로 조정하며 최적 설정 탐색 |
| **Tool Use 테스트** | Agent 도구(Function) 호출 동작 확인                       |
| **프로토타이핑**       | 코드 없이 빠르게 PoC 수준의 대화 흐름 검증                        |

***