MemER (dusting ckpt) probe on Keh0t0/scene-mem-benchmark
TL;DR
- Dataset access:
Keh0t0/scene-mem-benchmark은 private.aiclaudev토큰으론 404,~/envs/api_keys.txt의 owner 토큰으로 접근 OK. 858 scenarios / 4204 files / 34 combo prefix. - Mismatch 확인: 벤치마크는 VLA-level (PandaOmron mobile-base action emit + memory_success = approached∧door_open). MemER 공개 코드는 subtask string emitter 1채널만. 직접 metric 못 잼.
- Probe 결과: 3 test × 103 inference call = 309 call, parse 100% 성공. Object recognition ✅ (steak/bowl/fish 정확) / Vocabulary lock-in ❌ (모두 "place X on top/bottom shelf" — dusting 어휘).
- Keyframe selection은 instruction-blind: 3 query 모두 frame 669/1929를 메모리에 동일하게 픽 → query에 따라 다른 답을 못 줌. scene-mem 본질 task에는 부적합.
1 배경 / 목적
Keh0t0/scene-mem-benchmark는 long-horizon scene memory를 측정하는 RoboCasa 기반 벤치마크. 핵심 컨셉:
Policy가 prior-task 비디오 3개를 보고 "어디에 뭐가 놓였는지" 기억해 둔 다음, 새 instruction ("Show me where the steak is placed.")에 대해 mobile base를 그 fixture까지 끌고 가서 문을 열 수 있는가.
오늘 목표: MemER의 inference-only probe — prior 비디오를 흘려넣고 test instruction에 대해 (a) 어떤 keyframe을 메모리에 넣는지, (b) 어떤 subtask 문자열을 뱉는지 정성 관찰. Pi0.5 통합 + 정량 평가는 다음 세션으로 미룸.
memory_success 측정 불가. low-level VLA 통합 전에 MemER 출력의 적합성을 먼저 봐야 함.2 작업 내용
2.1 Dataset schema (4204 files / 858 scenarios)
- 858 scenarios 중 193개만 비디오 보유 (665는 env-only)
- 비디오+spec+state 모두 갖춘 257개가 실제 평가 대상 (combo_015 66, combo_014 51, combo_024 42, combo_021 32, combo_002 27, combo_011 26 …)
- 한 scenario에 여러 test 묶임 (combo_002_L29_S48_0006는 steak/bowl/fish 3-test)
2.2 Eval contract
→ 객체 잡기/조작은 평가 안 함. "기억하고 있던 fixture로 mobile base를 끌고 가서 문 열기"만 본다.
2.3 MemER mismatch 표
| 측면 | scene-mem-benchmark 요구 | MemER 공개 코드 |
|---|---|---|
| 출력 | np.ndarray action (PandaOmron HYBRID_MOBILE_BASE: arm OSC_POSE 6 + gripper 1 + base velocity 3 + torso 1 ≈ 11) | current_subtask 문자열 |
| 메모리 | 정책이 알아서 (LSTM/attention/whatever) | EpisodicMemory: VLM keyframe 1D clustering FIFO |
| 판정 | mujoco state (body_xpos, qpos) | 문자열 vs GT subtask 매칭 |
2.4 어댑터 작성
scripts/eval_scene_mem_one_scenario.py (171 lines) — 한 scenario 안의 모든 test sweep, model 1회 로드. 카메라는 agentview_left + agentview_right 2장 vertical stack (eye_in_hand 제외 — wrist 뷰는 해석 어려움).
3 결과
combo_002_L29_S48_0006 (Layout 29, Style 48 RoboCasa kitchen) — 3 tests × 103 calls = 309 inference, 275.6s wall clock. parse 100%.
3.1 Subtask 분포 — top-5 per test
| Test | Instruction | Top subtask (count / 103) | 2nd | Target object | Target fixture |
|---|---|---|---|---|---|
| 0 | "Show me where the steak is placed." | place the steak on the bottom shelf (64) | pick up spatula (6) | steak ✅ | freezer ❌ |
| 1 | "Show me where the bowl is placed." | place the red bowl on the top shelf (54) | place the bowl on the bottom shelf (9) | bowl ✅ | cabinet ❌ |
| 2 | "Show me where the fish is placed." | place the fish on the bottom shelf (56) | place the red bowl on the top shelf (13) | fish ✅ | oven ❌ |
tune_mm_vision=False, tune_mm_mlp=False) 효과를 봄."place X on top/bottom shelf"로 고정. RoboCasa fixture 명사 (freezer/oven/cabinet)나 mobile-base 어휘 (navigate to / approach) 0회. 심지어 test 1에서 "put down duster"까지 누수.3.2 Memory FIFO 진화 — 3 query 비교
| Test | Memory progression (raw frame index, 20 fps) | Final memory | kf events / 103 calls |
|---|---|---|---|
| 0 (steak) | [] → [669] → [669,1129] → [669,1129,1929] → [669,1129,1929,3599] | [669, 1129, 1929, 3599] | 4 |
| 1 (bowl) | [] → [669] → [669,1229] → [669,1229,1929] → [669,1229,1929,2879] → [+4639] | [669, 1229, 1929, 2879, 4639] | 5 |
| 2 (fish) | [] → [669] → [669,1229] → [669,1229,1929] → [669,1229,1929,3599] | [669, 1229, 1929, 3599] | 4 |
3.3 모든 test에 공통으로 들어간 keyframe 시각화
3.4 Raw text 샘플 (test 0)
keyframe_positions non-empty. 나머지 99% call은 빈 리스트 반환 → 시각적 saliency가 강한 순간만 골라 넣음. instruction과의 연관성은 약함.4 Takeaway
1. Object recognition은 살아있다 ✅
3 query 전부 target object("steak"/"bowl"/"fish")를 정확히 명명 — base Qwen3-VL-4B-Instruct의 visual+language 능력이 dusting finetune 후에도 보존됨. SFT가 LLM head + prompt contract만 바꾸고 vision/MLP는 frozen이었던 게 효과를 봄.
2. Vocabulary는 dusting에 박혀있다 ❌
출력 패턴이 "place X on top/bottom shelf"로 고정. RoboCasa의 적절한 fixture 명사 (freezer/oven/cabinet)나 mobile base 어휘 (navigate to/approach)는 절대 안 나옴.
→ Pi0.5와 cascade 시 conditioning이 망가짐: Pi0.5-RoboCasa는 "approach the freezer" 같은 navigation 명령을 받기를 기대할 텐데 MemER는 "place the steak on the bottom shelf"만 줌. 이대로 붙이면 score 0% 가능성.
3. Keyframe selection은 instruction-blind
3 query 모두 frame 669/1929를 메모리에 동일하게 픽. 시각적 saliency는 잘 잡지만 instruction-conditioning은 약함. scene-mem-benchmark의 본질 task ("이 query에 대한 답이 어느 frame에 있는가")에는 부적합.
이 약점은 메모리 메커니즘 자체보다 dusting finetune의 single-task vocabulary lock-in의 부산물로 보임. RoboCasa-tuned MemER에서는 query별로 다른 frame을 뽑을 가능성.
5 Next Steps
1순위 — Prompt-level vocabulary enforcement (다음 세션)
MemER prompt를 수정해서 RoboCasa primitive 리스트 중 하나만 고르게 강제:
memer_eval/contract.py의 DEFAULT_SYSTEM_PROMPT 변경만으로 코드 수정 최소. dusting-tuned LLM이 이 enum을 얼마나 신뢰성 있게 따를지 미지수 — 5–10 scenarios sanity-check 필요.
2순위 — Pi0.5-RoboCasa 통합
사용자 확정: Pi0.5는 robocasa 학습된 게 있고 robosuite+robocasa 환경도 이미 setup. 다음 세션에서:
- Pi0.5 ckpt 위치 + load API 확인 (사용자에게 받아야 함)
- 통합 어댑터:
MemerPi05Policy(BasePolicy)— reset에서 prior 비디오를 MemER에 흘려넣어 메모리 채우고, get_action에서 매 step마다 MemER subtask + Pi0.5 act - 비용 분석: 257 scenario × ~80s memory build = ~17h sequential. 첫 세팅은 sample subset (combo_002 27개 등)
- GPU placement: MemER 9GB + Pi0.5 ~8GB → 1 B200(180GB)에 둘 다 OK
스케일링 — MemER 부분만 257 scenario 전체 sweep
scripts/eval_scene_mem_all.py batch wrapper로 확장. 257 scenario × ~3 test = ~771 inference batch (각 100 call). 총 ~14h sequential at 80s/test → SLURM 1 GPU job (sbm "bash scripts/scene_mem_all.sh" --gres=gpu:1 -c 8 --mem 200GB --qos=extra). 결과 요약: scenario별 keyframe 위치 분포, top subtask 일치도, vocabulary leakage rate.
Ablation 후보
- eye_in_hand 카메라 활용: 지금 agentview L+R만 stack. wrist 단독 또는 left+wrist 조합으로 ablation
- Stride/subsample sensitivity: stride=50 (2× cost)에서 keyframe 선택이 더 dense해지는지 — 1 scenario에서 측정