데이터의 네 가지 역할¶

기존 운영 모델의 high_risk 예측 비율이 늘었지만, 이 신호만으로 데이터가 달라졌는지 모델에 문제가 생겼는지 판단할 수는 없습니다. 운영 요청에는 정답이 없고, 예측 비율은 들어온 요청의 구성에 따라서도 달라질 수 있기 때문입니다.

따라서 Candidate A와 Candidate B를 비교하기 전에 원본 관측값, 특성 표, 데이터 분할이 같은 평가 범위를 가리키는지 확인해야 합니다. 이 장에서 데이터 관련 원인 후보와 모델 평가 범위를 정리하되, 데이터 구조가 정해 둔 규칙과 맞는다는 사실을 모델 품질이나 실제 서비스 적합성으로 확대하지 않습니다.

1장에서 먼저 고정할 것

어떤 원본·특성·분할이 후보 비교의 입력인지
각 데이터 역할에 정답이 있는지와 언제 쓰는지
데이터 검증이 보여 주는 구조적 사실과 아직 모르는 모델·운영 결론

이 장에서 나누는 확인

2교시에는 학습, 검증, 최종 평가, 운영 자료의 역할을 고정합니다. 3교시에는 결측, 범위, 라벨 구성의 관측값을 만듭니다.

이 장의 핵심 질문¶

예측 비율 변화에 대응할 모델을 고르려면 두 후보의 비교 수치가 같은 대상 집합과 같은 규칙에서 나왔는지 먼저 확인해야 합니다. 이 장에서는 다음 질문에 답할 수 있도록 데이터 범위를 확인합니다.

Candidate A와 Candidate B를 비교한 수치가 같은 대상 집합과 같은 특성 규칙, 같은 데이터 분할에서 나온 것인가? 그렇지 않다면 회의에서 그 수치를 어디까지 설명할 수 있는가?

원본 관측값의 결측, 개별 기록 단위 특성으로 바꾸는 과정, 데이터 검증 결과, 고정된 데이터 분할은 서로 다른 사실입니다. 각 자료에서 확인한 사실과 아직 모르는 것을 구분해야 다음 장의 품질 지표와 이후 API, 대시보드 결과를 같은 조건에서 해석할 수 있습니다.

교육용 데이터 안내

이 장의 위험도 분류와 교육용 정답은 데이터 품질과 모델 평가 범위를 익히기 위한 예시입니다. PhysioNet의 기록(record)은 실제 의사결정이나 조언에 사용하지 않습니다.

개념이 낯설다면

원본 관측값, 특성(feature), 정답(label), 최종 평가 데이터(test set)의 역할은 AI 품질과 이상 신호와 분류 지표와 곡선에서 먼저 확인합니다. 이 개념을 구분해야 서로 다른 시점이나 분할에서 나온 숫자를 섞지 않고 2장의 평가 수치를 해석할 수 있습니다.

데이터 검증(data validation)이 성공해도 모델이 좋은 것은 아닙니다. 데이터 검증은 원본 데이터와 가공한 특성 표의 구조가 정해 둔 규칙과 맞는지 확인하는 과정입니다. Candidate A와 Candidate B의 승인 여부는 다음 장에서 최종 평가 결과와 사전에 정한 보호 기준을 비교해 판단합니다.

같은 자료를 네 역할로 나누는 이유¶

데이터의 역할을 나누는 목적은 모델이 배운 답을 다시 맞히는 시험과 새로운 사례에 대한 시험을 구분하는 것입니다. 기존 기능 시험에서는 명세의 기대 결과를 알고 구현을 고쳐도 문제가 없지만, 학습 모델은 정답을 본 데이터에 맞춰 파라미터를 바꿉니다. 같은 자료에서 학습과 평가를 모두 하면 모델이 이미 본 관계가 성적에 반영됩니다. 따라서 train 2,900건에서 얻은 학습 성적을 최종 성능으로 쓰지 않습니다.

