assets/060_kitchenpot/ 등 URDF 변형 객체 디렉토리 7개가 다른 세션 작업으로 삭제(mtime 2026-09-02 04:33) → rand_create_sapien_urdf_obj(modelid=randint(0,2))가 존재하지 않는 인덱스를 참조해 씬 생성 단계에서 전 에피소드 fail 처리(ValueError: modelid 1 is out of range 207~255회/task).X-WAM/third_party/RoboTwin/assets를 flex-pi가 심링크로 공유 — tau-0-wm의 RoboTwin 평가에도 동일하게 영향.assets_own 복사본(공식 HF, objects.zip 3.74 GB + embodiments.zip 0.22 GB) 분리 → 9k/10k 4 units, 10960 13 units 재실행 대기.clean-50 ckpt 선택 평가(9k / 10k / 10960 × 8 task × 25 ep, tmp/aggregate_clean50_ckpt.py 집계)에서 lift_pot success rate가 9k/10k에서는 4% / 0%인데, 10960 job의 부분결과에서는 100%로 나타났다. 같은 task·같은 시드 분포에서 ckpt 3개(9k/10k/10960)가 이 정도로 갈리는 것은 학습 진행에 따른 정책 차이로 설명하기엔 비현실적인 크기 — 정책이 아니라 환경 쪽 원인을 의심하고 추적했다.
로그 대조 + 파일시스템 mtime 추적으로 원인을 좁혔다.
조치 4가지:
| task | 9k (clean/random) | 10k (clean/random) |
|---|---|---|
| click_bell | 100 / 72 | 100 / 80 |
| adjust_bottle | 100 / 44 | 100 / 44 |
| place_shoe | 96 / 56 | 96 / 56 |
| put_object_cabinet | 84 / 20 | 88 / 20 |
| scan_object | 88 / 48 | 92 / 32 |
| stack_bowls_two | 92 / 96 | 100 / 88 |
공유·가변 에셋 디렉토리에 심링크로 의존하는 것은 재현성 리스크다 — 다른 프로젝트/세션이 같은 트리를 수정하면 실행 시점에 따라 같은 ckpt·같은 task가 전혀 다른 success rate로 나온다. 프로젝트별 불변 복사본(assets_own)이 원칙이어야 하며, 이번 사고로 얻은 절차상 교훈은 평가 결과 판독 시 "정책 실패"와 "환경/에셋 실패"를 반드시 로그의 Traceback 종류(정책 관련 예외 vs out of range 같은 리소스 조회 예외)로 구분해야 한다는 것 — 이번엔 에러 문자열 집계로 뒤늦게 잡혔다.
영향 범위가 flex-pi에 국한되지 않는다는 점도 중요하다 — X-WAM 심링크 트리를 공유하는 tau-0-wm의 RoboTwin 평가도 같은 시각 이후 실행된 job이라면 동일하게 오염됐을 가능성이 있다.
X-WAM 쪽 원본 assets 트리는 아직 삭제된 URDF 변형이 복구되지 않은 상태 — flex-pi는 assets_own으로 격리했지만, X-WAM/tau-0-wm이 같은 트리를 계속 쓴다면 재발 위험이 남아 있다(사용자에게 재추출 권고만 전달, 직접 수정은 하지 않음).
9k/10k lift_pot·open_microwave 4 units를 assets_own 기준 RESUME_DIR로 재실행 → 재교정된 값으로 ckpt 선택 표 갱신. 10960은 남은 13 units 재개. 향후 aggregate_clean50_ckpt.py에 씬 생성 단계 예외(out of range) 자동 카운트를 추가해 "정책 실패"와 "에셋 실패"를 집계 시점에 구분하는 방안 검토.