02. 데이터 검증과 모델 품질 평가¶
모델 품질 평가는 1장에서 확인한 기준 데이터 조건을 검증 기준과 모델 지표(metric) 해석으로 확장하는 과정입니다. 2장에서는 train, validation, test를 분리하고, 기준 validation 데이터셋과 품질 저하 validation 데이터셋을 같은 모델과 같은 임계값(threshold)으로 비교합니다. 핵심은 검증 실패와 지표 변화가 함께 나타날 때, 모델 자체 문제와 평가 조건 변화를 분리해 설명하는 것입니다.
2장에서 쓰는 vital_signs_valid_degraded.csv는 실제 운영 로그도 운영 DB 덤프도 아닙니다. 이 파일은 high_risk 예측 비율 증가 운영 시나리오에서 나타날 수 있는 결측, 범위 오류, 일부 라벨 기준 흔들림을 validation 기준에서 교육용으로 재현한 품질 저하 평가 데이터셋입니다. 실제 운영 사건은 4장과 5장에서 operational_holdout 기반 로그로 다시 확인합니다.
이 장에서 수강생은 모델 평가 결과를 검토하는 품질/운영 담당자로서, 지표 변화가 모델 자체의 문제인지 데이터 조건 변화 때문인지 분리해서 설명합니다.
| 기준 | 내용 |
|---|---|
| 맡는 일 | 데이터 검증 결과와 모델 지표를 함께 읽어 평가 조건과 모델 품질을 구분 |
| 이번 장의 상황 | 품질 저하 validation 데이터셋에서 검증 실패와 정밀도 하락, FP 증가, PR-AUC 하락이 함께 발생 |
| 확인 증거 | Great Expectations 리포트, Accuracy, Precision, Recall, FP/FN, PR-AUC(AUPRC), 평가 기록 |
| 판단 산출물 | 모델 지표 해석과 원인 후보를 포함한 QA 판단 문장 |
1. 공통 운영 시나리오 적용¶
공통 운영 시나리오 high_risk_prediction_shift는 2장에서 운영 로그가 아니라 재현 평가 질문으로 바뀝니다. 품질 저하 validation 데이터셋은 실제 운영 덤프가 아니며, 같은 모델과 같은 threshold에서 데이터 조건 변화가 지표를 흔드는지 확인하기 위한 비교 근거입니다.
| 항목 | 2장에서의 적용 |
|---|---|
| 이번 장의 역할 | 데이터 조건 변화가 같은 모델과 threshold의 지표를 흔드는지 확인 |
| 새로 확인하는 증거 | 검증 실패 리포트, validation 비교, FP/FN, PR-AUC |
| 후보 상태 변화 | 입력 품질 저하 후보는 강화하고, 모델 자체 결함 단정은 약화함 |
| 보고서 문장 | 같은 모델과 threshold에서 데이터 조건이 흔들리면 Precision과 PR-AUC가 낮아지고 FP가 증가할 수 있습니다 |
| 다음 질문 | 평가에서 확인한 모델과 threshold가 API 응답에서도 그대로 추적되는가 |
2. 이번 장에서 다룰 모델 평가 상황¶
2장은 같은 모델과 같은 임계값에서 데이터 조건만 달라졌을 때 지표가 어떻게 흔들리는지 확인합니다. 기준 데이터셋은 모델 평가가 가능한 상태였지만, 현재 운영 입력 변화를 재현한 품질 저하 평가 데이터셋에서는 heart_rate 결측과 oxygen_saturation 범위 오류가 검증 리포트에 나타납니다.
앞 장에서는 data/vital_signs_evaluation_baseline.csv가 모델 평가를 시작할 수 있는 데이터 조건인지 확인했습니다. 그러나 현재 운영 입력 샘플처럼 데이터 품질이 흔들릴 때 모델 지표가 어떻게 바뀌는지는 아직 판단하지 않았습니다. 2장은 이 남은 질문을 품질 저하 validation 데이터셋 검증 실패, 라벨과 예측 비교, FP/FN, PR-AUC로 좁혀 봅니다.
train split으로 기준 모델 학습
→ validation 기준 평가
→ 품질 저하 평가 데이터셋 검증 실패 확인
→ 같은 모델과 같은 threshold로 다시 평가
→ test split에서 선택된 설정 최종 확인
→ 정밀도, FP, PR-AUC 변화 확인
→ QA 판단: 데이터 품질 저하를 지표 변화의 강한 원인 후보로 남김
이 사건의 핵심은 “모델 자체 문제인가”와 “평가 조건 변화인가”를 구분하는 것입니다. 같은 모델과 같은 threshold를 사용했는데 검증 실패와 지표 변화가 함께 나타났다면, 모델 자체 문제로 단정하기 전에 데이터 조건 변화를 먼저 원인 후보로 기록해야 합니다.
3. 모델 품질 평가의 역할¶
2장의 역할은 데이터 조건이 충족된 상태에서 모델 품질을 어떻게 읽을지 정하는 것입니다. 1장에서는 data/vital_signs.csv가 필수 컬럼, 라벨(label), 관심 클래스 표본 수(Positive support), 범위 검증 기준을 충족하는지 확인했습니다. 2장은 그 판단을 자동 검증과 모델 지표 해석으로 확장합니다.
검증 규칙은 데이터가 모델 평가 전에 만족해야 하는 조건입니다. 예를 들어 필수 컬럼 존재, 라벨 허용 목록, 허용 범위, 관심 클래스 표본 수 최소 기준을 규칙으로 만들면 같은 기준을 반복해서 확인할 수 있습니다. 1장에서 사람이 Pandas로 확인한 내용을 2장에서는 파일과 리포트로 관리합니다.
모델 지표는 모델 예측을 라벨과 비교해 계산한 품질 숫자입니다. 하지만 숫자만으로 품질을 판단하면 위험합니다. 같은 정확도라도 클래스(class) 불균형, 임계값, FP/FN 비율에 따라 해석이 달라집니다.
2장에서는 다음 질문으로 모델 품질 평가를 읽습니다.
| 확인 대상 | 1장에서 가져온 전제 | 2장에서 확장할 판단 |
|---|---|---|
| 데이터 검증 | 필수 컬럼, 라벨, 관심 클래스 표본 수 확인 | 검증 규칙으로 반복 확인 |
| 검증 리포트 | 데이터 품질 리포트가 평가 전제를 설명 | 실패한 규칙이 평가 신뢰도에 미치는 영향 해석 |
| 모델 지표 | 라벨과 예측을 비교할 준비 완료 | 정확도, 정밀도, 재현율(Recall), PR-AUC를 함께 해석 |
| 임계값 | 점수가 예측으로 바뀌는 기준 필요 | FP/FN 균형과 업무상 허용 가능한 오류 유형 판단 |
| 평가 기록 | 어떤 데이터 조건에서 평가했는지 기록 필요 | 데이터셋, 모델 버전, 임계값, 지표 비교 |
이 표에서 중요한 것은 데이터 검증과 모델 평가는 분리된 작업이 아니라는 점입니다. 데이터 조건이 흔들리면 모델 지표의 의미도 흔들립니다. 따라서 2장에서는 먼저 데이터 검증 결과를 읽고, 그 다음 모델 지표를 해석합니다.
4. 핵심 질문¶
2장의 핵심 질문은 모델 지표 숫자보다 그 숫자를 믿을 수 있는 조건을 확인하는 것입니다. 모델 지표는 데이터 조건, 라벨 기준, 임계값에 따라 달라집니다. 따라서 “몇 점인가”보다 “어떤 조건에서 계산한 숫자인가”를 먼저 확인해야 합니다.
평가 데이터의 클래스 구성은 지표 해석의 안정성을 크게 바꿉니다. 예를 들어 high_risk 샘플(sample)이 충분하지 않은 평가 데이터에서는 재현율이나 PR-AUC가 작은 표본 변화에 크게 흔들릴 수 있습니다. 반대로 low_risk가 대부분인 데이터에서는 정확도가 높아도 관심 클래스를 잘 찾는 모델이라고 보기 어렵습니다. 품질 저하 validation 데이터셋에서 high_risk 예측 분포가 달라진 경우도 마찬가지입니다. 예측 비율 변화만으로는 좋아진 것인지 나빠진 것인지 알 수 없고, 실제 라벨과 비교해 FP/FN을 확인해야 합니다.
2장에서 사용할 핵심 질문은 다음과 같습니다.
| 확인 관점 | 핵심 질문 | 판단 근거 |
|---|---|---|
| 자동 검증 | 데이터 품질 기준을 검증 규칙으로 반복 적용할 수 있는가 | 필수 컬럼, 라벨, 범위, 관심 클래스 표본 수 |
| 검증 리포트 | 실패한 규칙이 모델 평가 신뢰도에 어떤 영향을 주는가 | 실패 항목, 실패 비율, 평가 전 판단 |
| 모델 지표 | 정확도 외에 정밀도, 재현율, FP/FN, PR-AUC를 함께 보는가 | 혼동 행렬(Confusion Matrix), 관심 클래스 기준 |
| 임계값 | 점수가 어떤 기준으로 예측으로 바뀌는가 | 임계값별 FP/FN 변화 |
| 평가 기록 | 데이터셋, 모델 버전, 임계값, 지표를 함께 남기는가 | JSON 평가 기록과 선택적 MLflow tracking |
이 질문들은 모델을 더 좋게 만드는 방법을 묻는 질문이 아닙니다. 모델 평가 결과를 QA 관점에서 설명할 수 있는지 묻는 질문입니다. 2장의 Lab과 Demo는 각 질문에 필요한 근거를 하나씩 확인하도록 구성되어 있습니다.
5. 학습 흐름¶
2장의 학습 흐름은 데이터 검증에서 시작해 모델 지표 해석과 평가 기록으로 이어집니다. 1장에서 수동으로 만든 판단을 자동 검증으로 반복하고, 그 검증 결과를 모델 평가 지표와 연결합니다. 이 흐름은 품질 저하 validation 데이터셋의 지표 변화 원인 후보를 데이터, 모델, 임계값, 기록 관점으로 좁혀 가는 순서입니다.
검증 규칙 정의
→ 검증 리포트 확인
→ 모델 지표 해석
→ 임계값 변화 비교
→ 데이터 품질과 지표 변화 연결
→ scikit-learn 평가 기록 확인
이 순서가 중요한 이유는 모델 지표를 먼저 계산하면 원인을 잘못 볼 수 있기 때문입니다. 검증 리포트에서 라벨 오류나 관심 클래스 표본 수 부족이 확인되면 지표 변화는 모델 자체 문제가 아니라 데이터 조건 문제일 수 있습니다. 반대로 데이터 조건이 안정적이라면 모델 지표와 임계값 비교에 더 집중할 수 있습니다.
2장의 문서 흐름은 다음 판단으로 이어집니다.
| 단계 | 확인하는 것 | 다음 질문 |
|---|---|---|
| 데이터 검증 자동화 | 수동 확인 기준을 검증 규칙으로 옮김 | 어떤 규칙 실패가 평가를 제한하거나 보류하게 만드는가 |
| Great Expectations 리포트 | 도구가 만든 검증 결과를 읽음 | 실패한 규칙을 QA 판단으로 어떻게 해석하는가 |
| 모델 지표 이해 | 정확도, 정밀도, 재현율, FP/FN, PR-AUC를 구분 | 어떤 지표를 함께 봐야 오류 유형을 설명할 수 있는가 |
| 모델 평가 Lab | 실제 평가 결과와 혼동 행렬 확인 | 데이터 조건이 지표에 어떤 영향을 주는가 |
| 평가 기록 Demo | 데이터셋, 모델 버전, 임계값, 지표 기록 | 평가 결과를 나중에 비교할 수 있는가 |
이 흐름을 따라가면 2장 끝에서는 “모델 지표가 높다/낮다”보다 더 구체적인 판단을 할 수 있습니다. 예를 들어 “vital_signs_valid_degraded.csv에서 결측과 범위 오류가 확인되었고, 같은 모델과 threshold에서 정밀도와 PR-AUC가 낮아지고 FP가 증가했으므로 입력 품질 저하를 원인 후보로 남긴다”처럼 설명할 수 있어야 합니다.
6. 산출물과 확인 기준¶
2장의 산출물은 데이터 검증 결과와 모델 평가 결과를 함께 해석하기 위한 근거입니다. 검증 리포트와 모델 평가 결과는 따로 읽지 않습니다. 검증 리포트는 지표를 믿을 수 있는 데이터 조건을 설명하고, 모델 평가 결과는 그 조건에서 모델이 어떤 오류를 내는지 보여줍니다.
2장에서 확인할 산출물은 다음과 같습니다.
| 산출물 | 실행 또는 확인 경로 | 보고서에 남길 필드 | QA 해석 |
|---|---|---|---|
| 검증 규칙 | 2-1 문서와 검증 설정 파일 | 결측값, 범위, 라벨, 관심 클래스 표본 수 기준 | 평가 전제가 반복 가능한 기준으로 정의되었는지 확인 |
| Great Expectations 리포트 | 2-2 문서의 리포트 해석 예시 | 실패한 규칙, 실패 비율, 실패 컬럼 | 데이터 조건이 평가 가능, 조건부 평가, 평가 보류 중 어디에 가까운지 판단 |
| 기준선 모델 artifact | uv run --group lab python labs/ch02_model_quality/train_baseline.py |
학습 행 수, 특성 목록, chapter_02_baseline.pkl 경로 |
이후 평가와 서빙이 같은 기준선 모델을 쓰는지 확인 |
| 모델 평가 결과 | labs/ch02_model_quality/model_evaluation_lab.ipynb, artifacts/experiments/chapter_02/model_test_eval.json |
Accuracy 0.7006, Precision 1.0000, Recall 0.4266, FP 0, FN 5989, PR-AUC 0.8033 |
관심 클래스와 오류 유형을 함께 해석 |
| validation/품질 저하 비교 결과 | artifacts/experiments/chapter_02/validation_degradation_comparison.json, artifacts/reports/chapter_02_model_quality_comparison.md |
Precision 1.0000 -> 0.9828, FP 0 -> 110, PR-AUC 0.7999 -> 0.7806 |
입력 품질 저하를 모델 지표 변화의 강한 원인 후보로 기록 |
| 임계값 비교 결과 | artifacts/experiments/chapter_02/validation_degradation_comparison.json의 threshold_analysis |
threshold별 FP/FN 변화와 업무상 더 위험한 오류 | 업무상 더 위험한 오류를 기준으로 조정 필요성 판단 |
| 평가 기록 | uv run --group lab python labs/ch02_model_quality/evaluate_and_record.py, artifacts/experiments/chapter_02/model_test_eval.json |
데이터셋 vital_signs_test, 모델 버전, threshold 0.50, metric 세트 |
선택 이후 test 조건이 기록되었는지 확인 |
평가 기록과 비교 artifact는 전체 시나리오와 분리된 별도 활동이 아닙니다. 시간이 있는 수강생은 make lab-model-quality로 scikit-learn 기준선 모델, test 평가 기록, 2장 비교 artifact를 다시 만들 수 있고, 시간이 부족하면 artifacts/experiments/chapter_02/model_test_eval.json, artifacts/experiments/chapter_02/validation_degradation_comparison.json, artifacts/reports/chapter_02_model_quality_comparison.md를 열어 데이터셋, 모델 버전, threshold, metric, validation/degraded 변화가 함께 남았는지 확인합니다. MLflow는 같은 기록을 도구 화면이나 tracking DB로 확인하는 선택 경로입니다.
산출물을 읽을 때는 “통과/실패”나 “높음/낮음”으로 끝내지 않습니다. 실패한 검증 규칙이 지표에 어떤 영향을 줄 수 있는지, 지표 변화가 데이터 조건 때문인지 모델 출력 때문인지, 임계값 변경 때문인지 구분해야 합니다. 2장 보고서에는 “같은 모델과 threshold에서 데이터 조건이 흔들릴 때 Precision과 PR-AUC가 낮아지고 FP가 증가했으므로, 모델 자체 결함으로 단정하기 전에 입력 품질 저하를 주요 원인 후보로 남긴다”는 형태의 판단을 남깁니다.
7. 문서 목록¶
아래 순서대로 읽으면 데이터 검증 결과를 모델 지표 해석과 평가 기록으로 연결할 수 있습니다. 각 문서는 하나의 판단 질문에 대응합니다.
| 순서 | 문서 | 확인할 내용 |
|---|---|---|
| 1 | 데이터 검증 자동화의 필요성 | 수동 확인 기준을 검증 규칙으로 바꾸는 이유 |
| 2 | Great Expectations 기반 검증 리포트 확인 | 실패한 검증 규칙을 QA 판단으로 해석하는 방법 |
| 3 | 모델 품질 지표 이해 | 정확도, 정밀도, 재현율, FP/FN, AUROC, PR-AUC의 역할 |
| 4 | scikit-learn 기반 모델 평가와 기록 실습 | 기준선(baseline) 평가 결과, 혼동 행렬, 임계값, 평가 기록 |
| 5 | 데이터 품질과 성능 지표의 연결 | 데이터 품질 저하가 점수와 지표에 미치는 영향 |
| 6 | 평가 기록 기반 버전 비교 | 데이터셋, 모델 버전, 임계값, 지표 기록과 비교 |
| 7 | 2장 마무리 | 모델 지표를 QA 판단으로 바꾸는 기준 |
| 8 | 전체 참고문헌 | 출처와 추가 학습 자료 |
2장이 끝나면 수강생은 같은 Kaggle 기반 데이터 흐름에서 데이터 조건 변화와 모델 지표 변화를 함께 설명할 수 있어야 합니다. 남은 질문은 이 평가 기준이 실제 API 응답과 배포 설정에서도 그대로 유지되는가입니다.