Jev의 깊은 내부를 살펴보면 "패러다임 혁신"의 왕관을 쓸 수 있을지 여부

저자：박양

편집：서청양

기술 분야에서, 과대 광고의 주기는 항상 놀라울 정도로 비슷하다.

2026년 9월, 전체 실리콘밸리와 오픈소스 커뮤니티는 Jev라는 모델을 위해 열광하고 있다.

이 모델은 "시스템 1(System One)" 모델이라고 주장하며, 혁신적인 변화를 가져올 수 있다고 자칭한다.

지난 3~4년 동안, 우리는 마치 장황한 수필가처럼 대형 언어 모델(LLM)에 익숙해져 왔다. 이들은 간단한 "예"와 "아니오"에 대한 답변을 하기 전에 수백 개의 무의미한 사고 토큰을 생성한 후, 느릿느릿 JSON 형식의 결론을 내놓는다.

하지만 Jev는 다르다. Jev는 직접 판단을 제공하고, 확률을 제시하며, 믿을 수 없을 만큼 빠르다.

개발자들은 이러한 "빠르고 정확한" 인터페이스에 미쳐가고 있다.

결국, 복잡한 AI 에이전트(지능형 에이전트)를 구축할 때, 자주 필요한 것은 단지 "이 기억이 관련이 있나요?" "이 요청은 어떤 도구에 전달해야 하나요?" "이 사건은 인력 검토가 필요한가요?"라고 물어보는 것이다.

사람들은 비즈니스에서 일반 대형 모델이 각 작은 문제에 대해 텍스트, 설명 및 구조화된 코드를 생성하는 데 너무 많은 토큰과 지연을 쏟아부었다. 실제 요구에서 출발하여, Jev는 매우 아픈 통증 지점을 정확히 겨냥했다.

하지만, Jev는 정말로 충분한 혁신성을 가지고 있는가?

"텍스트 생성" 과정을 생략했을 때, 이 블랙박스에 남아 있는 판단 능력은 과연 얼마나 원래 대형 언어 모델의 기여에서 비롯된 것인지, 또 얼마나 TypeSafe 팀이 소위 전문적으로 훈련한 것인지에 대한 질문이 남는다.

이 질문에 답하기 위해, 우리는 Jev의 포장을 한 겹씩 벗겨내어 여러 측면에서 자세히 이야기해보자.

01

예측 판단 모델은 GPT보다 더 일찍 등장했다

Jev가 대표하는 이 방향은 매우 긴 역사를 가지고 있다.

2018년, 구글은 BERT를 출시했다. 이는 오늘날 우리가 익숙한 GPT 계열 모델과는 다르게, 정보의 양방향 소통을 허용하는 Encoder-only(인코더 전용) 구조를 채택하여 모델을 완전한 문장으로 훈련시켰다.

비록 나중에 훈련된 Decoder-only(디코더 전용) 모델(예: ChatGPT)이 주류가 되었지만, 명확한 분류 작업에서는 BERT가 여전히 장점을 가지고 있다.

모든 정보를 볼 수 있는 인코더 덕분에 BERT는 텍스트의 각 위치가 앞뒤 문맥을 결합하여 완전한 특성 표현을 형성하게 하고, 간단한 분류 레이어를 연결하여 라벨이 붙은 이메일로 훈련한 후 빠르게 판단을 내릴 수 있다.

현대 LLM도 사실상 많은 경우 분류기 역할로 훈련된다.

2019년, OpenAI는 "Fine-Tuning Language Models from Human Preferences"라는 논문에서 모델이 인간의 텍스트 선호를 학습하도록 시도하기 시작했다.

2020년 텍스트 요약에 관한 연구에서, 이 기술 파이프라인은 더욱 명확해졌다. 인간 주석자는 두 개의 요약을 비교한 후, 이를 통해 보상 모델을 훈련시켜 인간이 어떤 요약을 더 선호하는지를 예측하도록 했다.

이 과정에서 인간의 판단은 성공적으로 점수 함수로 변환되었다. 보상 모델 자체는 긴 평가 코멘트를 작성할 필요가 없으며, 질문과 답변을 읽고 신경망의 출력층을 통해 직접 점수를 제공하면 된다.

이는 현재 모델 학습의 가장 기본적인 패턴 중 하나로, Jev가 강하게 비판하는 RLHF이다.

따라서 "언어 모델의 이해 능력을 계승하되, 텍스트를 생성하지 않는다"는 Jev만의 독창적인 아이디어가 아니다.

2023년의 유명한 논문 "Let's Verify Step by Step"에서는 이러한 감독이 모델의 각 단계에 더욱 세분화되어 적용되었다. 보상 모델, 검증기 및 평가 지표는 다양한 작업에서 발전하여 AI 산업에서 필수적인 여러 판단 도구로 점차 형성되었다.

2025년부터 2026년까지 관련 연구는 여전히 진행 중이다. 2025년 Galileo는 Luna-2를 발표하고, 이후 논문에서 소형 언어 모델을 "단일 토큰 분류기"로 훈련시키는 방법을 보여주었다. Skywork-Reward-V2는 0.6B에서 8B까지의 보상 모델 시리즈를 출시하여 LLM의 직접 점수 경로를 최적화했다.

알고리즘 구현의 관점에서 보면, 이는 본질적으로 어렵지 않다. LLM에 몇 가지 간단한 변경을 가하여 내부의 숨겨진 표현에서 후보 점수를 직접 계산하도록 하면 된다.

후속 실험에서 우리는 세 개 이상의 방법을 볼 수 있다.

그렇다면 Jev는 이번 물결에서 도대체 어떤 다른 것을 가져왔는가?

현재의 구조 해독 및 공식 설명에 따르면, Jev의 핵심 차별성은 두 가지 차원에 있다.

첫째, 더 일반적인 변화는 새로운 후 훈련 방법 덕분이다.

