Index
2026-08-13 — Analysis

샘플 데이터셋 검증 — val_136__0 / val_290__0

scene_bench | 계획 대비 일치 · 차이 · 릴리즈 차단 버그 4건 · 추가 필요 항목
← Finding → subgoal 파이프라인 계획

TL;DR

4
차단급 버그
22%
swapped 이벤트
15%
질의시점 정답 노출
8.5분
에피소드 길이
11-dim
mobile Franka

1 데이터 개요

sample/<house>__<seed>/ meta.json schema 0.1 — house/seed/split/fps/n_steps/cameras/scene_fingerprint/n_event(_ok)/n_subtask subtasks.json 이벤트 5개, 각각 task_description + slots + obj + swapped + outcome + tags + segments[] eval_spec.json schema 0.2 — queries[] : kind/name/template/query/n_candidates/ambiguous/answers[]/candidates[] traj.h5 traj_0/{actions, obs, env_states, obs_scene, rewards, success, ...} final_state.npz videos/ wrist_camera.mp4 · exo_camera_1.mp4 · exo_camera_2.mp4
항목val_136__0val_290__0
길이12,697 frame / 25 fps = 508 s (8.5분)11,891 / 25 = 476 s (7.9분)
이벤트5 (ok 4)4 (ok 4)
세그먼트23 (nav 6 · carry 6 · manip 11)16 (nav 4 · carry 4 · manip 8)
세그먼트 길이평균 22.1 s (6.6 ~ 72.9)평균 29.7 s (9.5 ~ 106.0)
추적 물체17—
질의6 (target 3 / distractor 3)7 (target 3 / distractor 4)
영상640×480 · 25 fps · 프레임 수 == h5 스텝 수 (정합 확인)
용량에피소드당 mp4 3개 ≈ 44 MB / 32 MB

h5에 들어 있는 GT (풍부하다)

obs/extra/tracked_obj_pose (T, 17, 7) 물체별 프레임 pose ← 위치 GT obs/extra/tracked_obj_pixels (T, 17, 3) 카메라 3대별 픽셀 수 ← 가시성 GT ★ obs/extra/robot_base_pose (T, 7) 베이스 궤적 ← 경로비/SPL 계산 가능 obs/extra/policy_phase (T,) 프레임별 phase 라벨 ← 세그먼트 경계 공짜 obs/extra/successes/terminals (T,) obs/extra/sensor_param_*/ intrinsic_cv, extrinsic_cv, cam2world_gl obs_scene (JSON 21 KB) task_description, plan, event_results, policy_phases, tracked_objects, visibility, videos, frozen_config(13.6 KB) actions/joint_pos {arm:7, base:[x,y,yaw], gripper:1} ← 11-dim mobile Franka policy_dt_ms = 40.0 → 25 Hz 제어
tracked_obj_pixels가 결정적이다. units="pixels", 카메라 3대별 픽셀 수 → "이 물체가 이 프레임에 보이는가"를 프레임 단위로 안다. 계획서의 게이트 "남은 일감이 현재 시야에 보이나"를 추측 없이 코드로 검사할 수 있다. 아래 버그 ④도 이걸로 잡았다.

2 계획과 맞는 것

계획실제
단일 에피소드 (심기→개입→질의)8.5분 / 7.9분 단일 롤아웃✓ L3 범위(6~8분) 일치
저장은 mp4 (PNG 금지)mp4 3캠, 프레임 수 == 스텝 수✓
인스턴스 수준 IDbowl_847a24bf…_1_0_7✓
세그먼트별 instructionNavigate to the {} / Pick up the {} / Place the {} in or on the {}△ 아래 §3-5
메모리 질의 (Finding A1)"Navigate to the bowl I moved earlier"✓
동종 미끼find_distractor 질의 + 같은 카테고리 복수 인스턴스(candle ×3, butterknife ×2)✓
base task 길이 13~20 s 추정세그먼트 평균 22.1 / 29.7 s△ 조금 김
GT는 생성 시점에 확정event_results, tracked_obj_pose, frozen_config✓

3 계획과 다른 것

