판단 모델 Jev

텍스트 대신 미리 정한 선택지와 확률을 돌려주는 판단 모델의 개념을 알고, 작은 LLM과 구조화 출력·logprobs로 도구 선별을 실습한다.

컨텍스트 엔지니어링의 관리 기법은 작은 판단의 반복("이 도구가 필요한가?"). 매번 큰 모델을 부르면 느리고 비쌈.
판단 모델(decision model): 텍스트를 생성하지 않고 미리 정한 선택지 중 하나와 그 확률을 돌려주는 모델.

비교 항목	생성 모델(LLM)	판단 모델
출력	자유로운 텍스트·도구 호출	선택지 하나 + 확률, 점수, 예/아니오
쓰임	답변 작성, 계획, 요약	분류, 라우팅, 점수 매기기
속도·비용	출력 토큰만큼 느리고 비쌈	짧은 지연, 낮은 비용
선택지 밖의 답·이유	가능	불가능

빠른 직관(시스템 1)에 빗대 "System One" 모델이라고도 부름. 함수처럼 쓰고 분기는 코드가 담당.

Jev

TypeSafe AI가 2026년 9월 15일 공개한 판단 모델. 질문 유형은 noul(참일 정도 0-1), choice(최대 255개 선택지 중 하나 + 확률), score(2-10단계 척도).
회사 발표: 입력 100만 토큰당 0.042달러(출력 무료), 지연 대부분 약 100ms. 가중치는 비공개, API·SDK로 사용.
참고용 형식(Quick Start을 옮긴 것, API 키가 없어 실행하지 않음):

from typesafe_sdk import Noul, TypeSafeClient

with TypeSafeClient(model="jev-latest") as client:
    response = client.system_one(
        state="현재 작업: 주문 A-0950 반품 접수\n대화 턴: user: 오늘 서울 날씨 어때요?",
        questions={"still_needed": Noul(instructions="이 대화 턴이 현재 작업에 아직 필요하다")},
    )
print(response.nouls["still_needed"].noul)  # 0~1

한계와 주의점

이유를 쓰지 않음. 근거 설명이 필요한 업무에는 여전히 LLM. 질문도 선택지 형태로 다시 설계해야 함.
"환각이 없다"는 홍보 문구 주의: 출력 형식을 벗어나지 않는다는 뜻일 뿐. 있는 선택지 중 틀린 것을 고를 수는 있음.
외부 평가: Rao·Callison-Burch(2026), Decision Models vs. LLMs as Rubric Judges: Cheaper, Faster, and Wrong in the Same Places
- flash급 LLM 심사위원이 비용 16-357배, 시간 5-350배. 판단 모델이 유의하게 뒤진 경우는 27개 비교 중 최대 6개.
- 판단 모델이 확신하며 틀린 문항에서 LLM도 85% 넘게 같은 오답.
대안: AnyJev(Nokia)처럼 공개 LLM의 다음 토큰 확률에서 선택지별 확률을 읽음. 아래 실습도 같은 원리.

실습: 작은 LLM으로 판단 함수 만들기

판단용 모델: openai/gpt-4o-mini. 기본 모델 openai/gpt-4.1-mini는 OpenRouter에서 logprobs를 지원하는 제공자가 없어 404 오류(2026-11-01 확인).
require_parameters: True: logprobs를 지원하는 제공자에게만 요청을 보냄.

!pip install -q openai

from pathlib import Path
from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=Path("openrouter-key.txt").read_text().strip(),  # 키 파일에서 읽기
)
judge_model = "openai/gpt-4o-mini"  # 판단용

구조화 출력의 enum으로 답을 선택지 안으로 제한 → "선택지 밖은 답하지 않음"을 흉내.
선택지 토큰 위치의 top_logprobs에서 확률 계산( $p = e^{logprob}$ ) → "확률"을 흉내. 선택지는 한 토큰짜리 영어 단어(yes/no)로 정함.

import json
import math

def decide(state, question, options):  # 선택지 하나와 선택지별 확률
    schema = {"type": "object", "properties": {"answer": {"type": "string", "enum": options}},
              "required": ["answer"], "additionalProperties": False}
    choice = client.chat.completions.create(
        model=judge_model,
        messages=[{"role": "user", "content": f"[상태]\n{state}\n\n[질문]\n{question}"}],
        response_format={"type": "json_schema", "json_schema": {"name": "d", "strict": True, "schema": schema}},
        logprobs=True, top_logprobs=5, temperature=0,
        extra_body={"provider": {"require_parameters": True}},
    ).choices[0]
    answer = json.loads(choice.message.content)["answer"]
    for token in choice.logprobs.content:  # 후보에 선택지가 처음 나오는 토큰
        probs = {t.token: math.exp(t.logprob) for t in token.top_logprobs if t.token in options}
        if probs:
            return answer, {o: round(probs.get(o, 0), 3) for o in options}

도구 선별

고객센터 에이전트의 도구 6개(실제로는 수십-수백 개). 모두 보여 주면 도구 설명이 컨텍스트를 차지하고 엉뚱한 도구를 고를 위험(혼동·충돌).
도구마다 "이 작업에 필요한가?"를 묻고 확률 순으로 정렬.

