TypeSafe Jev 시리즈 5/10 — Choice·Score·Noul, 세 가지 질문 유형 정리 | DAKER 커뮤니티

질문을 잘게 나누는 일은 자동화의 정확도를 좌우합니다. 특히 모델이 무엇을 판단해야 하는지 분명히 정해 두면, 응답을 다시 해석하느라 생기는 비용을 줄일 수 있습니다.

이번 글은 TypeSafe Jev의 Primitives(Questions)에서 다루는 세 가지 질문 유형, Choice·Score·Noul을 정리합니다. 각각이 어떤 답을 돌려주는지, 언제 어떤 유형을 고르면 좋은지, 여러 질문을 한 번에 묻는 방식까지 함께 살펴봅니다.

질문–답 쌍이 기본 단위입니다

질문은 state에 대한 하나의 판단을 정의하고, 답은 그에 대응하는 타입 있는 값으로 돌아옵니다. 이렇게 받은 답을 코드에서 조합해 최종 결정을 만들면 됩니다.

질문 하나는 판단 하나를 담고, 답은 코드에서 바로 쓸 수 있는 타입 있는 값으로 돌아옵니다.

Primitives(Questions)에서 다루는 유형은 세 가지입니다.

• Choice — 이 옵션들 중 어느 것인가를 묻고, choice, probabilities, confidence를 반환합니다.

• Score — 어느 수준인가를 묻고, score, legend, probabilities, confidence를 반환합니다.

• Noul — 이것이 참인가를 묻고, noul (0–1)을 반환합니다.

한 질문은 한 번에 판단할 수 있는 크기가 좋습니다

좋은 질문은 지식 있는 사람이 맥락만 보면 바로 판단할 수 있는 형태입니다. 예를 들어 이 메시지가 긴급한가 같은 질문은 한 번에 답하기 좋습니다.

반대로 분석하고 최선의 조치를 정해라처럼 느린 추론이 필요한 요청은 작은 질문으로 나누는 편이 좋습니다. 그런 다음 코드에서 답을 합쳐 결정을 만드는 방식이 더 안정적입니다.

느린 추론이 필요한 큰 문제는 작은 질문으로 쪼개고, 조합은 코드에서 하는 것이 좋습니다.

질문 정의에는 네 가지 필드가 들어갑니다

질문을 정의할 때는 다음 필드를 사용합니다.

• ID — 예: refund_requested. 응답에서 답을 찾는 키이며, 모델에는 전달되지 않습니다.

• type — choice / score / noul

• instructions — state에 대해 무엇을 묻는지 적는 부분으로, 평가 로직이 들어갑니다.

• criteria — Choice의 옵션 맵, Score의 수준 목록, Noul의 yes/no 설명을 담는 선택 항목입니다.

ID가 충분히 분명해 보여도, instructions에는 완전한 질문을 적는 것이 중요합니다.

Choice·Score·Noul은 이렇게 고르면 됩니다

Choice: 정해진 항목 중 하나를 고를 때

Choice는 순서가 없는 알려진 집합에 적합합니다. 예를 들어 부서 라우팅, 문서 유형, 언어 감지처럼 결과가 미리 정해진 목록 안에 있을 때 쓰기 좋습니다.

목록이 완전하지 않을 수 있다면 other 또는 none of the above를 두는 것이 좋습니다.

Score: 스펙트럼 위의 수준을 나눌 때

Score는 연속적인 정도를 몇 개의 수준으로 정의해 판단할 때 적합합니다. 버그 심각도, 좌절감, 숙련도처럼 각 지점의 의미를 함께 설명해야 하는 경우에 잘 맞습니다.

Noul: 예/아니오와 그 확률이 중요할 때

Noul은 yes/no 자체와 그 확률이 신호가 되는 경우에 적합합니다. 예를 들어 PII 포함 여부나 환불 요청 여부처럼 참인지 아닌지를 보고 싶을 때 유용합니다.

여기서 주의할 점도 있습니다. 파이썬에 강한가를 Noul로 물었을 때 0.5는 중간 숙련도를 뜻하지 않습니다. yes와 no의 가능성이 비슷하다는 뜻입니다. 숙련도처럼 수준을 재고 싶다면 Score로 정의해야 합니다.

Noul의 0.5는 중간 수준이 아니라 yes/no가 비슷한 확률이라는 뜻입니다.

답은 제한된 값으로 돌아오고, 서로 독립적입니다

이 질문 유형들의 장점은 답이 여러분이 준 옵션이나 수준 안으로만 제한된다는 점입니다. 그래서 생성된 산문에서 값을 다시 복구할 필요가 없습니다.

또한 각 답은 서로 독립적입니다. 질문을 추가하거나 삭제해도 다른 답의 숨은 컨텍스트가 되지 않습니다.

같은 state를 본다면 여러 질문을 한 번에 묻는 편이 좋습니다

같은 state를 사용하는 질문은 한 요청에 함께 넣을 수 있습니다. 이때 질문 유형을 섞어도 됩니다.

필요할지도 모르는 추측(speculative) 질문도 같이 넣어 두고, 실제로는 코드가 필요한 답만 골라 쓰면 됩니다. 문서의 Parallel questions 쿡북은 13질문을 한 번에 넣는 편이 별도 13회보다 훨씬 싸고 빠르며 답이 같다고 보고합니다.

다만 한 답이 다른 질문의 입력이 되어야만 하는 경우에는 두 번째 요청이 필요합니다. 그렇지 않다면 함께 묻고, 코드에서 필요 없는 답을 무시하는 방식이 더 단순합니다.

한 답이 다음 질문의 입력이 되는 경우가 아니라면, 함께 묻고 코드에서 필요한 답만 고르는 편이 좋습니다.

마무리

업무에서 자주 하는 판단 하나를 골라 Choice, Score, Noul 중 무엇이 맞는지 나눠 보면 이 구조가 금방 익숙해집니다. 그다음 ID, instructions, criteria를 짧게 적어 보면 실제 적용 지점도 더 선명해집니다.

참고 자료

Primitives (Questions) (.md)

이전: 4/10 평가할 재료를 한곳에 · 다음: 6/10 고정 옵션에서 하나 고르기

여러분은 실제 업무 판단을 Choice·Score·Noul 가운데 어떤 방식으로 가장 자주 나누게 될 것 같나요?