실험 3 Oracle-plan — find·restore 최종 결과(완주 보관소)

260925 갱신(사용자 결정): 보관소 본표의 find·restore tagmem-r3 행은 카메라 수정판 재현 런(tmrep, src_main14 strict_policy_camera, 두 번째 추첨)으로 교체됐다 — tagmem find SR .360 → .367(McNemar 13/13 p=1.00), restore .142 → .176(16/6 p=.052, GC 부호검정 29/12 p=.012). 아래 표는 교체 전 값. 결론(find 동률 · restore rf-v3 유의)은 불변, restore tagmem 은 2위·경계. 상세 260925-oracle_tmrep_tagmem_replicate.html.

TL;DR

750 / 740

find / restore 행(완주)

.33 – .39

find SR 5 arm (p ≥ .26)

.196 vs .108

restore rf-v3 vs blind SR (p=.011)

77 / 102

5 arm 전부 실패 질의 (find/restore)

149

restore 재실행 대체 칸 (슬림 69·비슬림 80)

$52 + $140

API 비용

find(150질의 공통): SR blind .367 · frames .387 · rf-v3 .353 · vis .327 · tagmem .360 — blind 대비 McNemar 전부 p ≥ .26, GC 부호검정 p ≥ .40. 계획이 정답이면 시드 없는 온라인 쓰기는 SR·GC 를 못 올린다. 효율만 방향이 있다(tagmem 재-pick .053 vs .073, 낭비턴 .315 vs .383; frames false_done .220 vs .280).
restore(148질의 공통, 운반 수정판 149칸 대체): rf-v3 SR .196 vs blind .108, McNemar 18/5 p=.011(1답 칸 .318 vs .159), GC 부호검정 26/13 p=.053 — 유일한 유의 차. frames .142 · vis .162 · tagmem .142 는 p ≥ .11.
천장은 VLA 파지: 5 arm 전부 실패 질의가 find 77/150 · restore 102/148, 전부 성공 31 · 1. 실패 사례는 정답 자리 앞에서 같은 pick 을 10~43회 반복(lifted 0). 메모리는 "어디로 갈지"를 바꾸지 "잡히느냐"를 못 바꾼다.
출처: 재실행 149칸(rr 129 + rry 18 + rradd 2) 중 센서 슬림 69 · 비슬림 80(summary_restore.json.rerun_sensors, PROVENANCE §3); 짝 비교 성공 13 → 35. 병합 검사 ①~⑨ 통과.

1배경 / 목적

실험 3 은 독립 실험(사용자 결정 260921): 5 arm 전부에 GT 계획을 과제 지시 블록에 고정(--plan gt --plan-slot instruction), 시드 메모리 제거(--seed none), goal 이미지 없음. 같은 칸을 돌므로 arm 비교는 blind 대비 McNemar. find 는 260923 완주, restore 는 운반 버그(730a879, 두께 >4 cm 물체를 운반 첫 스텝에 놓음) 영향 칸을 수정판 src_main6 로 재실행한 뒤 오늘 완주했다(잔여 6칸 sx7 원격 이관 → 추가 영향 2칸 rradd0).

실험 2 와 나란히 두지 말 것 — 셀·조건·계획 출처가 다르다(실험 2 = VLM 읽기 답 + 시드 메모리, 자기 셀). 논문에는 별도 표.

2find — 150질의 × 5 arm

arm	SR	M1 재-pick	M2 false_done	M3 낭비턴	M4 GC	D1 GT 인스턴스 (n칸)	턴	pick/칸	$/칸	분/칸
blind	.367	.073	.280	.383	.430	.858 (128)	11.2	7.8	.056	9.2
frames-uniform	.387	.068	.220	.360	.446	.867 (123)	10.1	6.9	.097	8.4
rollforward-v3	.353	.089	.313	.399	.422	.854 (124)	11.1	8.4	.058	9.7
rollforward-vis-pure	.327	.059	.273	.337	.394	.870 (126)	11.6	7.8	.067	9.7
tagmem-r3	.360	.053	.273	.315	.420	.853 (124)	11.6	8.3	.069	10.1

blind 대비 짝비교(같은 150칸)

arm	SR b01/b10 p	false_done b01/b10 p	GC 우세/열세 p (부호검정)
frames-uniform	10/7 p=.629	13/22 p=.175	18/15 p=.728
rollforward-v3	10/12 p=.832	23/18 p=.533	17/19 p=.868
rollforward-vis-pure	7/13 p=.263	22/23 p=1.000	15/21 p=.405
tagmem-r3	12/13 p=1.000	19/20 p=1.000	19/21 p=.875

층화(사전 선언): 1답 90칸 SR .456~.544(frames .544 · blind .500) · 2답 38칸 .18~.24 · 3답 22칸 0~.045. multi "1단계 성공" 17칸 GC .64~.72(전 arm 비슷), "1단계 실패" 43칸 .13~.19.

find 는 arm 이 구별되지 않는다. 계획(방·가구)이 주어지면 어디로 갈지는 정해지고, 남는 것은 파지 성공 여부 — 그건 메모리가 아니라 VLA 몫이다.

3restore — 148질의 × 5 arm (수정판 149칸 대체)

