온라인 계획형 본 런 — find 1108칸 분석

TL;DR

난이도를 맞추면 전략 간 실행 성공률 차이가 사라진다. 자기 셀 SR 은 .524~.634 로 벌어져 보이지만, 같은 칸을 돌린 다른 전략의 평균을 기대값으로 놓는 leave-one-out 보정에서 모든 Δ가 ±0.031 이내, 전부 2·SE 미만. frames-uniform 의 .634 는 같은 칸에서 다른 전략들도 .649 를 낸다.
종단 SR = 읽기 정답률 × .58. 온라인 층이 전략 무관 상수처럼 작동하므로 순위는 읽기 트랙을 그대로 물려받는다 (vis-pure .285 · textlog .256 · frames .253 · rf-v3 .216 · blind .073).
전략이 바꾸는 건 성공이 아니라 효율. 같은 칸에서 textlog 은 vis-pure 보다 1.8턴 더 쓰고(+0.82 vs −1.00), 대신 첫 navigate 적중은 textlog 이 +0.12 로 가장 높다(축어적 장소 이름 vs 시각 추론 이름).
실패의 84%는 파지다. 실패 470칸 중 393칸이 GT 앞까지 가고도 못 들었다. navigate 를 아예 안 한 165칸 (그중 162칸은 스폰부터 reach 1 m 안)조차 SR .491 — 항법을 공짜로 줘도 절반은 못 집는다.
에이전트는 끝난 줄 모른다. false_done 25%(목표 미달인데 done) · unaware_success 82칸 · 전체 8013턴 중 2439턴(30.4%)이 목표 달성 후 낭비. 전략별 차이는 보정 후 전부 잡음.
SR 은 동률이어도 효율은 갈린다. 같은 칸에서 textlog 은 vis-pure 보다 pick 2.1회·턴 2.5회 더 쓴다. 다만 어느 전략도 더 많은 장소를 뒤지지 않는다(서로 다른 navigate 표적 0.88~0.94 동일) — 낭비는 제자리 재-pick이고, 든 채 재-pick 1341회 중 257회(19%)는 자기가 들었던 것을 도로 놓친다.
효율 차이는 온라인 기록이 아니라 시드 메모리의 성질에서 온다. 온라인에서 자기 행동을 기록하는 전략은 사실상 없고, textlog 내부에서 시드 텍스트가 길수록 pick 초과가 커진다(짧은 1/3 +0.14 → 긴 1/3 +2.53, r=+0.20).
⚠ 감사(§9): 우리가 재려던 execute-state 메모리가 6 arm 중 1개(tagmem)에서만 켜져 있었다. textlog 은 프롬프트가 note: null을 강제해 원천 차단, vis-pure 는 계약은 있으나 89% 칸에서 0장 보관, frames-uniform 의 온라인 1장은 현재 뷰의 중복이라 순증 0, tagmem 조차 온라인에서는 태그화·재검색을 하지 않는다. 따라서 현재 데이터로 "execute-state 가 효율을 만든다"는 주장할 수 없다.
계획 메모리([plan] 줄)는 사실상 비어 있었다. append 계열 4전략은 계획을 고칠 수단이 구조적으로 없고(0/884 갱신), rf-v3 는 노트를 다시 쓰면서 계획 줄을 지운다(198칸 중 100%). 그런데도 SR 에 영향이 없다.

1108

완주 칸

.576

SR@예산

84%

실패 중 파지

30.4%

낭비 턴

$62.46

API

1 배경 · 이 표를 읽는 열쇠

읽기 트랙은 "메모리에서 어디 있었나"를 묻는다. 계획형 온라인 프로토콜 v3는 그 답을 초기 계획으로 넘겨 MuJoCo 씬에서 실제로 걸어가 집게 한다. 파일럿(260915)에서 오답 계획으로는 성공이 0(62행)임을 확인했기 때문에, 본 런은 그 전략의 읽기 답이 방·가구까지 맞은 칸만 돌린다.

그래서 셀 집합이 전략마다 다르다. vis-pure 287 · textlog 280 · frames-uniform 235 · rf-v3 224 · blind 82. 자기 셀 SR 열은 전략 간 비교에 쓸 수 없다 — 서로 다른 과제 위의 점수다. 공정 비교는 두 가지뿐: 5전략 공통 37칸(검정력 없음)과, 아래 §3의 leave-one-out 난이도 보정(전략당 81~260칸).

