KJH-Judge-4B-ko

Korean JEV Benchmark를 보고 판정 모델을 직접 만들어 본 개인 학습 프로젝트입니다. 아래 수치는 모두 직접 잰 결과이며, 실서비스에서 검증한 모델은 아닙니다.

정해진 보기 중 하나를 골라, 보정된 확률과 함께 돌려주는 한국어 판정 모델입니다. 감정·주제 분류, 문장 관계(함의·모순), 혐오 표현 검수, 정책에 따른 행동 선택, 에이전트의 도구 호출 판단(도구 호출 / 되묻기 / 직접 답변) 같은 일에 씁니다. 다른 모델의 답변을 채점하는 LLM-as-a-judge 모델이 아닙니다.

English summary. A personal learning project: a Korean decision model fine-tuned from Qwen3-4B. Given a task description, an item, and 2–26 options, it returns the chosen option with calibrated probabilities from a single forward pass (no text generation, ~tens of ms per decision on a GPU). Good for classification, NLI, moderation, policy actions, and tool-call routing. It does not generate text, extract spans, or do numeric reasoning.

이 모델의 특징

• 보기 고르기만 합니다. 글을 생성하지 않고 프롬프트를 한 번 계산한 뒤, 보기 기호(A, B, …) 토큰의 점수만 읽습니다. 그래서 빠르고(GPU 서버 안 계산 기준 판정 한 번 약 90ms), 답이 항상 보기 중 하나입니다.
• 확률이 보정되어 있습니다. 검증셋으로 맞춘 온도(1.72)로 보정해, Korean JEV Benchmark에서 기대 보정 오차(ECE)가 0.027입니다. “확신 70% 미만이면 사람에게 넘기기” 같은 기준을 걸 수 있습니다. 다만 학습하지 않은 출처의 데이터에서는 평균 확신이 정확도보다 최대 10%p 정도 높게 나왔으니, 기준값은 쓰려는 데이터에서 다시 맞추는 것이 좋습니다.
• 보기 순서에 흔들리지 않습니다. 보기를 정확히 거꾸로 놓고 다시 물어도 97.9%가 같은 답입니다.

빠르게 시작하기

pip install torch "transformers>=5" accelerate

from transformers import pipeline

judge = pipeline(model="coderecode95/KJH-Judge-4B-ko", trust_remote_code=True,
                 device=0, dtype="bfloat16")      # GPU가 없으면 device, dtype 를 빼세요 (매우 느림)

쓰는 방법은 세 가지이고, 결과는 모두 같은 모양입니다.

{'choice': '긍정', 'confidence': 0.97, 'probabilities': {'긍정': 0.97, '부정': 0.03}}
#  고른 보기      그 보기의 확률(보정됨)   보기별 확률

1. 자주 쓰는 판정 — 메서드 하나로

학습 때와 같은 지침·보기 문구가 자동으로 들어가서, 따로 프롬프트를 쓸 필요가 없고 정확도도 가장 잘 나옵니다.

judge.sentiment("배송은 느렸지만 물건은 정말 마음에 들어요")          # → 긍정
judge.nli("보증금은 퇴거 후 30일 이내 반환한다.", "보증금은 퇴거 40일 뒤에 받는다.")  # → contradiction
judge.next_action("강남역에서 서울역까지 택시 불러줘", tools)          # → CALL:call_taxi

메서드	판정	고르는 값
sentiment(문장)	감정	긍정 / 부정
topic(뉴스 제목)	뉴스 주제	사회 / IT과학 / 세계 / 생활문화 / 정치 / 스포츠 / 경제
hate(문장)	혐오·비하 표현	비혐오 / 혐오
offensive(댓글, news_title=None)	댓글 공격성 3단계	없음 / 공격적 / 혐오
nli(전제, 가설)	문장 관계	entailment / contradiction / neutral
similar(문장1, 문장2)	같은 뜻인지	같음 / 다름
yes_no(질문, 지문)	지문 근거 예/아니오	예 / 아니오
same_meaning(단어, 문맥1, 문맥2)	단어 뜻이 같은지	같음 / 다름
reading(지문, 질문, 보기)	독해 객관식	보기 중 하나
next_action(대화, 도구 목록)	에이전트 다음 행동	CALL:<도구> / ASK / RESPOND
policy_action(정책, 고객 요청)	정책에 따른 행동	ANSWER / ASK_CLARIFICATION / ASK_CONFIRMATION / CALL_TOOL / CALL_MULTIPLE_TOOLS / ESCALATE / REFUSE

