3. 실습 데이터셋과 평가 흐름¶

3-1. 이 문서를 읽는 기준¶

이 문서는 실습 데이터의 전체 지도를 먼저 잡기 위한 overview입니다. Kaggle의 Human Vital Sign Dataset은 AI QA 개념 설명용 classification 예제로만 사용합니다. 생체신호 자체를 판단하는 자료가 아니라, 데이터 품질, 모델 평가, 서빙 입력, 운영 로그, 릴리스 판단을 서로 다른 근거 축으로 나누어 읽는 연습 자료입니다.

가장 먼저 기억할 기준은 같은 원본에서 출발해도 데이터의 역할은 같지 않다는 점입니다. test는 모델 평가 질문에 답하고, valid_degraded는 validation 조건 변화 질문에 답하며, operational_holdout은 운영 관측과 릴리스 판단 질문에 답합니다. 이 경계를 지켜야 뒤 장에서 모델 문제, 입력 품질 문제, 운영 배포 판단을 한 근거로 섞지 않습니다.

처음 구분할 질문	대표 데이터와 산출물	연결되는 장	판단 범위
평가를 시작해도 되는가	`evaluation_baseline`	1장	데이터 품질 기준 확인
선택한 모델은 어떤 기준인가	`train`, `valid_baseline`, `test`	2장	모델과 threshold 평가
운영 입력은 어떻게 들어오는가	`serving_requests_*`	3장	API 입력 계약 확인
현재 운영 변화는 무엇인가	`operational_current_events`, `drift_report`	4장, 5장	운영 관측과 릴리스 판단

이 표는 이후 장을 읽을 때 사용할 방향 표지입니다. 지금 단계에서 모든 파일명을 외울 필요는 없습니다. 중요한 것은 “이 수치가 모델 평가 근거인지, validation 비교 근거인지, 운영 current 근거인지”를 구분하는 것입니다.

3-2. 원본 데이터와 교육용 label¶

원본 데이터와 모델 산출물은 처음부터 분리해서 읽어야 합니다. 원본 파일은 Human Vital Sign Dataset.zip이고, 저장소에서는 human_vital_signs_dataset_2024.csv를 실습 schema에 맞게 정리합니다. 원본 target인 Risk Category는 교육용 label로 바꾸지만, score, threshold, prediction, metric은 원본 데이터에 있는 값이 아니라 이후 모델 평가와 운영 관측에서 생성되는 값입니다.

이 구분이 무너지면 원본 label, 모델 점수, 최종 예측을 같은 종류의 값처럼 오해하게 됩니다. label은 정답, feature는 모델 입력, score는 Positive class 가능성, threshold는 class 변환 기준, prediction은 최종 예측, metric은 품질 지표입니다. 문서와 보고서에서는 이 용어를 같은 의미로 반복 사용합니다.

항목	사용 방식
원본 데이터	Kaggle Human Vital Sign Dataset
원본 target	`Risk Category`
교육용 label	`High Risk`를 `high_risk`, `Low Risk`를 `low_risk`로 정리
Positive class	`high_risk`
Negative class	`low_risk`
모델 score	모델 학습 후 생성되는 `risk_score`
threshold	`score`를 class로 바꾸는 기준
prediction	`score >= threshold` 기준으로 생성되는 최종 예측

이 데이터셋은 심박수, 호흡수, 체온, 산소포화도, 혈압 같은 수치형 feature를 포함합니다. 그래서 결측치, 이상치, 라벨 분포, score와 prediction 변화까지 한 흐름으로 설명하기에 적합합니다. 다만 모든 설명은 classification 예제와 QA 판단 근거에 한정합니다.

3-3. Data Lineage 그래프¶

데이터 계보(data lineage)는 숫자와 판단이 어떤 원천 데이터에서 이어졌는지 보는 지도입니다. overview에서는 전체 파일 관계를 모두 보지 않고, 장별 판단 축만 봅니다. 상세 파일 관계는 configs/lineage/course_data_lineage.yaml에서 관리하고, 이 문서에는 처음 읽을 때 필요한 큰 흐름만 둡니다.

flowchart TB
  raw["Kaggle 원본"]
  std["교육용 표준 데이터"]
  quality["1장<br/>데이터 품질 기준"]
  model["2장<br/>모델 학습과 평가"]
  serving["3장<br/>서빙 입력 확인"]
  ops["4장<br/>운영 관측"]
  release["5장<br/>릴리스 판단"]

  raw --> std
  std --> quality
  std --> model
  std --> serving
  serving --> ops
  model --> release
  ops --> release

