resume · rf-v3 절제: 재작성 대신 누적

TL;DR

귀무다. resume_ok .174 → .186, McNemar +16/−14, p=.856. 161행 중 30행이 뒤집혔는데 거의 반반이다.
메모리를 2.8배(컷 시점 중앙 123 → 361 단어)로 불렸는데 정답률 불변, 기권만 +6.8pp 늘었다.
기제가 잡혔다 — 누름이 걸린 49행 중 메모리가 누름을 한 번이라도 언급한 행이 rf-v3 10 · append 12. 37~39행은 두 연산자 모두 아예 안 썼다. 재작성이 지운 게 아니라 writer 가 관측을 못 한다.
부수 소득: MEM 의 압축은 이 벤치마크에서 잃는 게 없다 → rf-v3 를 MEM 의 충실한 재현으로 제시할 근거.

.174→.186

resume_ok

p=.856

McNemar

2.8×

메모리 길이

10·12/49

누름 기록된 행

$8.67

실비 (승인 $16)

1 배경 — 무엇을 의심했나

rollforward-v3 는 MEM(arXiv 2603.03596)식 언어 메모리로, 청크마다 m_t+1 = f(m_t, clip) 로 통째 재작성한다. 압축이 이 방법의 정체성이지만 동시에 실패 원인으로 지목돼 왔다.

기존 관측: 32B rf-v3 의 사건 보존율 36~39%(flash 72%) — 재작성 때마다 앞 사건이 지워진다(260918). 그리고 resume 는 같은 행동의 반복 횟수가 정답을 가르는 가족이라, 재작성이 "두 번째 누름"을 "누름"으로 합치기 쉽다.

그래서 물었다 — rf-v3 의 약세는 방법(언어 메모리)의 한계인가, 갱신 연산자(재작성)의 한계인가?

2 설계 — 연산자만 바꾼다

	갱신식	컷 시점 메모리
rf-v3 (기준)	`m_t+1 = f(m_t, clip)`	요약 1개 · 중앙 123 단어
rf-v3-append	`m_t+1 = m_t ⊕ g(m_t, clip)`	누적 전체 · 중앙 361 단어

통제(바이트 동일): 30 s 청크 · 청크당 4프레임 · writer preamble v2 + type2 힌트 · 어휘 주입 · heard/task part · 파싱(_parse_memory) · 온도 · 컷 접두사 의미론 · 읽기 자리(메모리 턴 1개, 이미지 0장) · 질의 관측 1장.

다른 것은 둘뿐: ① 프롬프트의 MEMORY 블록 지시문 한 단락(diff 확인) ② writer 가 매 청크에 보는 것이 "마지막 요약"이 아니라 누적 전부(정보 동등성 — 사용자 결정). 타임스탬프 접두사는 붙이지 않았다: 진행도 질의에 시간 단서를 한쪽만 주면 비교가 깨진다.

모델 gemini-3.7-flash · cap 8 · SBENCH_WRITER_PREAMBLE=v2 · 4샤드 × 2루트 루트 분리: 66편 scene-mem-benchmark-v1_61871a3e + 누름 34편 ..._fd856246 (보관본 표와 같은 분할) 161행 · 잡 147853(39분) / 147854(20분) · 오프라인 스텁 검증 + 2편 스모크 선행

사전등록 — 주지표 resume_ok 같은 행 McNemar, 방향 무관 보고, 결과 보고 프롬프트 재조정 금지. v3c(횟수를 세라고 명시)가 .174→.143 으로 떨어졌던 전례가 있어 사후 선택은 편향만 남긴다. 이 팔은 절제이지 우리 방법이 아니다 — 올라도 tagmem-r3 를 대체하지 않는다.

3 결과 — 차이 없음

지표	rf-v3	append	Δ	McNemar
resume_ok (주지표)	.174	.186	+.012	+16/−14 · p=.856
tasks_ok	.453	.435	−.019	+15/−18 · p=.728
remaining_ok	.230	.267	+.037	+18/−12 · p=.362
slot_ok_frac	.320	.351	+.031	—

층화 (사전등록 지표, 전부 유의하지 않음)

층	n	rf-v3 → append	McNemar
누름 포함	49	.061 → .122 (+.061)	+5/−2 · p=.45
누름 없음	112	.223 → .214 (−.009)	+11/−12 · p=1.00
n_pending>1	61	.098 → .164 (+.066)	+6/−2 · p=.29
n_pending=1	100	.220 → .200 (−.020)	+10/−12 · p=.83

가설 방향이긴 하다: 누름·다중 미완에서 누적이 +6pp 씩 기울었다. 그러나 각 층에서 뒤집힌 행이 7~8개뿐이라 잡음과 구별되지 않는다. 가설을 살려내는 쪽으로 읽지 않는다.

압축의 대가는 치렀는데 이득이 없다

	컷 시점 메모리	기권율	비용
rf-v3	중앙 123 단어 (최대 238)	.137	$9.01
append	중앙 361 단어 (최대 922)	.205	$8.47

비용은 오히려 조금 싸다 — 입력이 길어진 만큼 출력(증분 vs 전체 재작성)이 짧아져 상쇄됐다.

4 기제 — 재작성이 지운 게 아니라 애초에 안 써졌다

누름이 걸린 49행에서 컷 시점 메모리가 누름 사건을 한 번이라도 언급하는지 셌다 (press|pressed|pressing|button).

	언급한 행	누름 단어 총 등장	누름 행 remaining_ok