이번 분석이 답하려는 질문 세 가지: ① 계획이 맞은 뒤에도 메모리 전략이 실행 성공률을 바꾸는가? ② 종단(읽기 × 실행) 순위가 읽기 표와 같은가? ③ 에이전트는 자기가 끝낸 줄 아는가?

2 실행 설정

데이터

find v1.0 · 100편 · 462질의

칸

1108 (전략별 82~287)

VLM

gemini-3.7-flash

VLA

MolmoBot place_oc@10000

관측 예산

턴당 4장 · 시드 8장

스텝 예산

1500 (답 개수 배수)

턴 상한

22 (984칸) / 30·34·50

가드

nav루프 6 · stall 6 · lifted-guard 끔

클러스터

4샤드 × 1 GPU · own · 35잡

비용

$62.46 · 109.1 GPU-시간

VLA 교체 근거(260919 페어 프로브): MolmoBot pick 68% vs π0.5 45%, pick∧hold 35% vs 22%. 20k 체크포인트 없음. 원천·재현 절차는 final_results/online_plan_v1_260920/PROVENANCE.md.

3 결과 A — 난이도를 맞추면 전략 차이가 사라진다

전략	자기 셀 SR	공통 37칸	비교가능 셀	관측	기대(타 전략)	Δ ±SE
blind	43/82 = .524	.486	81	.531	.516	+0.014 ±0.055
textlog	151/280 = .539	.459	201	.562	.531	+0.031 ±0.031
frames-uniform	149/235 = .634	.459	221	.643	.649	−0.006 ±0.028
rollforward-v3	127/224 = .567	.514	208	.562	.569	−0.007 ±0.028
rollforward-vis-pure	168/287 = .585	.514	260	.573	.591	−0.018 ±0.027

읽는 법: Δ = (그 전략의 점수) − (같은 칸을 돌린 다른 전략들의 평균). 커버리지 2 이상 셀만 쓴다 (1전략 137칸 · 2전략 136 · 3전략 94 · 4전략 58 · 5전략 37).

자기 셀 SR 의 .524~.634 격차는 전부 셀 선정 효과다. 쌍둥이 비율로 표준화해도(blind .37 → rf-v3 .15) 격차가 안 닫혔는데 LOO 는 닫았다 — 난이도 축이 쌍둥이 하나가 아니라는 뜻. 4전략 공통 61칸에서는 순위가 아예 뒤집힌다(rf-v3 .607 > textlog .541 > frames .525 > vis-pure .475). McNemar 불일치 쌍도 전부 균형(blind vs textlog 6/5 · frames vs rf-v3 5/7 · rf-v3 vs vis-pure 6/6).

전략이 실제로 바꾸는 것 — 성공률이 아니라 효율

전략	Δ턴	Δ첫 navigate 적중	Δfalse_done
textlog	+0.82 ±0.32	+0.121 ±0.026	−0.022 ±0.033
blind	+0.55 ±0.52	+0.031 ±0.033	−0.077 ±0.056
rollforward-v3	+0.25 ±0.30	+0.009 ±0.015	+0.025 ±0.030
frames-uniform	−0.00 ±0.35	−0.063 ±0.016	+0.024 ±0.027
rollforward-vis-pure	−1.00 ±0.31	−0.056 ±0.016	+0.001 ±0.028

해석

텍스트 노트(textlog)는 같은 칸을 vis-pure 보다 1.8턴 더 써서 푼다. 대신 첫 navigate 적중은 가장 높다 — 축어적으로 적어 둔 장소 이름이 씬 카드 정본 어휘와 그대로 맞기 때문이고, 이미지 전략은 시각 추론으로 이름을 지어내 한 번 빗나간다. 즉 텍스트 메모리는 조준이 정확하고 이미지 메모리는 수렴이 빠르다. 성공/실패로는 안 보이고 효율 축에서만 보이는 차이다.

4 결과 B — 종단 SR: 병목은 읽기다

전략	읽기 정답 계획 (589행 중)	온라인 SR	종단 SR = 곱
rollforward-vis-pure	287/589 = .487	.585	.285
textlog	280/589 = .475	.539	.256
frames-uniform	235/589 = .399	.634	.253
rollforward-v3	224/589 = .380	.567	.216
blind	82/589 = .139	.524	.073

