Jev의 확률은 어디까지 믿어도 될까요

1편에서는 Jev를 제 파이프라인 두 곳에 붙여 속도와 호출 수를 쟀습니다. 결론은 판단 횟수였어요. 판단이 많은 곳에서는 이득이고, 두세 번뿐인 곳에서는 손해입니다.

이번 편은 속도 말고 나머지입니다. Jev가 어떤 형태로 답하는지, 선택지가 늘면 정확도가 얼마나 떨어지는지, TypeSafe가 가장 크게 내세우는 확률은 어디까지 믿어도 되는지 짚어 봅니다.

글에 나오는 용어는 Jev 용어집에 따로 모아 뒀어요.

---

답은 세 가지 형태뿐입니다

만든 사람은 디오고 알메이다입니다. OpenAI에서 RLHF와 InstructGPT를 함께 만든 연구자예요. 그가 TypeSafe AI를 세우며 던진 질문은 이겁니다.

전구가 천지에 깔렸는데, 경제가 뒤집혔다는 소식은 대체 어디 있습니까?

채팅창은 넘쳐 나는데 자동화는 왜 안 늘었느냐는 문제 제기죠. 그는 이렇게 봅니다. 실제 자동화에서 사람과 나누는 대화는 1%고, 나머지 99%는 소프트웨어끼리 주고받는 통신입니다. 프로그램은 긴 문장을 원하지 않아요. if 문으로 바로 분기할 수 있는 값을 원합니다.

그래서 Jev의 답은 세 형태(Primitive)뿐입니다.

"이 문의는 결제·주문·반품·계정 중 어디로 보낼까?"라고 물으면 이런 값이 돌아옵니다.

{ "type": "choice", "choice": "returns",
  "probabilities": { "billing": 0.01, "orders": 0.01, "returns": 0.95, "account": 0.03 },
  "confidence": 0.92 }

요금은 100만 토큰 기준으로 이렇게 매깁니다. 오른쪽 끝 열은 꼭 같이 보세요.

네 줄 중 세 줄이 회사가 낸 숫자입니다. 직접 잰 사람들의 숫자를 따로 봐야 하죠.

---

Jev는 선택지가 적을 때 강합니다

선택지가 둘일 때는 Jev가 LLM을 이겼고, 77개로 늘자 LLM에 밀렸습니다.

Aman Kumar가 공개 데이터셋 네 종에 1만 6천 번을 호출해 정확도를 쟀어요.

저자는 질문 문구만 바꿔도 정확도가 5%p씩 흔들렸다고 적었습니다.

TypeSafe가 공개한 워크플로 평가도 봐 둘 만합니다. 가로축이 비용(로그 스케일), 세로축이 정확도예요. Jev는 맨 왼쪽에 홀로 떨어져 있습니다. 정확도는 중간급 LLM과 비슷한데, 비용은 10분의 1에서 100분의 1이죠.

워크플로별로 보면 편차가 큽니다. 고객 응대는 가장 정확한 LLM 워크플로와 2.3%p 차이인데, 인보이스 처리는 17.3%p가 벌어져요.

TypeSafe는 못 하는 것도 문서로 먼저 적어 뒀습니다. 실무에서 바로 걸리는 건 네 가지예요.

• 숫자 계산. 계산은 코드로 빼라고 문서가 직접 적었습니다.
• 날짜와 시간 비교. 날짜 추출만 맡기고 비교는 코드에서 합니다.
• 관련 없는 정보가 많은 입력. 입력이 길고 잡다할수록 판단이 흔들립니다.
• 구조적 일관성. 같은 질문을 Noul로 물으면 0.22, Choice로 물으면 'no' 0.99가 나오기도 합니다.

한국어는 따로 재 보셔야 합니다. 공식 문서는 영어가 주력이고, 한중일 문자는 처리하지만 같은 수준은 아니라고 적어 뒀어요.

---

애매한 구간은 사람에게 넘깁니다

TypeSafe가 내세우는 건 속도보다 확률(Probability)입니다. 회사 설명은 이렇습니다. 95%를 맞혀도 틀리는 5%가 언제인지 말해 주지 못하면, 그 일은 자동화할 수 없다.

그래서 학습 방식부터 다릅니다. 채팅 모델은 사람이 더 좋아하는 답(RLHF)으로, 추론 모델은 자동 채점되는 정답(RLVR)으로 다듬죠. Jev는 확률이 실제 결과와 맞도록 다듬었습니다. 이걸 RLCD(Reinforcement Learning for Calibrated Decisions)라고 불러요.

같은 청구 건을 15번 반복해 물었을 때, Jev의 질문별 확률 표준편차 평균은 0.0102였어요. 비교한 LLM 조건 전부보다 작았습니다.

그래도 흔들립니다. "이 손해가 보장 대상인가"라는 질문은 0.43과 0.53 사이를 오가며 0.5 기준선을 넘나들었어요.

그래서 임계값(Threshold)을 두 개 둡니다.

• 0.30 미만: 아니오로 자동 처리
• 0.70 초과: 예로 자동 처리
• 그 사이: 사람이 검토

애매하면 결론을 내리지 않고 사람에게 넘깁니다. 확률이 붙어 있으니 코드 몇 줄로 이 분기를 만들 수 있어요.

다만 이 확률을 어디까지 믿을지는 따져 봐야 합니다. 보정(Calibration)은 여러 답을 묶었을 때의 비율이에요. 공식 문서도 개별 답을 보장하지 않는다고 못 박아 뒀습니다. 게다가 TypeSafe는 보정 데이터를 아직 공개하지 않았어요. 제이 반 질은 4천만 달러를 투자받은 모델이 보정된 확신도를 내세우면서 보정 오차 도표 하나 내놓지 않았다고 꼬집었습니다.

판단 근거도 볼 수 없습니다. Jev는 확률만 돌려주고, 입력의 어느 대목을 보고 그렇게 판단했는지는 알려 주지 않아요. 채용 심사처럼 편향이 곧바로 누군가의 피해가 되는 일에는 붙이지 않는 게 맞습니다.

---

판단이 싸지면 더 자주 묻게 됩니다

Jev라는 이름은 경제학자 제번스(Jevons)에서 왔습니다. 석탄 기관이 효율적으로 바뀌자 석탄 소비가 줄기는커녕 폭발했다는, 그 제번스 역설이요.

저도 그렇게 됐습니다. 판단이 비쌀 땐 정규식으로 때우고 넘어갔어요. 싸지니까 규칙 세 개를 전부 모델에게 묻고 있습니다.

TypeSafe가 그리는 소프트웨어도 이런 모습입니다. 사람이 짠 규칙만 도는 전통 소프트웨어와 LLM이 모든 걸 떠맡는 에이전트 사이에서, 싼 판단을 코드 곳곳에 심는 구조예요.

이제 저는 어느 모델이 더 똑똑한지 묻지 않습니다. 이 판단에 LLM이 꼭 필요한지부터 따집니다.

---

출처

• TypeSafe 공식: 모델·가격 · 실패 유형 · 일관성 쿡북 · AI Primer · 워크플로 평가
• 독립 측정: Aman Kumar · LiteLLM · Near Here
• 비판: 보정 데이터 미공개