#계획실제 데이터영향
3-1심기는 로봇이 보기만 (W-obs)로봇이 pick&place를 직접 수행. 질의도 "the bowl I moved earlier"W-act 변형. 지난 결정과 반대. 둘 중 하나로 정해야
3-2open/close로 은폐 (a)task가 pick_and_place 하나뿐. articulated 상호작용 없음은폐 (a) 불가 → A3·C1·B계열 전부 불가
3-3subgoal 시퀀스 평가eval이 navigate-only. 정답 = 위치 1개(xyz/room/surface)Target Accuracy 중 pick 항목을 못 잰다
3-42 캠 (π0.5-DROID 규약)3 캠 wrist + exo1 + exo2, 640×480VLA 어댑터에서 캠 선택 규칙 필요
3-5place는 pick 포함 한 덩어리Pick + PickAndPlace(tail)로 분할. "Place the {} in or on the {}"는 MolmoSpaces 정책 프롬프트에 없는 문구이 문구로 VLA를 돌리면 OOD
3-6제어 15.15 Hz 가정policy_dt_ms=40 → 25 Hz길이 등급 재계산 (아래)
3-7embodiment 미확정 (R2 리스크)mobile Franka: {arm:7, base:[x,y,yaw], gripper:1} = 11-dimR2 해소. RB-Y1 아님. π0.5-DROID(8-dim)와는 base 3-dim 차이
3-8ID 규약 <room>/<Type>_<kk>stand_6bc09b7e…_2_0_7 (asset_hash_idx_?_room)데이터 규약을 따르자. 내 규약 폐기
길이 등급 재계산 (25 Hz, 실측 세그먼트 기준)
세그먼트(=base task) 평균 22~30 s ← 이전 가정 13~20 s 보다 김 L1 ~2분 → base task 4~5 (이전 6~9) L2 ~5분 → base task 10~13 (이전 11~18) L3 ~8분 → base task 16~22 (이전 20~26) 실측: val_136 = 23 세그먼트 / 8.5분, val_290 = 16 / 7.9분 → 표와 일치

! 릴리즈 차단 버그 4건

증거 등급 — 무엇이 사실이고 무엇이 해석인가
#등급근거
①확정 — 데이터 내부 모순slots.pickup_name이 planned_obj와 9/9 일치, obj와는 7/9. 이름의 출처가 planned_obj임이 확정되고, 정답은 obj를 쓴다. 외부 메타데이터 없이 판정됨
②확정 — 완전 문자열 일치tissuepaper_1f28299e6e99a63de7abb400051cb351_1_0_7가 target·distractor에 동일 문자열로 등장
③확정 — 물리적 불가능같은 obj·같은 xyz인데 room/surface가 다름. ambiguous 3건 중 2건
④사실 확정 / 심각도 조건부거리·픽셀은 실측. 다만 "질의가 최종 상태에서 시작된다"는 가정이다 — 근거는 note의 "컨텍스트 종료 시점" 표현과 리셋 pose 필드의 부재. 하네스가 따로 리셋하면 비issue → 버그라기보다 스펙 공백

반증 검토한 것: ①에 대해 "objaverse 이름 노이즈 때문에 tissuepaper 에셋의 표시 이름이 실제로 'bowl'일 수 있다"를 검토했다. ObjectMeta.short_descriptions가 빈 배열을 반환해(메타 DB 미연결) 그 경로로는 확인 불가였으나, 이름 출처 역추적(9/9 vs 7/9)으로 반증되었다.
정정: butter knife가 물체 2개를 가리키는 것은 버그가 아니다 — 실제로 다른 butterknife 인스턴스 2개(xyz 상이, 같은 countertop)이고 ambiguous=true로 정직하게 선언돼 있다. 정당한 ambiguity다.