온라인 층이 전략 무관 상수(.58)처럼 작동하므로 종단 순위는 읽기 순위를 거의 그대로 물려받는다. 메모리 전략의 값어치는 "계획을 맞히는 능력"에서 나오지 "계획을 실행하는 능력"에서 나오지 않는다. 온라인 트랙의 논문 기여는 전략 순위 재확인이 아니라 읽기 점수가 실행으로 얼마나 전이되는지의 계수를 재는 데 있다.

5 결과 C — 실패의 84%는 파지다

실패 유형 (470칸)	칸	비율
GT 근처에 한 번도 못 감	58	12%
도달했지만 못 듦(파지 실패)	393	84%
들었지만 예산 초과	9	2%
들었지만 그 외(종료 위치·done 미달)	11	2%

층	해당	나머지
쌍둥이 셀	.438 (224칸)	.611
multi 질의	.267 (30칸)	.584
첫 navigate 적중	.635 (865칸)	.366
find_distractor	.658 (497칸)	.509
바닥 낙하 발생	.465 (43칸)	.580

항법을 공짜로 줘도 절반은 못 집는다. navigate 를 한 번도 안 한 165칸(전체 14.9%, 그중 162칸은 스폰 시점에 이미 reach 1 m 안)의 SR 도 .491에 그친다. VLA 파지 품질이 기억 평가의 천장을 누르고 있다.

실패 사례 ③ 0f2f74931cb9 (rf-v3, "Pick up the cell phone I moved earlier") — 계획은 정답(on the bed in the bedroom), 스폰부터 reach 안이라 navigate 0회. pick 1회차와 12회차의 팔 자세가 사실상 같고 휴대폰은 끝까지 침대 위. 턴 상한으로 종료.

12회차 pick 롤아웃 (exo)

에피소드 전체 관측 스트림

6 결과 D — 완료 인지: 에이전트는 끝난 줄 모른다

사용자 요청(260918, "task를 마친줄 아는지 모르는지도 중요")으로 새로 넣은 측정축. 성공 판정과 별개로 기록한다.

25%

false_done (279/1108)

unaware_success

2439

낭비 턴 (전체의 30.4%)

142

overrun > 5턴

전략	false_done	unaware_success	overrun 중앙값	예산 초과	nav_loop
blind	.29	.05	2	.20	.02
textlog	.23	.09	2	.29	.02
frames-uniform	.25	.09	2	.16	.03
rollforward-v3	.28	.05	2	.17	.01
rollforward-vis-pure	.25	.07	2	.18	.02

완료 인지 결함은 모델·전략 공통이다. LOO 보정 후 Δfalse_done 최대 +0.025 ±0.030 — 전부 잡음. 기존 SR 이 잡지 못하는 실패 양식이고, 값이 크고(25% · 30.4%), 층별로 안정적이라 새 측정축으로 값어치가 있다.

실패 사례 ① 184a006604d1 (vis-pure, "Pick up the bowl") — 계획 정답, t1 navigate 적중(GT 0.70 m), pick 1회 시도 후 t2에 done 선언. 모든 프레임에서 그릇은 식탁 위 그대로.

실패 사례 ② 1111ac0bb213 (vis-pure, "Pick up the vase I moved earlier") — t2에 화병을 들어 이미 성공(goal_met_turn=2). 그 뒤 20턴 더 pick 을 21회 반복하다 턴 상한 22에서 종료. done 선언 없음, 계획 줄은 끝까지 done: false.

사례 ①의 유일한 pick — 그릇이 움직이지 않는다

사례 ②의 관측 스트림 — 성공 후 20턴 낭비

7 결과 E — 계획 메모리(`[plan]` 줄)는 작동하지 않았다

전략	계획 갱신 1회 이상	최종 계획 상태
blind · textlog · frames-uniform · vis-pure	0/884	초기 계획이 축어적으로 남고 체크 안 됨
rollforward-v3	198/224 (88%)	그중 100%가 계획 줄을 삭제 · done 체크는 2칸(1%)

rf-v3 갱신 로그 (대표, 6ed0ce305e7f · 성공 칸): shown : [{"text": "pick up the bowl — on the dining table in the bedroom", "done": false}] returned: [] stats : {"checked": 0, "unchecked": 0, "added": 0, "removed_open": 1, "n_items": 0}

