How to Build a Decision Model Like Jev

배경

Oumi는 지난 글에서 Oumi로 파인튜닝한 4B 모델이 BANKING77에서 검색 단계 없이 Jev와 같은 정확도를 냈다고 소개했어요. 그러자 Jev가 어떤 모델이고 직접 만들 수 있는지 묻는 사람이 많았대요. TypeSafe는 Jev의 작동 방식을 공개하지 않아서, 이 글은 Oumi의 추정이라고 밝혀요.

결정 모델은 두 가지만 다른 평범한 LLM

• 학습: 프롬프트의 한 지점에서 정해진 토큰 집합에 점수를 매겨 답하도록 배워요. 텍스트는 쓰지 않아요.
• 서빙: 문서 하나를 한 번 읽고, 그 문서에 대한 모든 질문에 한 번의 순전파로 답해요.

글은 4부로 이어져요. 1부 학습(한 토큰으로 답하기, 학습과 보정), 2부 서빙(한 문서에 많은 질문을 한 번에), 3부 Jev의 기반 모델 추정(답과 토큰 수가 주는 단서), 4부 추정 제작 방식(어휘 교체와 RLCD)이에요.

Jev가 하는 일

Jev는 상태(문서, 티켓, JSON 레코드 등)와 질문 묶음을 받아요. 질문 유형은 세 가지예요.

| 유형 | 내용 | |---|---| | Choice | 최대 255개 보기 중 하나 | | Noul | 예/아니오를 확률로 | | Score | 2–10단계 평점(별 1–5개, 학점 등) |

모든 보기에 확률을 돌려주고, 질문을 늘려도 응답 시간에 영향이 적어서 필요한 질문을 한 요청에 다 넣으라고 권한대요.

왜 한 토큰인가

채팅 모델은 답을 토큰 하나씩 쓰고 그 텍스트를 파싱해요. 확률이 필요하면 숫자로 쓰게 하거나(잘 못해요), 쓰려던 첫 답 토큰의 확률을 읽을 수 있어요. 결정 모델은 후자를 바탕으로 해요.

토큰과 임베딩 기초

예시는 Qwen 3.5로 들어요(3부에서 Jev가 이를 기반으로 했을 가능성을 보여 줘요). 토크나이저가 텍스트를 약 248k개 토큰 ID로 자르고, 각 ID는 임베딩 표의 행(Qwen3.5-35B-A3B에선 2,048개 숫자)을 가리켜요. 끝에서는 출력 헤드가 토큰마다 로짓을 매겨요. 결정 모델은 답 보기를 뜻하는 새 토큰 몇 개를 양쪽 표에 추가하고, 답을 읽는다는 건 그 행들의 출력 점수를 읽는 일이에요.

원문 앞부분(개요와 1부 도입)을 기준으로 옮겼어요. 보정, 서빙, 기반 모델 추정 부분은 다 읽지 않았어요.