이 그래프의 핵심은 2장의 모델 평가와 4장의 운영 관측이 서로 다른 길에서 5장의 릴리스 판단으로 모인다는 점입니다. 모델 평가 결과는 “모델 기준이 무엇인가”를 말해 주고, 운영 관측 결과는 “현재 입력과 출력이 어떻게 움직였는가”를 말해 줍니다. 5장에서는 두 근거를 함께 보되, 하나를 다른 하나의 증거로 대체하지 않습니다.

3-4. 분할 비율과 파생 규칙¶

분할 비율은 모델 성능을 최대화하기 위한 최적 비율이 아니라 강의 증거를 분리하기 위한 계약입니다. evaluation_baseline은 1장의 데이터 품질 확인에 사용하고, train, valid_baseline, test는 2장의 모델 평가 흐름에서 서로 다른 역할을 합니다. operational_holdout은 모델 개발에서 제외하고 3장부터 5장의 운영 입력, 로그, 릴리스 판단을 만드는 데 사용합니다.

분할 또는 파생 데이터	비율 또는 출처	쓰는 장	핵심 역할
`evaluation_baseline`	10%	1장	모델 평가 시작 전 데이터 품질 기준 확인
`train`	55%	2장	기준선 모델 학습
`valid_baseline`	15%	2장	설정 후보, threshold 후보, FP/FN 비교
`test`	10%	2장	선택된 모델과 threshold의 최종 모델 평가
`operational_holdout`	10%	3장, 4장, 5장	API 요청, 운영 로그, release gate 재평가 생성
`valid_degraded`	`valid_baseline`에서 파생	2장	current 운영 입력 실패 양상을 validation 기준에서 재현

valid_degraded는 별도 원본 분할이 아니라 validation 기준에서 파생합니다. 목적은 운영에서 실제로 발생한 모든 일을 복제하는 것이 아니라, 같은 모델과 threshold를 고정했을 때 입력 품질 저하가 metric 변화와 함께 나타나는지 보는 것입니다. 따라서 이 overview에서는 valid_degraded를 “2장에서 조건 변화 영향을 비교하는 데이터”로만 기억하면 됩니다.

3-5. 기준 데이터의 층위¶

기준 데이터라는 표현은 장마다 다른 층위를 가집니다. 1장의 기준 데이터는 모델 평가를 시작할 수 있는지 확인하는 evaluation_baseline_data입니다. 2장의 기준 데이터는 같은 모델과 threshold로 비교할 model_valid_baseline과 최종 모델 평가에 쓰는 model_test_baseline입니다. 4장과 5장의 기준선은 운영 로그와 대시보드에서 현재 값과 비교할 operational_baseline입니다.

이 구분은 결론의 범위를 제한하기 위한 장치입니다. “기준 데이터가 평가 가능하다”는 1장 결론은 운영 입력도 정상이라는 뜻이 아닙니다. 2장에서는 validation 기준과 품질 저하 재현 데이터를 비교하고, 4장과 5장에서는 운영 기준선과 현재 운영 샘플을 비교해야 합니다.

기준 데이터	의미	보고서에 남길 수 있는 문장
`evaluation_baseline_data`	모델 평가를 시작해도 되는지 확인하는 데이터	기준 데이터는 필수 컬럼과 label 기준을 충족하므로 모델 평가를 시작할 수 있습니다
`model_valid_baseline`	설정 후보를 비교하는 validation 기준	validation 기준에서 설정 후보와 FP/FN, PR-AUC를 비교했습니다
`model_test_baseline`	선택된 모델과 threshold를 마지막으로 확인하는 test 기준	test 기준에서 최종 모델 metric을 확인했습니다
`operational_baseline`	현재 운영 입력 샘플과 비교할 평소 운영 분포	현재 운영 입력 샘플은 운영 기준선 대비 score와 prediction 분포가 함께 이동했습니다
`release_holdout_baseline`	최종 승인/보류 재평가를 위한 holdout 기준	회귀 테스트와 approval rule을 같은 기준으로 다시 적용합니다

QA 보고서에는 어떤 기준 데이터에서 무엇을 확인했는지가 들어가야 합니다. 그래야 모델 문제, 데이터 문제, API 계약 문제, 운영 입력 변화 후보를 단계별로 줄일 수 있습니다.

3-6. Lineage 관리 방식과 산출물 계약¶