append 계열 4전략은 쓰기 규칙상 기존 줄을 고칠 수단이 없다 → 계획은 있지만 불변 상수.
rf-v3 는 노트를 통째로 다시 쓰는 규칙이라 첫 재작성에서 [plan] 줄을 지워버린다. 32B rf-v3 붕괴와 같은 노트 덮어쓰기 메커니즘이다.
그런데도 SR 은 영향 없음(rf-v3 LOO Δ −0.007). 계획 텍스트는 0턴의 첫 navigate 표적으로만 쓰이고, 그 뒤엔 관측 루프가 과제를 끌고 간다.

주의 — 인과 주장 안 함. rf-v3 내부에서 계획 유지 26칸 SR .769 vs 삭제 198칸 .540 (턴≥3 조건에서도 .778 vs .528)이지만, 빨리 끝난 편은 애초에 재작성 턴에 도달하지 못한다. 역인과 의심이 크다.

의견

"계획을 유지·갱신하는 능력"을 재고 싶다면 노트와 분리된 계획 슬롯이 필요하다. 다만 이건 하네스 개선 제안이지 이번 측정의 수정 사유가 아니다 — 평가지 튜닝 금지 원칙상, 현재 수치는 그대로 보고한다.

8 결과 F — SR 은 동률인데 효율은 갈린다 (맴돌기 · 끝난 줄 모름)

성공률이 같다면 "너무 돌아다닌다 / 끝났는데 끝난 줄 모른다" 축에서는 갈리는가? 전부 같은 LOO 난이도 보정 위에서 쟀다.

0) 각 전략이 온라인에서 실제로 들고 다니는 메모리

전략	시드	온라인 중 갱신	최종 노트	메모리 이미지
blind	계획 1줄	없음	162자	0장
textlog	읽기 행동로그 6줄 + 계획	없음 — 모델이 낸 note 는 `null`(슬롯 자체가 없음)	841자	0장
frames-uniform	이미지 8장	온라인 프레임 정확히 1장(235/235칸 고정)	162자	8장
rollforward-v3	계획 + 노트	노트 재작성 — 단 88%가 계획 줄 삭제	279자	0장
rollforward-vis-pure	이미지 8장	KEEP 가능하나 평균 0.11장만 보관(89%가 0)	162자	8장

온라인에서 "내가 방금 한 일"을 기록하는 전략은 사실상 없다. rf-v3 만 텍스트를 다시 쓰고, 그나마 계획을 지운다(§7). 그러므로 아래 효율 차이는 온라인 기록이 아니라 시드 메모리의 성질에서 나온다.

1) 돌아다님 — "탐색"이 아니라 "제자리 맴돌기"

전략	navigate 수	같은 표적 재호출	최대 연속	서로 다른 표적 수
blind	1.15 (+0.19±0.12)	0.43 (+0.17±0.10)	1.11 (+0.22±0.11)	0.72 (+0.04±0.05)
textlog	1.58 (+0.37±0.09)	0.65 (+0.33±0.09)	1.53 (+0.45±0.09)	0.91 (+0.04±0.03)
frames-uniform	1.21 (−0.01±0.08)	0.28 (−0.03±0.06)	1.07 (−0.10±0.06)	0.88 (−0.01±0.03)
rollforward-v3	1.17 (−0.24±0.08)	0.22 (−0.20±0.08)	1.11 (−0.18±0.08)	0.94 (−0.00±0.03)
rollforward-vis-pure	1.23 (−0.14±0.08)	0.30 (−0.12±0.07)	1.12 (−0.18±0.07)	0.88 (−0.04±0.02)

서로 다른 navigate 표적 수는 전 전략 0.88~0.94 로 동일 — 어느 전략도 더 많은 장소를 뒤지지 않는다. textlog 의 추가 navigate 는 전부 같은 표적 재호출이다(반복 ≥3회 칸 9.6% 최대 11회 vs rf-v3 2.7%/6회). 방 재방문은 0.01~0.05 로 사실상 없다 — navigate 가 텔레포트라 '이동 거리' 축은 측정 불가.

2) 진짜 낭비는 제자리 재-pick

