종합 점수가 같은 두 모델이 정반대였다

종합 점수 83.1% 대 83.0%. 거의 같다. 그런데 항목을 펼치면 이렇다.

| 벤치마크 | Jeff-2B | Jev | |---|---|---| | Financial PhraseBank | 96.3% | 77.0% | | RAGTruth | 88.9% | 77.3% | | BBH | 68.0% | 94.3% | | WinoGrande | 79.0% | 90.7% | | JudgeBench | 64.6% | 78.6% | | JevBench hard | 53.3% | 73.3% |

같은 평균이 정반대 성격의 모델을 가리킨다. 문장 분류와 근거 확인이 내 일이면 한쪽이고, 다단계 추론이면 반대쪽이다. 종합 점수만 보고 고르면 반대 방향으로 간다.

출처: firelex/jeff

확인된 것

무엇인가 — 상황 설명과 선택지를 받아 단 한 번의 순전파로 각 선택지의 보정된 확률을 돌려주는 소형 분류 모델. 질문 유형 세 가지(choice 최대 255개 중 선택 / noul 예-아니오 확률 / score 점수). TypeSafe의 상용 모델 Jev와 요청 형식만 동일하며, 저자는 "not affiliated with or endorsed by TypeSafe"라고 명시한다.

속도 — 0.8B 기준 RTX PRO 6000에서 22ms, Apple M4 Max(MLX)에서 28ms, CPU 32스레드에서 463ms. 2B는 각각 24ms / 60ms / 708ms.

학습 비용 — 워크스테이션 GPU 한 장으로 0.8B가 약 2시간, 2B가 약 3.5시간. 합성 데이터 생성은 DGX Spark 두 대. 오픈 모델만 썼고 상용 모델 출력은 넣지 않았다고 밝힌다.

라이선스 — 코드 MIT, 가중치 Apache 2.0. 학습 데이터셋은 공개하지 않았다.

저자가 직접 적은 한계

• "Small models don't reason." 다단계 추론이 아니라 서술된 선택지 사이의 빠르고 보정된 선택을 기대하라
• "Benchmark scores don't predict game play."
• Jeff-2B는 벤치마크 점수가 더 높은데도 Jeff-0.8B보다 게임을 못한다 — 학습이 의도치 않은 위험 회피를 넣은 것으로 보인다고 저자가 추정
• "Prompts matter enormously. Wording matters enormously."
• 미래 상태를 예측하게 시키면 무작위와 다를 바 없다
• 영어, 텍스트 전용

비교의 단서

The published Jev and AutoJev figures were measured on a different sample of the same benchmarks.

판단

1. 평균이 전부 가린다 — 내 작업에 가장 가까운 항목 하나만 봐라

83.1 대 83.0은 "비슷한 모델"로 읽힌다. 실제로는 Financial PhraseBank에서 19%p 이기고 BBH에서 26%p 진다.

방향이 일관적이라 더 쓸모 있다. 이기는 쪽은 분류와 근거 확인(금융 문장 감성 분류, RAG 환각 판정)이고, 지는 쪽은 추론(BBH, WinoGrande, JevBench hard)이다. 소형 분류기라는 정체성과 정확히 맞는다.

→ 실행은 단순하다. 종합 점수를 보지 말고 내 작업과 가장 닮은 벤치마크 하나를 골라 그 열만 읽는다. 없으면 그 모델에 대해 아무것도 모르는 것이다.

2. 저자가 두 방식으로 쟀고, 어긋났고, 그걸 README에 적었다

이 저장소에서 제일 값진 건 모델이 아니라 이 문장이다. 벤치마크 점수가 게임 플레이를 예측하지 못한다. 그리고 구체적으로 — 2B가 벤치마크에서 4%p 높은데 게임은 0.8B가 더 잘한다.

벤치마크로 골랐으면 틀린 걸 골랐을 상황을, 만든 사람이 스스로 공개했다.

사흘 전에 쓴 기준의 더 강한 형태다. 측정기를 같이 내는 것보다 한 단계 위는, 자기 측정기 둘이 싸운 결과를 그대로 보여주는 것이다.

→ 실행: 에이전트에 모델을 붙일 때 공개 벤치마크에서 멈추지 말고 내 작업을 흉내 낸 시나리오 하나를 만든다. 20개 케이스면 충분하다. 둘이 어긋나면 뒤쪽을 믿는다.

3. "판단을 물어보는" 호출 중 상당수는 분류다

라우팅, 의도 분류, 근거 확인, 예-아니오 게이트. 이런 걸 프런티어 모델에 네트워크 왕복으로 물어보고 있다면 옮길 자리가 있다. 0.8B가 M4 Max에서 28ms고, CPU만 있어도 463ms다. 학습은 GPU 한 장 2시간.

다만 옮길 수 있는 것과 없는 것이 숫자로 갈린다. RAGTruth 86.1%와 Financial PhraseBank 96.4%는 쓸 만하고, BBH 64.0%와 JevBench hard 47.6%는 아니다.

→ 분류나 판정으로 좁혀 쓸 수 있는 것만 옮긴다. "이게 맞는지 판단해줘"는 못 옮기고, "이 응답이 주어진 문서에 근거하는가"는 옮길 수 있다.

4. 한계 두 개가 채택 조건을 정한다

프롬프트 민감도. 0.8B 분류기가 표현에 크게 흔들린다면, 선택지 문구를 코드에 상수로 고정하고 버전 관리해야 한다. 프롬프트가 데이터가 아니라 설정이 된다. 어제 쓴 채팅 템플릿 얘기와 같은 자리다.

예측은 안 된다. 현재 상태 평가용이지 미래 상태 예측용이 아니라고 저자가 못 박는다. 무작위와 차이가 없다. 이걸 모르고 "다음 분기에 이탈할 사용자" 같은 데 붙이면 조용히 망가진다.

모르는 것

• 직접 돌려보지 않았다. 지연시간도 정확도도 저자 측정이다.
• 저장소가 어제 만들어졌다(2026-09-28 생성, 별 184개). 제3자 재현 결과가 아직 없다.
• Jev와의 비교는 다른 표본에서 측정된 공개 수치와 붙인 것이다. 저자가 밝혔지만, 동일 조건 비교가 아니므로 표의 승패를 곧이곧대로 읽으면 안 된다.
• "game play"가 정확히 무엇인지 확인하지 못했다. 저자가 벤치마크와 별개의 평가를 돌린 건 분명한데 그 설계를 보지 못했다. 이 글의 두 번째 판단이 거기 걸려 있으니 그만큼 약하다.
• 학습 데이터셋이 공개되지 않아 재현하려면 데이터 생성부터 다시 해야 한다. 저자는 그 단계에 DGX Spark 두 대를 썼다.
• 한국어는 안 된다. 영어 텍스트 전용이라 국내 서비스에 바로 붙일 수 없다.
• Jev 쪽 자료를 직접 확인하지 않았다. Jev 수치는 저자가 옮겨 적은 공개값이다.