Laya 실전 ②: 세 가지 결정 프리미티브

choice — 라벨 지도가 곧 프롬프트다 (예제 04–05)

choice 질문은 닫힌 라벨 집합을 주고, 승자와 전체 분포를 한 번의 순전파로 받습니다. criteria는 라벨 → 설명 map이고, 키가 곧 합법적인 답이 되며 값은 인코더가 상태와 함께 읽는 텍스트입니다.

python

{"department": {
    "type": "choice",
    "instructions": "Which department should handle this request?",
    "criteria": {"billing": "invoices, payments, refunds",
                 "technical": "bugs, outages, system errors",
                 "sales": "pricing, new contracts",
                 "other": "everything else"}}}

예제 05는 같은 상태("체크아웃이 500을 뿜는다")에 대해 설명을 세 가지로 바꿔 봅니다. 모호한 설명("money", "tech")에서는 표면 단어 'payment'에 끌려 billing이 이깁니다. 상태를 실제로 포괄하는 구체적 설명("outages", "system errors")으로 바꾸면 답이 technical로 뒤집히고, 두 라벨의 설명을 거의 같은 문장으로 시작하게 쓰면 모델이 갈림길에 확률의 3분의 1을 얹어둔 채 우왕좌왕합니다.

결론: 지도가 곧 프롬프트 엔지니어링입니다. 어떤 라벨이 계속 진다면 질문을 다시 쓰지 말고, 그 라벨의 설명에 사정을 적어주세요.

score — 기대 레벨과 루브릭의 정직 (예제 06–07)

score는 순서 있는 criteria 리스트를 받고, 기대 레벨 score = Σ(level × p)를 돌려줍니다. 0-기준이라 레벨 사이 값(예: 1.4)이 정상이고, legend가 인덱스를 문구로 되돌려주므로 숫자가 루브릭에서 이탈하지 않습니다.

예제 07은 같은 긴급도 판정을 3·5·7 레벨로 묻습니다. 중요한 두 가지: 기대값은 각 루브릭 자기 스케일 위의 값이라 비교하려면 (레벨 수 − 1)로 나눠야 하고, 레벨을 늘려도 모델이 아닌 해상도는 생기지 않습니다. 7-레벨 루브릭은 "급할 것 없다"는 요청에 low와 normal에 애매한 확률을 깔아두며 엔트로피 confidence를 깎아먹습니다.

질문에 답하는 가장 굵은 루브릭을 고르세요. 문턱은 애플리케이션 코드에서 언제든 만들 수 있지만, 모델에 해상도를 되돌려줄 방법은 없습니다.

noul — 임계값은 당신의 것 (예제 08–09)

noul은 "이 명제가 참인가"에 대한 P(true)를 그대로 돌려줍니다. 모델은 절대 라벨로 반올림하지 않습니다. 0.9에서 동작하는 지원 큐와 0.5에서 걸러내는 사전 필터가 같은 숫자의 정당한 쓰법입니다. 주의할 점: confidence = max(p, 1−p)는 대칭이라 어느 쪽이 이겼는지 말해주지 않습니다. 방향은 noul 값에만 있습니다.

criteria로 false/true 양쪽의 정의를 명시할 수 있고, 예제 09는 말투가 경계를 어떻게 움직이는지 측정합니다. true 쪽을 "불만의 기미만 있어도"로 빗장을 낮추고 false 쪽을 까다롭게 쓰면, 명확히 정상인 메시지의 P(true)가 0.032 → 0.077로 두 배 이상 올라갑니다. 양쪽 대칭으로 정의하는 것 자체도 기본 문구보다 false 케이스를 살짝 끌어올립니다. 문구는 포맷이 아니라 정책 결정입니다.

모두 합쳐도 순전파 한 번 (예제 10)

세 프리미티브는 같은 인코더 위의 다른 헤드입니다. choice·score·noul을 한 predict()에 섞어도 추가 순전파는 없고, output_tokens는 여전히 0입니다. 한 메시지에 대해 궁금한 것 전부를 한 호출에 담으세요 — 이 원칙의 비용 측정은 ④편에서 이어집니다.

다음 편은 상태 설계입니다: 같은 사실의 세 가지 글쓰기가 답을 어떻게 바꾸고, 이메일 정리가 판단을 어떻게 뒤집는지 (예제 11–15).