2-6. 평가 기록 기반 버전 비교¶
2-6 Demo의 목표는 2-4와 2-5에서 만든 평가 기록을 읽고, 나중에 같은 조건으로 다시 비교할 수 있는지 확인하는 것입니다. scikit-learn으로 학습한 기준선 모델의 지표(metric)는 숫자만 남기면 의미가 약해집니다. 어떤 데이터셋(dataset), 특성(feature), 라벨(label) 기준, 모델 버전(model_version), 임계값(threshold)에서 나온 값인지 함께 남아야 QA 판단에 사용할 수 있습니다.
이 Demo는 MLflow 서버 운영을 깊게 배우는 시간이 아닙니다. 수강생은 2-4의 evaluate_and_record.py가 만든 JSON 산출물과, 선택적으로 MLflow tracking 결과를 확인합니다. 핵심 질문은 “이 지표를 나중에 같은 조건으로 다시 비교할 수 있는가”입니다.
2장의 관통 사건과 연결하면, 품질 저하 validation 데이터셋의 FP 증가와 정밀도(Precision) 하락도 비교 조건이 함께 남아야 해석할 수 있습니다. model_test_eval.json은 선택된 모델과 threshold의 test 평가 조건을 기록하고, validation_degradation_comparison.json은 기준 validation과 품질 저하 validation 비교 조건을 기록합니다. 수강생은 두 기록을 함께 읽어 “test 평가 조건”과 “품질 저하 validation 비교 조건”이 모두 추적 가능한지 확인합니다.
| 산출물 | 경로 | 확인할 내용 |
|---|---|---|
| 평가 기록 CLI | labs/ch02_model_quality/evaluate_and_record.py |
scikit-learn 기준선 모델의 test 평가와 기록 생성 |
| JSON 평가 기록 | artifacts/experiments/chapter_02/model_test_eval.json |
MLflow가 없어도 확인 가능한 test 평가 조건과 지표 |
| validation/품질 저하 비교 JSON | artifacts/experiments/chapter_02/validation_degradation_comparison.json |
같은 모델과 threshold에서 데이터 조건 변화와 지표 변화가 함께 기록되었는지 확인 |
| 보고서용 비교 리포트 | artifacts/reports/chapter_02_model_quality_comparison.md |
릴리스 회의 보고서에 옮길 비교표와 제한 사항 확인 |
| 선택적 MLflow tracking DB | artifacts/mlflow.db |
MLflow가 설치된 환경에서 같은 평가 기록을 추적 도구로 확인 |
2-6-1. 평가 기록이 필요한 이유¶
평가 기록은 모델 평가 결과의 비교 조건을 잃어버리지 않기 위한 활동입니다. 정확도(Accuracy), 정밀도, 재현율(Recall) 같은 지표만 남기면 나중에 같은 조건에서 계산한 값인지 확인할 수 없습니다.
지표 개선처럼 보이는 변화도 평가 조건이 다르면 모델 자체 개선으로 볼 수 없습니다. 예를 들어 재현율이 0.66에서 0.72로 올랐다고 하겠습니다. 이 숫자만 보면 관심 클래스(Positive class)를 더 잘 찾게 된 것처럼 보입니다. 그러나 평가 데이터셋이 바뀌었거나, 관심 클래스 표본 수(Positive support)가 늘었거나, 임계값이 낮아졌다면 모델 자체 개선이라고 말할 수 없습니다.
2-5의 비교도 같은 문제를 가집니다. 품질 저하 validation 데이터셋에서 정밀도가 낮아지고 FP가 늘었다면, 그 결과가 같은 모델과 같은 임계값에서 나온 값인지 기록으로 확인할 수 있어야 합니다. 그렇지 않으면 데이터 품질 저하 때문인지, 모델 버전 변경 때문인지, 운영 기준 변경 때문인지 구분하기 어렵습니다.
2-6 Demo에서 확인하는 기록은 다음 질문에 답하기 위한 것입니다. 여기서 파라미터(parameter)는 모델 내부 가중치가 아니라, 평가 실행을 설명하는 조건값입니다.
| QA 질문 | 필요한 기록 |
|---|---|
| 같은 데이터셋으로 비교했는가 | dataset_name, dataset_version |
| 같은 입력 특성을 사용했는가 | feature_columns |
| 같은 라벨 기준인가 | label_mapping |
| 같은 모델 버전인가 | model_name, model_version |
| 같은 운영 기준인가 | operating_threshold |
| 어떤 오류 유형이 늘었는가 | false_positive, false_negative |
QA 관점에서 평가 기록은 모델 개발자의 내부 메모가 아닙니다. 배포 승인, 회귀 테스트, 장애 분석에 필요한 증거입니다. 비교 조건이 남아 있어야 “모델 자체 개선”과 “평가 조건 변화”를 구분할 수 있습니다.
2-6-2. 기록 산출물과 MLflow 선택 확인¶
2-4의 evaluate_and_record.py는 기준선(baseline) 모델을 vital_signs_test.csv에 적용하고, 선택된 모델과 threshold의 test 평가 조건과 지표를 기록합니다. 기본 실행은 JSON 산출물을 생성합니다. 여기서 산출물은 평가 결과를 다시 확인할 수 있게 남긴 파일을 뜻합니다.
2-6에서 확인할 일은 MLflow UI 자체가 아니라 test 단일 실행 기록과 validation/품질 저하 비교 artifact의 추적 가능성입니다. 이 Demo는 기록 구조를 보여주기 위해 단일 실행 기록(run)을 사용합니다. 기준 validation 데이터셋과 품질 저하 validation 데이터셋의 비교는 make lab-model-quality가 생성하는 validation_degradation_comparison.json에 남습니다. 따라서 test 단일 실행 기록과 validation/품질 저하 비교 artifact가 모두 데이터셋, 모델 버전, feature, threshold, FP/FN을 추적하는지 봐야 합니다.
이 명령은 2-4에서 만든 scikit-learn 평가 결과를 JSON 기록으로 남깁니다. 2-4에서 아직 평가 기록을 만들지 않았다면 다음 명령으로 생성합니다.
uv run --group lab python labs/ch02_model_quality/evaluate_and_record.py
MLflow 확인은 같은 평가 기록이 추적 도구에도 남는지 보는 선택 경로입니다. MLflow까지 함께 확인하려면 demo dependency group을 포함한 선택 Demo를 실행합니다. 이 명령도 같은 평가 기록 로직을 사용하며, MLflow가 설치된 환경에서는 artifacts/mlflow.db local tracking DB를 함께 남깁니다.
uv run --group demo python demos/ch02_mlflow/run_demo.py
이 출력에서 확인할 핵심은 평가 요약과 기록 경로가 같은 실행에서 함께 남는지입니다. 예상 출력은 평가 요약과 기록 경로입니다.
dataset=vital_signs_test
threshold=0.50
confusion_matrix=TP:4455 FP:0 FN:5989 TN:9558
metrics=accuracy:0.7006 precision:1.0000 recall:0.4266 f1:0.5980 auroc:0.7200 pr_auc:0.8033
experiment artifact
/.../artifacts/experiments/chapter_02/model_test_eval.json
수강생이 먼저 볼 파일은 JSON 산출물입니다. MLflow UI를 열지 않아도 어떤 조건에서 어떤 지표가 계산되었는지 확인할 수 있기 때문입니다. MLflow tracking DB는 같은 기록이 추적 도구에 어떻게 남는지 보여주는 선택 확인 항목입니다.
| 확인 대상 | 평가 기록에서의 값 | QA 해석 |
|---|---|---|
| 실행 기록(run) 이름 | model_test_eval |
선택된 모델과 threshold의 test 평가 실행을 식별 |
| 데이터셋 | vital_signs_test, v1-test |
최종 모델 평가 데이터 조건 확인 |
| 모델(model) | chapter_02_baseline, v1 |
비교할 모델 버전 확인 |
| 임계값 | 0.5 |
FP/FN 해석 기준 확인 |
| 산출물 | chapter_02_baseline.pkl |
재현에 필요한 모델 파일 추적 |
validation/품질 저하 비교의 조건과 변화량은 단일 test 실행과 분리해서 읽어야 합니다. 별도 artifact에서 확인합니다.
| 확인 대상 | 비교 artifact에서의 값 | QA 해석 |
|---|---|---|
| 비교 artifact | artifacts/experiments/chapter_02/validation_degradation_comparison.json |
같은 모델과 threshold에서 데이터 조건 변화와 지표 변화를 함께 확인 |
| 모델 버전 | v1 |
모델 자체 변경 가능성을 낮추는 조건 |
| 임계값 | 0.50 |
threshold 변경 효과와 데이터 조건 효과를 분리 |
| Precision 변화 | 1.0000 -> 0.9828 |
관심 클래스 예측 신뢰도 하락 후보 |
| FP 변화 | 0 -> 110 |
오탐 증가와 운영 부담 증가 후보 |
MLflow Tracking 공식 문서는 실행 기록(run)이 파라미터(parameter), 지표, 산출물 같은 메타데이터(metadata)를 남기는 단위라고 설명합니다. 2-6에서는 MLflow의 모든 기능을 다루지 않고, QA가 비교 조건을 잃지 않기 위해 무엇을 기록해야 하는지에 집중합니다.
2-6-3. 평가 조건 비교¶
평가 조건은 지표를 해석하기 위한 전제입니다. model_test_eval.json의 params에는 데이터셋, 모델(model), 특성, 라벨, 임계값이 함께 남습니다. 이 값들은 “무엇으로 평가했는가”를 설명합니다.
이 조건 표에서 확인할 핵심은 지표 비교 전에 평가 전제가 추적 가능한지입니다. 실제 JSON 산출물의 핵심 조건은 다음과 같습니다.
| 평가 조건 | 값 | QA가 확인할 것 |
|---|---|---|
dataset_name |
vital_signs_test |
어떤 평가 데이터셋인지 |
dataset_version |
v1-test |
선택 이후 test 데이터 버전인지 |
model_name |
chapter_02_baseline |
어떤 모델인지 |
model_version |
v1 |
어떤 모델 버전인지 |
feature_columns |
heart_rate, respiratory_rate, ... |
입력 특성이 같은지 |
label_mapping |
High Risk=high_risk, Low Risk=low_risk |
라벨 값 표준화 기준이 같은지 |
operating_threshold |
0.5 |
예측(prediction) 변환 기준이 같은지 |
평가 조건이 빠지면 지표 변화의 원인을 분리하기 어렵습니다. 예를 들어 정밀도가 낮아졌을 때 operating_threshold가 함께 남아 있지 않으면 모델 점수(score)가 나빠진 것인지, 임계값이 바뀐 것인지 알기 어렵습니다.
QA는 지표를 비교하기 전에 먼저 평가 조건을 비교합니다.
| 비교 조건 | 같아야 해석하기 쉬운 이유 |
|---|---|
dataset_version |
데이터 변경 효과를 분리 |
feature_columns |
입력 정보 변경 효과를 분리 |
label_mapping |
라벨 값 표준화 방식의 변경 효과를 분리 |
operating_threshold |
FP/FN 균형 변경 효과를 분리 |
이 조건이 다르면 지표 차이를 모델 품질 차이로 단정하지 않습니다. 먼저 조건이 달라진 비교인지, 같은 조건에서의 비교인지 분리해야 합니다. 2-5의 기준 validation 데이터셋과 품질 저하 validation 데이터셋 비교는 validation_degradation_comparison.json에서 같은 모델 버전과 threshold 조건으로 기록합니다.
2-6-4. 지표와 오류 유형 비교¶
지표는 모델 평가 결과입니다. model_test_eval.json의 metrics에는 정확도, 정밀도, 재현율, F1, AUROC, PR-AUC(AUPRC)와 함께 FP/FN 개수가 기록됩니다. 이 값들은 모두 같은 실행 기록(run)의 조건 아래에서 계산된 결과로 읽어야 합니다.
이 평가 기록에서 확인할 핵심은 지표와 오류 건수가 같은 실행 조건 아래 묶여 있는지입니다. 실제 평가 기록은 다음과 같습니다.
| 지표 | 값 | QA 해석 |
|---|---|---|
accuracy |
0.7006 |
전체 샘플(sample) 중 맞힌 비율 |
precision |
1.0000 |
관심 클래스로 예측한 것 중 실제 관심 클래스 비율 |
recall |
0.4266 |
실제 관심 클래스 중 탐지한 비율 |
auroc |
0.7200 |
점수의 클래스(class) 구분력 참고 |
pr_auc |
0.8033 |
관심 클래스 탐지 품질 참고 |
false_positive |
0 |
오탐(FP) 건수 |
false_negative |
5989 |
미탐(FN) 건수 |
FP/FN을 함께 남기는 이유는 정밀도와 재현율만으로는 운영 부담을 바로 설명하기 어렵기 때문입니다. 정밀도가 낮아졌다는 말보다 FP가 몇 건 늘었는지 함께 보면 후속 확인과 운영 기준 논의가 쉬워집니다.
지표 기록은 정확도보다 오류 유형과 조건을 먼저 확인하는 순서로 읽어야 합니다. 다음 순서가 좋습니다.
| 순서 | 확인 질문 |
|---|---|
| 1 | 정확도만 보지 않고 정밀도, 재현율을 함께 봤는가 |
| 2 | FP와 FN 중 어떤 오류가 더 큰가 |
| 3 | AUROC와 PR-AUC가 점수 구분력 약화를 시사하는가 |
| 4 | 지표를 계산한 평가 조건이 명확한가 |
이 순서를 지키면 평가 기록이 단순 점수표가 아니라 품질 판단 근거가 됩니다.
2-6-5. 산출물과 재현 가능성 확인¶
재현 가능성은 나중에 같은 결과를 다시 확인할 수 있는 산출물이 남아 있을 때 확보됩니다. 2-4의 평가 기록에는 기준선 모델 파일 artifacts/models/chapter_02_baseline.pkl이 함께 연결됩니다. JSON 산출물 자체도 QA가 확인할 수 있는 평가 기록입니다.
산출물을 남기는 이유는 그때 어떤 모델과 데이터 조건으로 계산했는가를 확인하기 위해서입니다. 모델 파일이나 평가 리포트가 없으면 run 이름과 지표만 남아도 재현이 어렵습니다.
| 산출물 | 확인 이유 |
|---|---|
| 모델 파일 | 같은 모델로 평가를 재현할 수 있는지 확인 |
| JSON 평가 기록 | MLflow UI 없이도 평가 조건과 지표 확인 |
| validation/품질 저하 비교 JSON | 데이터 품질 저하와 모델 지표 변화의 연결 확인 |
| 보고서용 비교 리포트 | 수강생이 prepared artifact에서 확인한 값으로 보고서 문장 작성 |
| 선택적 MLflow tracking DB | 실행 기록(run) 간 비교와 검색 가능성 확인 |
MLflow UI 확인의 목적은 화면 사용법이 아니라 여러 실행 기록(run)의 조건 차이를 빠르게 찾는 것입니다. MLflow UI를 사용할 수 있다면 실행 기록 목록에서 model_test_eval을 찾고 평가 조건과 지표를 확인합니다.
MLflow가 설치되어 있지 않은 환경에서는 JSON 산출물만으로도 이번 Demo의 핵심 목적을 달성할 수 있습니다. 중요한 것은 도구 이름이 아니라, 평가 조건과 지표를 함께 남기는 습관입니다. 수강생은 model_test_eval.json으로 단일 실행 조건을 확인하고, validation_degradation_comparison.json으로 2장 사건의 비교 조건과 변화량을 확인합니다.
2-6-6. 버전 비교와 품질 회귀 판단¶
버전 비교의 목적은 최신 모델이 더 적합한지 묻는 것이 아니라, 새 결과가 품질 기준을 만족하는지 확인하는 것입니다. 최신 모델이 항상 승인 가능한 모델은 아닙니다. 특정 지표는 높아졌지만 FP나 FN이 늘어날 수 있습니다.
품질 회귀(regression)는 새 데이터, 새 모델, 새 임계값에서 기존보다 품질 기준이 후퇴하는 상황입니다. 여기서 회귀(regression)는 회귀 모델(regression model)이 아니라, 이전보다 품질이 후퇴한 상태를 뜻합니다. QA는 회귀가 의심될 때 원인을 네 영역으로 나누어 봅니다.
| 원인 영역 | 확인할 기록 |
|---|---|
| 데이터 변경 | dataset_version, 관심 클래스 표본 수, 검증 리포트 |
| 입력 특성 변경 | feature_columns |
| 모델 변경 | model_version, 모델 산출물 |
| 운영 기준 변경 | operating_threshold, FP/FN 변화 |
품질 회귀가 의심될 때는 다음 순서로 비교합니다. 2장의 validation/품질 저하 비교에서는 첫 단계에서 vital_signs_valid_degraded.csv의 검증 실패를 확인하고, 이후 같은 모델과 임계값 조건에서 FP와 정밀도가 어떻게 바뀌었는지 봅니다.
데이터 검증 결과 확인
→ 기준선 지표 확인
→ 새 실행 기록의 평가 조건 비교
→ 정밀도/재현율과 FP/FN 비교
→ AUROC/PR-AUC 변화 확인
→ 비교 조건 일치 여부와 회귀 의심 여부 정리
보고 문장은 조건과 결과를 함께 담아야 합니다. 다음 예시는 model_test_eval 단일 실행 기록(run)과 validation/품질 저하 비교 artifact를 함께 읽는 방식입니다.
model_test_eval 실행 기록(run)은 `dataset_version=v1-test`, `model_version=v1`,
`operating_threshold=0.5` 조건에서 계산되었습니다.
정밀도는 1.0000, 재현율은 0.4266이며 FP는 0건, FN은 5989건입니다.
다음 모델 버전과 비교할 때는 `dataset_version`, `feature_columns`,
`label_mapping`, `operating_threshold`가 같은지 먼저 확인합니다.
조건이 다르면 지표 차이를 모델 개선 또는 회귀로 단정하지 않습니다.
validation/품질 저하 비교 artifact에서는 같은 `model_version=v1`과 `operating_threshold=0.5`
조건에서 품질 저하 validation 데이터셋의 정밀도가 1.0000에서 0.9828로 낮아지고
FP가 0건에서 110건으로 증가했음을 확인했습니다.
이 변화는 입력 품질 저하를 강한 원인 후보로 남기되,
실제 API의 model_version과 threshold 일치성은 3장에서 확인합니다.
2장의 결론은 모델 지표를 단독 숫자로 보지 않는 것입니다. 데이터 검증 결과, 평가 조건, 모델 버전, 임계값, FP/FN이 함께 남아야 모델 품질을 QA 판단으로 바꿀 수 있습니다. 다음 확인은 이 기준이 실제 API 응답과 서빙 환경에서도 유지되는지입니다.