Visual Summary 검색·대치
텍스트는 어디서 개입하나

요청한 흐름을 따라 읽되, Visual Tree 자체를 그대로 해시하는 구조는 아니다. 컴포넌트의 doc + RLSC와 사용자의 markdown이 각자 준비되어 조회에서 만난다.

↓ 두 경로가 Candidate retrieval에서 만남 ↓

1. ① Visual Tree 구성

   기하 포함 관계 + 반복 그룹 판정. 글자 수 비율을 사용하며 VT2 tight box는 렌더된 텍스트의 기하다.

   TEXT USED?YES · 원본 텍스트 파생

2. ② Signature 생성

   RLSC → signature forest → 구조 해시. Visual Tree는 별도로 저장·채점에 기여한다. 용량·스타일·fingerprint도 생성한다.

   TEXT USED?YES · 저장 행 / 생성 과정

3. ③ Candidate retrieval

   질의 트리의 변형 해시와 일치하는 행을 조회하면서 cap_chars·cap_lines를 필터링한다. sig3는 노드별 벡터도 비교한다.

   TEXT USED?YES · 질의 구문과 분량

4. ④ Filter / score

   줄 수 초과, 대치 후 예측 박스의 축소, 미매핑 노드를 채점한다. 별도의 후보 원문 의미 비교는 없다.

   TEXT USED?YES · 길이·문자 종류·매핑

5. ⑤ Reranking / dedupe

   채점 → fingerprint별 하나 유지 → tier·스마트블록 우선순위·총점 정렬. 중복 제거는 결과에 남는 후보를 바꾼다.

   TEXT USED?YES · 파생 점수와 원문 지문

6. ⑥ 최종 match → 대치

   상위 N개를 고르고 variant와 text_map의 경로로 글을 넣는다. 미매핑 노드에 한해 원문 보존 패턴을 검사한다.

   TEXT USED?YES · 실제 입력 문자열

④·⑤는 별도 모델 두 개가 아니다. rankCompCandidates 안에 채점·중복 제거·정렬이 이어져 있어 설명을 위해 나눴다. 태그 필터는 활성화됐을 때 ③의 조회 조건에 함께 들어간다.

코드 근거 · build-comp-signatures.ts:131 · build-search-hashes.ts:125 · rank-candidates.ts:126

검색 키(structureHash)와 시그니처 저장 행(CompSignature)을 구분한다. 아래 “직접 입력”은 최종 해시 문자열의 토큰을 뜻한다. 토큰으로 없더라도 그 앞의 트리 생성·적재 자격에는 관여할 수 있다.

CompSignature는 공통 필드 9개와 sig3 선택 필드 capLinesArr/capCharsArr를 선언한다. “원문 문자열을 저장하지 않는다”는 이 반환값에 대한 설명이며 원본 sheetJson에는 텍스트가 있다.

최종 직렬화만 보면 단순하다. v2는 자식 수와 괄호, sig3는 여기에 헤딩·격자 토큰을 더한다.

v2    : 2(2(0)(0))(0)
sig3  : 1(H2(0)([table]))
        ↓ xxhash64 → signed int64의 10진 문자열
        structure_hash

코드 근거 · signatureTree.ts:543 · summaryTree.ts:59 · matching.ts:329 · summaryTree.ts:198 · useMatchSearch.ts:473

text_map.chars/lines는 원본 문자열 길이·실제 렌더 줄 수가 아니라 슬롯의 수용 용량이다. 그러나 “박스만 같으면 텍스트와 완전히 무관하다”도 정확하지 않다.

코드 근거 · matching.ts:850 · matching.ts:873 · helpers.ts:1581 · textPredict.ts:15 · nodeStyle.ts:54 · signatureTree.ts:518

최초 candidate retrieval은 TEXT USED? YES. UI의 fetchHashRows는 변형 해시를 조회할 때 그 변형에 배정된 텍스트의 수요도 함께 필터링한다. “해시로 전부 가져온 뒤 reranking에서 처음 텍스트를 본다”는 흐름이 아니다.

minChars = floor(demand.chars / multiplier)
minLines = floor(demand.lines / multiplier)

WHERE structure_hash = variant.hash
  AND cap_chars >= minChars
  AND cap_lines >= minLines

sig3 추가: 모든 경로 i에서
  cap_chars_arr[i] >= floor(text[i].length / multiplier)
  cap_lines_arr[i] >= floor((1 + 개행 수[i]) / multiplier)

