사용자 단위로 데이터를 분리하기, 실패를 설명할 단서 남기기
같은 사용자의 기록이 학습과 평가에 나뉘어 있으면 새 사용자에 대한 성능을 과대평가할 수 있다. 결과와 원인을 구분하는 기록를 중심으로 작은 예제와 확인 기준을 정리합니다.
같은 사용자의 기록이 학습과 평가에 나뉘어 있으면 새 사용자에 대한 성능을 과대평가할 수 있다.
실패했다는 사실만으로는 다음 행동을 정하기 어렵다. 어떤 입력으로 어디까지 진행했으며 무엇을 기대했는지가 함께 있어야 한다. 이번에는 성공 여부를 표시하는 데서 한 걸음 더 나아가, 다음 사람이 같은 조건을 확인할 수 있도록 관찰 항목을 정리한다.
결과와 원인을 구분하는 기록
서로 관련된 행을 하나의 그룹으로 묶고 그룹을 기준으로 분리한다. 평가 대상이 새 사용자인지 기존 사용자의 새 사건인지 먼저 정해야 한다.
이번에 확인할 질문: 결과만 전달받은 사람이 원래 입력과 기대 동작을 복원할 수 있는가?
작게 확인하는 예제
다음 예제는 핵심 조건을 드러내기 위한 출발점이다. 서비스의 전체 구현을 대신하지 않으므로 실제 입력 범위와 실패 처리 규칙을 함께 읽어야 한다.
from sklearn.model_selection import GroupShuffleSplit
splitter = GroupShuffleSplit(n_splits=1, test_size=0.2, random_state=42)
train_idx, test_idx = next(splitter.split(X, y, groups=user_ids))
assert set(user_ids[train_idx]).isdisjoint(set(user_ids[test_idx]))
학습과 평가의 사용자 식별자 교집합이 비어 있는지와 서비스의 실제 예측 상황이 이 분할과 맞는지 확인한다.
놓치기 쉬운 조건
그룹 분리가 모든 상황의 정답은 아니다. 실제 적용 대상과 다른 분할을 사용하면 필요 이상으로 어렵거나 쉬운 평가가 될 수 있다.
| 확인할 부분 | 살펴볼 내용 |
|---|---|
| 기준 동작 | 학습과 평가의 사용자 식별자 교집합이 비어 있는지와 서비스의 실제 예측 상황이 이 분할과 맞는지 확인한다. |
| 비교 조건 | 입력과 실행 순서를 고정하고 한 번에 한 조건만 바꾼다. |
| 적용 범위 | 예제가 생략한 의존성과 실제 서비스의 제약을 구분한다. |
다음 변경에 적용할 순서
- 기대 결과와 실제 결과를 서로 다른 칸에 적는다.
- 개인정보나 비밀값을 제외하고 재현에 필요한 조건만 남긴다.
- 관찰 사실과 원인에 대한 가설을 구분해 후속 확인을 정한다.
기록을 많이 남기는 것과 유용하게 남기는 것은 다르다. 원인을 좁히는 데 쓰이지 않는 항목은 줄이고, 누락 때문에 다시 묻게 되는 조건은 보완한다. 관찰할 수 있는 범위가 분명해지면 실패한 상황에서도 다음 실험을 작게 잡을 수 있다.
이 이야기가 도움이 되었나요?