Jev의 내부 구조를 추측하여 직접 구현해 보았습니다. 일반 노트북 PC로 구동했습니다.

요약 (TL;DR)

• 발단: 글을 생성하지 않고 '형식화된 값 + 보정된 확률'만 반환하는 Jev(TypeSafe AI)는,
  LLM의 본체 + 전용 판단 헤드 + 상태 캐시로 구현할 수 있지 않을까?

추론 과정이 없다면 작은 모델로도 충분하지 않을까? 라는 두 가지 가설 중, 첫 번째 가설은 맞았습니다. 이 구조로 Jev처럼 형식과 확률만 반환하는 판단기를 만들 수 있었습니다. 학습에 사용되지 않은 12가지 태스크에서 정답률 72.7%를 달성했고,

보정 오차(ECE) 0.055, 신뢰도 상위 30%로 한정했을 때는 정답률이 91%까지 올라갔습니다. 동일한 모델을 내장 GPU에서 구동했을 때도 정답률 71.9%를 기록했으며, 문제당 약 0.94초(모델 3.4GB)가 소요되었습니다. - 두 번째 가설은 틀렸습니다. 이번에 시도해 본 범위에서는 정확도가 모델 크기에 의해 거의 결정됩니다 (0.6B → 1.7B에서 최대 개선). 데이터를 늘리거나 손실 함수를 조정해도 성능 향상이 나타나지 않았습니다.

• 진행 과정: 공개된 정보를 바탕으로 추측, 가설 설정 및 방향 판단은 필자가 담당했고, 구현과 실험은 AI 에이전트(Claude Code)가 수행했습니다.

제가 던져준 후에는 거의 방치 상태였고, 코드 수정이나 실험 실행에 전혀 관여하지 않았습니다. 약 1일 동안 진행되었습니다.

계기

Jev는 TypeSafe AI가 2026/09에 공개한 'System One 모델'입니다. 상태(이메일, 로그 등)와 질문을 입력하면,
형식화된 값과 확률만 반환하고 글은 생성하지 않습니다. 공표상으로는 70500ms (동급의 프론티어 LLM 대비 40200배 빠른 속도)이며,
학습 방식은 '정직한 확률'에 보상을 주는 RLCD입니다. 내부 구조는 비공개입니다.

처음 인상은

우선 설정한 방침은, 먼저 Jev가 수행했을 법한 방식만으로 한계까지 재현하고, 정체기에 도달하면 기사로 정리하며, 그 이후는 자체적인 고안으로 정확도를 높이는 것입니다.

Jev의 재현 수준과 자체적인 고안 효과를 섞지 않기 위해서입니다. 특정 업무 태스크에 국한하지 않고, 처음 접하는 태스크에 대한 범용성을 평가 기준으로 삼았습니다.

도중에 중요했던 판단은, 후술할 ③(전용 헤드로 전환) 외에도 다음 두 가지였습니다.

• Jev가 3가지 종류의 질문(Choice / Score / Noul)을 다룬다는 것을 알게 된 시점에, 형식을 Jev에 맞췄습니다. 단계 평가 순서 처리는 기사 이전에 검증했습니다(→ ⑤)
• 성능 향상이 멈춘 시점에서, 방침대로 기사로 정리했습니다(정체기 기준: 다음 수단이 +2pt 미만).

결과

학습에 사용하지 않은 12가지 종류의 태스크(경비 규정 위반, 계약 리스크, 요약 충실성, 경어 오용, 진료 권유 등. 총 509문항). torch 버전으로 평가했습니다(내장 GPU 버전은 ④):

최종 모델에서는 신뢰도와 실제 정답률이 어느 구간에서든 거의 일치합니다.

| 신뢰도 | 0.37 | 0.46 | 0.55 | 0.65 | 0.75 | 0.85 | 0.96 |
|---|---|---|---|---|---|---|
| 실제 정답률 | 0.34 | 0.42 | 0.55 | 0.64 | 0.78 | 0.79 | 0.92 |

태스크 종류별로 보면, 강점과 약점이 명확하게 나뉩니다.

전용 스코어 헤드(専用スコアヘッド)로 구성하자, 백지 상태에서 시작했음에도 학습량의 1/4만으로 기호 방식에 근접했으며, 학습과 동일한 종류의 태스크에서는 최고 성능을 기록했습니다.

직접 만들어 본다면, 첫인상으로 '전용 판단 헤드(専用の判断ヘッド)'가 정답이었습니다.

④ CPU는 빨라지지 않는다. 내장 GPU로 4배 향상

'llama.cpp로 양자화하면 CPU에서도 빨라질 것'이라고 예상했지만, 제가 가진 CPU로는 어떤 구현 방식도 큰 차이가 없었습니다.

(스레드를 늘리면 오히려 느려지는 경우도 있었습니다). 효과를 본 것은 내장 GPU였습니다.

최종 모델을 내장 GPU(f16)로 구동했을 때, 문제당 시간은 5.2초 → 0.94초로 단축되었고, 정답률은 72.7% → 71.9%로 거의 유지할 수 있었습니다.

상태를 한 번만 읽어 각 질문에서 공유하는 구조는 llama.cpp의 시퀀스 ID(하나의 토큰을 여러 시리즈에 속하게 하는 메커니즘)로 그대로 재현할 수 있습니다.

이번 내장 GPU에서는, Q8_0으로 양자화해도 빨라지지 않았고 (문제당 0.91초), 정답률만 약간 떨어졌습니다 (70.9%). 이는 GPU가 f16을 그대로 계산할 수 있기 때문이라고 생각합니다.

반면, Windows 경로에 일본어(사용자 이름)가 있는 경우 llama.cpp가 DLL과 모델을 읽지 못하거나, torch와 같은 프로세스에 넣으면 OpenMP가 충돌하는 등,

이러한 환경적인 난관도 있었습니다 (자세한 내용은 리포지토리의 실험 로그를 참고하십시오).

⑤ 효과가 없었던 것

태스크 종류 늘리기: 40개 → 92개로 늘려도, 동일한 계산량에서는 성능 향상이 없습니다. -
학습 기간 늘리기: 학습과 동일한 종류의 태스크에서는 성능이 향상되지만, 처음 보는(초견) 태스크에서는 오히려 하락합니다. -
단계 평가에 순서를 고려한 손실(RPS) 추가: 정