scripts/archive_final_results.py --family find|restore — 멱등 실행, git 추적 대상. 표·원문 I/O·이미지 풀·PROVENANCE.md를 한 구조로 스냅샷rf-v2(naive concat)는 논문 미사용 결정 → 기본 전략 세트에서 제거, 값은 *_incl_rfv2_NOT_IN_PAPER.md로만 보존find v1.0(7모델) · restore v1.1(6모델) 두 캠페인이 몇 주에 걸쳐 진행되며 병합 파일(tmp/v1delta_*_merged.json, tmp/v11_*_merged.json 등)이 흩어지고, 논문 표에 들어간 숫자가 정확히 어떤 실행에서 나왔는지 되짚기 어려워졌다. 논문 집필 시점에 "이 셀 숫자의 원문(모델이 실제로 뭐라 답했는지)을 보여달라"는 요청에 즉시 답할 수 있는 구조가 필요했다.
tmp/에만 있고 재현 경로(릴리즈 커밋, 하네스 커밋, 읽기 비용)가 코드 주석이나 로그 파일에 산재. 재작성 시 어느 게 최신인지 헷갈릴 위험.scripts/archive_final_results.py --family find|restore [--images] — 멱등(재실행해도 같은 결과), git 추적 대상 스크립트. final_results/ 자체는 대용량이라 .gitignore 처리하고 스크립트만 커밋.
동시에 사용자 결정(260906): "rf-v3가 MEM-style, rf-v2는 논문에 안 쓴다. find·restore 전략을 맞춰라." — 확인 결과 논문 .tex 본문에는 rf-v2 인용이 없었고, 표 파일(scene_bench_paper/tables/visibility_ablation*)과 핸드오프 문서 2건에만 남아 있었다. ablation_visibility.py의 STR, grid_v1final.py의 STRATS 기본값에서 rf-v2를 제거하고(--rfv2 인자로만 남김), 관련 표를 재생성했다.
| 가족 | 모델 수 | 행/모델 | 텍스트 아카이브 | 이미지 풀 |
|---|---|---|---|---|
| find (v1.0, e987b40f) | 7 | 4,123행 | — | 3,483장 (141 MB) |
| restore (v1.1, 609076c0) | 6 | 3,626행 | — | 2,728장 (110 MB) |
| 합계 | — | 370 MB | 251 MB | |
이미지 풀은 편별 memory/<ctx>/frames 심볼릭 링크 1,100개로 모델 간 공유 — 같은 프레임을 모델마다 중복 저장하지 않는다. 증분 아카이브는 sbatch(CPU 25분, job 111213/111838)로 실행.
격자 스크립트도 이 정리에 맞춰 수정: 셀 라벨(D1/D2/D3/S1/S2)을 모든 세트에 부여하고 집계를 항상 원본 행에서 재계산하도록 바꿔, find v1.0 표에도 격자 셀 표가 자동으로 붙는다(예: find Direct② vis-pure flash-3.7 .746 vs Direct① — 별도 재작업 없이 표 파일에서 확인 가능).
이 작업 자체는 새 실험 결과를 내지 않지만, 캠페인이 끝난 시점에 "논문 표의 이 숫자가 어디서 왔는지" 추적 비용을 사실상 0으로 만든다 — 데이터팀 요청(예: Restore ② fold)이 들어와도 final_results/ 구조 위에서 델타만 재실행하면 되고, 리뷰어가 특정 셀의 원문 응답을 요구해도 models/<model>/io/<ctx>.md에서 바로 인용할 수 있다.
남은 luna·sonnet restore 잡(7전략 그대로 두어 대칭 보관, rf-v2 몫 ≈$10)은 표에는 안 들어가지만 아카이브에는 남는다 — 용량이 계속 늘어나는 구조이므로 논문 완성 후 정리 필요.
데이터팀 restore_distractor fold(S②) 요청 도착 시, 이 아카이브 구조 위에서 읽기 전용 델타만 추가(≈$10 예상).