Index
2026-05-17 — Analysis

B1 Eval 최종 분석 — scene-mem v2 LoRA

5-defect 교정 saga · 최종 88.4%/97.2% · tier3b 대비 notchunked +60pp — memer

TL;DR

88.4%
m1 Final-Query
97.2%
m4 Chunked
77.1%
m4 Notchunked
95.2%
m2 Narration
100%
m3 KF Rate
0
Parse Fail

1 배경 / 목적

scene-mem v2 LoRA (eval_loss 0.0066, job 3993)가 실제로 압축-메모리에서 subtask를 recall하는지 robocasa sim / Pi0.5 없이 정량화. 핵심 질문: "prior task 영상을 메모리로 보고, 최종 질의를 자기 메모리만으로 올바른 fine subtask로 답하는가."

V1에는 GT fine 라벨이 없어 정확도 측정 자체가 불가능했다. V2가 검증된 fine_subtasks.json(858 scenario)을 만들어 비로소 B1 offline eval이 가능해졌다.

선행 문맥: 기존 카드 260516-scene_mem_v2_b1_eval.html은 초기 buggy rollout 결과 (m1 ~0.6%, chunked ~1%) — 방법론 결함으로 인한 artifact로 취소됨. 본 카드는 교정 후 최종 결과를 다룬다.

Held-out val 57 scenario / 189 test sample (train 801 scenario로만 학습 → train leak 0, 런타임 assert).

2 작업 내용

Eval Contract: builder-structure autoregressive

신뢰 가능한 숫자를 얻으려면 eval이 학습과 동일한 contract를 따라야 한다. 핵심 설계 결정:

eval은 빌더(build_scene_mem_v2.build_turns_for_test)를 그대로 재호출 → byte-identical turn 구조 - [system]: MemER contract (학습과 동일 함수 memer_eval.contract) - memory turn ×(N-1): Task: {segment composite instruction} + bounded-FIFO(=8) + wrist상/agentview_left하 320×360 - final turn ×1: Task: {eval_spec query} + 최종 메모리 이미지 autoregressive 생성: turn k → 모델이 직접 생성한 assistant 0..k-1을 context로 사용 GT/빌더 assistant는 절대 context에 안 들어감 (런타임 assert) → 모델이 자기 narration을 메모리로 쌓아 질의에 답하는 진짜 held-out 측정

5-Defect 교정 Saga (job 4039 → 4050 → 4071 → → 4192)

지표가 신뢰 가능하려면 contract가 학습과 일치해야 한다. orchestrator 독립검증(에이전트 self-report 불신)으로 5회 결함 차단:

1
Teacher-forced replay (job 4039) → ~100% artifact, 취소 GT 이전 턴을 context에 주입 → 모델이 정답을 보고 출력. eval_loss 0.0066 모델이 자명 ~100%. 즉각 취소.
2
OOD 카메라 (job 4050) → ~1.75% artifact, 취소 agentview L+R 320×180 사용. 학습은 wrist+left 320×360. 분포 mismatch가 거의 모든 정답을 막음.
3
Continuous per-frame rollout (job 4071) → ~0.6% artifact, 취소 학습은 memory turn=composite, 최종만 query. rollout은 모든 step에 query → contract mismatch → "X in the X" 붕괴 + keyframe rate 6.9%.
4
Orchestrator "final-query prompt mismatch" 가설 → 자기 정정 실데이터 확인: 학습이 최종 턴에 query를 실제 사용함 → 거짓 버그. 미보고 후 수정.
5
Builder-structure autoregressive (job 4192) → 최종 채택 코드 직접 판독으로 no-TF + builder-faithful 확정. 189/189 완료.
교훈: 표면 숫자(특히 극단값 ~0% or ~100%)는 방법론 결함의 신호다. 매번 실데이터/코드 직접 대조로만 인정했다.

Metric 정의 (what each number measures)

Metric측정 대상판정 기준
m1 final-query모든 prior memory 소비 후 최종 턴 current_subtask 정확도semantic scorer: verb-class + 모든 GT 객체 + GT fixture 전부 일치
m2 narration모든 memory 턴 narration 정확도동일 scorer, fine/composite 분리. composite 81%(긴 verbatim exact — 정상)
m3 keyframe모델 emit keyframe_positions vs 빌더 GTP/R/IoU + final turn emission rate
m4 chunked진짜 압축-memory recall — target이 PnP regex 매치 → FIFO 실제 통과동일 scorer. "진짜 메모리 recall"
m4 notchunkedFIFO에 없는 케이스 — 학습 prior로만 답 가능동일 scorer. "추측 floor"

3 결과

최종 수치 (job 4192, 189/189 completed, orchestrator 독립 재카운트 일치)