과거의 점수기는 기본적으로 단일 작업을 위해 훈련되었다. Jev는 특정한 점수에 국한되지 않고, 매우 일반적인 확률 인터페이스를 제공하려고 한다.

그리고 이 일반성은 사실 확률에 대한 일반성이지, 인간의 선호에 대한 일반성이 아니다.

이번에 TypeSafe 팀은 "확률 보정"을 훈련 목표의 절대 중심 위치에 두었다. 그들은 이 방법을 RLCD(결정 보정을 위한 강화 학습)라고 부른다. 전통적인 선호 보상 모델(RLHF)은 인간의 선호 확률을 찾는 것이지, 실제 세계 사건의 확률을 찾는 것이 아니다.

둘째, 아키텍처에서 병렬 계산을 극한으로 압축했다.

Jev는 정보가 모델을 통과하는 방식을 변경했다. 과거의 점수 모델은 병렬 응답에서 수정이 많지 않았는데, 주된 목표가 밀집 보상 모델을 훈련하여 나오는 각 토큰에 점수를 주는 것이었기 때문이다.

하지만 이번 Jev는 동일한 자료에 대해 최대 250개의 질문에 답할 수 있다. 이 질문들 간에 생성 순서에 대한 의존 관계가 없다면, 대규모로 배치 병렬 실행이 가능하다.

이것들은 어떻게 구현되었을까?

비록 Jev가 구체적인 아키텍처를 공개하지 않았지만, 실제 성능과 Jev를 복원하려는 여러 시도를 통해 우리는 대략적인 윤곽을 설명할 수 있다.

02

테스트와 복원에서 Jev의 원형을 조합하다

우선 TypeSafe가 현재 공개한 내용을 살펴보자.

블랙박스 밖에서 TypeSafe가 명확히 공개한 것은 우선 인터페이스다. 이 인터페이스에 두 가지를 제공할 수 있다.

상태(State): 긴 독해의 원문에 해당하는 것(예: 긴 고객 불만 기록이나 시스템 로그).

질문(Questions): 이 원문에 대해 동시에 여러 질문을 제기할 수 있다. 질문들 간에는 서로 간섭하지 않는다. 시스템이 이러한 독립적인 답변을 받은 후, 코드를 작성하는 사람(당신)이 다음 비즈니스 논리를 결정한다.

질문을 표준화하기 위해, TypeSafe는 질문 방식을 세 가지 원시어(Primitives)로 수렴시켰다. 포함된 것은:

Noul(예/아니오 질문): "여부"를 묻고, 0~1 사이의 확률을 직접 반환한다(예: 이 일이 긴급한가요? 0.95 반환).

Choice(선택 질문): "어떤 것을 선택할까요?"라고 묻고, 몇 가지 후보를 제시하여 각자의 확률 분포를 반환한다(예: 기술 부서에 0.8, 재무 부서에 0.2).

Score(점수 질문): "정도"를 묻고, 각 등급의 확률과 최종 가중 점수를 반환한다(예: 고객 분노 지수 4.5점).

프로그램이 일반적인 판단을 하도록 하는 것이 목표라면, 이 세 가지 원시어는 상당 부분의 출력 형식을 포괄하며, 거의 모든 판단을 이 세 가지 질문으로 변환할 수 있다.

마지막으로 프로그램은 숫자를 받아 자신의 규칙에 따라 행동을 취한다.

공식적으로 약속된 바에 따르면, Jev는 상태를 한 번만 읽는다. 이후 모든 질문은 동일한 요청 내에서 이 상태에 대해 병렬적이고 독립적인 판단을 한다.

독립적이라는 것은 여러 질문 간에 서로의 답변을 참조할 수 없다는 의미다. 만약 두 번째 질문이 첫 번째 질문의 결과에 의존해야 한다면, 두 번 요청을 보내야 한다.

따라서 TypeSafe는 "추측적 팬 아웃(Speculative fan-out)"이라는 사용법을 장려한다. 예를 들어 고객 불만을 처리할 때, 마지막에 시스템 결함이 아니라는 것을 발견하더라도, 프로그램은 처음부터 "결함인가요?", "결함이 얼마나 심각한가요?", "누구에게 전달해야 하나요?"를 모두 물어볼 수 있다. 시스템은 한 번에 모든 답변을 병렬로 계산한 후, 하위 코드 논리가 쓸모없는 결과를 버린다.

현재, 이것이 우리가 알고 있는 모든 공식 발표된 주요 정보이다.

Jev가 주목받은 후, Archer Hume는 일련의 블랙박스 테스트를 진행하여 Jev가 상태 텍스트를 처리하는 방법에 대한 많은 통찰을 얻었다. 동시에 Kev, NanoJev, minojev 등 오픈소스 복제 프로젝트도 우후죽순처럼 등장했다.

어떤 복제 프로젝트의 테스트 피드백이 Jev 본체에 더 가까운지를 비교함으로써, 우리는 그들의 실제 내부 구조를 역으로 가정할 수 있다.

이 복제들이 Jev의 본체를 100% 복원했다고 말할 수는 없지만, 공식 인터페이스 문서 사이에 남겨진 거대한 블랙홀, 예를 들어 원문이 상태를 어떻게 공유하는지? 일반 후보 옵션이 어떻게 특성 표현을 형성하는지? 그들 간에 어느 단계에서 서로 영향을 미치는지?

우리는 이 렌즈를 통해 대략적인 윤곽을 엿볼 수 있다.

다음으로, 우리는 구체적인 요청을 통해 이 블랙박스 대형 모델의 "내부 소화" 과정을 다시 한 번 거쳐보겠다.

우선, Jev가 실제로 처리하는 정보 구조를 명확히 해야 한다. 완전한 처리는 세 부분으로 구성된다: 공유 배경으로서의 상태(State)(예: 긴 불만 텍스트), 여러 개의 독립적으로 제기된 질문(Questions), 그리고 이 질문 각각에 해당하는 옵션(Options)(후보들).

