단일 은닉 요청만. 은닉 복수 요청은 출처(자기/타인)에 따라 S1/S2로 이동 — 옛 D3에 두 케이스가 섞여 있었음.src/sbench_eval/dataset_v1.py:paper_cell 하나로 통일(multi 먼저 판정 → 그다음 single hidden). grid_v1final.py·writer/hint delta·online/w1 집계기가 모두 이 함수를 호출.scene_bench 논문 Table 1은 Finding/Restore 질의를 은닉·이동 조건에 따라 5개 셀(D1 내가 옮김·D2 남이 옮김·D3 은닉·S1 자기 복수·S2 타인 복수)로 나눠 보고한다. 기존 D3 정의는 "은닉된 질의"를 통째로 담고 있어서, 단일 은닉 요청과 복수 물체 중 일부가 은닉된 요청이 같은 칸에 섞여 있었다. 이 둘은 난이도 성격이 다르다(전자는 단일 사건 탐색, 후자는 multi 채점의 all-or-nothing 특성이 겹침) — Overleaf Table 1 해석 절을 쓰다가 이 혼동이 드러났다.
재현·산발 구현을 막기 위해 셀 판정을 단일 공통 분류기로 모으고, 기존 채점 결과는 재호출 없이 재집계만 했다.
대안이 없었던 이유: 셀 판정이 여러 스크립트(grid_v1final.py, writer/hint delta, online 집계기)에 각각 흩어져 있어 정의를 바꿀 때마다 전부 손대야 했다. 공통 함수로 모으면 다음 정의 변경도 한 곳만 고치면 된다.
| 평가 데이터 | 전체 | D1 | D2 | D3 | S1 | S2 |
|---|---|---|---|---|---|---|
| Finding e987b40f | 589 | 215 | 268 | 52 | 34 | 20 |
| Restore 6511da78 | 575 | 215 | 196 | 28 | 79 | 57 |
Finding: 옛 D3 11행 중 8행 → S1, 3행 → S2. Restore: 옛 D3 28행 전부 → S1.
| 가족 | 제외 규칙 | 제외 행수 | 헤드라인 행수 | 채점 가능 |
|---|---|---|---|---|
| Finding | D3 52 + hidden S1 8 + hidden S2 3 | 63 | 526 (불변) | 524 |
| Restore | 변경 없음 | — | 575 (불변) | 569 |
| 검증 항목 | 결과 |
|---|---|
| 순수 분류 회귀 테스트 | 17개 통과 |
| 가족별 6개 보관 모델 원시 라벨 분류 일치 | 일치 (Finding·Restore 각 6모델) |
| 전략별 합계 보존 | 확인 |
| 원본 데이터 SHA256 | 불변 확인 |
| Overleaf Table 1 / Restore 분해표 | 갱신 + PDF 컴파일·배치 확인 |
이번 변경은 점수 결과에는 영향이 없는 논문 표기 정확성 수정이다 — Finding 526행 / Restore 575행 헤드라인과 그 안의 모든 전략 비교(예: tagmem vs frames-uniform vs vis-pure의 D1/D2 셀)는 그대로 유효하다. 바뀐 것은 세부 breakdown 표(D3/S1/S2)의 의미론뿐 — 이전에는 "은닉이면 D3"였던 게 이제 "은닉이면서 단일 요청일 때만 D3"가 되어, S1/S2(복수 요청) 표와 개념이 명확히 분리됐다.
공통 분류기로 모은 것도 부수적 이득: 다음에 셀 정의를 또 바꿔야 할 상황이 오면(예: routine의 D 카테고리 확장) 한 함수만 고치면 grid_v1final.py·writer/hint delta·online 집계기가 전부 따라간다 — 260902 기록에 있던 "D3 폐기" 논의(OpenRAL 리서치 카드) 이후 처음으로 D3 정의가 코드 레벨에서 명문화됐다.
공통 분류기로 확인된 소비처는 grid_v1final.py·writer/hint delta 집계기·online/w1 집계기 3곳뿐. 논문 부록 스크립트나 다른 세션이 만든 임시 집계 코드 중 옛 D3 정의를 하드코딩한 곳이 남아있을 수 있어 별도 감사가 필요하다.
Overleaf 본문에서 D3/S1/S2 각 셀을 인용하는 서술 문장이 옛 정의 기준 수치를 언급하고 있지 않은지 재확인(표는 갱신됐으나 본문 설명 문장은 별도 검토 대상). 4가족(routine 포함) 확장 시 같은 paper_cell 분류기를 routine에도 적용할지 결정 필요.