SceneMem

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

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 외부 평가에서 나옴

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

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

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

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 재생성 전까지 재현 불가.

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

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

메모리가 어떻게 저장되고(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).

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에서만 깨끗이 변별. 상식차단 필요.

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).

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).

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 보정 → 재측정

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