문장 대신 판단과 확률을 반환하는 AI 모델 Jev

Jev란? 문장 대신 판단과 확률을 반환하는 AI 모델

작성자:

Jev란 문장을 생성하는 대신 선택·점수·확률과 같은 판단 결과를 반환하는 TypeSafe AI의 AI 모델입니다. 고객 문의의 담당 부서를 분류하거나 검토가 필요한 문서를 가려내는 것처럼, 정해진 범위 안에서 빠르게 판단해야 하는 작업을 위해 설계되었습니다.  공식 모델 설명

일반적인 생성형 AI처럼 답변 문장이나 코드를 만드는 것이 목적이 아닙니다. Jev가 판단과 확률을 반환하면 프로그램이 그 결과를 검사해 분류·검토·실행 여부를 결정합니다. 따라서 Jev를 활용하려면 AI가 무엇을 판단할지와 코드가 무엇을 실행할지를 분리해 설계하는 것이 중요합니다.

Jev는 무엇을 입력받고 무엇을 반환하나요?

Jev에는 판단에 필요한 자료와 답의 형태를 지정한 질문을 함께 보냅니다. 자료를 읽은 모델은 질문별 결과를 반환하고, 프로그램은 그 값을 조건문이나 분류 규칙에 바로 사용할 수 있습니다.

고객이 “결제가 중복된 것 같아요. 확인해 주세요”라고 문의했다고 합시다. 입력 자료에는 문의 내용과 관련 결제 기록을 넣고, 질문에는 “어느 부서가 담당해야 하는가?”와 가능한 부서 목록을 지정합니다. 입력 자료는 공식 문서에서 state, 질문 묶음은 questions라고 부릅니다.

이때 답이 어떤 종류의 값이어야 하는지 미리 정하는 것이 타입 지정입니다. 부서 선택 질문이라면 정해 둔 부서 중 하나와 각 후보의 확률이 돌아옵니다. “결제팀에 보내는 것이 좋겠습니다”라는 문장을 다시 해석해 부서명을 찾아낼 필요가 없습니다. 공식 소개 문서

질문 형태 고객 문의 예시 반환하는 정보
Choice: 선택 결제·기술·기타 중 담당 부서는? 선택 결과, 후보별 확률, 신뢰도
Score: 정도 평가 문의가 얼마나 긴급한가? 정의한 단계상의 점수, 단계별 확률, 신뢰도
Noul: 참·거짓 판단 고객이 환불을 요청했는가? ‘예’일 확률인 0~1 사이 값

Score를 쓸 때는 ‘낮음·중간·높음’만 적기보다 각 단계에 해당하는 상황을 설명해야 합니다. 반환 점수는 단계 사이에 놓일 수도 있습니다. 질문 유형 문서

Noul은 정도를 재는 점수가 아닙니다. 0에 가까우면 강한 ‘아니요’, 1에 가까우면 강한 ‘예’를 나타내며, 0.5 부근은 두 답의 확률이 비슷하다는 뜻입니다. “환불을 요청했는가?”의 값이 중간에 가깝다면 환불 의사의 강도가 중간이라는 뜻이 아니라, 예와 아니요 중 어느 쪽인지 불확실하다는 뜻입니다. Noul 값의 해석

LLM의 구조화 출력과는 무엇이 다른가요?

Jev의 차이는 출력 형식을 제한하는 데 그치지 않고, 생성할 문장 대신 제한된 판단과 확률을 모델의 중심 출력으로 삼았다는 점입니다. TypeSafe는 이런 계열을 빠르고 범위가 좁은 판단에 초점을 맞춘 System One 모델이라고 부릅니다.

많은 대화형 AI의 바탕이 되는 대규모 언어 모델, 즉 LLM은 문맥에 이어질 텍스트를 생성합니다. 이 배경이 낯설다면 LLM의 기본 작동 원리를 먼저 읽어도 좋습니다. 다만 LLM도 정해진 구조의 값을 반환하도록 사용할 수 있으므로, ‘LLM은 문장만 내놓고 Jev만 구조화된 값을 준다’고 나누면 부정확합니다. TypeSafe의 공식 비교용 코드도 LLM의 구조화 출력 기능을 사용합니다. 공식 비교 어댑터

TypeSafe의 설명에 따르면 Jev는 문자열을 순서대로 생성하는 대신 여러 질문의 출력을 병렬로 구합니다. 범용적인 문장 생성의 자유를 내려놓고 소프트웨어가 소비할 판단에 집중한 설계입니다. 공식 출시 글

