2026-06-24 · Scene-Mem API track
메모리는 어떻게 저장되고 → 어떤 회상 결과로 이어지나
gemini-3.5-flash · recall-report · control / M1 / M2 / M3v2 · 저장 구조 시각화 + forced-M2
TL;DR — 저장 충실도가 회상을 결정한다
- control 저장 없음 · M1 전체 균일 8샘플 · M2 중요 keyframe 보관 · M3v2 append 텍스트 로그.
- M2(keyframe) 최고 — 중요 순간을 골라 보관 → 회상됨. 단 긴 에피소드선 8-cluster eviction으로 급락(combo_002 0.44 → 다양12 0.18).
- M2 병목 = sparse nomination: 모델이 walk 대부분에서 keyframe를 안 골라 8칸 중 3~5칸만 참 → forced-M2로 5.3→12.6칸 채움.
- forcing은 소폭 개선(place_acc 0.179→0.23) 하지만 fallback 프레임이 노이즈로도 작용. 절대정확도는 여전히 낮음(상식누수+마지막프레임 anchor).
1메모리가 어떻게 저장되나 (메서드별)
같은 에피소드(combo_002 steak, 8분/11세그먼트)에서 각 메서드가 회상 시점에 들고 있는 메모리:
control
저장 없음 — 현재 프레임만. (회상 근거 0)
M1
에피소드 전체를 균일 8샘플. 아래 strip: steak 세그먼트(0~724)엔 idx 0 하나만 걸려 배치 순간 놓침.
M1 = 전체 균일 8장. 8분을 8장으로 → 초반 배치(460~640)가 샘플 사이로 빠짐.
M2
모델이 지목한 중요 keyframe 보관. 아래: idx 460·640 = steak 세그먼트 내부(배치 순간)를 잡음.
M2 = 선별 keyframe. seg0 내부 460·640 보관 → M1보다 회상 유리. (단 fridge/freezer 시각 모호로 'fridge' 오답)
M3v2
매 세그먼트 emit한 raw subtask를 append 로그. 그런데 walk가 세그먼트당 1콜이라 마지막 행동만 기록:
1. Close the fridge door
2. Navigate to the cabinet
3. Close the cabinet door
4. Navigate to the oven
5. Slide the tray back inside the oven
6. Navigate to the stove
7. Turn on the front left burner on the stove
8. Navigate to the cabinet
9. Pick up the spoon from the counter
10. Navigate to the sink
11. Place the cup in the sink
M3v2 로그에 steak 배치가 없다. 1번이 "Close the fridge door" — 즉 steak 세그먼트(seg0)에서 모델이 emit한 건 placement가 아니라 그 다음 동작(walk 자체의 over-advance). 누적은 하는데 잘못된 1줄을 누적 → 회상 실패.
2회상 결과 — 저장 충실도 순서대로
combo_002 (짧은 에피소드, 3 시나리오)
| method | place_acc | action | cost |
|---|---|---|---|
| control (저장 없음) | 0.000 | 0.667 | $0.74 |
| m3 (MEM 덮어쓰기→망각) | 0.000 | 0.667 | $0.77 |
| m1 (균일샘플) | 0.222 | 0.444 | $1.37 |
| m3v2 (append 로그) | 0.222 | 0.889 | $0.81 |
| m2 (keyframe 보관) | 0.444 | 0.778 | $0.95 |
다양12 (긴·다양 에피소드, 12 패밀리)
| method | place_acc | action | cost |
|---|---|---|---|
| control | 0.051 | 0.564 | $3.28 |
| m1 | 0.051 | 0.744 | $6.32 |
| m3v2 | 0.077 | 0.821 | $3.59 |
| m2 (keyframe) | 0.179 | 0.769 | $5.38 |
M2 최고 일관 (보관형이 이긴다). 짧은 에피소드 0.44, 긴 에피소드 0.18 — 둘 다 1등.
긴 에피소드에서 M2 급락(0.44→0.18). 8분짜리는 클러스터가 8개를 넘어
reps[-8:]가 초반(steak)을 evict → 보관해도 못 들고감. M1은 다양12서 control과 동급(0.05)으로 무용.3M2의 병목 = 저장이 비어있다 (sparse nomination)
M2는 모델이 walk마다 keyframe를 지목해야 채워지는데, recall walk는 세그먼트당 1콜(=11콜)이고 모델이 대부분 [](없음)을 냅니다. 그래서 8칸 중 3~5칸만 차는 경우가 흔함.
용량이 아니라 '안 고르는 것'이 문제
오프라인 worst-case(모델이 항상 [])에서 non-forced M2 저장 = 0장. 즉 메모리가 텅 빌 수 있음. 회상이 될 리가 없죠. → "무조건 찍게(force)" 하면?
4forced-M2 — 무조건 찍게 + cap 상향
--m2-force: 모델이 아무것도 안 찍은 콜이면 fallback으로 윈도 중앙 프레임 강제 지목(세그먼트당 ≥1) + 보관 cap을 8→16으로 올려 초반 evict 방지.
같은 에피소드(combo_015) 저장 비교. 위=non-forced 4장(성김, 오른쪽 빈 공간=후반 통째 누락). 아래=forced 11장(에피소드 전체 고르게 채움).
| place_acc | 저장 keyframe 평균 | |
|---|---|---|
| non-forced M2 | 0.179 | 5.3칸 |
| forced M2 (cap 16) | 0.231 | 12.6칸 |
풀 다양12, n=39 (확정). forced helped 5 / hurt 3 (net +2). cost ~$6.4.
작동은 한다. 메모리 5.3→12.6칸, place_acc 0.179→0.23(+50% 상대). 사용자 직감(보관하면 회상된다) 방향 맞음.
그러나 양날. glass cup은 forced가 맞춤, bowl→cabinet은 non-forced가 맞던 걸 forced가 틀림 — fallback 중앙프레임이 항상 '배치 순간'은 아니라 노이즈로도 작용. 순(net) 소폭 개선이지 만능 아님.
5정직한 한계 & 정석 다음
cap 8 → 16은 deviation. 원래 MemER keyframe 상한은 8. forced에서 16으로 올린 건 초반 evict 방지용 — "force nomination"과 "메모리 예산 증가"가 혼재됨. 정석 = cap 8 유지 + 선발을
reps[-8:](최근편향) 대신 시간상 분산(초반+중반+말)으로 바꿔 8장 안에서 초반 보존.절대정확도는 여전히 낮다(0.25). steak→상식누수(fridge로 찍음), bowl→마지막프레임 anchor(sink). 메모리 외 교란이 천장 → 상식차단(강제선택/반상식 배치) + STATE anchor 제거가 남은 조각.
다음
(1) 분산선발 cap=8, (2) 상식차단 질의(사용자 task), (3) 마지막프레임 STATE 제거, (4) 풀 다양12 forced 확정.
data: results/gemini-3.5-flash__*__{full,val}__recall__report*.json · code: --recall-style report, --m2-force · 로그: claude/260623/analysis-m3_overadvance_leadup_fix.md