전략	총 pick	첫 성공까지	첫 성공 이후	든 채 같은 물체 재-pick
blind	4.79 (+0.39±0.54)	3.30 (+0.49±0.37)	1.49 (−0.10±0.40)	0.94 (−0.02±0.30)
textlog	4.99 (+1.07±0.33)	3.16 (+0.63±0.26)	1.82 (+0.44±0.24)	1.03 (+0.24±0.15)
frames-uniform	4.57 (+0.08±0.36)	2.35 (−0.15±0.18)	2.22 (+0.23±0.32)	1.52 (+0.14±0.25)
rollforward-v3	4.36 (+0.06±0.32)	2.64 (−0.15±0.24)	1.72 (+0.21±0.23)	1.33 (+0.33±0.16)
rollforward-vis-pure	3.64 (−1.06±0.32)	2.27 (−0.39±0.20)	1.38 (−0.67±0.26)	0.93 (−0.57±0.21)

1341

든 채 재-pick 턴

19%

그 바람에 놓침(257회)

63%

성공 칸 턴 중 성공 이후

2.4~2.7

첫 성공까지 턴(전략 무관)

갈리는 건 '언제 성공하나'가 아니라 '성공한 뒤 언제 멈추나'다. 첫 성공까지 걸린 턴은 전 전략 2.36~2.74 로 Δ 전부 비유의. 반면 성공 이후 행동량은 vis-pure 만 유의하게 적다. 그리고 든 채 재-pick 1341회 중 257회(19%)는 스스로 들었던 물체를 놓쳤다 — 자기 성공을 자기가 깬다.

3) 완료 인지 플래그 자체는 메모리로 안 갈린다

false_done(.24~.28) · unaware_success(.05~.10) · 예산 초과 — LOO Δ 전부 2·SE 미만. 관측 4장은 전 전략 동일하므로 "손에 들었다"를 못 읽는 건 메모리가 아니라 관측의 한계다.

4) 예상 밖 — 텍스트가 길수록 더 헛짓한다 (textlog 내부 용량-반응)

textlog 201칸	시드 노트	시드 줄	같은 칸 대비 pick 초과
짧은 1/3	711자	5줄	+0.14
긴 1/3	905자	6줄	+2.53

상관 r = +0.203(n=201, t≈2.9). 같은 전략·같은 하네스 안에서 시드 길이만 다른 비교이고, 칸 난이도는 LOO 잔차가 흡수한다.

해석

frames-uniform 과 vis-pure 는 노트 162자·이미지 8장으로 형식이 동일한데 vis-pure 만 유의하게 효율이 높다. 차이는 그 8장이 무엇이냐뿐이다 — 에이전트가 읽기 트랙에서 고른 keep 세트 vs 시간 균등 표본 + 온라인 1장. 종합하면 긴 1인칭 행동 로그는 재조작을 유도하고, 에이전트가 고른 이미지 세트는 줄인다. 온라인 기록 능력이 아니라 시드 메모리의 성질이 실행 효율을 만든다.

기대 vs 실제

전략	기대했던 것	실제
blind	기억이 없으니 가장 많이 반복·맴돌 것	반쯤 — 맴돌기 +0.17·pick +0.39 이지만 전부 비유의(n=81). 예산 초과만 유의하게 낮다(쉬운 칸)
textlog	지금 진행을 못 적으니 재시작할 것	정확히 맞음 — nav +0.37 · 재호출 +0.33 · pick +1.07 · 턴 +1.11 전부 유의. 게다가 길수록 심하다
frames-uniform	온라인 프레임이 섞이니 현재를 보고 멈출 것	틀림 — 1장은 아무 효과 없음. 전 축 중간, 방 재방문만 +0.04 유의(더 헤맴)
rollforward-v3	유일하게 기록하니 반복 최소일 것	절반만 — 맴돌기는 최소(−0.24/−0.20 유의)지만 든 채 재-pick 은 최다(+0.33 유의). 계획을 지우며 진행 상태도 날린다
rollforward-vis-pure	시드 이미지뿐이니 현재를 모를 것	완전히 틀림, 최고 효율 — pick −1.06 · 성공 후 pick −0.67 · 든 채 재-pick −0.57 · 성공 칸 턴 −1.42 전부 유의

9 감사 — 우리가 재려던 execute-state 메모리는 켜져 있었나?

이 트랙이 재려는 것은 실행 중에 바뀐 세계 상태를 메모리 구조에 반영하고 다시 꺼내 쓰는 능력이다 ("2개 중 1개는 끝냈다"를 아는 것). §8 결과를 그렇게 읽으려면 각 arm 이 실제로 그 채널을 가져야 한다. 스냅샷 코드에서 메모리 계약 원문을 재구성하고 실측과 대조했다.

