1-5. 모델 평가 전 데이터 품질 결과 해석¶
데이터 품질 리포트는 모델 평가를 시작해도 되는지 설명하기 위한 판단 근거입니다. 1-5에서는 1-4 Lab에서 만든 artifacts/reports/chapter_01_quality_report.md를 읽고, 출력값을 그대로 옮기는 대신 모델 평가 전 QA 판단 문장으로 바꾸는 방법을 정리합니다.
1-5에서 해석하는 리포트는 data/vital_signs_evaluation_baseline.csv 실습 기준 데이터의 결과입니다. 이 리포트가 1장의 운영 사건 원인을 직접 확정하는 것은 아니며, 운영 사건을 만났을 때 어떤 형식으로 데이터 조건을 판단하고 기록할지 연습하는 자료입니다.
이 문서를 읽을 때는 다음 기준을 중심으로 확인합니다.
- 리포트 해석 순서: 데이터 규모, 필수 컬럼, 라벨(label), 관심 클래스 표본 수(Positive support), 범위 검증 결과
- 판단 표현 선택:
평가 가능,조건부 평가,평가 보류를 코드 출력이 아니라 QA 보고 표현으로 사용 - 제한 사항 기록: 결측치, 이상치, 라벨 문제를 모델 지표(metric) 해석의 조건으로 남김
- 모델 입력 컬럼 구분: 평가에 쓰는 특성(feature)과 추적/참고 컬럼을 구분
- 다음 확인: 데이터 조건이 설명된 뒤 모델 지표를 계산할 준비가 되었는지 판단
1-5-1. 데이터 품질 리포트를 읽는 관점¶
리포트의 첫 역할은 모델 평가의 전제 조건을 확인하는 것입니다. 1-4 Lab에서 만든 리포트는 모델 품질을 직접 평가하지 않습니다. 대신 모델 지표를 계산하기 전에 데이터 구조, 라벨 기준, 관심 클래스 표본 수, 명백한 범위 오류가 설명 가능한 상태인지 보여줍니다.
리포트를 읽을 때는 “통과했는가”보다 “이 조건에서 지표를 해석할 수 있는가”를 먼저 봅니다. 모델 지표는 라벨, 특성, 클래스(class) 분포의 영향을 받습니다. 따라서 데이터 조건을 설명하지 않고 정확도(Accuracy), 정밀도(Precision), 재현율(Recall)을 계산하면 숫자는 있어도 해석이 약해집니다.
이번 실습 리포트의 핵심 값은 다음과 같습니다. 기본 평가 전제 충족은 1-4 실습 코드가 만든 편의 확인값이며, 업계 표준 용어가 아닙니다. 이 값은 기본 전제 확인을 빠르게 보여줄 뿐이고, 최종 판단은 아래 세부 항목을 함께 읽어 작성합니다.
| 리포트 항목 | 실습 결과 | 먼저 해석할 것 |
|---|---|---|
| 행(row) 수 | 20002 |
평가 대상 행 수가 예상 범위인지 확인 |
| 컬럼(column) 수 | 17 |
실습용 스키마(schema) 기준으로 컬럼이 정리되었는지 확인 |
| 누락 필수 컬럼 | 없음 |
필수 컬럼 누락으로 평가 전제가 깨지지 않았는지 확인 |
| 기본 평가 전제 충족 | True |
실습 코드 기준의 기본 전제 확인값으로만 사용 |
high_risk 표본 수 |
10416 |
관심 클래스(Positive class)를 평가할 표본 수 확인 |
low_risk 표본 수 |
9586 |
비교 클래스(Negative class)의 표본 수 확인 |
| 허용되지 않은 라벨, 라벨 결측 | 0, 0 |
정답 기준에 포함할 수 없는 값과 빈 값 여부 확인 |
| 범위 검증 결과 | 모든 항목 0.00% |
명백한 허용 범위 초과 값이 있는지 확인 |
이 표에서 바로 결론을 내리면 안 됩니다. 예를 들어 기본 평가 전제 충족이 True라도 결측치가 특정 클래스에 집중되거나, 클래스 비율이 기준선과 크게 다르거나, 모델 입력 기준이 불명확하면 제한 사항을 남겨야 합니다. 리포트는 결론이 아니라 판단의 출발점입니다.
1장의 품질 이상 사례처럼 API는 정상 응답을 반환하지만 high_risk 예측(prediction) 비율이 급증했다면, 같은 형식의 리포트를 신규 데이터나 운영 배치에 적용해 원인 후보를 줄입니다. 필수 컬럼과 라벨이 정상이라면 잘못된 파일 구조나 라벨 결측 가능성은 낮아집니다. 반대로 범위 오류나 허용되지 않은 라벨이 보이면 모델 자체 문제가 아니라 데이터 조건 문제를 먼저 확인해야 합니다.
| 리포트 신호 | 줄어드는 원인 후보 | 아직 남는 확인 |
|---|---|---|
| 필수 컬럼 누락 없음 | 잘못된 파일 구조, 스키마 누락 | 결측치 위치, 타입 오류, 모델 입력 컬럼 기준 |
| 라벨 결측과 허용되지 않은 라벨 없음 | 정답 기준 누락 또는 허용되지 않은 값 | 라벨 생성 기준, 클래스 비율 |
| 범위 검증 오류 없음 | 명백한 숫자 범위 오류 | 기준선 대비 입력 분포 변화 |
| 관심 클래스 표본 수 충분 | 관심 클래스 평가 표본 부족 | 정밀도, 재현율, PR-AUC(AUPRC) 해석 |
QA 관점에서는 각 항목을 독립적으로 보지 않습니다. 범위 오류가 없더라도 high_risk 비율이 이전 평가 데이터와 크게 다르면 지표 비교에는 제한이 생길 수 있습니다. 리포트의 각 값은 모델 지표 해석의 조건으로 읽어야 합니다.
1-5-2. 모델 평가 전 판단 표현¶
모델 평가 전 판단은 데이터가 완벽한지 묻는 것이 아니라, 지표를 설명할 수 있는지 묻는 것입니다. 실무 데이터에는 작은 결측치나 일부 이상치가 있을 수 있습니다. 중요한 것은 그 문제가 모델 평가 결과를 크게 왜곡하는지, 그리고 제한 사항으로 설명할 수 있는지입니다.
평가 가능, 조건부 평가, 평가 보류는 1-4 코드가 자동으로 출력하는 값이 아닙니다. 리포트 결과를 읽은 뒤 QA 보고서나 실습 코멘트에 사용할 판단 표현입니다. 자동 확인값인 기본 평가 전제 충족과 사람이 작성하는 판단 문장을 분리해야 합니다.
이 세 표현은 도구가 출력하는 상태값이나 업계 표준 상태명이 아니라, 수업에서 데이터 품질 결과를 설명하기 위해 사용하는 판단 문장입니다. 여기서는 모델 지표를 계산하기 전에 데이터 조건을 어떻게 설명할지에 초점을 둡니다.
이번 실습 리포트에 붙일 기본 판단 표현은 평가 가능입니다. 필수 컬럼이 누락되지 않았고, 라벨 결측과 허용되지 않은 라벨이 없으며, 관심 클래스 표본 수가 충분하고, 범위 검증 오류도 없습니다. 이 상태에서는 data/vital_signs_evaluation_baseline.csv 기준으로 모델 지표를 계산할 수 있습니다.
다만 평가 가능은 데이터 품질 이슈가 전혀 없다는 뜻이 아닙니다. 현재 실습 기준 데이터와 설정 파일 기준으로 모델 평가 전제가 충족되었다는 뜻입니다. 모델 평가 후 지표가 기대와 다르게 나오면, 1장에서 확인한 데이터 조건을 다시 근거로 삼아 모델 자체 문제와 데이터 문제를 구분해야 합니다.
판단 표현은 리포트 값을 그대로 복사하지 않고 모델 지표 해석의 의미로 바꾸어야 합니다. 아래 표는 리포트 값을 판단 표현으로 바꾸는 방식입니다.
| 리포트에서 확인한 내용 | 판단 표현 | 보고 문장 |
|---|---|---|
| 필수 컬럼 누락 없음, 라벨 결측 없음, 관심 클래스 표본 수 충분 | 평가 가능 | 현재 데이터는 모델 평가에 필요한 특성과 라벨을 포함합니다 |
| 낮은 비율의 허용 범위 초과 값 존재 | 조건부 평가 | 모델 평가는 가능하지만 해당 특성의 범위 오류를 제한 사항으로 함께 보고합니다 |
| 클래스 비율이 기준선과 크게 다름 | 조건부 평가 | 이전 평가 결과와 비교할 때 데이터 구성 변화가 제한 사항으로 남습니다 |
| 라벨 결측 또는 허용되지 않은 라벨 포함 | 평가 보류 | 정답 기준이 불안정해 모델 지표를 신뢰하기 어렵습니다 |
| 필수 특성 누락 | 평가 보류 | 모델 입력 조건이 학습 또는 평가 기준과 달라져 먼저 데이터 구조를 수정해야 합니다 |
조건부 평가는 문제가 작다는 뜻이 아닙니다. 현재 데이터로 평가를 진행할 수는 있지만, 결과 해석에 제한 사항을 함께 적어야 한다는 뜻입니다. 예를 들어 oxygen_saturation 허용 범위 초과 값이 낮은 비율로 존재한다면, 모델 지표가 흔들릴 때 이 항목을 다시 확인해야 합니다.
평가 보류는 모델 개발을 멈춘다는 뜻이 아닙니다. 라벨 확인, 필수 컬럼 복구, 샘플(sample) 보강, 데이터 생성 로직 점검이 먼저 필요하다는 뜻입니다. 정답 기준이나 입력 조건이 깨진 상태에서 모델 지표를 계산하면 모델 자체 문제와 데이터 문제를 구분하기 어렵습니다.
이번 실습 리포트를 QA 문장으로 바꾸면 다음처럼 정리할 수 있습니다.
현재 데이터는 필수 컬럼을 포함하고 있으며,
라벨 값은 `high_risk`와 `low_risk`로 정리되어 있습니다.
라벨 결측과 허용되지 않은 라벨은 없고,
관심 클래스 표본 수는 모델 평가를 진행할 수 있을 만큼 충분합니다.
범위 검증에서도 허용 범위 초과 값은 확인되지 않았습니다.
QA 판단: 평가 가능
후속 조치: 모델 지표를 계산하고,
지표 해석 시 현재 데이터 조건을 함께 보고합니다.
이 문장은 모델이 좋다는 결론이 아닙니다. 데이터 품질 관점에서 모델 평가를 시작할 수 있다는 판단입니다. 모델이 실제로 어떤 품질을 보이는지는 라벨과 예측을 비교해 확인해야 합니다.
1장 판단은 기준 데이터의 평가 가능성에 한정합니다. 운영에서 관측된 high_risk 비율 0.4583과 평균 점수 0.6402의 원인은 아직 현재 입력 구성 변화, 모델 지표 변화, threshold 변경, API 또는 운영 로그 변화 중 어느 하나로 좁힐 수 없습니다. 이 원인 후보는 2장 이후 현재 운영 입력 샘플의 검증 실패, 품질 저하 validation 데이터셋의 모델 지표, threshold, 서빙 응답, 운영 로그 증거를 연결해 줄여 가야 합니다.
1-5-3. 모델 입력에 쓰는 컬럼과 제외할 컬럼 구분¶
모델 평가에서는 데이터 파일에 있는 모든 컬럼을 모델 입력으로 보지 않아야 합니다. 데이터 파일에는 모델 입력 특성, 라벨, 추적용 메타데이터(metadata), 참고용 파생 특성이 함께 들어 있을 수 있습니다. 1-5에서는 어떤 컬럼이 실제 모델 평가에 쓰이는지 먼저 구분합니다.
이번 실습의 모델 입력 특성은 configs/validation/model_features.yaml에 정리되어 있습니다. feature_columns에는 heart_rate, respiratory_rate, body_temperature, oxygen_saturation, systolic_blood_pressure, diastolic_blood_pressure가 포함됩니다. 모델 평가는 이 목록에 있는 컬럼만 입력으로 사용합니다.
1-4 Lab의 데이터 품질 확인은 configs/validation/dataset_schema.yaml의 model_feature_columns를 사용했고, 모델 학습과 평가는 configs/validation/model_features.yaml의 feature_columns를 사용합니다. 두 목록은 같은 모델 입력 특성을 가리키도록 맞춰져 있습니다. 이 일치성이 있어야 데이터 품질 확인 결과를 모델 지표 해석 조건으로 그대로 넘길 수 있습니다.
두 설정 파일의 역할은 다음처럼 구분합니다. 1장에서는 데이터 파일 안의 컬럼을 품질 확인 관점으로 분류하고, 모델 평가는 별도 설정 파일에 고정된 특성 목록을 사용합니다.
| 설정 파일 | 핵심 필드 | 역할 |
|---|---|---|
dataset_schema.yaml |
required_columns |
데이터 파일이 기본 구조를 갖췄는지 확인 |
dataset_schema.yaml |
model_feature_columns |
1장 Lab에서 모델 입력 후보의 결측치와 범위 오류를 확인 |
dataset_schema.yaml |
metadata_columns |
추적과 원인 분석에 쓸 참고 컬럼 구분 |
dataset_schema.yaml |
derived_feature_columns |
현재 모델 입력은 아니지만 계산 기준을 확인할 파생 특성 구분 |
configs/validation/model_features.yaml |
feature_columns |
실제 모델 학습과 평가에 사용하는 입력 특성 |
configs/validation/model_features.yaml |
excluded_columns |
모델 입력에서 명시적으로 제외할 컬럼 |
이 구분이 필요한 이유는 평가 결과의 의미가 달라지기 때문입니다. 추적용 ID나 시간 정보(timestamp)는 문제 원인을 찾는 데 유용하지만, 검토 없이 모델 입력으로 사용하면 운영 재현성이나 데이터 누수(leakage) 문제가 생길 수 있습니다. 여기서 데이터 누수(leakage)는 평가 시점에는 사용할 수 있지만 실제 예측 시점에는 사용할 수 없는 정보가 모델 입력에 섞이는 문제를 뜻합니다. 파생 특성도 계산식과 생성 시점이 분명하지 않으면, 평가에서는 지표가 높게 보이더라도 운영에서는 같은 조건을 만들기 어려울 수 있습니다.
데이터 파일에는 이 목록 밖의 컬럼도 있습니다. excluded_columns에는 patient_id, timestamp, derived_hrv, derived_pulse_pressure, derived_bmi, derived_map처럼 명시적으로 모델 입력에서 제외할 컬럼이 들어 있습니다. 또한 age, gender, weight_kg, height_m처럼 데이터 품질 확인에는 쓰지만 현재 모델 입력에는 쓰지 않는 참고 컬럼도 있습니다.
컬럼 구분은 모델 지표 조건과 원인 분석 참고 정보를 분리하기 위한 기준입니다. 아래 표는 현재 데이터 파일의 컬럼을 평가 관점에서 나누어 읽는 방법입니다.
| 컬럼 유형 | 예시 | 1장에서의 판단 |
|---|---|---|
| 모델 입력 특성 | heart_rate, oxygen_saturation |
모델 평가에 쓰는 입력 조건으로 확인 |
| 라벨 | label |
예측과 비교할 정답 기준으로 확인 |
| 추적용 메타데이터(metadata) | patient_id, timestamp |
오류 원인 추적과 시간대 비교에 사용 |
| 데이터 품질 참고 컬럼 | age, gender, weight_kg, height_m |
범위와 분포 확인에 사용하되 현재 모델 입력으로 보지 않음 |
| 참고용 파생 특성 | derived_bmi, derived_map |
현재 모델 입력에서는 제외하고 계산 기준만 확인 |
현재 모델 입력 설정에서 제외된 파생 특성은 모델 지표 근거로 해석하지 않아야 합니다. 예를 들어 derived_bmi나 derived_map은 데이터 파일에 존재하지만, 현재 모델 입력 설정에서는 제외되어 있습니다. 따라서 1장에서 이 값들을 모델 지표 근거로 해석하지 않습니다. 다만 이후 모델 입력에 포함하려면 계산식, 단위, 생성 시점, 운영에서 같은 값을 만들 수 있는지를 별도로 확인해야 합니다.
이 구분은 서빙 일치성으로도 이어집니다. 학습과 평가에서 사용한 특성이 운영 API에서도 같은 방식으로 들어와야 합니다. 1장에서는 먼저 “무엇을 모델 입력으로 보았는가”를 명확히 남기고, 같은 입력 조건이 서빙 환경에서도 유지되어야 한다는 확인 대상을 남깁니다.
컬럼 구분을 QA 기록으로 남기면 다음과 같습니다.
| 확인 결과 | QA 해석 |
|---|---|
모델 입력 특성은 configs/validation/model_features.yaml 기준으로 확인 |
지표는 해당 입력 조건에서만 해석 |
patient_id, timestamp, age, gender, weight_kg, height_m은 현재 모델 입력이 아님 |
원인 분석과 데이터 품질 확인에는 사용하되 모델 지표 근거로 보지 않음 |
derived_* 컬럼은 현재 모델 입력에서 제외 |
사용하려면 계산식과 운영 재현성 검토 필요 |
이 절의 결론은 단순합니다. 모델 평가 전에는 “데이터 파일에 무엇이 들어 있는가”와 “모델 평가에 무엇을 사용했는가”를 분리해야 합니다. 이 구분이 있어야 이후 계산할 지표의 조건을 설명할 수 있습니다.
1-5-4. 모델 평가 전 판단 기록¶
판단 기록은 통과 표시가 아니라 모델 평가 전 조건을 설명하는 근거입니다. 1장의 마지막 확인은 모델 지표를 계산하기 전에 데이터 조건을 정리하는 것입니다. 기록에는 “확인했는가”보다 “이 결과가 모델 지표 해석에 어떤 의미인가”가 담겨야 합니다.
판단 기록은 1-4 Lab 출력이 모델 지표 해석의 어떤 전제 조건인지 연결해야 합니다. 아래 표는 1-4 Lab 출력과 1-5의 판단을 연결합니다.
| 확인 항목 | 확인 방법 | 판단에 쓰는 방식 |
|---|---|---|
| 필수 컬럼 존재 | missing_columns |
모델 입력과 라벨 비교가 가능한지 확인 |
| 특성 결측치 | missing_count, missing_ratio |
입력 정보 부족이 지표 해석을 제한하는지 확인 |
| 라벨 결측치 | LabelSupport.missing_count |
정답 비교가 가능한 행이 충분한지 확인 |
| 특성 이상치 | range_results |
입력값 의미가 흔들릴 수 있는지 확인 |
| 허용되지 않은 라벨 | LabelSupport.invalid_count |
라벨 값 표준화 규칙 문제 여부 확인 |
| 관심 클래스 표본 수 | LabelSupport.positive_count |
관심 클래스 평가 안정성 확인 |
| 클래스 비율 | 라벨 개수와 비율 | 기준선과 비교할 때 데이터 구성 변화 확인 |
| 모델 입력 특성 | configs/validation/model_features.yaml |
지표를 계산한 입력 조건 확인 |
| 모델 입력 제외 또는 참고 컬럼 | excluded_columns, metadata_columns |
추적용/참고용 컬럼을 모델 입력으로 오해하지 않도록 기록 |
판단 기록은 다음 순서로 읽으면 자연스럽습니다.
데이터 구조 확인
→ 결측치와 이상치 확인
→ 라벨 분포와 관심 클래스 표본 수 확인
→ 모델 입력 특성과 제외 컬럼 구분
→ 모델 평가 전 판단 표현 선택
→ 모델 지표 해석으로 이동
판단 기록을 작성할 때는 통과/실패만 남기지 않습니다. 확인 결과, 판단, 제한 사항, 다음 조치를 함께 남겨야 이후 모델 평가 결과를 설명할 수 있습니다.
| 기록 항목 | 예시 |
|---|---|
| 확인 결과 | label 결측치 0건, 허용되지 않은 라벨 0건 |
| 판단 | 모델 평가 진행 가능 |
| 제한 사항 | 현재 리포트 기준의 데이터 조건에서만 지표를 해석 |
| 다음 조치 | 모델 지표를 계산하고 데이터 조건과 함께 보고 |
이번 실습 리포트 값으로 실제 기록을 남기면 다음과 같습니다. 이 표는 1장 마무리의 최종 QA 코멘트로 이어지는 중간 기록입니다.
| 기록 항목 | 이번 실습 기록 |
|---|---|
| 확인 결과 | 필수 컬럼 누락 없음, 라벨 결측 0건, 허용되지 않은 라벨 0건, 범위 초과 0건 |
| 판단 | 평가 가능 |
| 제한 사항 | 이 판단은 data/vital_signs_evaluation_baseline.csv와 현재 설정 파일 기준의 데이터 조건에 한정 |
| 다음 조치 | 같은 데이터 조건을 검증 규칙(validation rule)으로 반복 확인하고 모델 지표를 계산 |
1-5의 결론은 간단합니다. 현재 리포트 값이 평가 전제를 충족하면 모델 평가를 진행할 수 있습니다. 다만 모델 평가 결과는 항상 데이터 조건과 함께 읽어야 합니다. 1장 마무리에서는 이 판단을 최종 QA 코멘트 형식으로 정리합니다.
따라서 1-5를 마친 보고서 문장은 “기준 데이터는 평가 가능하다”에서 멈춰야 합니다. “운영 high_risk 증가 원인이 모델 문제다”, “배포를 승인한다”, “배포를 보류한다” 같은 결론은 1장 증거만으로는 방어할 수 없습니다.