첫 번째 단계: 공통 정보 처리

각 질문이 수만 자의 불만을 처음부터 끝까지 다시 읽어야 한다면, 질문이 많을수록 반복되는 무의미한 계산이 많아진다.

따라서 가장 좋은 방법은 모든 질문이 한 번만 읽고 사용할 수 있도록 하는 것이다.

Jev가 정말로 "한 번만 읽는다"는 것을 검증하기 위해, 연구자 Archer Hume는 API의 청구서와 지연 데이터를 검토했다: 가장 간단한 예/아니오 질문을 제출할 때, 청구서는 268개의 입력 토큰으로 표시되었다; 두 개의 질문으로 늘어났을 때, 276개로 변했다. 추가된 것은 단지 새로운 질문 자체의 글자 수 비용일 뿐, 시스템은 공동의 상태 자료를 반복적으로 청구하지 않았다.

동시에, 문제 수가 거의 백 개에 이르기 전까지 서버의 응답 시간은 거의 수평선과 같았다.

상업적 요금 규칙과 대량 실행이 그래픽 카드의 실제 계산 기록을 가렸지만, 이는 현상적으로 공식의 "공동 자료는 한 번만 읽고, 각 문제는 대량 계산"이라는 주장과 매우 일치했다.

이 정보 구조에 대해, 오픈 소스 프로젝트 Kev의 복원이 현재 가장 명확하다.

Kev는 먼저 상태를 한 번에 처리하고, 계산된 중간 결과를 Kv Cache에 동결시킨다. 그 다음, 이 50개의 문제는 이 Kv Cache를 공유하여 계산하므로 각 문제를 한 번씩 읽을 필요가 없다.

두 번째 단계: 문제 분할

하지만 또 다른 핵심 문제는, 이러한 대량 계산의 문제들이 정말로 공식에서 말하는 것처럼 서로 간섭하지 않는가?

Archer Hume는 이를 위해 교묘한 "암호 실험"을 설계했다. 그는 문제 A에 "암호는 ZEBRA-7741"이라는 문장을 삽입하고, 문제 B의 선택지에서 모델이 "다른 문제에서 언급된 암호"를 선택하도록 했다. 결과는 Jev가 올바른 암호를 제시할 확률이 0.00이라는 것을 보여주었다. 그러나 이 암호를 문제 A에서 제거하고 모두가 공유하는 State 텍스트에 넣으면, 문제 B가 올바른 답을 제시할 확률이 순간적으로 0.90 이상으로 급증했다.

이는 문제 간에 엄격한 물리적 분리가 존재한다는 강력한 증거를 구성한다: 공동 자료는 모든 문제에 보이지만, 인접한 문제는 절대 서로 "엿볼 수 없다."

문제가 분리될 수 있도록 Kev는 두 가지 방법을 사용했다.

첫 번째 방법은 주의력 마스크로, 이를 통해 시스템이 [동결된 불만 원문] + [문제 1] + [문제 2]를 함께 계산할 때, 모델이 문제 1을 처리하는 동안 마스크 메커니즘이 문제 2의 영역을 값이 0인 상태로 강제로 변환하여, 답변할 때 공동의 불만 원문과 자기 자신만 "주의"할 수 있도록 한다.

두 번째 방법은 독립 분기 재사용으로, 순환 특성이나 특정 구조를 가진 기반(예: 문서에서 언급된 Qwen3.5)에서는 주의력 마스크가 분리될 수 없다. 그래서 이러한 모델을 사용할 때, 모델이 불만 원문을 읽고 나면, 이 동결된 기억을 시작점으로 하여 50개의 평행 고속도로(독립 분기)를 직접 분리해낸다.

각 분기 도로는 이미 처리된 불만 기억을 완벽하게 상속받아, 원문을 다시 읽지 않아도 되는 혜택을 누린다.

세 번째 단계: 선택지 계산

이제 상태가 공용으로 사용되고, 문제도 각각 분리되었으니, 분리된 선택지 내부에서 모델은 후보 항목을 어떻게 계산하고 처리하는가?

이때, 모델 앞에는 몇 개의 후보 항목이 놓여 있다. 예를 들어 "재무", "기술" 등이 있다. 가장 전통적인 방법은 선형 헤드(Linear Head)와 Softmax를 사용하는 것이다. 이는 Zefan Open-Jev 버전이 Jev를 재현하려고 시도할 때 사용한 방식이다.

이것을 절대적으로 폐쇄된 "검은 방 블라인드 심사"와 동일하게 생각할 수 있다. 참가자 "재무"가 검은 방에서 공연을 하고, 당신은 엄격한 채점 가이드라인(이것이 선형 헤드의 기능이다)에 따라 그에게 80의 절대 점수를 주고, 이어서 "기술"이 검은 방에 들어가면 90점을 준다. 이 두 사람은 전 과정에서 만난 적이 없으며, 당신은 그들을 비교하지도 않는다. 마지막으로, 당신은 Softmax라는 비율을 계산하는 수학 공식을 사용하여 80과 90이라는 두 개의 고정 점수를 승률로 변환한다.

이 가상의 과정에서, 만약 우리가 선택지 풀에 전혀 논리적이지 않은 방해 항목인 "나쁜 날씨"를 넣으면, 그것은 최대한 분모에서 포탄 역할을 하여 모든 사람의 비율이 조금씩 줄어드는 역할을 할 뿐이다. 그러나 당신이 재무에 80점을 주고 기술에 90점을 준 것은 이미 종이에 펜으로 적혀 있으므로, 그들 간의 "상대 배당률"은 방해 항목이 추가되었다고 해서 절대 흔들릴 수 없다.

하지만 테스트자 Archer Hume의 테스트는 추가된 선택지가 실제로 모델의 점수 차이에 영향을 미친다는 것을 증명했다. 그는 정상적인 선택지 그룹에 "나쁜 날씨"라는 방해 항목을 강제로 넣고, 10개의 무작위 배열 테스트에서 이것이 재무와 기술의 상대 배당률을 실제로 변경했다는 것을 발견했다. 이는 "검은 방 블라인드 심사" 방식의 사형을 직접 판결한 것이다.

