Chapter 07 · Jev

Jev: 글 대신 결정을 내는 모델

지금까지는 ‘LLM에게 무엇을 읽힐까’를 다뤘다. 그런데 프로그램 안에서 AI를 쓰다 보면 정작 필요한 건 긴 문장이 아니라 “결제팀으로 보낼까, 기술팀으로 보낼까?” 같은 결정 하나인 경우가 많다. Jev는 이런 결정을 위해 만든 모델이다.

Jev = 서술형 답안 대신 OMR 카드. 상황(state)과 선택지를 주면, 글을 쓰지 않고 선택지마다 확률을 돌려준다. 프로그램은 그 확률을 기준(임계값)과 비교해 자동 처리할지, 사람에게 넘길지 정한다. 빠르고 형식이 깨지지 않지만, 정해 준 선택지 밖의 답은 못 한다.

Jev는 무엇인가

Jev는 샌프란시스코의 스타트업 TypeSafe AI가 2026년 9월 제한 공개(early access)한 모델이다. 회사는 이를 빠르고 직관적인 판단을 뜻하는 ‘System 1’에서 이름을 딴 System One 모델의 첫 제품이라 부른다. 공개된 사실을 정리하면 다음과 같다.

종류판별(discriminative) 모델 — 분류·점수 매기기를 하며, 자연어 글을 생성하지 않는다
입력상황 state(문자열, JSON, 문자열 목록) + 하나 이상의 질문(questions)
질문 유형noul(예/아니오), choice(순서 없는 선택지 중 하나), score(순서 있는 등급)
출력질문마다 선택지별 확률 분포. 사람보다 프로그램이 읽도록 만든 출력
속도·비용 (회사 발표)응답 70–500 ms, 자체 시험에서 최상위 LLM보다 40–200배 빠르고 40–400배 싸다고 주장
공개되지 않은 것모델 구조, 가중치, 기술 논문. 트랜스포머 기반이며 합성 데이터로만 학습했다고만 밝힘
숫자는 회사 발표다

속도·비용 수치는 TypeSafe가 직접 만든 업무 흐름으로 잰 값이고, 회사도 실제 업무와 다를 수 있다고 밝혔다. 구조가 공개되지 않아 외부에서 검증하기도 어렵다. 이 장은 Jev라는 제품보다 ‘글 대신 확률로 결정을 받는’ 방식을 이해하는 데 초점을 둔다.

생성 vs 판별: 답안지의 모양이 다르다

서술형 시험 vs OMR 카드

LLM에게 “이 문의는 어느 팀 담당이야?”라고 물으면 “결제 관련 문의로 보입니다. 다만 앱 오류일 수도 있으니…” 같은 서술형 답이 온다. 사람에게는 친절하지만, 프로그램은 이 글에서 팀 이름을 다시 뽑아야 하고, 가끔 형식이 어긋난다. Jev는 처음부터 OMR 카드에 표시하듯 “결제 0.96, 기술 0.03, 영업 0.01”을 돌려준다. 프로그램은 숫자만 비교하면 된다.

COMPARE

같은 문의, 두 가지 출력

LLM 쪽 문장과 Jev 쪽 확률은 모두 설명을 위해 만든 예시다. 실제 LLM도 “JSON으로만 답하라”고 지시하면 형식을 맞출 수 있지만, 확률(얼마나 확신하는지)을 믿을 만한 숫자로 주는 것은 별도의 문제다.

Jev가 결정을 내리는 흐름

문의를 바꿔 가며 마지막 단계에서 길이 어떻게 갈라지는지 보자. 기준(임계값)은 0.8이다.

세 가지 질문 유형

같은 상황(고객 후기 한 건)에 세 종류의 질문을 던질 수 있다. 질문 하나는 결정 하나만 묻는 것이 원칙이다. 한 요청 안의 여러 질문은 동시에(병렬로) 답하므로 서로의 답을 참고할 수 없다.

SIMULATOR

noul · choice · score

state: 배송은 빨랐는데 포장이 찢어져 왔어요. 상담원분은 친절하게 교환을 안내해 주셨습니다.
질문 (개념 예시)
출력 (합성 예시)
요청 형식은 이해를 돕기 위한 개념 예시다. 실제 API의 필드 이름과 제한(예: 입력 최대 64k 토큰)은 TypeSafe 공식 문서를 확인하자. score는 등급마다 확률을 주므로 가중 평균(예: 3.0점)처럼 등급 사이 값으로도 쓸 수 있다.

확률을 결정으로: 임계값 실험

확률을 받았으면 프로그램이 규칙을 정해야 한다. 가장 흔한 규칙: 가장 큰 확률이 기준(임계값) 이상이면 자동 처리, 아니면 사람에게. 기준을 어디에 둘지가 핵심 결정이다. 아래는 문의 20건(합성 데이터)이다.

