실험 3 Oracle-plan Online

TL;DR

게이팅 질문 해소: v1.2 cross_multi 가 온라인에서 돈다 — 2사슬 칸이 done 도달·물체 파지. find 표본을 v1.0 으로 되돌릴 필요 없음.
주지표가 죽은 값이 아니다: M2 false_done 발화 — 2답 blind 가 1/2 만 든 채 턴 6 에 done 선언.
실행 상태 채널이 arm 별로 갈린다: tagmem 노트 500자 · frames-uniform 이미지 6장 · blind 0/0. 실험 2 의 "채널이 대부분 꺼져 있다" 문제가 이 조건에서는 실제로 열려 있다.
3사슬 실패는 메모리 효과가 아니다: 접지·주행 모두 성공(pose_gate: passed)인데 파지가 0 — VLA 공통 바닥. 단, 본 런 표본의 84%는 1답 칸이고 실험 2 실측 파지율은 39%다.
본 런 견적 $191 · 391 GPU시간 (1,490칸). 승인 대기.

스모크 칸

$0.72

실지출 / $2 캡

false_done

1490

본 런 칸

$191

본 런 견적

1 배경 / 목적 — 회상 기억과 실행 상태 기억을 가른다

세 실험은 무엇을 기억해 답했는가와 도는 동안 무엇을 기억했는가를 분리하려는 구조다.

실험	계획 출처	시드 메모리	남는 변수
1 컨텍스트 VLM 이밸	—	—	회상 정확도
2 계획형 온라인	VLM 읽기 답	있음(전략별)	회상 + 실행
3 GT 온라인 (이 문서)	정답(GT)	없음	실행 상태 기억만

실험 2 에서 관측된 것은 SR 이 아니라 효율의 차이였다. 낭비의 정체는 "제자리 재-pick" 이고, 그중 19%가 자기 성공을 스스로 깼다. 그런데 실험 2 는 회상 실패와 실행 실패가 섞여 있어 "메모리가 실행을 돕는가"를 단독으로 못 읽는다.

설계: 계획을 정답으로 고정하고 시드 메모리를 빼면, 남는 것은 에이전트가 도는 동안 스스로 쌓은 기억뿐이다. 5 arm 이 같은 칸을 돌므로 LOO 난이도 보정 없이 McNemar 짝비교를 쓴다.

주지표는 SR 이 아니다 — 실험 2 restore multi 가 0/47 이라 SR 로는 신호가 안 나온다. 사전등록: M1 held_repick_rate · M2 false_done · M3 wasted_turn_share · M4 gc.

2 세팅 — 무엇을 바꿨나

--plan gt 읽기 답 대신 facts.gt_selections 로 계획 생성 (online_plan.gt_plan_answer) --plan-slot instruction 계획을 메모리 노트가 아니라 **지시문 블록**에 넣는다 --seed none 읽기 트랙 메모리 미주입 (퇴거 안내문도 함께 꺼짐) plan_source=="gt" → plan_mode="fixed" arm 무관, 계획이 정답이라 갱신할 것이 없다

왜 지시문 블록인가: 노트에 넣으면 전략별 메모리 규칙이 계획을 지우거나 덮어쓴다 — 실험 2 실측에서 rf-v3 는 100% 삭제했고, append 4전략은 0/884 갱신이었다. 계획이 조건인데 조건이 사라지면 실험이 성립하지 않는다.

모델이 실제로 받는 계획 (3사슬 칸)

Plan — the task has been broken into these steps for you: 1. pick up the butter knife — on the countertop in the kitchen 2. pick up the cell phone — on the chair in the kitchen 3. pick up the remote control — on the dresser in the bedroom This plan is part of the task. It is accurate and does not change, and you cannot edit it. Work through the items in order.

체크박스(- [ ]) 표기는 제거했다(사용자 결정). 계획은 정답 물체·표면·방을 그대로 담는다.

표본

가족별 논문 서브타입(D1/D2/D3/S1/S2)마다 k=30 층화추출(seed 20260921), 칸 = (에피소드, 질의, arm) 3튜플.

