Jev 신뢰도 임계값, 내 데이터로 검증하고 정하는 방법

Jev 신뢰도 임계값은 라벨이 붙은 데이터에서 수락한 판단 중 오류의 비율과 전체 트래픽 중 수락한 비율을 측정해 정하세요. 0.8이나 0.9가 안심할 만한 숫자로 보인다는 이유로 선택하면 안 됩니다. 질문, 모델 버전, 입력 모집단과 대체 경로의 동작이 정해져야 임계값에도 의미가 생깁니다.

이 튜토리얼은 오프라인 평가 스크립트, 정답을 알고 있는 합성 테스트 데이터, 기존 Jev 로그에서 별도 보류 테스트로 나아가는 절차를 제공합니다. 지원 요청을 여러 담당 부서로 보내는 것과 같은 Choice 분류 질문을 대상으로 합니다. 실제 API 호출, Jev 정확도 측정, 중대한 영향을 주는 판단의 자동화 검증은 수행하지 않습니다. 아직 응답을 수집하지 않았다면 Jev API 가이드부터 읽어 보세요.

어떤 수치에 임계값을 적용하는지 이해하기

공식 API는 답변의 확률과 confidence를 구분합니다. 선택지가 n개인 Choice의 문서상 신뢰도 공식은 (n × p_max − 1) / (n − 1)입니다. 선택지가 3개이고 가장 큰 확률이 0.8이면 신뢰도는 0.7입니다. 따라서 한 필드에 적용한 임계값을 다른 필드에 같은 값으로 적용할 수는 없습니다. TypeSafe 신뢰도 참고 문서.

2026년 10월 2일 캡처한 공식 문서 화면입니다. 필드의 정의를 보여 주며, 자신의 데이터에서 어떤 임계값이 유효하다는 증거는 아닙니다.

Score는 순서가 있는 수준 사이의 거리를 반영하는 별도 계산법을 사용합니다. Noul은 별도 신뢰도 필드 없이 yes 확률을 반환합니다. 세 유형을 모두 ‘확실성’이라는 공통 열에 넣고 하나의 기준값을 적용하지 마세요. 이 튜토리얼의 CSV에는 고정된 질문 하나에서 반환된 Choice 신뢰도를 넣어야 합니다.

그다음 두 개념을 따로 측정해야 합니다. 보정은 사례 집단별 예측 확률이 관측 결과와 맞는지를 묻습니다. 선택적 평가는 정한 기준값에서 수락한 판단이 얼마나 자주 틀리는지를 묻습니다. 특히 거의 모든 트래픽이 대체 경로로 넘어간다면, 확률이 잘 보정되지 않았어도 선택적 오류율은 좋아 보일 수 있습니다.

결과를 보기 전에 수락 기준 정하기

애플리케이션이 티켓을 billing, technical, other로 분류한다고 가정해 보겠습니다. 올바른 분류란 독립적으로 부여한 라벨과 일치하는 것입니다. 티켓이 불완전하거나 모순되거나 해당 범주 밖이라면, 정답 라벨을 만드는 과정에서 어떻게 처리해야 하는지 정해야 합니다. 그렇지 않으면 검토자도 정당화할 수 없는 답을 모델이 추측했을 때 좋은 평가를 주게 됩니다.

허용 가능한 최대 오류율, 최소 수락 트래픽, 지연 시간 예산, 별도 검토가 필요한 오류를 적으세요. 이는 Jev가 제공하는 숫자가 아니라 애플리케이션의 결정 사항입니다. 되돌릴 수 있는 담당 부서 배정과 되돌릴 수 없는 조치가 모두 라벨을 반환한다는 이유로 같은 수락 기준을 써서는 안 됩니다.

예시를 담은 라벨 지침을 사용하고, 모델 출력을 평가하기 전에 검토자 간 의견 차이를 해결하세요. 가능하면 검토자에게 예측 결과를 보여 주지 마세요. 모델 답변을 먼저 보면 ‘정답’이 독립적인 근거가 아니라 모델에 동의한 결과로 바뀔 수 있습니다.

개발·검증·최종 테스트 분리하기

개발 예시는 질문과 범주 정의를 개선하는 데 사용합니다. 검증용 분할은 임계값 후보를 비교하는 데 사용합니다. 별도로 보류한 최종 테스트를 실행하기 전에 질문과 임계값을 모두 고정하세요. 최종 테스트 결과를 본 뒤 기준값을 반복 조정하면 그 데이터는 또 다른 검증 세트가 됩니다.

관련 행 사이에 정보가 새어 나갈 수 있다면 대화, 고객 문서 또는 템플릿 계열 단위로 분할하세요. 일반 트래픽과 중요한 경계 사례를 포함하되, 경계 사례의 비중을 의도적으로 높였다면 결과를 따로 보고합니다. 좋은 평균이 지원하지 못하는 하위 집단을 가리지 않도록 언어와 입력 길이 그룹을 기록하세요.

배포를 안전하게 만들어 주는 보편적인 표본 크기는 없습니다. 특히 수락한 사례가 몇 건뿐인데 오류가 없었다는 사실은 근거가 약합니다. 대략적인 통계 예시로, 독립 시행에서 오류가 한 번도 관측되지 않았다면 ‘3의 법칙’은 오류율의 약 95% 상한을 3 / accepted_count로 근사합니다. 이는 계획용 근사치이지 보증서가 아닙니다. 사례 간 상관관계, 선택 편향, 분포 변화가 있으면 이 해석이 성립하지 않을 수 있습니다. 정식 통계 추론에는 평가 책임자와 함께 적합한 구간 추정법과 표본 설계를 선택하세요.

고정된 질문의 결과로 CSV 준비하기