rf-v3 (재작성)	10 / 49	24	.122
append (누적)	12 / 49	26	.163

결정적: 재작성이 지운 것이라면 누적본에는 남아 있어야 하는데, 37~39행에서는 두 연산자 모두 누름을 아예 기록하지 않았다. 이 가족의 병목은 메모리 관리가 아니라 writer 가 30 s 청크 4프레임에서 버튼 누름을 관측·기술하지 못하는 것이다.

4.5 "누름만 그런가?" — 세 갈래로 갈린다

단일답 유형	n	rf-v3 → append	McNemar	사건 언급률	오라클
press_button	25	.040 → .040	+1/−1	.16 → .20	1.000
put_in_container	27	.296 → .444	+7/−3 p=.34	.81 → .93	1.000
move_objects	17	.588 → .294	+1/−6 p=.13	.94 → 1.00	1.000
visit_rooms	31	.097 → .065	+1/−2	.61 → .48	.419
multi(복합)	61	.098 → .164	+6/−2 p=.29	—	.738

① 누름 = 미기록. 언급률 16~20% 인데 오라클은 1.000 — 정보는 로그에 있고 시각 writer 가 못 뽑는다. tasks_ok .640 / remaining_ok .160: 어떤 명령이 미완인지는 알면서 세지를 못한다.

② 담기·옮기기 = 기록은 된다. 언급률 81~100% 인데도 틀린다 — 미기록이 아니라 횟수·대응 문제다. 그리고 절제가 실제로 움직인 곳이 여기다: 담기 +14.8pp, 옮기기 −29.4pp. 방향이 반대라 합치면 0 이 된다. 전체 귀무는 "아무 일도 없었다"가 아니라 상쇄다.

4.6 ⚠️ visit_rooms 는 하네스 결함이다

오라클(textlog)이 31행 중 18행을 틀리고 그 중 17행이 기권한다. 기권 사유 원문이 전부 같다:

"the total number of rooms in the house cannot be determined from the available memory" "only the kitchen was visited before interruption, and the total number of rooms in the house cannot be determined"

remaining = (집의 총 방 수) − (방문한 방 수)인데 총 방 수가 어디에도 주어지지 않는다 — build_query_parts 는 "후보 리스트 없음(설계 v2)"이고 build_system_resume 도 방 목록을 안 준다. 오라클의 추론은 맞는데 0점이다. 영향 범위는 단일 31행 · 복합 포함 62/161행.

전략	전체 161	visit 제외 130	visit 31행
blind	.062	.062	.065
frames-uniform	.155	.154	.161
rollforward-v3	.174	.192	.097
append	.186	.215	.065
vis-pure	.199	.215	.129
tagmem-r3	.211	.238	.097
textlog(오라클)	.789	.877	.419

31행을 빼면 오라클이 .789 → .877. 순위는 바뀌지 않고 tagmem−rf-v3 격차는 +3.7 → +4.6pp 로 오히려 벌어진다. 본표를 바꾸자는 제안이 아니라 측정 한계로 보고할 항목이다 — 처리 방식은 사용자 결정.

5 Takeaway

① rf-v3 의 resume 약세는 MEM 의 재작성 때문이 아니다. 연산자를 정반대로 바꿔도 p=.856. 32B 의 보존율 36~39% 는 그 writer 의 성질이지 resume·flash 를 가르는 요인이 아니다.

② 압축은 공짜에 가깝다. 메모리를 2.8배로 늘려도 얻는 게 없고 기권만 는다 — MEM 의 압축이 이 벤치마크에서 잃는 게 없다는 뜻이고, 논문에서 rf-v3 를 MEM 의 충실한 재현으로 쓰는 근거가 된다.

③ "쓰기 이전이 병목"은 누름에만 해당한다 — 일반화하면 틀린다. 누름은 언급률 16~20% 로 미기록이지만 담기·옮기기는 81~100% 기록되고도 틀린다(횟수·대응 문제). 누름에 한해서는 개입 네 가지가 전부 실패했다(v3c 명시 지시 .174→.143 · append .040→.040 · 팔 접기 재생성 .000→.050 · 관측 밀도 3배 0~+2.8pp) — 남는 설명은 writer 의 시각 접지다. 행 원문에서 세탁기를 black safe 라 부른다. 자세히는 세 갈래 리포트.

④ 덤으로 하네스 결함 1건. visit_rooms 62/161행이 총 방 수 미제공으로 답이 결정되지 않는다 — §4.6.

6 다음

일반성 — flash-3.7 단일 모델 결과다. 보존율이 낮은 오픈 32B 로 같은 절제를 돌리면(API $0) "연산자가 문제인 writer 가 따로 있는가"를 확인할 수 있다.
관측을 올리려면 청크당 프레임 수(4장)나 청크 길이(30 s)를 건드려야 하는데, 그건 전 전략 공통 조건이라 바꾸면 전 가족 재측정이다. 현 단계에서는 측정 한계로 보고하는 것이 맞다.
본표에는 넣지 않는다. 절제 부록 행으로만 싣는다.

사전등록·결과 전문: claude/260922/exp-resume_rfv3_append_ablation.md 집계: tmp/rfv3append/analyze.py · 기제: tmp/rfv3append/mechanism.py 구현: prompts/rollforward_v3append.txt · src/sbench_eval/rollforward.py:ingest_append