1-3. 데이터 품질의 중요성¶
데이터 품질은 모델 평가 결과를 믿고 해석할 수 있는지 결정하는 전제 조건입니다. 1-3에서는 1-2에서 본 high_risk 예측 비율 증가 사건을 데이터 품질 관점으로 다시 읽습니다. 핵심은 결측치, 이상치, 라벨 오류, 클래스 불균형이 모델 평가 전에 어떤 원인 후보가 되는지 구분하는 것입니다.
목표는 오류 이름을 외우는 것이 아닙니다. API가 정상이고 코드 변경이 없어도 예측 비율이 달라졌다면, 먼저 데이터 조건을 확인해야 합니다. 1-3은 같은 사건을 결측치, 이상치, 라벨, 클래스 분포라는 네 가지 증거로 나누어 보는 절입니다.
데이터 품질 이슈는 세 가지 평가 조건으로 나누어야 해석이 쉬워집니다. 같은 오류처럼 보여도 모델 입력을 흔드는 문제인지, 정답 기준을 흔드는 문제인지, 평가 표본 구성을 흔드는 문제인지에 따라 확인할 근거와 후속 판단이 달라집니다.
| 평가 조건 | 확인 질문 | 1-3에서 다루는 이슈 |
|---|---|---|
| 입력값 상태 | 특성(feature)의 결측치와 이상치가 모델 입력을 흔드는가 | 결측치, 이상치, 범위 오류 |
| 정답 기준 | 라벨이 예측과 비교할 만큼 일관되는가 | 라벨 오류, 허용되지 않은 라벨, 라벨 값 표준화 오류 |
| 평가 표본 구성 | 관심 클래스(Positive class)와 비교 클래스(Negative class)를 평가할 표본이 충분한가 | 클래스 불균형, 분포 치우침 |
이 세 조건을 확인하면 데이터 오류를 단순 통계가 아니라 모델 평가 전에 남길 해석 조건으로 정리할 수 있습니다. 1-4 Lab의 data/vital_signs_evaluation_baseline.csv는 이 판단 흐름을 연습하기 위한 기준 데이터입니다. 1-3에서는 운영 사건을 데이터 품질 질문으로 나누고, 1-4에서는 같은 질문을 실습 데이터와 리포트 출력으로 확인합니다.
1-3-1. 모델 평가 전 확인해야 할 데이터 조건¶
평가 가능한 데이터란 오류가 전혀 없는 데이터가 아니라, 모델 평가 결과를 해석할 조건이 확인된 데이터입니다. 실무 데이터에는 결측치, 표기 차이, 일부 극단값이 남아 있을 수 있습니다. 중요한 것은 오류의 존재 여부만 세는 것이 아니라, 그 오류가 모델 입력, 정답 기준, 평가 표본 구성 중 어디를 흔드는지 구분하는 것입니다.
1-2에서는 데이터 상태가 점수(score)와 예측에 영향을 준다는 큰 흐름을 봤습니다. 1-3에서는 그 흐름을 세 가지 조건으로 나눕니다. 입력값 상태는 모델이 직접 보는 특성의 상태이고, 정답 기준은 예측과 비교할 라벨의 상태입니다. 평가 표본 구성은 관심 클래스와 비교 클래스를 지표(metric)로 해석할 만큼 표본이 충분한지 보는 조건입니다.
이 절의 판단 대상은 “완벽한 데이터”가 아닙니다. 모델 평가 전에 필요한 질문은 현재 데이터의 한계를 알고도 지표를 해석할 수 있는지입니다. 따라서 데이터 품질 확인 결과는 통과/실패 목록이 아니라, 이후 모델 평가 결과를 읽을 때 함께 붙일 조건으로 남아야 합니다.
데이터셋의 상태와 한계를 기록해야 하는 이유도 여기에 있습니다. Datasheets for Datasets는 데이터셋의 동기, 구성, 수집 과정, 권장 사용 범위를 문서화해야 한다는 관점을 제시합니다. 1장에서는 이 관점을 데이터 품질 리포트로 좁혀 사용합니다. 어떤 조건의 데이터로 지표를 계산했는지 남겨야 뒤에서 나온 숫자를 올바르게 해석할 수 있기 때문입니다.
실습 데이터는 Kaggle의 Human Vital Sign Dataset을 기반으로 교육용 분류(classification) 예제로 가공합니다. 생체신호 값은 현실의 건강 상태를 판단하기 위한 근거가 아니라, 데이터 품질 문제가 모델 평가에 어떤 영향을 주는지 설명하기 위한 예제입니다.
운영 로그에서 high_risk 예측 비율이 평소보다 크게 늘었다면, 곧바로 모델 장애라고 볼 수 없습니다. 먼저 heart_rate 같은 입력 특성이 비어 있는지, oxygen_saturation처럼 범위 규칙이 분명한 값이 깨졌는지, label 기준이 일관되는지, 관심 클래스인 high_risk 표본 수가 충분한지 확인해야 합니다. 이 질문들은 모델을 고치기 전에 데이터 조건을 분리하는 순서입니다.
품질 이상 현상은 원인을 확정하기 전에 데이터 조건으로 되짚어야 합니다. 아래 표는 품질 이상 현상을 데이터 조건으로 되짚는 방법입니다. 표의 목적은 원인을 확정하는 것이 아니라, 어떤 근거를 먼저 확인해야 하는지 정리하는 것입니다. 1-4 Lab에서는 configs/validation/dataset_schema.yaml과 configs/validation/data_quality_rules.yaml에 적힌 기준으로 같은 항목을 확인합니다.
| 사건에서 확인할 조건 | 실습 데이터 예시 | 1-4 Lab에서 볼 근거 | 평가 전 판단 |
|---|---|---|---|
| 입력값 상태 | heart_rate, oxygen_saturation |
missing_count, invalid_count, 영향받은 행(row) |
모델 입력 정보가 부족하거나 왜곡되는지 판단 |
| 정답 기준 | 원본 Risk Category, 정리 후 label |
허용되지 않은 라벨 수, 라벨 결측 수 | 예측과 비교할 정답 기준을 신뢰할 수 있는지 판단 |
| 평가 표본 구성 | high_risk, low_risk 건수 |
라벨별 건수, 관심 클래스 표본 수(Positive support) | 관심 클래스 평가가 가능한지 판단 |
| 기준 데이터와 비교 | 기준 데이터와 신규 데이터의 클래스 비율 | 클래스 비율 변화, 특정 시간대 집중 여부 | 이전 평가 결과와 직접 비교해도 되는지 판단 |
이 구분을 기준으로 보면 heart_rate 결측치와 label 결측치는 둘 다 빈 값이지만 평가에 미치는 영향이 다릅니다. oxygen_saturation = 135처럼 허용 범위를 벗어난 값과 실제로 낮거나 높은 유효값도 같은 방식으로 처리하면 안 됩니다. 데이터 품질 확인은 값을 고치는 작업보다, 어떤 값이 모델 평가 해석을 제한하는지 먼저 구분하는 작업입니다.
1-4 Lab에서는 이 표의 확인 방법을 실습 기준 데이터에 적용합니다. 필수 컬럼은 스키마 확인 결과로, 결측치와 이상치는 요약표와 영향을 받은 행으로 확인합니다. 라벨 기준과 관심 클래스 표본 수는 라벨 표본 수 출력으로 확인합니다. 여기까지 확인하면 “데이터 구조가 흔들렸는가”라는 첫 번째 원인 후보를 줄일 수 있습니다.
1-3-2. 결측치와 이상치¶
결측치와 이상치는 모델 입력을 흔들 수 있으므로 전체 개수보다 발생 위치와 집중 여부를 먼저 확인합니다. 결측치(missing value)는 데이터에서 값이 비어 있는 상태이고, 이상치(outlier)는 일반적인 값의 범위를 벗어난 데이터입니다. 두 문제는 모두 데이터 오류처럼 보이지만, 평가를 제한하는 방식은 서로 다릅니다.
결측치의 영향은 위치에 따라 달라집니다. 모델 입력 특성의 결측치는 점수 계산을 흔들 수 있고, 라벨의 결측치는 지표 계산 자체를 어렵게 만듭니다. timestamp나 샘플(sample) 추적용 ID가 비어 있으면 운영 시점이나 특정 요청을 추적하기 어려워집니다.
high_risk 비율 증가 사건에서 결측치를 발견하면 먼저 영향 범위를 나눕니다. 같은 빈 값이라도 모델 입력인지, 정답 기준인지, 추적 정보인지에 따라 평가 전 판단이 달라집니다.
| 결측 위치 | 예시 | 먼저 확인할 질문 | 평가에 미치는 영향 |
|---|---|---|---|
| 특성 결측치 | heart_rate 누락 |
모델 입력으로 쓰는 컬럼인가 | 점수 계산 또는 분포 해석 제한 |
| 라벨 결측치 | label 누락 |
예측과 비교할 정답이 남아 있는가 | 지표 계산 대상 제외 가능 |
| 시간 정보 결측치 | timestamp 누락 |
특정 시점의 품질 변화를 추적해야 하는가 | 시간대별 원인 분석 제한 |
| 추적 ID 결측치 | 샘플 추적용 ID 누락 | 같은 샘플을 재현할 수 있는가 | 원인 분석과 재현 어려움 |
이상치는 “드물지만 가능한 값”과 “데이터 오류로 봐야 하는 값”을 구분해서 읽어야 합니다. 예를 들어 oxygen_saturation = 135가 늘었다면, high_risk 증가를 모델 판단 변화로 보기 전에 입력 수집 오류 후보를 먼저 확인해야 합니다. 극단적인 값이 모두 오류는 아니지만, 허용 범위를 벗어난 값이나 오류 코드가 특성에 들어오면 점수 분포와 지표 해석을 제한할 수 있습니다.
아래 기준은 실습의 범위 검증 규칙 일부입니다. 이 범위는 현실의 건강 상태를 판단하는 기준이 아니라, 교육용 데이터에서 명백한 입력 오류 후보를 찾기 위한 품질 규칙입니다.
| 특성 | 실습 허용 범위 | 범위 안 값의 해석 | 범위 밖 값의 해석 |
|---|---|---|---|
heart_rate |
1~250 | 모델 입력으로 사용 가능 | -999는 오류 코드 유입 후보 |
oxygen_saturation |
0~100 | 범위 오류는 아님 | 135는 수집 또는 단위 오류 후보 |
body_temperature |
30~45 | 범위 오류는 아님 | 120은 단위 오류 또는 파싱 오류 후보 |
age |
0~120 | 범위 오류는 아님 | 음수나 120 초과 값은 입력 오류 후보 |
행 단위로 보면 결측치와 이상치는 더 분명해집니다. 아래 표는 이런 값을 발견했을 때 high_risk 증가 사건과 어떻게 연결해 읽어야 하는지 보여주는 설명용 샘플입니다. 여기서는 “값이 있다”와 “평가에 써도 된다”를 구분하는 연습이 중요합니다.
| 샘플 | heart_rate |
oxygen_saturation |
label |
QA 해석 |
|---|---|---|---|---|
| A | 82 | 97.2 | low_risk |
기본 확인 가능 |
| B | 비어 있음 | 96.4 | low_risk |
모델 입력 특성 결측으로 평가 제한 사항 기록 |
| C | 79 | 135.0 | high_risk |
산소포화도(oxygen saturation) 허용 범위 초과, 수집 오류 후보 |
| D | -999 | 95.8 | low_risk |
오류 코드가 특성 값으로 들어온 후보 |
이 표에서 중요한 것은 결측치와 이상치가 어느 클래스에 집중되는지입니다. 전체 결측 비율이 낮아도 high_risk 샘플에 집중되어 있으면 관심 클래스 평가가 흔들릴 수 있습니다. 반대로 모델 평가에 사용하지 않는 참고 컬럼에만 결측치가 있다면 high_risk 증가 사건을 설명하는 근거로는 약합니다.
결측치와 이상치를 처리할 때 가장 위험한 방식은 이유를 남기지 않고 삭제하거나 대체하는 것입니다. 삭제하면 특정 클래스나 특정 시간대의 샘플이 줄어들 수 있고, 대체하면 원래 분포와 다른 값이 들어갈 수 있습니다. 따라서 처리 전에는 컬럼, 비율, 실제 행, 특정 클래스 집중 여부를 먼저 기록해야 합니다.
처리 방법을 고르기 전에 “무엇을 확인해야 다음 판단으로 넘어갈 수 있는가”를 정리합니다. 아래 표는 값을 고치는 절차가 아니라, 모델 평가를 진행하기 전 원인 후보를 줄이는 질문입니다.
| 발견한 현상 | 피해야 할 처리 | 먼저 확인할 질문 |
|---|---|---|
heart_rate 결측치 |
결측 행 일괄 삭제 | 특정 클래스나 시간대에 결측이 몰려 있는가 |
oxygen_saturation = 135 |
임의로 100으로 보정 | 수집 단위, 파싱 오류, 원본 파일 오류 중 무엇인가 |
body_temperature = 120 |
극단값으로 그대로 사용 | 단위 오류인지, 범위 규칙을 벗어난 입력 오류인지 확인했는가 |
오류 코드 -999 |
숫자이므로 모델 입력에 포함 | 결측 표시값이 숫자 특성에 섞인 것은 아닌가 |
1-4 Lab에서는 labs/ch01_data_quality/pandas_data_quality_lab.ipynb로 결측치 요약을 만들고, labs/ch01_data_quality/pandas_data_quality_lab.ipynb로 범위 검증 결과를 확인합니다. 이론에서 본 질문은 실제 출력에서 missing_count, missing_ratio, invalid_count, invalid_ratio, 영향을 받은 행의 라벨 분포로 나타납니다.
| 이론에서 확인한 질문 | 1-4 Lab 출력 | 판단 방식 |
|---|---|---|
| 어떤 값이 비어 있는가 | missing_count, missing_ratio |
모델 입력 특성인지 라벨인지 구분 |
| 어떤 값이 허용 범위를 벗어났는가 | invalid_count, invalid_ratio |
수집 오류, 단위 오류, 오류 코드 유입 후보 확인 |
| 문제가 특정 클래스에 몰렸는가 | 결측 또는 이상치 행의 라벨 분포 | 관심 클래스 평가 제한 여부 확인 |
| 문제가 특정 시점에 몰렸는가 | 결측 또는 이상치 행의 timestamp |
운영 수집 경로나 배치 생성 조건 확인 |
현재 실습 기준 데이터의 실제 출력에서는 모델 입력 특성의 missing_count가 모두 0이고, 품질 리포트의 범위 검증 결과에서도 invalid_count가 모두 0입니다. 이 결과는 기준 데이터에서 명백한 입력 결측과 범위 오류 후보가 낮다는 뜻입니다. 따라서 1장에서는 모델 평가를 시작할 수 있는 기준선을 만들고, 이후 같은 기준으로 신규 데이터나 비교 데이터를 다시 확인합니다.
1-3-3. 라벨 오류와 라벨 값 표준화¶
라벨은 모델 평가에서 정답으로 보는 값이므로, 라벨 기준이 흔들리면 지표 해석도 흔들립니다. 모델 품질 지표는 예측을 라벨과 비교해 계산합니다. 그래서 라벨이 잘못되었거나 일관되지 않으면 지표 변화가 모델 자체 변화인지 데이터 조건 변화인지 판단하기 어렵습니다.
Kaggle 원본 데이터에서 정답 역할을 하는 컬럼은 Risk Category입니다. 실습에서는 이 컬럼을 label로 이름 붙이고, 원본 값인 High Risk, Low Risk를 모델 평가에 쓰는 값인 high_risk, low_risk로 맞춥니다. 라벨 값 표준화(label normalization)는 새로운 정답을 만드는 작업이 아니라, 같은 의미의 정답 값을 코드와 지표 계산에서 일관되게 쓰도록 맞추는 작업입니다.
실습 코드에서는 이 기준을 packages/ai-quality/src/ai_quality/common/labels.py의 LABEL_MAP과 ALLOWED_LABELS로 고정합니다. 따라서 라벨을 확인할 때는 원본 값이 무엇이었는지, 정리된 값이 무엇인지, 그 값이 평가에서 어떤 클래스를 뜻하는지 함께 봐야 합니다.
| 원본 라벨 | 실습용 라벨 값 | 평가에서의 의미 |
|---|---|---|
High Risk |
high_risk |
관심 클래스 |
Low Risk |
low_risk |
비교 클래스 |
high_risk 비율 증가 사건에서 라벨 문제는 두 층으로 나누어 봐야 합니다. 첫 번째는 원본 Risk Category 자체가 잘못 기록된 경우입니다. 두 번째는 원본 값을 high_risk, low_risk로 맞추는 규칙이 잘못된 경우입니다. 라벨 값 표준화는 표기를 맞추는 작업일 뿐, 원본 라벨의 의미가 맞는지까지 자동으로 보장하지는 않습니다.
| 라벨 문제 | 예시 | 먼저 확인할 근거 | 평가 전 영향 |
|---|---|---|---|
| 원본 라벨 오류 | High Risk로 기록되어야 할 샘플이 Low Risk로 기록 |
원본 데이터, 라벨 생성 기준 | 학습과 평가의 정답 기준 왜곡 |
| 라벨 값 표준화 오류 | High Risk를 low_risk로 정리 |
LABEL_MAP, 정리 후 클래스 건수 |
관심 클래스와 비교 클래스 기준 뒤집힘 |
| 허용되지 않은 라벨 | Unknown, Medium Risk |
ALLOWED_LABELS, invalid_count |
평가 전 라벨 값 표준화 또는 제외 기준 필요 |
| 라벨 결측치 | Risk Category가 비어 있음 |
missing_count, 결측 행 |
지표 계산 대상에서 제외 가능 |
| 표기 불일치 | High risk, HIGH_RISK, High Risk |
원본 값 목록, 라벨 값 표준화 규칙 | 같은 의미가 여러 클래스로 분리될 가능 |
이렇게 두 층으로 나누면 확인할 근거가 달라집니다. 원본 라벨 오류는 원본 데이터와 데이터 생성 기준을 확인해야 하고, 라벨 값 표준화 오류는 LABEL_MAP, 허용 라벨, 정리 후 클래스 건수를 확인해야 합니다.
라벨 오류는 결측치나 이상치보다 발견하기 어려울 수 있습니다. 결측치는 비어 있고, 이상치는 범위 규칙으로 찾을 수 있습니다. 그러나 잘못된 라벨은 형식상 정상처럼 보일 수 있습니다. 그래서 모델이 틀린 것인지, 정답 기준이 틀린 것인지 구분하기 어렵습니다.
라벨 값 표준화 오류는 특히 위험합니다. 원본 High Risk와 Low Risk를 high_risk, low_risk로 바꿀 때 기준이 뒤집히면, 모델과 데이터가 그대로여도 평가 결과의 의미가 바뀝니다.
| 원본 라벨 | 올바른 정리 결과 | 잘못된 정리 결과 | 발생하는 문제 |
|---|---|---|---|
High Risk |
high_risk |
low_risk |
관심 클래스가 비교 클래스로 해석됨 |
Low Risk |
low_risk |
high_risk |
비교 클래스가 관심 클래스로 해석됨 |
High risk |
high_risk |
invalid 또는 누락 |
표기 차이 때문에 샘플 제외 가능 |
라벨 품질 확인은 모델 평가 전 가장 중요한 정답 기준 확인입니다. 특성이 문제이면 모델 입력이 흔들리고, 라벨이 문제이면 평가 기준이 흔들립니다. 정답 기준이 흔들린 상태에서 계산한 정확도(Accuracy), 정밀도(Precision), 재현율(Recall)은 모델 품질보다 라벨 문제를 반영할 수 있습니다.
1-4 Lab에서는 허용 라벨 목록과 정리 후 라벨 분포를 확인합니다. 실습 코드의 라벨 상수는 packages/ai-quality/src/ai_quality/common/labels.py에 있으며, 라벨 분포와 관심 클래스 표본 수는 labs/ch01_data_quality/pandas_data_quality_lab.ipynb에서 확인합니다.
현재 실습 기준 데이터의 리포트에서는 허용되지 않은 라벨이 0건이고, 라벨 결측도 0건입니다. 이 결과는 기준 데이터의 정답 기준을 모델 평가에 사용할 수 있다는 근거입니다. 이 근거가 있어야 이후 예측이 틀렸는지, 라벨 기준이 흔들렸는지, 입력 데이터가 달라졌는지를 분리해서 볼 수 있습니다.
1-3-4. 클래스 불균형과 분포 치우침¶
클래스 불균형은 정확도를 높아 보이게 만들 수 있으므로 관심 클래스의 표본 수를 먼저 확인해야 합니다. 클래스 불균형(class imbalance)은 한쪽 클래스가 다른 클래스보다 지나치게 많거나 적은 상태입니다. 표본 수(support)는 평가 데이터 안에 특정 클래스가 몇 건 있는지를 뜻합니다.
이 절에서는 두 가지 문제를 구분해서 봅니다. 클래스 불균형은 라벨의 비율 문제이고, 분포 치우침은 특정 특성, 시간대, 그룹, 데이터 출처(source)에 샘플이 몰리는 문제입니다. 둘 다 평가 결과를 왜곡할 수 있지만 확인할 근거가 다릅니다.
| 구분 | 흔히 보이는 현상 | 먼저 확인할 근거 |
|---|---|---|
| 클래스 불균형 | high_risk 또는 low_risk 한쪽이 너무 적음 |
라벨별 건수, 관심 클래스 표본 수 |
| 분포 치우침 | 특정 시간대, 연령대, 수집 경로 데이터가 과도하게 많음 | timestamp, 주요 특성 분포, 데이터 출처(source) |
분류(classification) 문제에서는 클래스 불균형이 정확도를 쉽게 착시로 만들 수 있습니다. 아래 숫자는 원리를 설명하기 위한 단순 예시입니다. 평가 데이터의 95%가 low_risk이고 5%만 high_risk라고 하겠습니다.
| 라벨 | 건수 | 비율 |
|---|---|---|
low_risk |
950 | 95% |
high_risk |
50 | 5% |
이 상태에서 모든 샘플을 low_risk로 예측하면 1000건 중 950건을 맞힙니다. 정확도는 95%지만, 관심 클래스인 high_risk 50건은 모두 놓칩니다. 그래서 불균형 데이터에서는 “전체 중 몇 개를 맞혔는가”와 “관심 클래스를 실제로 찾았는가”를 분리해서 봐야 합니다.
| 예측 방식 | 정확도 | 관심 클래스 확인 | QA 해석 |
|---|---|---|---|
모든 샘플을 low_risk로 예측 |
95% | high_risk 0건 탐지 |
정확도만 보면 높아 보이지만 관심 클래스를 전혀 찾지 못함 |
high_risk 일부를 구분하는 모델 |
예: 90% | 일부 high_risk 탐지 가능 |
정확도는 낮아도 관심 클래스 탐지 여부를 따로 해석할 수 있음 |
이 예시는 정확도를 버리자는 뜻이 아닙니다. 클래스 불균형이 있을 때는 정확도만으로 품질을 판단하지 말고, 관심 클래스를 실제로 평가할 표본이 충분한지 먼저 확인해야 한다는 뜻입니다. 모델 평가에서는 이 조건 위에서 정밀도, 재현율, PR-AUC(AUPRC)를 함께 읽습니다.
현재 실습 기준 데이터는 불균형 예시와 다른 상태입니다. high_risk와 low_risk가 모두 충분한 표본 수를 갖고 있으며, 한쪽 클래스가 극단적으로 적은 데이터는 아닙니다. 따라서 관심 클래스 표본 수 부족은 현재 기준 데이터에서 강한 제한 사항이 아닙니다.
| 라벨 | 건수 | 대략적 비율 | QA 해석 |
|---|---|---|---|
high_risk |
충분 | 약 절반 수준 | 관심 클래스 평가 표본 충분 |
low_risk |
충분 | 약 절반 수준 | 비교 클래스 표본 충분 |
이 결과는 모델이 좋은지 나쁜지를 말하지 않습니다. 단지 정밀도, 재현율, PR-AUC 같은 지표를 계산할 때 관심 클래스 표본 부족이 강한 제한 사항은 아니라는 뜻입니다.
클래스 비율 변화는 모델 지표를 비교할 때 먼저 확인해야 하는 데이터 조건입니다. 여기서 말하는 클래스 비율은 라벨(label) 기준의 high_risk와 low_risk 비율입니다. 운영 로그에서 보이는 high_risk 비율은 예측(prediction) 분포이므로, 1장 표에 섞지 않고 4장과 5장에서 score, threshold, prediction 흐름으로 따로 해석합니다.
| 비교 대상 | low_risk 비율 |
high_risk 비율 |
QA 해석 |
|---|---|---|---|
| 기준 평가 데이터 | 약 절반 | 약 절반 | 관심 클래스와 비교 클래스 표본이 모두 충분함 |
| 신규 평가 데이터 | 60% | 40% | 라벨 구성 변화가 지표 비교에 영향을 줄 수 있음 |
| 특정 출처에서 추출한 평가 데이터 | 55% | 45% | 데이터 출처(source)나 표본 구성 집중 여부 확인 |
이 변화가 평가 데이터의 라벨 구성 변화라면 모델 지표 해석에 영향을 줄 수 있습니다. 반대로 평가 데이터 추출이나 필터링 오류라면 평가 데이터를 다시 구성해야 합니다. 운영 prediction 분포 변화와 평가 label 분포 변화는 서로 다른 증거이므로 보고서에서 분리해 적어야 합니다.
| 원인 후보 | 확인할 근거 | 다음 조치 |
|---|---|---|
| 실제 입력 변화 | 시간대별 요청, 데이터 출처(source), 주요 특성 분포 | 운영 관측과 원인 분석으로 연결 |
| 평가 데이터 추출 오류 | 추출 조건, 기간, 중복 제거 기준 | 평가 데이터 재생성 |
| 라벨 기준 변화 | LABEL_MAP, 허용 라벨, 원본 Risk Category 분포 |
라벨 기준 재확인 |
| 특정 구간 데이터 집중 | timestamp, age, 주요 특성 히스토그램(histogram) |
기준 데이터와 비교 |
그래서 클래스 불균형은 모델 지표 해석뿐 아니라 데이터 파이프라인 검증과도 연결됩니다. 모델 지표를 읽을 때도 먼저 확인할 질문은 “관심 클래스를 평가할 표본이 충분한가”입니다.
분포 치우침은 클래스 비율만의 문제가 아닙니다. 특정 나이대, 성별, 체형 구간, 시간대, 데이터 출처(source)에 샘플이 몰릴 수 있습니다. 1장에서는 이런 치우침을 공정성 평가로 깊게 확장하지 않고, 평가 데이터가 한쪽 조건에 과도하게 몰려 있지는 않은지 확인하는 수준으로 제한합니다.
| 치우침 유형 | 예시 | 평가 전 확인 |
|---|---|---|
| 클래스 치우침 | low_risk 대부분 |
관심 클래스 표본 수와 클래스 비율(class ratio) |
| 특성 구간 치우침 | 특정 산소포화도 구간에 집중 | 주요 특성 분포 |
| 시간 치우침 | 특정 기간 또는 시간대 데이터만 많음 | timestamp 분포 |
| 그룹 치우침 | 특정 age, gender 구간 데이터가 많음 |
주요 그룹별 샘플 수 |
| 데이터 출처(source) 치우침 | 특정 수집 경로의 요청만 포함 | 데이터 출처(source) 또는 파일 생성 조건 |
1-3에서 클래스 불균형의 핵심은 두 가지입니다. 첫째, 평가 데이터 안에 관심 클래스가 충분히 있는지 확인합니다. 둘째, 기준 데이터와 비교할 때 클래스 비율이 크게 달라졌는지 확인합니다. 1장에서는 지표를 계산하기 전 데이터 조건을 확인하고, 이 조건이 모델 평가 결과를 읽는 출발점이 됩니다.
1-3-5. 데이터 오류가 지표 해석에 미치는 영향¶
데이터 품질 확인의 끝은 오류 목록이 아니라 모델 평가 전에 남길 해석 조건입니다. 결측치, 이상치, 라벨 오류, 클래스 불균형을 발견했다면 “문제가 있다”에서 멈추지 않고, 모델 평가 결과를 읽을 때 어떤 제한이 생기는지 정리해야 합니다.
데이터 오류는 모두 같은 심각도를 갖지 않습니다. 사용하지 않는 참고 컬럼의 결측치와 모델 입력 특성의 결측치는 영향이 다릅니다. 한두 건의 범위 오류와 특정 클래스에 집중된 범위 오류도 다르게 해석해야 합니다. QA와 운영 관점에서는 오류의 위치, 규모, 클래스 집중 여부를 근거로 평가 전 제한 사항을 적어야 합니다.
데이터 품질 문제는 지표 해석의 제한 사항으로 표현해야 QA 판단에 쓸 수 있습니다. 아래 표는 데이터 품질 문제를 지표 해석의 제한 사항으로 바꾸는 방법입니다.
| 데이터 품질 문제 | 지표 해석에서 생기는 제한 | 평가 전 판단 |
|---|---|---|
| 특성 결측치 | 점수 계산에 필요한 입력 정보가 부족할 수 있음 | 결측 컬럼, 결측 비율, 특정 클래스 집중 여부 확인 |
| 특성 이상치 | 점수 분포가 실제 입력 특성보다 오류값에 흔들릴 수 있음 | 허용 범위, 초과 건수, 실제 행 예시 확인 |
| 라벨 오류 | 예측과 비교할 정답 기준이 흔들릴 수 있음 | 원본 라벨, 허용 라벨, 라벨 값 표준화 규칙 확인 |
| 관심 클래스 표본 수 부족 | 관심 클래스 지표가 일부 샘플에 크게 흔들릴 수 있음 | high_risk 건수와 비율 확인 |
| 클래스 비율 급변 | 이전 평가 결과와 직접 비교하기 어려울 수 있음 | 기준 데이터와 신규 데이터의 클래스 비율(class ratio) 비교 |
제한 사항의 강도는 문제의 위치와 지표 영향 가능성에 따라 달라집니다. 예를 들어 high_risk 비율 증가와 같은 시점에 oxygen_saturation 이상치가 일부 확인되었지만 비율이 낮고 원인이 설명 가능하다면 제한 사항을 기록하고 평가를 진행할 수 있습니다. 반대로 label 결측이나 허용되지 않은 라벨이 많다면 정답 기준이 흔들리므로 라벨 기준 확인이나 데이터 보완을 먼저 해야 할 수 있습니다.
데이터 오류를 실무 보고서에 적을 때는 오류 이름만 쓰지 않습니다. 무엇이 발견되었고, 어떤 평가 해석을 제한하며, 다음에 무엇을 확인해야 하는지까지 적어야 합니다.
| 단순 기록 | 평가 전 제한 사항으로 바꾼 기록 | 다음 확인 |
|---|---|---|
heart_rate 결측치 42건 |
주요 특성인 heart_rate 결측치 42건이 확인되어 입력 정보 부족 가능성을 제한 사항으로 남김 |
결측 행의 클래스와 시간대 분포 |
oxygen_saturation 이상치 있음 |
oxygen_saturation 허용 범위 초과 값이 있어 수집 오류와 단위 오류 여부 확인 필요 |
원본 값, 단위, 파싱 로직 |
| 관심 클래스 표본 수가 적음 | high_risk 표본 수가 낮아 관심 클래스 지표의 안정성이 낮을 수 있음 |
평가 데이터 재구성 가능 여부 |
| 라벨 오류 있음 | 허용되지 않은 라벨이 포함되어 라벨 값 표준화 규칙 확인 전 지표 해석 보류 필요 | 원본 라벨, LABEL_MAP, 허용 라벨 |
1-4 Lab의 품질 리포트는 모델 평가 전 조건을 설명하는 근거입니다. 현재 실습 기준 데이터의 리포트는 필수 컬럼 누락 없음, high_risk 10416건, low_risk 9586건, 허용되지 않은 라벨 0건, 라벨 결측 0건, 범위 오류 0건을 보여줍니다. 이 값들은 모델이 좋다는 결론이 아니라, 모델 지표를 계산해 볼 수 있는 데이터 조건을 설명하는 근거입니다.
현재 리포트를 평가 전 조건 관점으로 읽으면 다음과 같습니다. 여기서는 최종 보고 문장을 만들기보다, 1-4 Lab에서 어떤 출력값을 확인해야 하는지까지 연결합니다. 최종 보고 표현은 1-5에서 따로 정리합니다.
| 리포트 근거 | 현재 값 | 1-4에서 확인할 출력 | 평가 전 판단 |
|---|---|---|---|
| 필수 컬럼 | 누락 없음 | missing_columns |
모델 입력과 라벨을 함께 확인 가능 |
| 라벨 기준 | 허용되지 않은 라벨 0건, 라벨 결측 0건 | LabelSupport |
정답 기준으로 사용할 수 있음 |
| 관심 클래스 표본 수 | high_risk 10416건 |
LabelSupport |
관심 클래스 평가 표본 충분 |
| 범위 검증 | 모든 항목 0.00% | range_results |
기준 데이터에서는 명백한 범위 오류 없음 |
이 표는 실습 기준 데이터에서 모델 평가를 시작할 수 있는 전제 조건을 보여줍니다. 다만 이 판단은 모든 운영 데이터에 문제가 없다는 뜻이 아닙니다. 실제 운영 사건을 조사할 때는 같은 리포트 기준을 신규 데이터에 다시 적용하고, 이후 지표가 기대와 다르면 점수, 임계값(threshold), 모델 버전(model_version), 운영 입력 분포까지 확인해야 합니다.
데이터 품질 확인은 단순 통계 요약에서 끝나지 않습니다. 1-4 Lab에서 같은 출력값을 직접 확인한 뒤, 1-5에서는 그 근거를 모델 평가 전 QA 보고 표현으로 바꿉니다.