side table을 말했고, desk/coffee table로 구제된 221행 중 200행(90%)은 그 방에 그 가구가 없다(어휘 대체로 설명됨).stand_ 접두사로 TVStand·SideTable을 한 이름으로 접는데, 온라인은 sim category로 접지한다 → 오라클-플랜 본 런 1,490칸 중 170칸이 no 'tv stand' in room_x로 차단, 30칸은 엉뚱한 바디로.shelf도 같은 결함이었다(ShelvingUnit) — R2를 만들 때 몰랐던 케이스. 전체 가구 18종 중 불일치는 3종뿐.dresser 기각을 우회한다 — 구제 473행 중 130행(27%)이 그 방에 진짜 있는 다른 가구를 답했고, 84행이 dresser다. 읽기 본표에서 oracle(textlog)만 −0.7~2.6pp 부푼다.읽기 트랙(VLM eval)에 tv stand 구제 규칙(R2)을 넣어 정답이 늘었다. 원인은 하네스 결함 둘이다.
질문은 둘이었다. (a) 읽기에서 정답을 늘린 게 타당한가? (b) 늘어난 답(desk·coffee table 등)을 온라인에서 실행하면 로봇은 어디로 가야 하나?
navigate(room, surface) → grounding.ground_selection(strict=True)). 그래서 읽기의 관대화가 온라인으로 그대로 옮겨지지 않는다.| 구제 근거 | find | restore | 계 |
|---|---|---|---|
| 원문이 side table / nightstand / end table 을 말함 | 102 | 150 | 252 (53%) |
| 답 값이 desk · coffee table 이라서 | 160 | 61 | 221 (47%) |
| ↳ 그 방에 그 가구가 없다 (어휘 대체로 설명됨) | 159 | 41 | 200 (90%) |
| ↳ 그 방에 진짜 있다 (위양성 의심) | 1 | 20 | 21 |
헤드라인 영향은 find +0.2~2.6pp · restore 최대 +5.0pp(textlog). blind 는 +0.2pp만 움직이고 tagmem−vis-pure 격차는 오히려 줄어든다 — 우리 쪽에 유리한 방향의 관대화가 아니다.
GT 표면 uid를 씬카드 body로 조인해 진짜 category를 얻고, 읽기 이름(vocab.surface_display(uid 접두사))과 온라인 이름(naming.display_name(sim category))을 비교했다.
| uid 접두사 | 씬카드 category | 읽기 이름 | 온라인 이름 | GT 사용(칸) |
|---|---|---|---|---|
stand | SideTable | tv stand | side table | 180 |
shelf | ShelvingUnit | shelf | shelving unit | 35 |
refrigerator | Fridge | refrigerator | fridge | 0 (잠복) |
| 나머지 15종 (dining table · countertop · chair · dresser · TVStand · toilet · sofa · bed · desk · armchair · sink · coffee table · cart · clothes dryer · washing machine) | 일치 | |||
shelf는 아무도 몰랐던 같은 결함이다. 이 79채에서 shelf_ 바디는 전부 ShelvingUnit이라, 읽기 GT가 "shelf"라고 말하는 순간 온라인에서는 항상 접지에 실패한다.| 장치 | 무엇을 한다 | GT를 보나 |
|---|---|---|
naming.COARSE_ALIASES (접지) | 거친 이름(tv stand·shelf)이 두 category에 닿게. 정밀 이름(side table)은 자기 것만 — 한 방향 | 아니오 (누구에게나 같음) |
online_plan.retarget_gt_surfaces (계획) | GT/오라클 계획 문장이 그 씬이 부르는 이름을 쓰게 | GT→GT (누출 없음) |
retarget_rescued_surfaces (구제 행) | R2로 정답 판정된 행의 계획을 GT 바디로. 모델이 댄 가구가 그 방에 진짜 있으면 치환 안 함 | 예 (사용자 결정 260921) |
| 판정 | 수정 전 (find · restore) | 수정 후 |
|---|---|---|
| ok | 117 · 84 | 126 · 97 |
| ungroundable (그 방에 그 이름 가구 없음) | 17 · 17 170칸 | 0 · 0 |
| misrouted (엉뚱한 바디로) | 1 · 5 30칸 | 0 · 0 |
| ambiguous (같은 이름 가구 여럿) | 14 · 42 | 23 · 51 |
남은 ambiguous는 이름 결함이 아니라 답 granularity 한계다 — "어느 의자인가"는 답 어휘로 표현할 수 없다. find는 instances_on이 같은 이름 앵커 전부에서 질의 물체를 찾아 흡수한다. §6에서 따로 다룬다.
shelf였다. 온라인 셀이 "읽기에서 맞힌 칸"만 쓰기 때문에, tv stand 결함 행은 애초에 거의 안 들어왔다.dresser 기각을 우회한다구제 행에 위양성 가드를 실제로 돌려 보니 473행 중 130행(27%)에서 모델이 댄 가구가 그 방에 진짜 있었다. 답 분포: dresser 84 · tv stand 18 · dining table 7 · toilet 5 · 그 외 16.
R2 문서는 "dresser 는 구제하지 않는다 — 실측상 그 방에 진짜 dresser 가 있었다(restore 54/54 · find 80/82)"라고 명시한다. 그런데 추론 원문 어딘가에 "side table"이 나오기만 하면 답이 dresser여도 통과한다. R3를 기각한 바로 그 행들이 다른 문으로 들어온다.
| 가족 | 가장 큰 하락 (그 130행 제외 시) | 우리(tagmem-r3) |
|---|---|---|
| find | textlog(oracle) −0.007 ~ −0.014 (4~8행) | −0.002 ~ −0.003 |
| restore | textlog(oracle) −0.010 ~ −0.026 (6~15행) | −0.002 ~ −0.005 |
guarded: true로 표시, 셀에서 빼는 것을 권함). 읽기 본표를 고칠지는 사용자 결정 대기 — 고친다면 side_pass의 원문 분기 뒤에 "댄 가구가 그 방에 없을 것"을 더하면 dresser 기각과 잣대가 하나로 통일된다.같은 방에 같은 이름 가구가 여러 개라 답이 어느 인스턴스인지 특정하지 못하는 면이다. 실례(restore train_1299__2, "종이타월을 원래 자리에"):
| 장치 | 하는 일 | 왜 모호를 못 푸나 |
|---|---|---|
place_anchors (260918) | 든 채 이동 시 그 가구의 어느 쪽에 설지를 물체 원래 자리 기준으로 정렬 | 게이트가 surface == decision.object_id — 이미 GT 가구를 골랐을 때만 걸린다(순환). 틀리면 접근 보정까지 같이 잃는다 |
instances_on | 같은 이름 앵커 전부에서 질의 물체를 찾아 "물체가 올려진 그 가구"로 접지 | find 전용. restore 목적지는 물체가 아직 거기 없다 — 그게 과제다 |
| 모호한 면 | uid 1등 == GT | |
|---|---|---|
| find | 20 (k=2가 12 · 최대 k=6) | 7 |
| restore (목적지) | 29 (k=4가 14 · k=5가 6) | 6 |
grounding.py의 기존 원칙 — "답의 granularity(방·가구)까지는 메모리 책임, 그 아래 국소 지각은 하네스가 대신한다". find는 그걸 지각으로 풀고, 지각 단서가 없는 목적지는 GT로 푼다.
place_anchors와 같이 하네스 내부에만 쓰이고 VLM에 노출되지 않는다 — 프롬프트 패리티 게이트 통과(공유 프롬프트 288개 바이트 동일).