블라인드 심사가 아니라면, 이는 참가자들이 심사위원이 최종 점수를 주기 전에 반드시 "서로를 볼 수 있었다"는 것을 의미하며, 화학 반응이 발생했음을 나타낸다. 오픈 소스 커뮤니티는 이러한 화학 반응을 구현하기 위한 두 가지 설계를 제시했다.

첫 번째 방법은 Kev 프로젝트에서 설계한 "포인터 헤드(Pointer Head)" 방식이다. 이를 "동일한 장면에서의 그룹 면접"으로 상상할 수 있다. 모델은 더 이상 참가자를 검은 방에 가두지 않고, "재무, 기술, 나쁜 날씨"를 일렬로 배치하여 심사위원이 한 번에 모두 볼 수 있도록 한다.

심사위원이 마지막에 서 있는 참가자를 볼 때, 그는 이 면접에 대한 "전체 맥락"을 이미 형성하고 있다. 그런 다음, 심사위원은 마지막 위치에 서서 손가락처럼 앞의 참가자들을 하나씩 가리키며, 이 순간의 전체 인상에 따라 점수를 매긴다. 이 행동을 포인터 헤드라고 한다. 심사위원이 모든 사람을 본 후 다시 돌아가서 가리키고 점수를 매길 때, 그의 마음가짐과 기준이 이미 변했으므로, 재무와 기술에 매긴 점수도 자연스럽게 변동하게 된다.

두 번째 방법은 "심사위원회 내부 토론"으로, NanoJev 등 프로젝트에서 설계한 "후보 간 주의력 모듈(Inter-candidate Attention Module)" 방식이다. 이번에는 모델이 순수한 블라인드 심사도, 순수한 그룹 면접도 아니다. 먼저 "재무"와 "기술"이 각각 공연을 하게 하고, 그들의 성과를 긴 고차원 숫자 평가로 압축한다. 이 용어를 특징 벡터라고 한다.

이때, 두 개의 평가 카드가 여전히 격리되어 있다. 그러나 이후에 하나의 작은 모델이 이 두 개의 평가 카드와 나중에 추가된 "나쁜 날씨"의 평가 카드를 함께 "주의력 모듈"이라는 회의실에 던진다.

이 회의실에서, 이 몇 개의 참가자를 대표하는 숫자(특징 벡터)는 서로 비교되고 평가된다. 원래 재무와 기술은 비례하여 난해하게 얽혀 있었지만, 갑자기 "나쁜 날씨" 카드가 토론에 참여하게 되면, 전체 심사위원회의 토론 초점과 비교 가중치가 즉시 뒤바뀌게 된다.

이러한 상호 간섭의 내부 회의 후에 주어진 최종 점수는 자연스럽게 처음 두 사람만의 모습이 아니게 된다.

왜 Jev는 이렇게 애를 쓰며 이러한 선택들이 하위 코드에서 "서로 간섭"하도록 만들었을까? 이는 단순히 기술을 과시하기 위한 것이 아니라, 실제 복잡한 비즈니스에서는 정답이 종종 절대적이지 않고, "비교"를 통해 도출되기 때문이다. 선택지 자체가 사실상 문제 해결의 숨겨진 단서이다.

예를 들어 에펠탑이 어디에 있는지 물어본다면? 후보 선택지는 A.유럽 B.프랑스 C.파리이다. 모델이 이 세 가지 선택지를 동시에 볼 때, 이 선택지 자체가 이 문제의 의도를 해독하는 숨겨진 단서가 된다. 이 문제는 대략적인 위치를 묻는 것이 아니라, 지리적 위치의 최고 정확도를 시험하는 것이다.

네 번째 단계: 결과 제시

프로세스의 마지막 단계는 구체적인 점수를 도출하는 것이다.

TypeSafe의 공식 설명에 따르면, Jev는 확률 숫자를 직접 반환하며, 절대적으로 텍스트를 생성하지 않는다.

Archer Hume의 외부 탐색도 이를 확인했으며, 그가 후보 선택지를 두 개에서 두 백 개로 미친 듯이 늘렸을 때, API가 반환한 응답 텍스트는 매우 길어졌지만, 서버의 처리 시간은 비례적으로 늘어나지 않았다.

이는 대형 모델이 실제로 가장 시간이 많이 소요되는 자기 회귀 생성(즉, ChatGPT처럼 다음 단어를 예측하는 단계)을 건너뛰었다는 것을 의미한다.

그렇다면 이 최종 확률 숫자는 도대체 어디서 "꺼내"온 것일까? 이 기술 구현은 사실 여러 가지가 있으며, 주로 이전 단계에서 선택지를 계산할 때 사용한 방법에 의존한다.

선택지 상호작용에 특별한 처리를 하지 않은 openjev/openjev의 방식은 모델이 첫 번째 글자를 생성해야 하는 "응답 위치"에서 직접 대형 모델 내부의 단어 목록에서 지정된 후보 문자 토큰의 원래 점수(Logits)를 읽는 것이다.

포인터 헤드가 추가된 Kev는 그 전체를 볼 수 있는 포인터 헤드를 통해 직접 점수를 비교하여 출력한다. 공유 모듈이 추가된 minojev는 그 인공 외부 공유 점수 모듈을 통해 결과를 출력한다.

어떤 추출 방식이든, 프로세스 설계가 적절하다면 대형 모델은 수다스러운 텍스트 생성을 버리고, 계산의 최종 단계에서 직접 정확한 수학적 확률을 추출하여 시스템 수준의 자동 결정을 완료할 수 있다.

여기까지, 우리는 평가와 복원을 기반으로 Jev의 구조 모델을 대략적으로 제시할 수 있다.

