resume 읽기 격자 6모델 완성 — v2 writer 프롬프트 + 오픈 VLM 3종

1배경 — 왜 오픈 모델을 resume 에 붙였나

find·restore 는 7모델 격자가 있는데 resume 만 API 3모델(flash-3.7·sonnet-5·luna)뿐이었다. "쓰기 병목의 크기가 과제 가족마다 다르다"는 주장을 모델 계급 축에서도 받치려면 8B 행이 필요하다. 오픈 모델은 자체 vLLM 서빙이라 API 비용이 0이므로 예산 제약도 없다.

resume 은 v1 오픈 기준선이 아예 없으므로 처음부터 v2 writer 프롬프트로 쟀다. writer 프롬프트를 안 쓰는 blind·textlog·frames-uniform 은 정의상 v1 = v2 이라, API 3모델은 재측정하지 않았다 (표에서 ᵛ¹ 로 표기).

tagmem-r3 는 사용자 결정으로 보류(별도 성능 작업 후), rf-v2 는 논문 미사용이라 제외했다.

2본표 — 6모델 × 6전략

셀 = resume_ok / slot_ok_frac. resume_ok 는 미완 명령을 정확히 지목하고 남은 개수까지 맞힌 행의 비율(전 슬롯 동시 정답), slot_ok_frac 은 슬롯 단위 부분점수다.

자기 blind 대비 이득 (최고 비오라클 − blind)

메모리 이득은 6/6 모델에서 양수지만, 8B 3종은 +.03–.05 로 얇다. flash-3.7 의 +.186 과 4–6배 차이다.

3지목은 되는데 개수를 못 센다

resume_ok = tasks_ok ∧ remaining_ok. 발화 목록은 blind 를 포함한 모든 전략에 공통 제공되므로 "어떤 명령이 남았나"(tasks_ok)는 상식으로도 어느 정도 찍히지만, "몇 개 남았나"(remaining_ok)는 메모리가 없으면 못 푼다.

4rf-v3 는 왜 8B에서 죽는가 — 재작성 계약을 이행하지 못한다

rf-v3 는 청크마다 기존 메모리 + 새 프레임 4장을 주고 메모리 전체를 다시 써서 덮으라고 시키는 MEM 계열이다. writer 가 낸 출력이 직전 메모리와 어떤 관계인지 전이 1,384건(100편 × 청크)을 직접 분류했다 — "무변화" = 직전 메모리를 토씨 하나 안 바꾸고 반환, "덧붙이기" = 직전 메모리를 그대로 접두사로 복사한 뒤 뒤에만 추가, "재작성" = 앞부분을 실제로 고침.

writer 호출은 100편 전부 calls == n_chunks 로 정상 실행됐다(건너뛴 게 아니다). 세 가지 고장이 서로 다르다:

• cosmos·molmo2 — 복사 부담형: 절반 이상이 직전 메모리를 그대로 돌려준다 → 그 청크에서 본 장면은 버려진다.
• qwen — 편집 회피형: 무변화는 2.6%뿐이지만 61.7%가 앞부분을 복사하고 뒤에만 덧붙인다 → 사실상 rf-v2(누적)로 퇴화. 논문에서 구분하려는 두 전략이 8B에서는 같은 것이 된다.
• molmo2 의 17k자: 전이의 5.2%에서 반복 루프로 폭주하고, 이후 청크가 그걸 그대로 복사하니 한 번 부풀면 끝까지 남는다. 길이는 결과이지 원인이 아니다.

왜 — "얼마나 베껴 써야 하는가"에 비례한다

무변화율을 직전 메모리 길이와 청크 위치로 나누면 단조 증가한다. 첫 청크는 베낄 게 없어 거의 다 제대로 쓴다.

하네스 공정성 메모

rf-v3 는 "메모리 전량 재출력", vis-pure 는 "KEEP/DROP 몇 글자"다. 8B 에게 rf-v3 만 출력 부담이 압도적으로 크므로, 표에서 vis-pure > rf-v3 로 나오는 것은 전략의 우열과 출력 부담의 차이가 섞여 있다. flash-3.7 은 부담을 감당하므로(재작성 98.4%) 그 행에서는 전략 비교가 성립한다. 사용자 결정(260910): 지금은 한계로 기록하고 표는 그대로 둔다; 출력 부담을 맞춘 대조군은 필요 시 $0 로 추가.

molmo2 루프 원문 (contexts/type2/train_123__2000, 최종 19,397자)

5실패 사례 — 원문 · 원인 · 교훈

① qwen3vl-8b · rf-v3 · press_button (Press the button on the washing machine five times., 남은 2회)

컷 시점 메모리 원문 — 5개 청크(≈2.5분)가 한 문장으로 남았다:

모델 응답:

채점: tasks_ok 0 · remaining_ok 0 · named_finished 1 — 이미 끝난 심부름 ("move the soap bottle …")을 미완으로 지목했고, 정작 남은 세탁기 버튼은 "were either completed or interrupted" 라며 넘겼다.

② cosmos-r2-8b · 생성 붕괴로 채점 이전 사망 176/805행

실패 행 전부 attempts=2(재시도해도 같은 붕괴), raw 길이 median 80,135자 대 성공 행 669자. 예: resume:train_123__2000:cut_06 / textlog — 78,065자 생성 후 절단.

에러 메시지는 JSON decode failed: Unterminated string starting at: line 2 column 16 … 로 JSON 파스 실패지만, 실제 원인은 스키마 오해가 아니라 같은 문장을 반복하다 토큰 상한에 잘린 것이다.

6과제 종류별 분해 — 무엇이 원천적으로 안 되는가

press_button (n=25) — 화면에 흔적이 없는 행동

rf-v3 는 flash-3.7·sonnet·luna·qwen 전부 .000. cosmos .160 · molmo2 .120 은 각자의 blind(.200 · .080)와 구분되지 않는 추측이다. 오라클은 .32–1.00 이므로 정답 자체는 존재하고, 메모리에 안 실린 것이다.

visit_rooms (n=31) — 발화에 수사가 없다

오라클조차 .419 / .290 / .258 / .065 / .129 / .032 로 붕괴한다. 발화가 "every room" 이라 총 몇 개인지가 원문에 없고, move 44/44 · put 67/67 · press 49/49 가 수사를 포함하는 것과 대조된다. 이건 전략의 문제가 아니라 데이터 축이며, 실행 트랙의 remaining_rooms 필드로 해결된다.

multi (미완 2개, n=61) — 동시 정답 규칙의 벽

두 명령을 모두 맞혀야 resume_ok 가 1이므로 급락한다. flash-3.7 vis-pure 가 .180 으로 최고, 8B 3종은 비오라클 전부 .000 — slot_ok_frac 으로만 차이가 보인다(.172 / .139 / .057).

7Takeaway

8보완점 / 다음

• tagmem-r3 오픈 3종 미측정(사용자 보류) — 표 마지막 줄이 3모델뿐. 성능 작업 후 재개.
• sonnet·luna 의 rf-v3·vis-pure 는 아직 v1 수치(ᵛ¹). v2 재측정은 비용 문제로 최후순위.
• cue ablation(322행, task_named/task_named_n, ≈$17) — visit_rooms 의 "총 개수를 주면 얼마나 오르나"를 정량화. 사용자 보류 중.
• 다음 API 런(사전 승인 필요): type1 v2(find+restore, flash-3.7, rf-v3+vis-pure, 공유 ingest ≈$53) → restore 질의 힌트 읽기 전용 5전략(v1 메모리 재사용, ≈$25).