확정 ① swapped — 라벨과 실물이 다른데 outcome=ok
// val_136 event 0 {"planned_obj": "bowl_847a24bf…_1_0_7", "obj": "tissuepaper_1f28299e…_1_0_7", "swapped": true, "ok": true, "tags": ["shift"]} // 그런데 subtasks.json 은 여전히 task_description : "Pick up the bowl from the dining table … place it in or on the tv stand" slots.pickup_name: "bowl" // val_290 event 1 planned_obj = "fork_a17d780c…_1_0_6" → obj = "peppershaker_d3a7b2ab…_1_0_6"
val_136 같은 instruction 다른 물체
Figure 1 — val_136__0 event 0. 동일한 instruction "Pick up the bowl"이 두 번 나오고, 집힌 물체가 다르다. 왼쪽(frame 347)은 흰 그릇, 오른쪽(frame 1634)은 구겨진 티슈. 데이터는 두 번째 것만 obj로 기록한다.
프레임을 따라가 보면 실제로 벌어진 일 — 단순 오라벨이 아니다 event 0 은 세그먼트가 8개다 (nav→pick→carry→place 를 두 번 반복). tags=["shift"] Pick#1 [225, 526] "Pick up the bowl" → 진짜 bowl 을 잡았다 (wrist 75,729 px @ f347) 진짜 bowl 이동 구간 f441~ 시작 z=0.837 → 종료 z=0.050 = 바닥에 떨어뜨림 총 이동거리 1.138 m Pick#2 [1486,1787] "Pick up the bowl" → tissuepaper 를 잡았다 (wrist 83,239 px @ f1634) tissuepaper 이동 구간 f1636~2442 → tv stand 위에 안착. 이동거리 0.553 m event_results 기록 : obj = tissuepaper, ok = true eval_spec 정답 : tissuepaper 의 tv stand 위치 → 즉 진짜 bowl 도 "내가 옮긴" 물체다. 그것도 1.1 m 나 움직여 바닥에 떨어져 있다. "Navigate to the bowl I moved earlier" 의 정답으로는 진짜 bowl 이 오히려 더 타당하다. 그런데 채점기는 tissuepaper 만 정답으로 인정한다.
val_290 fork 지시에 peppershaker
Figure 2 — val_290__0 event 1, frame 2909. instruction은 "Pick up the fork"인데 그리퍼에 잡힌 것은 후추통이다 (wrist 20,458 px). 씬에는 진짜 fork 인스턴스가 2개 따로 있고, 그중 하나는 find_distractor "fork"의 정답으로 쓰인다.
이름의 출처 역추적 — 9개 이벤트 전수 name planned_obj 카테고리 obj 카테고리 v136 ev0 'bowl' bowl MATCH tissuepaper ✗ v136 ev1 'candle' candle MATCH candle MATCH v136 ev2 'bottle' bottle MATCH bottle MATCH v136 ev3 'pen' pen MATCH pen MATCH v136 ev4 'candle' candle MATCH candle MATCH v290 ev0 'cell phone' cellulartel MATCH cellulartel MATCH v290 ev1 'fork' fork MATCH peppershaker ✗ v290 ev2 'bowl' bowl MATCH bowl MATCH v290 ev3 'cell phone' cellulartel MATCH cellulartel MATCH ───────────────────────────────────────────────────────────────── planned_obj 와 일치 9/9 obj 와 일치 7/9 → 이름은 planned_obj(의도한 물체)에서 나온다. 예외 없음. → 그런데 eval_spec 의 정답은 obj(실제 옮긴 물체)를 쓴다. → 질문의 이름과 정답의 물체가 서로 다른 객체에서 나온다.

정책이 의도한 물체 대신 옆 물체를 집었다. 그런데 설명·슬롯은 안 고쳐졌고 outcome은 ok다. 9개 이벤트 중 2건(22%).

파급이 크다 — eval_spec의 "Navigate to the bowl I moved earlier"의 정답이 tissuepaper의 위치가 된다. 그리고 씬에는 진짜 bowl_847a24bf…가 한 번도 안 움직인 채 존재한다. 진짜 bowl을 찾은 모델이 오답 처리된다.

고침 — (1순위) swapped=true 이벤트는 질의 생성에서 제외. (2순위) obj의 실제 카테고리로 task_description·slots를 재생성. 그리고 outcome에 swapped를 성공으로 치지 않는 규칙 추가.
치명 ② 같은 물체가 target이자 distractor
// val_136 — 같은 obj, 다른 이름, 서로 반대 역할 find_target "Navigate to the bowl I moved earlier" → tissuepaper_1f28299e… find_distractor "Navigate to the tissue box" → tissuepaper_1f28299e… ← 동일 객체! // val_290 — 같은 이름 "fork", 다른 물체 find_target "Navigate to the fork I moved earlier" → peppershaker_d3a7b2ab… find_distractor "Navigate to the fork" → fork_a17d780c…_2_0_6