arm	SR	M1	M2 false_done	M3 낭비턴	M4 GC	D1 (n칸)	턴	pick/칸	놓다 낙하 칸	$/칸	분/칸
blind	.108	.001	.196	.310	.145	.856 (141)	28.2	20.0	13	.157	25.2
frames-uniform	.142	.001	.243	.179	.190	.849 (137)	22.4	15.1	16	.262	20.1
rollforward-v3	.196	.007	.135	.270	.227	.881 (137)	28.9	22.6	13	.159	26.5
rollforward-vis-pure	.162	.008	.182	.299	.200	.864 (136)	23.8	16.4	13	.178	20.0
tagmem-r3	.142	.004	.135	.192	.189	.870 (133)	26.5	20.3	13	.186	25.1

blind 대비 짝비교(같은 148칸)

arm	SR b01/b10 p	false_done b01/b10 p	GC 우세/열세 p
frames-uniform	13/8 p=.383	24/17 p=.349	26/16 p=.164
rollforward-v3	18/5 p=.011	11/20 p=.150	26/13 p=.053
rollforward-vis-pure	14/6 p=.115	16/18 p=.864	21/11 p=.110
tagmem-r3	15/10 p=.424	15/24 p=.200	26/17 p=.222

층화: 1답 88칸 SR blind .159 · frames .227 · rf-v3 .318 · vis .261 · tagmem .239; 2답 35칸 전 arm ≤ .057; 3답 25칸 전부 0. 운반 수정 효과(짝 149칸): 성공 13 → 35, 운반 낙하 턴 5. 그래도 pick 20회/칸 · "놓다 낙하" 13~16칸/arm 이 남는다.

rf-v3 만 blind 를 유의하게 이긴다(SR +.088, 1답 칸 2배). 운반·놓기 단계가 긴 과제일수록 텍스트 롤포워드 노트가 진행 상태를 유지하는 데 기여했다는 해석이 가능하나, 다른 세 arm 은 유의하지 않다 — 과장하지 말 것.

4실패 사례 — 5 arm 전부 실패(1답 칸)

v1_train_1299__2 "Pick up the remote control I moved earlier" (find) / "… place it in or on where it first was" (restore) find : blind done 13턴 pick 11 · frames done 3턴 pick 1 · rf-v3 budget 18턴 pick 17 · vis done 5턴 pick 3 · tagmem budget 18턴 pick 17 — lifted 전부 [] · 최근접 0.51~0.67 m restore : 5 arm 전부 budget_exhausted 42~45턴 · pick 30~43회 · lifted [] · 최근접 0.50~0.63 m v1_train_2169__1 "Pick up the vase …" find : pick 3~18회 · lifted [] · 최근접 0.65~0.77 m · tagmem 은 5턴 만에 done 선언(false_done) restore : 5 arm 전부 budget_exhausted 23~39턴 · pick 15~36회 · lifted []

공통 패턴: 정답 자리(계획이 준 방·가구) 앞에 서서 같은 pick 을 반복한다. 얇은 리모컨·꽃병처럼 VLA 가 못 잡는 물체는 어떤 메모리도 구제하지 못한다. 실험 3 이 find 에서 arm 차이를 못 보이는 이유가 여기 있다(5 arm 전부 실패 77/150).

5출처 · 함정

보관소 final_results/oracle_plan_v1_260923(git 미추적): rows/(원 행 + oracle_restore_rr*/rry*/rradd0 대체 행) · turns/ · tables/oracle_{find,restore}.md · summary_*.json · PROVENANCE.md.
재실행 149칸 = rr 129(이 클러스터 몫, yj 실행) + rry 18(yj 몫) + rradd0 2(sx7 회수 뒤 추가). 병합 검사 check_rerun_merge.py ①~⑨(스테이징 = 로컬, 조각·목록, 중복 0, 조건, episode.json mtime, 백업 149/149) 통과.
센서 슬림 혼합(사용자 260924 08:15): 슬림 69 · 비슬림 80 — 같은 조건으로 취급(표에 구분 없음), 칸 수만 rerun_sensors 에 남김.
스냅샷 find/restore src_main4, 재실행 src_main6(+slim). 채점 find lifted(바닥 답 reached_only) · restore placed_on.
routine(615칸, 진행 중 → 통 90칸 src_main12 재실행 대체)·resume(805칸, src_main13 스모크 검증 완료, 본 런 승인 대기)은 같은 보관소에 --families 로 추가한다.

6Takeaway · Next

해석

GT 계획 조건에서 온라인 메모리 쓰기의 이득은 find 에서 0, restore 에서 rf-v3 만 +.09 SR. 실행 병목(VLA 파지·놓기)이 메모리 효과의 천장을 정한다 — 온라인 트랙의 변별력은 파지 성능이 올라야 생긴다. 논문 표는 "5 arm 동률(find) / rf-v3 유의(restore)" 두 줄 + 재실행·슬림 출처 한 줄.

routine 오라클 완주 → rc 90칸 재실행 → 보관소 추가.
resume 오라클 본 런(805칸, 견적 $120~210) 승인 → 실행 → 보관소 추가.
place 사례 연구 2편(약속분) 별도.

scene_bench · 실험 3 Oracle-plan · 로그 claude/260924/exp-oracle_plan_final_find_restore.md · 원천 final_results/oracle_plan_v1_260923/tables/

find·restore 최종 결과 — GT 계획 + 시드 없음, 5 arm 같은 칸