scene-mem API eval — 종합 결과

1. 배경 / 목적

scene-mem-benchmark (Keh0t0, RoboCasa-based)는 로봇이 긴 멀티태스크 에피소드를 수행한 뒤, "그 물체가 어디 놓였는지"를 회상하는 능력을 측정한다. 우리는 zero-shot API 모델(Letsur 게이트웨이 경유 Gemini-2.5-flash)이 이 벤치마크에서 어디까지 도달하는지 측정하려 했고, 그 과정에서 벤치마크 자체의 "충실도 갭"(eval 계약이 실제 MemER 메커니즘과 얼마나 일치하는가)을 두 차례 보정해 가며 진짜 측정에 도달했다.

2. 방법론 — 3 eval 계약 비교

(a) trainstruct (멀티턴 전체 대화) — 초기 계약

학습 JSONL(build_scene_mem_v2.build_turns_for_test) 그대로 멀티턴 [system, u0, a0, u1, a1, …, uF, aF]로 autoregressive. 매 turn의 user에 그 세그먼트 instruction + 메모리 키프레임 이미지 + recent 이미지. assistant 턴은 모델 자기 출력 누적(GT 절대 미투입). 학습된 LoRA엔 byte-identical이지만 zero-shot엔 모델이 자기 이전 subtask 텍스트를 다시 읽을 수 있어 메모리 회상이 trivialize.

(b) gt_score 키프레임-FIFO (architecture-faithful) — 1차 보정

실제 MemER 배포(MemERDeploymentPolicy + EpisodicMemory) 메커니즘. 매 스텝 단일턴(이전 user/assistant 텍스트 누적 0), 메모리 = 키프레임 이미지만 bounded FIFO(≤8)로 다음 스텝에 전달. 텍스트 transcript 인플레 제거. 단 초기에는 instruction이 매 스텝 회상질의로 고정돼 중간 task 부재가 또 다른 충실도 갭이었음.

(c) faithful = (b) + 스텝별 현재-task instruction — 2차 보정 (본 측정)

--gt-per-segment-instruction. subtasks.json으로 timestep→세그먼트 매핑, 매 스텝 그 시점 현재 세그먼트 task instruction 주입, 회상질의는 최종 스텝만. 실제 MemER 배포(매 스텝 현재 task로 conditioning + 키프레임 FIFO + 별도 회상 질의)에 정확히 부합. 이게 본 측정의 계약.

실제 와이어 프롬프트 (faithful, 매 스텝)

system prompt = 빌더 원문 DEFAULT_SYSTEM_PROMPT("You are a robot program that predicts actions. … Return a JSON with current_subtask, keyframe_positions.") + SCENE_MEM_FORMAT_GUIDANCE(범용 주방 어휘로 출력 형식 제약, GT 비포함 — zero-shot format adapter).

3. 결과

3.1 3 계약 비교 (동일 2 샘플, combo_002_L29_S48_0089)

3.2 본 측정 (faithful) — n=30 / 10 시나리오

3.3 task 유형별 (faithful n=30)

3.4 ground-truth로 0/30 검증 (extreme metric → 의심·검증)

• 30개 최종답 전부 parse_ok·실제 문장(블랭크 0) — 스코어 결함/빈응답 아님.
• 일관 패턴: object·"Place"는 맞고 fixture만 매번 틀림:
  • Place the steak in the pan on the stove ← 정답 freezer
  • Place the bowl on the counter ← 정답 cabinet
  • Place the fish on the counter ← 정답 oven
  • Place the bagel in the fridge ← 정답 toaster oven
  • Place the cup on the counter ← 정답 steak→microwave (이 케이스는 object까지 틀림)
• = "무엇을/Place"는 추적, "어디 놨는지를 회상 못 함" = scene-mem이 측정하려던 정확히 그 능력의 실패. score_subtask는 정상 동작(fixture 불일치로 fail).

4. 증거 — 영상

읽는 법: 좌측 = wrist(상) + agentview_left(하) 카메라 스택. 우측 = 현재 task 시점의 정보 패널(CURRENT TASK fed to MemER / GROUND TRUTH — 현재 세그먼트 task + atomic fine_subtasks / MemER predicted subtask / 최종 스텝에 빨강 "MEMORY RECALL QUERY" 마커). 하단 = memory FIFO 썸네일(실제 모델이 기억하는 비디오 프레임). 화면 ✅/❌는 제거(per-step 무의미; 권위 수치 = metrics.json).

4.1 대조 — 같은 steak 케이스, 두 계약의 차이

4.2 faithful n=30 대표 — task 유형별 실패 패턴

5. 의미 (Takeaway)

• 방법론적 발견이 결과보다 더 중요: trainstruct 50%는 계약 결함이 만든 수치였고, 실제 MemER 메커니즘에 충실하게 계약을 보정해 가니 0/30이 드러남. 이는 "벤치마크 수치를 그대로 믿지 말고 계약이 실제 측정하려는 메커니즘과 일치하는지 검증"의 교과서적 사례.
• zero-shot Gemini-2.5-flash는 scene-mem 압축메모리 회상 능력이 사실상 없음: 현재 task 추종(narration)은 정상이나, 장기 메모리에서 placement fixture 회상은 0%. fine-tuning 없이 in-context로 keyframe-FIFO 메모리를 활용한 회상은 zero-shot 한계.
• 오답 패턴이 일관됨(object✓ fixture✗) → 모델은 질의 대상은 추적하나 keyframe selection이 초반 배치 이벤트를 보존하지 못함. 영상이 이를 시각적으로 입증.

6. 한계 / 다음

• 표본: n=30 / 10 시나리오 (val-189의 앞 30). 모집단 전체 주장은 n 추가 필요하나 신호의 방향·강도는 n=2→n=30에서 일관·강함.
• 단일 모델: gemini-2.5-flash zero-shot 한정. claude-* / 다른 게이트웨이 모델 비교 미수행. 다음 후보: 동일 계약으로 claude-sonnet-4-6 / gemini-2.5-pro 비교.
• game-theoretic: faithful 계약은 학습 LoRA의 trainstruct 수치와 직접 비교 불가(다른 계약). LoRA에도 faithful 계약을 적용해 in-distribution effect 분리하면 의미 있는 비교 가능(현 시점 미수행).
• 게이트웨이 content_filter: 10건 중간 스텝 차단(최종 taint 0). 더 큰 n에서는 최종 스텝이 차단될 확률이 있으므로 향후 taint exclusion 로직 유지/강화 필요.
• atomic GT timing: 영상의 GT 카드는 세그먼트 granularity까지만 (subtasks.json frame-stamp 한계). 세그먼트 내 atomic 단위 정확한 frame 매핑은 데이터에 없어 false precision 만들지 않음.

7. 재현 커맨드

상세 설계·진단·코드 변경·중간 산출물은 claude/260519/plan-scene_mem_api_eval.md에 시간순 기록. 결과 디렉토리: eval_outputs/b1_gtscore_perseg_n30/ (predictions.jsonl + metrics.json + report.md + 자동 HTML).