이 구조 자체는 복잡하지 않으며, 혁신적인 부분이 거의 없다. 특정 상황에 대한 우수한 엔지니어링 최적화이긴 하지만, 그 이상은 아니다.

03

정확도의 보장은 후 훈련이다

구조는 속도를 보장하지만, Jev의 높은 정확도는 어떻게 달성되었을까?

그것은 TypeSafe가 RLCD(교정 결정 강화 학습) 후 훈련 방법이라고 부르는 것에 의존한다. RLCD는 공개되지 않은 블랙박스이므로, 우리는 오픈 소스 커뮤니티의 시도를 통해 그것의 잠재적인 문제와 알고리즘 구현 방식을 살펴볼 수밖에 없다.

RLCD 훈련 문제의 탄생

가장 간단한 방법은 직접 합성하는 것이다. 예를 들어 Hmm 버전 복제에서 제시된 방식이다.

연구자들은 DeepSeek V4.1이 코드에서 100개 이상의 작업 시나리오를 나열하도록 하였다. 여기에는 환불 처리, 고장 점검, 관련성 검색, 이메일 분류 등이 포함된다.

매번 하나의 시나리오를 선택하고, 자료 형식과 출제 요구 사항을 조합한다. 예를 들어

무관한 세부 사항이 포함된 긴 메시지를 사용하여 몇 개의 환불 사례를 작성한다.

키워드에 의해 오해받기 쉬운 사례를 추가한다.

각 사례에 4~5개의 선택지, 참/거짓 또는 등급 문제를 첨부한다.

DeepSeek V4.1 Flash는 이후 전체 자료, 문제, 후보 항목, 판단 기준 및 답변을 생성한다.

그 후 이 문제가 사용할 수 있는지를 테스트하기 위해 원래 답변을 숨기고, DeepSeek V4.1 Flash가 다시 답변하도록 하며, 기본적으로 세 번 호출하여 매번 선택지 확률을 제시하도록 요구한다. 코드는 최소 두 번의 유효한 응답이 있는 문제만 사용할 수 있도록 허용한다.

Kev의 방법은 현재 존재하는 뉴스 분류, 댓글 감정, 텍스트 함축 등의 데이터 세트를 규칙에 따라 판단 형식인 「자료＋문제＋후보 답변」의 형태로 통합하는 것입니다.

모델은 규칙과 사실을 생성하고, 답변을 계산한 후 이를 글로 작성합니다.

9월 24일의 Kev-4B는 실제 작업 환경을 이용해 문제를 구성하는 시도를 했습니다. 그들은 5,219개의 실제 소비자 금융 불만을 수집하여 「어떤 제품이 관련되어 있는지, 주요 문제는 무엇인지」를 중심으로 문제를 만들었습니다. 문제가 나온 후, 두 개의 서로 다른 교사 모델의 판단이 소비자가 원래 기입한 레이블과 일치할 때만 레이블을 유지합니다.

이 훈련을 더 효과적으로 만들기 위해 복원된 시험 문제는 특별히 쌍으로 된 함정 문제를 출제합니다.

예를 들어 두 문제의 규칙이 완전히 동일하지만 하나의 중요한 이름(예: 서명자가 권한이 있는 Mira에서 권한이 없는 Noah로 변경됨)만 바꾸면 답변이 바로 뒤집힙니다. 이러한 문제는 모델이 보상 해킹을 통해 답변을 외우는 것을 효과적으로 방지하고, 문제와 답변 옵션 간의 깊은 표현과 관계를 학습하도록 강제합니다.

훈련 방법, LoRA와 증류만으로 충분할까요?

현재 기본적으로 모든 후 훈련 방법의 재현은 「LoRA+교사 증류」라는 방법을 사용하여 올바른 옵션의 확률을 높이고 있습니다.

Winnow를 예로 들면, Gemma 4 12B 지시 모델에서 LoRA 미세 조정을 선택했습니다. LoRA의 역할은 기본 원래 가중치를 유지하고, 계산에 참여하는 수정 매개변수를 소량 훈련하여 모델 수정 비용을 낮추는 것입니다.

Winnow는 두 가지 감독을 동시에 사용합니다. 하나는 표준 답변을 제공하여 모델이 올바른 옵션의 확률을 높이도록 요구합니다. 다른 하나는 교사가 모든 옵션에 대한 확률 분포를 제공하여 학생이 이 분포에 가까워지도록 합니다. 교사가 선택한 1위와 표준 답변이 일치할 때만 Winnow는 두 번째 감독을 채택합니다.

두 가지 모두 교차 엔트로피를 통해 훈련 오차를 계산합니다. 여기서 교차 엔트로피가 수행하는 작업은 학생이 확률을 얼마나 잘못 분류했는지를 검사하는 것입니다. 표준 답변이 있을 때, 올바른 옵션이 얻는 확률이 낮을수록 처벌이 커집니다.

교사 분포를 사용할 때, 훈련은 학생이 교사가 각 옵션에 대해 분배한 것을 모방하도록 추진합니다. 예를 들어 교사가 A, B, C에 각각 80%, 15%, 5%를 분배하면 학생은 이 세 가지 옵션 간의 차이를 학습해야 합니다.

일반적으로 LoRA, 증류 및 교차 엔트로피는 이미 준비된 문제, 답변 및 참조 분포가 있는 작업(예: 이러한 예측 확률 작업)에 대해 충분합니다. 왜냐하면 그들이 학습하는 것은 단지 확률이기 때문입니다.

하지만 증류는 사실상 교사 확률을 학습하는 것이지 RCLD가 말하는 현실 확률이 아닙니다. 증류의 격차가 사실/교사의 비율을 통해 어떻게 극복되는지는 현재의 재현에서도 명확한 아이디어가 없습니다.

이론적으로 Jev의 주장을 실현하려면 더 큰 데이터 양과 더 효율적인 학습 방법이 필요합니다.

