무엇을 재나. 현재 visual summary 방식 프로세스의 기본 품질. 원본 컴포넌트에서 거꾸로 만든 정답 YAML 을 넣고 지금 운영 그대로(검색 → 대치 → 렌더) 돌려, 1위 결과가 원본과 동등한가를 본다. 정답 YAML 마다 그것을 담는 원본이 있으므로 목표는 100% 다.
동등의 조건. 유형이 같다 · 구조와 자리가 같다(빈칸 · 필드 옮김 · 내용 버림 · 남는 원본 글 · 자리 어긋남 없음) · 제목 요소가 하나 더 생기지 않는다 · 렌더에서 넘침 · 단어 잘림 · 겹침이 없다.
실패는 어느 링크 탓인가. 1위가 틀린 장마다 사슬 순서대로 묻고 처음 걸린 곳 하나에 센다 — 렌더 결함만 있나 → 운영 IIS 가 원본을 막았나 → 원본 자리 용량이 원본 글보다 작았나 → 원본이 깨끗한데 다른 후보가 앞섰나 → 원본 자신의 대치 결함인가.
100% 까지 — 링크별로 잃는 몫
읽는 법
- 통과 몫이 지금의 기본 품질이다. 나머지가 링크별 개선 가능 점수다 — 그 링크를 고치면 되찾을 수 있는 최대 몫.
- 빌드(용량)가 가장 크다: 원본 자리 용량이 원본 글보다 작게 매겨져 원본이 후보에서 빠지고, 남은 후보 중 동등한 것도 1위에 오지 못한다.
- 대치 · 렌더 몫은 1위가 규칙상 동등한데 그림에서 단어 잘림 · 겹침 · 넘침이 생긴 것이다.
- 검색 몫의 절반 넘게는 「제목 자리 있는 후보가 앞섬」 — 원본에 없는 제목 요소가 하나 더 생긴다.
이 탭. 링크마다 두 수를 나란히 둔다. ① 링크 정확도 — 그 링크로 들어가는 입력을 정답으로 고정하고 산출을 그 링크의 정답과 대조한 수. ② 결과에 미치는 몫 — 1위 실패 중 그 링크가 첫 걸림인 장의 비율(%p). 정확도가 낮아도 결과 몫은 작을 수 있다(원본이 막혀도 다른 동등 후보가 1위를 대신하는 경우).
링크 정확도(test)
결과에 미치는 몫(test · %p)
이 탭. 1위 실패의 원인을 링크 구분 없이 임팩트(떨어뜨리는 장 비율) 큰 순서로 세운다. 「사례 보기」를 누르면 그 원인의 장으로 간다.
이 탭. 원인마다 장을 하나씩 「① 원본 → ② 이 링크의 정답 → ③ 이 링크의 산출 → ④ 판정」으로 본다. 검색 링크는 원본의 순위와 1위가 왜 점수가 더 좋은지(비용 항 · 낮을수록 좋다)를, 대치 · 렌더는 1위 렌더 그림과 결함을 보인다.
왼쪽에서 장을 고른다.
부록 · 참고 실험. 29 문서의 엄격판 원본 재현율(원본이 필터를 통과하고, 원본 이상 점수의 후보가 모두 동등)과, 원본 행 일부만 정답으로 고친 스냅샷 계단이다. 원본 순위에 묶인 정의이고 계단이 부분 수선이라 링크별로 깨끗이 갈리지 않아, 본 지표에서 뺐다.
이 탭. 정답을 원본 컴포넌트에서 거꾸로 만든다: 원본 A → ① semantic component(경계 · 속성) → ② YAML(params 포함) → ③ 원문. 종류마다 만드는 방법, 그 방법의 품질을 재는 방법, 만든 결과(세트 · 유형별 분포와 전체 목록)를 담는다.
| 정답 종류 | 입력 | 만드는 방법 | 확정 규칙 |
|---|---|---|---|
| 원본 표본 | 운영 DB(읽기 전용) | 판 2.6 · 뿌리 하나 · 카테고리 하나 · 운영 IIS 카테고리 일치 · Rust 스냅샷 안 DO 에서 유형마다 md5 순으로 뽑는다. 쌍둥이(같은 모양) 제외 | LLM 없음 |
| ① 경계 | 시트 노드 트리 · 썸네일 · 규약(capability 45종) | 판정자 A · B 가 따로 컴포넌트 범위와 글 노드의 역할(core · 위성 · 밖)을 정한다 | A = B 면 확정 · 갈리면 C 가 두 답을 보고 정한다 |
| ① 속성 | 같음 + 경계 | 카테고리 · entities(항목마다 label · items · 필드 노드) · dataset · relations 를 정한다 | 같음 |
| ② YAML | 확정 ① | 규칙으로 변환(LLM 없음 · 결정적). title 은 위성 제목, 없으면 첫 항목 이름(규약 12쪽 「title 필수」). iui 생성 검증기 strict V1 · V3 통과 | 결정적 |
| ② params | 썸네일 + ② + 노드 트리 | iui 속성 어휘(PROPERTY_PARAM_SPEC · 25 카테고리)대로 판정자 A · B · 갈리면 C | A = B · C |
| ③ 원문 v6 | ② | 규칙 템플릿(LLM 없음) — 첫머리 유형 힌트 + params 힌트, 항목마다 이름 줄 · 「- 」 내용 줄. ② 에 없는 글을 덧붙이지 않는다 | 기계 검사 |
판정자: test · val 의 ① 은 Fable, train 은 Fable + gpt-6.1-sol, ext 는 gpt-6.1-sol. params 는 모두 gpt-6.1-sol. 판정 지시문 · 패킷 · 결과 파일은 모두 보관하고, 확정은 그 파일에서 기계로만 낸다(LLM 없는 단계는 다시 돌려 한 글자도 다르지 않음을 확인).
판정자 일치와 모델 대조
| 대조(train 57장) | 속성 | 경계 |
|---|---|---|
| Fable A = Fable B | 48/57 | 51/57 |
| gpt-6.1-sol 대 확정 정답 | 41/48 (85%) | 46/51 (90%) |
| gpt-6-luna 대 확정 정답 | 36/48 (75%) | 39/51 (76%) |
gpt-6.1-sol 은 Fable 끼리 일치에 조금 못 미치는 수준이라 판정자로 골랐다. params 판정은 A · B 일치 852/872, 갈린 20 은 C 로 확정.
확정 방식(① 속성 · 경계)
② YAML · ③ 원문 검사
- iui 생성 검증기 V3 통과: test · val 전부 · train 342/352 · ext 836/865 — 남은 장은 모두 V3 어휘 밖 유형(Ending · QnA · Venn …)이라 정답으로 둔다.
- 원문 기계 검사(② 글 조각이 다 들어 있고 덧붙인 글이 없다): test · val · train 전부 통과 · ext 863/865(같은 글이 네 번 되풀이된 장의 검사기 오탐 2).
- 되접기(원문 v5 → 운영 생성기 → YAML): 유형 · 항목 수 · 자리 전부 같음 test 48.5% · val 52.5%. 갈림은 원문이 아니라 생성기 · 규약의 유형 갈림(List ↔ 표 · 목차 ↔ List)이 대부분.
사람 검수 — 진행 중
- test(Fable) 정답 표본: 경계 60 · 속성 30.
- gpt-6.1-sol 정답 표본(train 10–13 + ext 1,059 중): 경계 60 · 속성 30.
- 렌더 그림 판정 대조: val 무작위 60장.
결과가 오면 정답 신뢰도 · 그림 판정 정확도를 이 탭과 ③ 에 붙인다.
유형별 정답 수(② 기준 · 세트별)
불러오는 중…
이 탭. 고리마다 「정답을 넣었을 때 무엇이 나와야 맞는가」를 정하고, 그 기준으로 잰 결과와 원인을 담는다. 기준의 재료는 검색 · 대치가 후보에서 실제로 읽는 정보뿐이다. 규약 · 구현 · 정답이 어긋나면 규약이 명확하면 규약 · 애매하면 취지 + 규약 보완 · 틀렸으면 규약 정정 순으로 가른다.
| 고리 | 무엇을 평가하나 | 판정 기준(맞음) | 판정 방식 |
|---|---|---|---|
| b 경계 | 컴포넌트 범위와 경계 안 글의 역할 | 정답 ① 의 core · 위성 · 밖과 운영 Frame 역할(unit · 위성 · 경계 밖 · 묶이지 않음)이 같다 | 규칙 — 글 노드 대조 |
| c 속성 | 카테고리 · 유닛 수 · params | 정답 ① 카테고리 · 항목 수 · params 정규화 값이 운영 색인 행과 같다 | 규칙 |
| d 빌드 | 자리마다 매긴 글 용량 | 원본 글이 원본 자기 자리 용량에 들어간다(Rust 용량 게이트를 그대로 옮겨 잰다) | 규칙 |
| e 검색 | 필터 · 순위 | 원본 또는 동등 가치 후보가 1위에 온다. 원본이 빠지면 빠진 자리(필터 항목 · 용량 · 순위 비용 항)를 가른다 | 규칙 — 서버 응답 + 원본 하나 풀 진단 |
| f 대치 | 글을 자리에 싣고 렌더한 결과 | 유형 같음(tier 1) · 빈칸 0 · 필드 옮김 0 · 내용 버림 0 · 남는 원본 글 0 · 글 조각마다 같은 종류 자리 · 남는 headline 유닛이 있으면 제목이 실림 · 글 params 가 실림 · 그리고 그림에서 넘침 · 단어 잘림 · 겹침/가림 · 과축소 0 | 규칙(clean2) + 그림 국소 판정 |
왜 이 기준이 합리적인가
- 정답이 원본에서 왔으므로 「원본 결과」라는 닻이 있다. 원본과 같은 정보를 담는 다른 후보도 맞음으로 쳐서, 원본 하나만 고집하지 않는다.
- 파이프라인이 읽지 않는 요소(색 · 장식 · 디자인 취향)를 끼우면 고리의 결함과 디자인 선호가 섞인다 — 그래서 그것은 LLM judge 몫으로 뗀다.
- 렌더에서만 보이는 결함은 렌더 문서 상자 값으로 믿을 만하게 가를 수 없었다(렌더러가 컴포넌트를 통째로 키워 오탐) → 구운 그림을 노드 단위로 판정한다.
- 제목 중복은 「원본에 없는 요소가 하나 더」라 결함과 따로 센다(검색이 제목 자리 있는 후보를 1점 앞세운 몫 · 류민 결정).
원본 하나만 든 풀에 정답 YAML 로 운영 검색을 그대로 대어, 원본이 어디서 빠지는지 장마다 가른 것이다(정답 v3 진단 기준).
유형별 원본의 운명(전 세트 · 비율)
막대는 유형 안 비율, 오른쪽 수는 원본이 상위 50 안에 든 비율이다.
결과
- 경계 집합(글 노드)은 거의 같다: val 126/126 · test 247/252 · train 358/364 · ext 922/941. 다른 장은 모두 운영 안 글을 정답이 위성으로 뺀 것.
- 결함은 「어디까지」가 아니라 경계 안 글의 역할에서 난다. 정답 core 글 13,904개 → 운영 unit 9,403 · 표 칸 1,506(결함 아님) · Marker 1,255(보존 · 결함 아님).
- 경계 안 내용 글을 묶지 않음 1,083개 · 336장(20%) — Description 289 · Highlight 286 · Title 272 · Subtitle 163 · Decoration 70.
- 정답 core 를 운영이 위성으로 801개 · 240장 — ComparisonTable desc 180 · Donut 88 · Cycle 72.
원인과 영향
- 묶지 않은 내용 글은 대치 뒤 원본 글로 남는다: 해당 장의 원본 잔여 100% 대 나머지 32–44%.
- SWOT(Highlight 153 · Subtitle 76) · 목차(Description 59)에 몰린다.
- 위성으로 간 글은 대치가 위성 자리로 받아 잔여를 만들지 않는다 — 대신 자리 종류(core → desc)가 달라진다.
- 고칠 곳: 운영 IIS 의 역할 부여(경계 안 글은 유닛 필드 또는 위성으로 반드시 묶는다).
운영 색인 행 대 정답 ①(② 가 있는 장)
원인
- 카테고리 어긋남의 절반이 정답 List ↔ 운영 표(ListingTable 85 · ComparisonTable 78) — 시트에 TableItem 이 없는 글 상자 격자를 운영 IIS 는 표로, 정답은 요소 규칙대로 List 로 둔다. 그다음 List ↔ HighlightedMessage 31 · LongForm 25 · BarChart 20.
- 유닛 수 어긋남 497 중 272 가 차트 — 차트 제목 · 주석을 운영 색인 행이 유닛 label 로 잡는다(정답은 차트 = dataset + title).
- params: 운영 색인 행의 24% 가 params 를 가진다(LongForm title · Steps sequence · Cycle rotation …). 정답 v4 에 params 를 넣자 1위가 바뀐 장은 params 있는 장의 4–7%.
결과 — 용량 탈락은 빌드 몫
- Rust 용량 게이트를 그대로 옮겨 원본 글을 원본 자기 자리 용량에 넣어 보았다. 서버가 용량 탈락이라 한 619장 중 582장(94%)은 자기 글도 넘는다. 서버 통과 399장 중 335장(84%)은 넘지 않는다.
- 원인 셋(장 단위 · 겹침): ① 줄 용량 0(hardLimit) 131장 ② 글자 폭 상수 하나(
predictTextBbox.tsAVG_CHAR_WIDTH_COEFF = 0.8597, 문자 체계 무관) ③ 줄 용량이 원본 줄 수의 절반(줄 초과 배율 중앙 2.0). - 10/09 규명(87 DO · TS 게이트)과 같은 원인이 새 정답 1,683장 · Rust 게이트에서 재현된다.
문자 체계별 자기 글 초과율(용량 0 제외)
문자별 폭(라틴 소문자 0.52 · 대문자 0.65 · 공백 0.28 · 한글 0.92 · 가나 · 한자 1.0 — 제안값)으로 바꾸면 582장 중 약 218장(37%)이 풀린다(추정). 실측은 ④ 계단 1.
필터는 통과했는데 상위 50 밖 — 222장(전 세트)
| 원본을 미는 비용 항 | 장 | 비용 합 |
|---|---|---|
| unitBlank(유닛 통째 빈칸) | 106 | 1,590 |
| insideResidue(경계 안 잔여) | 31 | 770 |
| fontShrink | 19 | 75 |
| titleDropped(1위도 받음) | 222 | 222 |
원본 비용 중앙 16.0 대 1위 중앙 1.0(낮을수록 좋다).
원인 — 「차트 제목」 한 뿌리
- unitBlank 106장 중 105장은 원본 유닛이 정답 항목보다 정확히 하나 많고 전부 차트(Donut 36 · Pie 23 · Bar 22 · LineArea 21), 그 남는 유닛에 정답 title 글이 들어 있다(105/106).
- c 고리(운영 IIS 가 차트 제목을 유닛으로) → f 고리(대치가 title 을 그 유닛에 싣지 않음 — 규약 「없으면 첫 headline 유닛」 미구현) → e 고리(빈칸 벌점 15로 원본 50위 밖).
- 모의로 그 벌점만 빼면 141장 중 140장이 1위(동률 포함)로 돌아온다. 실제 고침은 ④ 계단 2.
1위 결과의 규칙 결함(기준 · 전 세트)
그림 결함(1위 · val + test)
- 정답 title 이 진짜 제목인 장의 80–91% 는 1위 결과에 제목이 실리지 않는다 — 후보에 제목 자리도 경계 밖 글 노드도 없을 때.
- 「제목 = 첫 항목 이름」인 장은 후보에 제목 자리가 있으면 같은 글이 두 번 보인다 → 「제목 요소 하나 더」로 따로 센다.
- 도넛 centerLabel 같은 글 params 는 대치가 놓을 자리를 만들지 않는다(params 글 버림).
이 탭(보조 지표). 원본 재현은 A 위의 모든 후보를 보지만, 여기서는 1위 하나만 본다. 정답 YAML 을 넣어 검색 → 대치 → 렌더까지 간 1위 결과가 원본과 동등한 가치인지(규칙 clean2 ∧ 그림 결함 0) 잰다. 세트는 val 118 · test 237(그림 굽기 실패 2장 제외 235). 갤러리에서 장마다 원본과 결과 그림을 나란히 본다.
탈락 사유(기준 · val + test)
한 장이 여러 사유를 가지면 「제목 하나 더 → 규칙 결함 → 그림 결함」 순으로 하나에 센다.
읽는 법
- 규칙만으로는 1위의 90–95% 가 원본과 동등하다. 그림에서 단어 잘림 · 겹침 · 넘침이 약 20% 를 더 깎는다.
- 「제목 요소 하나 더」는 정답 title 이 첫 항목 이름인 장(원본에 제목 자리가 없다)에서 제목 자리 있는 후보가 이길 때 생긴다. 원본이 후보였다면 제목이 안 실려 원본 그대로였을 것이다.
- 정답 title 출처로 나누면: 제목 위성 67–69% 대 첫 항목 이름 43%.
유형별 동등 가치(기준 · val + test)
이 탭. 원인으로 짚은 고리를 고친 서버를 따로 띄워(실험용 로컬 사본 · iui 에 반영하지 않는다) 같은 정답 · 같은 장치로 다시 잰다. 계단을 쌓아 개선 몫을 가른다.
계단
| 계단 | 고친 것 |
|---|---|
| 기준 | iui main cc6d1e4f4 그대로 |
| 1 용량 | 용량 게이트가 문자별 폭으로 줄 · 글자 수를 잼 + hardLimit 줄 용량 0 → 1 |
| 2 제목 유닛 | + 후보에 제목 위성이 없고 남는 첫 유닛이 label 하나뿐이면 그 유닛에 title(규약 「첫 headline 유닛」) |
| 2′ 차트 한정 | + 계단 2 를 차트 카테고리에만 |
동등 가치
표 — 원본 기준
| 세트 | 기준 | 계단 1 | 계단 2 | 계단 2′ |
|---|---|---|---|---|
| val 118 | 53.4% | 56.8% | 58.5% | 57.6% |
| test 235 | 53.2% | 56.2% | 58.7% | 57.4% |
| test 기준 대비 좋아짐/나빠짐 | 7 / 0 | 18 / 5 | 15 / 5 | |
| test 원본 상위 50 | 30 | 40 | 46 | 46 |
계단 1 · 2 는 test 에서 유의(부호 검정 p 0.016 · 0.011). val 은 장 수가 적어 유의하지 않지만 방향은 같다. 용량을 넓혀도 그림 결함은 늘지 않았다.
부작용 — LLM judge 로 잡힌 것
- 계단 2 는 원본 기준으로 좋아졌지만 judge BAD 비율이 23.0% 에서 41.5% 로 올랐다. 원인 = 제목 패치가 차트가 아닌 보통 항목 유닛까지 잡아 페이지 제목이 첫 항목 자리에 들어가고 항목이 밀림(위계 역전). 원본 기준은 제목이 「실렸다」만 보고 그 유닛이 제목 역할인지 보지 않아 놓쳤다.
- 계단 2′(차트 한정)에서 차트 아닌 쪽 위계 역전은 사라졌다. 차트 안에서도 첫 유닛이 제목이 아닌 후보(범례 · 주석)가 섞여 좋아짐 26 대 나빠짐 18 로 갈린다 → 제목 유닛을 가르는 신호(역할 · 위치 · 글자 크기)가 더 필요하다.
정식 구현 — iui 브랜치 feat/vs-basic-quality-fixes (10/15)
계단 1(용량)을 실험용 환경변수 패치가 아니라 iui 코드로 옮겼다. 서버 런타임 설정 두 개(capacity_glyph_width, capacity_line_floor, 기본 꺼짐)로 켜고, 용량 사전 거름도 같은 측정을 쓴다. 꺼져 있으면 결과가 종전과 바이트 단위로 같다. 브랜치는 원격 push 까지만 했고 PR 은 열지 않았다.
결과 — 계단 1 과 같다
judge 는 새 판정 없이 지난 회차(#271, #263, #261)의 판정을 렌더 요청 내용 해시로 다시 썼다. 원본 기준이 그대로인데 1위만 바뀐 장에서 judge 가 움직이는 것은 자기일치도 회차 #262 에서 본 「후보의 디자인 차이」와 같은 양상이다.
귀속 변화 — test 235, 첫 걸림
| 링크 | 기준 | F1 |
|---|---|---|
| 통과(1위 동등) | 125 | 132 |
| 빌드 | 37 (15.7%p) | 21 (8.9%p) |
| 대치 · 렌더 | 33 | 33 |
| 검색 | 23 | 29 |
| IIS | 17 | 20 |
빌드에서 빠진 16장 중 7장은 통과로, 나머지는 사슬 뒤쪽(검색의 「제목 요소 하나 더」, IIS 의 「경계 안 글 미결속」)으로 첫 걸림이 옮겨 갔다. 원본이 용량 게이트를 통과하게 되면서 그 뒤 링크의 문제가 드러난 몫이다.
넣지 않은 것 — 차트 제목 유닛에 title (F2)
- 차트 후보의 Frame 은 유닛이 하나뿐이고(차트 본체는 dataset), dataset 글의 글자 크기와 행의 최대 글자 크기도 비어 있다. 같은 후보 안에서 「첫 유닛이 제목처럼 큰가」를 견줄 재료가 검색 서버에 없다.
- 남는 것은 절대 글자 크기 문턱뿐이다. 페이지 크기에 따라 흔들리고, val 과 test 사례를 보고 정한 값이 되어 「test 는 통계만 본다」는 규칙에 어긋난다.
- 제목 유닛을 가리려면 색인 단계에서 유닛 label 노드의 역할이나 위치를 Frame 에 실어야 한다. 색인을 다시 빌드해야 하는 일이라 이번 범위 밖이다.
이 탭. 고치기 전 · 후 1위를 운영 judge 와 같은 조건으로 판정했다. 결정(류민 10/14): 원본 기준과 judge 는 서로 다른 것을 재는 두 지표로 함께 보고한다 — 원본 기준은 「담을 수 있나 · 제자리에 실리나」, judge 는 「결과 디자인이 좋은가」. judge 입력 원문은 정답 원문 v6. BAD 비율은 낮을수록 좋다.
동등 묶음별 BAD 비율 (회차 #271 · #273 · #263, val + test)
| 묶음 | 장 | BAD | 디자인 완결성 뺀 BAD |
|---|---|---|---|
| ① 원본 그대로 | 353 | 8.2% | 5.9% |
| ②+③ 1위가 원본 또는 동등한 다른 후보 | 186 | 15.6% | 10.8% |
| ④ 1위가 동등 아님 | 164 | 31.1% | 25.6% |
| ④ 중 대치 · 렌더 | 53 | 39.6% | 39.6% |
| ④ 중 IIS | 25 | 36.0% | 32.0% |
| ④ 중 빌드 | 54 | 29.6% | 22.2% |
| ④ 중 검색 | 32 | 15.6% | 3.1% |
읽는 법
- 세 묶음이 기대한 순서로 갈린다. 원본 그대로 8.2%, 동등 15.6%, 동등 아님 31.1%(원본 대 동등 p 0.009, 동등 대 동등 아님 p < 0.001). 헤드라인의 「동등」이 judge 가 보는 결과 품질과 같은 방향이라는 보조 증거다.
- 원본 그대로는 원본 시트를 대치 글 없이 ②–④ 와 같은 미리보기 렌더러에 태워 재배치하고, 같은 판정 칸으로 쟀다. 디자인 완결성까지 포함한 값을 그대로 견준다.
- 1위가 원본 자신인 장은 3장뿐이다. 동등의 대부분은 원본과 같은 템플릿의 다른 행이 1위에 서는 경우라 ②와 ③을 함께 본다.
- 검색 몫은 디자인 완결성을 빼면 거의 BAD 가 아니다. 검색 실패의 대부분인 「제목 요소 하나 더」는 judge 도 결함으로 보지 않는다.
계단 1 (회차 #261 · 118장)
자기일치도 (회차 #262)
차이 약 24%p 는 judge 흔들림이 아니라 바뀐 후보의 실제 디자인 차이다.
계단 2 · 2′ (회차 #263 · 135장)
judge BAD 비율 — 전 · 후
읽는 법
- 장 단위로 둘 다 움직이면 방향은 대체로 같다(계단 2 · 2′ 에서 유의).
- 원본 기준이 「같음」인 장에서도 judge 는 움직인다 — 1위가 다른 후보로 바뀌면 judge 는 그 후보의 디자인(가림 · 페이지 균형 · 스타일 · 대비)을 새로 잰다. 원본 기준의 범위 밖이다.
- 그래서 judge 의 디자인 차이는 후보 고르기(검색 순위) 과제로 따로 다룬다.
이 탭. 정답 1,572장을 한 장씩 본다 — 원본 썸네일 · 정답 YAML · semantic component(정답 ① · 운영 색인 행) · 원문 v6 · 검색 1–10위 썸네일 · 1위 대치 결과(바인딩 · 빈칸 · 비용 항) · 렌더 그림과 그림 판정 · LLM judge 등급 · 원본의 운명. 렌더 그림은 val · test 에만 있다.
왼쪽에서 장을 고른다.
이 탭. 「맞음」의 정의 · 사슬 고리 · 측정 장치 · 한계 · 내려진 결정 · 다음 일을 담는다.
사슬 — 정답 YAML 이 들어가 결과가 나오기까지
| 고리 | 하는 일 | 이 측정에서 |
|---|---|---|
| a 생성 | 원문 → YAML | 보조(정답 원문 v6 되접기). 주 사슬은 정답 YAML 에서 시작 |
| b 경계 | 컴포넌트 범위 · 글 역할 | 정답 ① 대 운영 색인 행 |
| c 속성 | 카테고리 · 유닛 · params | 정답 ① 대 운영 색인 행 |
| d 빌드 | 자리마다 글 용량 | 원본 글이 원본 자기 용량에 드는가 |
| e 검색 | 필터 · 순위 | 원본 · 동등 후보가 상위에 오는가 |
| f 대치 | 글을 자리에 싣기 · 렌더 | 규칙 판정 + 렌더 그림 국소 판정 |
한눈에 — 지금 무엇이 문제인가
- 용량이 원본을 가장 많이 막는다(test 237 중 90장). 그 94% 는 원본 글이 자기 자리 용량조차 넘는다 — 빌드가 매긴 용량이 작다(글자 폭 상수 하나 · 줄 용량 0).
- 차트 제목 한 뿌리가 세 고리에 걸친다 — 운영 IIS 가 차트 제목을 유닛으로 잡고 → 대치가 title 을 그 유닛에 싣지 않아 → 빈칸 벌점으로 원본이 50위 밖.
- 경계 안 내용 글을 묶지 않는 장이 20%(336장) — 그 장은 원본 글이 100% 잔여로 남는다.
- 1위 결과의 동등 가치는 val 53.4% · test 53.2%. 탈락은 「제목 요소 하나 더」(따로 세는 몫) · 그림 결함(단어 잘림 · 겹침 · 넘침) · 규칙 결함 순.
- 두 계단을 고치면 test 58.7% 까지 오른다(유의). 다만 LLM judge 는 같은 변화를 디자인 쪽에서 다르게 본다 — 두 지표를 함께 본다.
측정 장치
| 검색 | 로컬 Rust comp-pass 서버 — iui main cc6d1e4f4 빌드 · 스냅샷 2.6(10/08 · frame 행 220,847) · 운영 frame-search 그대로 |
|---|---|
| 대치 | iui 상류 buildFrameReplacement 사본(파일 단위 드리프트 0 · 매니페스트 94 파일) |
| 렌더 | 제품 미리보기 렌더러(상자 넓히기 · 글자 축소 · 정렬 반영) → 합성기로 그림 |
| 그림 판정 | gpt-6.1-sol · 대치한 글 노드마다 넘침 · 단어 잘림 · 겹침/가림 · 과축소 · 같은 그림 두 번 판정 일치 99% |
| LLM judge | 운영 judge 와 같은 조건(gemini-3.5-flash · 5축 · 프롬프트 묶음 8 · excluder · 검증 · 재평가) |
| 원본 운명 진단 | 원본 하나만 든 작은 스냅샷을 같은 서버에 올려 원본이 필터를 통과하는지 · 어디서 빠지는지 가른다 |
한계 · 미확정
- 사람 검수(정답 표본 · 그림 판정 대조) 전 — 신뢰 구간 미부착.
- 스냅샷은 2.6 · 10/08 공개본. 실시간 풀과 다를 수 있다.
- 원본 운명 진단은 정답 v3(params 없음) 기준.
- 원문에서 시작하는 사슬(생성 고리)은 보조로만 쟀다. 실제 사용자 원문은 아직 보지 않는다.
- 렌더 · 그림 판정은 val · test 만. train · ext 는 규칙 판정까지.
내려진 결정
- 맞음 = 원본과 동등 가치 · 기준은 추출 · 검색 · 대치가 읽는 정보만.
- 판단 순서: 규약 명확 → 따름 · 애매 → 취지 + 보완 · 틀림 → 정정.
- 정답에 params 를 넣는다(gpt-6.1-sol 판정 허용) · 원문에 params 힌트 허용.
- 제목 위성이 없는 원본의 정답 title = 첫 항목 이름 · 제목 중복은 따로 센다.
- 원본 기준과 LLM judge 는 두 지표로 함께 보고.
다음
- 사람 검수 반영 → 확정판(신뢰 구간).
- 제목 유닛 신호를 더한 계단 2″.
- 경계 안 내용 글 묶기 · 차트 제목 위성화(운영 IIS 몫) 설계.
- judge 가 잡는 디자인 차이 — 후보 고르기 과제로.