vocab.py(물체 57 / 방 4+floor / 표면 15 고정 어휘) + system_v3 프롬프트 + assert_no_episode_leak() 회귀 가드.{category, room|floor, surface}("어디에 있는가") + tolerant JSON 파서 + 어휘 정규화(canonicalization).260818 260818-e6_eval_design.html에서 사용자가 "물체가 어디 있는지 찾아야 하는데
리스트가 이미 다 알려주고 있다"고 지적했고, 실측 검증(답 835개 전수)으로 정확함이 확인됐다:
에피소드별 후보 리스트(uid + 초기 방 표기)를 읽기만 해도 답의 66.6%(556/835)가
맞았고, find_distractor 질의는 100%(400/400)가 누출이었다(정의상
움직이지 않는 물체라 초기 방=정답). uid 접미사에 방 번호가 그대로 박혀 있어 표기를 지워도
누출이 남는다는 점까지 확인되면서, "uid 선택형 답 계약" 자체를 폐기해야 한다는 결론이 나왔다.
이 카드는 그 설계(v2)가 승인된 문서에 머물지 않고 실제 실행 가능한 코드로
전환됐음을 기록한다 — 설계 문서(plan-e6_v07_eval_design.md §6-c, §7)의
"구현 변경 목록"이 이번 커밋으로 전부 반영됐다.
커밋 메시지 그대로 "Implements design v2" — 신규 모듈 7개 + 테스트 재정비로 구성.
설계 문서(§7 "구현 변경 목록")와 실제 구현을 대조하면 schema.py 항목만 별도
파일 대신 answer.py에 흡수됐고, 나머지(candidates.py 폐기 → vocab.py 신설,
query_runner.py → prompt.py/runner_v3.py 분리, scorer.py → grading.py, eval_fixes.py →
facts.py 계층화 부분 흡수)는 계획대로 반영됐다.
| 항목 | 수치 | 비고 |
|---|---|---|
| 변경 파일 | 13 | 신규 7 + 테스트 정비 4 + 기존 1(test_memory_strategy.py) |
| 총 diff | +773 / -172 | 순증가 601줄 |
| v3 계약 테스트 | 14개 (test_v3_contract.py) | 누출 회귀 포함 |
| 폐기 테스트 | 3 파일 (-155줄) | v1 계약 전용 — candidates/eval_fixes/query_runner |
| 고정 어휘 | 물체 57 / 방 4+floor / 표면 15 | vocab_v1.json, 153 eps 전수에서 1회 생성 |
| 토큰 절감 추정 | ~30% | 설계 문서 추정치 — 에피소드 리스트(24줄) 삭제 대신 어휘는 system에 1회만 |
~/datasets/scene-mem-benchmark)이 현재 41GB 전량 다운로드 완료된 상태를 직접 확인 — 260818 시점 context.md의 "43.7GB 다운로드 중" 블로커가 해소되어 있어, S1 파일럿을 실제로 돌릴 수 있는 상태다(이번 리포팅에서는 실행하지 않음).test_v3_contract.py는 pytestmark = pytest.mark.skipif(not DS.exists(), ...)로 데이터셋 부재 시 스킵되는 구조 — 이번 카드는 커밋 diff와 코드 정독을 근거로 작성했고, 실제 pytest 실행 결과(14개 전부 pass 여부)는 별도 확인이 필요하다.E6는 이제 "설계안"이 아니라 "실행 가능한 파이프라인"이다. 핵심은 assert_no_episode_leak이
단순 코드리뷰가 아니라 매 호출마다 실행되는 런타임 가드라는 점 — 66.6% 누출을
낳았던 실수 패턴(uid/방번호가 프롬프트에 섞임)이 재발하면 조용히 넘어가지 않고 즉시 실패한다.
설계 v2가 "계약"으로만 존재했다면 이 가드가 그 계약을 코드 수준에서 강제한다.
답 계약이 uid 선택 → {category, room, surface}로 바뀌면서 헤드라인 지표도 obj_strict에서 loc_acc/place_strict로 이동한다 — 공식 body-id 채점과는 간접 대응이 되므로(설계 문서에 이미 명시), 다음 단계에서 이 트레이드오프가 실제로 감당 가능한지 S1에서 먼저 확인해야 한다.
① 실제 pytest 실행 결과 미확인(14개 전부 pass인지, 데이터셋 로딩 경로가 맞는지) — 다음 세션에서 먼저 돌려봐야 한다. ② body-id 공식 채점과의 간접 대응 관계가 실제 리더보드에서 얼마나 정보 손실을 만드는지 아직 모름. ③ 방 4종 해상도가 거칠다는 한계는 설계 단계 지적이 그대로 남아있음(twin_nearby 98건 별도 보고 필요).
설계 문서 §6 단계 그대로: S1 검증 (val_101__0 등 3 eps × 5전략 × 2모델, ~$5) — 스키마/파서/픽스처가 신규 계약에서 실라이브로 도는지 확인. 통과하면 S2 층화 파일럿(15 eps, kind×steps×misplaced 층화, ~$50)으로 전략 재필터(5→3?) 및 모델 확정. 데이터셋은 이미 로컬에 있으므로 블로커 없이 바로 착수 가능.