실험 3 — find·restore 에서 메모리가 못 이기는 이유

TL;DR

.76 – .79

첫 navigate 적중 (find, arm 무관)

5 – 7%

pick 시도당 lift (find)

±6칸

SR 이항 SD (n=150)

18%

같은 arm 재현 뒤집힘 (tmrep 109칸)

77 / 102

5 arm 전부 실패 (find/restore)

메모리가 알려 줄 것이 지시에 이미 있다: 전 arm 이 GT 계획(방·가구·물체)을 과제 지시에 받고, 사용자 턴에는 "직전 서브골 실행 중 프레임 + 현재 뷰"가 들어간다 — blind 도 1턴 전은 본다. find 는 1-hop(가서 잡으면 끝, 평균 11턴)이라 그 이상은 필요 없다.
남는 변수는 파지 복권: 시도당 lift 5~7% × 칸당 7~8회 → SR ≈ .4. VLA 몫이라 arm 이 못 바꾼다. 같은 칸이 모두에게 실패(77/150).
arm 차는 잡음 안: SR 범위 .327~.387 = 9칸 = 1.5 SD; 같은 arm 을 다시 돌려도 칸당 18% 가 뒤집힌다(9 vs 11, p=.82). "frames 가 잘한다"(+3칸)·"tagmem 이 못한다"(−1칸) 모두 순위로 읽을 크기가 아니다.
restore 만 예외: 2-hop(집기 → 든 채 이동 → 놓기)이라 "지금 들고 어디로 가는 중"이 몇 턴 유지돼야 하고, 텍스트 롤포워드(rf-v3)만 +.088(3 SD, p=.011). tagmem 은 같은 텍스트지만 사건 로그가 상태 요약이 아니라 held 상태가 흔들린다(260924 턴 분석).
실험 2 의 tagmem 우위는 계획의 질(읽기 메모리에서 방·가구·인스턴스를 맞히는 것)이지 온라인 쓰기가 아니다 — 실험 3 이 그 둘을 분리해 보여 준다.

1arm 이 실제로 받는 입력 (blind, find, t=4)

[과제 지시 블록] GT 계획: "pick up the box — on the dining table in the kitchen" (전 arm 동일, 검사기 ⑤ 전 행 확인) [사용자 턴 texts] "Frames captured while your previous subgoal was executing:" ← 직전 서브골 프레임(전 arm 공통) "Your current view:" ← 현재 4장 "Object names used in this house: CD, alarm clock, apple, …" "Room names used in this house: bedroom, bathroom, kitchen, living room" "Goal: Pick up the box" "Reply with the JSON object only." [결정 t=4] "The robot is in the process of grasping the box on the dining table. The lift is not completed yet, so continue the pick action." → pick

메모리 arm 은 여기에 자기 노트/프레임(여러 턴 전)을 더 받는다. find 에서 여러 턴 전 정보가 필요한 상황은 multi(2~3답, "무엇을 이미 집었나")뿐인데 multi 는 파지 곱셈 천장으로 전 arm 0~.24 라 차이가 생길 여지가 없다.

2병목 지표 — find 150칸

arm	SR	첫 navigate 적중	pick/칸	pick 시도당 lift	lift 있는 칸(pick 있는 칸 중)	1답 SR	false_done
blind	.367	.773	7.8	.062	.461	.500	.280
frames-uniform	.387	.787	6.9	.075	.537	.544	.220
rollforward-v3	.353	.773	8.4	.053	.476	.500	.313
rollforward-vis-pure	.327	.787	7.8	.057	.460	.456	.273
tagmem-r3	.360	.760	8.3	.055	.460	.489	.273

항법 열이 평평한 것이 핵심이다 — 계획이 정답이면 "어디로"는 끝난 문제이고, 그다음은 시도당 6% 짜리 파지 복권을 몇 번 돌리느냐다. 메모리 arm 이 시도 횟수나 성공률을 바꾸지 못한다(pick/칸 6.9~8.4, 시도당 .053~.075).

잡음: n=150·p≈.36 → SR 의 이항 SD .039(≈6칸). arm 범위 9칸 = 1.5 SD. tmrep(tagmem 을 카메라 수정판으로 다시 돌린 109칸): 같은 결과 82%, 뒤집힘 실패→성공 9 · 성공→실패 11(p=.82). McNemar 전부 p≥.26.

3restore 148칸 — 2-hop 이라 텍스트 상태 유지가 값을 갖는다

arm	SR	첫 navigate 적중	pick/칸	1답 SR	false_done	blind 대비 SR McNemar
blind	.108	.709	20.0	.159	.196	—
frames-uniform	.142	.723	15.1	.227	.243	13/8 p=.38
rollforward-v3	.196	.770	22.6	.318	.135	18/5 p=.011
rollforward-vis-pure	.162	.743	16.4	.261	.182	14/6 p=.12
tagmem-r3	.142	.736	20.3	.239	.135	15/10 p=.42

이항 SD .029(≈4칸); rf-v3 − blind = 13칸(3 SD)만 잡음 밖. 5 arm 전부 실패 102/148 — 파지·놓기 천장은 여기서도 지배. tagmem 이 rf-v3 만큼 못 얻는 이유는 260924 턴 분석대로 `[t=k]` 사건 로그가 상태 요약이 아니어서 held 상태가 흔들리고(재-pick 드롭 6878, 진동 3655), `[now]` 슬롯이 그것을 고치지 못했기 때문.

4Takeaway

해석

"no-memory 가 잘한다"가 아니라 "메모리가 더 잘할 재료가 없다". 실험 3 은 계획(어디로·무엇을)을 정답으로 고정해 메모리의 주 역할을 제거한 설계이고, 남는 변수는 (a) VLA 파지 복권(전 arm 공통) (b) 몇 턴 전 상태의 유지(2-hop restore, 텍스트만 유효) (c) "끝났느냐"(resume 에서만 큰 값). find 는 (a)만 남아 동률이 설계상 결과다. 논문에는 표 각주로 "이항 SD ≈6칸·같은 arm 재현 뒤집힘 18%"를 적어 ±3칸을 순위로 읽지 않게 할 것.

파지 천장을 걷어낸 조건(오라클 파지 또는 파지 성공률 높은 VLA)에서 같은 5 arm → (b)·(c)의 순이득이 커지는지 확인 가능(비용 승인 필요).
tmrep 완주 후 뒤집힘률 확정치를 각주에.

scene_bench · 실험 3 Oracle-plan · 로그 claude/260925/analysis-oracle_find_restore_no_memory_parity.md · 선행 260924-oracle_tagmem_online_gap.html

find·restore 에서 no-memory·frames 가 tagmem 과 동률인 이유

TL;DR

1arm 이 실제로 받는 입력 (blind, find, t=4)

2병목 지표 — find 150칸

3restore 148칸 — 2-hop 이라 텍스트 상태 유지가 값을 갖는다

4Takeaway

해석