valid는 학습 파라미터를 직접 맞추지 않아도 개발 의사결정에 참여합니다. 개발자가 600건의 결과를 보며 모델이나 임계값을 고르면 그 결과가 다음 선택에 영향을 줍니다. 여러 번 비교한 뒤 가장 좋은 결과를 골랐다면 그 자료에 우연히 잘 맞는 후보를 선택했을 가능성도 있습니다. valid를 개발용 비교 자료라고 부르는 이유이며, 정답을 본 적 없는 최종 평가와 구분합니다.

test 400건은 선택을 끝내고 조건을 고정한 뒤 평가하는 자료입니다. 결과를 읽고 다시 임계값을 바꾸면 테스트 결과가 개발 과정에 들어와 독립적인 최종 평가 역할을 잃습니다. 이 수업에서는 원시 테스트 파일을 열지 않고 이미 고정된 평가 요약을 읽습니다. operational 100건은 정답을 제외한 운영 관찰 자료이므로, 예측 분포와 입력 조건은 확인해도 새 정밀도나 재현율은 계산하지 않습니다.

역할별 건수의 합과 레코드의 중복 여부는 서로 다른 검사입니다. 2,900 + 600 + 400 + 100 = 4,000이 맞아도 같은 레코드가 두 역할에 들어가고 다른 레코드가 빠졌을 수 있습니다. 한 레코드의 시간별 측정 행을 나눠 학습과 평가에 넣으면 동일한 기록의 정보가 양쪽에 섞입니다. 분할 이력의 roles_are_disjoint_and_exhaustive와 레코드별 역할을 확인해 교집합이 없고 전체 범위를 포함하는지 봅니다.

평가 자료의 정보가 학습이나 선택에 섞이는 현상을 데이터 누수(data leakage)라고 합니다. 전처리도 예외가 아니므로, 결측을 채울 값이나 스케일을 전체 4,000건에서 먼저 학습하지 않습니다. Scikit-learn의 누수 방지 지침은 학습 자료에서 전처리를 맞추고 나머지 자료에는 같은 변환을 적용하도록 설명합니다. 이 과정에서는 데이터 품질 근거에 데이터 역할, revision, 분할 seed 43과 파일 지문을 함께 남깁니다.

확인할 자료¶

모델의 우열은 이 자료만으로 결정할 수 없으며, 이 자료는 평가 숫자가 적용되는 데이터 범위를 확인하는 근거입니다.

확인할 자료	경로 또는 위치	확인한 사실	아직 모르는 것
원본 데이터 규칙	`configs/contracts/physionet-record.yaml`	4,000개 기록, 48시간 관찰 구간, `target`과 제외된 결과 열의 범위	모델이 실제 서비스 판단에 적합한지
개별 기록 단위 특성 표	로컬 준비 뒤 생성되는 `data/features.csv`	4,000행, 모델 입력에 사용하는 특성 133개, 정답 554건	결측값이 곧바로 오류인지
데이터 분할 이력	`configs/data/split-v2.yaml`, `docs/evidence/data-v2/split-revision.json`	`train`, `valid`, `test`, `operational`의 역할과 최종 평가 범위	로컬 데이터 검증이 최종 평가 데이터를 사용했는지
Great Expectations(GE) 검증 결과	`artifacts/data-quality/great-expectations/validation-summary.json`	원본 적재와 가공 데이터 준비 과정이 구조 규칙을 통과했는지	특정 후보의 배포 가능 여부나 품질 지표가 달라진 원인

Candidate A와 Candidate B의 비교는 현재 고정한 분할 안에서만 해석해야 하며, 예전 분할의 숫자를 섞어서는 안 됩니다. 현재 데이터 분할은 예전 분할을 그대로 쓰지 않습니다. 과거에 operational이었던 400건은 새 최종 평가 데이터로 옮기고, 예전 테스트 500건은 train으로 옮긴 별도 개정본입니다.