가족	데이터셋 루트	질의	칸	제외
find	`…_fd856246` (v1.2)	150	750	바닥 답 25
restore	`…_6511da78` (v1.1)	148	740	어휘 미등록 9

루트가 다르다: v1.2 의 restore 질의는 내용이 v1.1 과 같아도 편(traj.h5)이 다르게 렌더돼 GT 가 어긋난다. 바닥 답은 방 이름을 못 채워 계획 문장이 불완전해지므로 제외했고, 어휘 미등록(raw slug 폴백) 물체도 이름으로 지시할 수 없어 뺐다.

3 스모크 결과 — 6칸

유일한 게이팅 질문은 v1.2 cross_multi(2·3사슬)가 온라인에서 도는가였다. 안 돌면 find 의 S1/S2 표본을 v1.0 으로 되돌려야 했다.

arm	사슬	종료	턴	비용	시간	파지	M4 gc	M2	노트/이미지	예산
`blind`	2답	done	6	$0.027	4.0분	1/2	0.50	예	0자 / 0장	3000
`frames-uniform`	2답	budget_exhausted	21	$0.216	23.2분	0/2	0.00	—	0자 / 8장	3000
`tagmem-r3`	2답	budget_exhausted	23	$0.122	24.7분	0/2	0.00	—	2342자 / 0장	3000
`blind`	3답	budget_exhausted	45	$0.222	45.5분	0/3	0.00	—	0자 / 0장	5500
`frames-uniform`	3답	nav_loop	6	$0.075	1.7분	0/3	0.00	—	0자 / 6장	5500
`tagmem-r3`	3답	nav_loop	6	$0.057	1.7분	0/3	0.00	—	500자 / 0장	5500

게이팅 해소: 2사슬 칸이 done 에 도달하고 물체를 들었다 → find 표본 되돌릴 필요 없음.

함께 확인된 것

예산 이중계산 수정 라이브 — budget_steps 3답 5500 / 2답 3000. 버그가 남아 있었다면 16500.
시드 제거 확인 — 전 칸 seed_lines=0 seed_images=0.
실행 상태 채널 분기 — tagmem 만 노트(2답 2,342자·3답 500자), frames-uniform 만 이미지(8·6장), blind 0/0. 시드를 빼서 생긴 직접적 결과 — 쓸 것이 자기 경험밖에 없다.
M1 은 6칸 전부 0.000 — 파지가 통틀어 1회뿐이라 "이미 든 물체를 다시 집는" 사건이 일어날 기회가 없었다. 스모크는 M1 을 검증하지 못했다(근거는 실험 2 6,237턴의 0.171).
M2 발화 — 2답 blind 가 1/2 만 든 채 턴 6 에 done 선언(false_done=True).

4 실패의 정체 — arm 과 무관한 공통 바닥

6칸 중 5칸이 실패했는데 양식이 둘로 갈린다. 6칸 통틀어 pick 턴 82회 중 파지 성공은 1회다.

양식	arm	턴	pick 시도	파지 성공	원인
nav_loop	3답 frames-uniform · tagmem-r3	6	0	—	물체가 사거리 밖(`out_of_reach=5`) → navigate 6연속 → 가드 발동
budget_exhausted	3답 blind · 2답 frames-uniform·tagmem-r3	21~45	18~41	0	접근은 했는데 `hold_count_end` 가 끝까지 0

에이전트는 매 턴 category:"butter knife", surface:"countertop", room:"kitchen" 을 정확히 냈고, 접지·주행 모두 성공(ok=True, pose_gate: passed)이었다. 재접근 이동거리는 0.07~0.93 m.

즉 실패는 계획·회상이 아니라 VLA/주행 자세의 공통 바닥이고, arm 과 무관하다.

그렇다면 M1 이 본 런에서도 0 으로 죽는가? — 아니다

실험 2 find 본 런 실측:

칸	총 턴	pick 턴	파지 성공	M1 held_repick
1답 793칸	5,541	3,570	1,394 (39.0%)	0.171
2답 28칸	696	468	132 (28.2%)	0.152

파지는 평균적으로 1/3 이상 성공한다. 스모크의 1/82 는 다중사슬 칸에 몰린 꼬리다. 본 런 표본의 84%(1,255/1,490)가 1답 칸이므로 M1 은 측정된다.

해석

다중사슬 칸(235/1,490 = 16%)은 VLA 파지 바닥에 눌려 arm 차이를 못 보여줄 가능성이 높다. 본 분석에서 사슬 길이를 층으로 나눠 읽어야 한다 — 다중사슬을 섞어 평균내면 1답 칸의 신호까지 희석된다.

5 본 런 전에 닫은 것

M4 gc_score 결함 수정 (37bf6fd) — placed|lifted|reached 합집합이 answer_scoring 의 값을 무시해 "pick" 답이 다가가기만 해도 충족으로 세어졌다. 집기는 못 하면서 돌아다니기만 하는 팔이 유리해지는 방향이라 arm 비교를 왜곡한다. 술어를 online.online_success._sat 와 일치시켰다.
본 런 스냅샷 분리 (e74cf55) — tmp/oracle_plan/src_main. 스모크가 돈 src 는 증거로 보존. nav0.py 만 실험 2 find 본 런 스냅샷(tmp/plan_main/src_w2)과 바이트 동일로 고정.
패리티 게이트 통과 — 공유 프롬프트 288개 바이트 동일(--oracle-axes, exit 0).
5 arm 전부 렌더 확인 — rf-v3 는 plan_mode_for()=="rewrite" 라 plan_block 이 ValueError 로 죽을 수 있는 경로였다. plan_source=="gt" 강제로 전 arm fixed, 체크박스 없음 확인.
M1~M4 배선 확인 — scan_online_turns.py --prefix oraclesmoke → 4/4칸 기록(episode.json 누락 0) → 집계 정상.

nav 조건을 옛것으로 고정한 이유: 다른 세션이 260921 에 pick 접근 정면 보정을 기본 켬으로 넣었다(00e299e). 실험 3 은 실험 2 와의 대조로 읽는 실험이라, 주행·파지 조건까지 같이 바뀌면 "GT 계획 + 시드 제거" 효과와 분리할 수 없다.

알려진 한계(기록만): episode.json 턴 스키마가 스킬마다 다르다 — held_object_id 는 pick 턴에만 실려, M1 은 연속 pick 턴 기준으로만 센다. 실측 차이는 1055 → 1064(0.9%)라 사전등록 정의를 유지했다.

6 본 런 견적 — 승인 대기

가족	칸	사슬 분포	비용	GPU시간	샤드당
find	750	1답 650 · 2답 50 · 3답 50	$44.3	94시간	23.6h (4샤드)
restore	740	1답 605 · 2답 115 · 3답 20	$146.4	297시간	37.1h (8샤드)
합계	1490	—	$190.7	391시간	동시 8샤드 ≈ 49시간

단가는 실험 2 본 런 실측(find 821행 · restore 461행)이고, find 3답만 스모크 실측이다. 실험 3 은 시드가 빠져 입력 토큰이 줄고 정답 계획이라 헛턴이 줄므로 상한으로 읽어야 한다 — 스모크 2답 blind 는 6턴에 끝났는데 실험 2 2답 평균은 24.9턴이었다.

페이싱: 게이트웨이 일일 캡 $100 → 최소 2.4일에 나눠 돌려야 안전(하루 계획 ≤$80). find 먼저($44, 하루 안) → restore 이어서($146, 2일).

승인 범위

현재 승인된 것은 P1 스모크 ≤$1.5 뿐이고 실지출은 $0.72다. 본 런 $191 는 별도 승인이 필요하다.

scene_bench · 실험 3 Oracle-plan Online · job 144442 · 생성 scripts/build_oracle_smoke_report.py

실험 3 · GT 계획 온라인 제어 — P1 스모크