SIMULATOR

자동 배정 기준을 움직여 보자

자동 처리
자동 처리 중 오배정
사람 검토
초록 테두리 = 자동 처리했고 맞음, 빨강 = 자동 처리했는데 틀림, 점선 = 사람에게 넘김. 기준을 낮추면 사람 일은 줄지만 틀린 자동 배정이 늘고, 높이면 그 반대다. ‘틀렸을 때의 피해’(환불 오처리 vs 문의 전달 지연)를 따져 기준을 정한다.

보정(calibration): 확률을 믿을 수 있나

임계값 규칙이 통하려면 모델이 말하는 확률이 정직해야 한다. “90% 확신”이라고 한 답들을 모아 보면 실제로 열에 아홉은 맞아야 한다. 이것을 보정이 잘 됐다고 한다. TypeSafe는 보정된 결정을 위한 강화학습(RLCD)으로 Jev를 학습했다고 밝혔지만, 자세한 내용은 공개하지 않았다.

SIMULATOR

말한 확신 vs 실제 정답률

점 = 위 20건을 확신 구간별로 묶었을 때의 실제 정답률(점 크기 = 건수), 점선 대각선 = 완벽한 보정. 점이 대각선보다 아래면 과신, 위면 소심이다. 슬라이더는 같은 모델의 출력에 소프트맥스 온도를 곱해 과신(왼쪽: 확률이 실제보다 높음)이나 소심(오른쪽: 확률이 실제보다 낮음)한 모델을 흉내 낸다. 과신하는 모델에 임계값 0.8을 쓰면, 생각보다 훨씬 많은 오배정이 자동으로 처리된다.

일반 LLM으로 흉내 내기

보통의 LLM으로도 비슷한 일을 할 수 있다. 선택지에 [1], [2], [3] 번호를 붙여 보여주고, 답 칸을 “최선의 답: [”까지 미리 채워 둔 다음, 모델이 다음 토큰으로 ‘1’, ‘2’, ‘3’을 고를 확률을 읽는 것이다. 글을 생성하지 않고 확률만 읽으므로 Jev 방식과 닮았다. 이렇게 일반 LLM에서 보정된 결정 확률을 뽑는 방법을 연구한 논문(“LLM-as-Jev”)도 나왔다.

SIMULATOR

번호 토큰의 점수 → 소프트맥스 → 확률

문의: 업데이트 후 결제 버튼이 안 눌려요 이 문의를 처리할 팀은? [1] 결제 [2] 기술 [3] 영업 최선의 답: [ ← 여기서 다음 토큰 확률을 읽는다
소프트맥스는 점수 목록을 합이 1인 확률로 바꾼다. 점수 차이가 1 벌어질 때마다 확률 비는 약 2.7배(e배)가 된다. 온도를 높이면 확률이 고르게 퍼지고, 낮추면 1등에 몰린다. 이 확률이 ‘정직’하도록 맞추는 것이 앞 절의 보정이다.

RAG·CAG·KAG와 함께 쓰기

Jev는 자료를 찾아 주지 않는다. 판단할 재료(state)는 부르는 쪽이 준비해야 한다. 그래서 앞의 세 방식과 경쟁하기보다 함께 쓰인다.

재료는 RAG로, 판단은 Jev로

환불 규정을 RAG로 찾아 문의와 함께 state에 넣고 “환불 대상인가?”(noul)를 묻는다.

Jev로 길 안내

먼저 Jev가 질문 종류를 고르고(choice: 규정 질문 / 관계 질문 / 잡담), 규정 질문은 CAG, 관계 질문은 KAG로 보낸다.

Jev로 답 검사

LLM이 쓴 답과 근거를 state로 주고 “답이 근거에 맞는가?”(noul)를 물어, 확신이 낮으면 사람에게 보낸다.

핵심 정리

  1. Jev는 TypeSafe AI의 판별(결정) 모델이다. 글을 생성하지 않고, 정해 준 선택지마다 확률을 돌려준다.
  2. 질문 유형: noul(예/아니오), choice(하나 고르기), score(순서 있는 등급). 질문 하나에 결정 하나.
  3. 프로그램은 확률을 임계값과 비교해 자동 처리/사람 검토를 나눈다. 기준을 올리면 실수 ↓, 사람 일 ↑.
  4. 임계값이 의미 있으려면 확률이 보정되어 있어야 한다(90%라 하면 90% 맞음).
  5. Jev는 자료를 찾지 않으므로 RAG·CAG·KAG가 모은 재료 위에서 ‘결정’ 단계를 맡는다.

확인 퀴즈