SceneMem API 트랙 — 전체 진행 정리

한눈에

출발점: 메모리 메서드 3개를 돌렸는데 결과가 이상했다. 원인은 메서드가 아니라 측정 파이프라인이었음 — 3중의 버그를 순차적으로 찾아 수정.
수정 ① 회상 질의에 "다음 행동"을 답하던 문제 → --recall-style report (과거 배치 보고로 프레이밍)
수정 ② 채점/누적 윈도가 한 스텝 앞서가던 over-advance → --state-align leadup, --recall-walk fine
수정 ③ 모델이 템플릿의 "in/on"을 그대로 출력해 정답이 오답 처리되던 파서 버그 → 정규식 수정
새 메서드 ours(tagged-keyframe + 검색) 구현 → 시각 메모리 계열 최고 성능(m2 0.308 → ours 0.462, +50%). 다만 텍스트 로그(m3v2 0.564)엔 아직 못 미침.

0.564

m3v2 (1위)

0.462

ours (2위)

+50%

ours vs m2

n=39

diverse12 회상 task

커밋

⚠️ 먼저 읽을 것 — 이 수치는 구 858 데이터셋 기준

이 문서의 모든 측정은 858-시나리오 벤치마크에서 나온 것이다. 그 뒤(2026-07-27) HF Keh0t0/scene-mem-benchmark가 879-시나리오 릴리즈로 교체됐고, 현재 디스크 상태는 이렇다:

항목	현재 상태	의미
시나리오 수	`list_scenarios()` = 879	데이터셋이 이미 교체됨
`fine_subtasks.json`	없음 (신규 시나리오)	`--recall-walk fine`·회상 GT가 이 파일에 의존 → 현재 재현 불가
diverse12 (측정 셋)	12개 중 9개만 ID 존재	남은 9개조차 영상이 100% 재생성돼 구 측정치 이식 불가

따라서 아래 순위·수치는 "방법론적 결론"으로 읽어야 하고, 현 데이터셋의 성능 수치가 아니다. 실질 이행 블로커 = fine annotation 재생성. 그 전까지 새 스윕은 돌릴 수 없다. (상세: 같은 폴더 260727-benchmark_879_resync.html)

반면 코드 수정(3개 버그 fix)과 ours 구현은 데이터셋과 무관하게 유효하다 — fine annotation만 복구되면 그대로 재측정 가능.

0 이 프로젝트가 뭐였나 (맥락 복원)

목표: RoboCasa 기반 벤치에서 "로봇이 ~8분짜리 영상으로 여러 task를 수행한 뒤, 메모리를 반영해 올바르게 답하는 능력"을 측정. 로드맵은 API 트랙(현재) → Open-VLM 튜닝 → ours. (측정 당시 858 시나리오 → 현재 879로 교체됨, 위 경고 참조)

측정 방식 2가지가 있었는데, 이번에 하나는 폐기하고 하나만 유효화했다:

모드	내용	판정
next-subtask	타깃 시점의 "다음 할 일" 예측	폐기 GOAL 텍스트에 정답이 그대로 들어있음(recipe leak) → 메모리 없이도 풀림 = 인지/지시수행 과제
recall	에피소드 끝에 "그 물건 어디 뒀어?" 질의	유효 과거 사건을 기억해야만 답 가능 = 진짜 메모리 측정

비교 대상 메서드(이 부분만 서로 다름): control(메모리 없음) · m1(과거 프레임 균일 샘플) · m2(MemER keyframe) · m3v2(수행한 subtask 텍스트 로그) · ours(이번에 새로 만든 것).

1 여정 — 무엇이 망가져 있었고 어떻게 고쳤나

① 증상: "메모리 3개를 같이 돌렸는데 뜻대로 안 나온다"

텍스트 메모리(M3)가 특히 이상. 사용자 가설 = "메모리에 Now closing the freezer 같은 게 들어가서 계속 틀리는 것 같다".

② 진단: 메모리 탓이 아니라 over-advance(창이 한 스텝 앞서감)

채점 대상 프레임 창의 마지막 프레임에 이미 동작이 완료돼 있어서, 모델은 자연히 "그 다음 동작"을 답함. 결정적 증거: 메모리가 아예 없는 control도 똑같이 앞서감(control vs m3 예측 80% 동일).

③ 수정 A: `--state-align leadup`

채점 창을 한 fine-step 앞으로 당겨 "동작 직전" 장면을 보게 함.

→ control 슬롯 정확도 0.000 → 0.800 (짧은 셋). 원인 확정.

④ 수정 B: `--recall-style report`

회상 질의인데 시스템 프롬프트가 "다음 행동을 내놔"라서, "steak 어디 뒀어?"에 "냉장고로 이동"이라 답하고 있었음. 회상 전용 프롬프트로 과거 배치를 보고하게 변경.