val_136은 한 물체가 "내가 옮긴 것"이자 "안 옮긴 미끼"다 — 정의상 모순. val_290은 같은 단어 "fork"가 두 질의에서 다른 물체를 가리켜, 모델이 무엇을 답해도 하나는 틀린다. 둘 다 버그 ①의 파생이다.

고침 — 질의 생성 후 충돌 검사를 건다: (a) 한 obj가 target과 distractor에 동시 등장 금지, (b) 한 name이 서로 다른 obj를 가리키는 두 질의 동시 존재 금지.
중대 ③ ambiguous 질의의 답이 중복이자 물리적으로 모순
// val_136 "Navigate to any candle I moved earlier" n_candidates=2, ambiguous=true answers = [ {obj: candle_77f795c2…_3_0_7, xyz: [4.969, 0.47, 0.549], room: 6, surface: countertop_…}, {obj: candle_77f795c2…_3_0_7, xyz: [4.969, 0.47, 0.549], room: 5, surface: crapper_…} ] // 같은 obj · 같은 xyz 인데 room 과 surface 가 다르다 → 물리적으로 불가능

ambiguity가 아니라 중복이다. 같은 촛대를 event 1과 event 4에서 두 번 옮겼는데, 생성기가 이벤트당 answer 1개를 찍었다. xyz는 note대로 종료 시점 실측이라 둘 다 최종값인데, room/surface는 이벤트 시점 값이라 섞였다. 출처가 다른 필드를 한 레코드에 넣은 것.

note에 이미 미해결로 적혀 있지만, 실제 원인은 "이름 중복"이 아니라 물체 중복이다. val_290의 cell phone도 동일 패턴(event 0, event 3).

고침 — answer를 obj 단위로 dedupe하고 최종 위치 1개만 남긴다(room/surface도 최종값으로 재계산). 그러면 이 두 건은 ambiguous=false가 된다. 진짜 ambiguity(서로 다른 인스턴스 2개가 같은 이름)는 별도로 남긴다 — butter knife가 그 경우다.
사실 확정 / 심각도 조건부 ④ 질의 시점에 정답이 화면에 보인다
(1) 정답 물체의 가시 픽셀 (wrist / exo1 / exo2) 질의 프레임 정확값 직전 5초 최댓값 val_136 "candle" [ 486, 198, 190 ] = 874 [ 8,924, 199, 192 ] val_290 "cell phone" [ ... ] = 610 [ 30,897, 524, 522 ] 나머지 11개 질의 [0, 0, 0] [0, 0, 0] → 정상 (2) final_state.npz 로 로봇 최종 위치 ↔ 정답 물체 거리 ← 이쪽이 결정적 val_136 candle 0.75 m ⚠ bowl 9.50 · bottle 3.18 · butter knife 8.72 val_290 cell phone 0.66 m ⚠ bowl 9.19 · fork 4.59 · vase 12.21
수치 정정 — 처음 보고한 8,924 / 30,897은 질의 직전 5초의 최댓값이지 질의 프레임 값이 아니다. 질의 프레임 실측은 874 px / 610 px로 훨씬 작다(그래도 0이 아니라 보이긴 한다). 결론을 지탱하는 것은 픽셀이 아니라 거리 0.75 m / 0.66 m다 — Navigate-to 성공 기준 1.5 m를 이미 밑돈다.
질의 시점 최종 프레임
Figure 3 — 질의 시점(최종 프레임). val_136은 로봇이 변기 앞에 서 있고 물탱크 위 초록 촛대가 그리퍼 바로 옆이다. val_290은 서랍장 위 휴대폰 앞이다. 두 경우 모두 "이동"이 이미 완료된 상태다.
이 그림이 버그 ③도 증명한다. val_136의 촛대는 변기 물탱크(crapper) 위에 있다. 그런데 eval_spec의 답 2개 중 하나는 room:6 / surface:countertop이다 — 육안으로 낡은 값임이 확인된다.
가시성 타임라인
Figure 4 — find_target 정답 물체의 가시 픽셀 시계열. 각 물체는 자기 이벤트 동안만 보이다가 사라지는데, 마지막 이벤트의 물체만 QUERY 선까지 살아 있다(점 = 질의 프레임 실측값). 범례에 "bowl" → tissuepaper, "fork" → peppershaker 불일치가 그대로 드러난다.

