대부분의 사람들은 채팅창을 열고 타이핑을 하면서 새로운 모델을 만납니다. Jev는 그런 반사적인 행동을 처벌합니다. Jev는 TypeSafe AI의 System One 모델로, 전혀 산문을 생성하지 않습니다. 대신 프로그램 상태와 유형이 지정된 질문 세트를 제공하면, Jev는 확률이 첨부된 결정을 돌려줍니다. 이러한 역할 변화가 전체 기술의 핵심입니다. 여러분의 언어 모델은 계속 글을 쓰고, Jev는 다음에 무슨 일이 일어날지 결정하며, 여러분의 코드는 그 결정을 어떻게 처리할지 결정합니다.
이 가이드는 호출 자체보다는 호출을 둘러싼 아키텍처를 다룹니다. 먼저 기본 정보가 필요하다면, Jev가 무엇인지부터 시작한 다음, 회사의 관점을 이해하기 위해 TypeSafe의 출시 게시물을 읽어보세요.
Jev가 탁월한 점
Jev가 하는 모든 것은 세 가지 기본 요소로 이루어집니다. noul은 상태에 대한 하나의 진술이 참일 확률을 반환합니다. choice는 기준 맵(최대 255개 옵션)에서 하나의 옵션을 선택하고 선택된 옵션, 전체 확률 분포 및 신뢰도 값을 반환합니다. score는 상태를 2~10단계의 순서가 있는 평가 기준에 배치하고 해당 수준, 범례, 확률 및 신뢰도를 반환합니다. 회사 및 모델군에 대한 배경 정보는 TypeSafe AI에 대한 저희 글에서 확인할 수 있습니다.
아키텍처에는 네 가지 속성이 중요합니다. 모든 답변은 프로그램이 이미 이해하는 유형으로 도착합니다. 모든 답변은 자체적인 불확실성을 가지고 있으므로, "확실하지 않음"은 놀라움이 아닌 분기가 됩니다. 하나의 상태에 대한 많은 질문은 단일 패스로 해결됩니다. 그리고 출력 토큰에 대한 요금 없이 백만 입력 토큰당 0.042달러의 비용으로, 샘플링 대신 모든 이벤트에 대해 질문할 수 있습니다.
Jev를 작성자가 아닌 심판관으로 활용하기
네 가지 역할, 명확하게 분리됨:
- LLM이 생성합니다. 코드, 이메일 초안, 요약, 계획 등.
- Jev가 결정합니다. 요청을 분류하고, 위험을 평가하며, 경로를 선택하고, 미리 작성된 기준에 따라 출력을 확인합니다.
- 여러분의 코드가 제어합니다. 임계값과 규칙은 행동할지, 재시도할지, 에스컬레이션할지, 중단할지 결정합니다.
- 사람이 예외를 처리합니다. 낮은 신뢰도와 높은 이해관계의 경우 사람이 개입합니다.
이 분할이 작동하는 이유가 여기 있습니다. 언어 모델은 무엇이든 생성할 수 있기 때문에 유연하지만, 바로 그 자유로움 때문에 의존하는 워크플로우 내부에 두기에는 까다롭습니다. TypeSafe의 관점은 Jev가 "문자열 생성을 포기하고" 그 대가로 좁은 계약을 얻는다는 것입니다. 즉, 가능한 답변 세트가 요청이 서버를 떠나기 전에 고정되고, 모든 결과는 선언된 형태에 맞으며, 불확실성은 임계값과 비교할 수 있는 숫자라는 것입니다.
비용 측면도 동일한 절충점에서 나옵니다. TypeSafe는 70ms에서 500ms에 이르는 종단 간 응답 시간을 보고하며, 테스트한 워크플로우에서 193.6배 빠르고 444.6배 저렴하다고 주장합니다. 이 수치들은 독립적인 벤치마크가 아닌 공급업체 수치로 간주하세요. 구조적인 핵심은 어느 쪽이든 유효합니다. 즉, 비싼 모델은 정말로 무언가를 작성해야 할 때만 실행되며, 그 주변의 반복적인 판단은 저렴한 곳에서 실행됩니다.
Jev가 답변할 수 있는 질문 설계하기
모든 요청은 하나의 공유된 state와 독립적인 질문 세트를 포함합니다. Jev는 상태를 한 번 읽고 모든 질문에 답변합니다. 지원 티켓 분류 호출은 다음과 같습니다.
{
"model": "jev-latest",
"state": {
"message": "I've been trying to connect Stripe for three days. I'm losing sales and I need this fixed today.",
"plan": "Pro",
"account_age_months": 14,
"recent_technical_tickets": 3
},
"questions": {
"department": {
"type": "choice",
"instruction": "Which team should own this ticket?",
"criteria": {
"billing": "Payments, charges, invoices, subscription changes",
"technical": "Bugs, broken behavior, failing integrations",
"sales": "Pricing, plans, questions asked before purchase"
}
},
"frustration": {
"type": "score",
"instruction": "How frustrated is this customer?",
"criteria": [
"Calm and matter of fact",
"Frustrated but civil",
"Extremely frustrated or threatening to leave"
]
},
"urgent": {
"type": "noul",
"instruction": "The customer needs a resolution today."
}
}
}
세 가지 습관이 효과적인 질문과 그렇지 않은 질문을 구분합니다.
프롬프트 작성을 멈추세요. 페르소나, 예시, 긴 서론은 텍스트 생성기를 안내합니다. Jev는 텍스트를 생성하지 않습니다. Jev는 상태, 하나의 원자적인 질문, 그리고 각 답변이 무엇을 의미하는지에 대한 정확한 설명을 필요로 합니다. 설명적인 기준이 단순한 레이블보다 효과적입니다. 예를 들어, "결제, 청구, 인보이스, 구독 변경"은 "billing"이라는 단어 자체보다 더 잘 라우팅됩니다. 또한 Jev에게 설명을 요구하지 마세요. 응답은 결정, 확률, 신뢰도만을 포함하며 그 외에는 아무것도 없습니다.
하나의 질문, 하나의 판단. "이 리드는 가치가 있고, 긴급하며, 구매할 가능성이 높습니까?"는 트렌치코트를 입은 세 가지 질문입니다. 이들을 분리하고 코드에서 결과를 결합하세요. 그러면 가중치를 보고 변경할 수 있습니다.
산술 계산을 모델에서 제외하세요. Jev는 의미를 판단합니다. 여러분의 프로그램이 계산을 하고, 할인율을 적용하며, 계약 조건을 확인합니다. 이러한 분할 덕분에 전체 프로세스를 감사할 수 있습니다.
TypeSafe는 또한 코딩 에이전트에게 이러한 규칙을 가르치는 드롭인 스킬을 제공하며, Claude Code에서는 claude plugin marketplace add typesafe-ai/skills로, 다른 환경에서는 npx skills add typesafe-ai/skills로 설치할 수 있습니다. 자세한 내용은 에이전트 스킬 페이지에서 확인할 수 있습니다.
상태를 깔끔하게 유지하기
관련성 있는 상태가 최대 상태보다 중요합니다. 일반적으로 세 가지 섹션으로 구성됩니다. 판단 대상 객체, 해당 객체를 읽는 데 필요한 컨텍스트, 그리고 변경될 경우 결정을 바꿀 수 있는 사실들입니다. 그 외의 모든 것은 전송 비용을 지불하는 노이즈입니다.
중복된 로그 라인, 현재 문제보다 앞선 기록, 그리고 모델이 도달하기를 바라는 결론을 명시하는 문장은 모두 제거하세요. 요청당 최대 64k 토큰이며, 상태와 가장 긴 질문에 32k가 할당되지만, 이 한도에 도달하기 훨씬 전에 정확도가 변동될 수 있습니다. 라우팅이 모호해질 때, 상태를 축소하는 것이 기준을 다시 작성하는 것보다 일반적으로 더 빠른 해결책입니다.
병렬 질문 및 신뢰도 게이트
Jev는 상태를 한 번 읽기 때문에, 열세 번째 질문은 두 번째 왕복보다 훨씬 적은 비용이 듭니다. 행동을 변경할 수 있는 모든 독립적인 판단(의도, 위험, 긴급성, 감정, 관련성, 필요한 다음 단계)을 보내세요. 그리고 코드가 하는 일을 전혀 변경하지 않는 질문은 제거하세요. 사용되지 않는 신호는 아무런 이득 없이 유지보수 비용만 발생시킵니다.
판단의 형태에 맞는 기본 요소를 사용하세요. 심각도, 품질, 적합성과 같은 그라데이션은 강제적인 예/아니오 대신 score에 속합니다. 단일 사실 진술은 noul에 속합니다. 고정된 목적지 세트는 choice에 속합니다.
게이트는 아키텍처가 실제로 존재하는 곳입니다. 유형이 지정된 답변도 여전히 틀린 답변일 수 있으므로, 신뢰도가 다음에 어떤 일이 일어날지를 결정합니다. 한 가지 실용적인 시작 패턴은 다음과 같습니다: 0.85 이상에서는 자동으로 처리하고, 0.55에서 0.85 사이는 더 강력한 모델이나 두 번째 패스로 넘기며, 0.55 미만은 사람에게 할당합니다. 이러한 정확한 숫자는 예시일 뿐입니다. TypeSafe의 신뢰도 라우팅 패턴은 오답 비용을 기반으로 작업별로 별도의 임계값을 설정하며, 신뢰도 페이지에서는 "자신의 데이터로 테스트하고 결과를 관찰하면서 조정하라"고 안내합니다. 임계값이 조정되면 모델을 고정하세요. jev-latest는 최신 안정 릴리스를 따르는 반면, jev-1.13.0은 측정한 동작을 고정합니다.
Apidog에서 의사결정 레이어 테스트하기
의사결정 레이어는 그 동작 방식을 증명할 수 있을 때만 신뢰할 가치가 있습니다. 이는 일회성 curl의 터미널 기록이 아닌, 저장된 요청과 어설션을 의미합니다. Apidog는 이 두 가지를 모두 제공하며, 어설션은 문자열 대신 숫자와 열거형 값을 확인하기 때문에 일반적인 API 테스트와는 다릅니다.
키를 환경 변수로 저장하세요. TypeSafe라는 환경을 생성하고, TYPESAFE_API_KEY를 로컬 값으로 추가하여 자신의 머신에 유지되도록 한 다음, Bearer 토큰에서 {{TYPESAFE_API_KEY}}로 참조하세요. 환경 및 비밀 변수에 대한 저희 가이드에서 범위 규칙을 다룹니다.
실제 호출을 보내세요. 위에 제시된 상태-및-질문 본문을 사용하여 POST https://api.typesafe.ai/v1/systemone을 전송하세요.
결정에 대해 어설션하세요. answers.department.choice가 billing과 같고, answers.urgent.noul이 0.9보다 크며, answers.frustration.score가 1.5보다 크다는 등의 후처리 어설션을 추가하세요. 이제 동작 변경이 조용히 티켓을 잘못 라우팅하는 대신 테스트에 실패하게 됩니다.
그 다음 중요한 시나리오를 구축하세요. 라벨이 지정된 작은 상태 세트를 테스트 시나리오로 저장하세요. 예를 들어, 차분한 질문, 화난 취소 위협, 그리고 좋은 라우터라면 주저해야 할 의도적으로 모호한 메시지입니다. 처음 두 개에 대해서는 높은 신뢰도를 어설션하고, 세 번째에 대해서는 신뢰도가 게이트 아래로 떨어지는 것을 어설션하세요. 이 단일 시나리오는 임계값 조정을 추측이 아닌 증거로 바꾸며, 사람이 수동으로 알아차리기 가장 어려운 실패를 잡아냅니다. 예를 들어, 누군가 기준 설명을 다시 작성하고, 모든 응답은 여전히 유효하지만 라우팅이 조용히 변경되는 경우입니다. CI에서 실행하면 재작업으로 인해 빌드가 실패합니다.
응답 형태를 모의하세요. 프론트엔드 작업이 토큰을 소모하지 않도록 하기 위함입니다. answers 객체는 요청 전에 선언되므로, 모의 응답과 실제 응답이 서로 달라질 수 없습니다. Apidog를 다운로드하여 설정할 수 있으며, 무료 플랜은 4명으로 구성된 팀을 지원합니다.
의사결정 레이어가 가치를 발휘하는 다섯 가지 워크플로우
- 범용 검증자. 모든 고비용 LLM 호출을 감싸세요. 들어오는 프롬프트에서 주입 공격 여부, 선택된 도구의 명백한 불일치 여부, 출력물에 누락된 요구 사항이 있는지, 최종 답변이 원본 자료에서 지원되지 않는 주장을 하는지 확인하세요. 값비싼 두뇌 주변의 저렴한 검사입니다.
- 지원 관제탑. 한 번의 호출로 티켓을 분류하고, 긴급성, 불만, 환불 의도, 취소 위험을 감지한 다음 라우팅합니다. 잘못된 대기열에 있는 티켓 수를 줄이고 가치 있는 계정이 방치되는 것을 줄이는 것이 이점입니다.
- 리드 자격 평가. 회사 적합성, 기술 성숙도, 명시된 문제점, 구매 의도 및 긴급성을 별도의 신호로 점수화한 다음, 파이프라인 검토에서 소유하고 방어할 수 있는 가중치와 결합합니다.
- 모델 라우터. 요청별로 확정적 코드, 소규모 모델, 최첨단 모델 또는 사람이 처리해야 할지 결정합니다. 일반적으로 여기서 비용 절감이 가장 먼저 나타납니다.
- 대규모 데이터셋 작업. 지원 로그, 리뷰, 목록, 기록 또는 에이전트 추적 전반에 걸쳐 동일한 의미론적 판단을 실행하여 구조화된 특징을 추출하고 사람이 검토할 가치가 있는 기록의 순위를 매깁니다. 각 결정이 빠르고 거의 무료일 때만 실용적인 분석이 됩니다.
자주 묻는 질문 (FAQ)
여전히 언어 모델이 필요한가요? 네. Jev는 답변, 요약 또는 코드를 작성할 수 없습니다. 어떤 시스템이 이를 수행해야 하는지 결정하며, 정책 준수 여부나 하지 않는 약속이 답변에 포함되어 있는지와 같은 명시적인 기준에 따라 초안을 평가할 수 있습니다.
이것이 JSON 모드 또는 구조화된 출력과 어떻게 다른가요? 구조화된 출력은 텍스트 모델의 형식을 제한하지만, 모델은 여전히 토큰을 생성하며 유효한 형태 안에 거짓 주장을 할 수 있습니다. Jev는 여러분이 정의한 답변 세트에 대한 확률 분포를 반환하므로, 불확실성이 일등 시민 필드입니다. OpenAI 구조화된 출력에 대한 저희 설명서에서 그 비교의 다른 측면을 다룹니다.
어떻게 접근할 수 있나요? Jev는 대기자 명단을 통해 초기 액세스 중이므로, 아직 셀프 서비스는 아닙니다. TypeSafe는 개발자들을 배치별로 명단에서 해제하며, 완료되면 console.typesafe.ai에서 로그인할 수 있습니다. 또한 Vercel AI Gateway를 통해 AI SDK 7의 experimental_evaluate를 통해 typesafe-ai/jev로 사용할 수 있으며, 이는 SDK 전용이며 OpenAI 호환 엔드포인트에는 노출되지 않습니다. Jev API 키 얻기에 대한 저희 가이드에서 요청 및 SDK 세부 정보를 확인할 수 있습니다.
이와 같은 것을 로컬에서 실행할 수 있나요? 여러 프로젝트가 공개 가중치에 대한 제약된 디코딩을 사용하여 이 아이디어의 일부를 재현하고 있습니다. 저희는 OpenJev 및 오픈 소스 Jev 대안에서 각 프로젝트가 보정된 신뢰도에 얼마나 충실한지 포함하여 이들을 비교했습니다.
마무리
Jev는 다른 모델을 대체하는 모델이 아닙니다. Jev는 다른 모델이 언제, 어디서, 실행될지 여부를 결정하는 레이어입니다. 다음과 같이 구축하세요: 하나의 깔끔한 상태, 명시적인 기준을 가진 원자적 질문, 병렬 평가, 그리고 모든 행동 앞에 있는 신뢰도 게이트. 그런 다음, 단 하나의 실제 티켓이라도 라우팅하기 전에 Apidog에 저장된 시나리오를 통해 게이트가 작동함을 증명하세요.