TL;DR
- 유예→도착→재식별 루프가 닫힌다 — 신규 지표
id_recovered 최초 측정, 메모리 arm 전부 5~6/6. N12에서 관측조차 불가능했던 축이다
- 메모리는 오지목을 없앤다 — notes 계열 18 trial wrong 0, blind는 6/6 wrong. 정보가 없으면 모델은 기권하지 않고 확신에 찬 오답을 낸다
- 불확실 표기 강제가 거짓말을 없앴다 — 실패한 서브골을 노트가 완료로 적는 비율 100% → 0% (notes v1 5/5 → notes-v2 0/2)
- 오라클의 절차 함정 재현 — textlog 절차 2/6로 최하(notes 계열 5~6/6), 심지어 오지목 1건 발생. 오라클은 정보 가용성의 상한일 뿐
- 수정 2건: 방 앵커 단일 후보 → 순차 시도, 그리고 신규 실패 모드 plan-exhaustion done("계획 소진=과제 완료"로 오판) 차단
1 지표를 왜 고쳤나
N12의 object_id_match는 첫 결정에서 정확한 id를 말했는가만 봤다. 그래서 navigate(room)으로 "가서 확인하겠다"고 유예하는 — 설계가 의도한 가장 배포-정합적인 — 행동이 오답과 똑같이 감점됐다. 게다가 도착 후 실제로 id를 되찾는지는 에피소드가 1서브골이라 관측 자체가 불가능했다.
| 지표 | 정의 |
|---|
id_outcome (3범주) | correct 정확한 id 지목 / deferred room 경로로 식별 유예 / wrong 틀린 id 지목 |
id_recovered (신규) | max_subgoals≥3으로 연장해 도착 후 실제로 정확한 id를 회수해 행동했는가 |
procedure_match | 유지 (먼저 그 방으로 갔는가) |
2 결과 (2씬, n=3/arm)
| arm | correct | deferred | wrong | procedure | id_recovered |
|---|
| blind (하한) | 0 | 0 | 6 | 0/6 | 0/6 |
| notes | 4 | 2 | 0 | 5/6 | 6/6 |
| notes-v2 (불확실 강제) | 2 | 4 | 0 | 6/6 | 5/6 |
| notes-stepwise | 2 | 4 | 0 | 5/6 | 5/6 |
| textlog (오라클) | 5 | 0 | 1 | 2/6 | 6/6 |
핵심: 메모리를 가진 arm은 단 한 번도 틀린 물체를 지목하지 않았다(18 trial, wrong 0). blind는 6/6 전부 엉뚱한 물체를 확신하며 지목했다. 그리고 유예한 경우에도 도착 후 5~6/6으로 실제 회수한다 — "기억하고, 가서, 다시 확인하고, 행동한다"는 배포 시나리오가 실측으로 성립했다.
3 write-phase — 불확실 표기가 거짓말을 없앴다
| arm | 실패한 서브골 | 노트가 "완료"로 오기록 | 비율 |
|---|
| notes (v1 프롬프트) | 5 | 5 | 100% |
| notes-v2 (결과 단정 금지 + 불확실 표기 + 시점 표기) | 2 | 0 | 0% |
오기록 원문 (v1, 실제로는 실패한 서브골):
"Picked up the cooking pan from room_6 and placed it onto the bed in room_2."
"Picked up the cooking pan [cookingpan_d667247d94068c4177c8ed800f8c264f_1_0_6] from room_6
and placed it onto the bed [bed_aed5602affd158c34e7eda83481a...]"
부수 효과가 일관적이다: v2는 더 자주 유예하고(4/6) 절차 점수가 최고(6/6)다. "확신 없으면 단정하지 말고 미뤄라"는 지시가 기록·행동 양쪽에 같은 방향으로 작동했다. 단 표본이 작다(실패 서브골 v1 5건 / v2 2건) — 더 많은 실패 상황에서 재측정 필요.
4 실패 사례 · 수정 2건
P1. plan-exhaustion done 수정 완료 신규 실패 모드
현상: navigate(room) 성공으로 도착했는데 다음 턴에 planner가 done 선언.
원문: "The previous subgoal 'navigate' succeeded, and all steps in the plan have been
executed. The task is now complete."
원인: plan-first가 **계획 소진 = 과제 완료**로 처리 → 도착해서 새로 보이게 된 물체를
계획에 넣지 않음. F4(done-escape)와 같은 계열이나 원인이 다름(압박 회피 아님).
수정: done 정의를 "사용자 목표 충족"으로 명시 + 유예 스텝은 도착 후 plan 확장 유도.
수정 직후 스모크에서 id_recovered False → True 전환 확인.
P2. 방 앵커 단일 후보 수정 완료
현상: navigate(room)이 실패 — PLACE_ROBOT_NEAR "No free points found" (house 290 dining table)
원인: resolve_room_anchor가 앵커를 하나만 선택 → 그 가구 주변에 여유가 없으면 방 전체 실패
수정: 후보 순차 시도(receptacle 우선, 결정론 유지), 성공 앵커·시도 횟수 기록
의미: id_recovered가 "앵커 뽑기 운"에 오염되지 않게 하는 전제 조건이었다
P3. 오라클의 오지목 1건 주의
GT 로그를 받은 textlog arm에서도 wrong 1건이 나왔다 — 완전한 정보가 곧 완전한 행동은 아니다. 절차 2/6와 함께, "오라클 = 상한"이라는 가정을 축별로 재검토해야 할 근거가 하나 더 늘었다.
5 판단과 다음
판단
이번 라운드로 배포형 메모리의 전 구간이 측정 가능해졌다: 무엇을 기억했나(id_outcome) → 어떻게 행동했나(procedure) → 실제로 되찾았나(id_recovered). 그리고 병목으로 지목했던 write-phase는 프롬프트 한 번 고쳐서 오기록 100%→0%가 됐다 — 메모리 품질이 모델 능력만의 문제가 아니라 기록 규약 설계의 문제라는 뜻이고, 벤치마크가 다룰 변수로서 훨씬 흥미로운 결과다.
| # | 다음 |
|---|
| 1 | 표본 확대(n=6 → 그 이상) + 씬 다양화로 v2 효과와 오라클 역전 재확인 |
| 2 | 실패 상황을 더 많이 만드는 시나리오에서 오기록률 재측정(현 v1 5건/v2 2건은 소표본) |
| 3 | frames(이미지 메모리) arm 추가 |
| 4 | VLA 결합 — 실조작 성공률과 메모리 품질의 상호작용(카메라 zed2 기준) |