SceneMem — Reports

260817 — 260823 3 reports · 24 tables 3

contexts/ 5편(1.2GB) 위에 find 18행 · restore 11행 · resume 7행이 얹힌 구조를 실물 파일로 해부하고, 가족별 실제 행 하나를 프레임 그림과 함께 끝까지 따라간 뒤 문서-실물 불일치 7건을 정리. 아직 없는 네 번째 가족 routine(D1 배치 규칙)의 설계 제안을 val_406__0의 실측 배치 3/5로 근거를 세워 스키마 초안까지 붙임

16 tables

08-21 analysis

샘플 해부에서 확정한 실측치를 계획 통계에 붙여 외부 벤치마크와 비교

Scene-Mem 벤치마크 포지셔닝

에피소드 길이 10,520~17,250 스텝(420~690초)으로 2위 RoboMemArena(1,076)의 10~16배, 고유 질의 약 1,160개로 RoboCasa365(365 task)의 3.2배 — CALVIN/LIBERO-Long/RoboCasa365/RoboMME/RoboMemArena/LongAct 6종과 길이·개수·집 다양성 3축 비교, routine ~90행 추정 근거 포함

5 tables

08-17 exp

pi0.5 × MolmoSpaces — Phase 5 본 학습 완료 + 최종 checkpoint validation

pi0.5×MolmoSpaces Phase 5 본 학습(15k step, job 68392) 16h18m 만에 완주 — loss 1.6255→0.0026. 최종 checkpoint(14999) validation: action L1 0.0193 vs zero-motion baseline 0.0785 → \1 (context.md 통과선 1.5x 대비 여유 확보). held-out split은 없어 fit-sanity 수준이며, 진짜 검증은 bench-v2 외부 평가에서 나옴

3 tables

260810 — 260816 1 report · 4 tables 1

08-11 analysis

학습 데이터 ↔ bench-v2 태스크 대응 분석

학습 4계열은 프레임 기준 Pick 35%/PnP 65%로 비대칭이고, 계획된 평가 세트의 Open/Close는 학습 데이터가 0% — \1가 RBY1M이라 확정.

4 tables

260803 — 260809 2 reports · 7 tables 2

08-03 analysis

변환 파이프라인 전면 실패 원인 분석 + Phase 3 선행 준비

변환 96/96 샤드 전멸을 잡 상태가 \1로 은폐 — 원인 3중(빈 \1, \1 종료코드 삼킴, \1에 걸려 실행 못한 merge 가드) 규명 후 데이터 손실 0으로 복구, Phase 3 블로커 3개도 선제 제거

2 tables

08-03 plan

pi0.5 × MolmoSpaces 파인튜닝 — 구현 계획 재수립 (TRAIN_PLAN_V2)

pi0.5 × MolmoSpaces 파인튜닝 계획 재수립 — GPU가 7×3090→8×B200으로 바뀌어 full FT가 1장에 들어가고, 카메라는 2뷰로 확정, DROID \1 norm stats는 재사용하되 \1 stats는 joint velocity라 사용 금지. 기존 LeRobot 변환에서 오류 4건 발견.

5 tables

260727 — 260802 4 reports · 29 tables 4

07-28 progress

SceneMem API 트랙 — 전체 진행 정리

SceneMem API 트랙 전체 정리: 측정 파이프라인 버그 3개(recipe leak/over-advance/파서)를 잡아 회상 측정을 유효화하고 새 메서드 \1(tagged-keyframe+검색) 구현 — place_acc control 0.154 / m2 0.308 / ours 0.462 / m3v2 0.564. ※수치는 구 858 데이터셋 기준, 현재 879로 교체돼 fine annotation 재생성 전까지 재현 불가.

6 tables

07-28 progress

Scene-Mem API 트랙 — 전체 정리 (260519→260727)

Scene-Mem API 트랙 전체 정리 (260519~260727). 측정 버그 4개를 연달아 잡으며 결론이 두 번 뒤집힘: '\1 최고' → (leadup 수정) next-subtask는 메모리를 아예 안 잼 → (recall 재설계 + fine walk) 텍스트 로그 \1 0.564 최고, 우리 메서드 \1 0.462로 시각계 1위. 현재 블로커 = 879 신 릴리즈 fine annotation 재생성.

6 tables

07-28 eng

전체 정리 → 런타임 동작 상세 해부

Scene-Mem 런타임 동작 완전 해부 (실측 트레이스)

파이프라인이 실제로 어떻게 도는지 코드+실측 트레이스로 완전 해부: 비디오 2Hz 3-cam composite 샘플링 → 콜당 8장 base64 → structured output → 메모리 5종 저장 → 회상. 프레임 인덱스 동기화 산술, leadup shift, M2 eviction 실증, ours 검색 실측 포함. ⚠️ 부수 발견: \1가 이미 879 릴리즈를 가리켜 현재 파이프라인 실행 불가.

12 tables

07-27 eng

SceneMem 879-scenario 릴리즈 재다운로드 및 구버전 대조