m1 Final-Query (PRIMARY)
88.36% (167/189)
m4 Chunked (진짜 memory)
97.17% (103/106)
m4 Notchunked (prior floor)
77.11% (64/83)
m2 Narration Overall
95.19%
m3 Keyframe P/R/IoU
0.94/0.92/0.89
m3 Final-KF Rate
100%
Parse Failures
0
Distinct Final Preds
34 / 189

tier3b vs V2 B1 비교 (chunked/notchunked 분해)

EvalOverallChunked (진짜 memory)Notchunked (prior)비고
Tier-3a (30-sample)97.9% (허수)long-context bypass, 진짜 memory loop 아님
Tier-3b (30-sample)64.9%100%17.1%dusting LoRA, PnP regex 커버리지 버그
V2 B1 (189 val)88.4%97.2%77.1%V2 LoRA, held-out val, autoregressive
chunked: tier3b 100% → V2 97.2% — 동급. 압축-FIFO에서의 recall은 V2에서도 거의 완벽하다.
notchunked: 17% → 77% (+60pp) — V2 fine subtask 라벨이 비-chunked(메모리에 없는) 케이스의 prior 추론까지 끌어올렸다. V2 재설계의 정량 가치.

Contract별 결과 추이 (방법론 결함의 영향)

JobContractm1m3 KF Rate결론
4039Teacher-forced replay~100% (artifact)취소
4050OOD 카메라 (agv L+R 320×180)~1.75%취소
4071Continuous rollout~0.6%6.9%취소
4192Builder-structure autoregressive88.4%100%최종
keyframe final-rate=100%는 분포 일치의 핵심 지표: OOD rollout에선 6.9%였고, 올바른 contract에서 100%로 복구됨. 모델이 메모리 메커니즘을 실제 가동중임을 확인.

추세: 129 → 142 → 189 증분에서 m1 89.2% → 89.4% → 88.4%로 안정 수렴. 마지막 배치에서 미세 하락(정상 분산).

4 Takeaway

0.6% → 88.4%는 모델이 아니라 eval contract의 차이

V2 LoRA는 세 가지 eval 오류(teacher-forced / OOD 카메라 / continuous rollout)에서 각각 ~100% / ~2% / ~0.6%를 보였다. 올바른 builder-structure autoregressive contract에서 88.4%가 나왔다. 같은 모델, 같은 체크포인트다. 숫자를 결론으로 받아들이기 전에 방법론을 검증해야 한다는 것의 구체적 사례.

V2 fine 라벨의 가치: notchunked +60pp

chunked(진짜 압축-memory recall)는 tier3b와 동급(97~100%). 차이는 notchunked(메모리에 없는 케이스)에서 나왔다 — 17% → 77%. 이 케이스는 모델이 학습 prior로 답하는 구간이다. V2의 95.7% fine 라벨이 prior 추론 품질까지 끌어올렸다는 직접 증거. V1의 ~7% 가비지가 이 구간을 망가뜨리고 있었을 것으로 추정된다.

Pi0.5 cascade에 대한 의미: m1(88.4%)은 Pi0.5에 전달되는 atomic subgoal 한 줄의 정확도다. scene-mem benchmark에서 모델이 한 번도 안 본 scenario(held-out val)에서 이 정확도가 나온다면, cascade의 "planner 정확도" 병목은 최소화됐다고 볼 수 있다.

5 Next Steps

B2: Pi0.5 cascade — 진짜 memory_success

B1은 sim/Pi0.5 없이 subtask 텍스트 정확도만 측정했다. B2는 MemER subgoal(88.4% 정확)을 Pi0.5 low-level policy에 실제로 전달해 robocasa sim에서 task 완료 여부(memory_success)를 측정한다. 병목이 planner(MemER)인지 executor(Pi0.5)인지 분리된다. 사용자 Pi0.5 V2 fine 재학습이 선행 조건.

m4 notchunked 77% 한계 분석

notchunked 케이스(83개)는 target이 FIFO를 통과하지 않아 모델이 학습 prior로 답한다. 77%는 prior 한계의 기저 성능이다. 이 케이스에서 틀린 23%의 패턴을 분석해 — instruction 표현 변형인지, task 클래스 편향인지 — V3 학습 데이터 방향을 결정할 수 있다.

m2 composite narration 81% (정상 범위)

composite narration(§7 verbatim 27 task)의 81%는 긴 원문을 semantic scorer가 exact match로 요구하는 구조적 특성으로 인한 것 — 실제 품질 저하 아님. 단, composite 입도 memory turn이 fine turn 대비 recall 신호를 약화시키는지 cascade 단계에서 별도 검증 예정.