find의 flat 답 스키마 기준으로만 짜여 있어, restore의 nested from/to 스키마 322행 전부가 surface-unlabeled로 오판정 → 채점 대상에서 통째로 제외되고 있었음_gt_spot/surface_unlabeled/라벨 층화 축(concealment, n_hidden, n_floor, n_unlabeled)을 family-aware로 전환 — restore는 from·to 양쪽 지점을 각각 find 계약(바닥→floor, hidden+fixture→엄격, 그 외 미라벨)으로 판정V1_FAMILIES override 추가뿐 — 실제 restore family 모델 채점 잡은 아직 미제출지금까지 v1 final 캠페인(4~7모델 × 7전략 격자, 릴리즈 델타 e987b40f 등)은 전부 find family만
실측했다 — run_v1_final_shards.sh/serve_eval_vllm.sh가 --families find로
하드코딩돼 있었고, 260827 채점 계약 확정(v1final_grading_contract 카드)도 find의 flat
answers[i] = {surface, concealment, on_floor, ...} 스키마를 기준으로만 설계됐다.
restore family는 "물건을 원래 자리(to)에서 다른 자리(from)로 옮겼다가
되돌리는" 과제로, 답 스키마가 answers[i] = {from: {...}, to: {...}} 형태의 nested 구조다.
다음 델타/모델 격자 확장 단계에서 restore family를 처음 채점 대상에 넣으려는 시점에, 기존 채점 함수들이
이 nested 구조를 전혀 모른다는 사실이 드러났다.
surface_unlabeled()와
query_labels()의 라벨 축이 a.get("surface") / a.get("concealment")를
answer 최상위에서 직접 읽는데, restore의 answer에는 그 키가 없다(전부 from/to 안에 nested).
결과적으로 모든 restore 행이 surface=None, concealment=None으로 읽혀 C(미라벨) 규칙에
걸려 322행 전부가 평가 세트에서 자동 제외되고 있었다 — 조용한 전량 데이터 손실이라 실행
전에는 드러나지 않는 종류의 버그.find용으로 짜여 있던 채점 헬퍼들을 family 분기로 확장했다. 원칙은 "restore의 from/to 각 지점에 find와 동일한 계약을 개별 적용"이다.
대안으로 restore 전용 별도 채점 함수를 새로 만드는 방법도 있었지만, find 계약을 그대로 재사용해 두 family 간 채점 기준을 강제로 동일하게 유지하는 쪽을 택했다 (계약 불일치가 다음 회귀의 근본 원인이었으므로, 계약을 하나로 좁히는 방향).
| 항목 | 수정 전 | 수정 후 | 비고 |
|---|---|---|---|
| restore 322행 gradable 비율 | 0% (전량 C 제외) | 100% (322/322) | dry-run 실측 |
| restore GT (room, surface) 쌍 | 미검증 (애초 로직 미비) | 정합 확인 | from/to 양면 hidden+fixture strict 포함 |
| find 채점 회귀 테스트 | 107 (기준) | 107 통과 | find 채점 동작 변경 없음 확인 |
V1_FAMILIES=restore로 첫 실측 잡을 돌리는 건 다음 단계.지금까지 v1 final 결과 테이블(4~7모델 격자, 릴리즈 델타)은 전부 find family
단일 트랙이었다 — restore family는 데이터셋에 존재했지만 채점 계약이 없어 사실상 미사용
상태였다. 이번 수정으로 restore가 find와 동일한 채점 계약(hidden strict, floor 처리, C 미라벨
제외)을 공유하게 되어, find-only였던 v1 final 캠페인을 restore family로 확장할 수 있는
선결 조건이 풀렸다. 322행이 "발견되자마자 곧바로 100% 사용 가능"해진 건, 버그가 채점
로직의 정확도 문제가 아니라 순수하게 스키마 라우팅 누락이었다는 뜻이기도 하다.
restore family의 채점 계약을 확정하는 별도 문서(find의 260827
v1final_grading_contract에 해당하는 카드)가 아직 없다 — from/to 양면 hidden+fixture
strict 처리가 find와 대칭적으로 맞는지는 이번 dry-run(GT 쌍 정합)까지만 확인됐고, 실제 모델 응답을
채점해본 적은 없어 응답 파싱/매칭 단계에서 추가 엣지케이스가 나올 가능성이 있다.
V1_FAMILIES=restore로 소규모 모델(예: gemini-3.6-flash) 대상 첫 restore 채점 잡을
돌려 실측치를 확보하고, find 캠페인과 동일한 비용/전략 구조(cap 8, 30s 청크, 공통 전문)를 그대로
재사용할 수 있는지 확인한다. 이후 find 격자에 이미 포함된 모델들(flash-3.6/3.7, sonnet, luna,
오픈 VLM 3종)로 restore family를 확장해 find+restore 통합 결과 테이블을 만드는 것이 다음 목표.