loc_set(방만, 가구 무시) — experiments.tex:12에 명시, 숫자도 보관소 loc와 일치.논문에 실린 본표 숫자가 정확히 어떤 채점 규칙(방만? 가구까지?)을 쓰는지, 그리고 그 숫자가 실험 보관소(final_results/*/tables/*.md)와 일치하는지가 불분명했다. 최근 여러 세션에서 채점 규칙·프로토콜이 여러 번 바뀌었기 때문에(routine 물건목록 질의 전환, resume 이미지 예산 공정화 등) 논문이 최신 상태를 반영하는지 직접 확인이 필요했다.
Overleaf git bridge를 클론(~/repos/Robotics/scene_bench_paper)했으나 로컬이 origin/main보다 43커밋 뒤처져 있어 작업트리가 아니라 git show origin/main:<path>로 직접 읽었다. sections/experiments.tex의 첫 표(\label{tab:tier1})만 떼어 파싱해 보관소의 loc 값과 4가족 × 6전략 × 6모델로 대조했다. 파서 함정 2개: 결측은 \ph(뒤쪽 예약표 tab:online 전체가 \ph)라 첫 표만 잘라야 하고, 본표 결측은 ---로 별도 표기된다.
loc_set (방만)experiments.tex:12가 "(loc_set) as the headline metric"이라고 명시한다. 부록 appendix.tex:204-205도 "loc_set matches the room multiset, while the stricter place_set matches room and supporting surface"라고 확인해준다. 숫자로도 검증: 논문 Finding/blind Cosmos 0.387·flash 0.242 = 보관소 loc(place는 각각 .132/.155) — 가구는 채점에 안 들어간다.
| 구간 | 차이 크기 | 원인(추정) |
|---|---|---|
| find·restore 전반 | +.002 ~ +.015 | 보관소가 당일 09:33 재생성됨(다른 세션) — 원인 미확정 |
| routine 전반 | +.02 ~ +.193 | 260915 물건목록 질의 전환 이전 값 (flash textlog .565→.758, tagmem .513→.635) |
| resume vis-pure | −.018 ~ −.050 | 260915 이미지 예산 공정화 이전 값 (최대 16장 읽던 결함 조건) |
| resume tagmem | +.130 (flash .075→.205) | 같은 공정화(6장→8장) 이후 값이 반영 안 됨 |
| qwen3vl-32b tagmem | --- 4칸 | 4가족 모두 미기입(보관소엔 find .310·restore .103·resume .062·routine .297 존재) |
| 가족 | 표 mtime | 판정 |
|---|---|---|
| find | 2026-09-16 09:33:27 | 🟡 미확정 — 당일 재생성됨 |
| restore | 2026-09-16 09:33:29 | 🟡 미확정 — 위와 같음 |
| resume | 2026-09-15 12:37:44 | 🔴 논문이 틀림 — 보관소 안정, 순수 260915 델타 |
| routine | 2026-09-16 02:09:31 | 🔴 논문이 옛 프로토콜 — 보관소 안정 |
resume·routine은 지금 바로 고쳐도 되고, find·restore는 09:33 재생성 원인을 찾기 전엔 건드리면 안 된다.
experiments.tex:152 "Routine multi-object queries in this table explicitly list the target objects" — "in this table"이 하위유형 표(tab:tier1-subtypes)를 가리켜, 현재 Overleaf 상태는 본표(tab:tier1) routine = 옛 bare 질의, 하위유형 표 routine = 새 목록 질의로 서로 다르다. 숫자 교체만으로는 안 되고 서술도 같이 정리해야 한다.
논문(experiments.tex:16,36 · appendix.tex:230)은 routine을 "310 of 314"(규칙 증거 노출 4건 추가 제외)로 쓰는데, 보관소 헤드라인은 314(누출 행 제외 후)다. 갱신 시 어느 쪽으로 통일할지 결정이 필요하다.
논문 본표는 방만 맞으면 정답인 관대한 지표다 — "가구까지 맞아야"로 설명하면 틀린 설명이 된다. 더 엄격한 place_set은 부록 정의에만 있고 본표 숫자에는 반영돼 있지 않다. 더 심각한 문제는 routine·resume 숫자가 이미 폐기된 실험 조건의 값이라는 점이다 — 특히 resume vis-pure는 결함(16장 읽기) 조건이라 그대로 두면 MemER 계열을 과대평가한 표가 되어 리뷰 방어가 안 된다. find·restore의 ±.01 드리프트는 보관소가 이 세션 오전에 다른 세션에 의해 움직인 탓이라, 논문 갱신 전에 보관소를 먼저 한 시점으로 고정해야 한다.
① resume 4전략 × 6모델 수치 교체 + 캡션에 "이미지 cap 8 공통" 명시. ② routine 수치 교체 + 본표 프로토콜 서술 정리(본표도 목록 질의임을 명시) + 분모 310/314 통일. ③ qwen3vl-32b tagmem 4칸 기입(find .310·restore .103·resume .062·routine .297).
find·restore는 09:33 보관소 재생성 원인 규명 후 일괄 반영. 미커밋 코드(facts.py의 scene_card_rooms·room_map_for_prompt)가 원인일 가능성이 있으나 cards_root 기본값 미설정 시 opt-in이라 단정할 수 없음 — 별도 추적 필요.