→ 출력 형식이 바뀌며 회상 채점이 비로소 가능해짐(action 정확도 0 → 0.67).

⑤ 진단 2: 회상용 메모리 누적도 깨져 있었다

누적 walk가 coarse 세그먼트당 1콜이라, 한 세그먼트(이동→집기→놓기→닫기)가 1줄로 뭉개지고 그 1줄마저 over-advance. 실제로 M3v2 로그 1번 줄이 "Close the freezer door" — 배치 사건이 기록조차 안 됨.

⑥ 수정 C: `--recall-walk fine` (fine-subtask 단위 + leadup)

세그먼트를 K개 fine-subtask로 쪼개 각각 관측. 로그가 "1줄/세그먼트" → "1줄/fine-subtask"로.

→ 같은 에피소드 M3v2 로그 1번 줄이 "Place the bottled water in the freezer"로 교정. place 정확도 0.00 → 0.667. 콜 수는 2.18배.

⑦ 새 메서드 `ours` 설계·구현 (아래 §2)

M2처럼 keyframe을 고르되 태그(물체/장소/행동)를 붙여두고, 회상 때 질문에 맞는 태그를 검색해서 답하는 방식.

⑧ 막판 발견: 채점 파서 버그 (모든 메서드 영향)

프롬프트 템플릿이 "Place the <obj> in/on the <place>"인데 모델이 "in/on"을 리터럴로 출력 → 파서가 슬래시를 연결어로 인식 못 해 action=other로 처리 → 정답을 오답 처리.

→ 정규식 수정 후 재채점: m2 0.179→0.308, control 0.026→0.154. (m3v2는 무변 — 로그에서 깨끗한 문장을 읽어 헤지를 안 함)

교훈: "메모리 방법 비교"를 하기 전에 측정 파이프라인이 메모리를 실제로 요구하고, 정답을 정답으로 채점하는지 검증해야 한다. 이번 3개 버그는 모두 메서드 순위를 바꿀 만큼 컸다.

2 `ours` — 어떻게 동작하나

아이디어: 시각 메모리(m2)는 "8장 이미지"라 용량이 작고 회상 때 다시 인식해야 하는 부담이 있다. 텍스트 로그(m3v2)는 정보가 촘촘하지만 인덱스가 없어 비슷한 줄이 쌓이면 엉뚱한 걸 조회한다. 둘을 합치자 — keyframe을 고르되 구조화 태그를 박제하고, 회상 때 검색한다.

① SELECT walk 중 모델이 기억할 프레임 지목 (M2/MemER 방식, 이미지 예산 8장) ② TAG 같은 콜에서 그 프레임의 태그를 함께 출력 (fused) {objects:[모든 보이는 물체], place: 장소, action: 행동} ③ RETRIEVE 회상 질문의 물체와 매칭되는 태그 검색 → 최신순 top-3 → 태그 텍스트 + 그 keyframe 이미지를 근거로 답변

설계 중 바뀐 것 — "캡션을 언제 다나"가 성패를 갈랐다

처음엔 walk가 끝난 뒤 보존된 keyframe을 따로 캡션했다. 그런데 정지 프레임 한 장만 보니 동작 판정이 틀렸다 — steak를 freezer에 넣는 장면을 place=fridge, action=open으로 오라벨. 그래서 walk 콜 안에서 선택과 태깅을 동시에(fused) 하도록 바꿨다. 모션이 보이는 창에서 판단하니 교정됐다.

	사후 캡션 (초안)	fused 선택+태깅 (최종)
steak 태그	fridge / open ✗	freezer / place ✓
태그 수 (1 에피소드)	6	16
API 콜	39	33 (별도 캡션 콜 제거)

실제로 저장된 태그 (모델이 본 3-cam 합성 프레임)

[t] objects=[cup] place=microwave action=place
열린 전자레인지에 컵을 넣는 순간. "컵 어디 뒀어?" 질의가 이 태그를 검색 → 정답 (m3v2는 이 문제를 틀림)

[t] objects=[steak] place=freezer action=place
냉동실 선반에 스테이크를 넣는 순간. 사후 캡션에선 fridge/open으로 틀렸던 것을 fused가 교정 → 정답

세로 합성: 위=agentview-left, 중간=agentview-right, 아래=wrist(eye-in-hand). 모델은 이 형태로 관측한다.

3 최종 결과

diverse12(서로 다른 12개 task family에서 1개씩) · 회상 task 39개 · --recall-walk fine · --recall-style report · gemini-3.5-flash · 파서 수정 반영.

place_acc — 회상한 물건+장소가 정답과 일치한 비율

m3v2 (텍스트)

0.564

ours

0.462

m2 (keyframe)

0.308

m1 (history)

0.179

control (없음)

0.154