전략	정책	프롬프트가 허용하는 것	실측	판정
blind	`none / none`	아무것도 안 씀	시드 = 계획 1줄, 불변	✅ 대조군 의도대로
textlog	`none / none`	"you do not write anything down … Always return `note`: null" + "you have no way to tick items off"	모델 출력 `note: null`, 최종 노트 = 시드 그대로	❌ 채널 원천 차단
frames-uniform	`none / uniform`	선택권 없음, 자동 표집	온라인 프레임 정확히 1장(235/235) — 그런데 그 1장은 이번 턴 현재 뷰, 즉 관측과 중복	❌ 순증 0
rollforward-v3	`rewrite / none`	매 턴 노트 전체 재작성	88% 재작성, 그중 100%가 계획 줄 삭제, done 체크 1%	△ 구조화 상태 소실
vis-pure	`none / keep`	tagmem 과 글자 그대로 같은 KEEP/DROP 계약	keep 0.12/칸 · 89% 칸이 0장 · seed_left 7.89/8	❌ 열렸으나 모델이 안 씀
tagmem-r3	`append / keep`	"Record what you attempted, what visibly changed, and what is still left to do" + KEEP	온라인 노트 6.6줄/칸, 77% 칸이 완료 문장, 온라인 프레임 87% 칸 ≥1장 — 단 태그화·재검색은 안 함	△ 절반만(쓰기 ✅ / 검색 ❌)

tagmem 온라인 노트 실물 — 실행 상태가 실제로 기록된다 [t=0] Navigating to cup on the floor in the bedroom. [t=1] Picked up the pen from the toilet lid in the bathroom. [t=4] The desk and cup are in the living room (seen in m7), not the bedroom. Navigating to living room floor near cup.

textlog 이 막힌 경위 — 버그가 아니라 철회된 설계 결정

20156b3(260909): textlog 의 온라인 writer = 하네스가 쓰는 oracle 행동 로그로 켰다. 근거 — 읽기 textlog 도 모델이 쓴 게 아니라 생성기 이벤트 로그다.
135778b(같은 날 철회, 사용자 판단): "읽기 GT 로그는 스크립트 에이전트가 성공한 행동이고, 온라인 로그는 이 에이전트의 시도(대부분 실패) + 판정 uid ≠ VLA 가 만진 물체일 수 있다 → 다른 물건이다."
배관은 전부 살아 있다(테스트된 채 꺼짐): WRITER_POLICY["textlog"].notes="oracle" · run_episode(oracle_log=True) · _textlog_line · 프롬프트 계약.

이 감사가 §8 의 해석을 바꾼다

전략	execute-state	n	ΔSR	Δ턴	Δpick
tagmem-r3	✅ 씀	116	−0.022±0.04	−0.76±0.33	−1.14±0.44
vis-pure	❌ 거의 안 씀	265	−0.016±0.03	−0.89±0.29	−0.91±0.29
rollforward-v3	△ 자유서술만	210	−0.001±0.03	+0.39±0.29	+0.21±0.33
frames-uniform	△ 1장	222	−0.004±0.03	+0.09±0.34	+0.19±0.34
textlog	❌ 못 씀	212	+0.031±0.03	+0.79±0.30	+1.16±0.34
blind	— 대조군	81	+0.013±0.05	+0.69±0.52	+0.51±0.54

execute-state 를 쓰는 tagmem 과 거의 안 쓰는 vis-pure 가 동률이다. 따라서 현재 데이터로는 "execute-state 메모리가 효율을 만든다"를 주장할 수 없다 — 6개 arm 중 4개가 채널이 없거나 안 쓰는 상태라 대조 자체가 성립하지 않는다. §8 의 "vis-pure 가 가장 효율적"은 "온라인에 거의 아무것도 안 쓰는 arm 이 이겼다"로 읽어야 한다.

그리고 find 는 원리적으로 execute-state 가 거의 필요 없는 과제다. 단일 질의 = navigate 1 + pick 1 이라 기억할 중간 상태가 없다. 사슬이 2단계 이상인 곳에서만 물린다 — find multi 는 30칸뿐(SR .267), restore 는 전 칸이 pick→carry→place 2단계(지금 본 런 진행 중), routine 은 다물체. find 에서 신호가 안 나온 건 하네스 결함이 아니라 과제 선택의 문제이기도 하다.

추가 확인 2건 — "배선이 막힌 건 textlog 뿐"이지만 "나머지가 잘 된다"는 아니다

