Jev vs LLMs: 실제 엔터프라이즈 테스트 결과 및 벤치마크

저자: @eddiedzhou, @mr_cheu, @MatZhao, @CosmicPegasis19, @manav_ai

Jev는 타입이 지정된 결정을 내리기 위한 모델입니다. 컨텍스트와 함께 고정된 질문 및 선택지 세트를 전달하면, 텍스트를 생성하는 대신 선택 결과, 점수, 확률을 반환합니다. 바로 "System One" 모델이죠!

하지만 분류 작업 자체는 새로운 것이 아니며, 구조화된 출력이나 소형 모델, 로짓(logits)에서 확률을 읽어오는 방식 역시 마찬가지입니다. 이러한 배경이 Jev 에 대한 엇갈린 반응의 일부를 설명해 줍니다...

회의론자들의 지적에도 일리가 있지만, Jev 는 이 생태계에서 분명한 자리를 차지하고 있습니다. 이를 더 잘 이해하려면 전체 솔루션 공간을 먼저 짚어봐야 합니다.

대안에는 어떤 것들이 있을까?

시스템에 레이블, 점수, 또는 예/아니오 답변이 필요할 때 고려할 수 있는 합리적인 옵션은 네 가지입니다.

접근 방식

사용 이유

트레이드오프

범용 LLM

제로샷(zero-shot)으로 유연하게 작동하며, 근거와 설명도 생성할 수 있음. 추론 시 컴퓨팅(추론)을 통해 이른바 "더 높은 지능"을 발휘한다고 볼 수 있음.

작은 결정 하나를 위해 자기회귀(autoregressive) 모델의 지연 시간과 비용을 지불해야 함

오픈 제로샷 분류기

저렴하고 로컬에서 실행 가능하며 제어하기 쉬움

품질 편차가 크며, 모델 선택과 서빙을 직접 관리해야 함

파인튜닝된 분류기

레이블 품질이 좋고 트래픽이 많은 안정적 작업에 대체로 가장 적합함

데이터 수집, 학습, 배포, 데이터 드리프트 문제, 그리고 덜 유연한 택소노미(taxonomy)

Jev

깔끔한 호스팅 API 뒤에 숨겨진 제로샷 유연성

작업에 따라 달라지는 품질, 텍스트 생성 불가, 제공업체 종속성

Jev 를 선택해야 하는 이유는 명확합니다. 팀이 새로운 학습 데이터를 수집하지 않고도 질문과 선택지를 바꿀 수 있으며, 모델을 제대로 서빙하는 번거로운 작업도 피할 수 있습니다. 이런 장점을 무시할 사람은 없을 것입니다. "우리도 직접 만들 수 있다"는 말은 대부분의 인프라 제품에 해당하는 이야기니까요.

오픈 소스 재현 프로젝트들은 이 모델의 참신함에 대한 주장을 적절히 견제합니다. Qwen 과 SGLang, DiffusionGemma 와 vLLM, 그리고 Kev를 활용한 구현체들이 API 나 모델 구조의 상당 부분을 그대로 재현해 냈습니다.

n=764 기준 Jev 85.7%, Kev-8B 79.6%

Parallel 의 외부 테스트에서도 Jev 가 리랭킹(reranking) 작업에서 경쟁력을 갖추었음이 확인되었지만, 두 가지 분류 작업에서는 여전히 특화 모델이 우위를 보였습니다.

Glean 에서 확인한 결과

여기서 실질적인 질문이 남습니다. Jev 의 제로샷 유연성과 호스팅 추론 조합이 언제 대안들을 실제로 능가할까요? 저희는 Glean 에서 이미 베이스라인이 확보되어 있어 실제 엔터프라이즈 수준의 품질을 비교할 수 있는 네 가지 제한적(bounded) 결정 작업을 테스트했습니다. 이 베이스라인 대부분이 LLM 기반 시스템이었기 때문에, 해당 실험에서는 비용과 지연 시간이 두 자릿수 수준으로 개선될 것으로 예상했습니다. 결과는 프로덕션 대비 눈에 띄게 떨어지는 경우부터, LLM 기반 라우터보다 빠르고 정확했던 경우까지 다양했습니다.

쿼리 분류

쿼리 분류는 요청을 다운스트림 시스템이 사용하는 광범위한 작업 범주로 매핑하는 과정입니다. 이는 Jev 에 매우 적합한 워크로드인데, 요청 단위로 보면 레이블 공간이 미리 정해져 있지만, 택소노미 자체가 파인튜닝된 분류기를 다시 학습시키는 속도보다 빠르게 변할 수 있기 때문입니다.

이번 실험에서는 LLM 기반인 프로덕션/베이스라인 예측값과 Jev 의 일치도를 측정하는 데 집중했습니다. Jev 를 사용했을 때 오프라인 처리량에서 큰 속도 향상이 있을 것으로 예상했고 실제로도 그랬기에, 품질을 쉽게 가늠할 수 있는 지표로 일치도를 제시합니다. 또한 오픈 웨이트 결정 모델인 Laya 와 파인튜닝된 Laya 도 베이스라인으로 삼았습니다. 파인튜닝은 로컬 환경에서 몇 시간 만에 완료되었고, 모델 크기가 작아 개발자 머신에서도 충분히 서빙할 수 있었습니다.

