DATASET_sample_v1 × VLM eval 하네스 호환성

← 리포트 목록

TL;DR — 신규 샘플 배포본(36행·컨텍스트 5편)을 하네스 관점에서 판정. find는 어댑터 수준으로 기존 5전략 × v3 계약이 그대로 돌고, restore는 답 계약만 from/to 쌍으로 확장하면 같은 메모리를 재사용하며, resume만 신규 러너(행별 프레임컷)가 필요하다. 전수 측정 예상 비용 ~$5–10.

36행

find 18 · restore 11 · resume 7

0건

vocab_v1 커버리지 결손

2곳

find가 깨지는 지점 (로더·라벨)

$5–10

전수 측정 예상 (5전략×2모델)

1 배경 — 무엇이 바뀌었나

질의가 편 내부 eval_spec.json에서 루트 eval/<family>/queries.jsonl로 나왔고(행이 context 필드로 편을 참조, 편당 평균 6행), 가족이 find 하나에서 find / restore / resume 셋으로 늘었다. 컨텍스트도 type1(자율 개입, find·restore용)과 type2(사용자 발화 순차 + 중간 컷, resume용)로 갈린다.

DATASET_sample_v1/ ├── contexts/type1/{val_144__2, val_406__0, val_733__0} # find·restore 공유 │ meta.json · subtasks.json · traj.h5 · videos/ · states/final.npz ├── contexts/type2/{val_101__1100, val_733__1100} # resume 전용 │ states/cut_00..09.npz + final.npz + index.json # MuJoCo 전체 덤프 └── eval/{find,restore,resume}/queries.jsonl + stats.json # 행 = 채점 단위

내부 구조는 v0.7과 동일 실측 — traj_0/obs_scene (steps_emitted·tracked_objects·event_results), tracked_obj_pixels, 3캠 mp4, type1 subtasks의 slots 스키마까지 전부 같다. val_144__2가 구·신 양쪽에 있어 행 단위 diff로 확인 (q00 bowl multi는 답 xyz까지 동일).

2 호환성 매트릭스

가족	행	판정	필요 작업	재사용
find	18	거의 그대로	로더 어댑터 + `query_labels` 1곳	5전략·v3 계약·채점기·누출가드 전부
restore	11	계약 확장	답 스키마 from/to 쌍 + 채점 확장	메모리 전략 전부 (find와 ingest 캐시 공유)
resume	7	신규 러너	프레임컷 메모리 + commands 주입 + task/remaining 계약	전략 골격·클라이언트·체크포인트

find가 깨지는 곳 2가지 (전부 파악됨)

#	변경	영향
①	질의 위치 이동 + `final_state.npz` → `states/final.npz`	`load_episode`가 질의를 외부 주입받도록 어댑터
②	top-level `scoring` 삭제 → per-answer로 이동 + rename (lifted→`pick`, reached_only→`navigate_only`)	`facts.query_labels()`의 `query["scoring"]`이 KeyError → answers에서 유도

경미한 기존 특성: 질의 문구 "soap bottle"/"spray bottle" ↔ vocab display soapdispenser/atomizer 불일치 (v0.7부터 존재). 채점은 location 중심이라 영향 제한적이나, distractor 카테고리 채점에서 확인 필요.

3 restore — "이중 기억" 질의

"X를 집어서 처음/직전 자리에 놓아라" — VLM은 (a) 지금 어디 있는지(from)와 (b) 원래 어디였는지(to)를 둘 다 기억해야 한다. from은 find의 답과 동일하고 행마다 shares_answer_with로 명시된다 (공유율 1.0 → find와 점수 합산 금지).

축	분포	의미
`origin`	first 9 · previous 2	최초 자리 vs 직전 자리 — 기억의 시간 구조를 직접 찌르는 대조쌍
`steps`	single 8 · multi 3 (n≤3)	multi는 절을 "+"로 연결, 여러 물체 복원
`d_xy`	중앙 4.7 m · 최대 14.4 m	from→to 변위 (자격 하한 1.0 m)

답 계약 확장안: selections: [{category, from:{room,surface}, to:{room,surface}}]. 채점은 from쌍·to쌍 각각 loc_set. room_name_map의 flat 접근(answers[].room)을 from/to 중첩 대응으로 고치면 3중 조인은 그대로 쓸 수 있다 (room 정수 공간이 동일).

4 resume — 구조적으로 새로운 평가

type2 컨텍스트: 사용자가 반복 유닛 task를 순차로 시키고 중간에 세운다. 질의는 항상 "You were in the middle of something. Continue what you were doing." — 모델은 무엇을 하던 중이었고 몇 번 남았는지를 영상 기억에서 복원해야 한다.

resume:val_101__1100:cut_08 frames [0, 7529] 들은 발화(f1까지, cut-consistent 실측 확인): f1 "Press the button on the dryer three times." f848 "Navigate to every room in the house." f3169 "Pick up three of the eggs from the dresser and place them into the basket." GT: T3 put_in_container n=3 m=2 → r=1 (두 개 넣었고 하나 남음) decoys: T1(완료) T2(완료) — 이미 끝난 task를 다시 하면 오답

하네스 변경점	지금	resume 요구
메모리 구간	편 전체	f1까지만 (행마다 다름: 651~7529)
질의 관측	마지막 프레임	frame f1
ingest 캐시 키	episode	(context, f1)
추가 입력	—	`commands[]` (로봇이 실제 들은 발화 — 누출 아님)
답 계약	{category, room, surface}	{task, remaining} 신규
textlog 빌더	type1 slots 기반	type2 unit 기반 별도 (A2 상한 역할 유지)

r=0 2행이 음성 대조군 — 이미 다 끝난 상태에서 "계속하라"고 한다. 문장만 따라가는 모델(기억 없이 발화 반복)을 잡아내는 축으로, v0.7의 blind 상식 바닥선과 같은 역할을 resume에서 한다.

5 Takeaway & Next

기존 하네스의 핵심 자산(5전략 · 누출가드 · 채점기 · 에피소드 체크포인트)은 전부 유효하다. find부터 어댑터로 살리고, restore 계약 확장 → resume 러너 순으로 가는 게 증분이 가장 작다.

restore(first vs previous)와 resume(진행 상태 r)은 v0.7이 못 재던 축이다. v0.7 실측에서 textlog가 "사건은 잘, 본 것만은 못" 하던 패턴이 이 두 가족에서 어떻게 갈리는지가 다음 관전 포인트 — textlog는 restore의 to(사건 로그에 있음)에 강하고, resume의 유닛 카운트도 거의 공짜로 얻는 반면, 순수 시각 전략은 둘 다 프레임에서 세어내야 한다.