물론 이렇게 작은 판단 모델이 큰 모델의 판단 정확도에 도달할 수 있다면, 그것이 해결되지 않더라도 매우 유용합니다.

보정, 여전히 비책일 수 있습니다

그 외에도 Jev의 비책은 그것이 주장하는 보정 능력입니다.

모델이 얼마나 많은 문제를 맞혔는지와 그것이 얼마나 정확하게 자신감을 표현하는지는 두 가지 다른 문제입니다. 하나의 모델이 70%만 맞혔더라도, 항상 90%의 자신감을 보고할 수 있습니다.

Jev가 맹목적으로 자신감을 가지고 있는지 확인하기 위해 Archer Hume은 「거짓말 탐지 실험」을 수행했습니다.

그는 먼저 Jev에게 1200개의 MMLU(대규모 다중 작업 언어 이해) 테스트 문제를 제공한 후, 모든 선택된 답변을 시스템이 보고한 확률에 따라 10개의 등급으로 나누었습니다. 복잡한 가중치 계산을 거쳐, Jev의 보정 오차는 0.031에 불과했습니다.

30개의 간단한 세 자리 곱셈 문제에서 Jev는 86.7%를 맞혔고, 자신이 보고한 평균 자신감은 83%로 매우 일치했습니다. 문제가 난이도가 높은 「두 단계 응용 문제」로 바뀌었을 때, 정확도는 32%로 급락했으며, 중요한 것은, 보고한 평균 자신감도 30%로 떨어졌습니다.

이에 대해 후 훈련은 일반적으로 확률 성능을 개선할 수 있지만, 많은 경우 모델을 더욱 맹목적으로 자신감 있게 만들 수 있습니다.

Jev의 비교적 정확한 보정 능력을 복원하기 위해, 복제 버전은 몇 가지 방법을 사용했습니다. 예를 들어 Kev는 모델이 증거가 부족할 때 확실성을 낮추도록 명확히 요구합니다. 그는 훈련 세트에 주요 증거가 제거된 샘플을 추가한 후, 그들의 확률을 낮추어 모델이 근거 없이 특정 옵션에 확률을 집중시키는 것을 처벌합니다.

하지만 더 많은 재현은 단지 일시적인 온도 보정을 수행하는 것에 불과합니다.

엔지니어는 훈련된 모델이 보지 못한 테스트 문제의 소규모 샘플을 제시합니다. 모델이 과도하게 자신감을 보일 경우, 시스템은 이 문제를 통해 전체 자신감 수준을 얼마나 조정해야 하는지를 계산합니다.

조정이 완료되면, 모델이 이후에 확률을 출력할 때, 강제로 겸손한 필터를 착용하게 되어 더 완만한 확률로 변합니다.

이것은 동일한 문제의 옵션 순위를 변경하지 않으므로, 가장 높은 확률의 답변은 변하지 않습니다. 하지만 확률 기준선과 확률에 따라 계산된 점수는 변경될 수 있습니다.

이 방법은 여전히 효과적입니다. 예를 들어 Kev-9B는 온도 보정을 마친 후 보정 오차가 약 10.6%에서 4.2%로 감소했으며, 맞힌 문제 수는 변하지 않았습니다.

이것이 일시적인 해결책이라고 말하는 것은, 이것이 전체 자신감의 조정에서 비롯된 것이지, 자신이 자신감을 가져야 할지를 더 정확하게 구분하는 것에서 비롯된 것이 아니기 때문입니다.

만약 Jev가 정말로 보정률의 유효한 향상을 실현했다면, 그들은 여기서 정말로 특별한 능력을 가지고 있을 수 있습니다.

04

Jev의 적용 경계는 얼마나 넓을까요?

Jev는 의심할 여지 없이 현실적인 응용 의미가 있습니다. 그것은 본래 빠른 결정을 요구하는 작업을 빠른 결정 자체로 복원했습니다.

Agent의 전체 과정에서 요청 분류 및 라우팅, 검색 결과 정렬, 명확한 요구 사항에 대한 항목별 검토가 매우 많습니다. 이러한 모든 것은 Jev가 역할을 발휘할 수 있는 곳입니다.

예를 들어 고객 서비스 분류, 상품 분류, 피드백 분석, 데이터 주석은 우리가 일상 작업에서 자주 접하는 고빈도 시나리오입니다.

하지만 그것의 적용 경계가 얼마나 넓은지는 그것이 주장하는 패러다임 가치를 결정합니다.

현재의 벤치마크를 보면, Jev는 확실히 어느 정도의 일반성을 가지고 있습니다. Nimble 팀은 13개 그룹, 총 3,880개의 공개 데이터를 사용하여 사실 확인, 의도 라우팅, 의미 함축, 콘텐츠 검토, 의학 질문 응답 등의 작업을 측정했으며, Jev는 데이터 세트 평균 정확도가 76.0%입니다.

이는 Jev가 다양한 판단 작업을 수행할 수 있음을 나타냅니다.

하지만 진정한 일반성에는 두 가지 장애물이 있습니다.

첫 번째는 어려운 작업입니다. 만약 단순한 판단만 할 수 있다면, 그 적용 범위는 매우 제한적입니다.

우리는 먼저 판단에서 어려움이 무엇인지 정의해야 합니다. 일반적으로 우리는 단계가 많고 조건이 많으며 세부 사항 이해 요구가 더 세밀할수록 문제가 더 어렵다고 생각합니다.

「사용자가 환불을 원한다」는 단어의 문자적 의미를 이해하는 것만 필요하지만, 「이 환불을 승인해야 하는가」를 판단하려면 날짜를 확인하고, 기한을 계산하고, 조항의 우선 순위를 비교해야 하므로 명백히 더 어렵습니다. 만약 판단이 결과에 도달하기 위해 세 단계의 추론이 필요하다면, 세 번째 단계는 두 번째 단계의 결과에 의존합니다. 첫 번째 단계에서 정책을 잘못 찾으면, 이후의 계산이 완전히 정확하더라도 최종적으로 잘못 판단하게 됩니다.

