Jev란 무엇인가요? TypeSafe AI의 System One 모델 설명

대부분의 AI 모델은 무언가를 말하도록 만들어집니다. Jev는 무언가를 결정하고 — 소프트웨어가 즉시 사용할 수 있는 형태로 답을 반환하도록 만들어졌습니다.

고객의 메시지가 도착합니다. 이것이 청구 관련인지, 지원 관련인지, 판매 관련인지를 판단해야 합니다. 검색된 구절이 관련성이 있어 보입니다. 답변 모델로 보낼 만큼 충분히 강력한가요? 에이전트가 행동을 제안합니다. 워크플로가 이를 허용해야 할까요, 차단해야 할까요, 아니면 사람에게 물어봐야 할까요?

이것들은 사실 글쓰기 작업이 아닙니다. 소프트웨어 안에 숨겨진 작은 판단들입니다. 팀은 이미 가지고 있는 AI 도구이기 때문에 종종 이러한 작업을 범용 언어 모델에 맡깁니다. 모델은 입력을 읽고, 한 번에 하나의 토큰씩 응답을 생성하며, 애플리케이션은 답변을 레이블, 점수 또는 불리언으로 다시 파싱합니다.

TypeSafe AI는 Jev를 도입했습니다. 2026년 9월 15일, 다른 유형의 모델로 등장했습니다. 회사는 이 범주를 System One 모델: 구조화되지 않은 상태가 들어가고, 제한된 선택지, 점수, 확률, 신뢰도가 나옵니다. Jev는 대화하거나, 설명하거나, 코드를 작성하지 않습니다. 그것은 좁은 의미론적 결정을 내립니다.

그것은 작은 차이처럼 들립니다. 그러나 중요할 수 있습니다. 만약 Jev의 초기 속도, 비용, 그리고 보정 주장들이 더 넓은 테스트에서도 유지된다면, 애플리케이션은 워크플로우의 모든 작은 분기마다 대형 언어 모델을 사용할 필요가 없어질 수 있습니다. 그 결과는 LLM를 대체하지 않을 것입니다. 그것은 LLM와 그 주변의 나머지 소프트웨어에 더 빠른 결정 계층을 제공할 것입니다.

이 가이드는 Jev가 무엇인지, “System One”가 무엇을 의미하는지, 그 Choice, Score, 그리고 Noul 질문이 어떻게 작동하는지, 비용이 얼마인지, 벤치마크 증거가 무엇을 보여주는지, 그리고 그 한계가 어디에서 중요한지를 설명합니다. 간략한 사양과 1차 출처는 다음을 참조하십시오. Jev 1.13 model page 또는 새 항목을 둘러보세요 AI 결정 모델 카테고리.

Jev 사실	현재 세부 정보
개발자	TypeSafe AI
현재 모델	Jev 1.13; API ID jev-1.13.0
출시	2026년 9월 15일
반환 항목	선택지, 순위 점수, 확률 및 신뢰 신호
반환하지 않는 항목	자유 형식의 글, 설명, 코드, 이미지, 오디오 또는 비디오
입력 용량	요청당 64K 토큰; 상태와 가장 긴 질문 합계 최대 32K
가격	입력 토큰 100만 개당 $0.042; 출력은 무료
공개 속도	System One 형식 쿼리에 대해 처음부터 끝까지 70–500 ms
접근	조기 접근 Playground 및 Python 및 JavaScript SDK가 있는 API

Jev AI란 무엇인가?

Jev는 텍스트 또는 구조화된 상태에 대해 제한된 판단을 내리는 전문 모델입니다. 개발자가 “JSON 객체 작성”을 프롬프트하고 생성된 응답이 형식을 따르기를 기대하는 대신, 가능한 답변을 추론 전에 정의합니다. 그 후 Jev는 허용된 값 중 하나 또는 점수나 확률을 반환하며, 불확실성 정보도 함께 제공합니다.

가장 쉬운 정신 모델은 자연어를 이해하고, 동시에 여러 질문을 고려하며, 자신이 얼마나 확신하는지 드러낼 수 있는 매우 유능한 분류기입니다. Jev를 작은 채팅봇으로 취급하는 것보다 그 설명이 더 유용합니다. 그것은 애플리케이션 안에서 작동하도록 설계되었으며, 애플리케이션 자체가 되도록 설계된 것은 아닙니다.