문장 하나만 받는 메서드(sentiment, topic, hate, nli 등)는 리스트를 넣으면 여러 개를 한 번에 판정합니다.

2. 내 판정 만들기 — JEV 형식

Korean JEV Benchmark·JEV API와 같은 모양입니다. 상황(state) 하나에 이름 붙인 질문 여러 개를 한 번에 묻고, 보기에는 내가 쓸 ID를 붙입니다. 결과는 그 ID로 돌아옵니다.

judge.decide(
    state={"고객 문의": "지난달 요금이 두 번 빠져나갔어요. 오늘 안에 처리해 주세요."},
    questions={
        "부서": {
            "instructions": "고객 문의를 담당 부서로 분류한다.",
            "criteria": {"billing": "결제·환불", "delivery": "배송", "account": "계정·로그인"},
        },
        "긴급": {
            "instructions": "고객이 즉시 처리를 요구하는지 판단한다.",
            "criteria": {"urgent": "즉시 처리 요구", "normal": "일반 문의"},
        },
    },
)
# {'부서': {'choice': 'billing', 'confidence': 0.9…, 'probabilities': {...}},
#  '긴급': {'choice': 'urgent',  'confidence': 0.9…, 'probabilities': {...}}}

• state: 판단할 내용. {"이름": 값}이 프롬프트에 한 줄씩 들어갑니다. 문장 하나면 그냥 문자열로 넣어도 됩니다.
• instructions: 무엇을 어떤 기준으로 고를지. 판단 기준을 한두 문장 덧붙이면(예: “반어를 고려한다”) 정확도가 크게 오릅니다.
• criteria: {ID: 설명}, 2~26개. ID는 결과로 돌려받는 값이고, 모델은 설명을 보고 고릅니다. ID가 필요 없으면 ["결제·환불", "배송"]처럼 리스트로 넣어도 됩니다.

3. 한 줄로

judge("지난달 요금이 두 번 빠져나갔어요", choices=["결제·환불", "배송", "기타"],
      instruction="고객 문의를 담당 부서로 분류한다.")

judge.decide에서 질문이 하나일 때와 같습니다. 리스트를 넣고 batch_size=8처럼 주면 묶어서 계산합니다.

---

trust_remote_code=True는 이 저장소의 judge_pipeline.py와 judge.py(프롬프트 만들기와 보기 점수 계산)를 실행한다는 뜻입니다. 원격 코드를 쓰고 싶지 않으면 judge.py를 내려받아 from judge import Judge; judge = Judge()로 똑같이 쓸 수 있습니다. quickstart.ipynb에 예시를 모아 두었습니다.

사용 예시

이 모델은 “무엇을 할지”를 빠르게 정하는 앞단에 두는 것이 가장 잘 맞습니다. 정해진 보기 중 하나를 고르는 판단은 이 모델이 하고, 글 쓰기나 값 채우기처럼 생성이 필요한 일만 큰 모델이나 사람에게 넘기는 구성입니다. 아래 예시는 모두 위에서 만든 judge로 바로 돌아갑니다. 주석에 적은 결과는 의도한 정답이고, 실제 확률은 직접 실행해 확인하세요.

1. 고객 문의 분류 — 부서와 긴급도를 한 번에

문의 하나를 여러 관점으로 동시에 분류합니다. 질문마다 보기 ID를 정해 두면 결과를 바로 업무 코드에 연결할 수 있습니다.

def route_ticket(text):
    r = judge.decide(
        state={"고객 문의": text},
        questions={
            "부서": {
                "instructions": "고객 문의를 담당 부서로 분류한다. 여러 내용이 섞여 있으면 고객이 해결을 원하는 문제를 우선한다.",
                "criteria": {"billing": "결제·환불", "delivery": "배송", "account": "계정·로그인",
                             "product": "제품 사용·고장", "other": "기타"},
            },
            "긴급": {
                "instructions": "고객이 즉시 처리를 요구하거나 금전 피해가 진행 중인지 판단한다.",
                "criteria": {"urgent": "즉시 처리 필요", "normal": "일반 처리"},
            },
        },
    )
    return r["부서"]["choice"], r["긴급"]["choice"]