HF \1이 879-scenario 릴리즈로 갱신되어 24GB 전체 재다운로드 + 8803/8803 검증 완료. ID 공통 623개조차 영상이 100% 재생성되어 구 측정치·\1 858개 전부 이식 불가 — fine annotation 재생성이 이행 블로커.

5 tables

260622 — 260628 5 reports · 14 tables 5

06-24 exp

Scene-Mem — 메모리 저장 구조 & 회상 결과 시각화 (260624)

메모리가 어떻게 저장되고(control 없음/M1 균일샘플/M2 keyframe/M3v2 append 로그) 회상 결과로 어떻게 이어지는지 시각화. 저장 충실도가 회상을 결정: M2(중요프레임 보관) 최고. M2 병목=sparse nomination(8칸 중 3~5칸만)→forced-M2(무조건찍기+cap16)로 5.3→12.6칸 채움, place_acc 0.179→0.23(소폭). M3v2 append도 walk가 세그먼트당 1콜이라 steak 배치 누락. 절대정확도는 여전히 낮음(상식누수+anchor).

3 tables

06-25 exp

메모리 저장/회상 측정의 후속 — fine-walk 풀 스윕

Fine-walk recall 스윕: 텍스트 메모리가 시각 메모리를 3배 압도

diverse12 fine-walk recall 스윕(n=39): 텍스트 메모리 \1 place_acc 0.564로 시각 메모리 \1(0.179) 3.1배 압도. m3v2는 39개 중 14개를 혼자 맞춤(36%). 원인 = 정보밀도: m3v2 로그 평균 23.5줄(거의 전 행동 기록) vs m2 keyframe 5.4장.

4 tables

06-23 exp

Scene-Mem — recall-report 메모리 비교 (260623)

recall-report(과거배치 회상)로 메모리 메서드 비교(control/m1/m2/m3v2/m3, 3 시나리오). place_acc: control 0 / m3(망각) 0 / m1 0.22 / m3v2 0.22 / m2(keyframe) 0.44. → 메모리는 유효(보존형>무보존), M2 최고(next-subtask에선 해롭던 게 recall에선 1등=필요할때만 도움). 단 신호 작고 steak(상식누수)·bowl(마지막프레임 anchor) 교란 — fish에서만 깨끗이 변별. 상식차단 필요.

2 tables

06-23 exp

Scene-Mem — leadup STATE 윈도 보정 (over-advance fix) · 260623

M3/control이 강모델에서 slot=0으로 붕괴한 진짜 원인은 메모리가 아니라 **채점 STATE 윈도의 off-by-one**. 비율분할 chunk[tfi]가 행동 '완료' 장면을 보여줘서 모델이 tfi+1을 답함(over-advance). 윈도를 lead-up chunk[tfi-1]로 한 칸 당기는 \1 추가 → control slot 0.00→0.80, action 0.00→0.80. m3=control(텍스트 메모리 효과 0), m2(시각 keyframe)는 오히려 0.33로 악화(기존 'M2 best'는 깨진 측정하의 착시 가능성). 게이트웨이 estimated_cost로 정확 비용 로깅 추가($0.0192/call).

4 tables

260615 — 260621 2 reports · 40 tables 2

06-19 progress

Scene-Mem Inspector — 260619 (all rows)

34 tablesslides

06-19 exp

Scene-Mem — Recall + m3v2 S=100 (260619)

Recall mode(memer-style \1 query) 추가 + m3v2(sub-task log) 메서드 추가. S=100 16/18 셀 완료(2 셀 비용한도 미완). 발견: (1) recall slot ≈ 0 — 모델이 회상 질의를 next-action으로 응답 → prompt 재설계 필요, (2) M3 over-advance 진짜 원인은 **메모리가 아니라 walk sub-window 위치** (m3v2도 같은 패턴), (3) 비용 추정 8× 빗나감(~$38 → ~$300).

6 tables

260601 — 260607 1 report · 4 tables 1

06-02 progress

Scene-Mem API Track — Snapshot (260602)

Scene-Mem API 트랙 v2 스냅샷: hierarchical next-subtask 통합 프롬프트 + 메모리 4종(control/M1/M2/M3) × gemini 3세대 × S=100 완료. \1(MemER 시각 keyframe) 최고, \1(MEM 텍스트) 약모델 최고지만 강모델서 over-advance 붕괴. NEXT = M3 보정 → 재측정

4 tables

260525 — 260531 4 reports · 47 tables 4

260518 — 260524 7 reports · 23 tables 7

prompts combo_002_L29_S48_0006

05-19 research

awesome-memory-vla 전수 스캔 — SceneMem baseline 선별

awesome-memory-vla 61편 전수 스캔 → 코드/학습코드 유무로 SceneMem baseline 선별. \1 필수 추가, \1(모바일+코드), tabletop-short 다수=regime 공백이 novelty 근거

3 tables

05-19 plan

baseline scan → API 트랙 설계·구현계획 확정

Scene-Mem API Track — 설계 및 구현 계획

Scene-Mem API 트랙 설계·구현계획 확정: 메모리 3종(M1 subsample / M2 MemER keyframe / M3 MEM 압축 언어메모리) 비교, embodied 제거하고 final-task recall accuracy만 측정, TDD 18태스크