Data Split / Leakage 이해

난이도: 중급

태그: foundations,evaluation,data_split,leakage

좋은 성능 숫자보다 먼저 확인할 것은 "그 숫자가 공정한 평가에서 나왔는가"이다. split이 잘못되면 모델이 똑똑한 것이 아니라 답을 미리 본 것일 수 있다.

면접과 논문에서 자주 나오는 함정이 데이터 누수다. train/validation/test를 왜 나누는지 이해하지 못하면, 실험 결과가 좋아 보여도 신뢰할 수 없는 평가가 된다.

실제로 많은 초보 실험은 모델 구조보다 평가 설계에서 먼저 무너진다. 숫자가 높은데도 재현이 안 되거나 배포에서 성능이 급락하는 경우는 대개 split이나 leakage 문제와 연결된다.

1. 왜 split을 나누는가

핵심은 test가 "완전히 처음 보는 데이터"여야 한다는 점이다.

2. Leakage란 무엇인가

Leakage는 학습 과정에 들어가면 안 되는 정보가 모델이나 실험 설계 안으로 새어 들어가는 상황이다.

유형예시
데이터 중복같은 사용자의 문서가 train과 test에 동시에 존재
전처리 누수전체 데이터 평균으로 정규화한 뒤 split
모델 선택 누수test 성능을 보고 하이퍼파라미터를 반복 조정

3. 왜 위험한가

Leakage가 있으면 숫자는 높게 나오지만 실제 배포 환경에서는 성능이 무너진다. 논문에서는 재현이 안 되고, 면접에서는 실험 신뢰성을 바로 의심받는다.

중요한 점은 leakage가 항상 노골적이지 않다는 것이다. 같은 사용자의 샘플이 train과 test에 섞여 있거나, 전체 데이터 통계로 정규화한 뒤 split하는 식의 사소해 보이는 실수도 충분히 평가를 왜곡한다.

4. 실무에서 보는 포인트

5. 논문/면접 답변 프레임

"우리는 train/val/test를 분리했고, validation으로 모델 선택을 했으며, test는 최종 보고용으로만 사용했다. 또한 preprocessing statistic은 train split에서만 계산했다." 이 정도까지 말할 수 있으면 기본은 갖춘 것이다.

여기에 한 단계 더 나아가 "중복 샘플 여부를 확인했고, 사용자 단위로 split했으며, 시간 축이 있는 데이터는 시계열 순서를 보존했다"까지 설명할 수 있으면 훨씬 신뢰도 높은 실험 설계로 보인다.

6. 체크리스트