13개 질의 중 2건(15%)이 메모리 없이 풀린다. 원인이 구조적이다 — 두 건 모두 마지막 이벤트의 대상이다. 로봇이 방금 그 물체를 놓고 그 앞에 서 있으니 당연히 보인다.

MolmoSpaces Navigate-to 성공 기준 = "타깃이 1.5 m 이내에서 보일 것" → 0.75 m / 0.66 m 는 이미 성공 조건을 만족한다. → 이 두 질의는 "메모리 없이 풀린다"가 아니라 "아무 행동도 안 해도 정답"이다.

계획서 §7 규칙 1("현재 관측에 없는 정보")의 정확한 위반이다. blind 베이스라인이 이 두 건을 무행동으로 100% 맞히면서 전체 blind 점수를 부풀리고, 게이트 G1(blind ≤ chance)을 통과 못 하게 만든다.

단, 여기엔 가정이 하나 들어간다 — "질의가 이 최종 상태에서 시작된다". 가정의 근거 2가지 · eval_spec.note : "정답 xyz 는 컨텍스트 종료 시점 실측 위치" · eval_spec / obs_scene 어디에도 질의용 시작·리셋 pose 필드가 없다 (검색 확인) → 데이터만으로는 로봇을 최종 상태 외의 어디에도 놓을 방법이 없다 분기 하네스가 최종 상태에서 이어감 → 심각. 무행동으로 정답 (1.5 m 기준 이미 충족) 하네스가 로봇을 따로 리셋 → 비issue. 단 그 리셋 규격이 데이터에 없으므로 명시 필요 → 그래서 이 항목은 "버그"보다 스펙 공백으로 부르는 편이 정확하다.
고침 2안 — (권장) 마지막 이벤트 뒤에 "이석(離席) 구간"을 붙인다: 로봇이 다른 방으로 이동해 정답이 시야에서 사라진 뒤 질의. 자연스럽고 모든 질의에 일괄 적용된다.
(차선) 마지막 이벤트 대상은 질의에서 제외 — 간단하지만 이벤트 하나를 버린다.
어느 쪽이든 생성 후 tracked_obj_pixels로 자동 검사를 건다(재료가 이미 있다).
부수 항목 (차단은 아니나 규칙이 필요) — val_136 event 3은 outcome=failed_no_place(펜을 집었으나 놓지 못함, ok=false)이고 세그먼트가 3개뿐이다. 현재 pen 질의는 없지만, 실패 이벤트를 질의 대상에서 어떻게 다룰지 명시적 규칙이 필요하다. 권고: 실패 이벤트는 find_target에서 제외하되, "집었다가 놓지 못한 물체"는 오히려 좋은 B4 장치/절차 재개 소재이므로 별도 태그로 보존.

5 추가되어야 할 것

#항목왜난이도
A이석 구간 (질의 전 로봇을 다른 방으로)버그 ④ 구조적 해결. 모든 질의에 일괄 적용낮음 (nav 세그먼트 1개 추가)
Bopen/close 이벤트은폐 (a) "닫힌 곳" + A3·C1·B계열의 전제. 지금은 은폐 (b) "다른 방"만 가능중 (MolmoSpaces에 OpeningTask 존재)
C반사실 짝현재 0건. prior로 찍는 모델을 걸러내는 유일한 장치낮음 (심기 이벤트 1개 제거/치환)
Dsubgoal GT (gt.plan / required / forbidden)계획의 Target Accuracy·Plan F1 채점에 필요. 지금은 위치만 있다낮음 (segments에서 유도 가능)
E질의 실행 구간지금은 질의가 QA다. 실제 수행을 재려면 질의 후 롤아웃이 필요중
Ftotal_seen_s 상한 규칙bowl 136 s / 508 s = 27%, candle 283 s = 56%. 너무 오래 보이면 쉬운 문제 — 난이도 라벨 또는 상한 필요낮음 (이미 측정됨)
Gblind / oracle 메타세 조건 대조를 위한 필드. 텍스트 로그(oracle)는 event_results에서 바로 생성 가능낮음
HPickAndPlace(tail) 문구 정합"Place the {} in or on the {}"는 MolmoSpaces 정책 프롬프트에 없다. VLA를 돌릴 때 OOD낮음 (렌더러에서 pick_and_place 통짜로 복원)
I한국어 질의현재 영어. 실사용에 가깝게 하려면 — 다만 스키마는 영어 유지낮음 (선택)

