Jev는 소프트웨어를 위한 의사결정 계층으로 이해하는 것이 가장 적절합니다. 텍스트나 구조화된 상태를 읽고, 미리 정의된 분류, 점수, 예/아니요 확률을 반환합니다. 사용자를 위해 답변을 작성하지는 않습니다. 이처럼 더 좁은 인터페이스 덕분에 AI 에이전트 내부의 대량 라우팅, 트리아지, 검증, 가드레일 단계에 적합합니다.
실용적인 패턴은 간단합니다. 빈번하고 되돌릴 수 있는 판단은 Jev에 맡기고, 정책 집행은 비즈니스 코드가 담당하게 하며, 불확실하거나 결과가 중대한 사례는 유능한 LLM이나 사람에게 넘기는 것입니다.
Jev를 처음 접하신다면 가장 짧은 설명은 이렇습니다. Jev는 TypeSafe AI가 새로 출시한 AI 결정 모델로, 챗봇보다는 의미 기반의 if 문에 가깝게 동작합니다. 컨텍스트와 고정된 질문 세트를 제공하면, Jev는 애플리케이션 코드가 즉시 사용할 수 있는 타입화된 선택지, 점수, 확률을 반환합니다.
Jev란 무엇인가요?
TypeSafe AI는 Jev를 자사의 첫 번째 System One Model이라고 부르며, System 1/System 2 구분에서 "빠른" 쪽의 개념을 빌려 왔습니다. 요청에는 프로그램 상태와 타입이 지정된 질문이 포함됩니다. Jev는 질문들을 병렬로 평가하고, 소프트웨어가 바로 사용할 수 있는 확률과 신뢰도 값을 반환합니다.
사용 가능한 질문 유형은 다음과 같습니다.
Noul은 예/아니요 진술이 참일 확률을 구합니다.Choice는 미리 정의된 옵션 중에서 선택하며, 확률 분포와 신뢰도를 함께 반환합니다.Score는 순서가 있는 수준을 평가하며, 점수, 기저 분포, 신뢰도를 반환합니다.
자기회귀형 LLM과 달리 Jev는 임의의 문자열을 생성하지 않습니다. TypeSafe는 이를 통해 스키마 일치가 보장된다고 말합니다. 즉, 응답이 필드를 임의로 만들거나 잘못된 데이터 타입을 반환할 수 없습니다. 다만 유효한 답변 중 틀린 것을 고를 수는 있으므로, 타입 안전성을 의미적 무오류성으로 제시해서는 안 됩니다.
Jev는 에이전트 아키텍처의 어디에 들어가나요?
시스템이 제약된 판단이 필요할 때, 상태 변경 사이에 Jev를 사용하십시오.
User or tool result
-> Jev: classify, score, route, or check risk
-> application policy
-> execute a low-risk action
-> call an LLM for reasoning or language
-> request human review
이는 LLM을 보완하는 역할입니다. LLM은 개방형 추론, 설명, 생성 콘텐츠를 담당합니다. Jev는 가능한 답이 미리 알려진 반복적 질문을 처리합니다.
각 작업에 맞는 계층을 선택하세요
Jev는 더 큰 자동화 스택의 한 구성 요소로 보는 것이 가장 이해하기 쉽습니다.
| 계층 | 적합한 용도 |
|---|---|
| Jev | 반복적인 분류, 점수화, 라우팅, 위험 검사 |
| LLM | 복잡한 추론, 설명, 텍스트 생성 |
| 애플리케이션 코드 | 결정론적 규칙, 권한, 실행 |
| 사람 검토자 | 고위험, 모호하거나 예외적인 사례 |
이러한 분업이 Jev의 제품 아이디어의 핵심입니다. 모델이 모든 것을 결정할 필요도, 모든 것을 말할 필요도 없습니다. 모델은 모호한 의미적 맥락을 타입이 지정된 확률 신호로 바꾸고, 정책과 실행에 대한 책임은 주변 시스템이 계속 맡습니다.
1단계: 올바른 첫 워크플로 선택
이미 LLM과 구조화된 출력을 사용하고 있으며 처리량이 많은 기존 결정부터 시작하세요. 좋은 후보로는 지원 티켓 라우팅, 콘텐츠 품질 검사, 에이전트 트레이스 검토, 문서 트리아지, 모델 선택 등이 있습니다.
되돌릴 수 없거나, 법적으로 민감하거나, 지연 시간과 비용보다 최고 정확도가 더 중요한 결정으로는 시작하지 마세요. 또한 자연어 출력이나 감사 가능한 설명이 필요한 작업도 피하십시오. Jev는 추론 서술이 아니라 결정과 확률을 반환합니다.
2단계: 상태와 질문 정의
상태에는 결정에 필요한 근거를 담되, 정책은 애플리케이션 코드에 두세요. 가능하면 넓은 요청을 서로 독립적인 질문으로 분해하세요.
지원 워크플로의 경우 하나의 요청은 다음을 물을 수 있습니다.
- 이 티켓은 어느 큐로 보내야 하나요?
- 이슈의 심각도는 어느 정도인가요?
- 메시지가 악용을 시사하나요?
- 사람의 검토가 필요한가요?
옵션 목록이 실제 모든 사례를 포괄하지 못할 수 있다면 unknown이나 none_of_the_above를 추가하세요. 빠져나갈 경로가 없으면, 닫힌 분류기는 유효하지만 오해를 부를 수 있는 레이블을 골라야 합니다.
3단계: LangChain을 통해 Jev 호출
통합 기능을 설치하고, 환경 변수나 시크릿 매니저를 통해 API 키를 제공하세요.
pip install langchain-typesafe
export TYPESAFE_API_KEY="your-api-key"
그다음 타입이 지정된 질문을 만드세요.
from langchain_typesafe import Noul, TypeSafeClassifier
classifier = TypeSafeClassifier()
response = classifier.invoke(
state=(
"The deploy failed twice and customers are seeing 500s. "
"Can someone look now?"
),
questions={
"urgent": Noul(
instructions="Does this need attention right now?"
),
},
)
urgency = response.nouls["urgent"].noul
결과는 정책이 임계값과 비교할 수 있는 확률입니다. 그 자체로 실행해야 할 지시가 아닙니다.
4단계: 에스컬레이션 정책 구축
단일 보편 기준선 대신 여러 구간을 사용하세요.
high confidence + low consequence -> automatic action
medium confidence -> LLM verification
low confidence -> human review
high consequence at any score -> stronger control or approval
임계값은 작업별로 설정하세요. 티켓 레이블을 자동으로 지정하는 것과 결제를 자동으로 승인하는 것은 둘 다 확률을 사용한다는 이유만으로 같은 위험 정책을 공유해서는 안 됩니다.
5단계: 라우팅과 가드레일을 신중하게 사용
LangChain의 실험적 ModelRouterMiddleware는 Jev를 사용해 단순한 작업은 빠른 모델로, 복잡하거나 중요도가 높은 작업은 더 유능한 모델로 보낼 수 있습니다. 이렇게 하면 모든 요청을 가장 저렴한 옵션으로 처리하지 않고도 전체 모델 사용량을 줄일 수 있습니다.
실험적 AutoModeMiddleware는 Jev를 도구 호출 위험 검사에 적용하며, 제안된 호출을 실행 전에 차단할 수 있습니다. 민감한 도구 주변에는 결정론적 통제를 유지하세요. 분류기는 거짓 음성을 낼 수 있으므로, 허용 목록, 샌드박싱, 범위가 제한된 자격 증명, 속도 제한, 사람의 승인이 여전히 필요합니다.
6단계: 자체 데이터로 평가
TypeSafe는 엔드 투 엔드 지연 시간 70–500 ms, 입력 토큰 100만 개당 $0.042, 출력은 계량되지 않는다고 보고합니다. 네 가지 워크플로 평가에서 Jev는 참조 확률과 평균 67.8% 일치율을 보였으며, 샘플당 약 $0.0004와 0.4초가 소요되었다고 밝혔습니다. 같은 하네스에서 GPT-5.6 Terra는 67.9%, 샘플당 $0.0304와 10.1초였고, GPT-5.6 Sol은 74.1%, $0.0836과 23.3초였다고 보고합니다.
이는 벤더가 공개한 결과이며, 보편적인 예측이 아닙니다. 참조값은 사람이 라벨링한 정답이 아니라 GPT-6 Astra와 Fable 5.1의 평균 예측입니다. TypeSafe도 워크플로 작성자의 편향 가능성을 언급하며, 가장 큰 속도와 비용 개선 효과는 실제 개선 폭의 상한에서 나타날 가능성이 높다고 말합니다.
프로덕션 적용 전에, 가능한 경우 Jev를 현재 사용 중인 LLM, 단순 규칙, 도메인 특화 모델과 비교하세요. 다음 항목을 측정하십시오.
- 클래스별 정확도, 정밀도, 재현율.
- 보정(calibration)과 확신하고 틀린 비율.
- 보류(abstention) 및 에스컬레이션 비율.
- 배포 지역에서의 p50, p95, p99 지연 시간.
- 대체 경로를 포함한 전체 캐스케이드의 엔드 투 엔드 비용.
- 데이터 분포 변화와 적대적 입력에서의 성능.
7단계: 운영 안전장치 추가
프로덕션 준비에는 모델 품질 이상의 것이 필요합니다.
- 상태 버전, 질문 스키마, 확률, 신뢰도, 선택된 분기, 이후 결과를 기록하세요.
- 프롬프트나 질문 지침, 결정 임계값을 버전으로 관리하세요.
- 타임아웃, 횟수가 제한된 재시도, 서킷 브레이커, 결정론적 대체 경로를 추가하세요.
- 확신도가 높은 오류는 별도로 검토하세요. 이는 자동화에서 가장 위험한 실패입니다.
- 드리프트를 모니터링하고, 입력 모집단이 바뀜에 따라 임계값을 다시 보정하세요.
- 되돌릴 수 없거나 규제를 받는 작업은 더 강력한 기술적 통제와 사람의 통제 뒤에 두세요.
공개 자료에는 현재 Jev의 파라미터 수, 상세 아키텍처, RLCD 보상 설계, 표준 보정 곡선, 프로덕션 SLA, p95/p99 서비스 지연 시간이 공개되어 있지 않습니다. 이러한 공백은 가정이 아니라 평가 질문으로 다뤄야 합니다.
언제 Jev를 사용하지 말아야 하나요?
대화, 요약, 코드 생성, 상세한 설명, 장기 추론이 필요한 경우에는 Jev를 주 모델로 사용하지 마세요. 감사 가능한 근거가 필요한 고위험 프로세스에서 단독 결정자로 쓰기에도 적합하지 않습니다. 고정된 도메인에서는 기존의 소형 분류기나 특화된 리랭커가 더 정확하거나, 운영 비용이 적거나, 검증하기 쉬울 수 있습니다.
FAQ
Jev는 LLM인가요?
일반적인 채팅 모델의 의미에서는 아닙니다. 텍스트 또는 구조화된 상태를 입력받지만, 생성된 산문이 아니라 미리 정의된 결정 유형을 반환합니다.
"환각 없음"은 Jev가 틀릴 수 없다는 뜻인가요?
아닙니다. 출력 형태는 보장될 수 있지만, 선택된 답은 의미적으로 틀릴 수 있습니다. 이 주장은 스키마 및 타입 오류에 대한 보호로 해석해야 합니다.
Jev가 에이전트를 구동하는 모델을 대체하나요?
대개는 그렇지 않습니다. Jev는 보완재로 보는 것이 더 적절합니다. 빠른 구조화된 결정에는 Jev, 추론과 언어에는 LLM, 정책 집행에는 코드나 사람을 사용하세요.
RLCD란 무엇인가요?
TypeSafe는 이를 보정된 결정을 위한 강화학습(Reinforcement Learning for Calibrated Decisions)이라고 풀어 설명하며, 보고되는 확률을 관찰된 정답률과 맞추는 것을 목표로 한다고 합니다. 다만 공개 자료에는 독립적인 기술 감사를 할 만큼 충분한 학습 세부 사항이나 표준 보정 근거가 아직 없습니다.
무엇을 먼저 프로토타입으로 만들어야 하나요?
이미 LLM을 거쳐 처리되고 있는, 처리량이 많고 되돌릴 수 있는 분류 하나를 고르세요. Jev를 섀도 모드로 실행하고, 결정을 라벨링된 결과와 비교한 뒤, 임계값과 대체 경로가 검증된 다음에만 자동화를 도입하세요.
측정 가능한 결정 하나로 시작하기
Jev의 가장 큰 가치는 "모든 LLM을 대체하라"는 것이 아닙니다. 이미 알려진 형태를 가진 결정을 생성 모델에 비용을 들여 만들게 하지 말라는 것입니다. 에이전트 하네스에서 한 분기를 골라, 허용 가능한 오류와 에스컬레이션 정책을 정의한 뒤 자체 트래픽으로 테스트하세요.
원본 모델 주장과 주의 사항은 TypeSafe AI의 System One Models와 Jev 소개를, Python 통합과 미들웨어 패턴은 LangChain의 Jev로 하네스를 구축하는 가이드를 참고하세요.
AIHubMix에서 Jev 사용 시작하기
AIHubMix가 Jev 지원을 추가하여, 개발자들이 다른 주요 AI 모델과 함께 이 새로운 결정 모델에 한 곳에서 접근할 수 있게 되었습니다.
Jev를 체험하려면 AIHubMix를 방문하여 워크플로에서 익숙한 분기 하나를 측정 가능한 실험으로 바꿔 보세요. 되돌릴 수 있는 분류나 점수화 작업부터 시작하고, 성공 임계값을 정의한 뒤, 결과를 평가하는 동안 LLM 또는 사람에 의한 대체 경로를 유지하세요.
