사용 사례
Decisions API로 요청 라우팅
라우팅은 유한한 결정입니다: 어느 큐인가, 어떤 우선순위인가, 사람인가 자동화인가. 의사결정 호출은 선택지와 함께 모든 옵션의 확률을 반환하므로, 확신 있는 케이스는 자동 배정하고 나머지는 트리아지로 보낼 수 있습니다.
업데이트
라우팅이 자연스럽게 맞는 이유
라우팅은 유한한 질문을 합니다 — 내 큐 중 어디가 이것을 맡는가 — 그리고 그것은 의사결정 엔드포인트가 본질적으로 답하는 것입니다. 생성된 텍스트에서 큐 이름을 파싱할 필요도, 다섯 번째 큐를 지어내지 못하게 할 프롬프트 엔지니어링도 없습니다.
같은 호출에 같은 티켓에 대한 여러 질문을 실을 수 있어, 큐·긴급도·리뷰 필요 플래그를 한 번의 왕복과 1크레딧으로 해결합니다.
- 큐 배정: billing, platform, account, other
- 우선순위: 낮음부터 blocking까지의 순서 있는 스코어
- 에스컬레이션: 사람이 먼저 봐야 하는지의 noul 체크
criteria를 큐 설명으로 작성
choice 질문의 각 옵션에는 '무엇이 여기에 속하는가'의 짧은 설명을 붙입니다. 새 트리아지 담당자에게 브리핑하듯 쓰세요 — 그 설명이 곧 라우팅 정책입니다.
항상 'other' 또는 'unclear' 옵션을 넣으세요. 모델에 정직한 출구를 주면 모호한 티켓이 그럴듯하게 잘못 배정되는 것을 막습니다.
한 번의 호출: 큐 + 긴급도
티켓 텍스트를 state로 보내고 두 질문을 합니다: 담당 팀을 고르는 choice와 긴급도를 매기는 score. 응답에는 answers.team.choice, answers.urgency.score, 그리고 두 질문의 모든 옵션 확률이 들어 있습니다.
한 요청의 choice + score
// Route a ticket: ask for team + urgency in one call,
// then gate the automation on confidence.
const res = await fetch("https://decisions-api.net/api/v1/decisions", {
method: "POST",
headers: {
Authorization: "Bearer YOUR_KEY",
"Content-Type": "application/json",
},
body: JSON.stringify({
model: "decisions-1",
state: "Payments fail with a 500 since your last deploy. Enterprise plan customer.",
questions: {
team: {
type: "choice",
instructions: "Which queue should handle this request?",
criteria: {
payments: "Billing, charges, or payment failures.",
platform: "Deploys, infrastructure, or API errors.",
account: "Login, SSO, or permissions.",
other: "Unclear or out of scope.",
},
},
urgency: {
type: "score",
instructions: "How urgent is this for the customer?",
criteria: ["can wait", "normal queue", "needs attention today", "blocking revenue"],
},
},
}),
});
const { answers } = await res.json();
// Illustrative response: answers.team -> { choice: "payments", confidence: 0.84 }
// answers.urgency -> { score: 3, confidence: 0.79 } (0 = lowest level)
if (answers.team.confidence >= 0.8 && answers.team.choice !== "other") {
assignToQueue(answers.team.choice, { priority: answers.urgency.score });
} else {
assignToQueue("human_triage", { note: "low confidence" });
}confidence로 자동 배정을 게이트
확률 분포가 있어야 라우팅을 안전하게 자동화할 수 있습니다. 실용적인 기본값: confidence 0.8 이상이면 자동 배정, 미만이면 사람 트리아지 큐로.
임계값은 자신의 티켓 이력으로 조정하세요 — 잘못 배정된 티켓의 비용과 지연된 티켓의 비용 비율로 결정됩니다.
모델 사이에서 요청 라우팅
같은 패턴으로 어떤 모델이 답할지도 고를 수 있습니다. choice 질문의 옵션으로 fast_model(짧은 사실 확인이나 형식 변환 요청), strong_model(다단계 추론, 코드, 긴 컨텍스트), human(법률, 환불, 모델이 혼자 답해서는 안 되는 것)을 둡니다. 모든 옵션에 확률이 돌아오므로 배정이 얼마나 접전이었는지 알 수 있습니다.
게이트도 같은 방식입니다: 확신도가 낮으면 최상위 옵션을 믿는 대신 사람이나 더 안전한 경로로 보냅니다 — 차점 옵션의 확률이 그 판단이 얼마나 아슬했는지 보여줍니다.
비용과 볼륨
성공한 호출 한 번에 1크레딧 — 1개든 6개 질문이든 동일합니다. 과거 티켓 백로그는 대시보드 배치 도구로 같은 요청 형태를 CSV/JSONL에 적용할 수 있습니다.
FAQ
몇 개의 큐로 라우팅할 수 있나요?
choice 질문은 2~8개 옵션을 받습니다. 그보다 큐가 많으면 계층적으로: 첫 호출에서 부서를 고르고, 다음 호출에서 부서 안의 팀을 고릅니다.
같은 호출에서 긴급도도 매길 수 있나요?
네 — 순서 있는 레벨 설명의 score 질문을 추가하세요. 한 호출에 최대 6개 질문이 들어가므로 큐, 긴급도, 에스컬레이션 플래그를 함께 해결합니다.
애매한 티켓은 어떻게 되나요?
답변에는 모든 옵션의 확률이 들어 있습니다. 상위 두 옵션이 비슷할 때 — 예: 0.45 대 0.42 — 모호한 것으로 보고 승자를 믿지 말고 사람 트리아지로 보내세요.
영어가 아닌 티켓도 되나요?
state와 옵션 설명은 티켓의 언어 그대로 쓰고, 옵션 키만 ASCII로 유지하면 라우팅 코드가 읽기 쉽습니다.
어떤 LLM이 요청에 답할지 선택할 수 있나요?
네 — 모델들을 choice 질문의 옵션으로 만들고 각각이 무엇을 잘하는지 설명하세요. 확신도가 낮은 경우는 더 강한 모델로 라우팅하세요.
지금 티켓을 라우팅하세요
신규 방문자 무료 체험 1회 — 실제 티켓을 플레이그라운드에 붙여넣고 확률을 읽어보세요.