지원 시스템이 다음과 같은 메시지를 받는다고 가정해 보겠습니다: “어제 업그레이드했는데 카드가 두 번 청구되었고 추가 결제가 아직 사라지지 않았습니다.” 하나의 Jev 요청은 이 메시지가 청구와 관련된 것인지, 얼마나 긴급해 보이는지, 상위로 전달해야 하는지 여부, 민감한 계정 정보를 포함할 가능성이 얼마나 되는지 요청할 수 있습니다. 각 질문에는 지정된 출력 형식이 있습니다. 애플리케이션은 단락을 파싱하지 않고도 티켓을 라우팅할 수 있습니다.

현재 별명 jev-latest 결정된다 jev-1.13.0. 대부분의 독자들은 그 ID를 외울 필요가 없습니다; 그것은 주로 재현 가능한 생산 테스트에 중요합니다. 더 넓은 의미는 제품입니다: Jev는 TypeSafe가 에이전트, 검색, 검토, 운영 및 고객 워크플로우와 관련된 많은 작은 결정을 처리하기를 희망하는 범주의 첫 번째 구성원입니다.

왜 그것을 'System One' 모델이라고 부르나요?

이 이름은 심리학자 다니엘 카너먼(Daniel Kahneman)이 대중화한 시스템 1(System 1)과 시스템 2(System 2) 프레이밍에서 차용한 것입니다. 시스템 1은 빠르고 직관적인 판단을 설명하며, 시스템 2는 더 느리고 신중한 추론을 설명합니다. 이 비유는 Jev가 사람처럼 생각한다는 주장이 아닙니다. 이는 모델이 최적화된 작업을 설명합니다.

A frontier LLM 같은 GPT-6 Astra 또는 Claude Fable 5.1 광범위하고 생성적인 작업을 위해 설계되었습니다: 문제를 조사하고, 도구를 사용하고, 코드를 작성하고, 장단점을 설명하거나 문서를 작성합니다. Jev는 의도적으로 더 좁습니다. 사용 가능한 상태를 읽고 빠르게 작은 결정을 반환합니다.

TypeSafe는 아키텍처가 다음을 사용한다고 말합니다 병렬 샘플러 대답 토큰을 하나씩 생성하는 것보다는. 문서에서도 동일한 요청 내의 질문들은 독립적이고 병렬적으로 평가된다고 나와 있습니다. 이는 여러 분류나 채점 질문을 추가하는 것이 일반적인 LLM가 순차적으로 처리하는 것보다 지연 시간 패널티가 훨씬 적어야 함을 의미합니다.

회사는 Jev를 사용하여 훈련했습니다 RLCD, Reinforcement Learning for Calibrated Decisions의 약자입니다. 사용자에게 중요한 목표는 보정(calibration)입니다: 여러 유사한 예측 중에서 80% 확률은 대략 80%의 경우에 맞아야 합니다. 보정은 개별 답변이 정확할 것이라고 약속하지 않습니다. 대신 불확실성을 라우팅 및 임계값 설정에 더 유용하게 만듭니다.

선택, 점수, 그리고 Noul: Jev의 세 가지 질문 유형

Jev는 현재 세 가지 기본 요소를 제공합니다. 이들은 함께 비즈니스 소프트웨어 안에 숨겨진 작은 판단의 큰 부분을 포괄합니다.

선택은 허용된 집합에서 선택합니다.

Choice 질문은 Jev에 다음과 같은 고정된 라벨 목록을 제공합니다: 청구, 기술 지원, 영업, 취소, 또는 기타. 응답에는 선택된 라벨, 사용 가능한 선택 항목에 대한 확률 분포, 그리고 해당 분포에서 도출된 신뢰도 값이 포함됩니다.

이는 의도 분류, 대기열 라우팅, 정책 선택, 콘텐츠 태깅, 그리고 어떤 도구나 에이전트가 작업을 받아야 하는지 결정하는 데 적합합니다. TypeSafe 문서는 최대 255개의 선택지를 지원합니다. 매우 큰 라벨 집합의 경우, 그 지침은 수백 개의 거의 중복된 선택지를 하나의 평면 문제로 처리하는 대신, 필드를 좁히고 두 번째 결정을 내리라고 권장합니다.

Score는 항목을 순서가 있는 척도에 배치합니다.

점수 질문은 정렬된 범위를 정의합니다—예를 들어, 긴급도는 1에서 5까지, 잠재 고객 품질은 0에서 10까지입니다. Jev는 허용된 값에 대한 분포와 신뢰 신호와 함께 점수를 반환합니다.