overview 그래프는 학습 경로를 보여 주고, 상세 lineage manifest는 실제 파일 관계를 관리합니다. 기준 파일은 configs/lineage/course_data_lineage.yaml입니다. 이 manifest는 데이터와 산출물의 parent, 생성 위치, 쓰는 장, 가능한 주장과 금지할 주장을 기록합니다.

관리 항목	위치	역할
Overview 그래프	이 문서의 3-3	장별 큰 흐름 확인
상세 lineage manifest	`configs/lineage/course_data_lineage.yaml`	실제 파일 관계 관리
상세 snippet 생성	`scripts/build_lineage_docs.py`	manifest 기반 상세 그래프와 표 출력
manifest 검증 테스트	`packages/ai-quality/tests/unit/test_course_data_lineage.py`	생성 파일과 parent 관계 누락 방지

산출물도 장별 역할에 맞게 읽어야 합니다. 2장의 model_test_eval.json은 선택된 모델과 threshold가 test에서 어떤 metric을 냈는지 기록합니다. validation_degradation_comparison.json은 validation 기준과 품질 저하 validation 비교를 기록합니다. 4장과 5장의 drift_report.md, quality_issue_trace.md, release_approval.md, ai_qa_checklist.md는 test 결과가 아니라 운영 holdout에서 파생한 current 사건 증거를 묶습니다.

산출물	입력 데이터	보고서에서 가능한 표현	금지할 표현
`model_test_eval.json`	`vital_signs_train.csv`, `vital_signs_test.csv`	선택된 모델과 threshold의 test metric 확인	current batch 입력 변화 설명
`validation_degradation_comparison.json`	`vital_signs_valid_baseline.csv`, `vital_signs_valid_degraded.csv`	같은 모델과 threshold에서 데이터 조건 변화와 metric 변화 비교	운영 root cause 확정
`drift_report.md`	`serving_requests_valid.csv`, `serving_requests_current.csv`, 운영 로그	current batch 입력 구성과 score/prediction 분포 변화 확인	모델 자체 결함 단정
`quality_issue_trace.md`	`drift_report.md`, `operational_current_events.jsonl`	원인 후보, owner, audit reference 정리	후보 상태를 최종 원인으로 확정
`release_approval.md`	`release_regression_cases.csv`, current 운영 관측	approval rule 기준 승인 또는 조건부 보류 판단	live deployment 검증 완료로 과장
`ai_qa_checklist.md`	1장부터 5장까지의 주요 산출물	최종 QA sign-off와 재평가 조건 정리	체크리스트 완료를 근거 자체로 대체

최종 보고서는 산출물을 많이 첨부한 문서가 아니라 서로 다른 판단 근거를 섞지 않은 문서여야 합니다. 이 overview에서는 상세 manifest를 외우기보다, test metric과 운영 current batch 관측을 다른 근거 축으로 유지해야 한다는 점을 먼저 기억합니다.

3-7. 데이터셋 선택 이유¶

데이터셋 선택 기준은 품질 확인 흐름을 끝까지 보여줄 수 있는지입니다. 이 데이터셋은 생체신호 자체를 판단하기 위해서가 아니라 AI QA 개념을 설명하기 위해 사용합니다. 선택 기준은 값의 범위, class 분포, score와 prediction 변화까지 실습으로 연결되는지입니다.

생체신호 기반 위험 알림 시스템 예제는 실제 현장 판정을 대신하기 위한 자료가 아니라 classification 예제입니다. 따라서 문서와 보고서에서는 특정 대상의 상태를 판정하지 않습니다. 관심 대상은 high_risk, low_risk라는 class를 가진 AI 시스템에서 데이터 품질, 모델 출력, 운영 로그, 릴리스 판단을 어떻게 연결할지입니다.

이유	설명
수치형 feature 중심 데이터	Pandas 기반 결측치, 이상치, 통계 분석 실습에 적합
직관적인 범위 검증	산소포화도 0~100 범위처럼 값 검증 기준 설명에 적합
Classification 예제 구성 용이	`High Risk`와 `Low Risk`를 Positive/Negative class로 정리 가능
Threshold 실습에 적합	모델이 생성한 `risk_score`에 threshold를 적용해 prediction을 만드는 흐름 설명 가능
운영 관측과의 연결성	score 분포, prediction 분포, validation failure, current batch 변화로 확장 가능

실제 품질 검증에서는 데이터셋의 도메인보다 확인 기준이 더 중요합니다. 이 과정의 데이터 분할과 계보는 어떤 데이터셋에서도 반복해서 사용할 수 있는 품질 확인 질문을 연습하기 위한 장치입니다.