① frames-uniform 의 온라인 writer 는 정보를 0 추가한다. ep.n_steps(1만+) 대비 온라인 프레임이 6장 남짓이라 linspace 의 마지막 인덱스 하나만 온라인 구간에 떨어지고, 그건 항상 이번 턴의 현재 뷰다. 그런데 현재 뷰는 이미 관측으로 전 전략에 매 턴 주어진다 — 즉 메모리 기여분이 관측의 중복이다. 균등 규칙의 충실한 번역이라 버그는 아니지만, "온라인 상태를 기억한다"는 축에서는 blind 와 같다.

② tagmem 은 온라인에서 태그화도 재검색도 하지 않는다 — 절반만 작동. retrieve()·query_tags() 는 seed_memory() 안에만 있고 그 함수는 단 한 번 호출된다(online.py:538). 온라인 노트는 평문으로 append 될 뿐 태그 엔트리가 되지 않고 검색 대상도 아니다 — 지금 tagmem 의 온라인 쓰기는 사실상 rf-v2(naive append)와 같은 메커니즘이고, tagmem 의 정체성인 "태그 구조 + 질의 시점 검색"은 온라인 구간에서 한 번도 실행되지 않는다. find(6턴)에서는 전량이 프롬프트에 들어가 실질 손해가 없지만, restore·routine 처럼 턴이 길어지면 누적 기록이 검색 없이 통째로 들어가 "전부 기억하는 메모리"가 된다 — 읽기 트랙에서 고쳤던 바로 그 결함이다.

결정 4건 — 사용자 회신 반영 (260920)

A 보류 · B 진행 · C 진행 · D 진행 (사용자 결정). D 구현 완료(테스트 8건 통과), B 짝지은 16칸 × 2팔 제출(잡 140189/140190, 예상 $2.77), C 배선 완료(--family restore), A 는 260909 결정 유지 — 논문에서 textlog 은 "execute-state 채널 없음" arm 으로 명시한다.

A. textlog 의 oracle 로그 복원 여부 — 복원하면 textlog 가 행동 메모리의 오라클 상한 지위를 되찾는다 (읽기 단계에서의 역할과 동일). 로그의 (holding X)가 바로 "끝냈는지" 신호다. 260909 반론(실패 위주·uid 불일치)에 대해서는, _textlog_line 이 에이전트가 지목한 대상 + 판정 결과 + 실제 held 상태를 쓰므로 "무엇을 시도했고 어떻게 됐다"는 정확하다. 다만 (holding X)는 GT 누출이라 오라클 arm 인 textlog 에만 허용해야 한다. 권고했으나 사용자 결정으로 보류 — 260909 결정 유지. 논문에서 textlog 은 "execute-state 채널 없음" arm 으로 명시.

B. vis-pure 의 KEEP 억제 원인 규명(API 필요, 40칸 ≈ $3) — 계약 원문은 tagmem 과 동일함을 확인했으므로 누락이 아니라 모델 행동이다. 유력 가설 둘: ① 메모리가 시드 8장으로 꽉 차 KEEP 하려면 자기가 고른 읽기 프레임을 반드시 버려야 한다 ② 노트 채널이 없어 "기록하는 자세"가 안 생긴다(tagmem 은 같은 8장 꽉 참인데 1.56장 보관 → ②가 더 유력). 채택 가능한 개입은 프롬프트 한 문장 명료화뿐(예산·규칙 불변). 진행 중 — SBENCH_KEEP_EVICTION_NOTE(기본 끔) 추가, 짝지은 16칸 × 2팔 제출(140189/140190). A팔 프롬프트가 본 런과 바이트 동일함을 확인했고, KEEP 기회 117턴/팔 · 기준선 online_kept ≥1 3/16칸 · 예상 $2.77.

D. tagmem 온라인 쓰기를 태그 엔트리로 만들고 재검색할 것인가 — 그래야 온라인에서도 tagmem 이 tagmem 이다. 비용은 거의 0(retrieve 가 client 를 쓰는 건 r2 0히트 폴백 1회뿐). 권고: "온라인 기록이 예산을 넘을 때만 검색 발동"이라는 한 규칙 — find 는 현행과 완전히 동일하고(6턴이라 예산 미달), 긴 가족만 자동으로 올바르게 동작한다. 가족별 분기 불필요. 구현 완료 — note_entry()(태그는 읽기와 같은 결정론 태거, 추가 API 0) · TagmemNoteSelector(예산 초과 시 retrieve(always_tail=3)) · run_episode(note_selector=), 테스트 8건. 예산 초과 칸 = find 13% · restore 46%. 쓰인 줄은 notes_final 에 전량 보존 — 줄어드는 건 프롬프트에 보이는 것뿐. 진행 중이던 tagmem find 런은 보류(139962 hold, babysitter 정지) — 재측정 302칸 ≈ $26(순증 ≈$10) 승인 대기.