method	메모리 형태	place_acc	slot_acc	exact
m3v2	수행 subtask 텍스트 로그(~23줄)	0.564	0.282	0.128
ours	태그된 keyframe(≤8장) + 검색	0.462	0.256	0.077
m2	keyframe 이미지(≤8장)	0.308	0.154	0.000
m1	과거 프레임 균일 샘플	0.179	0.128	0.000
control	없음(상식만)	0.154	0.077	0.000

메모리는 확실히 유효하다 — 무메모리 0.154 대비 최고 0.564. 그리고 ours는 시각 계열 최고: 같은 keyframe을 쓰는 m2(0.308) 대비 +50%. 태그 + 검색이 raw 이미지 위에 실질 가치를 더한다는 증거.

ours vs m3v2 — 왜 아직 지나

39개 중 둘 다 정답 15, ours만 정답 3, m3v2만 정답 7.

격차의 정체 = 커버리지. m3v2는 에피소드의 ~23개 사건을 전부 텍스트로 남기지만, ours는 keyframe ≤8장만 보존한다. bowl→cabinet, peach→cabinet 같은 배치는 애초에 keyframe으로 지목되지 않아 메모리에 존재하지 않는다. 방법론의 결함이 아니라 용량 한계.

다만 상보적이다. ours만 맞춘 3건(cup, bowl→microwave, bagel→toaster oven)은 m3v2의 텍스트 로그가 틀린 케이스를 ours의 시각 keyframe+태그가 잡아낸 것. 즉 서로 다른 실패 모드를 가진다.

4 지금 코드 상태

# 실행 (회상 측정 표준 조합) python -m scene_mem_api.runner --model gemini-3.5-flash --method <method> \ --target recall --recall-style report --recall-walk fine \ --stage val --val-list tmp/diverse12.txt [--ours-retrieval r2] # 이번에 추가된 플래그 --state-align {chunk, leadup} # 채점 창 over-advance 보정 --recall-style {execute, report} # 회상 프롬프트 프레이밍 --recall-walk {coarse, fine} # 메모리 누적 입도 ← 영향 가장 큼 --ours-retrieval {r1, r2} # ours 검색 on/off (r1=전체 dump, ablation) --m2-force # M2 강제 지목(실험용)

커밋	내용
`516e2ab`	recall-report 프롬프트 + forced-M2 (메모리가 비로소 측정 가능)
`4dca378`	fine + leadup 누적 walk (`--recall-walk fine`)
`432905f`	diverse12 fine 스윕 문서화
`7456ca2`	`ours` 메서드(fused select+caption) + in/on 파서 수정
`e24f6ee`	ours 최종 스윕 문서화

주요 파일: scene_mem_api/memory/base.py(메서드 정책, OursPolicy) · runner.py(오케스트레이션) · prompts.py(RECALL_SYSTEM, OURS_STEP_SYSTEM) · templates.py(채점 파서).

5 다음에 할 것

0순위 (블로커) — fine annotation 재생성

879 릴리즈에 fine_subtasks.json이 없어 회상 측정 자체가 현재 돌아가지 않는다. 이게 복구돼야 아래 연구 방향을 실제로 측정할 수 있다. 코드(--recall-walk fine, ours)는 준비돼 있으므로 annotation만 생기면 즉시 재측정 가능.

연구 1순위 — 하이브리드 (텍스트 로그 + 시각 검색)

ours-only 3건 / m3v2-only 7건으로 실패 모드가 갈린다는 게 확인됐다. m3v2의 촘촘한 사건 로그를 인덱스로 쓰고, ours의 태그 검색·시각 확인을 얹으면 둘 다 넘을 여지가 가장 크다.

순위	후보	내용	기대
0 (블로커)	fine annotation 재생성	879 릴리즈용 `fine_subtasks.json` 생성	측정 재개 (이거 없으면 나머지 불가)
1	하이브리드	m3v2 로그 + ours 시각 검색	0.564 초과 가능성 (가장 유망)
2	ours 커버리지	이미지는 8장 유지, 태그(텍스트)는 더 많은 keyframe에 부여	커버리지 격차 직접 해소
3	ablation	ours R1(검색 off) vs R2(검색 on)	"검색"의 순수 기여 분해
4	리포트 갱신	기존 fine-sweep 리포트에 ours + 파서수정 반영	문서 일관성 (지금 옛 숫자)

알려진 한계 (정직하게)

절대 성능은 아직 낮다(최고 0.564). 상식 누수(steak→fridge 추측)와 마지막 장면 anchor 교란이 남아 있음.
diverse12는 (구) 858개 중 12개 표본 — 경향 확인용이지 최종 수치가 아님. 게다가 데이터셋이 879로 교체돼 현재는 재현 불가(맨 위 경고).
ours는 bowl/peach류 배치를 keyframe으로 못 잡는 커버리지 문제가 미해결.
상식 차단 질의(강제 선택지 / 반상식 배치) 설계는 사용자 몫으로 남아 있음.