M3는 카메라를 따르는가 — 반사실 궤적 실험

TL;DR

M3는 카메라를 실제로 따른다. 같은 클립을 같은 노이즈로 궤적만 바꿔 재생성하면 출력이 크게 움직이고(LPIPS 0.11–0.27) 실제 영상과의 거리도 함께 나빠진다. held-out과 한 번도 안 본 클립에서 동일.
반응은 M3의 메커니즘에 귀속된다. M1 대조군은 전 궤적에서 0.0000–0.0012 — 200–300배 차이. 두 arm이 공유하는 camera token으로는 설명되지 않는다.
쓰는 건 절대 위치가 아니라 창 안에서의 운동이다. 강체로 0.15 m 옮기는 offset만 무반응(0.0096). 원인: wrist 첫 프레임이 clean하게 주어져서 절대 위치는 이미 이미지 안에 있다.
M3의 oracle 성격이 날카로워졌다. wrist 카메라의 미래 운동 = action. M3가 받은 건 사실상 정답 action이었다.

0.2746

M3 reverse 반응

0.0005

M1 reverse 반응

0.0111

M3 offset 반응

120

생성 영상

unseen 클립

1 배경 / 목적

M3는 GT wrist pose를 먹고 M1 대비 wrist LPIPS를 44% 줄였다(0.2579 → 0.1438). 그런데 이 수치는 모든 validation 스텝에서 GT pose를 먹인 상태로 측정됐다. 전혀 다른 두 모델이 같은 곡선을 낸다:

가설 A
카메라에 따라 실제로 재투영하는 모델

가설 B
pose를 클립 지문으로 써서 암기를 도운 모델

학습 곡선으로는 구분이 안 된다. 구분하려면 학습 때 준 적 없는 카메라를 주고 생성시켜야 한다. 출력이 안 바뀌면 조건화는 장식이고 44%는 지문 덕분이다.

부차적으로, 지금까지의 held-out은 subset_10k의 꼬리 64개다. 학습엔 안 썼지만 129번 채점됐고 그걸 보면서 체크포인트를 골랐다 — 일반화 주장에는 약하다.

2 설계 — 실험이 성립하기 위한 세 조건

같은 노이즈

XWAMRunner.forward(seeds=...)로 클립마다 시드를 고정한다. 9프레임에서 노이즈 차이는 어떤 카메라 효과보다 크므로, 이게 없으면 두 생성물의 차이는 카메라가 아니라 노이즈다. gt vs 자기자신이 LPIPS 정확히 0.0000으로 나오는 것이 이 재현성의 확인.

두 채널을 함께

M3는 카메라를 wrist_viewmats(PRoPE query 회전)와 proprios(camera token, 첫 토큰만 clean하게 입력) 양쪽으로 받는다. 한쪽만 바꾸면 "카메라가 저기 갔다"와 "아니다"를 동시에 주는 모순이라 결과를 해석할 수 없다. 그래서 6D pose 하나를 변환하고 두 채널을 거기서 재생성한다.

궤적 크기는 추측이 아니라 측정 후 결정

처음엔 amplify(×2)를 크기 프로브로 넣었다. 실측해 보니 wrist 카메라는 9프레임 창에서 중앙값 3.2 cm만 움직이고 exo1 원점에서 0.57–0.74 m 떨어져 있다. 창 내 운동이 장면 규모의 5%라 ×2로는 3 cm를 더할 뿐 — 보이지 않는다. 그래서 offset(전체 궤적을 강체로 0.15 m = 시야각 약 14°)으로 교체했다.

궤적	바뀌는 것	보존되는 것
`gt`	—	—
`static`	창 내 운동 제거	frame 0 pose
`reverse`	시간 순서	경로 길이, 도달 pose 집합
`offset`	절대 위치 +0.15 m	프레임 간 상대 운동 (강체)
`swap`	전체 (다른 클립 카메라)	—

Unseen은 에피소드 단위로 제외

