11/27 까지 위성과 L3(포함 위상) 중 무엇을 먼저 하나

2026-11-04 · 11/06 팀 공유용 · 동반 문서 실험에서 임의로 정한 것

자세한 수치 · 그림 · 프롬프트 전문은 실험 사이트 부록(https://vs-sat-l3.miridih.app)에 있다. 실험에서 우리가 임의로 정한 정책 · 구현은 동반 문서 「실험에서 임의로 정한 것」에 모았다.

질문과 전제

• 질문: 12월 배포를 목표로 11/27 까지 할 일로 「L3(포함 위상)」와 「위성」 중 무엇을 먼저 하나.
• 두 축: 1. 작업량(난이도), 2. 효과.
• 실험의 전제. 정해지지 않은 정책은 실험 쪽에서 정했다. 없는 코드는 실험용으로 구현했다. 그래서 결과는 「실제 구현과 다르지만 방향은 같게 한 대리 조건」에서 나온 것이다. 정한 것과 그것이 결과를 어느 쪽으로 기울이는지는 동반 문서와 이 문서 끝의 「한계」 표에 있다.
• 입력과 풀.
  • 입력은 운영 생성 로그의 최근 원문 400 이다(L1 · L2 YAML 은 운영이 만든 것 그대로).
  • 풀은 2.7 판 전체(frame 284,300)다. 2.4–2.6 판에만 있던 포함 DO 1,008 개를 덧붙여, 포함 공급을 1,694 행으로 키웠다(L3 에 유리한 쪽).
  • 검색 서버는 운영 계보 판(iui PR #1612 머지 시점)이다.
• 비용. 실험 전체 실비는 약 $131.7 이다(판정 $126.27 포함).

개념 — 레벨과 위성

복잡도 레벨 (규약 mordor-wiki projects/mordor/visual-summary/spec/schema-v0.5.md 8.7–8.9)

• 규약 8.8 은 레벨을 「산출물 모양」이 아니라 「생성기에 허용한 범위」로 정의한다. 그래서 누적이다(L1 ⊂ L2 ⊂ L3).
• 규약 8.9 는 「병치」를 두 층으로 나눈다.
  • 질의 쪽 병치(L2): 컴포넌트 경계가 이미 갈린 것이다.
  • 색인 쪽 Juxtaposition(8.7): 컴포넌트 하나 안의 영역 배치다.
• 운영 생성기는 L1 · L2 만 낸다. iui main comp-pass-logic/src/generate/level.rs 의 Level::SUPPORTED 가 L1 · L2 이고, L3 요청은 normalize_wire 가 400 으로 거절한다.
  • 운영 생성 로그(10/21–11/03, 23,861건)에 L3 문서는 0건이다.
  • L2 요청 가운데 실제로 병치(형제 2개 이상)를 낸 것은 17.0% 다.
• 색인에는 포함이 적다. 운영 경계 추출(boundary-v12.4)은 포함을 Containment 관계로 이미 낸다.
  • 포함 관계가 있는 DO 는 2,172 개(0.36%)이고, 병치는 54,722 개(9.0%)다(경계가 있는 DO 609,027 기준).
  • 색인 frame 에는 부모 frame 의 nested 로 들어간다. 2.7 판은 696 행 / 281,706 행이다.
  • 그 가운데 86% 가 「부모 entity 하나에 자식 하나」 꼴이다(전 판 합계 1,707 행 중 1,471 행).

위성

• 위성은 경계(core) 밖에 딸린 제목 · 설명 글 · 장식이다. 글이면 desc, 그 밖(그림 · 도형 · 배경)이면 deco 다.
• 운영 경계 프롬프트 boundary-v12.4(운영 DB 등록부)는 「boundary 는 core 노드만 덮는다. 컴포넌트 전체 제목 · 부제 · marker · 배경 · 장식 같은 satellite 는 어느 boundary 에도 속하지 않는 것이 정상」이라고 적는다. 그러나 출력에 위성 칸이 없다. 그래서 경계 밖 노드는 기록되지 않는다.
• 위성 귀속에는 세 규칙(tree · box · near)이 있다. 페이지 IIS PoC 의 정의를 따른다(3편).
  • 이번 실험은 tree 위성만 썼다. tree 위성은 「DO 의 RLSC 잎 − 모든 경계 서브트리」이고, LLM 없이 코드로 계산된다(전량 26초).
  • 2.7 풀 경계 행의 14.9%(42,502 / 284,300)에 desc 위성이 생겼다.
• 지금 색인 frame 의 satellites{title, subtitle, desc} 칸은 이름은 같지만 다른 것이다. iui main comp-frame-index 의 collectHeaderSatellites 가 경계 안 헤더 글로 채운다.

1. 작업량

크기(소 · 중 · 대)는 실험 구현과 코드 확인에 근거한 판단이며, 정해진 공수 기준은 없다(제안). 코드 이름은 레포 main 의 파일 · 함수 이름이다. 「실험 코드」라고 적은 것은 원격에 반영되지 않은 실험 코드다.

1-1. L3 조합 없음 — 포함 DO 를 그대로 찾아 대치만

1-2. L3 조합 포함 — 부모 DO 와 자식 DO 를 따로 찾아 한 장에 짜 넣기

1-3. 위성

1-4. 작업량 요약

2. 효과

2-1. 측정 설계

• ①–④ 는 위성 유무 × L3 유무의 2×2 다. ⑤ 는 조합 대리다.
• 측정기는 넷이다.
  • judge: 다섯 축 · rep 1 · 정본 총평 규칙.
  • 기본 품질 카드 13장: 규칙 7 · LLM 6.
  • 짝 선호: 두 장을 나란히 보여 고르게 하는 새 측정기. 순서를 바꿔 두 번 묻는다.
  • 사람 검수 대체: 에이전트가 그림 40장을 직접 확인했다.
• 표본: 장 자리 1,000(원문 357)을 한 번 뽑아 모든 비교에 같은 자리를 썼다. 구간은 원문 군집 부트스트랩 95% 구간이다. 그림이 같은 자리는 판정을 복제했다.

2-2. judge — 조건이 구별되지 않는다

• 구간이 모두 0 을 넓게 걸친다.
• 축별로 0 을 넘는 것은 ①-49 의 시각적 계층 구조 하나다(+2.6%p, +0.7 – +4.6).
• 감점을 끈 ②′ 는 BAD 는 같지만 PERFECT 가 줄었다. (나음 − 나쁨)이 −5.2%p(−9.8 – −0.4)다.
• judge 는 절대 지표가 아니다. 같은 그림을 다시 판정했을 때 BAD 일치는 65% 였다. 「차이 없음」에는 이 흔들림이 섞여 있다.

2-3. 짝 선호 — 위성을 고른다

• 표본은 그림이 다른 자리에서 뽑은 200쌍이다. 두 답이 같은 쪽을 가리킬 때만 승패로 센다.
• judge 가 같은 등급을 준 103쌍에서도 짝 선호는 ② 41 · ① 19 · 같음 11 · 갈림 21 로 ② 를 고른다.
• 판정 사유를 보면 ② 쪽은 「표 형식으로 깔끔」 「단어가 부자연스럽게 잘리지 않음」이고, ① 쪽은 「막대 라벨 누락」 「불필요한 빈 상자」다.
• judge 등급 차가 보지 못하는 차이(제목 칸 · 글 배치)를 짝 비교가 잡는 것으로 보인다(해석).
• 짝 선호도 독립 측정기가 아니다. judge 와 같은 모델 계열이다. 위치 편향도 있다(400답 중 「A」 201 · 「B」 148). 순서를 바꾸면 갈리는 쌍이 20% 다.

2-4. 기본 품질 카드 — 뚜렷한 것만

(단위 %, 차이 %p · 구간. 13장 전체 표는 사이트 부록 「판정 결과」.)

• R6 · R8 · D4 는 위성 쪽에서 나아진다.
• E3 은 감점이 지킨다. 감점을 끈 ②′ 는 15.7% 다. 감점이 「비운 위성 칸이 보이는 장」을 막는다.
• E5 는 ② 에서 나빠진다(+2.3%p).
• ※ E1 · D2 는 측정기 불일치다. ② 는 컴포넌트 제목을 싣는데, BQ 측정기는 문서 제목을 정답으로 쓴다.
  • E1 결함 근거 144 중 126 이 「제목이 page_yaml 과 다르다」이고, D2 결함은 모두 제목 칸이다.
  • 제목 사유를 빼면(제안 보정) D2 는 차이가 0 이 된다. E1 은 0.5% → 5.0%(+4.5%p, +2.9 – +6.2)가 남는다.
  • 측정기에 컴포넌트 제목을 알리기 전에는 E1 결론을 내지 않는다.

2-5. 사람 검수 대체 — 위성 결함 사례

judge 는 BAD 인데 관문 카드가 결함을 못 잡은 장을 에이전트가 그림으로 봤다.

• ② 에서 많이 본 결함은 둘이다.
  • 같은 글 두 번(제목 칸과 본문 · 말풍선 · 꼬리 글이 같은 글, 5장). 컴포넌트 제목 칸에서 생기는 위성 고유 결함으로 보인다(해석). 지금 관문 카드에는 이것을 재는 카드가 없다.
  • 표 템플릿 13903035 의 행 정렬 불일치(5장).
• 그 밖에 차트 범주 · 수치 글 없음(4), 템플릿 문구 남음(1), 비운 글 자리 빈 상자(1) 등이 있다.
• 오판 비율로 BAD 를 보정하면 ① 20.1% · ② 21.6%, ②−① +1.5%p(구간 −1.5 – +4.6)다. 원값(−0.8%p)과 방향이 바뀌지만 둘 다 0 을 걸친다.
• 사람 판정으로 확정하려면 이 40장을 사람이 다시 본다.

2-6. 이상 L3(⑤ 합성 대리) — 6쌍 모두 졌다

• 방법: 부모 DO 1위 장의 entity 상자 안에, 자식 DO 1위 장을 종횡비를 지켜 줄여 넣었다(변형 A · B).
• 결과: ⑤ 대 ② 6쌍(원문 3 × 변형 2)에서 ② 가 모두 이겼다. 순서를 바꿔도 같았다.
• 사유: 자식이 썸네일 크기라 읽히지 않음(축척 0.06–0.22) · 내용 누락 · 깨진 상자.
• 이것은 대리의 한계다. L3 포함 꼴의 잠재 효과를 이 대리로는 잴 수 없다. 실제 조합 설계에 무엇이 필요한지는 동반 문서의 「L3 조합(⑤ 합성기)」 절에 있다.

2-7. 어휘 확장(18 → 45종) 효과

• ①-49 대 ① 은 L1 · L2 를 45종 어휘로 다시 생성한 효과다(L3 와 무관).
• judge BAD 는 같다(+0.1%p).
• 짝 선호는 ①-49 를 고른다(+14.0%p, +1.6 – +25.8).
• 시각적 계층 구조 축만 나빠진다(+2.6%p).
• ①-49 는 「시각화 종류」 추천(1군) 문서 없이 돌았다. 그래서 이 값은 어휘 확장과 군 구분 없음이 합쳐진 효과다.
• 이 결과는 위성 대 L3 질문 밖이지만, 18종 제약이 L3 생성도 막는다는 점(2-8 관문 2)과 이어진다.

2-8. L3 가 서비스까지 닿지 못하는 세 관문

원문 ──▶ 생성 ──▶ 공급(검색) ──▶ 서비스 노출
 0.25–0.5%   L2 와 같음 61–64%   앞 10 에 L3 0/11

• 가상 원문 50 은 포함 DO 50개(조합 50가지)에 맞춰 LLM 이 썼다. 실제 유저 원문보다 구조 표지가 뚜렷하다(L3 에 유리).
• 「바깥만」 갈래(안쪽 내용을 바깥 entity items 로 접음, V3 12 · V1 19)는 스키마상 L1 접기와 정보량이 같다. 이것은 생성 결함으로 보기 어렵다. 「L1 Versus 질의가 Versus ⊃ List DO 를 찾는가」 같은 검색 쪽 동치 문제는 따로 재야 한다(제안).
• 판정: 프롬프트만 고쳐서는 ③ 의 효과가 나기 어렵다. 지금 공급 꼴 · 관문으로는 L3 형을 더 만들어도 ③ = ① 이 되기 쉽다(해석).

권고 — 11/27 범위 (제안)

위성을 주로 하고, L3 는 「조합 없는 매칭까지」 또는 보류한다. 근거 기준이 따로 정해진 것은 없으므로, 아래는 모두 제안이다.

위성 (주)

• 범위:
  • tree 위성 계산(코드).
  • 컴포넌트 title · subtitle 생성.
  • 질의 위성 · 부제 짝.
  • 위성 감점 · 가점.
  • 못 채운 위성 글 비우기.
  • 같은 글 두 번 막기.
  • 측정기에 컴포넌트 제목 반영.
• 조건:
  • 감점 · 가점을 꼭 함께 넣는다(감점이 없으면 E3 +9.8%p).
  • box · near 귀속과 deco 는 이번 범위에서 빼고, tree 위성만 쓴다. near 는 검증이 안 됐고, 추출기 작업량이 대로 커진다.
  • 같은 글 두 번 결함은 생성 프롬프트(제목이 entity 글을 되풀이하지 않게)와 대치 검사 양쪽에서 막는다. 재는 카드를 같이 만든다.
  • 배포 전에 사람이 그림을 확인한다(사람 검수 대체 40장의 재확인 포함).

L3 — 조합 없는 매칭까지, 또는 보류

• 조합 없는 매칭까지 할 조건:
  • Rust 서버 이식과 N1 · N2 노출 규칙만 넣는다. 결과가 바뀌는 장이 거의 없다는 점을 받아들인다.
  • 프롬프트 판별 문장을 공급 다수 꼴(「entity 하나에 자식 하나」)도 포함으로 이끌게 고치고, L3 유리 원문 50 으로 다시 잰다.
  • pair_nested 개수 관문을 그대로 둘지 정한다(검색 담당 결정).
• 보류할 조건: 위의 셋을 11/27 안에 할 여력이 없으면 보류한다. 지금 상태로 켜면 서비스 결과가 바뀌지 않으므로 보류해도 잃는 것이 없다(이번 측정 범위에서).
• L3 조합 포함은 11/27 범위에 넣지 않기를 권한다. 작업량이 대이고 로드맵 조합 단계와 겹친다. 대리 실험(⑤)은 6/6 졌다.

한계와 가정이 결과를 기울이는 방향

부록

• 실험에서 임의로 정한 것(동반 문서): 가정 A-1–A-13 과 추가 결정, 프롬프트 · 정책 · 합성기.
• 실험 사이트(https://vs-sat-l3.miridih.app):
  • 판정 결과 전체 표(judge 축별 · 카드 13장 · 짝 선호).
  • L3 유리 원문 50 목록과 갈래.
  • 그림 사례(위성 결함 · ⑤ 합성 장).
  • 프롬프트 전문. 유저 원문의 개인 정보는 사이트에서 가림 처리했다.
• 배경 게시본:
  • 위성 정의와 귀속 규칙: 페이지 IIS 3편
  • 경계 밖 글을 frame 글로 올린 조건 C: 파일럿 결과
• 규약:
  • mordor-wiki projects/mordor/visual-summary/spec/schema-v0.5.md 8.7–8.9(레벨 · 위상)
  • spec/capability-table.md 3.6(N1–N5)