Jev 판단 도구 모음을 다운로드하고 압축을 푸세요. Python 3가 필요하며, 스크립트는 표준 라이브러리만 사용합니다. 키와 네트워크 연결은 필요하지 않습니다.

제공된 파일에는 5개 열이 있습니다.

실제 응답 모델, 요청 ID, 전체 확률 맵, 질문 버전과 원본 데이터 분할은 id로 연결되는 별도의 추적 명세에 보관하세요. 이 작은 평가기는 해당 메타데이터 필드를 강제하지 않습니다. 여러 모델 버전이나 질문을 하나의 CSV에 섞은 뒤 하나의 검증된 정책이라고 설명해서는 안 됩니다.

다음은 제공된 직접 작성한 합성 테스트 데이터의 일부이며 Jev 응답이 아닙니다.

id,gold,predicted,confidence,status
case-1,billing,billing,0.98,ok
case-2,technical,technical,0.94,ok
case-3,billing,technical,0.91,ok

자체 파일에서는 저장한 응답의 필드를 복사하되, 임계값을 적용하기 전에 반올림하지 마세요. 실패한 요청은 예측과 신뢰도를 비워 둔 error 행으로 유지합니다. 시간 초과를 빼면 처리 비율이 실제보다 높아 보입니다.

평가기를 실행하고 계산 확인하기

압축을 푼 디렉터리에서 실행합니다.

python3 evaluate.py synthetic.csv
python3 evaluate.py synthetic.csv --thresholds 0.8 0.9

제공된 합성 사례 8개로 첫 번째 명령을 로컬에서 실행했습니다. 출력은 계산기 로직을 검증한 결과이지 측정된 Jev 성능이 아닙니다.

처리 비율은 accepted / all eligible cases, 수락한 사례의 오류율은 wrong accepted / accepted입니다. 수락한 사례가 없으면 스크립트는 완벽한 정확도를 달성했다고 간주하지 않고 오류율을 null로 반환합니다.

이 데이터에서는 0.80에서 0.90으로 올리면 관측 오류율이 오히려 나빠집니다. 유한한 표본에서 높은 임계값이 단조로운 개선을 보장하지는 않습니다. 0.95 행에는 오류가 없지만 사례를 하나만 수락하므로 신뢰성의 근거로는 부족합니다. 이 예시는 실제 데이터에 적용하기 전에 흔한 두 가지 오해를 발견하도록 의도적으로 구성했습니다.

정책을 선택한 뒤 전체 파이프라인 검증하기

검증 데이터에서 후보별 결과 행과 수락된 실제 오류를 살펴보세요. 오류 제약을 위반하는 정책은 제외합니다. 남은 정책에서 처리 비율, 대체 경로 용량, 비용과 지연 시간을 평가합니다. 어느 것도 요구 사항을 충족하지 못하면 결론은 ‘아직 이 질문을 자동화하지 않는다’여야 합니다. ‘그나마 덜 나쁜 숫자를 고른다’가 아닙니다.

이후 선택한 임계값을 고정하고 보류 데이터로 한 번 평가하세요. 대체 경로도 평가해야 합니다. 신뢰도가 낮은 판단을 다른 모델이나 사람에게 보냈다고 자동으로 성공한 것은 아닙니다. 사용할 수 없는 처리기와 끝나지 않은 사례를 포함해 전체 워크플로를 채점하세요.

보수적인 정책의 골격은 다음과 같습니다.

if response_error or label_not_allowed or confidence_invalid:
    fallback()
elif confidence < validated_threshold:
    fallback()
else:
    enforce_permissions_and_business_rules()
    route_to_handler()

이는 애플리케이션 의사 코드이며 실행 가능한 Jev SDK 예제가 아닙니다. 비교 전에 누락되거나 유한하지 않거나 범위를 벗어난 신뢰도를 거부하세요. NaN이 숫자 기준값 검사를 통과해서는 안 됩니다. 권한, 입력 검증과 업무 규칙은 여전히 코드에서 처리해야 합니다. 신뢰도가 높다고 이를 건너뛸 수는 없습니다. 라우팅된 작업에 부수 효과가 있다면 기존 워크플로에 필요한 멱등성과 확인 절차를 동일하게 적용하세요.

실패를 숨기지 말고 진단하기

공개 결과의 더 넓은 해석은 Jev 벤치마크로 확인할 수 있는 것을 참고하세요. 해당 글은 벤치마크에서의 보정 결과만으로 특정 운영 임계값을 승인할 수 없는 이유를 설명합니다.

임계값을 버전과 함께 관리하기

재현성이 중요하면 평가한 모델 버전을 고정하고 응답이 보고하는 버전을 기록하세요. 질문을 바꾸거나, 선택지를 추가하거나, 상태 정보를 번역하거나, 전처리를 변경하거나, 다른 모델 버전으로 옮기면 다시 평가해야 합니다. 임계값이 같아도 입력이 달라지면 다른 정책이 될 수 있습니다.

섀도 판단부터 시작하고, 명확한 롤백 책임자를 지정한 뒤 되돌릴 수 있는 제한적 배포로 진행하세요. 새로 라벨을 붙인 표본에서 수락된 오류를 관찰하고, 전체 처리 비율, 대체 경로 부하와 완결된 작업 결과를 모니터링합니다. 실험을 다시 구성하지 않고도 돌아갈 수 있도록 이전 정책을 저장해 두세요.

마지막으로 측정한 처리 비율을 라우팅 비용 계산기에 넣으세요. 임계값은 작업의 품질 기준을 충족하면서 운영 가능한 애플리케이션을 남길 때 유용합니다. 보기 좋은 소수점 숫자를 만든다는 사실만으로 유용한 것은 아닙니다.