6 뜻밖의 수확 — 계획이 개선되는 지점

발견계획에 미치는 영향
tracked_obj_pixels (T,17,3) 픽셀 수 = 프레임별 가시성 GT게이트 "남은 일감이 현재 시야에 보이나"를 자동 검사할 수 있다. 버그 ④를 이걸로 잡았다. 난이도 라벨링(total_seen_s)·프레임 샘플링에도 그대로 쓴다
policy_phase (T,) + segments[].framessubgoal 경계 샘플링이 공짜. 계획서 §5의 "경계 샘플링으로 API 12배 절감"이 추가 작업 없이 된다
robot_base_pose (T,7)경로 길이 / Search Path Ratio / Room Revisit 계산 가능. scene_navi ego-command 생성도 이 궤적으로
event_results + subtasks.segments텍스트 로그 oracle을 바로 생성할 수 있다. 계획의 3조건 중 하나가 공짜
frozen_config (13.6 KB)씬 재현 가능 → 반사실 짝 생성 시 동일 씬 보장
embodiment = mobile Franka 11-dim, 25 HzR2 리스크 해소. 다만 π0.5-DROID(8-dim)와 base 3-dim 차이 → 어댑터 필요 여부는 별도 확인
정리하면, 계획서 §5의 "데이터 생성 7단계" 중 [1][3][4]는 이미 돌아가고 있다. 남은 건 [5] 반사실 짝, [6] 게이트, 그리고 위 버그 수정이다. 예상보다 앞서 있다.

7 우선순위

순위할 일근거
1버그 ①②③ 수정 — swapped 제외 + 충돌 검사 + answer dedupe전부 질의 생성기 후처리. 재시뮬 불필요
2버그 ④ — 이석 구간 추가 + tracked_obj_pixels 자동 게이트재생성 필요하지만 구조적 해결. 안 하면 blind 점수가 부풀려진다
3subgoal GT 유도 (segments → gt.plan/required/forbidden)파이프라인 계획의 B단계(골든 20개)를 수작업 대신 자동으로 만들 수 있다
4반사실 짝 생성낮은 비용, 가장 강력한 검증 장치
5open/close 이벤트 추가하위 task 절반이 여기 걸려 있다. 중기 과제
6심기 방식 결정 — 보기만(W-obs) vs 직접(W-act)현재 데이터는 W-act. 지난 결정은 W-obs. 하나로 정해야
순위 1은 재시뮬이 필요 없다. eval_spec.json 재생성만으로 끝난다 — event_results에 swapped/planned_obj/obj가 다 있으니 후처리로 걸러낼 수 있다. 순위 2만 재생성이 필요하다.

8 확인이 필요한 것

  1. swapped는 왜 생기나? 22%는 높다. tags:["shift"]가 같이 붙어 있어 "잡는 중 물체가 밀려서 옆 것을 집음"으로 보이는데, 원인이 grasp sampler인지 물리인지에 따라 대응이 다르다.
  2. secs 필드의 의미 — event 0이 secs=476.4인데 프레임 구간은 [0, 2628] = 105 s다. 생성 wall-clock으로 보이는데 확인 필요.
  3. tracked_obj_pixels의 카메라 순서 — videos.cameras = [wrist, exo1, exo2]와 같은 순서인지 확인 필요(가정하고 썼음).
  4. answer의 room 정수(4/5/6/7)와 obj UID 접미사의 방 번호가 어떤 관계인지 — UID는 초기 방으로 보인다.
  5. final_state.npz 용도 — 확인 완료: names(17) / pose(17,7) / robot_base_pose(7) / frame(). 종료 시점 스냅샷이고, 버그 ④의 거리 계산에 바로 썼다. 정답 검증·이석 구간 판정에 그대로 쓸 수 있다.
  6. 이석 거리 기준을 얼마로 둘까 — Navigate-to 성공 기준이 1.5 m이므로 최소 그 이상이어야 하고, 가시성까지 끊으려면 다른 방이 안전하다. 현재 정상 질의들의 거리 분포(3.0 ~ 12.2 m)를 보면 3 m + 시야 밖을 하한으로 두는 게 자연스럽다.