Keh0t0/scene-mem-benchmark rev bd811db3data/ 전체가 22 chunk로 재업로드. 858 → 879 scenariovideo_total_frames 불일치 623/623 (100%), n_tasks 변경 300/623fine_subtasks.json이 전부 사라졌고(0/879), 로컬 백업 858개는 구 영상에 index-align된 것이라 재사용 불가 → --recall-walk fine 경로가 신 데이터에서 동작하지 않음tests[].task 필드 신설 — restore 3,181 / find_target 2,878 / find_distractor 1,621 = 7,680 test로컬 미러 ~/Dataset/scene-mem-benchmark(858 scenario)의 취득 시점을 확인하던 중, HF 원본이 2026-07-22에 갱신된 것을 발견했다. 로컬은 원래 2단계에 걸쳐 받은 상태였다.
| 시점 | 내용 |
|---|---|
| 2026-05-13 11:30 | HF snapshot 최초 다운로드 (eval_spec / env / eval 코드) |
| 2026-05-13 15:12 | _pi05_meta/ 추가 |
| 2026-05-14 04:57~08:05 | combo 디렉토리 대량 다운로드, eval/eval_runner.py |
| 2026-05-16 13:52 | videos/ 추가 |
| 2026-05-20 05:35 | fine_subtasks_manifest.json — 자체 생성 annotation push |
| 2026-07-01 04:43~04:50 | trajectory.hdf5 재다운로드 |
리모트 최신 커밋은 bd811db3 "Update README for 879-scenario release"(07-22 07:10)이고, 그 앞에 Upload data chunk 1/22~22/22가 연속으로 붙어 있었다. 즉 data/ 전체가 재업로드된 릴리즈다.
HfApi.list_repo_tree로 리모트 파일 목록을 받아 로컬과 대조. 토큰은 ~/envs/api_keys.txt에서 self-read하고 출력하지 않았다. env는 conda_envs/envs/memer(huggingface_hub 0.36.2).
| 항목 | 로컬 (구) | 리모트 (신) |
|---|---|---|
| scenario | 858 | 879 |
| 파일 | 6,235 | 8,803 |
| 용량 | 22 GB | 24.88 GB |
| ID 신규 / 제거 / 공통 | 신규 256 제거 235 공통 623 | |
fine_subtasks.json | 858 | 0 |
fine_subtasks.json 858개가 리모트에서 통째로 소실된 것까지 확인됐다.증분 동기화(7.23 GB)가 아니라 새 디렉토리에 clean 전체 다운로드를 선택했다. 구버전을 그대로 남겨 과거 결과의 재현 경로를 유지하기 위함.
revision을 명시적으로 pin해서, 다운로드 도중 리모트가 바뀌어도 스냅샷 일관성이 깨지지 않게 했다.
리모트 파일별 size와 로컬 실제 size를 1:1 비교. 이어서 ID가 공통인 623개의 subtasks.json / eval_spec.json을 byte 비교하고, 차이가 난 항목을 파싱해 무엇이 바뀐 것인지 특정했다.
| 항목 | 값 | 비고 |
|---|---|---|
| scenario | 879 | 구 858 |
| test | 7,680 | 구버전엔 task 구분 없음 |
task=restore | 3,181 | 채점 restore_success |
task=find_target | 2,878 | 채점 memory_success |
task=find_distractor | 1,621 | 채점 memory_success |
| 평균 프레임 / scenario | 8,549 | ~7분 연속 영상 |
| license | cc-by-4.0 | 구 apache-2.0 |
| 대조 항목 | 결과 |
|---|---|
| ID 공통 scenario | 623 |
그중 video_total_frames 변경 | 623 / 623 (100%) |
그중 n_tasks 변경 | 300 / 623 |
subtasks.json byte 동일 | 0 / 623 |
eval_spec.json byte 동일 | 0 / 623 |
| 대상 | 구 | 신 |
|---|---|---|
eval_spec.json tests[].task | 필드 없음 | 신설 (3종) |
eval/tasks.py | 없음 | 신규 |
eval/eval_runner.py | 5,188 B | 6,753 B |
eval/success_fn.py | 2,294 B | 3,334 B |
당초엔 리모트가 annotation을 날렸으니 백업본을 새 디렉토리에 복원하면 된다고 봤다. 하지만 공통 623개가 전부 다른 영상으로 재생성된 것이 확인되면서 이 판단은 틀린 것이 됐다. fine_subtasks.json은 subtasks.json의 per_test에 index-align된 구조라, 영상이 다르면 정렬 자체가 무의미하다.
--recall-walk fine이 신 릴리즈에서 동작하지 않는다. scene_mem_api/dataset.py:177-181은 videos/fine_subtasks.json을 읽고 없으면 fall back 없이 raise한다. 신 디렉토리엔 이 파일이 0개다. 260624~260625의 핵심 결과(M3v2 0.564 / ours 0.462 / M2 0.308)가 전부 fine walk 기반이므로, fine annotation 재생성이 이행의 선행 블로커다.tmp/diverse12.txt 같은 시나리오 리스트도 ID 기준이라, 살아남은 ID조차 다른 에피소드를 가리킨다. 신 릴리즈 기준 수치는 전면 재측정이 필요하다.find_distractor(1,621건)는 영상 중 pick-and-place 대상이 아니었던 물체의 위치를 회상하게 하는 것으로, 기존 개선 항목이던 "상식차단 질의"(상식으로는 못 맞히게 하기)와 목적이 정확히 겹친다. 우리가 직접 설계하려던 것을 벤치가 먼저 제공한 셈.구 파이프라인(memer/tmp/hf_push_fine_subtasks.py 계열)을 신 subtasks.json에 맞춰 재실행. 이게 되기 전까지 --recall-walk fine 경로는 신 데이터에서 못 쓴다.
DATA_ROOT 전환scene_mem_api/config.py:4는 아직 구 경로를 가리킨다. fine annotation 재생성 전에 바꾸면 fine walk가 즉시 깨지므로 의도적으로 두었다. 재생성 완료 후 전환.
과거 결과 재현이 필요 없어지는 시점에 삭제. 그 전까지 보존. 백업 tarball(318K)은 어느 쪽이든 유지.
task 필드 3종 분기 대응현 러너는 task 필드를 모르고, restore는 채점 기준 자체가 restore_success로 다르다. 신 eval/tasks.py + eval/success_fn.py를 먼저 읽고 러너 대응 범위를 정할 것.
신 879개 기준으로 다양성 셋을 다시 뽑아야 한다 (ID 재사용 불가).