실험

광범위 작업 일치도

성능

Jev 제로샷

66.8%

12분 (동시성 4

)

기본 Laya

35.9%

90초 (로컬 개발 머신)

파인튜닝된 Laya

74.5%

90초 (로컬 개발 머신)

학습 없이 바로 사용할 수 있는 편리한 모델로서 Jev 는 기본 Laya 를 확실히 앞섰지만, 크게 놀랍지 않게도 파인튜닝을 거친 Laya 가 특히 성능 수치 면에서 뛰어난 결과를 보여주었습니다. 트레이드오프는 양질의 레이블을 확보하고 학습 환경을 구축하는 데 드는 노력입니다. 작업이 새로 추가되었거나 레이블이 자주 바뀌는 상황이라면 Jev 가 여전히 더 매력적인 선택지일 가능성이 높습니다.

모델 라우팅: 전문가 전송(expert transfer)

모델 라우팅은 쿼리 분류와 밀접하게 연관된 문제입니다. 여기서는 모델 라우팅을 '전문가 전송'으로 정의하여, 시스템이 어떤 전문가/모델이 요청을 처리할지 선택하도록 구성했습니다. 현재 프로덕션 베이스라인은 에이전틱 루프 내에서 LLM 이 직접 이 결정을 내리도록 요청합니다. Jev 가 생성형 호출을 제한적 결정으로 대체할 수 있는지 확인하는 자연스러운 테스트이지만, 중요한 기술적 한계가 있습니다. 전송이 발생하지 않는(non-transfer) 경우 Jev 는 반드시 호출을 추가한다는 점입니다. 반면 프로덕션 베이스라인은 전송이 없는 경우에도 동일한 첫 번째 LLM 호출 하나로 도구 호출(tool-calling) 작업을 즉시 시작할 수 있습니다.

저희는 전문가 3명만 포함하도록 프로덕션 라우팅을 단순화한 버전을 사용했습니다. 751개의 비교 가능한 골든(golden) 항목을 업데이트된 Jev 라우터로 다시 실행하고, 기존 프롬프트 기반 라우터(전통적인 LLM 구동)가 선택한 경로와 비교한 뒤 골든 레이블 대비 정확도를 측정했습니다.

또한 기존 경로에서 실제 전문가 전송 호출이 발생한 40개 항목(n 수가 더 작음)을 분리하여, 동일한 항목들에 대한 호출 지연 시간을 비교했습니다.

항목당 중앙값 기준 속도 향상은 8.1배였습니다. 이는 지금까지 나온 내부 Jev 결과 중 가장 강력한 성과 중 하나입니다. 이 제한적 라우팅 작업에서 Jev 는 더 정확하면서도 훨씬 빨랐습니다. 이 정도의 격차라면, 전문가에게 라우팅되지 않은 요청에서 발생하는 "차단(blocking)" 페널티를 감수하더라도 충분한 가치가 있다는 의미일 수 있습니다. 다만 아직 오프라인 골든 셋 비교 단계이며, 지연 시간 샘플에 포함된 긍정적 전송 사례가 40건에 불과하므로 위험을 줄이고 검증해야 할 부분이 많이 남아 있습니다!

리랭킹

Glean 에 아주 각별한 문제입니다! 아래 실험에서 프로덕션 베이스라인은 Glean 의 기존 검색 스택이 생성한 순서입니다. 이번 실험에서는 Jev 에 최대 50개의 결과 순서를 재조정하도록 요청했습니다.

Jev 의 타입 지정 출력을 통해 관련성을 표현하는 네 가지 방식을 시도했습니다.

방식

인용 증거 판별

인용 판별은 서로 연관된 두 가지 질문을 던집니다. 증거가 필요한 주장에 적절한 인용이 포함되어 있는가(인용 재현율), 그리고 인용된 출처가 실제로 해당 주장을 뒷받침하는가(인용 정밀도)입니다. 언뜻 보면 출력/레이블 공간이 제한적이어서(대부분의 판별기 설정과 유사) Jev 에 확실하게 어울리는 작업처럼 보입니다. 그러나 평가 기준이 복잡하고 여러 주장을 분해해야 할 수도 있습니다. 게다가 Jev 는 오류 분석에 자주 활용하는 판단 근거를 생성하지 않으므로 품질과 사용성 모두에 어느 정도 위험이 따릅니다.

응답과 인용 증거를 고정한 상태에서, 1,448단어 분량의 실제 프로덕션 평가 응답을 사용해 Jev 를 테스트했습니다. 추론(reasoning)을 사용하지 않은 경우와 xhigh 추론을 사용한 경우의 GPT-5.6 Luna 와 정밀도 및 재현율 통과율을 비교했습니다. 분산을 줄이기 위해 각 판별기를 세 번씩 실행했습니다.