점수는 인접한 결과 간의 차이가 중요한 경우에 유용합니다. 위험 점수 4는 1보다 5에 더 가깝습니다; 단순히 관련 없는 레이블 세트는 그 순서를 나타내지 못합니다. 응용 프로그램은 결과를 서비스 수준, 검토 대기열, 임계값 또는 우선순위 지정으로 변환할 수 있습니다.

Noul는 문장의 확률을 추정합니다.

Noul 질문은 0과 1 사이의 값을 요청합니다: 이 문장이 쿼리에 답할 가능성은 얼마인지, 요청이 규칙을 위반할 가능성은 얼마인지, 혹은 이 에이전트 추적이 실패를 나타낼 가능성은 얼마인지? Noul는 확률을 직접 반환합니다. Choice와 Score와 달리, 현재 Noul 응답은 별도의 신뢰 속성을 추가하지 않습니다.

이상한 이름은 패턴만큼 중요하지 않습니다. 모델이 임의의 경계에서 '예' 또는 '아니오'라고 말하도록 강제하는 대신, 애플리케이션은 확률을 받아 스스로 경계를 선택합니다. 무해한 개인화 결정은 0.65를 수용할 수 있습니다. 높은 위험의 결제나 보안 조치는 0.98과 두 번째 확인을 요구할 수 있습니다.

Jev가 정말로 '전혀 환각이 없다'고 할 수 있나요?

TypeSafe는 Jev가 스키마가 세 개만 허용할 때 네 번째 카테고리를 발명하거나, 코드가 숫자를 기대하는 단락을 반환하거나, 인식되지 않은 필드를 즉흥적으로 만들어낼 수 없기 때문에 환각에 대해 강한 언어를 사용합니다. 그것은 의미 있는 신뢰성 향상입니다. 그 shape 응답의 범위가 제한되어 있다.

그것이 그 판단이 항상 옳다는 것을 의미하지는 않습니다. Jev는 여전히 잘못된 라벨을 선택하거나, 점수를 너무 높게 매기거나, 간접적인 지시를 오해하거나, 입력이 적대적이거나 관련 없는 자료로 가득 찰 때 신뢰성이 떨어질 수 있습니다. TypeSafe 자체의 Jev 1.13 톱니 모양 안내 그 약점을 문서화한다.

정확하게 말하는 방법은:

• 스키마 환각은 제한됩니다. 출력은 선언된 결정 유형에 맞아야 합니다.
• 의미적 오류가 여전히 발생할 수 있습니다. 유효한 레이블일지라도 잘못된 레이블일 수 있습니다.
• 신뢰도는 오류 관리에 도움이 됩니다. 검토나 대체 접근을 유발할 수는 있지만, 이는 증거가 아닙니다.

이 구분은 모든 구조화된 AI 시스템에 중요합니다. 일반 LLM에서 JSON 모드는 파싱 가능한 필드를 보장할 수 있지만, 그 필드 안의 값들은 여전히 잘못될 수 있습니다. Jev는 전체 모델을 제한된 결정에 맞추어 전문화함으로써 문제를 더욱 줄이지만, 운영 팀은 여전히 평가와 안전 기준이 필요합니다.

Jev는 얼마나 빠르고 저렴한가요?

TypeSafe의 현재 모델 페이지에는 Jev 1.13가 입력 토큰 10억 개당 $42로 나와 있으며, 이는 다음과 동일합니다. 입력 토큰 백만 개당 $0.042. 출력은 Jev가 긴 응답을 생성하지 않기 때문에 무료입니다. 그 속도로라면, 백만 건의 500토큰 분류 요청은 5억 개의 입력 토큰을 사용하게 되며, 애플리케이션, 저장, 네트워크, 인적 검토 비용을 제외하기 전에도 모델 목록 비용이 약 $21가 됩니다.

출시 게시물 보고 70에서 500밀리초 System One용으로 설계된 작업에 대해 엔드 투 엔드(end to end)로 수행하며, 비교에 사용된 일반 모델보다 40배에서 200배까지 속도 향상을 주장합니다. 이러한 수치는 TypeSafe 자체가 제공하는 맥락이 필요합니다:

• 대부분의 시간 측정 테스트는 미국 서부 해안의 노트북에서 실행되었습니다;
• 네 가지 워크플로 평가는 TypeSafe 팀이 설계했습니다;
• 비교 라벨은 독립적인 인간 골드 라벨이 아니라 고사고 GPT-6 Astra 및 Claude Fable 5.1 응답에서 파생되었습니다; 그리고
• 회사는 초기 가격이 보조될 수 있으며 영구적인 것으로 간주해서는 안 된다고 말합니다.