tools = {"find_order": "주문 조회", "get_shipping_status": "배송 상태 조회",
         "cancel_order": "출고 전 취소", "request_return": "반품 접수",
         "get_refund_estimate": "환불 금액·수단 계산", "issue_coupon": "할인 쿠폰 발급"}
task = "A-0950 키보드 반품 접수해 주시고, 환불은 결제한 카드로 되는지 알려 주세요."

scores = {}
for name, desc in tools.items():
    _, probs = decide(f"작업: {task}\n도구: {name} - {desc}", "이 도구가 이 작업에 필요한가?", ["yes", "no"])
    scores[name] = probs["yes"]

for name, p in sorted(scores.items(), key=lambda x: -x[1]):
    print(f"{p:.3f}  {name}")

실행 결과

1.000  find_order
1.000  request_return
0.999  cancel_order
0.999  get_refund_estimate
0.000  get_shipping_status
0.000  issue_coupon

위 실행에서 find_order·request_return·get_refund_estimate는 1.000 근처로 작업(반품 접수 + 환불 수단 확인)에 맞음. 배송 조회·쿠폰은 0.
cancel_order도 0.999. 출고 전 취소는 반품 작업에 필요 없으므로 확신하며 틀린 판단. 확률이 높다고 맞는 것은 아님. 도구 설명을 더 구체적으로 쓰면 달라질 수 있고, 실행마다 값도 달라질 수 있음.
도구 n개 = 작은 호출 n번. 판단 모델이 싸고 빨라야 이 구조가 이득.

정리

판단 모델의 자리: 에이전트 루프 안에서 매 턴 반복되는 작은 판단(도구 선별, 가지치기, 라우팅).
확률을 쓰는 법: 임계값으로 자르기, 상위 k개, 애매한 구간은 큰 모델이나 사람에게. TypeSafe 문서의 예: 검토 기준 0.5, 되돌릴 수 없는 행동 전 0.9.
같은 decide로 가지치기도 가능: 지난 턴마다 ["keep", "drop"]을 물음. 턴을 따로 판단하면 앞뒤 맥락을 놓칠 수 있고, 도구 호출 요청·결과 메시지는 짝으로 다룸.

출처: TechTarget(2026), Jev decision model touted as quicker, cheaper LLM alternative; Flavio Copes(2026), Jev; TypeSafe AI, Jev 문서; Nokia Applied Research, AnyJev.

퀴즈

문제 1 / 5맞음: 0힌트: 0틀림: 0채점중: 0남음: 5

판단 모델이 생성 모델과 가장 다른 점은?

○미리 정한 선택지 중 하나와 확률을 돌려준다
○더 긴 텍스트를 더 빠르게 생성한다
○답변과 함께 판단 이유를 자세히 쓴다
○도구를 직접 실행해 결과를 돌려준다

퀴즈를 풀려면 대화형 기능을 불러와야 합니다.

판단 모델이 생성 모델과 가장 다른 점은?

출력의 형태를 비교하세요.

미리 정한 선택지 중 하나와 확률을 돌려준다더 긴 텍스트를 더 빠르게 생성한다답변과 함께 판단 이유를 자세히 쓴다도구를 직접 실행해 결과를 돌려준다

미리 정한 선택지 중 하나와 확률을 돌려준다

Jev의 '환각이 없다'는 홍보 문구를 바르게 해석한 것은?

스키마를 지키는 것과 답이 맞는 것은 다른 문제입니다.

정해진 출력 형식을 벗어나지 않는다는 뜻이며, 틀린 선택지를 고를 수는 있다모든 판단이 사람의 판정과 일치한다는 뜻이다확률이 항상 0 또는 1로 나온다는 뜻이다선택지에 없는 새로운 답도 정확히 만들어 낸다는 뜻이다

정해진 출력 형식을 벗어나지 않는다는 뜻이며, 틀린 선택지를 고를 수는 있다

실습에서 작은 LLM으로 판단 모델을 흉내 낼 때 선택지별 확률은 어디서 얻었나?

모델이 그 토큰을 고를 때의 확률 분포를 읽었습니다.

선택지 값이 놓인 위치의 토큰 logprobs모델이 답변에 적은 확신도 문장같은 질문을 여러 번 보낸 응답의 길이구조화 출력 스키마의 enum 순서

선택지 값이 놓인 위치의 토큰 logprobs

Rao·Callison-Burch(2026)의 비교 결과로 옳은 것은?

논문 제목의 세 형용사를 떠올리세요.

판단 모델은 훨씬 싸고 빠르며, LLM 심사위원과 같은 문항에서 틀리는 경향이 있었다판단 모델이 모든 비교에서 LLM 심사위원보다 정확했다LLM 심사위원이 판단 모델보다 싸고 빨랐다불확실한 판정을 LLM에 넘기면 정확도가 크게 올랐다

판단 모델은 훨씬 싸고 빠르며, LLM 심사위원과 같은 문항에서 틀리는 경향이 있었다

에이전트 루프에서 판단 모델에 맡기기 알맞은 일은?

선택지가 정해진 반복적 판단을 고르세요.

도구마다 이번 작업에 필요한지 판단하기고객에게 보낼 사과 편지 작성하기새 기능의 코드 작성하기판단 근거를 자세히 설명하는 보고서 쓰기

도구마다 이번 작업에 필요한지 판단하기