같은 에피소드의 다른 11프레임 창은 같은 장면·로봇·카메라 리그라 unseen이 아니다. 641,022개 중 subset의 8,381개 에피소드를 통째로 빼고 남은 441,671개에서 64개를 추출, 전부 디코딩 검증(64/64) 후 DA3 토큰을 별도 캐시에 만들었다.

M1도 같은 스윕을 돌린 이유

M1을 "카메라 없음"으로 부르기 쉽지만 아니다. use_camera_token은 모든 arm에서 켜져 있어 M1도 wrist frame 0의 pose를 clean proprio 토큰으로 받고, X-WAM의 global attention이 그 슬롯을 읽는다. M1이 없으면 반응을 M3의 메커니즘에 귀속시킬 수 없다.

3 결과

vs_gt_traj LPIPS = 같은 클립·같은 노이즈·진짜 카메라로 만든 생성물 대비 얼마나 달라졌나. 0이면 카메라 치환이 아무것도 안 바꿨다는 뜻. 각 6클립 중앙값. f0는 앵커(frame 0) 보존 여부 — reverse와 swap은 frame 0도 바꾸므로 앵커 조건이 달라진 성분이 섞인다. 깨끗한 비교군은 앵커 고정 4종.

궤적	f0	M1 held	M3 held	M1 unseen	M3 unseen
gt	—	0.0000	0.0000	0.0000	0.0000
offset 어디에 있나	✓	0.0001	0.0096	0.0002	0.0111
random_dir 어디로 가나	✓	0.0000	0.0630	0.0000	0.0982
static 움직이나	✓	0.0000	0.1118	0.0000	0.2035
jitter 매끄럽나	✓	0.0000	0.1234	0.0000	0.1061
swap	✗	0.0012	0.1519	0.0008	0.2189
reverse	✗	0.0001	0.2201	0.0005	0.2746

vs_real LPIPS = 실제 촬영 영상과의 거리.

궤적	M1 held	M3 held	M1 unseen	M3 unseen
gt	0.2210	0.0757	0.2422	0.1308
offset	0.2212	0.0797	0.2424	0.1343
random_dir	0.2210	0.1175	0.2422	0.1696
static	0.2210	0.1405	0.2422	0.2098
jitter	0.2210	0.2021	0.2422	0.1704
swap	0.2215	0.1823	0.2416	0.2408
reverse	0.2213	0.2519	0.2422	0.2991

1. M3는 카메라를 실제로 따른다. 궤적을 바꾸면 출력이 움직이고 실제 영상과의 거리도 함께 나빠진다. 무시하고 있다면 둘 다 안 변해야 한다. held-out과 unseen에서 동일하고 클립별로도 일관.

2. 반응은 M3의 메커니즘에 귀속된다. M1은 앵커 보존 궤적 네 개에서 정확히 0.0000(중앙값·최댓값 모두, 비트 동일). 이유가 완결적이다: M1은 use_query_prope=false라 wrist_viewmats를 안 읽고, proprio 토큰 1·2는 입력이 아니라 예측 타깃이라 샘플링 때 노이즈로 대체된다. 실제 입력은 토큰 0 하나뿐이고 앵커 보존 궤적은 그걸 그대로 둔다. M1의 카메라 민감도 전체가 그 토큰 하나이고 크기는 0.001 LPIPS다.

3. 카메라의 무엇을 쓰는지가 3층위로 갈린다. 앵커 고정 궤적의 순서가 held-out과 unseen 모두 동일하다.

카메라의 무엇	반응 (held / unseen)	왜
절대 위치 (offset)	0.0096 / 0.0111	주어진 첫 프레임 이미지에 이미 있음 → 중복
이동 방향 (random_dir)	0.0630 / 0.0982	프레임 간 flow의 방향을 바꿈
크기·매끄러움 (static, jitter)	0.1118–0.2035	flow의 크기를 바꾸거나 없앰

M3는 카메라를 "배치"가 아니라 "흐름"으로 쓴다