다시 말해, 출시 증거는 유망하지만 결정적이지는 않습니다. 헤드라인 최대치—193.6배 빠르고 444.6배 저렴함—는 공급업체가 수행한 과제 집합의 유리한 결과일 뿐, 모든 LLM 호출에 대한 보편적인 변환 계수는 아닙니다.

초기 Jev 평가가 실제로 보여주는 것

TypeSafe는 보안 사고 분류, 에이전트 추적 관찰 가능성, 송장 처리, 고객 서비스 결정과 관련된 네 가지 워크플로 평가를 게시합니다. 각 워크플로는 하나의 광범위한 프롬프트를 여러 개의 유형화된 질문으로 분해한 다음, 정확도, 비용 및 시간을 일반 모델 기준과 비교합니다.

중심적인 결과는 순위표보다는 워크플로 패턴에 관한 것입니다. 작업이 소수의 레이블이나 숫자로 끝난다면, 전문 모델은 결코 작성할 필요가 없는 답변을 구성하고 직렬화하는데 일반 LLM를 사용하지 않아도 됩니다. 병렬 질문은 또한 여러 개의 별도 호출을 대체할 수 있습니다.

하나의 유용한 외부 증거가 있습니다. 엔지니어 말테 울브(Malte Ubl)는 기존 분류기 평가에서 Jev를 실행했는데, 이 평가는 Gemini 2.5 Flash-Lite를 사용한 적이 있습니다. 그 하나의 테스트에서 Jev는 품질 평가를 포화시키면서 약 6배 빨리 실행되었습니다. 그 보고서 Jev보다 이전에 평가가 이루어졌기 때문에 고무적이지만, 여전히 단일 개발자의 테스트일 뿐이며 광범위한 독립 벤치마크 스위트는 아니다.

빠른 시각적 설명을 위해, 마티야 소식은 출판했습니다 45초 Jev 요약. 스티브 크라우스도 공유했다 작은 라이브 데모 그것은 벤치마크 표보다 상태-질문 패턴을 더 쉽게 느낄 수 있게 합니다.

이 증거는 Jev 테스트를 정당화하기에 충분합니다. 그러나 아직 Jev가 모든 작은 LLM, 분류기, 재순위기, 또는 규칙 엔진을 능가한다고 선언하기에는 충분하지 않습니다. 공정한 평가를 위해서는 실제 제품에서 가져온 고정 예제, 인간 검토 라벨, 동일한 네트워크 경로, 그리고 결과를 보기 전에 선택한 임계값 정책을 사용하는 것이 좋습니다.

Jev 대 LLMs: 실제로 무엇이 다른가?

차원	Jev / System One	범용 LLM
주요 업무	선택, 점수 매기기 또는 확률 추정	생성, 추론, 설명, 코딩 및 도구 사용
출력	사전 정의된 타입 값	선택적으로 JSON로 제한될 수 있는 개방형 토큰
불확실성	지원되는 경우 기본 확률 분포 및 신뢰도	보통 보정된 애플리케이션 신호로 노출되지 않음
여러 질문	병렬로 평가되는 독립적인 질문	종종 하나의 생성된 시퀀스 또는 여러 호출에서 답변됨
최적 용도	대규모, 좁은 의미 결정	모호하고, 창의적이며, 다단계 또는 설명적인 작업
불가 사항	산문, 코드 또는 설명을 작성할 수 없음	세 가지 모두 생성 가능

따라서 올바른 비교는 'Jev가 최첨단 모델을 이길 수 있는가?'가 아니라 '왜 우리가 최첨단 모델에게 이 특정 작업을 시키고 있는가?'이다. GPT-5.6 루나와 같은 작은 일반 모델 또는 Claude Haiku 4.5 더 유연하게 남아 있습니다. 하나의 요청에서 필드를 추출하고, 메시지를 재작성하며, 도구를 호출하고, 답변을 설명할 수 있습니다. Jev는 더 엄격한 계약을 대가로 그 유연성을 포기합니다.

Jev 대 구조화된 출력 또는 JSON 모드

구조화된 출력은 가장 친숙한 대안입니다. 개발자는 LLM에 스키마를 제공하고, 제공자는 생성된 응답이 파싱되도록 제한합니다. 이는 애플리케이션이 이름, 설명, 날짜 또는 다른 생성 필드를 가진 풍부한 객체가 필요할 때 매우 유용합니다.