조회 순서와 후보 수 한도로 어떤 후보를 실제 받아 오는지도 달라진다. v2는 template_idx·id 내림차순, sig3 SQL은 스마트블록 우선을 더한다. 이것을 텍스트 의미 검색 순위로 해석하면 안 된다.

코드 근거 · useMatchSearch.ts:789 · useMatchSearch.ts:888 · build-comp-signs.sql:920 · useMatchSearch.ts:1338

구현된 지원 경로는 별도로 있다. semantic_tags는 시그니처 해시 밖의 DB 컬럼이며 public.design_object_semantic_tags에서 옮겨 담는다. 태그가 활성화되어 호출자에게서 들어오면 다음처럼 후보 조회·정렬에 관여한다.

태그를 쓰는 경로에서는 tier가 점수보다 먼저이고, 목표 후보 수를 채우면 뒤 군을 생략한다. 이는 표현 형식 태그의 일치 정책이다. 질의와 템플릿 문장의 embedding을 비교하는 의미 유사도 점수와는 구분해야 한다.

코드 근거 · semanticTagUi.ts:7 · CompMatch.tsx:1165 · useMatchSearch.ts:426 · useMatchSearch.ts:1450 · build-comp-signs.sql:541

computeScoreBreakdown의 16개 항목 중 질의 경로의 text 값 또는 매핑 여부를 직접 사용하는 항목은 3개다. 하지만 파생 feature까지 포함하면 “텍스트와 관련된 것은 셋뿐”이라고 제한할 수 없다.

variant로 paths 복원
  → 16개 항목 채점·총점 합산
  → fingerprint별 후보 하나 유지 (dedupe 기본 true)
  → tier 오름차순 → 스마트블록 우선(기본 true) → score 내림차순
  → topN

fingerprint는 원문을 질의와 비교하지 않지만 최종 후보 선택에는 사용된다. 같은 지문을 가진 후보 중 우선순위·점수가 높은 하나를 남기므로, “중복 제거 전용이니 선택과 무관하다”는 설명은 틀리다. 점수는 높을수록 좋고 가점도 있어 0이 절대 최고점은 아니다.

코드 근거 · scoring.ts:446 · helpers.ts:1766 · predictTextBbox.ts:81 · predictTextBbox.ts:113 · rank-candidates.ts:191 · scoringWeights.ts:58

최종 match는 고른 컴포넌트와 그 컴포넌트에 맞았던 variant·textMap이다. buildContentReplacement는 variant로 paths를 복원하고 path → 노드 id 대응으로 실제 입력 문자열을 넣는다. 의미가 가까운 문장을 찾아 슬롯에 배정하는 단계는 없다.

대치에서는 실제 문자열을 사용하지만, 원문을 읽는 최초 단계는 아니다. 파싱·키:값 변형, 문자 폭 예측, fingerprint 생성에서도 이미 문자열을 읽었다.

코드 근거 · build-replacement.ts:116 · helpers.ts:708 · signatureTree.ts:361

빌더의 두 갈래를 정확히 그리면 다음과 같다. 이 함수는 이미 만들어진 RLSC를 받는다. 상류에서 RLSC role을 어떤 방식으로 추론했는지는 이번 확인 범위 밖이다.

rlsc + doc → buildSignatureTree / buildSignatureTreeRoleOnly
           → signature forest → structureHash + textMap의 경로

doc → computeVisualBundle → raw VT1 / 선택적 VT2 → 반복 그룹
    → visualTree 저장 + hasIllustration
    → raw VT1 부모맵 + textMap → visualSplitPairs

doc → buildNodeCapacityMap → 별도 VT1 경계 + 대표 fontSize
    → textMap의 용량 → cap 합계 / sig3 벡터

코드 근거 · build-comp-signatures.ts:140 · helpers.ts:275 · utils.ts:733 · utils.ts:817 · helpers.ts:346

다음에 Visual Summary → Visual Tree → RLSC/Search를 연결할 때는 입력의 내용·구문 구조, RLSC의 역할 구조, Visual Tree의 시각적 포함·반복 구조를 각각 놓고, 어디서 변환하거나 서로 참조하는지 확인하면 된다. 별도 comp-frame 경로의 동작으로 이 comp-sign 경로를 대신 설명하지 않는다.

기준은 miricanvas-iui 커밋 988a4c89ab5bcf56e8e555548ca78d819a82d925이다. 인용한 파일은 git diff HEAD -- 해당 파일에 변경이 없는지 확인하고, 링크는 해당 커밋과 실제 줄 번호로 고정했다.

코드 근거 · signatureSet.ts:24 · useMatchSearch.ts:200 · CompMatch.tsx:1250