로봇 영상의 프레임을 무작위로 나누면 같은 에피소드의 앞뒤 장면, 같은 방의 배경, 같은 물체와 작업자 습관이 학습과 테스트에 동시에 들어갈 수 있습니다. 성공률은 높아져도 새 장소와 새 물체에 대한 일반화는 확인되지 않습니다. 누수를 막으려면 프레임이 아니라 배포 질문에 맞는 그룹 단위로 split을 설계해야 합니다.
아래에서는 용어의 차이를 실제 시스템 경계, 실패 조건과 검증 순서로 나눠 살펴봅니다.
로봇 평가 누수는 정답 라벨이 새는 경우보다 같은 수집 맥락이 양쪽에 남는 경우가 더 흔하다
한 trajectory의 연속 프레임은 배경·물체 자세·로봇 상태가 거의 같습니다. 이를 행 단위로 무작위 분할하면 테스트 영상이 학습 영상의 몇 프레임 뒤 장면이 되어 모델이 작업 원리보다 장면 지문을 기억해도 높은 점수를 얻습니다.
로봇 VLA 평가에서 성공률을 해석하려면 먼저 무엇이 unseen인지 밝혀야 합니다. 새 프레임, 새 에피소드, 새 물체, 새 장소, 새 작업자는 서로 다른 일반화 질문이며 하나의 random split로 동시에 답할 수 없습니다.
split의 최소 단위는 frame이 아니라 독립성이 유지되는 episode 또는 session이다
동일한 teleoperation session에는 같은 카메라 노출, calibration, 작업자 동선과 물체 배치가 반복됩니다. episode만 나눠도 session 지문이 남을 수 있으므로 수집 방식에 따라 session·day·deployment를 상위 그룹으로 묶습니다.
DROID 공식 프로젝트가 여러 장소와 수집자를 포함하는 이유도 실제 로봇 데이터에서 scene diversity가 별도 축이기 때문입니다. 다양성을 보유했다는 사실과 그 축을 train·test 사이에 격리했다는 사실은 구분해야 합니다.
배포 질문을 먼저 쓰면 어떤 그룹을 hold-out해야 하는지가 정해진다
같은 공장에서 새 물체를 집는 정책을 배포한다면 object instance를 격리하고 장소는 공유할 수 있습니다. 새 고객 현장으로 옮기는 정책이라면 site와 camera setup을 함께 hold-out해야 하며, 새 작업자 지시를 다루려면 operator와 언어 표현까지 분리해야 합니다.
한 숫자로 모든 일반화를 요약하지 말고 in-distribution, unseen object, unseen scene, unseen operator를 별도 열로 보고합니다. 그래야 특정 축에서만 좋아진 모델을 범용 로봇 정책으로 오해하지 않습니다.
| 평가 질문 | 격리할 그룹 | 공유 가능 조건 | 대표 누수 |
|---|---|---|---|
| 새 에피소드 | episode·session | 같은 site·object | 인접 프레임 |
| 새 물체 | object instance·asset | 같은 task·site | 동일 개체 다른 자세 |
| 새 장소 | site·camera setup | 같은 task 정의 | 배경·calibration |
| 새 작업자 | operator·instruction source | 같은 robot | 조종 습관·문구 |
표준 시험 시설의 장비와 절차도 모델이 외울 수 있는 환경 특징이다
사진처럼 조명, 바닥, 표적, 안전 울타리와 장비 위치가 일정한 시험장은 반복 가능한 측정에 유리합니다. 그러나 동일 장면에서 수집한 train과 test는 현장 전이를 검증하지 않으므로 표준 시험과 일반화 시험의 역할을 나눠야 합니다.
고정 시험장은 regression test로 유지하고, 별도 challenge set에는 새 배치·새 물체·새 작업자를 넣습니다. 두 점수를 함께 보면 모델 업데이트가 기본 기능을 지키면서 외부 조건에도 견디는지 구분할 수 있습니다.
.jpg){kind=link}
같은 물체의 다른 영상은 파일명이 달라도 test 독립 표본이 아니다
컵 하나를 여러 각도에서 촬영한 파일을 서로 다른 object로 세면 instance memorization이 일반화처럼 보입니다. object ID는 클래스 이름이 아니라 실제 개체·제조 lot·3D asset까지 추적하고 파생 영상은 부모 ID를 상속합니다.
로봇 6D 물체 자세 추정처럼 자세 변화가 핵심인 문제에서는 같은 instance의 다른 pose를 평가할지, 완전히 새 instance를 평가할지 따로 설계합니다. 전자는 pose robustness이고 후자는 instance generalization입니다.
작업자 누수는 손 모양보다 조종 습관·실패 회피·언어 표현을 통해 들어온다
특정 작업자는 항상 같은 방향으로 접근하거나 실패 직전에 속도를 줄이고 비슷한 문구를 사용합니다. train과 test에 같은 작업자가 있으면 정책은 과제보다 개인별 궤적 패턴과 표현을 이용할 수 있습니다.
DROID 원 논문처럼 수집자와 장소가 다양한 데이터에서는 collector metadata를 보존해야 operator hold-out을 만들 수 있습니다. 개인정보가 필요한 것이 아니라 안정적인 익명 그룹 ID와 수집 세션 연결이 필요합니다.
증강본·리사이즈본·재인코딩본은 해시가 달라져도 같은 원본의 형제 표본이다
파일 SHA-256만 비교하면 crop, brightness, JPEG 재인코딩으로 만들어진 유사본을 놓칩니다. 원본 lineage ID, frame timestamp, perceptual hash, embedding nearest-neighbor를 함께 써서 split 경계를 넘는 near-duplicate를 찾습니다.
로봇 데이터 계보 관리에서 transform DAG를 보존하면 모든 파생본을 부모 episode와 같은 split에 묶을 수 있습니다. split 이후에 증강을 생성하는 방식이 가장 단순한 누수 방지 규칙입니다.
normalization과 vocabulary도 train split만으로 계산하지 않으면 test 정보가 스며든다
전체 데이터의 평균·표준편차, action quantile, tokenizer vocabulary를 먼저 계산한 뒤 나누면 test 분포가 학습 전처리에 반영됩니다. 작은 차이처럼 보여도 희귀 action 범위와 언어 표현을 미리 알려 줄 수 있습니다.
split ID를 먼저 고정하고 train만으로 통계를 산출하며 validation과 test에는 그대로 적용합니다. 통계 파일에는 입력 episode 목록과 digest를 기록해 dataset 버전이 바뀌어도 test가 계산에 섞이지 않았는지 재현합니다.
validation 반복 조회는 test를 직접 학습하지 않아도 선택 편향을 만든다
같은 test 결과를 보며 augmentation, checkpoint, prompt를 반복 선택하면 연구자가 test에 과적합합니다. validation은 모델 선택에 쓰고 final test는 결정이 끝난 뒤 제한된 횟수만 열어야 합니다.
RT-1 공식 프로젝트와 원 논문처럼 새 작업·새 환경 성능을 나눠 보고할 때도 각 세트의 용도를 고정해야 합니다. 공개 benchmark를 매일 개발 지표로 쓰면 사실상 validation이 되므로 비공개 challenge set이 필요합니다.
split 감사는 교집합 0이라는 선언을 metadata와 영상 유사도로 이중 검증한다
episode, session, site, object, operator ID별 train·validation·test 교집합을 계산하고 허용한 공유 축만 예외로 기록합니다. 이어서 대표 frame의 perceptual hash와 embedding 이웃을 찾아 ID 오기입과 복사본을 검출합니다.
검출 결과는 단순 삭제보다 원인별로 처리합니다. 동일 원본 파생본은 부모 split로 이동하고, ID가 없는 오래된 데이터는 격리하거나 별도 legacy 평가로 낮춰 confidence를 명시합니다.
평가표에는 평균 성공률과 함께 그룹별 표본 수와 신뢰구간을 공개한다
unseen site가 한 곳뿐이거나 object가 몇 개뿐이면 평균 성공률의 변동이 큽니다. trial 수, 독립 group 수, seed, 실패 유형과 interval을 함께 제시해야 작은 차이를 모델 우열로 과장하지 않습니다.
로봇 학습 데이터 품질 검사와 연결해 누락 metadata 비율도 보고합니다. site ID가 없는 표본을 무조건 새 장소로 세면 오히려 가장 불확실한 데이터를 가장 강한 일반화 근거로 쓰게 됩니다.
운영 가능한 split은 manifest로 고정되고 새 데이터가 들어와도 과거 test가 자동 재분배되지 않는다
Open X-Embodiment 공식 프로젝트처럼 여러 로봇·기관 데이터를 다룰수록 manifest에는 group key, membership, rule, seed, dataset digest와 생성 코드를 저장합니다. 새 episode가 추가돼도 frozen test는 유지하고 새 조건은 challenge set으로 확장합니다.
합격 기준은 그룹 교집합 0, near-duplicate 조사 완료, train-only 통계, test 조회 제한과 배포 질문별 결과 분리입니다. 이 기준을 통과해야 높은 성공률을 새 조건 일반화의 증거로 해석할 수 있습니다.
| 감사 항목 | 검사 방법 | 합격 기준 | 기록물 |
|---|---|---|---|
| 그룹 격리 | ID 교집합 | 허용 외 0 | split manifest |
| 유사본 | lineage·pHash·embedding | 검토 완료 | near-duplicate report |
| 전처리 | 통계 입력 목록 | train only | stats digest |
| 운영 | test 접근·변경 이력 | 제한·동결 | evaluation log |
로봇 평가 데이터 누수에서 자주 묻는 질문
로봇 데이터는 몇 대 몇 비율로 나누는 것이 좋나요?
비율보다 독립 group 수가 중요합니다. 먼저 배포 질문에 맞춰 episode·site·object·operator를 격리한 뒤 각 평가 조건에 충분한 독립 그룹이 남도록 비율을 정합니다.
같은 장소에서 다른 날 수집하면 새 test 환경인가요?
조명과 배치가 달라져도 배경·카메라·작업대 지문이 남을 수 있습니다. 날짜 일반화를 보는 세트로는 쓸 수 있지만 unseen site 근거로 부르면 안 됩니다.
파일 해시가 모두 다르면 중복 누수가 없는 것인가요?
아닙니다. crop·재인코딩·인접 프레임은 해시가 달라집니다. 부모 lineage, timestamp, perceptual hash와 embedding 유사도까지 확인해야 합니다.
test 성능을 보며 하이퍼파라미터를 바꾸면 왜 문제인가요?
선택 과정에 test 정보가 반영되어 test가 validation 역할을 하기 때문입니다. 모델 선택은 validation으로 끝내고 final test 접근 횟수를 제한합니다.
하나의 test set으로 모든 일반화를 평가할 수 있나요?
어렵습니다. unseen episode·object·site·operator는 격리 축이 다르므로 조건별 세트를 분리하고 각 표본 수와 실패 유형을 함께 보고하는 편이 정확합니다.
데이터 누수 방지는 평가의 신뢰성을 높이지만 실제 로봇 안전을 보장하지 않습니다. 새 환경 배포 전에는 별도의 위험 분석, 저속 시험, 안전 제한과 사람 감독 절차가 필요합니다.