Jev는 더 작은 출력 공간에 더 적합합니다. 답은 이미 존재하며, 모델은 단지 그것들을 선택하거나 점수를 매깁니다. 생성할 출력이 적고, 확률 분포는 제품의 일부이며, 전체 아키텍처는 결정에 맞춰 최적화됩니다. 구조 안에서 생성된 콘텐츠가 필요할 때는 JSON 모드를 사용하세요. 모든 유효한 답이 이미 알려져 있을 때는 Jev를 고려하세요.

Jev와 전통적인 분류기

일반적인 분류기는 학습 후에 매우 빠르고 비용이 저렴할 수 있습니다. 충분한 라벨이 있는 안정적이고 대량의 문제에는 최선의 선택이 될 수 있습니다. Jev의 매력은 각 팀이 별도의 모델을 학습하고 운영하도록 요구하지 않고도 자연어 유연성과 소수 샷 설정을 그 작업 범주에 가져오려고 한다는 점입니다.

거래-off는 제어입니다. 맞춤 분류기는 좁은 분류 체계에 맞게 조정할 수 있고, 익숙한 지표로 검사할 수 있으며, 사설 환경에 배포할 수 있습니다. Jev는 현재 호스팅된 조기 액세스 서비스입니다. 팀은 정확도와 지연 시간뿐만 아니라 데이터 위치, 재학습 필요성, 라벨 변동, 운영 노력도 비교해야 합니다.

Jev 대 리랭커

리랭커는 예를 들어 Cohere 빠른 Rerank 4 쿼리와 후보 문서를 받아서 해당 후보들을 관련성에 따라 정렬합니다. Jev는 특정 구절이 질문에 답하는지 여부를 묻거나 구절을 기준표에 따라 점수 매길 수 있지만, 동일한 학습 목표와 검색 전용 계약을 가진 즉시 사용 가능한 재정렬 모델은 아닙니다.

RAG의 경우, 도구들이 서로를 보완할 수 있습니다. 검색은 후보를 찾고, 재정렬기는 그 순서를 정하며, Jev는 '최상위 증거가 답변하기에 충분한가?' 또는 '이 단락이 어떤 정책 주제를 지지하는가?'와 같은 제한된 결정을 내릴 수 있습니다. 더 큰 모델은 결정 레이어에서 증거가 충분하다고 판단할 때만 인용된 답변을 작성합니다.

Jev가 유용할 수 있는 경우

1. 요청 및 에이전트 작업 라우팅

Jev는 들어오는 요청을 분류하고, 전문 에이전트를 선택하며, 긴급도를 평가하고, 사람이 검토해야 하는지 여부를 결정할 수 있습니다. 각 출력이 제한되어 있기 때문에, 오케스트레이터는 다음 단계를 수행하기 전에 서술형 응답을 해석할 필요가 없습니다.

2. AI 에이전트에 신뢰도 게이트 추가

에이전트는 행동을 제안할 수 있으며, Jev는 별도로 해당 행동이 사용자의 목표와 일치하는지, 정책 내에 있는지, 또는 완전해 보이는지를 판단할 수 있습니다. 신뢰도가 낮은 경우에는 일시 중지할 수 있습니다. 이것이 완전한 보안 경계는 아니며—모델은 여전히 적대적 입력에 의해 영향을 받을 수 있습니다—그러나 코드가 최종 규칙을 적용하기 전에 빠른 의미론적 검사를 추가할 수 있습니다.

3. RAG 및 기업 검색 개선

문서 시스템은 이미 파서와 같은 전문 레이어를 사용합니다: Cohere Parse 또는 우리 안의 오픈 소스 도구 문서화 가이드 구조를 복구하다; 임베딩은 후보를 검색하다; 재순위기는 그것들을 다시 정렬하다. Jev는 또 다른 결정을 추가할 수 있다: 증거가 충분한지, 모순되는지, 민감한지, 오래된 것인지, 혹은 특정 답변 경로에 적절한지 여부.

4. 분류, 점수 매기기, 그리고 운영

리드, 지원 티켓, 송장, 사건 보고서, 리뷰, 에이전트 추적 모두 결국 큐나 점수가 되는 비정형 언어를 포함하고 있습니다. Jev는 이러한 변환을 위해 설계되었습니다. 분류법이 너무 자주 변경되어 맞춤 분류기를 사용하는 것이 불편하지만 출력이 충분히 제한되어 있어 산문이 필요하지 않은 경우 그 가치가 가장 높습니다.

