후보 비교와 실험 이력¶
모델 지표가 만들어지는 과정과 공식 승인 근거를 구분해야 Candidate A와 Candidate B의 판단을 안전하게 설명할 수 있습니다. 먼저 train과 valid만 사용하는 작은 scikit-learn 활동에서 특성, 점수, 임계값, 예측, 혼동 행렬의 연결을 확인합니다. 이어 공식 평가 결과를 읽고 두 후보의 모델 승인 판단을 기록합니다.
개발용 활동에서 얻은 수치는 공식 승인 근거가 아닙니다. Candidate A와 Candidate B의 임계값을 조정하거나 최종 평가 데이터를 다시 사용하지 않으며, 확정된 평가 상태와 보호 기준을 두 번째 노트북, 필요한 경우 MLflow 화면에서 확인합니다.
강의 순서에서의 위치
개발 평가와 공식 승인, 생성 이력을 분리해야 모델 판단을 과장하지 않습니다. 1일차 오후 6교시에는 승인 조건과 후보 비교를 진행하고, 7교시에는 실험과 버전 연결로 첫째 날 모델 근거 행을 완성합니다.
실습 목표¶
이 실습의 핵심은 Candidate A와 Candidate B의 수치를 옮겨 적는 데 있지 않습니다. 모델이 점수와 예측을 만드는 과정을 직접 확인한 뒤, 같은 공식 평가에서 어떤 보호 기준을 통과했고 어떤 기준을 통과하지 못했는지 보고서 한 행으로 설명합니다. 정밀도, 재현율, 미탐(false negative, FN), 재현율 하한이 낯설다면 먼저 분류 지표와 곡선을 읽습니다.
실습에서 할 일
- 개발용
train/valid노트북으로 지표가 만들어지는 과정을 확인합니다. - 상태 명령으로 고정한 Candidate A/B 결론을 확인합니다.
- 비교 노트북에서 모든 보호 기준의 통과 여부를 대조합니다.
- 모델 승인만 기록하고, 대상 API와 운영 상태는 다음 장의 질문으로 남깁니다.
실습 전 확인
모든 명령은 tta-aiqa 저장소 루트에서 실행합니다. 실습 환경 준비에서 노트북 환경을 확인합니다. 첫 번째 노트북은 train과 valid만 사용하고, 두 번째 노트북과 상태 명령은 이미 확정된 평가 자료를 읽습니다. 결과가 예상과 달라도 공식 평가 자료의 임계값이나 정책을 조정하지 않고, 파일 경로와 저장소 버전을 기록합니다.
이 실습을 마치면 공식 평가에서 Candidate B가 승인된 근거를 기록할 수 있습니다. 대상 API의 실행 모델이나 운영 상태는 확인한 것이 아니며, 그 근거는 다음 장에서 따로 살펴봅니다.
1. 확인할 자료와 해석 범위¶
이 실습에서 확인하는 자료는 공식 평가 결과, 배포 전 정책, 배포 선언 파일입니다. 이 파일들을 새 실행 결과로 덮어쓰지 않고, 공식 평가에서 이미 정한 정책과 판단 이력을 읽는 자료로 사용합니다.
Candidate A와 Candidate B의 비교는 1장에서 확인한 데이터와 데이터 분할 범위를 전제로 합니다. 이 범위가 있어야 다른 데이터 분할의 수치나 로컬 학습 결과를 공식 평가 결과와 섞지 않습니다.
이 단계에서 확인할 경계는 다음과 같습니다.
- 첫 번째 노트북은
train과valid만 사용합니다. - 공식 상태와 비교 노트북은 이미 확정한 평가 자료를 읽습니다.
test를 다시 열거나 Candidate A/B의 임계값을 조정하지 않습니다.
2. 개발용 학습과 평가 흐름 확인¶
모델 학습의 목적은 새로운 배포 후보를 만드는 것이 아니라 품질 지표가 어떤 데이터와 계산에서 나오는지 이해하는 것입니다. 다음 노트북은 현재 특성 표에서 train 2,900건으로 단순 로지스틱 회귀를 학습하고 valid 600건에서 한 번 평가합니다.
labs/ch02-model-quality/00_train_valid_model_walkthrough.ipynb
노트북에서는 Pandas로 데이터 역할과 클래스별 건수를 확인한 뒤, 결측값 처리, 크기 조정, 로지스틱 회귀를 scikit-learn Pipeline으로 묶습니다. 임계값은 0.50으로 고정하며, 더 좋은 수치를 찾기 위한 반복 조정은 하지 않습니다.
개발용 train·valid 출력은 지표 계산과 정확도 착시를 이해하는 학습 근거이며, Candidate A/B의 공식 승인 근거로 사용하지 않습니다.
| 확인할 항목 | 예상 결과 | 판단에 사용하는 방법 |
|---|---|---|
| 사용한 역할 | train, valid |
최종 평가용 test와 operational을 개발용 계산에서 제외했는지 확인합니다. |
| 역할별 건수 | train 2,900, valid 600 |
학습과 평가에 같은 행을 사용하지 않았는지 확인합니다. |
| 클래스별 건수 | train 402/2,498, valid 83/517 |
클래스 불균형 때문에 정확도만 보지 않습니다. |
| 개발용 정확도 | 0.8550 | 전체 정답 비율이며 단독 승인 기준으로 쓰지 않습니다. |
| 개발용 정밀도/재현율 | 0.4500 / 0.2169 | 높은 정확도와 달리 놓침이 많다는 사실을 확인합니다. |
| 개발용 혼동 행렬 | TP 18, FP 22, FN 65, TN 495 | 오류 유형이 업무에 미칠 영향을 설명합니다. |
이 출력은 “정확도 85.5%이므로 모델이 좋다”는 결론을 반박하는 학습 근거입니다. high_risk 83건 가운데 65건을 놓쳤으므로 재현율과 FN을 함께 보지 않으면 품질 위험을 숨길 수 있습니다.
노트북이 test 또는 operational을 사용했다고 표시하거나 역할별 건수가 다르면 실행을 중단합니다. 데이터 분할 경로와 저장소 개정본을 확인한 뒤 데이터와 모델 담당자에게 알리고, 이 실행 결과를 공식 평가와 비교하지 않습니다.
3. 공식 평가 상태 확인¶
고정된 평가 결과가 승인 상태를 유지하는지 확인해야 노트북의 수치와 보고서 판단을 같은 근거로 연결할 수 있습니다. 아래 명령은 그 상태를 확인합니다.
uv run python scripts/run_model.py status
이 상태가 확인돼야 Candidate B의 공식 모델 승인과 배포 검토 가능 범위를 같은 근거로 기록할 수 있습니다. 출력에서는 다음 항목을 함께 확인합니다.
candidate-a=HOLD,candidate-b=APPROVEsealed_test=evaluated_oncedeployment_allowed=true
deployment_allowed는 Candidate B를 배포 검토 대상으로 삼을 수 있다는 뜻이며, 대상 환경 배포가 끝났다는 뜻은 아닙니다.
{
"decisions": {"candidate-a": "HOLD", "candidate-b": "APPROVE"},
"deployment_allowed": true,
"sealed_test": "evaluated_once",
"status": "APPROVED"
}
이 결과의 deployment_allowed는 Candidate B를 배포 검토 대상으로 삼을 수 있음을 나타냅니다. 이 값만으로 kubectl이나 대상 API를 확인하지 않은 상태에서 대상 환경 배포가 끝났다고 판단할 수는 없습니다.
승인 조건과 후보 비교¶
보호 기준의 통과 여부는 Candidate A와 Candidate B의 수치를 한 표에서 비교해야 설명할 수 있습니다. VS Code에서 다음 노트북을 열고 위에서 아래로 실행해 각 보호 기준을 확인합니다.
labs/ch02-model-quality/01_compare_model_evidence.ipynb
정밀도-재현율 곡선 아래 면적(Precision-Recall Area Under the Curve, PR-AUC)의 변화는 여러 임계값에서 정밀도와 재현율의 관계가 비교 기준 모델보다 얼마나 달라졌는지 나타냅니다. 후보별 수치는 다른 필수 보호 기준과 함께 통과 여부를 판단하고 보고서에 기록합니다.
| 확인할 항목 | Candidate A | Candidate B | 보고서에 적는 의미 |
|---|---|---|---|
| 임계값 | 0.40 | 0.35 | 고정된 프로필 설정값 |
| 재현율 / 재현율 하한 | 0.3091 / 0.1864 | 0.8000 / 0.6956 | 필요한 재현율과 불확실성 기준 |
| 정밀도 / PR-AUC 변화 | 0.7727 / +0.0698 | 0.3793 / +0.0499 | 알림 부담의 최소 기준과 순위 품질의 경계 |
| 미탐 감소 | 4 | 31 | 비교 기준 모델보다 필요한 15 이상을 줄였는지 |
| 판단 | HOLD |
APPROVE |
고정된 모델 승인 판단 |
노트북의 assertion은 예상한 조건이 맞는지 확인하는 검증식입니다. 이 검증식이 실패하거나 공식 상태와 다른 결과가 나오면 임계값을 조정해 결과를 맞추지 않습니다. 확인한 자료의 경로, 현재 저장소 버전, 출력값, 예상한 정책 해시값을 함께 남기고 모델 담당자와 배포 검토자에게 알립니다.
실험과 버전 연결¶
MLflow 화면은 공식 판단을 새로 만들지 않지만, 프로필과 실행 ID가 선언 파일의 근거와 이어지는지 확인하는 보조 자료가 됩니다. 화면을 확인해야 할 때에는 로컬 Compose 환경이나 별도로 제공된 URL을 사용합니다.
docker compose -f deploy/compose/simple-mlops/compose.yaml up -d mlflow
curl http://127.0.0.1:5000/health
MLflow 화면에서는 프로필 설정값, 검증 품질 지표, 데이터셋 이력, 모델의 MLflow 실행 ID를 확인합니다. 로컬 Docker가 실행되지 않거나 접속할 MLflow URL이 없으면 노트북과 기존 배포 선언 파일로 이력을 확인하고, MLflow 화면은 확인하지 못했다고 기록합니다. 화면을 보지 못했다고 해서 공식 판단이 약해지는 것은 아니지만, 확인하지 않은 화면 결과를 완료했다고 기록해서는 안 됩니다.
6. 실습 결과 정리¶
공식 평가 자료만으로는 모델 평가 단계의 승인까지 기록할 수 있고, 대상 환경 배포 성공이나 Grafana의 실시간 신호는 아직 모릅니다.
- 확인한 사실: A=
HOLD, B=APPROVE, B 임계값 0.35, 재현율 0.8000, 하한 0.6956, 정밀도 0.3793, 미탐 감소 31 - 확인한 범위: 공식 평가에서의 모델 승인
- 아직 모르는 것: 대상 모델 패키지 식별정보, API 규칙, 요청과 운영 관측
- 다음 장의 질문: 승인된 Candidate B와 API·Kubernetes 선언이 같은 고정 모델 패키지를 가리키는가
“Candidate B의 정밀도가 A보다 낮으므로 모델은 HOLD다”라는 결론은 현재 정책과 맞지 않습니다. 현재 정책은 정밀도 최소 기준 하나가 아니라 재현율, 재현율 하한, PR-AUC 변화, 미탐 감소를 함께 요구합니다. Candidate B는 모든 필수 기준을 통과했습니다.
보고서 문장은 모델 승인 범위와 실행 환경에서 아직 확인하지 못한 사실을 분리해야 합니다. 아래 문장을 실제로 확인한 값으로 완성합니다.
공식 평가 결과에서 Candidate A는
HOLD, Candidate B는APPROVE입니다. Candidate B는threshold0.35에서 재현율, 재현율 하한, 정밀도, PR-AUC 변화, 미탐 감소 기준을 모두 통과했습니다. 이 판단은 공식 평가에서의 모델 승인에만 해당합니다. [대상 환경/로컬/준비한 설정]에서 같은 모델 패키지가 동작하는지는 [확인 상태]입니다.
보고서에는 잘못된 승인과 과도한 보류의 위험을 구분하고, 지금 쓸 수 있는 결론과 다음 확인을 맡을 담당자를 함께 기록합니다.
| 판단 위험 | 지금 쓸 수 있는 문장 | 담당자와 다음 할 일 |
|---|---|---|
| 잘못된 승인 | Candidate A를 승인하면 재현율, 재현율 하한, 미탐 감소 기준을 충족하지 못한 사실을 숨기게 됩니다. | 검토 담당자와 모델 담당자: A=HOLD를 유지하고 새 개정본이 필요한 조건을 기록합니다. |
| 과도한 보류 | Candidate B를 모델 자체 HOLD로 쓰면 모든 기준을 통과한 평가 결과를 부정해 배포 검토와 품질 판단을 불필요하게 늦춥니다. |
검토 담당자: B=APPROVE를 유지하고 서빙과 플랫폼 담당자에게 실행 환경 자료를 요청합니다. |
모델 승인 기록만으로는 Risk API와 Kubernetes 선언 파일이 같은 고정 모델 패키지를 가리킨다고 결론낼 수 없습니다. 실행 환경 범위는 비워 두거나 target_pending으로 남기고, 다음 장에서 이 질문을 확인합니다.