C. execute-state 의 주 무대를 restore·routine 으로 명시 — 추가 비용 0. restore 본 런이 끝나는 대로 같은 LOO 효율 분석을 적용한다(aggregate_online_efficiency.py --family restore, 배선 완료).

10 실패 사례 요약 (원문 · 원인 · 교훈)

① false_done — 184a006604d1 (vis-pure, "Pick up the bowl")
계획 원문 pick up the bowl — on the dining table in the kitchen (정답). t1 navigate 적중 → pick 1회 → t2 done. 그릇은 그대로.
원인: pick 결과를 관측으로 확인하지 않고 "시도했으니 됐다"로 넘어간다. 관측 타일에서 그릇이 작아 판별이 어렵다.
교훈: 완료 판정을 모델의 done 에만 맡기면 25%가 거짓이다 — 이 수치 자체가 벤치마크의 측정 대상.

② unaware_success — 1111ac0bb213 (vis-pure, 화병)
t2 성공 후 20턴 더 pick 21회, done 없음, 턴 상한 종료.
원인: 손에 든 물체를 관측에서 인식하지 못하고, 계획 체크 수단도 없다.
교훈: SR 은 성공으로 세지만 예산의 91%를 낭비했다. 전체 턴의 30.4%가 이 낭비다.

③ 파지 실패 — 0f2f74931cb9 (rf-v3, 휴대폰)
계획 정답, 스폰부터 reach 안이라 navigate 0회, pick 12회 전부 실패.
원인: VLA 파지 품질 — 얇고 낮은 물체 + 침대처럼 푹신한 표면.
교훈: 실패의 84%가 여기다. 메모리 연구의 결론을 흐리지 않으려면 종단 SR 과 계획 정답률을 반드시 분리 보고해야 한다.

④ 쌍둥이 셀 — v1_train_2102__1 "Pick up the remote control I moved earlier"
blind · frames-uniform · vis-pure 세 전략이 모두 같은 3턴 · pick 2회 · 실패 궤적. 답은 셋 다 "living room dining table"로 같고, 씬에는 같은 카테고리 리모컨이 둘 있다.
교훈: 쌍둥이 셀 224칸(.438 vs .611)은 전략이 아니라 과제 난이도 축이다 — find S1 = 인스턴스 구별이라는 기존 관찰과 일치.

11 Takeaway · 다음

온라인 실행 층은 메모리 전략과 무관하다. 난이도만 맞추면 전 전략이 .52~.63 동률.
종단 SR = 읽기 × .58 로 요약된다. 읽기 트랙이 병목, 실행은 고정 계수처럼 작동.
완료 인지는 새 측정축으로 값어치가 있다 — false_done 25%, 낭비 턴 30.4%, 전략 무관.
계획 메모리 설계는 현재 형태로는 비어 있다 — 4전략은 구조적으로 못 고치고 rf-v3 는 지운다.

restore 본 런 진행 중 — 8샤드 제출(139954~139961), own 8 GPU 캡을 tagmem 온라인 2잡·v13 읽기 3잡과 나눠 쓰는 중이라 s0만 RUNNING. tagmem restore 는 다른 세션이 진행하므로 제외.
tagmem find 온라인 s0 진행 중(302칸 중 124).
사용자 결정 대기: ① 쌍둥이 셀 224칸 제외 여부 ② 관측 이미지 폭(half→full) ③ tagmem 온라인 시드 정의(검색 기반 vs 장부 전체).

원천: final_results/online_plan_v1_260920/ (PROVENANCE.md · tables/online_find.md · rows/ 1108행 · summary_find.json) 작업 로그: claude/260920/analysis-online_plan_find_main.md 집계: python3 scripts/aggregate_online_main.py --family find --read-merged .../merged.json --out-dir final_results/online_plan_v1_260920

온라인 계획형 본 런 — find 가족 1108칸 완주 분석