판별기

응답당 원래 측정 시간

응답당 원래 측정 비용

Jev

6.6초

0.014

GPT-5.6 Luna, 추론 없음

81.3–85.5초

0.030–

0.047

GPT-5.6 Luna,

xhigh

227.4–259.7초

0.047–

0.060

시간 측정은 엔드투엔드가 아닌 방향성 지표라는 점에 유의하세요. Jev 는 클라이언트의 순차적 경과 시간(wall time)을 보고하는 반면, Luna 행은 모델 호출 소요 시간을 합산한 값입니다. 비용에는 관찰된 캐싱이 반영되어 있습니다.

또한 동일한 28개 문단에 대해 일관성을 비교했습니다. 항목 변경은 동일한 입력으로 세 번 실행한 결과 중 최소 한 번 이상에서 해당 문단의 인용 범위가 충분한지에 대한 판정이 달라졌음을 의미합니다. 쌍별 불일치는 세 번의 실행 쌍에 걸쳐 각 문단을 계산한 것으로, 판별기당 총 84번의 비교가 이루어졌습니다.

판별기

재현율 판정이 변경된 문단 수

쌍별 재현율 불일치

Jev

28개 중 1개 (3.6%)

84개 중 2개 (2.4%)

GPT-5.6 Luna, 추론 없음

28개 중 7개 (25.0%)

84개 중 15개 (17.9%)

GPT-5.6 Luna,

xhigh

28개 중 5개 (17.9%)

84개 중 10개 (11.9%)

Jev 의 유일한 변경 사항은 특정 문단이 인용을 필요로 하는지 여부였으며, 원시 재현율 범주 자체는 변하지 않았습니다. 따라서 문단 단위 인용 범위 판정에 있어 Jev 는 두 가지 Luna 설정 모두보다 반복 가능성이 더 높았습니다.

이것이 Jev 를 더 정확한 판별기로 만든다고 결론짓는 것은 아닙니다(두 시스템은 서로 다른 지원 기준과 점수 분모를 적용했으며, 독립적인 사람 레이블링을 진행할 시간이 없었습니다). 하지만 xhigh 추론(Luna 의 모델 시간을 약 3배 늘림)을 적용하더라도 Jev 보다 일관성이 낮았습니다. 이 결과는 Jev 가 좁은 범위의 인용 정책을 구현하는 데 빠르고 저렴하며 비교적 반복 가능한 방법임을 뒷받침합니다.

실험 핵심 요약 및 실용 가이드

경우에 따라 Jev 는 전통적인 LLM 과 파인튜닝된 분류기 모두를 대체하는 마찰 없는 대안으로 빛을 발합니다. 베이스라인이 이미 강력하거나(리랭킹), 소형 모델을 쉽게 파인튜닝할 수 있는 경우(쿼리 분류)에는 이점이 상대적으로 줄어듭니다. 일부 작업(모델 라우팅)에서는 더 나은 품질의 징후가, 다른 작업(인용 판별기)에서는 더 나은 일관성과 안정성의 징후가 나타났습니다. 가장 중요한 워크로드 중 일부에서는 전통적인 LLM 대비 기대했던 비용 및 지연 시간 절감 효과를 달성했습니다.

위 결과는 훌륭한 방향성을 제시하며, Glean 은 Jev 에 대해 큰 기대를 걸고 있습니다. 몇 가지 추가 단계(주로 데이터 거주지 요건 및 보장 같은 운영 준비)를 거친 후, 이러한 유스 케이스 중 일부에 Jev 를 출시할 계획입니다. 또한 이번 주 사내 해커톤에서 Jev 가 큰 역할을 할 예정이어서, 더 많은 결과를 공유하게 되어 무척 기대됩니다!

마지막으로 일반적인 조언을 드리자면, 출력을 미리 나열할 수 있다면 Jev 를 벤치마크해 보세요. 작업과 레이블이 안정적이고 처리량이 많다면 파인튜닝된 분류기도 함께 벤치마크해 보는 것이 좋습니다. 호출 과정에서 쿼리, 설명 또는 기타 동적 텍스트를 생성해야 한다면 생성형 모델을 계속 유지하세요. 도구 호출이 좋은 예입니다. Jev 가 도구 선택을 돕는 데 유용하지만, 대부분의 Glean 도구는 여전히 동적으로 생성된 인수(검색 쿼리 등)가 필요합니다.

Jev 가 분류기가 이미 존재했다는 사실을 바꾸지는 않습니다. 단지 우수한 제로샷 분류기를 훨씬 더 쉽게 활용할 수 있게 만들어 줄 뿐입니다. 모든 AI 시스템의 새로운 토대가 되지는 않더라도, 그 자체로 탄탄한 제품임은 분명합니다.

Jev는 과대평가되었을까요? 실제 엔터프라이즈 작업 4가지로 검증했습니다.

대안에는 어떤 것들이 있을까?