학습 목표도 확률에 맞춰져 있습니다. 모델이 제시한 확률과 실제 결과의 빈도가 맞도록 훈련하는 접근을 확률 보정이라고 하며, TypeSafe는 이를 위한 강화학습 방법을 RLCD라고 명명했습니다. 잘 보정된 모델이라면 비슷한 확률을 부여한 많은 예측을 모았을 때 그 비율에 맞게 결과가 나타나야 합니다. 개별 답 하나의 정답을 보장한다는 의미는 아닙니다. 학습 목표와 확률 보정 설명

판단은 Jev가, 실행 조건은 코드가 맡습니다

Jev를 활용한 자동화에서는 모델이 좁은 질문에 답하고, 프로그램이 결과를 조합해 실행 여부를 결정합니다. 고객 문의를 읽었다고 해서 Jev 자체가 결제 시스템을 조작하거나 환불을 처리하지는 않습니다.

앞의 중복 결제 문의라면 담당 부서 선택과 환불 요청 여부를 따로 물을 수 있습니다. 같은 자료로 답할 수 있는 독립적인 질문은 한 요청에 묶습니다. 공식 문서는 문의 종류와 버그 심각도를 동시에 평가한 뒤, 실제 버그 문의일 때만 심각도 결과를 사용하는 방식도 제시합니다. 한 질문의 답을 다른 질문이 받아서 푸는 순차 추론과는 구분해야 합니다. 병렬 질문 패턴

Jev 판단과 코드의 검토 분기 구조
Jev가 반환한 판단과 확률을 코드가 검사해 자동 분류와 사람 검토로 나눕니다.

그림은 이를 고객 문의 분류에 적용한 구성 예시입니다. 코드가 분류 결과와 확률·신뢰도를 확인하고, 정한 조건을 충족하면 담당 부서로 보내며 불확실하면 사람이 검토하도록 합니다. 자동 분류 이후 환불 같은 실제 조치를 연결한다면 거래 기록 확인과 실행 권한 검사도 코드에서 별도로 처리해야 합니다. 공식 문서 역시 모델 답변을 코드의 검사와 결합하는 방식을 설명합니다. 모델과 코드의 역할 분담

이 관점에서 Jev는 기존 시스템 안의 분류·검증·분기 지점에 넣어 볼 수 있는 구성 요소입니다. 무엇을 맡기고 무엇을 검증할지 정하는 개발자의 역할은 AI 에이전트와 일하는 개발자의 판단 기준과도 이어집니다.

확률이 높으면 믿고 실행해도 될까요?

확률과 신뢰도는 자동 처리 여부를 정하는 재료이며, 정답 인증서가 아닙니다. 특히 후보별 확률과 별도 필드인 confidence를 같은 뜻으로 읽지 않아야 합니다.

Choice와 Score의 probabilities는 후보나 단계마다 배정된 확률입니다. confidence는 그 확률이 한쪽에 얼마나 모여 있는지를 요약한 값입니다. 신뢰도 값을 그대로 ‘이 건을 맞힐 확률’로 해석하면 안 됩니다. Noul에는 별도의 confidence 필드가 없으며, 반환값 자체가 ‘예’의 확률입니다. 확률과 신뢰도의 차이

출력 형식을 지키는 능력과 내용의 정확성도 별개입니다. ‘결제·기술·기타’만 허용하면 목록에 없는 부서를 만들어 내는 문제를 막을 수 있지만, 실제로는 기술 문의인데 결제를 고르는 오분류까지 사라지지는 않습니다. TypeSafe가 출시 글에서 내세운 환각 방지 주장은 이 출력 제약의 맥락으로 읽어야 합니다. 출력 형식 보장의 설명

자동 처리의 기준값은 실제 업무 자료로 정해야 합니다. 문의 분류를 잘못했을 때의 비용과 환불을 잘못 실행했을 때의 비용이 다르기 때문입니다. 사람이 판정한 사례와 모델 결과를 먼저 비교하고, 불확실한 입력을 검토로 보내는 범위를 조정해 보세요. 공식 문서도 업무별 위험과 자체 평가에 맞춘 기준 설정을 안내합니다. 신뢰도 기준 설정 안내

속도와 가격 수치는 어떤 조건에서 나온 것인가요?

Jev의 낮은 지연 시간과 입력 단가는 공식 자료로 확인되지만, 다른 모델보다 얼마나 유리한지는 업무와 비교 조건에 달려 있습니다. 공개 수치를 모든 AI 작업의 성능 차이로 확대해서는 안 됩니다.