5. 많은 항목에 대한 맵-리듀스 결정

워크플로우는 동일한 질문을 구절, 레코드, 메시지 또는 추적 범위에 독립적으로 적용한 다음 코드가 결과를 집계하도록 할 수 있습니다. 이를 통해 모델은 지역 의미 판단에 집중하고 결정론적 코드는 계산, 임계값, 최종 선택을 처리할 수 있습니다.

Jev가 적합하지 않은 경우

TypeSafe는 Jev의 거친 면들에 대해 유난히 직접적입니다. 이러한 투명성은 전문 모델이 하나의 데모에서 넓게 지능적이어 보이지만 인접한 작업에서 실패할 수 있기 때문에 유용합니다.

• 작성하는 데 사용하지 마십시오. Jev는 답변, 설명, 요약 또는 코드 한 줄을 작성할 수 없습니다.
• 코드에서 산수를 유지하십시오. 제공자는 계산, 산술, 숫자 정밀도의 약점을 문서화합니다.
• 날짜 로직을 코드에 유지하세요. 날짜와 시간을 비교하는 것은 문서화된 약점입니다.
• 질문을 문자 그대로 작성하십시오. 간접적이거나 중첩된 지침은 신뢰성을 떨어뜨릴 수 있습니다.
• 관련 없는 문맥을 제거하십시오. 관련 없는 많은 상태 정보는 문맥 제한에 맞더라도 결정에 해로울 수 있습니다.
• 적대적 입력을 테스트하십시오. 프롬프트 삽입과 모순되는 지시는 여전히 모델을 조종할 수 있습니다.
• 보정과 확실성을 혼동하지 마십시오. 높은 신뢰도 값은 제품 자체 데이터에서 검증이 필요합니다.

좋은 규칙은 결정론적 사실은 결정론적 시스템에 맡기는 것입니다. 코드는 합계를 계산하고, 타임스탬프를 비교하며, 권한을 확인하고, 제한을 강제하며, 부수 효과를 실행해야 합니다. Jev는 실제로 의미 판단이 필요한 부분을 처리해야 합니다.

실용적인 아키텍처: LLM 옆에 Jev를 사용합니다.

가장 설득력 있는 설계는 대체가 아닌 연쇄 구조입니다:

1. 코드는 강력한 검사를 수행합니다. 인증, 제한, 필수 필드, 날짜, 숫자 규칙을 검증합니다.
2. Jev는 좁은 의미 판단을 내립니다. 요청을 분류하고, 위험을 평가하거나, 증거가 충분한지 추정합니다.
3. 워크플로우는 불확실성을 읽습니다. 신뢰할 수 있고 위험이 낮은 결정을 수락하거나, 애매한 사례는 더 큰 모델에 전달하거나, 사람에게 물어봅니다.
4. LLM는 생성 작업을 처리합니다. 응답을 작성하고, 문제를 조사하고, 승인된 도구를 호출하거나, 결과를 설명합니다.
5. 코드가 이 행동을 담당합니다. 결정과 소스 버전을 기록하고, 정책을 시행하며, 최종 상태 변경을 수행합니다.

이 구조는 필요한 경우에만 비용이 많이 드는 추론을 예약할 수 있습니다. 또한 에이전트를 감사하기 쉽게 만들 수 있습니다: 결정 기록에는 질문, 허용된 답변, 확률, 임계값, 선택된 경로 및 모델 버전이 포함되어 있으며, 다른 구성 요소가 해석한 불투명한 단락 대신에 기록됩니다.

Jev를 생산 환경에서 사용하기 전에 평가하는 방법

