Jeeves: 추론을 더한 Jev 계열 의사결정 모델

AI 요약

Jeeves는 분류 결과와 함께 선택지별 확률을 돌려주는 Jev 계열 모델에 추론 단계를 넣은 오픈소스 프로젝트입니다. 개발자는 Qwen3.5-9B에 LoRA와 포인터 헤드를 적용하고, SFT와 CISPO로 학습했습니다. 예·아니요 질문, 객관식, 점수형 질문을 Jev 호환 API 한 번으로 처리합니다.

성능과 지연 시간

추론을 켠 테스트에서 Jeeves는 학습에 쓰지 않은 데이터를 포함한 테스트 전체에서 0.889를 기록했습니다. Jev는 0.857, Kev-9B는 0.822입니다. 공개 JevBench 전체 점수는 Jeeves 0.935, Jev 0.866이며, 어려운 항목 111개만 보면 각각 0.865와 0.730입니다. 공개 항목의 보정 오차(ECE)는 Jeeves 0.037, Jev 0.049입니다. 다만 비교에 쓴 Kev와 Jev 수치는 원문이 공개한 값이며, JevBench 밖에서는 같은 문항으로 비교하지 않았다고 밝힙니다.

모든 영역에서 앞서는 것은 아닙니다. 지식 평가인 MMLU에서 Jeeves는 0.793으로 Jev의 0.900보다 낮고, MMLU-Pro에서도 0.739로 Jev의 0.840에 못 미칩니다. 전이 평가 전체 점수 역시 Jeeves 0.746, Jev 0.800입니다. 추론을 끄면 테스트 정확도는 0.804로, 켰을 때의 0.840보다 낮습니다.

H100 한 대에서 질문 하나를 처리할 때 추론을 끄면 약 0.3초가 걸립니다. 추론을 켜면 중앙값은 3.3초, p90은 17.1초입니다. 325개 개발 질문에서 추론 길이를 768토큰으로 제한하고, 확신도가 0.9 이상이면 추론을 생략하도록 설정하면 정확도는 0.806, 중앙값 지연 시간은 2.0초로 줄어듭니다. 평균 추론 토큰은 1,138개에서 344개로 감소합니다.

모델과 학습 방식

모델은 질문과 선택지를 Qwen 채팅 템플릿에 넣고, 먼저 추론 토큰을 생성한 다음 선택지를 다시 제시해 답을 고릅니다. 포인터 헤드는 결정 위치의 은닉 상태와 각 선택지 끝 위치의 은닉 상태를 비교해 점수를 냅니다. 점수를 softmax로 확률화하며, 온도 값은 개발 데이터에 맞춰 보정합니다. 원문은 일반 텍스트 표식을 쓰거나 추론 뒤에 질문을 반복하지 않으면 성능이 떨어졌다고 설명합니다.

SFT 단계는 8개 GPU에서 2에폭, 596스텝 진행했습니다. 공개 데이터셋 12개와 합성 정책 데이터에서 만든 질문 19,126개를 사용했고, 절반에는 기반 모델이 생성한 추론 체인을 넣었습니다. 이어 9,992개 질문으로 CISPO 학습을 시작했지만, 개발 점수와 보정 성능이 가장 좋았던 402스텝에서 멈췄습니다. 원문은 그 뒤 학습을 계속하면 포인터 헤드가 포화된 강화학습 데이터에서 지나치게 확신하는 문제가 생겼다고 설명합니다.

추론 생성 속도를 높이기 위해 동결 모델용 diffusion drafter도 제공합니다. 블록 4 방식은 질문 하나에서 초당 176개 체인 토큰을 생성해 일반 탐욕적 디코딩의 109개보다 1.6배 빠릅니다. 블록 8은 193개로 더 빠르지만, 여러 질문을 묶어 처리할 때 비용을 고려해 블록 4를 기본값으로 선택했습니다. 실행에는 Python 3.12와 CUDA GPU가 필요하며, FP8 커널은 Hopper GPU를 사용합니다.

Hacker News 반응

• @alienbaby — ‘noul’이라는 말이 예·아니요 답변에 어디서 온 건지 궁금합니다. 조금 더 찾아보니 Noul은 정확히 두 결과, 즉 예와 아니요가 나오는 베르누이 시행을 뜻하지만, 둘 중 하나를 고르는 대신 진술이 참일 확률을 0.0에서 1.0 사이로 돌려준다고 합니다. 저는 싫습니다.
• @hjun1052 — 모델이 자기회귀 방식으로 추론한 뒤 결정하면 Jev 계열 모델의 장점인 단일 순전파와 저렴하고 빠른 확률 출력을 상당 부분 포기하는 것 아닌가요? 타입이 정해진 출력과 확률 인터페이스를 유지하면서 어려운 사례의 정확도를 높이는 게 주된 목적일까요?
• @esafak — Jev 계열 모델은 보정된 의사결정 확률을 주지만 정확도가 낮다고 했습니다. 그런데 두 결과를 함께 보여주지 않은 이유는 뭔가요?
• @sharih — p90이 17초라면 이 프로젝트의 목적이 뭔가요? 그럴 바에는 LLM을 쓰는 편이 낫겠습니다. Jev의 장점은 말도 안 되게 저렴하고 빠르다는 점입니다.
  • @zihotki — Jev를 아주 저렴하다고 단정하기는 조심스럽습니다. 제 스팸 탐지 사례에서는 Luna가 프롬프트 캐싱 덕분에 비용이 20% 낮았습니다. 속도는 Jev보다 느렸습니다.
• @TN1ck — 독일 축구 트윗에서 아이러니를 탐지하는 제 벤치마크를 M5 Pro, 메모리 48GB에서 돌렸습니다. 트윗 100개를 판단하는 데 30분 넘게 걸렸고, Jev보다 한참 낮았지만 제가 시험한 다른 오픈 의사결정 모델보다는 나았습니다. Jeeves가 68개를 맞혔고 Jev는 79개를 맞혔습니다.
  • @TN1ck — 업데이트입니다. Jeeves는 394개 데이터의 콘텐츠 조정을 약 2시간 만에 끝냈고 성능도 꽤 좋았습니다. Jev만큼은 아니지만 아주 가까웠습니다. 이런 모델은 콘텐츠 조정의 엄격함을 조절할 수 있다는 점도 좋습니다.
• @teravor — 이 작업을 위해 사후 학습을 할 필요는 없습니다. LLM에 먼저 추론하게 하고, 추론 뒤에 특정 JSON을 출력하도록 강제하면 됩니다. 출력 예시를 포함해 프롬프트를 잘 구성하면 됩니다.
  • @betenoire — 분류기는 생성 텍스트의 한 종류이므로 이런 답변은 요점을 놓친다고 생각합니다. Jev는 충분히 저렴하고 빨라서, LLM을 쓰면 지나치게 느리고 불필요하게 비싼 방식으로 앱 곳곳에 적용할 수 있습니다. 새로운 문제를 푸는 게 아니라, 새로운 접근으로 새로운 사용 사례를 여는 점이 목적입니다.
• @itzikkatz — 엔지니어링은 멋지지만 p90 지연 시간 17초는 Jev 계열 모델이 빠르고 저렴해야 한다는 목적을 무색하게 합니다. MMLU에서 10점 가까이 잃은 점도 좋지 않습니다.
• @quantized_state — diffusion drafter를 적용한 방식이 좋습니다.

원문: GitHub / 번역·요약: Trawling