Laya 실전 ⑦: 자체 스키마 설계와 캘리브레이션의 실제

스키마는 dict다, 설계를 말로 적어라 (예제 30)

자체 스키마는 질문 id / type / instructions / criteria의 dict일 뿐입니다. 예제 30은 버그 리포트 트리아주를 4축으로 만듭니다: category(choice), severity(score), reproducible(noul), data_loss_risk(noul). 겉보기에만 문제인 UI 보고와 데이터를 깨뜨리는 크래시를 비교하고, score 답의 confidence를 공식(1 − H/log k)대로 손으로 다시 계산해 보고와 대조하는 부분까지 담겨 있습니다. 넓지만 순서가 있는(wide-but-ordered) 분포는 낮게 읽힌다는 정의가 확인됩니다. laya.render_options()를 호출해 보세요 — 모델이 실제로 읽는 옵션 텍스트가 그대로 나옵니다.

criteria는 구조화된 데이터도 된다 (예제 31)

criteria의 값은 문자열 대신 dict/list여도 되고, 그 경우 컴팩트 JSON으로 렌더링되어 모델이 프롬프트에서 진짜 JSON을 읽게 됩니다. 규약은 테스트로 고정돼 있습니다: 문자열은 그대로, 구조화된 값은 compact JSON (Python repr 아님), choice에서 None/""는 "설명 없음"이지만 0과 False는 실값으로 유지, noul의 false/true 누락은 기본 문구로 폴백.

typed-decisions: 질문 id가 계약이다 (예제 32)

laya-typed-decisions는 네 개의 합성 워크플로로 파인튜닝된 체크포인트이고, 각 워크플로의 질문 id 집합이 학습 시점부터 고정입니다:

invoice_processing — {discrepancy_severity, disposition, duplicate, matches_order, urgency}
customer_service — {action, category, churn_risk, needs_human, urgency}
security_incidents — {credential_compromise, disposition, severity, true_positive, urgency}
agent_trace_observability — {action, needs_review, outcome, risk, urgency}

id 시그니처가 정확히 일치하면 Router는 지정도 없이 그 체크포인트를 고릅니다(auto task detection). 예제 32는 실제 invoice_processing 스키마로 40% 가격 편차가 있는 벤더 인보이스를 end-to-end로 처리합니다 — 다섯 개의 타입된 결정, 순전파 한 번.

77개 라벨과 헤드 예산 (예제 33)

호출의 포맷은 [CLS] 질문+옵션 [SEP] [MASK] opt0 ... [SEP] 상태입니다. 옵션 블록은 head_max_len에 맞춰 덩치를 재고, 상태는 max_len에서 남은 것을 가져갑니다 — 다만 head_max_len은 하드 캡이 아닙니다. 여유가 16토큰 아래로 떨어지면 각 옵션은

python

per = max(4, (head_max_len - 16) // N)   # 옵션 하나에 허락되는 토큰 수

영어 기본값 192에 Banking77의 77개 라벨을 넣으면 max(4, (192−16)//77) = 4 — 개당 4토큰짜리 옵션 77개 + 지시가 192를 넘는 헤드를 만들고, 일부 옵션은 스팬을 공유하게 되어 모델이 그 라벨들을 구별할 수 없게 됩니다. 그때 usage["options"]가 그 사실을 신고합니다. 대응은 두 가지뿐: head_max_len/max_len을 올리거나, 라벨 공간을 coarse-to-fine로 쪼개거나.

예제의 경고가 매섭습니다: 답은 변하는데 confidence는 경고하지 않습니다.

확률은 어디서 오고, temperature는 뭘 하나 (예제 34)

Laya는 strictly proper scoring rule(로그 스코어 + 스페리컬 스코어, score에는 RPS까지)로 학습됩니다 — 정직한 확률을 보고하는 것이 기대 이득을 최대화하는 구조라, 헤드에 캘리브레이션된 분포를 밀어넣는 학습 신호가 됩니다. 배포 체크포인트는 거기에 (질문 타입, 옵션 수) 버킷당 temperature를 하나 더 얹습니다: z = logits / T, p = softmax(z).

함정은 로드 시점입니다: 에이전트가 모든 temperature를 [0.5, 5]에 클램프합니다. 영어 체크포인트가 choice:11+에 실값으로 지니는 0.1006은 바닥 아래라서, 실제로 도는 값은 0.5(로그트 2배)입니다 — 원본이 암시하는 9.9배가 아닙니다. 캘리브레이션 루프(홀드아웃에 버킷당 temperature 재적합, ECE 0.466 → 0.081)를 돌리기 전까지 shipped 확률은 정책의 원재료일 뿐, 측정된 정확성이 아닙니다. ④편의 게이트 경고와 이어지는 지점입니다.

다음 편(마지막): 디바이스 선택과 지연, 처리량, 긴 문서, 파이프라인, 에러 처리, 그리고 예제 41의 프로덕션 트리아주 서비스.