입력은 딱 두 가지 — 상태(state)와 질문(questions). JSON과 LangChain으로 직접 불러본다
💡 "무엇을 볼지(state)"와 "무엇을 물을지(questions)"를 분리한 게 전부입니다. 나머지는 JEV가 알아서 병렬로 채웁니다.
고객 메시지 원문을 state에 그대로 넣고, "긴급한가?"를 noul 질문 하나로 던집니다. 아래가 그 실제 요청(JSON)과 응답입니다.
// 상태 하나 + noul 질문 하나 { "state": "Hi, I've been trying to connect my Stripe account for 3 days...", "questions": { "is_urgent": { "type": "noul", "instructions": "The message conveys urgency or time-sensitivity" } } }
{
"is_urgent": { "noul": 0.999 }
}
아래 코드는 앞의 JSON 호출을 파이썬 객체로 옮긴 것입니다 — 분류기를 만들고, state와 questions를 넘기고, 답을 꺼내는 세 단계가 전부입니다.
from langchain_typesafe import Noul, TypeSafeClassifier
classifier = TypeSafeClassifier()
response = classifier.invoke({
"state": "The deploy failed twice and customers are seeing 500s...",
"questions": {
"urgent": Noul(instructions="Does this need attention now?")
}
})
urgency = response.nouls["urgent"].noul # → 0~1 사이 확률
Choice·Score·Noul을 한 요청에 섞어 넣으면 모두 같은 상태를 공유하며 병렬로 평가됩니다. 그래서 질문을 1개에서 여러 개로 늘려도 응답 시간은 거의 변하지 않고, 추가 비용은 토큰뿐입니다.
병렬 평가라 막대가 거의 늘지 않습니다. LLM으로 질문을 순차 처리하면 개수에 비례해 폭증합니다.
# 응답의 confidence로 곧장 분기
if response.nouls["urgent"].noul > 0.9:
route_to_oncall() # 확신 높으면 자동 처리
3-3강에서는 이제 질문을 어떻게 설계하느냐로 들어갑니다. 하나의 크고 복잡한 질문 대신, 왜 여러 개의 원자적 질문으로 쪼개고 코드에서 합성해야 하는지 — 그리고 confidence를 이용한 에스컬레이션 패턴까지 살펴봅니다.