손목 뷰의 optical flow는 (카메라 변위) × (장면 깊이)로 결정된다. offset은 flow를 전혀 안 바꾸고, random_dir은 방향만, static/jitter는 크기 자체를 바꾼다. 반응 크기가 정확히 그 순서다.

즉 M3는 카메라를 "장면 안에 나를 배치하는 정보"가 아니라 "프레임 사이 화면이 어떻게 흐를지 예측하는 정보"로 쓴다. random_dir이 static의 절반쯤인 것도 맞는다 — 192×320 렌더에서 텍스처 없는 테이블 위쪽은 방향이 달라져도 비슷해 보이지만, 움직임이 아예 없거나 튀는 건 어디서든 보인다.

시각 확인

m3_unseen slot 05 (TRI+938130c4+2023-08-09, reverse 반응 최대 0.394):

gt: 손목 뷰가 테이블 위 상자·리모컨 쪽으로 다가감, GT와 거의 일치
reverse: 같은 노이즈·같은 클립인데 반대로 물러남 — GT 초반에 화면을 벗어나던 파란/주황 천이 후반 프레임에 다시 크게 들어옴
exo 두 행은 두 실행에서 거의 동일 — 단순 품질 저하라면 exo도 흔들려야 한다. wrist만 재조건화됐고 wrist만 움직였다

4 Takeaway

M3의 oracle 성격이 훨씬 날카로워졌다

wrist 카메라의 미래 운동이 곧 action이다. 그러니 M3가 받은 건 "카메라 정보"가 아니라 사실상 정답 action이고, M3가 한 일은 "주어진 앵커 프레임에서 알려준 운동대로 렌더링"이다. 44% 이득의 정체가 이것이다.

M4 방향은 옳다. 배포 시점에 필요한 건 "앵커는 이미지로 받고 운동을 추론"이고, camera token + frame-wise attention이 하려는 게 정확히 그거다. 절대 위치는 어차피 이미지에 있으니 추론할 필요가 없다.

동시에 M4의 천장이 어디서 오는지도 분명해졌다. M4는 M3가 공짜로 받은 미래 운동을 추론해야 하는데, 그건 이 프로젝트의 최종 목표(action 예측)와 사실상 같은 난이도다. M4가 M1/M2를 이기면 "카메라 운동을 어느 정도 추론했다"는 뜻이고, M3에 크게 못 미치는 건 예상된 결과 — 그 격차가 "추론이 얼마나 남았나"의 척도다.

생성 품질도 확인됐다. 학습에 쓰지 않은 에피소드에서 M3 gt의 wrist LPIPS는 0.1308(M1 0.2422). 격차가 유지된다.

5 보완점 / 다음

M4의 offset 무반응 여부가 진단 항목이 됐다. M3가 절대 위치를 안 쓰는 게 "첫 프레임에 이미 있으니까"라면 M4도 같아야 정상이다. M4가 offset에 크게 반응하면 오히려 camera token이 첫 프레임과 독립적인 뭔가를 학습했다는 뜻이라 따로 봐야 한다.
측정 못 한 것: 반사실 궤적에서 나온 영상이 기하학적으로 옳은지는 LPIPS로 판정 못 한다. "카메라를 따랐다"까지는 보였지만 "정확히 그 카메라의 시점인가"는 아니다. GT depth로 워프한 레퍼런스(droid_pose.warp_to_target가 이미 있음)와 비교하는 게 다음 단계.
M2는 안 돌렸다. M2도 PRoPE를 key에 걸므로 반응이 있을 수 있고, 있다면 "key만으로도 뭔가는 하는데 query가 없어 쓸모가 없었다"가 되어 Phase 1 해석이 정밀해진다. 1 GPU × 20분.
amplify는 등록만 하고 쓰지 않았다. 창 내 운동이 3 cm라 ×2로는 안 보이고, ×5–10은 심하게 off-manifold라 별도 실험으로 남긴다.

MetaView → WAM Backbone · 2026-08-06 · job 73212 + 73429 · 영상 168개 experiments/samples_m1_m3/

M3는 카메라를 따르는가, 아니면 덕을 봤을 뿐인가