출시 글은 요청부터 응답까지의 시간을 70~500ms로 제시합니다. 자체 업무 흐름 평가에서 193.6배 빠르고 444.6배 저렴했다고 발표했지만, 회사도 실제 개선 폭의 상단에 가까운 결과라고 설명합니다. 측정은 주로 서비스가 위치한 미국 서부에서 수행됐으며, 비교 LLM에 확률까지 출력하게 하는 설정도 시간과 비용에 영향을 줍니다. 평가는 정답표 대신 대형 외부 모델들의 평균 예측을 기준으로 삼았다는 한계도 있습니다. 성능 평가 조건과 단서

작성 기준일의 공식 모델 문서에는 jev-1.13.0이 현재 모델로 기재돼 있습니다. 텍스트를 모델이 처리하는 단위인 토큰을 기준으로 입력 100만 토큰당 0.042달러이며, 출력 토큰은 무료라고 안내합니다. 이 단가는 입력 분량에 대한 가격이므로 실제 업무 비용은 질문과 자료의 길이, 호출 횟수에 따라 달라집니다. 현재 모델과 가격

도입 여부를 판단하려면 같은 문의 자료로 기존 방식과 Jev를 비교해 보세요. 평균 응답 시간뿐 아니라 오분류, 사람이 검토해야 하는 비율, 재시도까지 포함한 비용을 함께 봐야 합니다. 빠르게 답하더라도 검토 부담이 커지면 전체 업무가 빨라지지는 않습니다.

어떤 작업부터 시험하고, 무엇은 맡기지 말아야 할까요?

처음에는 답의 범위를 미리 정할 수 있고, 잘못된 결과를 쉽게 검토할 수 있는 텍스트 분류부터 시험해 보세요. 담당 부서 선택처럼 결과를 바로 확인할 수 있는 과제가 적합한 출발점입니다.

Jev 1.13은 문장 생성, 정밀한 계산, 날짜 비교, 여러 단계를 건너가는 추론에 한계가 있습니다. 공식 한계 문서는 숫자 계산을 코드에 맡기고, 자료에서 필요한 후보를 찾은 뒤 그중 하나를 선택하게 하는 방식을 권합니다. 관련 없는 내용이 길게 섞이거나 판단을 유도하는 악의적인 문구가 들어가도 결과가 흔들릴 수 있습니다. 출력 형식이 안전하다는 이유로 이런 입력 문제까지 해결됐다고 가정해서는 안 됩니다. Jev 1.13의 알려진 한계

한국어 적용도 별도 평가가 필요합니다. 공식 문서는 영어를 주 학습 언어로 설명하며, 다른 언어도 처리하지만 같은 정확도를 보장하지 않습니다. 현재 입력은 텍스트만 지원하므로 이미지·음성·영상은 먼저 텍스트나 구조화된 자료로 바꿔야 합니다. 언어와 입력 지원 범위

시험은 공식 Playground에 자료와 질문을 넣어 결과를 확인하는 것으로 시작할 수 있습니다. 담당 부서 후보에 해당 없음이나 기타가 필요한지 살피고, 애매한 문의도 포함해 평가하세요. 운영 기준을 정한 뒤에는 모델 버전을 기록해 둡니다. 최신 버전을 가리키는 jev-latest는 대상이 바뀔 수 있으므로, 특정 버전에 맞춰 기준을 조정했다면 버전 ID를 고정하라는 것이 공식 안내입니다. 시작 안내 · 버전 선택 안내

Jev를 검토할 때 먼저 할 일은 자동화할 업무에서 ‘문장을 만들어야 하는 부분’과 ‘정해진 결과 중 판단하면 되는 부분’을 구분하는 것입니다. 후자에 속하는 작은 과제를 골라 기존 처리 방식과 비교하면, 생성형 모델과 Jev를 어디에 배치할지 판단할 수 있습니다.

자주 묻는 질문

Jev가 왜 그런 판단을 했는지 설명문도 받을 수 있나요?

공식 문서상 Jev는 판단 이유를 자연어 설명으로 생성하지 않습니다. 별도 생성형 모델로 설명을 작성할 수는 있지만, 그 문장을 Jev의 실제 내부 판단 과정이라고 취급해서는 안 됩니다.

회사 데이터로 Jev를 추가 학습시킬 수 있나요?

현재 공식 문서는 고객별 파인튜닝이나 LoRA 적용을 제공하지 않는다고 설명합니다. 업무 자료를 state에 넣고 질문의 지시문과 선택 기준을 조정해 적용합니다.

Score에서 같은 점수가 나오면 같은 판단인가요?

반드시 그렇지는 않습니다. Score는 단계 번호의 확률 가중 평균이므로 서로 다른 확률 분포에서도 같은 점수가 나올 수 있습니다. 결과를 처리할 때 점수와 함께 단계별 확률과 신뢰도를 확인해야 합니다.

참고 자료

댓글 남기기