route_ticket("지난달 요금이 두 번 빠져나갔어요. 오늘 안에 환불해 주세요.")   # ('billing', 'urgent')

• 지침에 헷갈리는 경우의 기준을 한 문장 넣으면(“여러 내용이 섞여 있으면 …을 우선한다”) 정확도가 오릅니다.
• 보기에 기타를 두면 어디에도 안 맞는 문의를 억지로 끼워 넣지 않습니다.

2. 리뷰 감정 분석 — 대량 처리와 사람 검토 기준

리스트로 넣으면 묶어서 계산합니다. 확신이 낮은 건 따로 모아 사람이 봅니다.

reviews = ["배송 참 빠르네요. 2주 걸렸어요", "가격 대비 괜찮아요", "다시는 안 삽니다", "그냥 그래요"]
results = judge.sentiment(reviews)

auto   = [(t, r["choice"]) for t, r in zip(reviews, results) if r["confidence"] >= 0.7]
review = [t for t, r in zip(reviews, results) if r["confidence"] < 0.7]   # 사람이 확인

• 반어·비꼼(“배송 참 빠르네요. 2주 걸렸어요”)은 높은 확신으로 틀리기도 합니다. 중요한 곳에는 표본을 사람이 다시 보세요.
• 기준값 0.7은 예시입니다. 실제 데이터 수백 건에 정답을 달아 보고 “이 기준 이상이면 몇 %가 맞는지”를 확인해 정하세요.

3. 리뷰를 여러 측면으로 — 배송·품질·가격 각각

한 리뷰에서 측면별로 따로 판단합니다. 같은 state에 질문만 늘리면 됩니다.

ASPECT = {"pos": "긍정적으로 언급", "neg": "부정적으로 언급", "none": "언급하지 않음"}

judge.decide(
    state={"리뷰": "배송은 하루 만에 왔는데 마감이 엉망이네요. 이 가격이면 그냥 그래요."},
    questions={
        "배송": {"instructions": "리뷰가 배송(속도·포장)을 어떻게 언급하는지 고른다.", "criteria": ASPECT},
        "품질": {"instructions": "리뷰가 제품 품질(마감·내구성·성능)을 어떻게 언급하는지 고른다.", "criteria": ASPECT},
        "가격": {"instructions": "리뷰가 가격·가성비를 어떻게 언급하는지 고른다. 애매한 평가는 언급한 것으로 보되 긍정·부정을 문맥으로 판단한다.", "criteria": ASPECT},
    },
)
# {'배송': {'choice': 'pos', …}, '품질': {'choice': 'neg', …}, '가격': {…}}

4. 댓글 검수 — 혐오 여부와 공격성 수준

hate로 차별·비하 여부를 거르고, offensive로 공격성 수준을 나눕니다. 기사 댓글이면 제목을 문맥으로 함께 넣습니다.

comment = "이런 기사 쓰는 기자는 머리가 있는 건지"

judge.hate(comment)                                               # 비혐오 / 혐오
judge.offensive(comment, news_title="정부, 내년 예산안 발표")      # 없음 / 공격적 / 혐오

• 두 메서드는 기준이 다릅니다. hate는 성별·나이·출신 같은 집단에 대한 차별·비하(APEACH 기준), offensive는 개인을 향한 모욕까지 포함한 공격성 3단계(BEEP 기준)입니다.
• 사람에게 불이익을 주는 결정(삭제·제재)에 쓸 때는 확신이 낮은 건 반드시 사람이 검토하게 하세요.

5. 에이전트 라우터 — 도구 호출 / 되묻기 / 직접 답변

에이전트가 매 턴 큰 모델에 “다음에 뭘 할지”를 묻는 대신, 이 모델이 먼저 정합니다. 도구 인자 채우기와 답변 작성만 큰 모델에 맡깁니다.

