Jev 신뢰도
확률을 실행, 검토 또는 상향 처리 기준으로 바꾸세요.
Choice와 Score 답변에는 확률 분포와 0~1 범위의 confidence 통계가 포함됩니다. Noul에는 포함되지 않습니다. Confidence은 분포의 형태에서 산출됩니다. 한 결과에 집중되어 있으면 확신도 높은 답변이고, 넓게 퍼져 있으면 불확실한 답변입니다. TypeSafe가 confidence를 계산하므로 직접 계산하지 않고도 임곗값을 적용할 수 있지만, 다른 통계를 쓰려는 경우를 위해 전체 확률도 항상 제공됩니다. 코드는 이 수치에 따라 실행, 검토 또는 상향 처리해야 합니다.
Confidence은 확률에서 산출됩니다
Choice에서 분포는 각 옵션에 대한 확률입니다. Score에서는 각 수준에 대한 분포입니다. 분포가 평평할수록 confidence이 낮습니다. Choice에서 confidence이 낮다면 뚜렷한 승자가 없는 경우가 많습니다. Score에서 confidence이 낮다면 수준이 모호하거나 다차원적이거나, state에 판단할 정보가 부족한 경우가 많습니다.
TypeSafe는 confidence을 편리한 기본값으로 제공할 뿐 사용을 강제하지 않습니다. 결정의 성격에 따라 분포를 다른 방식으로 단일 통계로 축약하는 편이 더 나을 수 있습니다. 문서에서는 이런 방법을 별도 쿡북에 정리하며, 하나의 공식에 얽매이지 않도록 모든 Choice 및 Score 답변에 확률을 계속 제공합니다.
Noul 답변은 [0, 1] 범위의 noul만 제공하며 그 이상은 없습니다. Noul에 복사할 confidence 필드는 없습니다. 0.5에 가까운 값은 모델이 해당 예/아니요 질문을 확정하지 못했다는 뜻입니다. 0.5를 "중간 수준의 환불 강도"로 해석하지 마세요. Choice의 confidence 임곗값을 noul에 그대로 적용하지 말고, 별개 질문 두 개에서 P(noul) + P(not noul)이 1이 될 것이라고 기대해서도 안 됩니다.
코드의 세 가지 처리 경로
유용한 시작 패턴은 세 구간입니다. 높은 confidence: 자동 실행합니다. 중간 confidence: 주의해서 진행합니다. 사용자에게 확인하거나, 검토 대상으로 표시하거나, state를 더 수집하세요. 낮은 confidence: 실행하지 않습니다. 담당자에게 넘기거나, 명확히 하기 위한 질문을 하거나, 다른 시스템으로 대체하세요. 경계선은 위험 수준에 따라 정해야 합니다.
confidence 임곗값 하나를 제품 전체에 적용해서는 안 됩니다. 의도를 잘못 판단해 잔액 화면을 표시하는 것은 복구할 수 있지만, 출금을 승인하는 것은 그렇지 않습니다. TypeSafe 예시에서는 실제 불확실성의 하한을 0.5로 나누고, 송금은 확인 후 실행하기 전에 >0.9를 요구하지만 잔액 확인 의도는 더 낮은 기준으로 진행할 수 있습니다. 위험 허용도는 코드에 반영됩니다. Jev는 분포만 보고합니다.
지능형 시스템이 불확실성을 정직하게 표현하지 못한다면 신뢰할 수 없습니다. Confidence은 Choice과 Score에서 이를 나타내는 신호입니다. 문자 그대로의 표현, 코드로 하는 계산, 생성 불가라는 jaggedness의 한계와 함께 고려하세요. 잘못 작성된 지침에 대한 높은 confidence의 Choice도 결국 엉뚱한 질문에 자신 있게 답한 것뿐입니다.
같은 티켓에서의 Noul와 Choice 비교
상식적 불변 조건을 다룬 TypeSafe의 jaggedness 기록에는 "핏이 마음에 들지 않습니다. 어떤 선택지가 있나요?"라는 문의가 나옵니다. "고객이 환불을 요청하고 있는가?"라는 Noul의 결과는 0.22였습니다. 같은 문구에 대한 예/아니요 Choice은 예 0.01 / 아니요 0.99의 확률과 confidence 0.97을 반환했습니다. 비교 대상은 noul과 probabilities["yes"]이며, 둘을 서로 바꿔 쓸 수는 없습니다.
두 번째 티켓에서는 환불과 환불 아님을 묻는 Noul 두 개의 합이 1.19였습니다. 별개 질문 사이에 산술 항등식이 성립한다고 모델에 요구하지 마세요. 옵션에 대한 Choice은 상대적입니다. 즉 어느 옵션인지를 고릅니다. 각 Noul는 절대적이며 모든 옵션에서 낮을 수 있습니다. 기술 추천 쿡북은 둘 다 사용합니다. Choice로 기술을 고르고, Noul로 기술을 아예 추천할지 결정합니다.
판정 게이트를 연결할 때는 임곗값 표에 프리미티브 이름을 적으세요. department에 대한 0.8 Choice confidence인지, urgency에 대한 0.8 Noul인지 명시하지 않으면 "0.8"은 아무 의미가 없습니다. 프리미티브, 키, 원시 확률, 버전 지정 모델 ID jev-1.13.0을 기록해 두면 이후 별칭이 변경되어도 프로덕션 게이트가 조용히 재조정되는 일을 막을 수 있습니다.
판정 게이트 운영
argmax와 confidence 스칼라만 저장하지 말고 전체 확률을 저장하세요. Choice가 잘못된 것처럼 보일 때는 2순위 옵션이 디버깅 단서가 되는 경우가 많습니다. Score가 수준 사이에서 막힌 듯 보일 때는 분포를 통해 범례가 모호한지, state가 비어 있는지 알 수 있습니다.
모델 ID가 바뀔 때마다 다시 조정하세요. jev-latest는 변할 수 있습니다. jev-1.13.0의 임곗값 0.9가 다음 공식 릴리스에서도 같은 의미라는 보장은 없습니다. 프로덕션 별칭을 전환하기 전에 새 ID였다면 어떤 결과가 나왔을지 일주일간 섀도 로그로 기록하세요.
위험도가 높은 작업은 레이블과 confidence 하한을 모두 충족한 뒤 제품 차원의 확인까지 거쳐야 합니다. TypeSafe의 송금 예시는 불확실성 하한으로 0.5를, 실행 전 기준으로 0.9를 사용합니다. 구조를 참고하되 수치까지 그대로 복사할 필요는 없습니다. 환불 정책과 게임 이용 정지 정책에 같은 임곗값을 쓸 수는 없습니다. 운영 절차서에서 프리미티브 이름 옆에 수치를 적으세요.
당직 담당자에게 확률을 숨기지 마세요. 초록색/빨간색 confidence만 표시하는 대시보드로는 confidence가 계속 높게 유지되는 동안 yes와 no가 뒤바뀐 사실을 알 수 없습니다. 핵심 산출물은 분포이며, 스칼라는 TypeSafe가 그 위에서 계산하는 편의값입니다.
0.5에 가까운 Noul은 예/아니요 질문에 솔직하게 "모르겠다"고 답한 것입니다. 여기에 붙일 confidence 필드는 없습니다. 두 번째 축이 필요하다면 질문을 하나 더 하거나, 명시적인 기준과 함께 yes/no/not-sure에 대한 Choice를 추가하세요. 단, 이는 noul과 다른 통계라는 점을 받아들여야 합니다.
질문 키별 confidence을 매주 그래프로 그리세요. 0.5를 향해 서서히 이동한다면 criteria가 더 이상 티켓과 맞지 않는다는 뜻입니다. 노이즈가 많은 대기열에서 1.0을 향해 급등한다면 세상이 단순해진 것이 아니라 옵션이 한쪽으로 쏠린 것입니다.
별칭 변경이 주간 그래프에 묻히지 않도록 모든 임곗값 옆에 jev-1.13.0을 기록하세요.
출처