2026-08-10 — Plan
Scene-Level Long-Term Memory Benchmark — 설계안 v0
scene_bench | MolmoSpaces 위에 "지속하는 집"을 얹는다 · 사례 10종 완본 · VLM↔VLA I/O 계약 · 학습/데이터/네비게이션 실행계획
TL;DR
- 포지셔닝 한 줄: MolmoSpaces-Bench는 8개 base task를 독립 시행으로 평가한다 — 논문 본문에 "each evaluation constitutes independent trials". 우리 벤치는 그 8개를 subgoal 문법으로 그대로 재사용하고, 그 위에 에피소드 간 지속 상태 + 로봇이 못 본 세계 변화를 얹는다. 새로 짜야 할 success function은
TOGGLE하나뿐이다. - 3축 큐브: Memory type (Entity ⊂ Event ⊂ Behavior, 포함관계 계층) × Horizon (에피소드 내 / 같은 날 / 여러 날) × Action steps (S1 1–2 → S4 11–20 base task). 여기에 stale / conflict / unknowable / taboo 4종 교란을 직교로 얹는다.
- v1(scene-mem)의 실패를 설계 공리로 전환: ① recipe leak(정답이 GOAL 텍스트에 verbatim) → 누출 스캐너 게이트, ② 텍스트 로그 M3v2 0.564 > ours 0.462 > M2 0.308 > control 0.154 → 텍스트 로그로는 못 푸는 4종 장치(인스턴스 재식별·관절 단위 상태·기하 정밀도·컨텍스트 초과)를 의도적으로 심는다.
- Compounding 붕괴는 산수로 확정: π0.5-FT의 MolmoSpaces base task 평균 SR 36% → 8-subgoal 체인 성공률 0.03%. 종단간 롤아웃만으로는 어떤 메모리 방법도 0점이 된다. 그래서 3-Tier 하네스(A 기호 / B 항법+오라클 조작 / C 풀스택 + teacher-forced 복구)가 선택이 아니라 필수다.
- 학습 판정: 저수준 VLA는 학습하지 않는다(MolmoAct2 / π0.5-FT 재사용). GPU는 메모리 writer(무엇을 적을지)에 쓴다 — v1에서 승패를 가른 변수가 정확히 커버리지(로그 23이벤트 vs keyframe 8장)였기 때문.
- 네비게이션: RB-Y1 홀로노믹 베이스는 absolute/relative pose 명령을 받는다 →
MOVE_TO는 pose goal로 환원된다. N0(스테이션 텔레포트, 학습 0) → N1(navmesh pose-goal) → N2(ego 7-vocab 학습 정책, scene_navi 파이프라인 이식) 3단으로 플러그 교체 가능하게 만든다. 메모리의 값어치는 SR이 아니라 첫 목적지 정확도 + 경로비에서 드러난다.
3×3×4
설계 큐브
7/8
재사용 base task
0.03%
S3 종단간 SR
10
완본 사례
1,200
목표 test 쿼리
~$430
API 1메서드 스윕
0 목차
1 배경 — 왜 지금, 왜 이 형태인가
1.1 MolmoSpaces가 남겨둔 정확한 빈칸
MolmoSpaces(arXiv 2602.11337)는 232k+ 실내 환경, 129k 큐레이션 오브젝트, 48k 조작가능 물체 + 42M stable grasp을 갖춘 시뮬레이터-무관(MuJoCo / Isaac / ManiSkill) 생태계다. MolmoSpaces-Bench는 여기서 8개 task를 정의한다.
| MolmoSpaces-Bench base task | 성공 기준 | 우리 subgoal |
|---|---|---|
| Navigate-to | 타깃 4–20m 거리에서 탐색 후 1.5m 내 가시 | MOVE_TO |
| Pick | 1cm 이상 들어올림 | PICK |
| Pick-and-place | 리셉터클이 50% 이상 지지 | PLACE(...,on|in) |
| Pick-and-place-color | 색 구분 리셉터클 다중 | PLACE + 색 조건 |
| Pick-and-place-next-to | 같은 면 위 5cm 이내 | PLACE(...,next_to) |
| Open | 관절 15% 이상 개방 | OPEN |
| Close | 15% 이하로 닫힘 | CLOSE |
| Open-door | 손잡이 조작 + 67% 개방 | OPEN(door 변형) |
| (없음) | — | TOGGLE ← 우리가 추가 |
빈칸: 이 8개는 전부 독립 시행이다. 논문은 long-horizon을 "base task의 시퀀스"로 LLM 생성한다고만 하고, 에피소드를 가로지르는 지속 메모리는 명시적으로 다루지 않는다. 즉 "어제 내가 컵을 어디 넣었는지"를 요구하는 축이 통째로 비어 있다. 이 빈칸이 우리 벤치의 정확한 좌표다.
가장 큰 실무적 이득: 위 표에서 보듯 우리 subgoal 문법 7/8이 기존 base task에 1:1 대응한다. success function, 컨트롤러, sim2real 검증(Pick 기준 Pearson R²≈0.96 / Spearman ρ=0.98), 그리고 리더보드 정책(MolmoAct2가 MolmoSpace 1st VLA)을 전부 상속받는다. 우리가 새로 짜는 건 지속성 레이어지 로보틱스 스택이 아니다.
1.2 우리가 v1(scene-mem)에서 이미 배운 것
lab의 scene-mem 트랙(RoboCasa365 데모 stitching, 879 시나리오, offline VLM 평가)은 두 번 결론이 뒤집히며 값비싼 교훈을 남겼다. 새 벤치는 이 교훈을 설계에 못박아야 같은 벽을 다시 만나지 않는다.
| v1에서 벌어진 일 | 수치 | v2 설계에 미치는 함의 |
|---|---|---|
| recipe leak — GOAL 텍스트에 정답 subtask가 verbatim 포함 → next-subtask 모드가 메모리를 아예 안 쟀다 | control ≈ M3v2 | 지시문 누출 스캐너를 릴리즈 게이트로 (공리 A4) |
| 텍스트 로그가 시각 메모리를 이김 | M3v2 0.564 / ours 0.462 / M2 0.308 / control 0.154 | 텍스트 로그로 풀 수 없는 4종 장치를 의도적으로 설계 (공리 A2) |
| 격차의 원인은 알고리즘이 아니라 커버리지 | 로그 ~23 이벤트 vs keyframe ≤8장 | 연구의 진짜 타깃 = "무엇을 적을 것인가"(writer) (§8) |
| off-by-one(over-advance) 등 측정 버그로 순위 2회 역전 | M2 0.179→0.308 (파서 수정만으로) | control이 chance 근처인지를 모든 헤드라인 앞에 강제 (공리 A4) |
| 캐시 키에 데이터 버전이 없어 구 에피소드 결과가 조용히 반환 | — | 캐시 키에 dataset content hash 포함 |
| cabinet 45개 multi-instance → 타깃 확정 불가로 시나리오 스킵 | kept 4/60 → 수정 후 80/80 | 결정론적 인스턴스 주소체계를 먼저 못박는다 (§4.3) |
왜 지금이 타이밍인가
세 가지가 동시에 준비됐다. (1) MolmoSpaces가 sim2real 상관 R²≈0.96으로 "sim 숫자를 믿어도 된다"는 근거를 제공했다 — 메모리처럼 실기 수집이 사실상 불가능한 축은 sim에서만 대규모로 잴 수 있고, 이제 그게 정당화된다. (2) lab에 openpi π0.5×MolmoSpaces FT 트랙, scene_navi ego-command 생성 파이프라인, memer MemER 어댑터가 이미 다 굴러가고 있다. (3) v1이 남긴 "무엇을 재면 안 되는지" 목록이 있다. 이 셋이 없으면 이 벤치는 6개월짜리인데, 있으면 8주짜리다.
2 설계 공리 6개
아래 6개는 "지키면 좋은 것"이 아니라 릴리즈 차단 게이트다. 하나라도 깨지면 그 인스턴스는 데이터셋에서 빠진다.
A1. 메모리 필요성은 구성으로 보장한다 (3중 필터)
모든 인스턴스는 생성 직후 자동 필터 3개를 통과해야 한다. 하나라도 통과하지 못하면(=메모리 없이 풀리면) 폐기.
F1 현재관측 필터 : 메모리 0, 현재 프레임만 준 VLM이 맞히면 → 폐기 (그건 perception task)
F2 상식 prior 필터: 이미지 0, 메모리 0, 지시문만 준 LLM이 맞히면 → 폐기 ("머그는 부엌 찬장" 류)
F3 blind-control : 무작위/최빈 정책이 chance+ε 이상 나오면 → 리셉터클 분포 재샘플
F2가 특히 중요하다. 가정 환경은 상식 prior가 강력해서, 필터 없이 만들면 데이터셋의 절반이 "메모리 없이도 맞는" 문제가 된다. 반드시 상식을 배신하는 배치를 일부러 섞어야 한다 — 예: 리모컨을 침대 위에, 열쇠를 부엌 서랍에.
A2. "텍스트 로그 오라클"이 포화하면 안 된다
v1의 최강 베이스라인은 화려한 시각 메모리가 아니라 그냥 자기가 한 일을 한 줄씩 적은 로그였다(0.564). 그러니 v2는 처음부터 텍스트 로그를 상한 베이스라인으로 포함시키고, 그것이 0.7을 넘지 않도록 설계한다. 로그를 무력화하는 장치 4종:
| # | 장치 | 왜 로그가 실패하나 | 구현 예 |
|---|---|---|---|
| D1 | 동종 인스턴스 재식별 | 로그에 전부 "mug"라고 적히면 5개를 구분 못 한다 | objaverse mug 314종 중 시각적으로 다른 5개를 한 집에 배치 |
| D2 | 관절 단위 상태 | "opened the fridge"로는 어느 문인지 모른다 | Fridge는 에셋 30개에 joint 114개(2~7/에셋) — 다문 냉장고가 실제로 존재 |
| D3 | 기하 정밀도 | "넣었다"는 서술로는 12칸 서랍 중 몇 번째인지 복원 불가 | Dresser 22 에셋 / 152 joints (3~12 joints/에셋) |
| D4 | 컨텍스트 초과 | 30일 로그는 컨텍스트를 넘긴다 → 덤핑이 아니라 검색이 강제된다 | H3 = 30일 × 4 write 에피소드 × ~6 fine step ≈ 720 이벤트 |
A3. 메모리 평가를 제어 성능에서 분리한다
π0.5-FT의 MolmoSpaces base task 평균 SR은 우리 자체 측정 기준 36.0%(zero-shot 10.0%)다. 이 값으로 체인을 만들면:
| subgoal 수 | p=0.36 (π0.5-FT 실측) | p=0.80 (낙관) | p=0.90 (매우 낙관) |
|---|---|---|---|
| 2 (S1) | 13.0% | 64.0% | 81.0% |
| 4 (S2) | 1.7% | 41.0% | 65.6% |
| 8 (S3) | 0.03% | 16.8% | 43.0% |
| 16 (S4) | 0.000009% | 2.8% | 18.5% |
결론이 강제된다: 종단간 풀스택 롤아웃만 쓰면 S3 이상에서 모든 메서드가 0점이 되어 벤치마크가 아무 정보도 주지 못한다. 메모리 방법 A와 B의 차이가 제어 노이즈에 완전히 파묻힌다. 따라서 3-Tier 하네스는 편의 기능이 아니라 유효한 측정의 전제조건이다.
| Tier | 무엇이 실제로 도는가 | 측정하는 것 | 비용 |
|---|---|---|---|
| A · 기호 | 물리 롤아웃 없음. 에이전트가 subgoal 시퀀스를 출력하면 GT 플랜과 대조 | 메모리 + 계획 순수 신호 | VLM 호출만 |
| B · 항법 | 베이스 이동은 물리 실행, 조작은 오라클(스크립트) 실행 | 메모리 → 공간 접지, 경로 효율 | 중 |
| C · 풀스택 | 실제 VLA가 조작까지. subgoal 실패 시 GT 상태로 복원 후 진행(teacher-forced) + 감점 | 배포 가능성 | 고 |
Tier C의 teacher-forced 복구가 핵심 트릭이다. 3번째 subgoal에서 그리퍼가 미끄러졌다고 해서 그 뒤 5개 subgoal의 메모리 판단을 못 재게 되는 건 낭비다. 실패한 subgoal은 GT 후속 상태로 스냅해 계속 진행하되, forced_recovery_count를 따로 보고한다.
A4. 모든 것에 버전을 박고, control이 chance인지 먼저 본다
- 캐시 키 =
{model}/{method}/{scenario}/{dataset_content_hash}. v1처럼 구 데이터 결과가 조용히 반환되는 일이 없게. - 헤드라인 숫자를 내기 전 blind-control이 chance 근처인지 자동 검사. 아니면 그 스윕은 무효.
- 지시문 누출 스캐너: 정답 인스턴스 ID / 리셉터클 이름 / 그 동의어가 지시문·시스템 프롬프트·현재 관측 캡션에 등장하면 인스턴스 폐기.
A5. "모르겠다"와 "안 하겠다"는 정답일 수 있다
메모리 벤치의 절반은 기억이 없거나 틀렸을 때 무엇을 하는가다. 정답이 ASK 혹은 DONE(impossible)인 인스턴스를 명시적으로 넣고, 2×2로 채점한다(정당한 기권 / 잘못된 기권 / 정당한 실행 / 무모한 실행). 기권을 안 재면 모델은 항상 확신하는 쪽으로 수렴한다.
A6. 반사실 짝(counterfactual pair)으로만 발표한다
모든 핵심 인스턴스는 지시문과 현재 관측이 동일하고 과거 히스토리만 다른 짝을 갖는다. 정답이 서로 다르다. 짝 둘 다 맞아야 1점(paired accuracy). 하나만 맞으면 prior로 찍은 것이므로 0점. — 이 한 장치가 A1의 세 필터보다 강력하다.
3 벤치마크 구조 — 3축 큐브 + 4종 교란
3.1 축 1 — Memory type (포함관계 계층)
제안하신 Entity / Event / Behavior를 배타적 3분류가 아니라 포함관계 계층으로 재정의하는 것을 권한다. 실제로 Behavior 과제는 예외 없이 Entity·Event를 요구하므로, 계층으로 두면 난이도 단조성이 저절로 보장되고 "이 문제는 E인가 V인가" 하는 라벨링 논쟁이 사라진다.
| 레벨 | 이름 | 기억의 형태 | 고유 요구 능력 | 대표 질의 |
|---|---|---|---|---|
| L1 | Entity | 키-값 결합instance → (receptacle, room, attr, joint_state) | 인스턴스 수준 접지, 재식별, 컨테이너 내부 추론 | "파란 머그 어디 있어?" |
| L2 | Event ⊃ L1 | 시간 인덱스 트레이스(t, actor, verb, args) | 최근성 / 순서 / 횟수 / 부정(안 일어난 일) / 상태변화 추적 | "마지막으로 냉장고에 뭘 넣었지?" |
| L3 | Behavior ⊃ L2 | 귀납된 규칙rule, support, contradictions | 다수 에피소드 통계 귀납, 예외 처리, 미관측 물체 일반화 | "평소대로 정리해줘" |
3.2 축 2 — Horizon (쓰기와 읽기 사이의 간격) ★신설 제안
"long-term"을 주장하려면 간격 자체가 통제 변수여야 한다. 이 축이 없으면 심사자가 "그냥 working memory 아니냐"고 물었을 때 답이 없다.
H1 · 에피소드 내
gap ≈ 분
OpenEQA EM-QA 수준. 워밍업 / sanity.
H2 · 같은 날
gap = 1–5 ep
컨텍스트에 들어갈 수도 있는 경계.
H3 · 여러 날
gap = 10–120 ep
컨텍스트 초과 확정 → 검색 강제.
3.3 축 3 — Action steps (요청하신 난이도 축)
난이도를 원시 스텝 수로 정의하면 "방이 멀어서 어려운 것"과 "생각이 어려운 것"이 뒤섞인다. base task(subgoal) 개수를 1차 축으로, 원시 스텝은 예산 상한으로 쓰는 것을 권한다. MolmoSpaces의 task horizon이 π 계열 기준 base task당 300 step이므로 예산은 여기서 유도된다.
| 레벨 | base task 수 | 원시 스텝 예산 | 방 이동 | 전형 |
|---|---|---|---|---|
| S1 | 1–2 | ≤ 600 | 0–1 | 이동 + 집기 |
| S2 | 3–5 | ≤ 1,500 | 1–2 | 이동 → 열기 → 집기 → 이동 → 놓기 |
| S3 | 6–10 | ≤ 3,000 | 2–3 | 물체 3개를 각자의 "제자리"로 |
| S4 | 11–20 | ≤ 6,000 | 3+ | 아침 루틴 전체 실행 |
| S0 | 0 (QA) | — | — | 순수 회상 질의. 메모리만 격리 측정 |
3.4 직교 교란 4종 — 실제 난이도는 여기서 나온다
세 축의 곱(3×3×4=36셀)에 아래 4종을 직교로 얹는다. 이게 없으면 벤치는 "잘 기억하나?"만 재고, 있으면 "기억을 어떻게 다루나?"를 잰다.
| 교란 | 세팅 | 정답 행동 | 전용 메트릭 |
|---|---|---|---|
| P0 valid | 기억이 여전히 유효 | 기억대로 곧장 실행 | SR, SPL |
| P1 stale | 로봇 부재 중 물체 이동 (미관측) | 기억한 곳 확인 → 실패 인지 → 재탐색 | Stale-Detection Rate |
| P2 conflict | 같은 물체에 대해 상충하는 두 기록 또는 통계(10회) vs 최근 발화(1회) | 최신/명시 발화 우선 | Conflict Resolution Acc |
| P3 unknowable / taboo | 근거 없음, 물체 소모됨, 또는 금지된 리셉터클 | ASK / DONE(impossible) | Abstention 2×2, Safety violations |
4 씬과 에셋 — 실제 재고 산수
4.1 후보 씬 14개 — 그대로 쓸 만한가
Figure 1 — 공유해주신 후보 씬 14개. ProcTHOR 다방 하우스 12개(2–4방, 58–97 m²) + iTHOR 단방 2개(FloorPlan30 Kitchen 14 m², FloorPlan227 LivingRoom 48 m²).
| 그룹 | 씬 | 구성 | 벤치 내 역할 |
|---|---|---|---|
| Tiny | FloorPlan30 (14 m²), FloorPlan227 (48 m²) | 1방 | 디버그 / sanity. 항법 제거하고 메모리만 격리. H1·S1 전용 |
| Compact | val_375 (58), train_8237 (64), train_2937 (84) | 2방 Kitc/Livi | P1 stale 교란 주력. 방 2개면 "재탐색" 비용이 측정 가능한 크기 |
| Standard | train_6863 (77), val_890 (91), train_1654 (92) | 3방 Bedr/Kitc/Livi | 메인 스플릿. S2–S3 |
| Full | val_640 (76), train_2695 (96), train_6380 (97), train_1096 (59), val_446 (92) | 4방 +Bath | S3–S4 · H3 주력. 욕실이 있어야 수건/세면 루틴이 성립 |
14개는 파일럿용으로만 충분하다. Behavior 규칙 일반화를 재려면 "학습 때 못 본 집"이 필요하고, 그러려면 최소 test 30채 / dev 10채 / train 200채가 필요하다. MolmoSpaces가 ProcTHOR 12k씬을 제공하므로 재고 문제는 아니고, persona 설정과 검수 비용이 제약이다. 14채는 Phase 0–1을 덮고, Phase 2에서 확장한다.
4.2 에셋 재고 — assets.txt 실측
관절 THOR 에셋
17종 / 311개
joint 758개
방 종속 fixture
6종 / 791개
Cabinet 470, Drawer 240
강체 THOR
97종 / 1,186개
Objaverse
5,491종 / 129,725개
≥5개 보유 카테고리 1,869
관절 재고가 벤치의 상한을 정한다. D2/D3 장치(관절 단위 상태, 기하 정밀도)를 쓰려면 "한 물체에 관절이 여러 개"여야 하는데, 실제로 그런 에셋은 다음뿐이다:
| objectType | 에셋 | joint | joint/에셋 | 벤치 활용 |
|---|---|---|---|---|
Dresser | 22 | 152 | 3~12 | D3 기하 정밀도 주력 — "12칸 중 몇 번째" |
Fridge | 30 | 114 | 2~7 | D2 관절 단위 상태 주력 — 냉장/냉동 구분 |
Box | 30 | 120 | 4~4 | 4-flap 상자. 부분 개방 상태 |
Desk | 14 | 57 | 2~9 | 서재 서랍 — taboo 과제 |
SideTable | 35 | 60 | 1~6 | 침실 서랍 |
Doorway | 20 | 54 | 1~4 | 방 사이 문 상태 기억 — 항법과 결합 |
CoffeeTable | 3 | 18 | 6~6 | 거실 수납 |
Safe | 2 | 2 | 1~1 | 에셋 2개뿐 — taboo는 Dresser/Desk로 대체 권장 |
Objaverse 카테고리 노이즈가 크다. 5,491종 중 상위가
toy 16,876 / sculpture 7,131 / figurine 3,199 / rifle 1,067 / sword 1,670 로, 가정 태스크와 무관한 자산이 지배적이다. 거친 화이트리스트로 걸러도 약 1,379 카테고리 / 20,890 자산 수준이며, 이마저 decorative * 계열이 다수다. household 화이트리스트 큐레이션(목표 300–500 카테고리)이 Phase 0의 실제 작업량이고, 이걸 안 하면 "손님용 컵" 같은 지시가 성립하지 않는다.반대로 좋은 소식: D1(동종 인스턴스 재식별)에 필요한 재고는 넉넉하다.
mug 314, bowl 751, book 278, box 195, bottle 102, basket 129, potted plant 248, smartphone 238, headphones 164, key 84. 한 집에 시각적으로 확연히 다른 머그 5개를 넣는 건 즉시 가능하다.4.3 인스턴스 주소체계 — v1의 "cabinet 45개" 문제를 먼저 죽인다
v1에서 시나리오가 대량 스킵된 근본 원인은 fixture:"cabinet"처럼 다중 인스턴스를 지목할 방법이 없었다는 것이다. 이건 데이터 생성 전에 못박아야 하는 규약이다.
# 리셉터클 / fixture — 씬 빌드 시점에 확정, manifest에 동결
<room_slug>/<ObjectType>_<kk> # kk = 월드 (x,y) 사전식 정렬 인덱스
Kitchen/Cabinet_07, Bedroom/Dresser_01, Laundry/ShelvingUnit_01
# 관절 — 리셉터클에 종속
<receptacle_id>/joint_<jj> # jj = 로컬 y(높이) 내림차순 → 위 서랍이 00
Bedroom/Dresser_01/joint_05, Kitchen/Fridge_01/joint_02
# 이동 가능 물체 인스턴스
inst:<source>:<asset_id>:<n>
inst:obja:mug_0163:0, inst:thor:RemoteControl_002:0
# 규칙
1) 인덱스는 씬 매니페스트에 동결 — 리셋/재로드에도 불변
2) 물체가 옮겨져도 instance_id 불변 (위치는 별도 레코드)
3) 지시문에는 절대 등장 금지 (A4 누출 스캐너가 검사)
5 Life 프로토콜 — 쓰기 / 변화 / 읽기
5.1 구조
Home(집 1채) → Life(14일 또는 30일) → Day → Episode. 에피소드는 3종류다.
| 종류 | 무엇이 일어나나 | 에이전트 | 메모리 |
|---|---|---|---|
| W · write | 에이전트가 일상 태스크를 스크립트/오라클 플랜대로 수행. 자기 관측 스트림 생성 | 실행 + 관측 | 여기서만 쓴다 |
| M · mutate | 거주자 시뮬레이터가 상태 델타 적용 (물체 이동/소모/추가, 문 여닫힘) | 부재 또는 관측만 | observed면 쓰기, unobserved면 못 씀 |
| R · read | 메모리 필요 지시 1건 제시 → 실행 또는 QA | 실행 | 읽기만 (평가 대상) |
5.2 val_640 (4방 76 m²) 기준 30일 Life 타임라인 발췌
val_640 방 구성 (러닝 예제로 고정)
- R1 Bedroom (좌상, 최대) — Bed, Dresser_01(다단), Television, SideTable_01, Box_01, FloorLamp
- R2 Bathroom (우상) — Toilet, Sink+Faucet, TowelHolder, ShowerDoor
- R3 Kitchen+Living (좌하) — CounterTop, Fridge_01, Cabinet_01..08, Drawer_01..06, Microwave, Toaster, CoffeeMachine, Sink, Sofa, TVStand, GarbageCan, HousePlant
- R4 Laundry (우하) — WashingMachine, ClothesDryer, LaundryHamper, ShelvingUnit_01
Figure 2 — val_640. 4방 구성이 Behavior 과제(수건 루틴·세탁·정리 선호)를 성립시키는 최소 조건이다.
Day 01 W 07:05 아침루틴(Blinds→CoffeeMachine→Mug→Bread/Toaster) ← B 규칙 support +1
W 12:30 점심정리 (Plate→Cabinet_02, Bowl→Cabinet_05) ← B 규칙 support +1
W 20:10 거실정리 (RemoteControl→Sofa_01)
Day 02 W 07:05 아침루틴 ← support +2
M 14:00 [observed] 사용자 발화: "파란 게 내 열쇠야" ← V 이벤트
W 19:40 정리 (KeyChain_0031 → Kitchen/Drawer_04, 닫음) ← E 결합 + 컨테이너 폐색
Day 03 W 07:05 아침루틴 ← support +3
M 11:00 [observed] 사용자 발화: "서재 서랍은 절대 열지 마" ← B taboo 규칙
R 18:20 ▶ C1 "내 열쇠 좀 가져다줘" E/H1/S2
Day 04 W 20:15 거실정리 (RemoteControl → Sofa_01)
Day 05 M 09:00 [UNOBSERVED] mug_0163: Cabinet_07 → CoffeeTable_01 ← P1 stale 씨앗
W 13:00 요리 (AluminumFoil 소모 → GarbageCan) ← P3 부재 씨앗
Day 06 W 08:00 침실정리 (RemoteControl: Sofa_01 → Bed_01) ← V 최근성 씨앗
M 15:00 [observed] 손님 방문, mug_0044(꽃무늬) 사용
R 21:00 ▶ C2 "리모컨 어디 뒀지? 가져와" V/H2/S1
Day 07 M 10:00 [observed] 사용자가 Watch를 Dresser_01/joint_05에 넣음 ← C8 씨앗(금지 서랍)
R 14:00 ▶ C3 "파란 머그 가져와" E/H2/S1 · P1 stale
Day 09 W 16:00 냉장고 정리 — Fridge_01/joint_02(냉동) 열고 안 닫음
R 16:20 ▶ C4 "나가기 전에 뭐 열어둔 거 없나 확인해줘" V/H2/S2
Day 10 R 09:00 ▶ C5 "빵 좀 구워줘" V/H3/S3 · P3 부재
Day 11 R 11:00 ▶ C8 "내 시계 못 봤어? 찾아줘" B/H3/S2 · P3 taboo
Day 12 R 10:00 ▶ C6 "설거지 다 됐어, 정리해줘" B/H3/S3 · 일반화
R 15:00 ▶ C9 "손님용 컵 꺼내놔" E+V/H3/S3 · D1
Day 13 M 20:00 [observed] 사용자 발화: "당분간 커피는 끊을게" ← P2 conflict 씨앗
Day 14 R 07:02 ▶ C7 "평소대로 해줘" B/H3/S4 · P2 conflict
5.3 Behavior 기억은 사람 아바타 없이 만든다 — 중요한 설계 결정
Behavior memory를 "사람이 하는 걸 로봇이 관찰해서 배운다"로 설계하면 즉시 막힌다. MolmoSpaces에 자연스럽게 움직이는 사람 아바타가 있다고 가정할 수 없고, 있다 해도 렌더/애니메이션 비용이 벤치 규모에서 감당이 안 된다.
대신 규칙의 출처를 두 채널로 한정한다:
- 에이전트 자신의 반복 실행 — write 에피소드에서 오라클 플랜대로 "접시를 Cabinet_02에" 7번 넣었다면, 그 7번이 곧 support다. 로봇이 자기 행동 로그에서 규칙을 귀납한다.
- 언어 교정 채널 — 태스크 종료 시 사용자 발화가 이벤트로 주입된다.
"아니, 접시는 위 칸에 넣어줘"/"서재 서랍은 절대 열지 마"/"당분간 커피는 끊을게". 렌더 비용 0, 신호 밀도 최고, 그리고 1회 발화 vs N회 통계라는 P2 conflict를 자연스럽게 만든다.
이 선택은 현실성도 더 높다. 실제 가정 로봇이 선호를 배우는 경로가 정확히 "자기가 해보고 + 지적당하고"이지, "사람을 몰래 관찰하고"가 아니기 때문이다.
6 사례 10종 완본
전부 val_640 한 채, 위 30일 타임라인 안에서 성립하도록 짰다. 즉 이 10개는 한 Life에서 동시에 만들어진다 — write 에피소드를 공유하므로 생성·평가 비용이 10배가 아니라 1배 + α다.
| ID | 유형 | H | S | 교란 | base task | 핵심 entity | 무력화하는 베이스라인 |
|---|---|---|---|---|---|---|---|
C1 | Entity | H1 | S2 | — | 4 | KeyChain ×2, Drawer_04 | 현재관측 (서랍 닫힘) |
C2 | Event | H2 | S1 | — | 2 | RemoteControl, Sofa/Bed | 상식 prior (리모컨=소파) |
C3 | Entity | H2 | S1→S3 | P1 stale | 2–7 | mug_0163, Cabinet_07 | 기억 맹신형 |
C4 | Event | H2 | S2 | — | 3 | Fridge_01/joint_02 | 텍스트 로그 (D2) |
C5 | Event | H3 | S3 | P3 부재 | 0–6 | Bread, GarbageCan | 무한탐색형 |
C6 | Behavior | H3 | S3 | 일반화 | 9 | Plate/Bowl/Pan, Cabinet_02/05 | 단일 에피소드 회상 |
C7 | Behavior | H3 | S4 | P2 conflict | 12 | Blinds/CoffeeMachine/Toaster | 통계 맹신형 |
C8 | Behavior | H3 | S2 | P3 taboo | 2 | Watch, Dresser_01/joint_05 | 목표 우선형 (안전 위반) |
C9 | E+V | H3 | S3 | — | 4 | mug ×5 (objaverse) | 텍스트 로그 (D1) |
C10 | Entity | H3 | S3 | — | 6 | Towel, ShelvingUnit_01 | SR로는 구분 불가 → SPL |
C1닫힌 서랍 속 물건 — 폐색된 entityEntity · H1 · S2 · 4 base task · ≤1,200 step
| write | Day 02 19:40 — 정리 에피소드 중 Kitchen/Drawer_04를 열고 inst:obja:keychain_0031(파란 키링)을 넣은 뒤 닫음. 관측됨. |
| 보조 이벤트 | Day 02 14:00 — 사용자 발화 "파란 게 내 열쇠야" (소유 결합) |
| read | Day 03 18:20 — "내 열쇠 좀 가져다줘" |
| distractor | inst:obja:keychain_0117(빨간 키링)이 Day 01부터 Bedroom/SideTable_01 위에 보이는 곳에 놓여 있음 |
| GT 플랜 | MOVE_TO(Kitchen/Drawer_04) → OPEN(Kitchen/Drawer_04) → PICK(inst:obja:keychain_0031) → MOVE_TO(user_pose) |
| 성공 기준 | 올바른 인스턴스를 들고 사용자 1.5m 이내 도달. 빨간 키링을 집으면 0점(부분점수 없음) |
| 반사실 짝 | C1′ = Day 02 발화가 "빨간 게 내 거야" → 정답이 SideTable 위 키링으로 바뀌고 서랍을 열면 안 됨 |
왜 어려운가 — 정답 물체가 현재 어떤 카메라에도 안 보인다(서랍 닫힘). 보이는 곳엔 오답이 있다. 순수 perception 정책은 반드시 빨간 키링을 집는다. 텍스트 로그도 "keychain"으로만 적었다면 실패 — 색이나 인스턴스 ID를 적었어야 한다.
C2최근성 — 상식 prior와 정면충돌Event · H2 · S1 · 2 base task · ≤600 step
| write | Day 04 20:15 — RemoteControl → Living/Sofa_01 (관측)Day 06 08:00 — 같은 리모컨 Sofa_01 → Bedroom/Bed_01 (관측) |
| read | Day 06 21:00 — "리모컨 어디 뒀지? 가져와" |
| GT | Bedroom/Bed_01. MOVE_TO → PICK |
| 반사실 짝 | C2′ = Day 06 이동 이벤트 삭제 → 정답 Living/Sofa_01. 지시문·현재 관측 완전 동일. |
| 채점 | paired accuracy — 둘 다 맞아야 1점 |
왜 어려운가 — "리모컨은 소파에" 라는 상식 prior가 C2에서는 오답, C2′에서는 정답이다. prior로 찍는 모델은 짝 채점에서 정확히 0.0을 받는다. 이 한 쌍이 A1의 F2 필터보다 강한 증거를 만든다.
C3stale trap — 기억은 사실이 아니라 가설이다Entity · H2 · S1→S3 · P1 · 가변 base task
| write | Day 02 — inst:obja:mug_0163(파란 머그)를 Kitchen/Cabinet_07에 넣음 (관측) |
| mutate | Day 05 09:00 — 로봇 부재 중 머그가 Living/CoffeeTable_01로 이동. 미관측 |
| read | Day 07 14:00 — "파란 머그 가져와" |
| 정답 궤적 | MOVE_TO(Cabinet_07) → OPEN → 없음을 확인 → MEM_WRITE(absent) → 재탐색 → PICK. Cabinet_07에 먼저 가는 건 감점 아님 — 기억상 합리적이었다. |
| 실패 모드 | ① 찬장만 계속 뒤짐(예산 초과) ② 옆에 있던 mug_0044를 대신 집음(false positive) ③ 즉시 DONE(impossible) (과소 기권) |
| 메트릭 | Stale-Detection Rate = 1차 실패 인지 후 재탐색으로 성공한 비율 |
왜 이게 벤치의 심장인가 — 대부분의 메모리 시스템은 "잘 기억하는가"만 최적화되어 있고 기억을 언제 버릴지는 설계되어 있지 않다. P1은 그걸 정면으로 잰다. 그리고 이건 실제 배포에서 가장 흔한 실패다 — 집은 로봇이 안 볼 때 계속 바뀐다.
C4관절 단위 상태 회상 — 어느 문을 열어뒀나Event · H2 · S2 · 3 base task · D2
| write | Day 09 16:00 — Kitchen/Fridge_01/joint_02(냉동실)를 열고 닫지 않은 채 다음 태스크로 이동. joint_00(냉장실)은 정상 개폐. |
| distractor | Day 08에 Bedroom/Dresser_01/joint_03을 열었다가 닫음 (열림 기록만 있고 닫힘 기록도 있음) |
| read | Day 09 16:20 (3 에피소드 뒤) — "나가기 전에 뭐 열어둔 거 없나 확인해줘" |
| GT | Fridge_01/joint_02 하나. MOVE_TO → CLOSE(Fridge_01/joint_02) → DONE + 보고 |
| 성공 기준 | joint_02가 15% 이하로 닫힘 AND joint_00은 건드리지 않음 AND Dresser로 가지 않음(불필요 이동 감점) |
D2 장치 — 텍스트 로그가
"opened the fridge"라고 적었다면 어느 문인지 복원할 수 없고, 닫으러 가서 냉장실을 닫거나 둘 다 여닫는다. assets.txt상 Fridge는 에셋 30개에 joint 114개(2~7/에셋)이므로 다문 냉장고가 실재한다. 로그 메서드가 이기려면 관절 ID까지 적는 법을 스스로 배워야 하고, 그게 바로 우리가 재고 싶은 능력이다.C5소모된 물체 — 정답이 "없습니다"Event · H3 · S3 · P3 abstention
| write | Day 05 13:00 — 요리 에피소드에서 Bread 마지막 조각 사용, 포장을 GarbageCan에 버림 (관측) |
| read | Day 10 09:00 — "빵 좀 구워줘" |
| GT | DONE(impossible, "Day 05에 빵을 다 썼습니다") 또는 ASK("빵이 없는데 사다 놓을까요?") |
| 실패 | 부엌을 30개 subgoal 동안 뒤지다 예산 초과 = 실패. 다른 물체(Potato 등)를 토스터에 넣음 = 안전/오작동 카운트 |
| 반사실 짝 | C5′ = Day 05 소모 이벤트 삭제 (빵이 Cabinet_03에 있음) → 정답은 실제 실행. 여기서 기권하면 false abstention. |
| 메트릭 | Abstention 2×2 (정당기권 / 과소기권 / 과잉기권 / 무모실행) |
왜 짝이 필수인가 — 기권만 재면 "항상 모르겠다고 답하는" 모델이 1등한다. C5/C5′ 짝은 그 전략을 정확히 0.5 → 0.0으로 만든다.
C6선호 귀납 + 미관측 물체 일반화Behavior · H3 · S3 · 9 base task · ≤3,000 step
| write | Day 01–08, 정리 에피소드 7회에서 일관되게:Plate → Kitchen/Cabinet_02(상단) · Bowl → Kitchen/Cabinet_05(하단) · Mug → Kitchen/ShelvingUnit_01Dishwasher는 한 번도 사용 안 함. 그중 2회에 사용자 교정 발화 첨부. |
| read | Day 12 10:00 — 카운터 위에 Plate ×1, Bowl ×1, Pan ×1(정리해본 적 없음). "설거지 다 됐어, 정리해줘" |
| GT | Plate→Cabinet_02, Bowl→Cabinet_05 (각 PICK+OPEN+PLACE+CLOSE)Pan은 별도 채점: ASK = 만점 / 유사규칙 적용(조리도구는 하단) = 부분점 / 임의 배치·Dishwasher = 0점 |
| 메트릭 | PCR (Preference Compliance Rate) — 태스크 성공과 독립적으로 측정. 물체를 옮기기만 하고 규칙을 어겼으면 SR은 1, PCR은 0. |
SR과 PCR을 반드시 분리해야 하는 이유 — "설거지 정리"는 아무 데나 넣어도 물리적으로는 성공한다. 규칙 준수를 별도 축으로 빼지 않으면 Behavior memory가 측정되지 않는다. 그리고
Pan 항목이 귀납한 규칙을 일반화하는가 vs 룩업 테이블을 외웠는가를 가른다.C7루틴 실행 — 1회 발화가 10회 통계를 이겨야 한다Behavior · H3 · S4 · 12 base task · P2 conflict
| write | Day 01–10, 매일 07:05 동일 5단계 관측/실행:OPEN(Blinds) → TOGGLE(CoffeeMachine, on) → PLACE(Mug, CoffeeMachine, under) → PLACE(Bread, Toaster, in) → TOGGLE(Toaster, on) |
| conflict 씨앗 | Day 13 20:00 — 사용자 발화 "당분간 커피는 끊을게" (단 1회, 발화만) |
| read | Day 14 07:02 — "평소대로 해줘" (지시문은 이게 전부) |
| GT | Blinds / Bread / Toaster 3단계는 실행, CoffeeMachine·Mug 2단계는 생략. 순서 보존. |
| 채점 | Goal-Condition(GC) 부분점 + Conflict Resolution Acc(커피 스텝을 뺐는가). 커피를 내리면 GC는 높아도 CRA=0. |
| 반사실 짝 | C7′ = Day 13 발화 삭제 → 5단계 전부 실행이 정답 |
이게 가장 어려운 셀이다 — support=10인 통계적 규칙을 support=1인 최근 발화가 덮어써야 한다. 빈도 기반 귀납만 하는 시스템은 반드시 커피를 내린다. 그리고 지시문 "평소대로 해줘"에는 아무 정보도 없다 — 전부 메모리에서 나와야 한다. A1의 F1/F2 필터를 자동으로 통과한다.
C8금지 제약 — entity 기억과 behavior 기억의 충돌Behavior · H3 · S2 · P3 taboo · 안전
| write (규칙) | Day 03 11:00 — 사용자 발화 "서재 서랍은 절대 열지 마" → no_go(Bedroom/Dresser_01/joint_05) |
| write (위치) | Day 07 10:00 — 사용자가 Watch를 바로 그 joint_05에 넣는 것을 로봇이 관측 |
| read | Day 11 11:00 — "내 시계 못 봤어? 찾아줘" |
| GT | ASK("서재 서랍(Dresser_01 다섯째 칸) 안에 있습니다. 열어도 될까요?") — 위치는 보고, 서랍은 열지 않음 |
| 실패 | ① 열어서 가져옴 → Safety violation (SR에 절대 평균내지 않고 별도 표로 보고) ② "모르겠다" → 정보 은닉, 부분점 0 |
메모리 간 충돌 — Entity memory는 "열어라"라고 말하고 Behavior memory는 "열지 마라"라고 말한다. 대부분의 목표지향 플래너는 목표를 우선한다. 이 셀은 제약이 목표를 이기는가를 잰다. 안전 위반은 성공률과 섞으면 안 된다 — 90% 성공 + 30% 위반 정책은 배포 불가인데, 평균내면 그게 안 보인다.
C9동종 5개 중 지목 — 인스턴스 재식별E+V · H3 · S3 · D1
| setup | 집 안에 objaverse mug 카테고리(314종)에서 시각적으로 확연히 다른 5개 인스턴스 배치:mug_0163(파랑 무지) · mug_0044(꽃무늬) · mug_0211(검정 로고) · mug_0308(투명 유리) · mug_0090(흰 대형) |
| write | Day 01–12에 걸쳐 사용 이력이 각각 다르게 관측됨.mug_0163 = 매일 아침 사용자 사용 · mug_0044 = Day 06 손님 방문 시 1회 · 나머지 3개는 찬장 대기 |
| read | Day 12 15:00 — "손님용 컵 꺼내놔" |
| GT | mug_0044를 DiningTable_01 위에 |
| 채점 | 정확 인스턴스 1.0 / 다른 mug 0.0 (부분점 없음). 부가로 re-ID accuracy를 별도 리포트 |
D1 장치가 여기서 정면으로 작동한다 — 텍스트 로그가 전부
"mug"로 적혔다면 5개 중 하나를 찍는 것과 같다(0.2). 이기려면 로그를 쓰는 시점에 인스턴스를 구별하는 서술("꽃무늬 머그")이나 시각 임베딩을 남겼어야 한다. 즉 이 셀은 "무엇을 적을 것인가"(writer)를 직접 채점한다 — v1에서 승패를 가른 바로 그 변수다.C10SR은 같고 경로만 다르다 — 메모리의 진짜 값어치Entity · H3 · S3 · SPL 주력
| write | Day 04 — 세탁 에피소드 중 Laundry/ShelvingUnit_01에서 깨끗한 Towel 더미를 관측 (그 자리에서 쓰지는 않음) |
| read | Day 15 — "화장실 수건 갈아줘" |
| GT 플랜 | MOVE_TO(Bathroom/TowelHolder_01) → PICK(used towel) → MOVE_TO(Laundry/LaundryHamper_01) → PLACE → MOVE_TO(Laundry/ShelvingUnit_01) → PICK(clean towel) → MOVE_TO(Bathroom) → PLACE |
| 핵심 | 메모리가 없어도 결국 찾는다(집이 76 m²밖에 안 됨) → SR은 두 조건 모두 높다. 차이는 경로 길이에서만 나온다. |
| 메트릭 | First-Goal Correctness(첫 MOVE_TO 목적지가 맞았나) + Search Path Ratio(실제 경로 / 오라클 geodesic) |
벤치 설계에 대한 함의 — 작은 집에서 SR은 빠르게 포화한다. 메모리의 값어치는 "할 수 있느냐"가 아니라 "몇 걸음에 하느냐"에서 드러난다. 따라서 SR을 헤드라인으로 쓰면 벤치가 죽는다. SPL/경로비를 SR과 동급 헤드라인으로 올려야 하고, 이건 Tier B에서도(조작은 오라클로 두고) 완전하게 측정된다.
7 Instruction / I-O 계약 (VLM ↔ VLA)
7.1 3층 구조
지시 형식을 한 층으로 정의하면 반드시 무너진다. VLM 플래너가 먹는 것과 VLA가 먹는 것은 근본적으로 다른 물건이다. 세 층을 명시적으로 분리하고, 중간층(subgoal 문법)을 벤치의 공식 계약으로 고정한다.
╔═ Layer 0 — 사용자 발화 (벤치마크가 배포하는 것) ═══════════════════╗
"평소대로 해줘" / "내 열쇠 좀 가져다줘" / "손님용 컵 꺼내놔"
→ 자연스럽고, 불완전하고, 메모리 없이는 접지 불가능해야 한다
╔═ Layer 1 — Planner (VLM) I/O ══════════════════════════════════════╗
[SYSTEM] household robot. home=val_640. now=Day14 07:02. budget=12 subgoals
[MEMORY] ← 검색된 레코드 top-k, 직렬화 (여기가 메서드마다 다른 유일한 부분)
[OBS] ← exo RGB + wrist RGB (+옵션: top-down semantic map crop)
[TRACE] ← 이번 에피소드에서 이미 실행한 subgoal 목록
[INSTR] ← Layer 0 발화 그대로
[OUTPUT] 다음 subgoal 정확히 1개 (아래 문법)
╔═ Layer 2 — VLA I/O (MolmoAct2 / π0.5) ═════════════════════════════╗
instruction : subgoal을 자연어로 렌더링한 1줄
"open the second drawer of the dresser"
images : exo + wrist (π0.5-DROID 규약: 2캠, right_wrist=zeros/mask=False)
state : (8,) = [q1..q7, gripper] // 모바일이면 base pose 추가
→ actions : (N, 8) absolute joint position
7.2 Subgoal 문법 — 벤치의 공식 계약
GOTO / MOVE_TO (<room> | <receptacle_id> | <pose>) → Navigate-to
FIND (<object_query>) → 탐색 (memory miss 시)
OPEN / CLOSE (<receptacle_id>[/joint_<jj>]) → Open / Close / Open-door
PICK (<instance_id>) → Pick
PLACE (<instance_id>, <receptacle_id>, on|in|next_to|under)
→ Pick-and-place(-next-to)
TOGGLE (<device_id>, on|off) → ★신규 success fn 필요
─────────────────────────── 비물리 ───────────────────────────
MEM_QUERY (scope=entity|event|behavior, key=..., t_range=..., topk=k)
MEM_WRITE (<record>)
ASK (<question>)
DONE (success | impossible, <reason>)
왜 MEM_QUERY / MEM_WRITE를 행동 공간에 넣는가
메모리를 각 메서드의 내부 구현으로 두면, 벤치는 최종 성공률만 볼 수 있고 "왜 실패했는지"를 못 잰다. v1에서 순위가 두 번 뒤집힌 이유도 여기에 가깝다 — 메모리가 실제로 뭘 담고 있는지 관측 불가능했다.
메모리 연산을 관측 가능한 행동으로 승격하면 세 가지가 생긴다. ① 검색 정밀도/재현율을 GT 레코드와 대조해 태스크 성공과 분리해 잴 수 있다. ② "검색은 맞았는데 계획이 틀렸다" vs "애초에 못 찾았다"를 구분할 수 있다. ③ writer 정책(무엇을 적었나)이 로그로 남아 §8의 연구 타깃이 직접 관측된다. 비용은 메서드가 이 인터페이스에 맞춰야 한다는 제약 하나뿐이고, RAG·keyframe·텍스트로그 모두 이 인터페이스로 표현된다.
7.3 메모리 레코드 스키마
// Entity
{"id":"e_0421", "t":"D07T09:14", "type":"entity",
"subject":{"instance_id":"inst:obja:mug_0163:0", "label":"파란 무지 머그",
"embed":"<siglip-256d>"},
"predicate":"located_in",
"object":{"receptacle_id":"Kitchen/Cabinet_07", "relation":"in",
"xyz":[2.13,1.44,-0.72], "room":"Kitchen"},
"evidence":{"episode":"ep_0033","frame":417,"bbox":[...],"conf":0.83},
"source":"agent_observation"}
// Event — actor는 agent | user | unobserved
{"id":"v_0117", "t":"D09T16:03", "type":"event", "actor":"agent",
"verb":"open", "args":["Kitchen/Fridge_01/joint_02"],
"post_state":{"joint_02":0.62}, "episode":"ep_0041"}
// Behavior — support/contradiction이 P2 conflict 해결의 근거가 된다
{"id":"b_0009", "type":"behavior", "rule":"place(Plate) -> Kitchen/Cabinet_02",
"support":7, "contradictions":0, "confidence":0.88,
"induced_from":["ep_0004","ep_0011",...],
"override":{"t":"D13T20:00","source":"user_utterance","text":"당분간 커피는 끊을게"}}
7.4 지시문 자연어 규약 (VLA에 실제로 들어가는 문자열)
π0.5는 프롬프트 문구에 극도로 민감하다 — MolmoSpaces 논문 Figure 13에 따르면 DROID에 자주 나오는 문구를 쓰면 π0가 π0.5와 1% 이내로 붙고, 아니면 14% 격차가 난다. 따라서 subgoal → 자연어 렌더링 템플릿은 임의로 쓰면 안 되고, DROID/MolmoSpaces 학습 분포의 문구를 그대로 따라야 한다. 이 템플릿을 벤치 코드에 고정하고 버전을 박는다. 안 그러면 "메모리 방법 차이"로 보고한 숫자가 실은 프롬프트 문구 차이가 된다.
8 학습이 필요한가 — 컴포넌트별 판정
질문을 "학습이 필요한가"에서 "우리 GPU 예산을 어디에 쓸 것인가"로 바꿔야 답이 나온다. 결론부터: 저수준 VLA에는 쓰지 않는다.
| 컴포넌트 | 학습? | 근거 | 방법 / 비용 |
|---|---|---|---|
| 저수준 조작 VLA | 재사용 | MolmoAct2가 MolmoSpace 1st VLA. lab에 π0.5-FT 트랙(15K step, 36.0%)이 이미 있음. 여기 더 태워도 벤치의 메모리 신호는 안 는다 | 기존 체크포인트 그대로. TOGGLE·다단관절만 소량 FT 검토 |
| Navigation | 부분 | MolmoSpaces에 RING / DualVLN 항법 베이스라인 존재. N0/N1은 학습 0 | §10 참조. N2만 학습 대상 |
| VLM 플래너 | 불필요(먼저) | Molmo2-ER / GPT급이 zero-shot으로 subgoal 문법을 따라온다. 프롬프트 베이스라인이 먼저 나와야 학습의 필요성을 증명할 수 있다 | 프롬프트 + few-shot. API 스윕 §9.4 |
| 메모리 writer (무엇을 적을 것인가) | ★핵심 | v1에서 승패를 가른 유일한 변수가 커버리지였다 — 로그 ~23 이벤트 vs keyframe ≤8장. "전부 적기"는 컨텍스트를 터뜨리고, "적게 적기"는 C9/C4를 놓친다 | salience 정책 학습. 라벨은 사후 유용성(그 레코드가 나중 쿼리에 실제로 쓰였나)에서 자동 생성 가능 |
| 메모리 retriever | ★핵심 | H3에서 720+ 이벤트는 컨텍스트를 넘는다. 검색 없이는 D4 장치에 전멸 | 쿼리 재작성 + 하이브리드(임베딩+시간+공간) 검색. GT 레코드가 있으니 지도학습 가능 |
| 인스턴스 re-ID | 학습 불필요할 수도 | C9(머그 5개)에 직결. DINOv2/SigLIP crop 임베딩 + 매칭으로 학습 없이 상당 수준 가능 | 먼저 학습 없이 측정 → 부족하면 대조학습 |
| 행동 규칙 귀납 | 프롬프트 먼저 | 이벤트 로그를 주고 "규칙을 뽑아라"는 LLM이 꽤 한다. C7의 P2 conflict에서 무너질 가능성이 높고, 그 실패가 논문의 발견이 된다 | 프롬프트 → 실패 분석 → 필요시 학습 |
가장 중요한 베이스라인 3종 — 이게 헤드라인 그림이 된다
- Blind (메모리 0) — 하한. control이 chance 근처인지 검증하는 A4 게이트 겸용.
- Oracle-memory (GT 레코드를 그대로 주입) — 상한. 이게 결정적이다: 실패가 메모리 탓인지 제어/계획 탓인지를 분리해준다. 오라클 상한이 낮으면 그건 메모리 연구가 아니라 VLA 연구를 해야 한다는 뜻이다.
- Text-log oracle (자기 행동을 한 줄씩 적은 로그 전량) — v1의 최강자(0.564). A2의 포화 감시자.
9 데이터 생성 파이프라인
9.1 7단계
[1] 씬 샘플링 ProcTHOR/MolmoSpaces에서 방 2~4개 하우스 추출
→ 인스턴스 주소체계(§4.3) 확정 → scene_manifest.json 동결
[2] persona 구성 거주자 수, 스케줄, 선호 규칙 N개를 규칙 템플릿 뱅크에서 샘플
storage_pref(type→receptacle) / no_go(receptacle)
time_routine(t, [subgoal...]) / owner(instance→person)
→ 규칙은 test 집에서 train과 겹치지 않게 (일반화 스플릿 3축 중 1)
[3] Life 롤아웃 Day 루프: write 에피소드는 오라클 플래너가 실행(물리 시뮬),
mutate는 상태 델타 직접 적용(관측 여부 플래그 포함)
→ 물리적으로 일관된 상태만 남음 (기호 시뮬 아님)
[4] GT 추출 시뮬을 우리가 굴렸으므로 GT가 공짜로 나온다:
entity 결합 시계열 / event 로그 / 잠재 behavior 규칙
→ 자동 채점 + Oracle 상한 + 메모리 F1이 전부 여기서 나온다
[5] 질의 생성 GT에서 템플릿 생성 → LLM 패러프레이즈(자연스러움)
→ 반사실 짝(A6) 자동 생성: 씨앗 이벤트 1개를 제거/치환
[6] 게이트 F1 현재관측 / F2 상식prior / F3 blind / 누출스캐너 / 짝 정합성
→ 통과 못 하면 폐기. 통과율이 곧 생성기 품질 지표
[7] 전문가 궤적 (train split만) GT 상태 → navmesh 최단경로 + 오라클 조작
→ subgoal 시퀀스 + 원시 액션 라벨
9.2 규모
| Pilot (Phase 0) | Test | Dev | Train | |
|---|---|---|---|---|
| 집 | 3 (val_640, val_375, FloorPlan30) | 30 (held-out) | 10 | 200 |
| Life 길이 | 14일 | 30일 (H3) / 14일 (H2) | 14일 | 30일 |
| write 에피소드 | ~170 | ~3,600 | ~560 | ~24,000 |
| read 쿼리 | 50 (전량 사람 검수) | 1,200 (짝 포함 → 600쌍) | 300 | — |
| 일반화 스플릿 | 3축 동시 held-out: 미관측 집 / 미관측 물체 인스턴스 / 미관측 선호 규칙 | |||
v1의 train/test 오염을 반복하지 않는다. π0.5 계획서에서 이미 "받은 데이터가 val split뿐인데 bench-v2도 전부 val"이라는 오염 위험이 확인됐다. 이번엔 house_id 단위 disjoint를 데이터 생성 시점에 강제하고, 매니페스트에 스플릿 소속을 기록한다.
9.3 저장 — GPFS 메타데이터를 먼저 계산한다
순진하게 프레임을 PNG로 저장하면 안 된다. v1 실측이 이미 경고를 줬다: 875 에피소드 = 45 GB / 48만 파일(소스는 5.2 GB), 본 규모 2.5만 ep 환산 ~1.3 TB / 1,370만 파일.
| 방식 | 용량 | 파일 수 | 판정 |
|---|---|---|---|
| PNG 프레임 (test 30채 기준) | ~195 GB | ~650만 | GPFS 메타데이터 부담 — 금지 (§15 취지) |
| 에피소드당 mp4 ×2캠 | ~30–60 GB | 7,200 | 채택 |
| 시드로 재생성 (프레임 미저장) | ~0 | — | 결정론 보장되면 최선. 렌더 재현성 검증 필요 |
산정: test 30채 × 30일 × 4 write ep × ~900 step × 2캠 ≈ 650만 프레임. mp4 인코딩 시 v1의 45 GB/480k PNG → 15 GB 비율을 적용.
9.4 비용 — API 메서드 1회 스윕
v1 실측 게이트웨이 단가 $0.019/call을 그대로 쓴다.
write walk (집당) : 30일 × 4 ep × ~6 fine step ≈ 720 call × $0.019 ≈ $13.7
test 30채 : ≈ $410
read 쿼리 1,200건 : 1,200 × ~$0.02 ≈ $24
────────────────────────────────────────────────────────────
1 메서드 1 스윕 ≈ $435 4 메서드 ≈ $1,740
비용 절감의 유일한 큰 레버: write-phase 메모리 구축 결과를 같은 집의 모든 read 쿼리가 공유하도록 캐시한다(v1의 "3-test 공유 walk"와 같은 발상, 스케일만 다름). 이걸 안 하면 40쿼리 × 720콜 = 집당 $547이 되어 30채에 $16k가 든다. 37배 차이다. 캐시 키에 dataset content hash 포함(§A4).
9.5 시뮬레이션 예산 (Tier B/C)
S3 에피소드 = 8 base task × 300 step = 2,400 step
π0.5 action chunk 10 step, 추론 ~0.1 s/chunk → 240 chunk ≈ 24 s (정책)
+ MuJoCo 물리 + 2캠 렌더 → 실측 전 보수 추정 2–4 분/에피소드
1,200 에피소드 × 3 분 = 60 h (1 env)
8× B200 병렬 (GPU당 env 1~2) → 4–8 h / 1회 전체 평가
``` sbm "bash scripts/eval_tierB.sh" --gres=gpu:8 -c 64 --mem 1600GB --qos=extra ```
※ 추정치. Phase 1 스모크에서 sjob -v로 GPU util을 봐서 렌더 바운드인지 정책 바운드인지 먼저 판정할 것 — π0.5 학습 계획서에서도 진짜 병목이 dataloader일 가능성이 지적됐다.
10 네비게이션 설계
10.1 먼저 짚어야 할 것 — 항법은 메모리 벤치에서 제어 문제가 아니라 결정 문제다
scene_navi는 transit 구간을 목적지를 모르는 ego 모터 명령 시퀀스(forward/backward/left/right/turn_left/turn_right/stop)로 분해했다. 그 설계의 핵심 통찰 — "ego 상대 명령은 stitching(좌표 재배치)에 불변" — 은 지금도 유효하고 재사용 가치가 크다.
그런데 메모리 벤치에서는 그것만으로는 안 된다. 명령 시퀀스를 주는 순간 "어디로 갈지"가 이미 정해진 것이고, 메모리가 답해야 할 질문이 사라진다. 메모리를 재려면 에이전트가 목적지를 스스로 정해야 한다.
따라서 역할 분담을 이렇게 둔다: 목적지 결정 = 메모리(평가 대상), 목적지까지 가기 = 항법 모듈(플러그 교체 가능). 그리고 scene_navi의 7-vocab은 후자의 인터페이스로, 그 데이터 생성 파이프라인은 후자의 학습 데이터원으로 이식한다.
10.2 항법 3단 — 전부 같은 MOVE_TO 인터페이스
MolmoSpaces의 모바일 플랫폼(Rainbow RB-Y1, 홀로노믹)은 absolute 또는 relative pose 명령을 받는다. 따라서 MOVE_TO는 어느 단계에서도 결국 pose goal로 환원된다 — 세 구현이 서로 드롭인 교체 가능하다.
| 구현 | 학습 | 측정되는 것 | 쓰는 Tier | |
|---|---|---|---|---|
| N0 | 스테이션 텔레포트 — 리셉터클마다 미리 계산한 standing pose로 베이스를 세팅. 비용 = navmesh geodesic 거리 | 없음 | 목적지 선택만. 제어 노이즈 0 | A, B-lite |
| N1 | navmesh pose-goal — 메모리 → 2D goal pose → A* + 홀로노믹 컨트롤러 | 없음 | + 실제 경로 길이, 충돌 | B (기본) |
| N2 | 학습 ego 정책 — RGB만 보고 7-vocab 명령 방출. memory-miss 시 FIND는 frontier/semantic 탐색 | 필요 | + 지각 기반 접지, 미관측 집 일반화 | C |
왜 N0를 기본으로 두는가: 메모리 방법 A와 B를 비교하는 게 목적인데, 두 방법 모두 같은 항법 노이즈를 겪으면 그 노이즈가 신호를 덮는다. N0는 항법 분산을 0으로 만들어 메모리 차이만 남긴다. 그리고 geodesic 비용은 navmesh에서 정확히 계산되므로 SPL은 N0에서도 완전히 측정된다 — 즉 §6 C10의 핵심 메트릭을 물리 롤아웃 없이 얻는다.
10.3 N2 학습 — scene_navi 파이프라인의 이식
전문가 데이터 생성 (train split, 자동)
GT 메모리 → 오라클 목적지 → navmesh 최단경로
→ body-frame 속도 시계열로 변환 → 이벤트 기반 양자화
→ 7-vocab 명령 + frame 구간 ← scene_navi/tmp/generate_combo.py 로직 이식
→ (RGB window, 명령) 쌍으로 IL
체크: scene_navi는 "축정렬 재생성"(한 번에 한 축)으로 커버리지 100%를 얻었다.
MolmoSpaces 홀로노믹 베이스에서도 같은 단순화를 적용할지 결정 필요.
- 적용 O → 라벨 깨끗, 모션 부자연(stop-and-go)
- 적용 X → 자연스럽지만 turn+병진 동시 구간에서 병진 손실 (v1에서 실측된 문제)
→ 권고: 학습 데이터는 축정렬, 평가는 자유 모션 (라벨 품질 우선)
10.4 항법에서 메모리가 쓰이는 두 지점
- 읽기 —
MOVE_TO목적지 결정. 여기가 평가 대상. - 쓰기 — 방을 지나가며 본 물체를 메모리에 적는다. 이게 사실상 mapping이다. 권고 구현: Molmo2-ER의 pointing으로 2D 접지 → depth로 3D 리프트 → 인스턴스 레코드 생성. MolmoAct2-Think의 depth-token reasoning이 대안.
10.5 항법 전용 메트릭
| 메트릭 | 정의 | 왜 필요한가 |
|---|---|---|
| First-Goal Correctness | 첫 MOVE_TO 목적지에 타깃이 실제로 있었나 | 메모리를 가장 직접적으로 재는 단일 숫자. 제어와 완전히 무관 |
| Search Path Ratio | 실제 이동거리 / 오라클 geodesic | SR이 포화해도 살아남는 신호 (C10) |
| SPL | SR × L_oracle / max(L, L_oracle) | 관례적 비교용 |
| Room Revisit Count | 같은 방 재진입 횟수 | 기억 없이 배회하는 패턴 탐지 |
11 채점 — 메트릭과 게이트
| 메트릭 | 적용 | 비고 |
|---|---|---|
| SR / GC | 전체 / S2+ | GC = subgoal 단위 부분점 (ALFRED 방식) |
| Paired Accuracy | 반사실 짝 전체 | 헤드라인. 둘 다 맞아야 1점 |
| First-Goal Correctness | 이동 포함 전체 | 헤드라인. 제어와 분리된 메모리 신호 |
| Search Path Ratio / SPL | 이동 포함 전체 | 헤드라인. SR 포화 대비 |
| Memory Retrieval P/R/F1 | MEM_QUERY 사용 메서드 | GT 레코드 대조. 검색 실패 vs 계획 실패 분리 |
| Stale-Detection Rate | P1 | 재탐색 성공률 |
| Conflict Resolution Acc | P2 | 최신/명시 발화 우선했나 |
| Abstention 2×2 | P3 + 짝 | 정당기권 / 과잉기권 / 과소기권 / 무모실행 |
| PCR | Behavior | SR과 독립 보고 |
| re-ID Accuracy | D1 셀 | 동종 인스턴스 지목 |
| Safety Violations | 전체 | 절대 평균에 섞지 않는다. taboo 위반 / 파손 / 문 열어둠 / 오작동 기기 |
| forced_recovery_count | Tier C | teacher-forced 복구 횟수 (제어 품질 지표) |
합성 점수 하나로 발표하지 않는다. "LTM score" 하나를 만들 수는 있지만, 리더보드에는 반드시 위 성분표를 함께 띄운다. 안 그러면 안전 위반 30%짜리 정책이 1등을 한다.
릴리즈 차단 게이트 (전부 자동)
G1 blind-control ≤ chance + ε ← 아니면 배치 재샘플
G2 현재관측-only VLM 정확도 ≤ chance + ε ← A1/F1
G3 텍스트-prior LLM(무이미지·무메모리) ≤ chance+ε ← A1/F2
G4 누출 스캐너 위반 0건 ← v1 recipe leak 재발 방지
G5 모든 핵심 인스턴스가 반사실 짝을 가진다 ← A6
G6 text-log oracle < 0.70 ← A2 포화 감시
G7 oracle-memory 상한 ≥ 0.80 (Tier A 기준) ← 상한이 낮으면 메모리 문제가 아님
12 리스크 & 선행 확인 항목
아래 R1–R3은 설계를 바꿀 수 있는 미확인 사항이다. Phase 0의 첫 3일 안에 코드/실측으로 확정해야 한다 — 추측으로 진행하면 안 된다.
| # | 리스크 | 영향 | 확인 방법 / 대안 |
|---|---|---|---|
| R1 | 치명 MolmoSpaces가 씬 상태 저장/복원을 지원하는가? 에피소드 종료 후 물체 위치·관절각을 그대로 이어받을 수 있어야 Life 프로토콜이 성립 | 없으면 벤치 자체가 불가 | env API에서 state serialize/deserialize 확인. 없으면 우리가 scene state serializer를 만든다(물체 pose + 관절 qpos + 인스턴스 매핑). 난이도 중, 필수 |
| R2 | 치명 embodiment 불일치. 우리 π0.5-FT는 Franka DROID 규약(2캠 / 8-D state / absolute joint pos)인데, 모바일 조작은 RB-Y1 bimanual holonomic이다 | 모바일 조작 정책이 없으면 Tier C 불가 | ① MolmoAct2/π0.5의 RB-Y1 체크포인트 존재 여부 확인 ② 없으면 Franka + N0 스테이션 텔레포트로 후퇴 — 이 경우에도 §6 사례 10개는 전부 그대로 성립한다(항법이 결정 문제로 남으므로). 설계가 이 후퇴를 견디도록 짜여 있다 |
| R3 | TOGGLE(커피머신 ON 같은 상태 토글)이 MuJoCo 포팅본에 존재하는가 | C7 루틴 과제가 약해짐 | 없으면 TOGGLE을 "버튼 리셉터클에 접촉" 같은 물리 대리 이벤트로 정의하거나, 해당 스텝을 PLACE 계열로 치환 |
| R4 | Objaverse 카테고리 노이즈 (5,491종 중 household 유효분 ~1,379종/20,890자산, 그마저 decorative * 다수) | C9 같은 인스턴스 과제의 자연스러움 저하 | Phase 0에서 300–500 카테고리 화이트리스트 큐레이션. 실제 작업량 있음 |
| R5 | 조명/시간대 랜덤화가 인스턴스 re-ID를 깨뜨림 | C9 점수가 메모리가 아니라 조명 강건성을 측정하게 됨 | Life 내 조명은 고정, 조명 변화는 별도 ablation 축으로 분리 |
| R6 | GPFS 메타데이터 폭증 (v1: 875 ep = 48만 파일) | 공유 NAS 전체 영향 | mp4 저장 확정 (§9.3). PNG 금지 |
| R7 | Compounding 붕괴로 Tier C가 전부 0점 | 벤치 무정보화 | teacher-forced 복구 + Tier A/B 병행 (§A3). 이미 설계에 반영됨 |
| R8 | API 비용 폭증 | 스윕 불가 | write-phase 메모리 공유 캐시 (§9.4, 37배 차이) |
| R9 | π0.5 프롬프트 문구 민감도 (DROID 문구 여부로 14% 차이) | 메모리 차이로 오인 | subgoal→자연어 템플릿을 코드에 고정 + 버전 태그 (§7.4) |
13 로드맵
| Phase | 내용 | 기간 | 통과 게이트 |
|---|---|---|---|
| 0 · 블로커 | R1/R2/R3 실측 확정. MolmoSpaces env에서 씬 상태 save/restore 왕복 검증. 로봇 embodiment 확정. household 화이트리스트 초안 | 3–5일 | save→mutate→restore 후 물체 pose/관절각 bit-level 일치. embodiment 결정 문서화 |
| 1 · 파일럿 | 집 3채 × 14일 Life. §6 사례 10종을 손으로 완성 + 50 쿼리 전량 사람 검수. Tier A 하네스 + Blind/Oracle/Text-log 3 베이스라인 | 2주 | Blind ≪ 메서드 ≪ Oracle 갭이 실제로 존재. text-log < 0.70. 없으면 설계로 되돌아간다 |
| 2 · 생성기 | persona/규칙 뱅크 + Life 롤아웃 자동화 + 질의 생성 + 게이트 7종 자동화. test 30채 / dev 10채 | 4주 | 게이트 통과율 리포트. 1,200 쿼리(600쌍) 확보. 10% 사람 검수 통과 |
| 3 · 하네스 | Tier B(N0/N1 항법) + Tier C(teacher-forced) 구현. MolmoAct2 / π0.5-FT 연결. 전 메트릭 리포터 | 3주 | Tier B 1,200 ep 완주 < 8 h (8× B200). forced_recovery 로깅 정상 |
| 4 · 확장/공개 | train split 200채 + 전문가 궤적. writer/retriever 학습 실험. 리더보드 + 데이터셋 릴리즈 | 4주+ | 학습 메서드가 프롬프트 베이스라인을 유의하게 상회 |
Phase 1의 게이트가 진짜 게이트다. 집 3채·50쿼리 규모에서 Blind → 메서드 → Oracle 갭이 안 보이면, 30채로 늘려도 안 보인다. v1은 이 검증 없이 규모부터 키웠다가 "측정이 메모리를 안 재고 있었다"를 두 번 발견했다. Phase 1을 통과 못 하면 Phase 2로 넘어가지 않는다.
14 Takeaway
이 설계가 거는 세 개의 베팅
① "새 시뮬레이터를 만들지 않는다." MolmoSpaces-Bench의 8개 base task를 subgoal 문법으로 그대로 흡수하면 success function·컨트롤러·sim2real 신뢰도(R²≈0.96)·SOTA 정책을 전부 상속받는다. 우리가 짓는 건 지속성 레이어 하나다. 이게 8주 계획과 6개월 계획을 가른다.
② "메모리를 제어에서 분리하지 않으면 아무것도 못 잰다." π0.5-FT의 36% × 8단계 = 0.03%라는 산수가 이걸 강제한다. 3-Tier 하네스, oracle-memory 상한, teacher-forced 복구, 그리고 SR 대신 First-Goal Correctness·경로비를 헤드라인으로 올리는 선택은 모두 이 하나의 제약에서 나왔다.
③ "v1이 진 상대(텍스트 로그)를 처음부터 링에 올린다." M3v2가 0.564로 이겼던 건 알고리즘이 좋아서가 아니라 커버리지가 넓어서였다. 그러니 v2는 텍스트 로그를 공식 상한 베이스라인으로 박아두고, 그것이 원리적으로 풀 수 없는 4종 장치(인스턴스 재식별·관절 단위 상태·기하 정밀도·컨텍스트 초과)를 데이터에 심는다. 그러면 "무엇을 적을 것인가"가 자동으로 연구 질문이 되고, GPU를 저수준 VLA가 아니라 writer/retriever에 쓰는 근거가 생긴다.
가장 값싼 다음 한 걸음: Phase 0의 R1(씬 상태 save/restore) 확인. 이게 되면 나머지 전부가 실행 가능해지고, 안 되면 그 serializer를 만드는 것이 이 프로젝트의 첫 코드가 된다. 어느 쪽이든 3–5일 안에 답이 나오고 그 답이 다음 4주를 결정한다.
확정된 결정
[260810] scene-mem v1과 완전 별도 벤치로 간다. 시뮬레이터·로봇·평가 방식이 전부 다르므로(RoboCasa offline video QA → MolmoSpaces embodied) 별도 트랙으로 세운다. 실무적 함의가 크다 — 879 릴리즈의 fine annotation 재생성 블로커와 완전히 분리되어 Phase 0을 즉시 착수할 수 있다. v1은 관련연구/모티베이션으로만 인용하고, v1 측정치(M3v2 0.564 등)는 설계 근거로만 쓰지 baseline 표에 옮기지 않는다 — 에피소드와 substrate가 달라 이식 불가하기 때문이며, 이는 v1 자체에서 "ID가 공통이어도 다른 에피소드 → 구 측정치 전부 이식 불가"로 이미 확인된 사실이다.
미해결 — 사용자 결정이 필요한 지점
- embodiment: RB-Y1 모바일로 갈 것인가, Franka + N0 스테이션 텔레포트로 단순화할 것인가. 후자는 사례 10종을 그대로 유지하면서 R2 리스크를 제거하지만 "mobile manipulation" 주장은 약해진다. R2 실측 선행 — 체크포인트 존재 여부가 확인되기 전에는 결정하지 않는다.
- Behavior 규칙 출처: §5.3의 "에이전트 자기 실행 + 언어 교정" 2채널 안을 확정할 것인가, 아니면 사람 아바타 관찰까지 넣을 것인가(비용 급증).
- 씬 규모: 후보 14채로 Phase 0–1을 진행하는 데는 동의하지만, Phase 2의 test 30채를 어디서 뽑을지(ProcTHOR 재샘플 vs 기존 14채 확장)를 정해야 persona 뱅크 설계가 확정된다.