머신러닝 파이프라인에서 '판단(decision) 모델'과 '추론 모델'은 오랫동안 서로 다른 역할을 맡아 왔다. Jev 계열로 대표되는 판단 모델은 각 선택지에 대해 잘 보정된 확률(calibrated probability)을 내놓는 것이 강점이다. 확률값이 실제 정답 가능성과 잘 맞아떨어지기 때문에, 임계값을 조정하거나 사람에게 넘길 경계를 정하는 운영 관점에서 다루기 편하다. 문제는 정확도 자체가 낮다는 점이다. 그래서 현업의 많은 파이프라인은 판단 모델이 애매해할 때 별도의 추론 모델을 폴백(fallback)으로 붙이는 방식으로 두 단계를 이어 붙여 왔다. PostHog가 공개한 오픈소스 프로젝트 Jeeves는 이 두 역할을 하나의 모델 안에서 합치려는 시도다.
결정하기 전에 먼저 추론하게 만든다
Jeeves의 핵심 아이디어는 이름 그대로다. Jev 스타일의 분류기를 Qwen3.5-9B 기반으로 만들되, 답을 고르기 전에 먼저 추론 사슬을 펼치도록 학습시켰다. 학습에는 LoRA와 별도의 '포인터 헤드(pointer head)'를 쓰고, 지도학습(SFT)과 CISPO라는 강화학습 기법을 결합했다. 그 결과 도메인 밖(out-of-domain) 과제에서 성능이 개선됐고, 공개된 JevBench의 어려운(hard) 구간에서 기존 Jev를 앞섰다고 프로젝트 측은 밝힌다. 판단 모델의 확률 보정 특성을 유지하면서, 추론 모델의 정확도 이점을 흡수하려는 구조인 셈이다.
선택지를 고르는 방식이 특히 눈여겨볼 만하다. 질문과 상태(state), 선택지들을 Qwen 챗 템플릿에 넣고 모델이 추론을 마친 뒤, 토큰 다음에 결정 단계를 덧붙인다. 포인터 헤드는 위치의 은닉 상태를 질의(query)로, 각 선택지의 위치 은닉 상태를 키(key)로 투영한 뒤 스케일드 닷프로덕트로 점수를 매긴다. 최종 확률은 이 점수들을 소프트맥스에 통과시키되 개발셋에서 맞춘 온도(temperature)로 나눠 얻는다. 흥미로운 것은 여기 쓰인 토큰들이 Qwen 토크나이저에서 거의 쓰이지 않는 희귀 토큰이라는 점이다. 어블레이션 실험에서 이를 'State' 같은 평문으로 바꾸면 성능이 나빠졌고, 추론 블록 뒤에 질문을 다시 반복하지 않아도 성능이 떨어졌다고 한다.
수치를 읽을 때 주의할 점
같은 체크포인트를 놓고 볼 때, 추론 없이 자체 테스트셋(2,962개 항목)에서 0.804를 기록한 반면 추론을 켜면 0.840으로 올라갔다. 판단 앞에 추론을 붙이는 것이 실제로 정확도를 끌어올린다는 근거다. 다만 비교 수치는 조심해서 읽어야 한다. JevBench 성적은 공개된 easy·standard·hard 세 구간(231개 항목)만 대상으로 했고, 봉인된 심사(sealed judge) 구간은 빠져 있다. 또한 비교 대상인 Kev-9B의 JevBench 결과는 공개된 적이 없어, 표에 실린 값은 사실상 Qwen3 기반 Kev-8B의 수치다. 즉 완전한 동일 조건 비교라기보다는 공개 항목 범위 안에서의 상대 평가로 이해하는 편이 정확하다.
확산 초안기와 실무 연동
속도 측면에서는 별도의 확산(diffusion) 초안기(drafter)를 둔 점이 특징이다. 이는 Orthrus에서 영감을 받았지만, 어텐션 전용 모델만 지원하는 Orthrus와 달리 Qwen3.5의 Gated DeltaNet 계층까지 지원한다. 마스크 토큰이 해당 계층의 합성곱 이후 키·값에 교차 어텐션하도록 허용하는 방식이다. 여러 질문을 배치로 묶어도 비용이 낮게 유지되는 블록 4가 기본값으로 잡혀 있다. 실제로 H100 한 장(FP8) 위에서 세 개 질문을 병렬로 추론하는 예시가 제시된다.
기존 시스템에 붙이는 부담을 줄인 점도 실무자 입장에서 반갑다. sdk/ 디렉터리는 Jev의 파이썬 SDK(typesafe-sdk)를 대체하도록 만들어졌고, 클라이언트는 기본적으로 127.0.0.1:8009(또는 JEEVES_BASE_URL)에 접속하며 API 키가 필요 없고 최대 120초까지 응답을 기다린다. 추가로 넘기는 options 인자는 선택 사항이라, 이를 보내지 않는 기존 Jev 클라이언트는 그대로 무시하고 동작한다. 서버 전역 기본값은 serve 플래그로 지정한다. 기존 Jev 기반 파이프라인을 크게 뜯어고치지 않고도 교체를 시도해볼 여지가 있다는 뜻이다.
다만 도입을 검토한다면 현실적인 제약도 함께 봐야 한다. 실행에는 Python 3.12와 CUDA GPU가 필요하고, 전체 학습 파이프라인(run.sh)은 GPU 8장을 전제로 한다. 데이터셋은 prep 스크립트로 Hugging Face에서 고정된 리비전으로 내려받아 구성하되, 각 공개 데이터셋은 저마다의 라이선스를 따른다는 점을 확인해야 한다. 또 하나 눈길을 끄는 대목은 학습을 402스텝에서 멈추는 것이 보정과 개발셋 점수 모두에서 가장 좋았다는 관찰이다. 그 이후로는 포화된 강화학습 풀에 헤드가 과도하게 날카로워진다고 한다. 확률 보정을 중시하는 판단 모델에서는 '더 오래 학습할수록 좋다'는 통념이 통하지 않을 수 있음을 보여주는 사례로, 비슷한 결정 모델을 다루는 팀이라면 학습 종료 시점과 보정 지표를 함께 관리할 이유가 된다.