R2 구제 칸 온라인 보충 런

TL;DR

왜: 온라인 셀 기준이 "R2 이전 정답 칸"이라, R2로 구제된 칸은 온라인에서 한 번도 안 돌았다(find 302/302이 preR2=1).
무엇: 그 칸의 계획은 모델이 어휘 때문에 desk/coffee table이라 답한 것 → 정답 판정을 따라 GT 바디 이름으로 치환해 실행(retarget_rescued_surfaces).
결과: 85칸 · $11.08 · 14.0분/칸 · 누락 0. 유효 50칸 합류 후 find .468→.467 · restore .184→.182 — 순위 불변.
⚠️ 도중 다른 세션이 채점 파이프라인 교체(scoring_fixes.py, 원값 키 place_set_preR2→place_set_raw) → is_rescued가 없는 키를 읽어 "정답이면 전부 구제"로 오작동. 35칸 폐기.

측정 칸

합류

폐기

$11.08

비용

±.002

총 SR 이동

1합류 결과 — 순위 불변

find

전략	기존	구제 추가	합계	Δ
blind	3/8 = 0.375	1/1	4/9 = 0.444	+0.069
textlog	3/58 = 0.052	3/4	6/62 = 0.097	+0.045
frames-uniform	7/32 = 0.219	2/5	9/37 = 0.243	+0.024
rollforward-v3	7/28 = 0.250	2/7	9/35 = 0.257	+0.007
rollforward-vis-pure	162/309 = 0.524	4/7	166/316 = 0.525	+0.001
tagmem-r3	177/332 = 0.533	0/3	177/335 = 0.528	-0.005
계	359/767 = 0.468	12/27	371/794 = 0.467	-0.001

restore

전략	기존	구제 추가	합계	Δ
blind	1/2 = 0.500	0/0	1/2 = 0.500	+0.000
textlog	32/257 = 0.125	2/12	34/269 = 0.126	+0.002
frames-uniform	10/53 = 0.189	0/2	10/55 = 0.182	-0.007
rollforward-v3	15/64 = 0.234	0/3	15/67 = 0.224	-0.010
rollforward-vis-pure	18/88 = 0.205	1/4	19/92 = 0.207	+0.002
tagmem-r3	29/107 = 0.271	0/2	29/109 = 0.266	-0.005
계	105/571 = 0.184	3/23	108/594 = 0.182	-0.002

구제 칸이 특별히 쉽거나 어렵지 않았다 — 총 SR 이동이 ±0.002다. 이제 "R2로 늘어난 정답을 온라인에서도 측정했다"고 쓸 수 있다(미측정 칸이 남았다는 반론이 닫힌다).

2⚠️ 채점 스키마 교체 사고

09-22 08:12에 다른 세션이 scripts/scoring_fixes.py를 신설해 보관 채점을 갈아끼웠다 — ① 물체↔위치 대응 강등(B) 추가 + ② R2(tight 기본), 원값 키는 place_set_raw로, 구제 표시는 행 플래그 naming_rescue_r2로.

# 내 코드 (구 스키마) is_rescued = bool(sc.get("place_set")) and not sc.get("place_set_preR2") # ^^^ 키가 사라짐 → not None == True # → place_set=1 이면 전부 "구제 행"

런이 그 경계를 가로질러 돌아서 결과가 갈렸다:

분류	칸	처리
새 기준에서도 구제 행 · 치환됨	50	본표 합류
구제 행 아닌데 치환됨 (정당화 안 되는 GT 주입)	14	폐기
구제 행 아닌데 셀에 들어옴 (치환 없음)	21	폐기

폐기 35칸은 기존 본표 셀과 중복 0이라 표에 구멍이 나지 않는다. 유효 50칸만 rescuefix_{fam}_s0.jsonl로 분리해 집계기에 배선했다 — 원본 rescue_*.jsonl은 오염분이 섞여 있어 읽지 않는다.

근본 원인은 조용한 기본값이다. 없는 키를 dict.get()으로 읽으면 스키마가 바뀌어도 코드가 죽지 않고 틀린 답을 낸다. is_rescued가 원값 키가 없으면 즉시 KeyError를 내도록 고치고 테스트로 고정했다(test_is_rescued_fails_loudly_when_the_raw_column_is_missing). 여러 세션이 같은 워킹트리를 동시에 고치는 환경에서는 "조용히 계속 도는 것"이 가장 비싼 실패다.

3실행 기록

제출 09-21 23:00 · 5샤드 (find main/tagmem · restore main×2/tagmem) 완주 09-23 00:11 · 85/85 · 누락 0 · $11.08 (견적 $12) · 14.0분/칸 QOS own → extra (oracle 본 런이 own 8장을 다 써서 큐 뒤로 밀림) 대기 클러스터 만석(120/120) 구간에서 반나절 정체 · babysitter 재제출 5회로 완주 스냅샷 tmp/rescue_cells/src_rescue = 본 런 src_w2 + 치환 3파일 (프롬프트 바이트 동일)

접지 규칙(resolve_name·grounding._cat_matches)은 본 런과 바이트 동일하게 두었다 — 이름 동치류·결정 C는 이 스냅샷에 넣지 않았다. 같은 표 안에서 접지 규칙이 갈리면 안 되기 때문. 기존 1,981칸과 새 50칸의 차이는 구제 행 계획 치환 하나뿐이고, 그건 정의상 새 칸에만 적용된다.