tools = [
    {"type": "function", "function": {"name": "call_taxi", "description": "택시를 호출한다",
     "parameters": {"type": "object", "properties": {"pickup": {"type": "string"}, "destination": {"type": "string"}},
                    "required": ["pickup", "destination"]}}},
    {"type": "function", "function": {"name": "get_weather", "description": "지역의 현재 날씨를 알려준다",
     "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}}},
]
messages = [{"role": "user", "content": "강남역에서 서울역까지 택시 불러줘"}]

r = judge.next_action(messages, tools)
if r["confidence"] < 0.7:
    action = "큰 모델에게 다음 행동을 맡김"
elif r["choice"].startswith("CALL:"):
    action = f"큰 모델로 {r['choice'][5:]} 의 인자를 채워 호출"     # 이 모델은 인자를 채우지 못합니다
elif r["choice"] == "ASK":
    action = "빠진 필수 정보를 사용자에게 되묻기"
else:  # RESPOND
    action = "도구 없이 바로 답변"

• 도구는 OpenAI 형식 그대로, 특히 required를 꼭 넣으세요. 이름만 주면 필수 인자를 볼 수 없어 ASK와 CALL을 구별하지 못합니다.
• 대화 기록(앞 턴, 도구 결과 {"role": "tool", …})을 함께 넣으면 “이미 처리됐으니 결과 안내(RESPOND)” 같은 판단도 합니다.
• 도구는 최대 24개까지 넣을 수 있습니다 (보기 26개 중 2개가 ASK·RESPOND).

6. 정책에 따른 고객센터 행동 결정

정책 문서와 고객 요청을 주면 실행 / 확인 / 되묻기 / 이관 / 거절 중 무엇을 할지 고릅니다. 예외 조항이 적용되는지까지 따집니다.

policy = ("해외 카드 승인 금액이 100,000원 이상이면 고객의 확인을 받은 후에만 실행한다. "
          "다만 VIP 등급 고객은 확인 없이 바로 실행한다.")

judge.policy_action(policy, "홍콩에서 카드로 149,000원 결제하려는데 승인해줘. 내 등급은 일반이야.")
# → ASK_CONFIRMATION (금액 기준을 넘었고 VIP 예외가 아님)

• 정책에 적혀 있는 것만 근거로 판단하도록 학습했습니다. 실제 업무 규정을 모델이 알아서 보충하지 않으니, 필요한 조건은 정책 문장에 다 쓰세요.
• 보기: ANSWER, ASK_CLARIFICATION, ASK_CONFIRMATION, CALL_TOOL, CALL_MULTIPLE_TOOLS, ESCALATE, REFUSE.

7. 답변이 근거 문서와 맞는지 확인 (RAG 검증)

검색한 문서를 전제로, 생성된 답변의 문장을 가설로 넣습니다. contradiction이면 문서와 어긋난 답이고, neutral이면 문서에 근거가 없는 내용입니다.

doc = "임대인은 계약이 끝나고 임차인이 집을 비운 날부터 30일 이내에 보증금을 돌려준다."
answer_sentences = ["보증금은 집을 비운 뒤 30일 안에 돌려받습니다.",
                    "보증금은 집을 비운 뒤 40일 뒤에 돌려받습니다.",
                    "보증금에는 연 3% 이자가 붙습니다."]

for s, r in zip(answer_sentences, judge.nli([doc] * len(answer_sentences), answer_sentences)):
    print(r["choice"], s)
# entailment     … 30일 안에 …   → 근거 있음
# contradiction  … 40일 뒤에 …   → 문서와 어긋남
# neutral        … 연 3% 이자 …  → 문서에 근거 없음

• 답변은 문장 단위로 나눠 넣으세요. 여러 주장이 섞인 긴 답변은 판단이 흐려집니다.
• 학습 최대 길이가 2,048토큰이라 긴 문서는 관련 단락만 잘라 넣으세요.

8. 약관·문서에 근거한 예/아니오

문서를 주고 질문에 예/아니오로 답하게 합니다. 문서에 없는 상식으로 답하지 않도록 학습했습니다.

terms = "구매 후 7일 이내에는 단순 변심으로도 환불할 수 있다. 단, 포장을 뜯은 소프트웨어는 환불 대상에서 제외한다."

judge.yes_no("포장을 뜯은 게임 CD를 3일 만에 환불할 수 있나요?", terms)   # → 아니오
judge.yes_no("뜯지 않은 키보드를 5일 만에 환불할 수 있나요?", terms)     # → 예

9. 비슷한 질문 찾기 — FAQ 중복 확인

새로 들어온 질문이 기존 FAQ와 같은 뜻인지 확인합니다. 후보는 검색(임베딩 등)으로 먼저 좁히고, 최종 확인에 이 모델을 쓰는 구성이 좋습니다.

faq = ["비밀번호를 잊어버렸어요", "배송지는 어떻게 바꾸나요", "회원 탈퇴는 어디서 하나요"]
q = "로그인 비번이 기억이 안 나요"

hits = judge.similar([q] * len(faq), faq)
best = max(range(len(faq)), key=lambda i: hits[i]["probabilities"]["같음"])
faq[best], hits[best]["choice"]          # ('비밀번호를 잊어버렸어요', '같음')

• similar는 학습하지 않은 과제입니다 (학습하지 않은 KLUE-STS에서 85.9%).

10. 내 분류 체계 그대로 쓰기

어떤 분류든 지침과 보기만 쓰면 됩니다. 학습하지 않은 과제라도 판단 기준을 지침에 적어 주는 것이 정확도를 가장 크게 좌우합니다.

judge.decide(
    state={"보고서 문장": "3분기 매출은 전년 대비 12% 증가했으나 영업이익률은 소폭 하락했다."},
    questions={
        "논조": {
            "instructions": "문장이 회사 실적을 어떤 논조로 전달하는지 고른다. 좋은 점과 나쁜 점이 함께 있으면 혼합으로 본다.",
            "criteria": {"positive": "긍정적", "negative": "부정적", "mixed": "혼합", "neutral": "사실 전달만"},
        },
    },
)

잘 안 되는 쓰임새: 숫자 비교·계산이 핵심인 판단(“어느 쪽이 더 싼가”), 문장에서 값 뽑기, 답변 작성, 다른 모델 답변의 품질 채점(LLM-as-a-judge). 이런 일은 생성 모델에 맡기세요.

원리: transformers만으로 직접 계산하기

import torch, json
from transformers import AutoModelForCausalLM, AutoTokenizer
from huggingface_hub import hf_hub_download

name = "coderecode95/KJH-Judge-4B-ko"
tok = AutoTokenizer.from_pretrained(name)
model = AutoModelForCausalLM.from_pretrained(name, dtype=torch.bfloat16, device_map="auto").eval()
T = json.load(open(hf_hub_download(name, "calibration.json")))["temperature"]   # 1.7179

choices = ["긍정적 감정", "부정적 감정"]
prompt = ("문장의 전반적인 감정 극성을 판단한다.\n\n"
          "text: 배송은 느렸지만 물건은 정말 마음에 들어요\n\n"
          "보기:\n" + "\n".join(f"{chr(65+i)}. {c}" for i, c in enumerate(choices)) +
          "\n\n정답 보기의 기호 하나만 답하세요.")
ids = tok(f"<|im_start|>user\n{prompt}<|im_end|>\n<|im_start|>assistant\n", return_tensors="pt", add_special_tokens=False).input_ids.to(model.device)
with torch.no_grad():
    logits = model(ids).logits[0, -1]
letters = [tok.encode(chr(65 + i), add_special_tokens=False)[0] for i in range(len(choices))]
probs = torch.softmax(logits[letters].float() / T, -1)
print({c: round(p, 4) for c, p in zip(choices, probs.tolist())})

프롬프트 형식

학습과 평가에 쓴 형식입니다. 이 형식을 지켜야 위 성능이 나옵니다.

<|im_start|>user
{과제 설명}                     ← instructions

{항목 이름}: {값}              ← state 의 항목마다 한 줄. 값이 문자열이 아니면 JSON
{항목 이름}: {값}

보기:
A. {보기 1}                     ← criteria 의 설명
B. {보기 2}
…

정답 보기의 기호 하나만 답하세요.<|im_end|>
<|im_start|>assistant

• judge.decide()와 메서드들은 이 형식을 자동으로 만듭니다. 직접 만들 때만 신경 쓰면 됩니다.
• 보기는 2~26개입니다.
• 과제 설명은 짧고 구체적으로 쓰세요. 판단 기준을 한두 문장 덧붙이면(예: “반어를 고려한다”, “정보가 없다는 이유만으로 모순을 고르지 않는다”) 정확도가 크게 오릅니다.
• generate()로 쓸 경우 max_new_tokens=1로 보기 기호 하나만 받으세요 (이 저장소의 generation_config.json은 do_sample: false입니다). 확률이 필요하면 위처럼 logits를 읽으세요.

성능

1. 학습하지 않은 공개 벤치마크

이 모델의 학습에 쓰지 않은 출처의 공개 데이터입니다 (KLUE-STS는 학습에 쓴 KLUE NLI·YNAT와 같은 KLUE 묶음이지만, STS 과제는 학습하지 않았습니다). 0-shot, 위 프롬프트 형식, 보기 기호 점수 방식으로 쟀습니다 (표본은 고정 시드, 괄호는 95% 신뢰구간). 재현 스크립트: eval/bench_heldout.py.

벤치마크	무엇을 재나	문항	정확도 (95% 구간)	무작위	출처 · 라이선스
NSMC	영화 리뷰 감성 (긍정/부정)	1,000	85.7% (83.4~87.7)	50%	e9t/nsmc · ratings_test · CC0 1.0
KorNLI (XNLI)	문장 관계 3분류 (XNLI 한국어 번역)	1,000	74.5% (71.7~77.1)	33%	kakaobrain/kor_nli · xnli/test · CC BY-SA 4.0
KLUE-STS	두 문장이 같은 뜻인지 (예/아니오)	519	85.9% (82.7~88.7)	50%	klue/klue · sts/validation (binary-label) · CC BY-SA 4.0
Korean UnSmile	악플·혐오 표현 여부	1,000	82.1% (79.6~84.4)	50%	smilegate-ai/kor_unsmile · valid (clean 여부) · CC BY-NC-ND 4.0
KMMLU	한국어 전문 지식 4지선다 (45과목)	990	42.6% (39.6~45.7)	25%	HAERAE-HUB/KMMLU · test · CC BY-ND 4.0
HAE-RAE Bench 1.0	한국 문화·어휘 지식 5지선다	983	56.1% (53.0~59.2)	21%	HAERAE-HUB/HAE_RAE_BENCH_1.0 · test · CC BY-NC-ND 4.0

같은 조건 비교 · 같은 문항 · 같은 프롬프트 · 0-shot · 보기 기호 점수. 다른 모델은 생각(thinking)을 끄고 각자의 대화 형식으로 물었습니다.

벤치마크	KJH-Judge-4B-ko (4B)	Gemma 4 26B-A4B-it (0-shot)
NSMC	85.7%	88.7%
KorNLI (XNLI)	74.5%	77.1%
KLUE-STS	85.9%	88.4%
Korean UnSmile	82.1%	81.3%
KMMLU	42.6%	64.0%
HAE-RAE Bench 1.0	56.1%	79.7%

원본 Qwen3-4B의 사전학습에 이 데이터가 들어갔는지는 알 수 없습니다. KMMLU·HAE-RAE는 전문 지식을 묻는 시험이라, 판정 능력보다 원본 모델의 지식이 점수를 좌우합니다.

2. Korean JEV Benchmark (참고: 같은 출처의 시험 문항)

DaehanKim/korean-jev-benchmark 25,418문항 전체입니다. 이 시험 문항 자체로 학습하지는 않았지만, 같은 출처 데이터(KLUE, KoBEST 등)의 학습 분할로 학습했기 때문에 다른 모델의 0-shot 점수와 같은 조건의 비교가 아닙니다.

항목	값
전체 정확도	90.37% (학습 전 Qwen3-4B 29.56%, 무작위 29.86%)
학습 데이터가 없는 과목 (Belebele 한국어 독해)	86.87%
보기를 거꾸로 놓아도 같은 답	97.93%
기대 보정 오차 (ECE)	0.0265

과목	정확도	과목	정확도
KoBEST BoolQ	95.65%	KLUE YNAT (뉴스 주제)	93.93%
KoBEST HellaSwag	94.65%	KLUE NLI	92.39%
KoBEST SentiNeg	93.91%	APEACH (혐오)	88.64%
KoBEST COPA	92.55%	KoBEST WiC	84.96%
SIB-200	94.44%	Korean Hate Speech (3분류)	77.87%
FunctionChat 도구 고르기	94.68%	EnterpriseOps 정책 행동 (7분류)	83.43%
FunctionChat 대화	93.50%	법령 질문 (v2·v3, 6개 묶음)	90.8~99.2%
FunctionChat 호출 판단	84.55%	법령 기간 계산	69.10%

속도

개인 GPU 서버에서 같은 문항 60개(NSMC·KorNLI)로 잰 참고값입니다 (네트워크 왕복 포함, 측정 스크립트: eval/bench_speed.py).

측정	KJH-Judge-4B-ko	Gemma 4 26B-A4B-it
판정 한 번 (중앙값)	250ms (서버 안 계산 87ms)	621ms
동시 4개씩 보냈을 때 처리량	3.9건/초	9.9건/초
생각을 켜고 답을 생성할 때		6.3초

• 동시 처리량은 비교 모델이 앞섰습니다. 비교 모델은 요청을 묶어 처리하는 서빙 엔진에서, 이 모델은 하나씩 처리하는 단순한 서버에서 돌았기 때문입니다. 대량 처리에는 리스트로 넣고 batch_size를 주어 묶어 계산하세요.
• CPU(노트북, fp32)에서는 판정 한 번에 6초에서 수 분이 걸려 실사용이 어렵습니다.

잘하는 것과 못하는 것

잘하는 것: 보기가 정해진 분류, 문장 관계 판단, 지문에 근거한 예/아니오, 정책·규칙에 따른 행동 선택, 에이전트의 다음 행동(도구 호출 / 되묻기 / 직접 답변) 결정. 처음 보는 지시문이라도 이런 형식이면 잘 따릅니다.

못하는 것

• 글 생성, 문장에서 값 뽑기: 보기를 고르는 것만 합니다. 도구 인자 값을 채우거나 답변을 쓰는 일은 생성 모델에 맡기세요.
• 숫자 비교·계산이 핵심인 판단: 거리·속도·점수 같은 수치를 비교해 고르는 일은 약합니다.
• 반어·비꼼: “배송 참 빠르네요. 2주 걸렸어요”를 긍정으로 높은 확신과 함께 고르는 경우가 있습니다.
• 지시문 문구에 민감: “실제 존재하는 인물인가요?”를 “실제 존재하나요?”처럼 읽는 경우가 있습니다. 기준을 명확히 쓰세요.

권장 구성: 큰 LLM 앞단에서 이 모델이 “무엇을 할지”를 빠르고 싸게 정하고, 확신이 낮은 건 사람이나 큰 모델에 넘기세요.

학습

학습 데이터 구성, 보기 순서 역순 학습, 오염 제거, 합성 데이터 만드는 법, 확률 보정, 체크포인트별 정확도까지 자세한 과정은 **TRAINING.md**에 정리했습니다.

항목	값
원본 모델	Qwen/Qwen3-4B
방법	SFT, LoRA (r 16, α 32, dropout 0.05, q·k·v·o·gate·up·down) → 원본에 병합
학습량	69,144문항 × 보기 순서 2가지(섞은 순서 + 역순), 출처 비율대로 섞어 4,430 step · 배치 32, 최대 길이 2,048
최적화	학습률 2e-4, cosine, warmup 3%
장비	GPU 1장, 약 3.5시간
정답 형식	보기 기호 한 글자 + `<
보정	검증셋 3,089문항으로 단일 온도(1.7179)를 맞춤. ECE 0.066 → 0.013

학습 데이터 (모두 위 프롬프트 형식으로 바꿔 사용, 평가 문항과 겹치는 문장은 제외)

데이터	라이선스
KLUE NLI · YNAT (학습 분할)	CC BY-SA 4.0
KoBEST BoolQ · COPA · HellaSwag · SentiNeg · WiC (학습 분할)	CC BY-SA 4.0
kocohub/korean-hate-speech (학습 분할)	CC BY-SA 4.0
APEACH (학습 분할)	CC BY-SA 4.0
SIB-200 (학습 분할)	CC BY-SA 4.0
정책 행동 · 법령 질문 · 도구 호출 판단	자체 합성 (규칙으로 생성, 정답은 코드로 계산. 정책·법령·도구는 모두 지어낸 것이며 LLM 생성물을 쓰지 않음)

라이선스와 주의

• 공개 학습 데이터는 모두 CC BY-SA 4.0입니다.
• judge.py의 과제별 지침·보기 문구(TASKS, CRITERIA)와 평가 스크립트의 지침 일부는 Korean JEV Benchmark(DaehanKim)의 과제 문구를 그대로 쓴 것으로, CC BY 4.0을 따릅니다.
• space/ 폴더(쇼릴 페이지)는 KoBEST·KLUE 문장을 포함하고 있어 CC BY-SA 4.0입니다.
• 혐오 표현 판정, 정책 판단 등 사람에게 영향을 주는 결정에 쓸 때는 확신이 낮은 결과를 사람이 검토하도록 하세요.
• 법률·금융 판단의 근거로 쓰지 마세요. 주어진 글 안에서 내용을 찾고 대조하는 도구입니다.