SBENCH_WRITER_PREAMBLE=v2)를 find·restore(type1)에도 적용하는 rf-v3·vis-pure 재측정 런을 커밋(988478a, a77b19c) 후 제출.429 policy_limit_exceeded(월간 비용 한도, 일일 한도 아님) — 70/100편(810행, ≈$29)에서 체크포인트.writer v2 프롬프트(공통 코어 + 편 종류별 힌트)가 resume에서 rf-v3 .056→.143로 검증됐으니, 같은 프롬프트를 find·restore(type1)에도 적용해 재측정할 차례였다. restore는 추가로 "왜 물체가 스스로 옮겨졌는가"를 유도하는 질의 힌트 v2(SBENCH_RESTORE_QUERY_HINT=v2)도 함께 배선했다 — distractor 계열(로봇이 만진 적 없는 물체)이 스스로 자리를 옮긴 편인데, 시스템 프롬프트가 그 가능성을 한 번도 말해주지 않아 모델이 "안 만졌으니 그대로겠지"로 오답하는 문제를 겨냥한다.
| 커밋 | 내용 | 비고 |
|---|---|---|
988478a | writer v2 배선 · restore 질의 힌트 v2 · 오픈 resume 서빙 · 프롬프트 8개 · 보관 스크립트 · 로그 | 19파일 |
a77b19c | resume family를 final_results/에 아카이브(v1+v2 writer 프롬프트 전략별 병합, cut-time 메모리 인덱스) | archive_final_results.py 가족 일반화 |
미커밋 잔여: run_eval_resume.py·run_eval_routine.py(다른 세션이 오픈 resume 런에 실제로 쓴 하네스) · .gitignore(final_results/).
tmp/type1v2/submit.sh, 전부 own QOS, CPU-only)| 잡 | 내용 | 추정 |
|---|---|---|
A 117491 t1v2_findA | find e987b40f 100편 ingest(rf-v3·vis-pure, v2) → 589행×2 && restore 6511da78 unchanged 53편을 A 메모리로 재사용 → 173행×2 | ≈$40 |
B 117492 t1v2_restB | restore 6511da78 rerun 47편 ingest(v2) → 402행×2 | ≈$19 |
D 117493 rqh2_flash37 | restore 6511da78 100편 5전략 읽기 전용, v1 메모리 + SBENCH_RESTORE_QUERY_HINT=v2, afterok:A:B | ≈$25 |
근거: plan_delta(e987b40f → 6511da78, find)에서 changed = 정확히 rerun 47편, unchanged 53편은 두 루트에서 sha 동일 → A의 find ingest를 restore 53편에 재사용 가능. 6511da78 index는 112편(type2/3 포함)이라 V1_CONTEXTS로 type1 100편을 명시. 신설 tmp/hf_check/merge_contexts.py(샤드 contexts 병합 → --memory-from). D는 A·B 실지출 확인 후 시작되도록 의존성으로 묶었다(합계 ≈$84, 캡 $100). dry-run 검증(A 5행 · D 정상) 후 본 제출.
117492 restore 47편: 1h30m, $23.01(ingest $15.41 = 편당 $0.328 · 읽기 $7.60), 402행×2, v1과 query_id 402/402 일치.
117491 find: 1h46m 만에 4샤드 동시에 429 policy_limit_exceeded / rule_key cost:monthly(retry_after 1,717,316s). 체크포인트 70/100편(810행, 읽기 $6.16 + ingest ≈$23 ≈ $29). && 체인이라 restore53(A 메모리 재사용) 단계는 미실행 — results.json 없음.
| Δloc (v2−v1) | ALL | D① 내가 옮김 | D② 보기만 | D③ hidden | S① | S② |
|---|---|---|---|---|---|---|
| find rf-v3 | +.044 | +.111 | −.070 | +.234 | +.176 | +.091 |
| find vis-pure | −.040 | −.049 | −.048 | .000 | .000 | .000 |
| restore rf-v3 | +.087 | +.281 | −.010 | +.276 | +.083 | .000 |
| restore vis-pure | −.015 | −.031 | −.036 | +.103 | .000 | +.018 |
rf-v3 기권율: find .35→.26, restore .45→.39. 두 가족 모두 v2는 rf-v3의 "내가 옮긴 것"(D①·D③)을 크게 올리고 D②(보기만 한 것)는 못 올리며, vis-pure는 −.02~−.05 미세 하락 — resume에서 본 방향(+.087 / +.031)과 정합한다. 확정은 find 잔여 30편 완료 후.
v2 프롬프트의 효과 방향이 resume·find·restore 세 가족 모두에서 일관된다 — rf-v3는 "행동 채널"(내가 무엇을 했는가)만 개선되고 "관찰 채널"(보기만 한 것)은 프롬프트로 못 고친다는 260910 통합 진단과 부합한다. vis-pure가 v2에서 소폭 하락하는 것도 일관적 — 이미지 기반 전략은 텍스트 프롬프트 변경에 민감하지 않거나 오히려 잡음을 더할 수 있다. 다만 이번 런에서 드러난 인프라 제약(일일이 아니라 월간 API 비용 한도)은 앞으로 실험 예산을 짤 때 "오늘 얼마"가 아니라 "이번 달 누적"을 먼저 확인해야 한다는 운영상 교훈이다.
find 30편이 미완이라 find 델타(rf-v3 +.044, vis-pure −.040)는 확정치가 아니다. A의 && 체인 특성상 restore53(A 메모리 재사용) 단계가 통째로 밀렸고, D(restore 질의 힌트 읽기)는 A·B 완료 확인 전까지 시작되지 않는다.
월간 한도 상향 후 A 재제출(체크포인트에서 partial 복원, 잔여 ≈$16) → 완료 시 D 자동 실행(≈$25). 미커밋 파일(run_eval_resume.py·run_eval_routine.py·.gitignore) 정리 커밋 필요.