로봇 모델 파일만 남기고 학습 데이터 폴더를 날짜로 복사하면 같은 결과를 다시 만들기 어렵습니다. 원본 episode, calibration, 라벨 수정, schema 변환, train·test split, normalization 통계와 학습 run을 불변 식별자로 연결해야 어느 데이터가 모델을 만들었고 문제가 생겼을 때 어디까지 되돌릴지 알 수 있습니다. 데이터 계보는 저장 위치 목록이 아니라 변환 관계와 증거를 추적하는 구조입니다.
아래에서는 용어의 차이를 실제 시스템 경계, 실패 조건과 검증 순서로 나눠 살펴봅니다.
데이터 버전은 폴더 날짜가 아니라 동일한 내용을 가리키는 불변 식별자다
dataset_final_v3_new 같은 이름은 파일이 바뀌어도 그대로 남고 사람마다 다른 내용을 가리킬 수 있습니다. manifest에 파일·episode digest, schema version, 생성 시각과 부모 버전을 기록해 동일 버전을 다시 계산할 수 있게 합니다.
MLflow Dataset Tracking 공식 문서는 dataset name뿐 아니라 digest, source, schema와 profile을 run에 연결하는 구조를 설명합니다. 로봇 데이터에서도 model run이 정확한 dataset identity를 참조해야 합니다.
원본 데이터는 수정하지 않고 정정 사항을 새 파생 버전으로 만든다
잘못된 label을 발견해 raw JSON을 직접 덮어쓰면 과거 모델이 보았던 상태를 잃습니다. 원본은 append-only 또는 immutable storage에 두고 correction table과 새 derived version에서 변경 이유를 남깁니다.
로봇 학습 데이터 품질 검사 결과도 버전에 연결합니다. 같은 dataset 이름이라도 검사 규칙과 threshold가 바뀌면 통과 결과가 달라질 수 있어 QA code version을 함께 저장합니다.
manifest는 episode·센서·action·권리·상태 정보를 한곳에 묶는다
각 episode의 source robot, task, session, operator, policy, start·end, sensor streams, action schema, calibration, outcome, license·consent와 checksum을 기록합니다. 파일 경로만으로는 삭제·이동과 schema 변경을 설명할 수 없습니다.
대용량 영상은 파일별 해시와 episode offset을 함께 둡니다. shard 하나가 여러 episode를 담으면 shard digest가 같아도 offset table 변경으로 데이터 의미가 달라지므로 메타데이터도 내용 주소화합니다.
| 계층 | 필수 식별자 | 함께 고정할 것 | 대표 위험 |
|---|---|---|---|
| episode | episode UUID·digest | task·outcome·operator | 중복·재라벨 혼동 |
| 파일 | URI·checksum | offset·codec·size | shard 교체 |
| 스키마 | schema version | unit·frame·dtype | 같은 열 다른 의미 |
| 권리 | source·license·consent | 사용 범위·만료 | 사용 불가 데이터 혼입 |
현장 로봇 데이터에는 software뿐 아니라 tool·calibration·firmware 계보가 필요하다
사진처럼 제조 장비의 로봇 팔은 tool 교환, fixture 이동, camera calibration, firmware와 controller tuning에 따라 같은 action의 결과가 달라집니다. session manifest에 이 하드웨어 구성을 snapshot으로 연결합니다.
장비 serial 전체를 공개할 필요는 없지만 내부 식별자와 유효 기간은 있어야 합니다. calibration이 적용된 시작·종료 시점을 모르면 변환 오류가 데이터 drift인지 모델 오류인지 구분할 수 없습니다.
변환 파이프라인은 입력·코드·파라미터·출력을 DAG로 기록한다
raw→sync→calibrate→filter→label→shard→normalize 각 단계가 어떤 입력 digest와 code commit, container, parameter로 어떤 output digest를 만들었는지 남깁니다. 결과 파일만 저장하면 중간 오류를 재현할 수 없습니다.
DVC의 데이터 버전·파이프라인 안내는 큰 파일을 remote에 두고 Git에는 참조와 pipeline 정의를 연결하는 방식을 보여 줍니다. 도구 이름보다 dependency와 output이 재실행 가능한지가 핵심입니다.
스키마 migration은 변환 성공과 의미 보존을 따로 확인한다
열 이름을 바꾸거나 v2에서 v3 shard로 옮겨 파일이 열려도 action unit, timestamp와 episode boundary가 틀릴 수 있습니다. migration code와 source·target schema, lossless·lossy 여부를 기록합니다.
LeRobot Dataset v3 구조 변환처럼 표본 episode를 전후 재생하고 state·action·video·task를 비교합니다. 되돌릴 수 없는 필드 삭제나 quantization은 원본 링크와 변환 손실을 명시합니다.
train·validation·test split도 독립된 계보 객체로 버전 관리한다
dataset 내용이 같아도 split이 바뀌면 평가 결과가 달라집니다. episode ID 목록, split rule, seed와 environment·object·operator grouping을 hash로 고정합니다.
새 episode가 추가됐다고 기존 test를 자동 재분할하면 이전 모델과 비교할 기준이 사라집니다. benchmark split은 고정하고 새 조건은 별도 challenge split으로 추가합니다.
정규화 통계와 vocabulary는 dataset version에 종속된다
mean·std, quantile, action scale, tokenizer vocabulary와 task mapping은 학습 데이터에서 계산된 파생 자산입니다. dataset이 바뀌면 같은 이름의 stats 파일을 재사용하지 않고 input digest와 계산 코드에 연결합니다.
로봇 간 행동 공간 정규화의 adapter와 frame 정의도 lineage에 포함합니다. 모델 checkpoint만 가지고는 어느 embodiment 변환으로 action을 해석해야 하는지 알 수 없습니다.
학습 run은 데이터 버전과 코드·환경·모델 설정을 함께 고정한다
run manifest에는 dataset digest, split digest, mixture version, normalization, code commit, dependency image, seed, hyperparameter와 output model digest를 기록합니다. latest 경로나 mutable branch만 참조하지 않습니다.
Hugging Face의 데이터셋 업로드 공식 문서는 dataset repository가 revision history를 가져 여러 버전을 저장할 수 있음을 설명합니다. production run에는 branch 이름보다 commit SHA를 고정하는 편이 재현에 유리합니다.
롤백은 모델만 내리는 것이 아니라 호환되는 데이터·adapter·schema 세트를 복원한다
새 모델이 문제를 일으켜 이전 checkpoint를 배포해도 current normalization과 action adapter가 바뀌었다면 같은 행동을 내지 않을 수 있습니다. model release manifest가 호환 dataset·stats·adapter·runtime 버전을 한 묶음으로 가리켜야 합니다.
rollback drill에서는 실제 artifact를 새 환경에 가져와 checksum을 확인하고 짧은 replay와 shadow evaluation을 수행합니다. 백업이 존재한다는 사실보다 복구 시간이 운영 한계 안인지가 중요합니다.
계보 검증은 임의 모델에서 원본 episode까지 양방향으로 추적한다
모델 release를 하나 골라 run, mixture, split, derived dataset, transform과 raw episode로 내려가고 각 digest가 실제 파일과 맞는지 확인합니다. 반대로 권리 철회나 센서 오류가 있는 raw episode에서 영향을 받은 model과 배포를 찾아냅니다.
삭제 요청이나 calibration 오류의 영향 범위를 찾지 못하면 lineage가 문서에만 존재하는 것입니다. 정기 표본 감사와 missing edge 검사를 자동화하고 실패 시 새 학습을 중단합니다.
운영 합격 기준은 재현·영향 분석·복구가 실제로 가능한지다
같은 run을 bitwise 복제하기 어렵더라도 동일 dataset·split·code로 허용 범위의 지표를 재현할 수 있어야 합니다. raw episode 변경이 어느 모델에 영향을 주는지 정해진 시간 안에 찾고 승인된 release로 롤백할 수 있어야 합니다.
로봇 데이터 팩토리의 수집부터 배포까지 owner와 승인 기록을 연결합니다. 계보는 저장 도구 하나가 아니라 팀이 변경을 승인하고 문제를 되돌리는 운영 계약입니다.
| 시험 | 시작점 | 도착점 | 합격 기준 |
|---|---|---|---|
| 재현 | model run | dataset·code·params | 동일 입력 복구 |
| 역추적 | model release | raw episode | 모든 edge 존재 |
| 영향 분석 | 문제 episode | affected models | 누락 없이 검색 |
| 롤백 | current release | previous compatible set | 시간·검증 기준 충족 |
로봇 데이터 버전과 계보 관리에서 자주 묻는 질문
데이터 폴더를 날짜별로 복사하면 버전 관리가 되나요?
간단한 백업은 되지만 내용 동일성, 부모 버전과 변환 관계를 보장하지 못합니다. manifest와 digest, schema·code·split 연결이 필요합니다.
원본 label이 틀리면 바로 수정하면 안 되나요?
원본을 덮어쓰지 말고 correction과 새 derived version을 만듭니다. 그래야 과거 모델이 본 상태와 변경 이유를 추적할 수 있습니다.
모델 checkpoint에 dataset 이름만 기록하면 충분한가요?
mutable 이름은 부족합니다. dataset·split·mixture·normalization digest와 code commit, adapter, runtime 호환 버전을 함께 고정해야 합니다.
Hugging Face나 DVC를 쓰면 계보가 자동 완성되나요?
도구는 revision과 artifact 추적을 돕지만 로봇별 calibration, action 의미, 변환 reason과 승인 관계는 팀이 명세해야 합니다.
계보가 제대로 작동하는지 어떻게 시험하나요?
임의 모델에서 raw episode까지 역추적하고 문제 episode에서 영향을 받은 모델을 찾아본 뒤 실제 compatible set으로 rollback drill을 수행합니다.
데이터 계보는 접근 통제, 개인정보·권리 관리와 안전 검증을 대신하지 않습니다. 민감 정보와 사용 권한은 별도 정책으로 관리하면서 각 버전에 적용 범위를 연결해야 합니다.