1. 기존 결정을 기준으로 시작합니다. 라벨, 순서가 있는 점수 또는 확률로 끝나는 기존 작업을 선택합니다—분류 데모에 억지로 맞춘 쓰기 작업이 아닙니다.
2. 대표 테스트 세트를 고정(freeze)합니다. 쉬운 사례, 모호한 사례, 희귀 라벨, 긴 입력, 모순되는 언어, 적대적 예제를 포함합니다.
3. 사람이 검토한 라벨을 사용하세요. LLM 합의는 탐색을 부트스트랩할 수 있지만, 생산 정확도는 사람들이 승인한 표준과 비교하여 측정해야 합니다.
4. 정확도뿐만 아니라 측정 보정도 하세요. 확률에 따라 예측을 그룹화하고 신뢰도가 관측된 정확성과 일치하는지 확인하세요.
5. 결과에 따라 기준을 설정하세요. 실제 결정에 대한 위양성 및 위음성 간의 균형을 최적화하십시오. 마케팅 태그와 결제 보류는 동일한 기준값을 공유해서는 안 됩니다.
6. 전체 작업 비용을 비교하세요. 재시도, 대체 LLM 호출, 인간 검토, 네트워킹 및 엔지니어링을 포함하고, 토큰 가격만이 아니라.
7. 모델 버전을 고정하세요. 사용하다 jev-1.13.0 재현 가능한 평가를 위해; 이동 jev-latest 회귀 테스트로만.
8. 안전하게 로그인하세요. 민감한 원본 텍스트를 불필요하게 오래 보관하지 않고 결정을 디버그할 수 있을 만큼 충분히 기록하세요.

Jev API를 일반 영어로 접근

Jev는 TypeSafe의 조기 접근 API와 플레이그라운드를 통해 이용 가능합니다. API는 사용합니다 POST /v1/systemone, 그리고 TypeSafe는 Python 및 JavaScript SDK를 제공합니다. 요청에는 공유 상태와 하나 이상의 질문이 포함됩니다. 응답에는 타입이 지정된 결과가 포함됩니다.

현재 공개된 얼리 액세스 제한은 초당 250,000 입력 토큰과 분당 1,200 요청이지만, TypeSafe는 수요가 안정될 때 제한이 동적으로 변경될 수 있다고 합니다. 하나의 요청에는 여러 개의 독립적인 질문을 포함할 수 있으므로, 모든 결정마다 네트워크 호출이 필요하지 않을 수 있습니다.

개발자는 두 가지 별칭을 염두에 두어야 합니다. jev-latest 안정적인 프로덕션 라인을 따르며 현재 Jev 1.13를 가리킵니다. jev-preview 가장 최신 후보를 위한 것이며 현재 동일한 버전을 가리킵니다. 규제되거나 영향이 큰 워크플로에 변화가 발생할 경우 숫자 ID를 고정하십시오.

개인정보 및 기업 고려사항

TypeSafe의 개인정보 보호정책에 따르면 고객 입력은 모델을 학습시키거나 세부 조정하는 데 사용되지 않습니다. 또한 서비스가 미국에서 호스팅된다고 명시되어 있습니다. 공개 정책은 모든 API 요청에 대해 하나의 고정된 데이터 보존 기간을 보장하지 않으며, 명시된 목적에 합리적으로 필요한 범위 내에서 개인정보를 보관한다고 설명합니다.

이는 Jev가 기업 데이터에 부적합하다는 의미와는 다릅니다. 이는 구매자가 자신의 워크로드에 필요한 정확한 데이터 처리, 보관, 하위 프로세서, 삭제, 보안 및 지역 조건을 확인해야 한다는 것을 의미합니다. 조기 액세스 시 서비스 수준 약속, 감사 로그, 모델 버전 공지, 사고 대응 및 용량 보장에 대해 문의하기에도 적절한 시기입니다.

자주 묻는 질문

Jev란 무엇인가요?

Jev는 TypeSafe AI의 첫 번째 System One 모델입니다. 이것은 텍스트나 구조화된 상태를 자유형 글을 생성하는 대신, 애플리케이션 코드용으로 미리 정의된 선택지, 점수, 확률로 변환합니다.

Jev는 LLM인가요?

TypeSafe는 Jev를 범용 LLM가 아닌 새로운 전문 모델 범주로 제시합니다. 그것은 자연어 상태를 이해하지만, 그 역할은 토큰 단위 텍스트 생성이 아닌 제한된 의사결정입니다.

Jev 가격은 얼마인가요?

TypeSafe는 현재 Jev 1.13를 입력 토큰 백만 개당 $0.042로 책정하고 있으며, 출력 토큰 요금은 없습니다. 회사 측은 초기 가격이 보조금 형태일 수 있으므로, 실제 생산 구매자는 실시간 요금을 확인해야 한다고 합니다.

Jev 속도는 얼마나 빠른가요?

TypeSafe는 적합한 System One 쿼리에 대해 종단 간 지연시간이 70~500밀리초라고 보고합니다. 이는 공급자가 보고한 범위이며, 보편적인 SLA가 아니며, 지리적 위치, 부하, 입력 길이 및 워크플로 설계에 따라 결과가 달라질 수 있습니다.

