유형을 먼저 보는 검색에서, LLM이 고른 유형의 컴포넌트는 충분한가

무엇을 쟀나

예전 검색은 유저 질의를 summary로 바꾼 뒤 구조와 길이로 찾았다. 컴포넌트가 어떤 유형인지는 보지 않았다. 바뀐 검색은 LLM이 판단한 유형으로 먼저 좁힌다. 공급이 유형별로 나뉘므로, LLM이 자주 고르는 유형에 컴포넌트가 적으면 예전에는 충분했던 후보가 모자라게 된다. 이 리포트는 그 우려를 8월 실제 질의로 잰다.

유형만 같다고 매칭되지는 않는다. 질의의 structure가 아래 순서를 모두 통과해야 후보가 된다. 이번 측정은 길이 조건까지 넣었다.

tier 1

LLM이 고른 유형 그 자체. 유형을 지켰다는 뜻이다.

tier 2 · 3

다른 유형으로 내려간 대체물(fallback). tier 3은 목록·장문·강조 메시지 세 종의 마지막 안전망이다.

stage 0 · 1 · 2

질의와 컴포넌트의 모양 비트가 0 · 1 · 2개 다르다.

L0

tier 1 × stage 0 — 유형도 모양도 그대로.

L1

tier 1 × stage 0–2 — 유형은 지키고 모양은 두 비트까지.

L2

tier 1–2 × stage 0–2 — 대체 유형까지 포함.

수요 건 질의에서 나온 컴포넌트 개를, 공급 행(IIS DO)에 검색했다. 검색 예산(min_candidates · top_n · tier_targets)은 풀었다 — 예산이 아니라 공급의 두께를 재기 위해서다.

길이를 넣으면 커버리지가 내려간다

공급에 label 용량을 넣지 않으면 길이 조건이 걸리지 않아 수치가 부풀어 오른다. 용량을 넣자 L0가 pp 떨어졌고, 질의는 섰는데 요청 유형의 공급을 못 찾은 몫이 두 배가 됐다.

허용 36종(불허 9종 제외) 기준도 거의 같다 — 불허 9종이 수요의 뿐이라서다. 이하 수치는 모두 용량 포함이다.

유형을 지킨 후보 수

우려에 직접 답하는 지표는 L2가 아니다. L2에는 다른 유형의 대체물이 섞인다. 아래는 LLM이 고른 유형 안에서만(tier 1 × stage 0–2) 찾은 후보 수다.

후보 0의 원인은 공급만이 아니다

유형 풀이 0인 컴포넌트 개 중 개는 질의가 검색 전에 깨져 그 유형을 조회조차 하지 않았다. 공급이 없어서 0인 것은 개()다. 이 둘을 섞어 "컴포넌트가 적다"로 읽으면 처방이 반대로 간다.

표의 비율은 전체 컴포넌트 대비다. 「그 밖의 사유」(개수 미달 등)는 카테고리별로 나누지 않았다.

질의 결함 두 가지

1. relation이 label 대신 id를 가리킨다

프롬프트(prompts/system.md 67줄)는 「of에는 그 블록 entities의 label을 적는다」고 지시한다. 후처리 assignIds도 label로 찾는다. 그런데 모델은 of: [e1, e2]처럼 id를 적는다. 산출된 of 값 87개가 전부 eN 꼴이었고 label과 맞는 값은 없었다. relation을 읽는 두 유형이 검색을 시작하지 못한다.

2. x축 셀 규칙이 프롬프트와 모순된다

셀 타입 규칙 B-37(2026-09-05 확정)은 role: x 열을 숫자로 요구한다. 그런데 프롬프트는 { label: 연도, role: x }를 좋은 예시로 가르치고, 실제 시간축은 대부분 범주다. 선·콤보 차트 x 셀 개를 나눠 보면 수는 한 줌이다.

그래서 Trend.LineAreaChart의 가 차트 유형으로 조회되지 않는다. 표 유형(ListingTable · ComparisonTable)도 role: value 열에 "약 161", "임금 동결" 같은 문자열이 들어가 같은 규칙에 걸린다.

질의만 고치면 요청 유형에 닿는다

검색 코드와 공급은 그대로 두고 질의만 고쳐 같은 조건으로 다시 검색했다. 결함 1은 of의 id를 label로 바꿨고, 결함 2는 셀 타입을 어긴 열의 role을 지웠다(B-37은 role이 없는 열을 제약하지 않는다).

이 반사실은 도달 등급만 셌다. 고친 뒤 유형 풀이 몇 개인지는 재지 않았다.

N.C.E. 차트 수요

막대 길이·호 각도로 값을 담는 차트 8종은 네이티브 차트 노드가 있는 컴포넌트에만 내용을 넣을 수 있다. 커버리지의 L0·L1은 같은 유형 태그에 닿았다는 뜻일 뿐이라, 그 적중이 진짜 차트 행인지 따로 확인했다.

• 허용 6종은 진짜 차트 공급에 닿는다 — tier 1 적중이 있는 컴포넌트는 모두 native 행을 포함한다. 다만 모양까지 정확한 적중(L0)은 낮다.
• Trend.LineAreaChart의 낮은 적중은 공급이 아니라 결함 2 때문이다.
• Gauge의 L1은 착시다 — 적중이 모두 게이지 태그만 붙은 비차트 행이었다. Radar는 적중 자체가 없다. 두 종 모두 생성기 불허 대상이다.

native 적중 확인은 용량을 넣기 전 공급으로 했다. 용량은 모양·출처를 바꾸지 않으므로(Frame 출처 분포 동일) 적중 행의 native 여부 판단에는 영향이 없다.

전제와 한계

• 공급은 무작위 표본이 아니다. dv2.4 유효 컴포넌트 약 25만 중 태그별 균형으로 뽑은 10만 건의 IIS 결과다. 희소 유형이 과대표집됐으므로 유형별 공급 행을 전체 풀 분포로 읽으면 안 된다.
• 커버리지는 하드 필터를 통과한 수이지 내용 대치 성공 수가 아니다. 스타일 적합까지 보장하지 않는다.
• 세는 단위는 컴포넌트 행 하나다. DO 단위나 텍스트 지문 dedup 단위의 옵션별 통계는 내지 않았다.
• 가짜 표·차트를 차감하지 않았다. dv2.4 유효 풀의 가짜는 2건뿐이라 결과에 영향이 없다.
• 용량은 현재 코드로 다시 계산했다. 적재된 iui.text_capacity는 계약 변경(9/11) 이전 산물이라 쓰지 않았다. vt2 캐시 적중 DO 100,007 / 100,025.
• 예산을 풀었다. 운영 기본값(min_candidates 500 · top_n 50)에서의 실제 풀보다 크다. 대신 top_n을 낮추면 L0 판정이 뒤집히므로(26건 중 9건) 판정 정확성을 위해 풀었다.
• 파라미터 정책 배제는 따로 집계하지 않았다.

재현 좌표

생성: . 원자료와 표는 작성자 vault auto/research/2026-09-12-mor2418-demand-coverage/에 있다.