좋은 핏제한된 결정을 위해 Jev를 사용하세요
- 하나의 요청을 하나의 명명된 대기열로 라우팅합니다.
- 순서화된 위험 또는 품질 척도에 따라 기록을 남깁니다.
- 명확하게 명시된 조건 중 하나가 참인지 추정합니다.
잘 맞지 않음대신 생성 모델을 사용하세요
- 개방형 텍스트를 작성, 요약, 번역 또는 다시 작성합니다.
- 자연스러운 다단계 대화를 나눠보세요.
- 유효한 출력의 이름을 미리 지정할 수 없는 경우 답변을 작성하십시오.
공식 정신 모델
STATE평가할 상태 1개
판단에 필요한 텍스트 및 관련 사실이 포함된 문자열, 개체 또는 배열을 전달합니다. 대부분의 실제 요청에는 명명된 개체 필드를 사용합니다.
QUESTIONS질문 당 하나의 즉각적인 판단
각 질문은 지식이 풍부한 사람이 제공된 상태에서 신속하게 판단할 수 있는 하나의 집중된 사항을 질문해야 합니다.
PARALLEL병렬적인 독립적인 질문
한 요청의 질문은 동일한 상태를 확인하고, 독립적으로 실행되며, 한 답변을 다른 답변으로 유출하지 않습니다.
CODE코드로 답변 작성
하나의 프롬프트에 워크플로 논리를 숨기는 대신 일반 코드에 가중치, 임계값, 분기 및 입력된 답변을 결합합니다.
분해 테스트: 판단에 여러 가지 독립적인 요소가 중요하거나 확장된 추론이 필요한 경우 이를 원자성 질문으로 분할하고 답변을 코드로 결합하세요.
이 장 이후:콘텐츠 생성 작업과 구조화된 의사결정 작업을 분리할 수 있습니다.
공식 참고자료: Introduction · State · Primitives
| 유형 | 당신은 공급 | 당신은 받는다 | 다음과 같은 경우에 사용하세요. |
choice | 명명된 옵션 → 설명 | 선택된 키 + 옵션별 확률(+ 신뢰도) | 상호 배타적인 라벨/경로 |
score | 정렬된 수준(2~10), 낮음 → 높음 | 확률 가중 레벨 점수 + 단계 문제 | 심각도, 품질, 위험 기준표 |
noul | 예/아니요 제안(+ 선택 기준) | 사실일 확률 | 단일 사실 확인 |
choice최대 255개 옵션
승자와 전체 배포
순서가 지정되지 않은 고정된 대안에 사용합니다. 목록에 모든 주가 포함되지 않을 경우 기타/없음을 추가하세요. 선택한 값은 확률이 가장 높은 옵션입니다.
{
"choice": "technical",
"probabilities": { "technical": 0.85, "billing": 0.15 },
"confidence": 0.78
}
score2~10개의 정렬된 수준
확률 가중 위치
레벨은 0부터 색인화됩니다. 점수는 레벨 확률 전체의 가중 평균이므로 두 레벨 사이에 속할 수 있습니다.
{
"score": 1.43,
"probabilities": { "0": 0.0, "1": 0.57, "2": 0.43 },
"confidence": 0.35
}
noul0 = 아니요 · 1 = 예
어떤 진술이 참일 확률
깨끗한 예/아니요 판단을 위해 사용하세요. 0.5에 가까울수록 속성의 중간 정도가 아니라 불확실성을 의미합니다. Noul에는 별도의 신뢰 필드가 없습니다.
{
"type": "noul",
"noul": 0.95
}
점수는 정확성이 아닙니다. 0~2 기준표에서 1.5점은 예상 수준이며 "75% 정확"이 아닙니다. Score 또는 Choice 신뢰도를 정확성 약속으로 취급하지 마십시오.
이 장 이후:라우팅, 조정 및 위험 점수에 대한 정답 형태를 선택할 수 있습니다.
공식 참고자료: Choice · Score · Noul
강력한 기준 작성
- 분리된 옵션. 두 개의 선택 키가 모두 참일 수 있는 경우 운영자는 모델과 싸울 것입니다.
- 모서리를 설명합니다. buy_intent에 포함된 것(재고, 배송지)과 가격_질문을 말해보세요.
- 잔여물을 마지막에 유지하세요. 게으른 잡기 도구가 아닌 다른 사람/인간을 탈출구로 사용하십시오.
- 주문 점수 오름차순. 기준 배열은 가장 낮음 → 가장 높습니다.
- 질문당 하나의 결정을 내립니다. "긴급"에서 "경로"를 별도의 키로 분할합니다.
질문의 분석
question_id코드에 대한 응답 조회 키입니다. 모델로 전송되지 않으므로 지침에는 완전한 질문이 포함되어야 합니다.
type선택, 점수 또는 Noul. 코드가 직접 작동할 수 있는 모양을 선택하세요.
instructions완전하고 구체적인 판단. 문자열, 개체 또는 배열일 수 있으며 명명된 상태 경로를 참조할 수 있습니다.
criteriaNoul에 대한 선택 옵션, 정렬된 점수 수준 또는 선택적 참/거짓 설명.
예 · 하나의 결정, 분리된 경계
route: {
type: 'choice',
instructions: 'Route this ticket to one queue.',
criteria: {
tech: 'Bugs, outages, API failures, or integrations',
sales: 'Pricing, plans, demos, or new-purchase intent',
billing: 'Charges, invoices, receipts, or subscriptions',
human: 'Ambiguous, sensitive, legal, or multi-issue'
}
}
구조 상태 및 참조 정확한 필드
명명된 상태 필드에 증거를 보관하고 점 및 인덱스 경로를 사용하여 해당 필드에 지침을 지정하세요. 이렇게 하면 어떤 텍스트, 기록 또는 정책이 답변을 제어해야 하는지에 대한 모호함이 줄어듭니다.
const state = {
ticket: {
message: 'I was charged twice. Please refund the duplicate.',
orderId: 'A-104'
},
order: { charges: [49, 49] },
refundPolicy: 'Duplicate charges are eligible for a refund.'
};
const questions = {
refund_requested: {
type: 'noul',
instructions: 'Does `ticket.message` request a refund?'
},
policy_supports_refund: {
type: 'noul',
instructions: 'Does `refundPolicy` support the request given `order.charges`?'
}
};
기본적으로 배치: 하나의 요청에서 동일한 상태를 사용하는 모든 질문(추론적인 질문 포함)을 물어보세요. 상태나 옵션이 실제로 이전 답변에 의존하는 경우에만 두 번째 요청을 하세요.
이 장 이후:코드에서 사용할 수 있는 안정적이고 테스트 가능한 질문 정의를 작성할 수 있습니다.
공식 참고자료: Primitives · State
공식 HTTP 엔드포인트로 시작
서버에 TYPESAFE_API_KEY를 유지하세요. 이름이 지정된 질문의 상태, 모델 및 맵을 POST /v1/systemone.로 보냅니다.
curl -X POST https://api.typesafe.ai/v1/systemone \
-H "Authorization: Bearer $TYPESAFE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"state": "Stripe has failed for 3 days. I am losing sales.",
"model": "jev-latest",
"questions": {
"department": {
"type": "choice",
"instructions": "Which team should handle this?",
"criteria": {
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions"
}
},
"is_urgent": {
"type": "noul",
"instructions": "Does this message convey urgency?"
}
}
}'
입력된 답변 및 재시도를 위해 공식 SDK를 사용하세요.
Python SDK는 환경에서 TYPESAFE_API_KEY를 읽고, 기본값은 jev-latest이고, 형식화된 질문/답변 클래스를 노출하고, 기본 재시도 정책을 적용합니다.
pip install typesafe-sdk
from typesafe_sdk import Choice, Noul, TypeSafeClient
with TypeSafeClient() as client:
response = client.system_one(
state={"message": "Stripe has failed for 3 days.", "impact": "Losing sales"},
questions={
"department": Choice(
instructions="Which team should handle this?",
criteria={
"billing": "Payment or subscription issues",
"technical": "Bugs or integration problems",
"sales": "Pricing or account questions",
},
),
"is_urgent": Noul(
instructions="Does `message` and `impact` convey urgency?"
),
},
)
department = response.answers["department"]
print(department.choice, department.confidence)
print(response.answers["is_urgent"].noul)
질문 ID 아래의 각 답변을 읽어보세요.
{
"model": "jev-1.13.0",
"answers": {
"department": {
"type": "choice",
"choice": "technical",
"confidence": 0.78,
"probabilities": { "technical": 0.85, "billing": 0.15, "sales": 0.0 }
},
"is_urgent": { "type": "noul", "noul": 0.95 }
},
"usage": { "input_tokens": 392, "output_tokens": 54 }
}
전체 오류 표면 처리
401API 키가 누락되었거나 잘못되었습니다. Bearer 토큰을 확인하세요.
422요청 형태가 잘못되었습니다. 문제가 있는 필드에 대한 응답을 검사합니다.
429비율 제한을 초과했습니다. 다시 시도하기 전에 물러나세요.
529서비스가 일시적으로 과부하되었습니다. 다시 시도하기 전에 물러나세요.
429 및 529의 경우 즉각적인 재시도보다는 지수 백오프를 사용합니다. 공식 SDK는 기본 재시도 정책에 따라 이 작업을 자동으로 수행합니다.
대안: Vercel AI 게이트웨이
이 사이트에는 AI SDK 평가를 위한 액세스 계층으로 게이트웨이도 문서화되어 있습니다. 이는 Jev 또는 TypeSafe의 일부가 아닌 대체 통합 경로입니다.
import { experimental_evaluate as evaluate } from 'ai';
import { gateway } from '@ai-sdk/gateway';
const result = await evaluate({
model: gateway('typesafe-ai/jev'),
state,
questions,
});
이 장 이후:자격 증명을 서버 측에 유지하고 확률에 따라 입력된 답변을 받을 수 있습니다.
공식 참고자료: Quick start · API reference · SDKs
PROBABILITY모든 옵션이나 레벨에 대한 증거
Choice 및 Score는 전체 분포를 반환합니다. 차점 옵션, 모호성 또는 사용자 정의 불확실성 측정이 중요한 경우 이를 사용하십시오.
CONFIDENCE분포 형태 요약
신뢰도는 분포가 얼마나 집중되어 있는지 또는 평평한지 0-1로 압축합니다. 선택한 옵션 확률과 동일하지 않습니다.
Noul: Noul은 이미 P(true)를 반환하므로 별도의 신뢰도가 없습니다. 0.5에 가까운 값은 불확실합니다. 위험에 따라 예와 아니오 측면 모두에 임계값이 적용됩니다.
TypeSafe는 옵션 배포에 대한 신뢰를 드러냅니다. 실질적인 정책은 다음과 같습니다.
01높은 신뢰도
UI에서 선택 사항(태그, 경로 또는 평결)을 자동으로 제안합니다.
02중간 신뢰도
제안을 표시하되 계속하기 전에 교환원에게 확인을 요청합니다.
03낮은 신뢰도
기본 작업 없이 인간 대기열로 보냅니다.
스트림이나 받은 편지함에서 라벨이 지정된 예시의 컷오프를 보정하세요. 임계값은 사용 사례에 따라 다릅니다. 제안을 금전으로 연결하거나 부작용을 환불하지 마십시오.
전역적으로 모델이 아닌 작업에 대한 임계값 지정
action = response.answers["action"]
if action.confidence < 0.5:
route_to_human(state) # uncertain: do not guess
elif action.choice == "check_balance":
show_balance(account_id) # reversible, low stakes
elif action.choice == "approve_transfer":
if action.confidence > 0.9:
confirm_then_execute(account_id)
else:
ask_user_to_confirm(account_id) # higher stakes, higher bar
자동화 전 교정
- 실제 워크플로에서 대표적이고 라벨이 붙은 예시를 수집하세요.
- 답변, 분포, 신뢰도, 대기 시간 및 사람의 결정을 기록합니다.
- 되돌릴 수 있는 작업, 비용이 많이 드는 작업, 되돌릴 수 없는 작업에 대해 별도로 임계값을 선택합니다.
- 상태, 지침, 기준 또는 모델 별칭을 변경한 후 드리프트를 모니터링하고 재평가합니다.
상태 팁문자열, 객체 또는 배열을 상태로 전달합니다. 하나의 메시지만 중요한 경우 전체 채팅 로그를 덤프하는 것보다 구조화된 기록(댓글 텍스트 + 메타데이터)을 선호합니다.
이 장 이후:신뢰도가 낮은 폴백을 설계하고 레이블이 지정된 데이터로 임계값을 보정할 수 있습니다.
공식 참고자료: Confidence
하나의 완전한 지원 분류 워크플로 구축
하나의 구조화된 티켓 상태를 보내고 세 가지 독립적인 질문을 동시에 질문하세요. 라우팅 및 안전 정책을 코드로 유지하세요.
STATE→CHOICESCORENOUL→POLICY
const questions = {
department: {
type: 'choice',
instructions: 'Which team should handle `ticket.message`?',
criteria: {
returns: 'Exchanges, wrong or damaged items',
shipping: 'Delivery status, delays, or lost packages',
billing: 'Charges, invoices, or payment problems',
other: 'None of the above'
}
},
frustration: {
type: 'score',
instructions: 'How frustrated is the customer?',
criteria: ['Calm', 'Concerned but civil', 'Very angry']
},
refund_requested: {
type: 'noul',
instructions: 'Does `ticket.message` request money back?'
}
};
입력된 답변을 감사 가능한 결정으로 전환
const department = result.answers.department;
const frustration = result.answers.frustration;
const refundProbability = result.answers.refund_requested.noul;
if (department.confidence < 0.5) {
return { action: 'manual_triage', reason: 'uncertain_department' };
}
const flags = [];
if (frustration.score > 1.4) flags.push('senior_agent');
if (refundProbability > 0.75) flags.push('refund_review');
return {
action: 'route',
team: department.choice,
flags,
evidence: {
departmentProbabilities: department.probabilities,
frustrationScore: frustration.score,
refundProbability
}
};
생산 체크리스트
- 자격 증명과 모델 호출을 서버 측에 유지합니다.
- API를 호출하기 전에 상태 크기, 필수 필드, 질문 정의를 확인하세요.
- 모델 버전, 질문 버전, 확률, 신뢰도, 최종 조치를 저장합니다.
- 명시적인 다른/인간 경로를 제공하고 불확실성에 대한 기본값을 만들지 마십시오.
- 제한된 지수 백오프를 사용하여 429 및 529를 재시도합니다. 유효성 검사 오류를 다시 시도하지 마세요.
- 자동화를 활성화하기 전에 레이블이 지정된 엣지 케이스를 테스트하고 임계값을 재보정하세요.
Case index
Six Jev patterns to explore next
These are research paths, not claims that this site built the projects. Each card opens the corresponding category in the open-source radar so you can inspect real implementations and source evidence.
01 CHOICE Jev model and agent routing
Choose a model, tool, skill, or queue from a bounded catalog; keep budget and fallback policy in code.
Browse sourced projects ↗ 02 CHOICE + NOUL Jev content moderation
Classify a record into allow, block, or review, then use a separate true/false check for a specific policy violation.
Browse sourced projects ↗ 03 SCORE + NOUL Jev MCP guardrails
Score proposed tool-call risk and gate irreversible actions behind an explicit human confirmation step.
Browse sourced projects ↗ 04 CHOICE Jev browser action selection
Choose the next action from controls extracted by an accessibility tree while another system observes and executes.
Browse sourced projects ↗ 05 SCORE + NOUL Jev code review and evaluation
Evaluate a diff against named rules, retain probabilities, and route uncertain findings to a reviewer.
Browse sourced projects ↗ 06 CHOICE + SCORE Jev support-ticket routing
Combine department Choice, frustration Score, and refund-request Noul without giving the model permission to issue money.
Browse sourced projects ↗ 이 장 이후:전체 워크플로우를 하나의 작은 결정 작업으로 전환할 수 있습니다.
공식 참고자료: Patterns · Primitives
더 깊이 들어가세요
보충 자료
핵심 과정을 마친 후에는 필요에 따라 공식 참고 자료, 공개 데모, 커뮤니티 디렉터리를 사용하세요.
공식 참고자료 및 스타터 7
공개 데모 4
커뮤니티 디렉토리 5