Choice, Score, 그리고 Noul는 무엇인가요?

Choice는 미리 정의된 레이블 중에서 선택하고, Score는 순서가 있는 척도에서 값을 선택하며, Noul는 0과 1 사이의 확률을 반환합니다. Choice와 Score는 분포와 신뢰 값도 반환하고, Noul는 확률 자체를 반환합니다.

Jev가 환각을 일으킬 수 있나요?

Jev는 선언된 타입 외의 출력을 만들어낼 수 없기 때문에 잘못되거나 개방형 응답을 방지할 수 있습니다. 그러나 의미상 잘못된 결정을 내릴 수 있으므로 팀은 정확성, 보정, 적대적 행동 및 임계값을 평가해야 합니다.

Jev가 GPT나 Claude를 대체할 수 있나요?

아니요. Jev는 글쓰기, 설명, 코딩, 브라우징 또는 도구 사용을 하지 않습니다. 일부 좁은 범위의 분류나 점수 호출을 대체할 수 있으며, 어려운 사례는 GPT나 Claude와 같은 일반 모델로 라우팅할 수 있습니다.

Jev는 RAG에 적합한가요?

잠재적으로 의사 결정 계층으로서, Jev는 증거가 충분한지 판단하고, 글을 분류하며, 정책 관련성을 평가하거나 답변을 제어할 수 있습니다. 그러나 임베딩을 생성하거나, 문서를 파싱하거나, 후보를 기본적으로 재순위화하거나, 최종 인용된 답변을 작성하지는 않습니다.

Jev는 일반적으로 사용 가능한가요?

아니요. Jev는 TypeSafe의 Playground와 API를 통해 2026년 9월 17일 기준으로 초기 접근 상태입니다.

출처 및 방법론

이 기사는 2026년 9월 17일에 조사되었습니다. 제품 설계, 속도, 비용, 벤치마크 주장은 TypeSafe AI에서 나옵니다 기사 출시, System One 문서, 모델 및 가격 페이지, 신뢰 가이드, 빠른 시작, 그리고 워크플로 평가 사이트. 제한 사항은 제공자의 Jev 1.13 톱니 모양 가이드에서 나오며; 데이터 처리 설명은 그것에서 나옵니다 개인정보 처리방침.

우리는 제공자 운영 결과를 제공자 청구로 표시합니다. Malte Ubl의 분류기 결과는 보편적 벤치마크가 아닌 독립 실무자 보고서로 포함됩니다. 저희는 직접 Jev 수행하지 않았으며, TypeSafe의 최고 속도나 비용 승수를 관련 없는 작업 부하에 대한 청구로 전환하지 않습니다. 가격, 별칭, 접근 및 초기 제한은 출판 후 변경될 수 있습니다.

결론

Jev 흥미로운 점은 AI 소프트웨어에서 일상화된 습관, 즉 모든 의미 작업을 작성하기 위해 만들어진 모델에 보내는 습관에 의문을 제기한다는 점입니다. 많은 생산 결정은 에세이가 필요하지 않습니다. 알려진 라벨, 순서가 정해진 점수, 또는 코드가 작용할 확률이 필요합니다.

TypeSafe의 첫 번째 릴리스는 그 전문 계층에 대한 야심찬 사례를 제시합니다. 비용은 매우 적고, 보고된 지연 시간은 밀리초 단위이며, 출력 계약은 좁고, 애플리케이션에서 불확실성을 활용할 수 있습니다. 출시 평가와 초기 개발자 테스트로 인해 Jev는 심각하게 실험해볼 가치가 있습니다.

한계는 개념의 일부이지, 부차적인 생각이 아닙니다. Jev는 스스로를 설명할 수 없으며, 산술이나 날짜 논리를 수행해서는 안 되며, 여전히 오분류할 수 있고, 좁은 문맥과 적대적 지시에 취약합니다. 그것은 결정적 코드와 범용 LLM 사이에 속하며, 둘보다 위에 있는 것이 아닙니다.

그 아키텍처가 실제 데이터에서 견고하다면, “System One 모델”은 유용한 범주가 될 수 있습니다. Jev는 중요해지기 위해 GPT, Claude 또는 학습된 분류기를 대체할 필요가 없습니다. 단지 그들을 둘러싼 작은 결정을 더 빠르고, 더 저렴하게, 더 명확한 계약으로 다룰 수 있으면 충분합니다.