JevBench의 어려운 문제 테스트에서 JevBench는 다단계 판단, 연속 증거 검색, 날짜 및 숫자 비교와 같은 판단 문제와 관련된 난이도 요인을 규정했습니다. 이 문제들에서 Jev의 다단계 검색 정확도는 85.7%, 긴 정책 판단은 60.5%, 시간 및 숫자 판단은 26.7%에 불과하며, Flash 수준의 모델에 비해 훨씬 떨어집니다. 어려운 문제를 합산하면 Jev는 74.1%를 맞혔고, DeepSeek V4.1 Flash는 95.0%로 인간 전문가와 비슷한 수준입니다.

비록 해당 테스트의 요청 중간 소요 시간이 약 0.67초와 3.15초로 Jev의 속도가 거의 네 배 빨라졌지만, 이렇게 큰 정확도 차이는 복잡한 작업에 대한 판단(예: 모두가 원하는 주식 거래)에서 어떤 선택을 해야 할지 명백합니다.

또한 여기서 다단계 검색 정확도는 다단계 추론이 아니라 주로 검색과 관련이 있습니다. Archer Hume의 테스트에서 Jev는 간단한 곱셈에서 86.7%의 정확도를 기록했지만, 두 단계 응용 문제로 바뀌자 정확도가 32%로 급락했습니다.

Briantrust는 Jev의 어려운 문제에 대한 발목을 더 세밀하게 평가했습니다. 그것은 Jev와 GPT 5.6 Luna 모델을 비교하여 모델이 두 개의 후보 답변 중에서 올바른 것을 선택하도록 하였고, 최종적으로 616개의 유효 문제 쌍을 비교했습니다. 두 모델의 지식 문제에서 차이는 1.6% 포인트에 불과했지만, 수학 및 추론에서는 19.3% 포인트로 확대되었고, 코드에서는 20% 포인트에 달했습니다.

따라서 어려운 판단이라는 장애물에서 Jev는 자신이 이미 넘어섰다고 말하기 어렵습니다.

또 다른 장애물은 일반화입니다.

만약 Jev가 정말로 일반화가 가능하다면, 그것은 비교적 좋은 일반화를 할 수 있어야 하며, 학습한 것에서 다른 문제 판단의 정확도를 향상시킬 수 있어야 합니다.

그렇지 않다면, 그것은 적용 범위가 조금 넓은 「전문 판단 모델」일 뿐이며, 이전의 판단 모델과는 큰 차이가 없습니다.

현재의 여러 직접 테스트 증거는 Jev가 확실히 일정한 일반화 능력을 가지고 있음을 입증할 수 있지만, 이러한 능력은 분야 내에서 매우 불안정합니다. 그리고 익숙한 장면을 넘어서는 순간, 그 성능은 여전히 큰 위험에 직면합니다.

먼저, 완전히 동일한 작업과 사실 하에서 Jev의 판단은 정보 제시 방식에 쉽게 영향을 받습니다. OpenProse 실험에서 어떤 사실, 문제 및 계산량도 변경하지 않은 상태에서, 핵심 관계가 텍스트의 앞쪽에 집중될 때 Jev의 정확도는 80.5%였지만, 이러한 관계가 중간으로 이동했을 때 정확도는 40.9%로 반토막이 났습니다.

이는 비록 비즈니스 분야를 변경하지 않더라도 Jev의 표현 강건성이 심각하게 부족함을 나타냅니다. Jev의 판단 능력은 외부 프로그램이 데이터를 어떻게 제공하는지에 크게 의존합니다.

둘째, 동일한 평가 시스템 하의 새로운 문제에 직면했을 때 Jev의 성능 변동도 매우 뚜렷합니다. JevBench의 새 버전 v1.4에서 추가된 308개의 폐쇄형 어려운 문제에서 Jev의 정확도는 공개 문제의 86.6%에서 36.7%로 급락했으며, 대조적으로 사고 방식을 사용하는 DeepSeek V4.1 Flash는 94.8%를 유지했습니다.

Jev가 과거에 공개 문제에서 얻은 높은 점수는 자동으로 미지의 복잡한 테스트로 이어지지 않습니다.

테스트가 실제 비즈니스 이전으로 더욱 진전될 때, Jev의 성과는 역시 긍정적이고 부정적인 면이 혼재되어 있다. 긍정적인 예시는 Agent Journal의 힌트 주입 감지에서 나타나며, Jev는 원래 테스트 세트에서 정확도가 83.65%였고, 2천 개 이상의 외부 데이터가 포함된 다른 테스트 세트로 직접 이전했을 때 정확도가 95.58%로 상승하여 전통적인 기준 모델을 훨씬 초과했다.

이는 특정 작업에서 데이터 출처의 변화에 적응할 수 있음을 보여준다.

하지만 논리가 더 복잡한 비즈니스에서는 이러한 일반화가 종종 실패한다. Scarif Labs는 이를 사용하여 소프트웨어 업데이트가 안전한지 판단했다. 모델을 하나의 소프트웨어 생태계에서 다른 생태계로 이동할 때, Jev의 안전과 위험 업데이트를 구분하는 능력 지표(AUROC)는 0.851에서 0.605로 떨어졌다(무작위 추측의 0.5에 가까움).

따라서 우리는 적어도 현재 Jev의 일반화가 비교적 제한적이며 의문이 있다는 것을 말할 수 있다. 그것은 일반적인 일반화 기준에서 아직 멀리 떨어져 있다.

Jev가 일반적인 두 가지 장벽을 넘지 못했으므로, 우리는 지금 어디에서 그것을 사용해야 할까?

더 적합한 위치는 Jev를 기준이 명확하고, 증거가 집중되어 있으며, 판단 결과를 검토하거나 수정할 수 있는 단계에 두는 것이다.