flowchart LR
  accTitle: 원본 관측에서 V2 데이터 역할까지의 흐름
  accDescr: 원본 관측 4,000건을 4,000행 133개 특성으로 바꾼 뒤 V2 분할에서 train 2,900건, valid 600건, test 400건, 정답이 없는 operational 100건으로 나눕니다.
  A["원본 관측 4,000건"] --> B["특성 4,000행"]
  B --> C["V2 분할"]
  C --> D["train 2,900"]
  C --> E["valid 600"]
  C --> F["test 400"]
  C --> G["operational 100"]

흐름도의 텍스트 대체: 원본 관측 4,000건을 개별 기록 단위의 4,000행·133개 특성으로 바꾼 뒤, V2 분할에서 train 2,900건, valid 600건, test 400건, 정답이 없는 operational 100건으로 나눕니다.

분할을 읽을 때는 다음을 확인합니다.

train과 valid는 개발·선택용이고, test는 선택을 끝낸 뒤 한 번 쓰는 최종 평가용입니다.
operational에는 정답이 없으므로 운영 입력·API·분포를 보는 데만 사용합니다.
역할별 행 수와 특성 표의 전체 행 수가 맞아야 비교 범위를 설명할 수 있습니다.

데이터 역할	행 수	정답 포함 여부	용도
`train`	2,900	포함	모델을 학습할 때 사용합니다.
`valid`	600	포함	학습 과정에서 설정을 점검할 때 사용합니다.
`test`	400	포함, 최종 평가용	모델과 임계값을 정한 뒤 한 번만 사용합니다.
`operational`	100	미포함	API와 운영 상황을 확인할 때 사용합니다.

역할별 행 수의 합이 4,000인 것은 특성 표의 행 수와 맞습니다. 특성 표는 전체 대상 집합을 나타내고, 분할 정보는 각 기록이 모델 수명 주기에서 맡을 역할을 하나로 정합니다.

이 장에서 정리할 내용¶

모델 승인 판단은 이 장에서 확인한 데이터 범위를 벗어나면 근거를 잃습니다. 보고서에는 다음을 남깁니다.

이 장의 역할: 모델 후보를 비교할 데이터 범위를 정리합니다.
확인한 사실: 원본 데이터 규칙, 4,000/133/554 구성, 역할별 건수, 원본·가공 데이터의 검증 결과
주의할 점: 원본 데이터·특성·데이터 분할을 혼동하면 2장의 품질 지표를 잘못 해석할 수 있습니다.
미확인: 결측 상태가 모델 지표·운영 신호에 미치는 영향, 실제 API 입력의 동일 조건 여부
다음 장 질문: Candidate A와 Candidate B가 이 고정된 범위에서 어떤 보호 기준을 통과했는가

보고서 문장 예시¶

보고서 문장은 데이터 구조 검증의 범위와 모델 승인에 아직 사용할 수 없는 근거를 분리해야 합니다. 아래 문장은 이 장에서 확인한 데이터 범위를 기록할 때 사용할 수 있습니다.

Candidate A와 Candidate B의 비교는 PhysioNet Set A에서 4,000개 기록으로 만든 특성 표와 현재 고정한 데이터 분할을 기준으로 한다. 원본 데이터와 가공 데이터의 GE 검증은 이 로컬 환경의 데이터 구조가 정해 둔 규칙과 맞는지만 보여 준다. 이 결과만으로 모델 성능의 원인이나 배포 가능 여부를 판단하지 않는다.

데이터 범위를 기록에 남겨야 모델 승인 판단이 어떤 조건에 적용되는지 추적할 수 있습니다. 이 문장은 배포 판단 기록의 데이터 근거에 남기고, 다음 장에서는 이 범위를 유지한 채 두 후보의 공식 평가 결과를 확인합니다.

함께 볼 자료와 실습¶

데이터 역할과 분할: 원본 데이터와 가공 데이터, 데이터 분할을 어떻게 구분해 해석하는지 설명합니다.
데이터 오류와 검증: tta-aiqa에서 노트북과 검증 명령을 실행하고 보고서 한 줄을 작성합니다.
실습 자료: tta-aiqa/labs/chapters/ch01/README.md, labs/chapters/ch01/01_physionet_data_quality_eda.ipynb