JEV 탐구 ④ — 빠른 판단은 어디까지 믿어도 될까?
고객이 “같은 주문이 두 번 결제됐어요. 하나는 취소해 주세요”라고 썼다. 문의를 결제 담당에게 보내는 판단과 실제로 돈을 돌려주는 판단 사이에는 꽤 긴 거리가 있다. 앞의 일에는 문장의 뜻을 파악하는 능력이 필요하다. 뒤의 일에는 실제 거래 기록, 이미 처리한 환불, 고객의 권한과 회사 정책이 필요하다. 이 글의 고객 문의는 설명을 위해 만든 가상 사례다. JEV에 호출해 얻은 결과나 실제 고객 기록이 아니다.
JEV를 살펴보면서 눈여겨볼 강점은 바로 앞쪽이다. TypeSafe 문서에 따르면 JEV는 자연어를 읽고, 자유로운 답변 대신 정해진 형태의 판단과 확률을 반환한다. 답장을 쓰거나 판단 이유를 길게 설명하는 모델은 아니다.[1] 따라서 “이 고객을 알아서 도와줘”보다 “어느 팀이 맡아야 하는가”, “환불을 명시적으로 요청했는가” 같은 질문이 인터페이스에 잘 맞는다.[5] 판단 결과를 코드에서 다루기 쉽다는 장점은 분명하다. 다만 그 편리함이 정답 보증으로 바뀌는 순간부터 사고가 시작된다.
JSON이 멀쩡해도 판단은 틀릴 수 있다
결제 문의에 billing이라는 값이 왔다고 가정하자. 반환값이 허용된 선택지에 속한다면 코드는 문자열을 다시 해석할 필요 없이 담당팀으로 보낼 수 있다. Choice가 정해진 선택지와 각 선택지의 확률을 반환한다는 것은 문서로 확인되는 기능이다.[8] 그러나 같은 문장을 보고 shipping을 골랐더라도 형식은 여전히 정상일 수 있다. 스키마 검증은 “배송팀이라는 값이 허용되는가”를 검사할 뿐, “이 고객을 배송팀으로 보내는 것이 맞는가”를 판정하지 않는다.
이 구분은 JEV를 폄하하려는 말이 아니다. 출력 형태가 제한되면 연결 코드를 단순하게 만들 수 있다. 다만 개발자는 파서 오류를 줄인 성과와 업무 오판을 줄인 성과를 따로 기록해야 한다. 형식 검사 통과율만 보고 “신뢰할 수 있다”고 결론 내리면 가장 중요한 오류가 통계 밖으로 빠진다. 결제팀 분류의 정답은 담당 조직이 붙인 검증 라벨로, 중복 청구 여부는 거래 원장으로 확인하는 식으로 판단마다 근거를 달리 잡아야 한다.
확률, confidence, Score는 서로 바꿔 읽으면 안 된다
Noul은 예·아니오 질문에서 ‘예’일 확률을 반환한다.[6] 예를 들어 “환불을 요청했는가”에 대한 값이 중간에 있다면, 그것은 환불 의향의 세기가 중간이라는 뜻이 아니다. 질문에 예라고 답할지 불확실하다는 뜻이다. 의향의 강도나 불만의 정도를 보고 싶다면 수준을 정의한 Score가 더 맞는다.[5]
현재 문서에서 Choice와 Score에는 probabilities와 별도의 confidence가 있지만, Noul에는 별도 confidence가 없다.[3] Noul용 confidence 필드를 가정해 공통 코드를 짜면 문서와 어긋난다. 필요하면 애플리케이션이 확률로부터 별도 지표를 계산할 수 있지만, 그 값은 반환 필드가 아니라 우리가 만든 파생값이라고 표시해야 한다.
여기서 confidence도 “이 답이 실제로 맞을 확률”이라는 별도의 인증서는 아니다. TypeSafe는 반환된 확률 분포로부터 이 값을 계산한다. Choice의 경우 선택지가 세 개이고 가장 큰 확률이 0.6이면 문서의 공식으로 계산한 confidence는 0.4다.[3] 이 숫자는 공식 설명을 위한 계산 예시이며 API 측정값이 아니다. 선택지 수에 따라 계산 기준이 달라지므로 서로 다른 질문에 같은 임계값을 붙이는 것도 신중해야 한다.
Score의 숫자는 또 다르다. 수준 번호를 확률로 가중평균한 위치다.[7] 가령 수준이 0·1·2일 때 전부 1에 몰린 분포와 0·2에 반씩 나뉜 분포는 모두 평균 1을 만든다. 전자는 가운데 수준이라는 판단이 뚜렷하고 후자는 양끝 사이에서 갈린다. 평균만 저장하면 이 차이를 잃는다. 높은 불만 Score를 높은 확신으로 읽거나, 중간 Score를 애매한 판단으로 읽어서는 안 된다.
보정이 잘됐다는 말은 여러 건을 모아 확인한다
Calibration, 즉 확률 보정은 예측 확률과 실제 결과가 얼마나 맞아떨어지는지에 관한 문제다. Guo 등의 논문은 분류 모델에서 실제 정답 가능성을 대표하는 확률 추정치를 다루며, 조사한 현대 신경망들이 잘 보정되지 않는 문제를 보고했다.[2] 이 논문은 JEV 평가 논문이 아니다. JEV가 나쁘거나 좋다는 근거로 가져올 수는 없고, 확률이라는 이름만으로 신뢰성을 보장할 수 없는 이유를 이해하는 자료다.
TypeSafe는 System One 모델을 결과에 맞춰 확률을 최적화하는, 보정된 판단을 위한 모델이라고 설명한다. 같은 페이지에는 보정이 예측 집단에 대해 측정되며 개별 답의 정확성을 보장하지 않는다고 적혀 있다.[1] 앞 문장은 회사가 설명하는 학습 목표이고, 뒤 문장은 제품을 사용할 때 지켜야 할 해석의 한계다. 이 글에서는 한국어 결제 문의에 대한 독립 실측 자료를 확보하지 않았으므로 우리 사례에서 얼마나 보정됐는지는 확인하지 못했다.
실무에서는 정답을 확인할 수 있는 과거 문의를 따로 남겨 두고, 비슷한 확률을 받은 사례들을 모아 예측과 정답 빈도를 비교해야 한다. 단순히 “정확도가 높았다”만으로 끝내지 말고, 잘못 자동 처리한 건과 검토로 보낸 건을 나누어 볼 필요가 있다. 문의 전체에서 그럴듯해 보여도 한국어의 완곡한 요청이나 드문 이중 결제 사례에서 어긋날 수 있기 때문이다. 여기서는 측정 데이터가 없어서 신뢰도 곡선을 그리지 않았다. 보기 좋은 대각선은 검증 기록을 대신하지 못한다.
한국어, 업무 용어, 긴 입력은 별도 조건이다
현재 Models 문서는 영어가 주된 학습 언어이고 정확도가 가장 좋으며, CJK를 포함한 다른 언어도 처리하지만 동등한 수준은 아니라고 명시한다.[4] 한국어를 입력할 수 있다는 것과 우리 상담 문장의 정확도가 확인됐다는 것은 다르다. “취소는 됐는데 아직 찍혀 있네요”처럼 결제 승인, 매입, 승인 취소가 섞이는 문장은 한국어 능력과 업무 지식 모두를 시험한다. 같은 문의를 영어로 번역해서 성공했다고 한국어 원문에도 성공했다고 기록해서는 안 된다.
문서상 고객별 파인튜닝이나 LoRA 적응은 제공하지 않으며, 같은 가중치에 state, 질문 지시문과 판단 기준으로 도메인 내용을 전달한다.[4] 따라서 사내 환불 규정과 예외를 요청에 잘 담는 작업이 중요하다. 그래도 자료가 빠졌거나 규정끼리 충돌하면 분명한 선택지를 만들어 주는 것만으로 해결되지 않는다. 이때의 대안은 자신 있게 답하도록 문구를 고치는 일이 아니라 필요한 사실을 더 조회하는 일이다.
긴 문서도 넣기만 하면 해결되는 조건은 아니다. 조회한 문서에서 Jev 1.14와 1.13의 기본 한도는 요청 전체 64k, 질문별 32k 토큰이다. 질문별 한도에도 state가 포함된다.[4] TypeSafe-Danger-Zone-Long-Context: true 헤더로 두 한도를 262k까지 늘릴 수 있지만 기본값은 꺼져 있고, 회사 문서 스스로 기본 한도 안에서 쓸 때보다 느리고 정확도가 낮다고 경고한다.[4] 긴 상담 이력 전체를 무조건 보내기보다 어떤 거래와 어떤 시점의 정책이 필요한지 먼저 좁히는 설계가 낫다는 것이 이 글의 판단이다.
애매한 고객에게는 추가 질문이 먼저다
이번에는 고객이 “또 결제된 것 같은데 지난번 건도 아직 보이네요. 확인 좀 해주세요”라고 썼다고 하자. 환불을 명시적으로 요청하지 않았고, 실제 두 번 청구됐는지도 알 수 없다. 단순히 청구 내역을 확인하려는 것일 수 있다. 이 문장에 예측 숫자를 붙여 JEV의 출력처럼 보여 줄 근거는 없다. 대신 애플리케이션이 해야 할 일은 분명하게 정할 수 있다. 관련 주문을 확인하고, 승인 대기와 확정 청구를 구분할 자료를 가져오며, 필요하면 고객에게 어떤 항목을 말하는지 묻는다.
확률이 애매할 때 보류하는 길은 유용하지만, 높은 confidence일 때도 입력 자료의 누락과 처리 권한은 별도로 확인해야 한다. 높은 값은 권한 확인을 생략하라는 지시가 아니다. 공식 문서도 임계값은 업무와 실제 성능에 따라 정하고 자체 데이터로 시험하라고 설명한다.[3] 문서 속 예시 임계값을 결제 시스템의 운영 기준으로 그대로 복사할 이유는 없다.
명확한 첫 번째 사례에서는 결제팀 분류까지 자동화할 여지가 있다. 환불 실행은 다른 경로에 둔다. 거래가 실제로 중복인지 코드와 원장으로 확인하고, 이미 환불한 거래가 아닌지 확인하며, 승인 권한을 가진 담당자나 별도로 검증된 정책 절차를 거친다. 사람에게 넘길 때도 “모델이 불확실합니다”만 보여 주면 검토가 어렵다. 원문, 관련 거래, 질문과 선택지, 반환 분포, 실제 모델 버전을 함께 보여 주는 편이 좋다.
문서에서 jev-latest는 현재 jev-1.14.0을 가리키지만 별칭은 새 릴리스에 따라 바뀐다. TypeSafe는 임계값을 조정한 버전의 ID를 직접 지정하고 응답의 모델 ID를 기록하라고 안내한다.[4] 검증한 질문과 모델을 고정해야 나중에 오판이 늘었을 때 입력 변화인지 모델 변경인지 조사할 수 있다.
JEV의 강점은 좁은 자연어 판단을 코드가 쓰기 좋은 값으로 연결한다는 데 있다. 지원 범위의 제한도 뚜렷하다. 현재는 텍스트 입력만 받으며 이미지·음성·영상은 지원하지 않고, 설명문이나 답장을 생성하지 않는다.[1] 회사가 내세우는 빠른 판단과 보정 학습은 제품 설명으로 읽되, 우리 서비스의 지연 시간과 오판율은 별도로 확인해야 한다. 이 글은 유료 API를 호출하지 않았고 성능을 측정하지 않았다. 도입의 첫 단계로 추천할 수 있는 것은 환불 자동 실행이 아니라, 사람이 정답을 확인할 수 있는 문의 분류와 검토 보조다. 그 기록을 쌓은 뒤 자동 처리 범위를 넓혀도 늦지 않다.
Sources
[1] System One
[2] On Calibration of Modern Neural Networks
[3] Confidence
[4] Models
[5] Primitives
[6] Noul
[7] Score
[8] Choice