여전히 환불을 예로 들자면, 사용자가 환불 의사를 표현했는지, 불만이 물류와 관련이 있는지 또는 상품 품질과 관련이 있는지, 증빙을 추가해야 하는지 판단하는 것은 개별적으로 검증할 수 있는 의미적 판단이다. 이러한 문제는 자주 발생하며, 일반적으로 설명을 생성할 필요가 없고 매번 주 모델이 추론을 전개할 필요도 없다. Jev는 여기서 초기 분류를 담당할 수 있다.

하지만 환불을 승인하려면 상황이 달라진다. 기한을 초과했는지, 날짜를 확인하기 위해 코드가 필요하고, 환불 금액은 규칙에 따라 계산해야 하며, 조항 충돌이나 예외 상황이 발생할 경우 추가 검토가 필요하다. TypeSafe 자신도 수학 연산과 날짜 비교는 코드에 맡기고 판단의 다층 의존성을 최대한 줄일 것을 권장한다.

이러한 분업을 통해 Jev의 속도를 적절한 위치에 활용할 수 있다.

정확도에 더 의존하는 용도, 예를 들어 보상 모델에서는 판단해야 할 것이 종종 표면적으로 합리적이지만 실제로는 잘못된 답변이다. 모델은 미세한 차이를 구별하고 표현 스타일의 간섭에 저항해야 한다.

그리고 규칙이 비교적 어려운 작업, 예를 들어 비교적 주관적인 평가를 포함하는 규칙의 경우, 적어도 Jev의 정확도를 먼저 시험해 본 후 배포해야 한다.

이때 Jev는 후보 솔루션으로 사용할 수 있지만, 채택자는 여전히 작업 전용 평가가 필요하다.

또한 놓쳐서는 안 될 점이 있다. Jev가 빠르게 반응한다고 해서, 그것을 추가한 후 전체 Agent가 더 빨라지는 것은 아니다.

만약 Jev가 간단한 요청을 미리 처리하여 이러한 요청이 주 모델을 호출하지 않게 된다면, 속도와 비용의 이점이 실현될 기회가 생긴다.

하지만 매번 Jev를 먼저 호출하고 여전히 같은 주 모델을 호출해야 한다면, 추가된 판단은 자신의 소요 시간과 비용을 상쇄하기 위해 충분히 많은 후속 작업을 절약해야 한다.

GitHub의 한 그룹 Agent 메모리 검색 실험에서 시스템은 Jev를 도입하여 검색된 정보가 유용한지 판단했다. Jev가 유용한 정보를 잘못 버리지 않도록 하기 위해 개발자는 판단 기준을 반복적으로 조정해야 했다.

결국 20개의 일반 사례가 모두 통과하게 되었지만, 그 대가는 명확했다. 시스템의 총 지연 시간은 649밀리초에서 1087밀리초로 증가했고, 천 번 호출당 비용도 두 배 이상 증가했다.

주 모델 자체가 복잡한 자료에서 답변을 선별하는 능력을 갖추고 있다면, 앞에 Jev를 판단기로 추가하는 것은 대기 시간을 늘릴 뿐만 아니라 오판으로 인해 중요한 증거를 놓칠 위험을 감수하는 것이다.

05

Jev의 혁신성은 과연 얼마나 진짜인가?

논의가 끝날 무렵, Jev가 우리에게 남긴 핵심 질문은, 도대체 무엇을 배우고 있는가이다?

원칙적으로 판단에 사용되는 모델은 새로운 사실을 통해 효과적인 판단을 내리기 위해 학습하는 표현을 배워야 한다.

이는 거의 가장 어려운 표현 중 하나이다.

일반적인 판단은 여러 능력을 동시에 호출해야 하며, 마지막에 단지 하나의 확률을 출력한다고 해서 그것이 답변을 생성하는 것보다 쉽다고 생각해서는 안 된다.

환불을 예로 들면, "환불하고 싶다"는 말을 보고 환불 의사를 인식하는 것은 주로 언어 이해에 의존한다. 하지만 "이 정책에 따라 환불을 승인해야 하는가"라고 물으면, 모델은 정책을 이해하고 구매 날짜, 상품 상태 등의 사실을 구체적인 조항에 대응시켜야 하며, 예외를 처리해야 한다.

이것은 기본적으로 Jev의 언어 모델의 능력 기반이다.

마지막 질문인 "환불이 이 고객을 유지하는 데 도움이 되는가"는 행동 결과를 예측해야 한다. 이것이 바로 모델이 훈련해야 할 부분이다.

모델은 어떤 사실이 결과에 영향을 미치는지, 어떤 조건에서 영향을 미치는지, 그리고 다른 상황으로 바뀌었을 때 이러한 관계가 여전히 성립하는지를 배워야 한다.

세 가지 질문 모두 "예의 확률"을 출력할 수 있지만, 그 뒤에 필요한 지식과 계산은 다르다.

"다른 사람들이 어떻게 판단할지를 예측하는 것"에서 "신뢰할 수 있는 행동 결과를 예측하는 것"으로 넘어가기 위해 우리는 결국 얼마나 많은 데이터와 훈련이 필요할까?

적어도 사람에게 있어, 종합적인 판단은 가장 배우기 어려운 일이다. 기본적으로 우리가 이전 기사에서 언급한 취향과 종합적인 공리 계산만큼 복잡하다.

따라서 나는 이 글에서 현재 공개된 학습 방법이 이러한 복잡한 표현을 수용할 수 있을지 매우 의심스럽다.

물론 우리는 Jev를 매우 기발한 공학 도구로 볼 수 있다.

규칙이 명확하고 자료가 충분한 비즈니스 파이프라인에서, 그것은 대기 시간과 계산 비용을 대폭 줄일 수 있으며, 그 가치는 의심할 여지가 없다.

하지만 그것이 실제로 어떤 일반적인 판단 법칙을 학습했다는 것을 증명하기 전까지, Jev에게 "패러다임 혁신"의 왕관을 씌우는 것은 시기상조이다.