TypeSafe Jev 7/10: 스펙트럼 위치와 확률을 Score로 읽는 법 | DAKER 커뮤니티
콘텐츠를 단순히 맞다, 틀리다로 나누기 어려운 경우가 있습니다. 버그의 심각도나 고객의 감정처럼 순서가 있는 스펙트럼 위에서 위치를 판단해야 할 때가 그렇습니다. 이 글은 TypeSafe Jev 시리즈 7/10으로, 이런 상황에서 Score를 어떻게 이해하고 써야 하는지 정리합니다.
특히 score와 confidence를 함께 읽는 법, 그리고 수준 설명을 어떻게 써야 모델이 덜 흔들리는지가 핵심입니다. 문서의 개념을 그대로 따라가되, 실무에서 바로 떠올릴 수 있게 구조를 다듬었습니다.
Score는 언제 쓰는가
Score는 순서 있는 서술 수준(levels)에 대해 콘텐츠를 평가하는 질문 유형입니다. 답에는 score, 수준별 확률, confidence가 포함됩니다.
답이 스펙트럼 위의 위치이고, 각 단계를 말로 설명할 수 있을 때 Score를 씁니다.
예를 들면 버그 심각도, 고객 감정, 경험치 같은 항목이 여기에 들어갑니다. 반대로 순서 없는 카테고리라면 Choice, 예/아니오 판단이라면 Noul이 더 맞습니다.
요청 구조는 어떻게 생겼는가
Score 요청은 세 가지 요소로 구성됩니다. 무엇을 평가하는지, 그리고 그 평가를 어떤 수준들로 나눌지를 분명하게 적는 방식입니다.
type:"score"instructions: 무엇을 평가하는지criteria: 낮은 끝부터 높은 끝까지의 수준 설명 배열(최소 2, API 상한 10)
수준 번호는 배열 위치를 따르며 0부터 시작합니다. 모델은 설명만 보고 각 수준을 state에 대해 따로 판단합니다.
score와 confidence는 함께 읽어야 한다
score는 수준 번호의 확률 가중 평균입니다. 문서 예시처럼 확률이 0→0.0, 1→0.57, 2→0.43이라면 계산은 다음과 같습니다.
score = 0×0 + 1×0.57 + 2×0.43 = 1.43
이 값은 두 수준 사이에 떨어질 수 있습니다. 그래서 정수 하나만 보고 딱 잘라 해석하면 놓치는 부분이 생깁니다.
같은 score라도 확률 분포가 다를 수 있으니 probabilities와 함께 보는 것이 좋습니다.
confidence는 분포가 한 수준에 모이면 높고, 여러 수준에 퍼지면 낮아집니다. 즉, 평균값이 비슷해 보여도 모델이 얼마나 확신하는지는 전혀 다를 수 있습니다.
좋은 수준 설명은 어떻게 쓰는가
수준 설명은 모호한 정도 표현보다 상황을 드러내는 문장으로 쓰는 편이 좋습니다. 예를 들어 적당히 심각이라고 쓰기보다 기능은 깨졌지만 우회가 있음처럼 적는 방식입니다.
모델은 이웃 수준 번호나 이전보다 나쁨 같은 상대적 힌트를 보지 않습니다. 그래서 숫자만 criteria에 넣으면 문서 예시처럼 확률이 갈라질 수 있습니다.
한 Score는 한 차원만 측정할 때 가장 안정적으로 작동합니다.
시간 엄수이고 똑똑하고 경험 많음처럼 여러 차원을 한 수준에 묶으면 배치가 어려워지고 confidence도 떨어집니다. 이런 경우에는 차원별로 나누는 편이 낫습니다.
복합 판단은 여러 Score로 나누는 편이 낫다
심각도, 좌절감, 리포트 품질처럼 서로 다른 축이 섞여 있다면 각각 따로 묻고, 코드에서 정규화한 뒤 가중 합으로 우선순위를 만드는 방식이 적합합니다.
원문에서 제시한 정규화 식은 score / (len(criteria)-1)입니다. 가중치는 코드에 두고, 팀의 실제 판단과 맞지 않으면 계수만 조정하면 됩니다. 이것이 Composite scoring 패턴입니다.
이웃 수준이 자주 헷갈린다면
수준 간 경계가 자주 흔들린다면 각 수준을 객체로 바꾸고, 커버 범위와 예시 상황을 같은 필드 이름으로 맞추는 방법을 생각해볼 수 있습니다. 예시는 실제 입력과 비슷할 때만 도움이 됩니다.
참고 자료
이전: 6/10 고정 옵션에서 하나 고르기 · 다음: 8/10 yes 확률 하나면 충분
여러분이 쓰고 있는 업무 루브릭 가운데, Score로 다시 나눠 보면 더 명확해질 항목은 무엇인가요?