--recall-walk fine · diverse12 (12 에피소드 / 39 recall task)m3v2 0.564 ≫ m2 0.179 > m1 0.077 > control 0.026 (place_acc). 텍스트 로그가 시각 keyframe의 3.1배.m3v2는 39개 중 22개 정답, 그중 14개(=전체 36%)를 혼자 맞춤. m2가 혼자 맞춘 건 단 1개.m3v2 로그는 평균 23.5줄(거의 모든 fine-subtask를 사실로 기록) vs m2는 평균 5.4장의 keyframe(cap 8) — ~23개 이벤트를 5장 이미지가 못 담는다.control "counter", m1 "fridge", m2 "stove", m3v2 "freezer" ✓. 이미지 메서드는 상식/최근장면으로 추측, 텍스트는 로그에서 조회.m3v2가 최저비용($6.2 vs m1 $11.9 / m2 $10.4) — 텍스트는 context에 이미지를 안 붙여 토큰 절반.회상(--target recall) 모드: 전 에피소드를 한 번 순회하며 메모리를 누적(Phase 1)하고, 에피소드당 recall task 3개가 그 메모리를 공유해 "그 물건 어디 뒀어?"를 답한다(Phase 2). 이번 스윕은 누적 walk를 --recall-walk fine(세그먼트를 fine-subtask 단위로 쪼개 leadup 윈도로 observe)로 고정하고 4개 메모리 메서드를 비교한다.
채점 place_acc = 회상 답의 물건+장소가 GT 배치와 일치한 비율. m3v2=append 텍스트 로그, m2=모델이 지목한 keyframe 이미지를 re-cluster해 최근 8개 노출.
| method | 메모리 | place_acc | slot_acc | action_acc | exact | 비용 |
|---|---|---|---|---|---|---|
| m3v2 | subtask 텍스트 로그 | 0.564 | 0.282 | 0.923 | 0.128 | $6.20 |
| m2 | keyframe 이미지 (MemER) | 0.179 | 0.077 | 0.667 | 0.000 | $10.42 |
| m1 | 균일 history 이미지 | 0.077 | 0.026 | 0.641 | 0.000 | $11.92 |
| control | 없음 | 0.026 | 0.000 | 0.564 | 0.000 | $6.20 |
각 task마다 4개 메서드의 정/오답 패턴을 집계하면, m3v2가 혼자 정답인 경우가 압도적이다:
| 패턴 (control · m1 · m2 · m3v2) | 건수 | 해석 |
|---|---|---|
| ✗ · ✗ · ✗ · ✗ | 15 | 아무도 못 맞춤 (남은 한계 — §5) |
| ✗ · ✗ · ✗ · ✓ | 14 | m3v2만 정답 (전체의 36%) |
| ✗ · ✗ · ✓ · ✓ | 5 | m2 + m3v2 |
| ✗ · ✓ · ✗ · ✓ | 2 | m1 + m3v2 |
| ✗ · ✓ · ✓ · ✓ | 1 | control 빼고 전부 |
| ✗ · ✗ · ✓ · ✗ | 1 | m2만 정답 (텍스트의 실패 — §5) |
| ✓ · ✗ · ✗ · ✗ | 1 | control만 (노이즈/우연) |
m3v2 정답 22개 = 혼자(14) + m2동반(5) + m1동반(2) + 전체(1). m2가 m3v2 없이 단독으로 기여한 건 단 1건. 즉 시각 메모리가 텍스트 위에 더해주는 정보가 거의 없다 — m3v2가 m2를 거의 완전히 포함(superset)한다.m3v2만 맞춘 14개의 전형. 같은 회상 질문에 메서드별 답:
| 회상 질문 (GT) | control | m1 | m2 | m3v2 |
|---|---|---|---|---|
| steak 어디? freezer | counter | fridge | stove | freezer ✓ |
| shrimp/bowl 어디? microwave | counter | counter | sink | microwave ✓ |
| fish 어디? oven | counter | oven(hedge) | counter | oven ✓ |
이미지 메서드는 배치를 못 봐서 상식으로 추측(steak→fridge)하거나 최근 장면에 끌린다(→counter/sink). m3v2는 walk 중 만든 텍스트 로그에서 해당 줄을 조회한다. 위 fish 예의 실제 m3v2 메모리 로그(25줄 중 발췌):
m1은 "in/on the oven"이라 장소는 맞았으나 "in/on" 헤지로 slot-match 실패(m3v2의 깨끗한 "on the oven"은 통과). 일부 m3v2 우위엔 이런 표현-포맷 효과가 섞여 있다. 그러나 steak(→fridge/stove로 장소 자체가 틀림)·microwave(→counter/sink) 같은 다수 사례는 순수하게 장소 오답이라 포맷 효과가 아니다.m2(MemER keyframe)는 fine walk로 nomination 기회가 늘었는데도 place_acc가 coarse와 동일(0.179)했다. 메모리 적재량을 보면 이유가 명확하다:
한 에피소드 ~23개 fine-subtask를 m3v2는 23.5줄로 거의 전부 담지만, m2는 8칸 cap + 최근편향 re-cluster eviction으로 평균 5.4장만 남긴다. 게다가 그 5.4장은 이미지라 회상 시 모델이 다시 인식해야 한다(텍스트는 이미 명제로 박제됨). 즉 m2의 병목은 walk 입도가 아니라 (a) 8-slot 용량 + (b) 회상 시 이미지 재인식 부담 — fine walk로는 못 푸는 구조적 한계.
fine walk로도 절대값은 0.564. 전부 실패한 15개의 실패 양상:
| 유형 | 예 (GT → m3v2 오답) | 원인 |
|---|---|---|
| 희귀 fixture 어휘 | bagel/baguette → toaster oven (m3v2 "counter"/"oven") | "toaster oven"을 모델이 "oven"/"counter"로 기록 — 어휘 불일치 |
| RestockBowls 데이터 | bowl → cabinet (m3v2 "sink"/"microwave") | 알려진 tfi 데이터 이슈 + 동일 물건 다중 배치 혼동 |
| 텍스트 조회 오선택 | bowl → microwave (m2만 정답, m3v2 "in the bowl") | 로그에 유사 물건의 중간 배치가 여러 줄 → 엉뚱한 줄 조회 |
m3v2가 엉뚱한 줄을 조회한다("bell pepper in the bowl" vs 정답 "in the microwave"). 시각 keyframe은 이 경우 마지막 장면을 직접 봐서 맞췄다. 드물지만(1/39) 텍스트 회상의 구조적 약점.올바른 누적 walk(fine + leadup) 하에서 subtask 텍스트 로그가 시각 메모리를 3.1배 압도하고, 시각 메모리가 추가로 기여하는 정보는 거의 없다(m3v2가 m2를 superset). 핵심은 정보밀도 — 텍스트는 ~23개 사건을 명제로 박제해 조회 가능하게 만들지만, 8-slot keyframe은 ~5장에 압축되며 회상 시 재인식 부담까지 진다. 비용도 텍스트가 최저. ⇒ 이후 open-VLM 튜닝/ours 설계의 메모리 기본선은 텍스트 로그로 가는 게 맞다.
m3v2 @ n=39 미보유(단일 combo_042 0→0.667만 직접 A/B). 필요시 ~$6로 보강.