제브는 텍스트를 생성하지 않고, 선택이나 진위 판별과 같은 “판단”을 확률과 함께 반환하는 TypeSafe AI의 판단 특화형 모델이다. 속도와 비용이 매력적이며, 사람들의 발상을 자극하는 점에서 훌륭한 제품이라고 생각한다.
최근의 열광적인 반응을 보면서, 마치 무엇이든 Jev로 해결될 수 있다는 이야기가 나오고 있습니다. Jev는 “시스템 1(직관적·즉각적인 판단)”에 특화된 제품으로, 깊이 생각하는 과정을 생략함으로써 속도와 저렴함을 얻고 있습니다. 활용 가능한 상황은 어느 정도 제한적일 것입니다. 시스템 1의 범위 안에서도 판단을 확률과 함께 반환하는 것만으로는 LLM의 로짓을 활용하는 것으로 충분하다는 지적도 있습니다.
이것에 대한 옹호는 Jev의 확률이 “교정(캘리브레이션)되어 있다”는 의미로, 즉 80%라고 하면 실제로 8할에 가까운 신뢰할 수 있는 숫자라는 주장이다. TypeSafe의 공식 웹사이트 또한 이 확률을 임계값으로 설정하여 자동으로 처리할지 또는 사람에게 연결할지를 결정하는 방식을 권장하고 있다.
그러나 그 확률이 실제로 보정되어 있다는 증거는, 제가 찾을 수 있는 범위 내에서는 적어도 발견되지 않았습니다. TypeSafe 자체도 공식 Skill로 대상 영역에 대한 검증을 요구하고 있으며, Vercel의 기사 또한 확률이나 confidence를 실제 레이블이 붙은 데이터로 보정하는 것을 권장하고 있습니다.
그러고 나서 저는 Jev에게 “완전히 공정한 주사위”를 건네 보았습니다.
공정하게 굴리는 주사위로 테스트해 보세요.
먼저 실험 결과를 말씀드리겠습니다.
제브는 정답을 알아내는 단서가 전혀 없었음에도 불구하고, 자신이 직접 선택한 결과에 80% 이상의 높은 확률을 부여했다. 실제 정답률은 무작위(약 1/6) 수준에 그쳐, 보고된 확률과는 현저하게 차이를 보였다.
여기 문제로 다루어야 할 것은 “주사위를 던져 원하는 눈이 나오지 않았다는 사실”이 아니다. “정보가 없는 상황에서 그 불확실성을 정확한 확률로 보고할 수 없었던 것”이다.
실험 설정
이번에는 Vercel AI 게이트웨이를 통해 Jev를 호출하고, 사전에 정의된 후보들 중에서 1개를 선택하여 각 후보의 확률도 반환하는 Choice라는 질문 유형을 사용했다. 주사위라면 후보는 “1부터 6”까지의 눈금이 된다.
※ 검증 코드와 저장 데이터는 GitHub 리포지토리에 공개되어 있습니다.
제공된 프롬프트에 따라 제시된 지침의 핵심은 다음과 같습니다 (실제로는 영어로 입력되었습니다).
공정한 6면 주사위를 한 번 굴렸습니다. 각 면은 동등한 확률로 나타나며, 결과는 공개되지 않았습니다. 실제로 나온 눈은 무엇일까요? (가장 가능성이 높은 결과가 확실하다고 가정하지 않고, 불확실성을 확률 분포로 유지합니다.)
프로그램 측에서 숨겨진 결과를 생성하는 동시에 제브에게 “추첨은 공정하다”는 것과 “결과는 보이지 않는다”는 것만 전달했다.
실험 결과
숫자 주사위(400개), 색깔 주사위(200개), 4등분 회전판(200개), 동전 던지기(200개)를 포함한 모든 항목에서 동일하게 검증했다.
다음의 “보고 확률”은 Choice가 선택한 후보에 부여한 값(probabilities[choice])을 의미합니다. 별도의 필드인 confidence와는 구별됩니다. confidence의 계산식은 유린 씨가 (N × 최대 확률 − 1) ÷ (N − 1)라고 복원한 것입니다. 최대 확률을 변환한 값일 뿐이며, 독립적인 신호는 아닌 것으로 보입니다.
숫자 주사위에서는 모든 400건 중 “1”을 선택한 경우가 76건이었다. 그리고 그 선택에 대해 평균 82.9%라는 극도로 강한 확률을 부여했다. 그러나 실제 적중률은 19.0% (76/400)로, 거의 이론적인 기대치 (16.7%)와 일치했다.
다른 추첨에서도 마찬가지로 정답률은 우연에 따른 수준에 머물러 있었지만, 보고 확률은 70%에서 90%대로 급격하게 상승하고 있었다.
선택과 확률 보고의 차이
정보가 없는 이상, 공정한 주사위를 무작위로 맞추는 것은 누구도 할 수 없다. 따라서 정답률이 약 1/6이었던 것 자체가 아무런 잘못이 아니다.
매번 “1”을 선택한 것 자체도 문제가 아니다. 모든 면이 나올 확률이 동일하다면, 토너먼트 방식의 승부차기 규칙으로 “일단 1을 답한다”는 것은 합리적인 행동이다.
하지만, 그 경우에도 원래 있어야 할 출력은 다음과 같아야 합니다.
하나의 후보를 선택하는 것과 그 후보가 정답이라는 확률을 추정하는 것은 완전히 다른 일이다.
확률을 시스템이나 업무 판단에 반영하기 위해서는 “80%의 확률로 일어날” 것이라고 예측된 사건의 집단을 모았을 때, 실제로 약 80%가 맞아떨어지는 대응 관계가 필수적이다. 이를 통계학이나 기계 학습에서는 확률의 보정을 의미한다.
TypeSafe 자체도 문서에서 동일한 정의를 채택하고 있습니다. 잘 검증된 모델이라면 확률 0.8을 부여한 결과 약 80%의 빈도수로 발생해야 한다고 하는 것이죠. 이번 실험은 이 정의를 그대로 적용하고 있습니다.
이번 입력에서는 이 보정이 크게 엉뚱하게 나타났다. 400건에 대해 보고율은 최소 71%(중앙값 83%)로, 실제 확률인 1/6의 4배 이상이었다.
진실 판단 “예/아니오”로 바꿔보자
선택형 특유의 습관이 아닌지 의심하여, 참/거짓(Yes/No)을 판별하는 질문형 Noul로도 검증했다 (Vercel에서는 Boolean). “출目は1か？”, “특정 리クエスト先이 선택되었는가?”와 같은 질문에 대해, 그것이 참일 확률을 반환하도록 하는 작업이다. 실제 출目이나 할당 결과는 伏せて渡す 조건은 공통으로, 각 조건 60건씩 테스트했다.
주사위(16.7%에 비해 19.2%)나 4분할(25.0%에 비해 24.7%)과 같이, 실제 확률에 상당히 가까운 값을 반환하는 경우도 관찰되었다.
그러나 선택지가 늘어나고 확률이 작아지면 행동이 부자연스럽게 나타난다. 20분할(진위율 5.0%) 설정을 적용했을 때, 평균적으로 15.0%(전체 건의 13~17% 범위)라는 과장된 값을 보고했다.
즉, “Choice가 문제라면 Noul을 사용하면 해결된다”라는 단순한 이야기가 아니다. 입력 조건이나 확률 범위에 따라 모델의 작동 방식이 달라지는 점에 유의해야 한다.
예측 문서의 수치를 다음 단계로 전달할 때의 위험성
단순한 주사위와 같은 인위적인 문제뿐만 아니라, 실제 업무 시나리오에서는 어떻게 될지 시험했다. 그래서 다음으로, 문서의 내용을 읽어 추출하여 에이전트나 후속 로직에 전달하는 상황을 시도했다.
예를 들어, “재고 충족 확률 70%, 부족 위험 30%”라고 적힌 수요 예측 보고서가 있다고 가정해 봅시다. 업무 자동화 에이전트가 다음으로 해야 할 일은 “충족이 최우선이기 때문에 문제없다”는 판단을 내리는 것이 아니라 “30%의 부족 위험이 있으므로, 예방 차원에서 대체품 확보를 발주해야 하는가?”를 판단하는 것입니다.
실험에서는 재고, 용량, 자금 흐름, 서비스 수준이라는 4가지 주제로 예측 확률을 명시한 합성 문서를 만들었습니다. “이 문서를 바탕으로 어떤 결과가 발생할지 판단하시오 (불확실성을 확률 분포로 유지하는 것)”라고 제브에게 지시했습니다.
30%의 위험이 5%로 축소됩니다.
재고 각각 “부족 위험 30%”로 기재된 세 건의 문서를 Choice에게 읽어준 결과, Choice가 제시한 부족 확률은 5%, 5%, 6% (평균 5.3%)였으며 (Noul의 경우 평균 26.7%였다).
원문에 적혀 있던 “30%의 위험”을 그대로 전달하고자 했지만, Choice를 거친 결과, 무려 5%의 “거의 무시할 수 있는 위험”으로 완전히 바꿔진 셈이 되었다.
또한, 문서에 기재될 확률을 단계적으로 변화시켜 나타낸 것이 아래 그래프이다.
그림 해설: 수평축은 원문에서 제시된 위험 확률(부족, 미달성 등), 수직축은 Jev가 제시한 확률이다. 4가지 소재에 대한 3가지 조건(총 12건)의 평균값을 나타낸다. 검은 선은 기재된 값과 출력 값이 일치하는 이상선(理想線)을 표시한다.
결과는 극단적이었다.
- 기록 값이 45%일 때 Choice의 보고 확률은 평균 6.6%이다.
- 기록 값이 55%일 때 Choice의 보고 확률은 평균 95.9%이다.
기록값의 차가 10 포인트밖에 안 되는데, Jev의 보고값은 약 89 포인트나 증가하고 있다. 확률을 매끄럽게 처리하지 않고, 50%를 기준으로 “우세한 쪽을 거의 100%로 이기고, 불리한 쪽을 0에 가깝게 억누르는” 극단적인 변화가 발생한다. Noul에서도 기록값 95%에 대해 출력이 75.9%가 되는 등, 원래의 수치를 그대로 소신 있게 계승하는 모습과는 어울리지 않았다.
이것은 업무 시스템에 치명적인 영향을 초래하는 경우입니다.
만약 시스템에 “부족 위험이 10%를 초과하면 자동으로 발주 알림을 낼”이라는 규칙이 설정되어 있었다고 가정해 보자.
- 원문 예측(30%)을 그대로 사용하는 경우, 10%를 초과하여 경고가 발동되고 안전 대책이 시행된다.
- 제브(Jev)의 Choice 출력(5.3%)을 사이에 두고 사용한 경우, 10% 미만을 기록하여 경고가 건너뛰고 품절 사고가 발생할 수 있다.
제브 스스로 판단의 필요성을 요구한 것은 아니었다. 동일한 규칙이라도 중간에 모델이 삽입되어 반환하는 ‘확률’ 척도가 달라지는 것뿐이며, 시스템 전체의 행동이 의도치 않게 흐트러지는 것이다.
확률을 시스템에서 사용하기 전에 알아두어야 할 사항
제브의 확률은 쓸모가 없다고 단정할 수 없다. 별도로 공식 데모와 유사한 합성 작업을 실시한 결과, 주사위처럼 극단적인 보정 오차는 관측되지 않았다. 유용한 경우는 여전히 많다.
문제되는 것은, 출력된 숫자를 “충분히 교정된 신뢰할 수 있는 확률”이라고 맹신하고, 꼼꼼한 검증을 소홀히 하며, 안전 계수를 낮추거나, 임계값에 따른 조건 분기에 직접적으로 연결시키는 경우이다.
제브(Jev)를 비롯한 판단 모델을 제품에 통합할 때는 다음 사항을 고려해야 합니다.
- 정답률뿐만 아니라 확률의 교정을 보았을 때 높은 확률을 설정한 경우에는 실제로 그 빈도에서 중타하는지 검증 데이터를 통해 측정한다.
- 정보가 부족한 예외적인 경우를 테스트 데이터에 섞어 답이 자명한 것뿐만 아니라, 의도적으로 “판단에 필요한 정보가 숨겨진 경우”를 입력하여 모델이 불확실성을 보고할 수 있는지 확인한다.
- 원본의 숫자를 임의로 덮어쓰지 않고 문서 내 예측 숫자를 후속 단계에 전달하고 싶다면, 분류기의 판단 확률로 대체하는 대신 원문의 숫자를 그대로 유지하고 추출하는 시스템을 채택한다.
빠르고 저렴한 판단 능력과 “출력된 수치를 무조건적으로 신뢰할 수 있는 것”은 완전히 다른 문제다.
코드와 데이터: GitHub
GitHub는 전 세계 개발자들이 코드를 공유하고 협업할 수 있는 플랫폼입니다. Git이라는 분산 버전 관리 시스템을 기반으로 하며, 이를 통해 프로젝트의 변경 사항을 추적하고 관리할 수 있습니다. GitHub는 단순히 코드를 저장하는 곳이 아니라, 프로젝트의 모든 것을 통합적으로 관리할 수 있는 환경을 제공합니다.
GitHub의 주요 기능은 다음과 같습니다.
* **리포지토리:** 코드를 저장하고 관리하는 공간입니다. 공개 리포지토리와 개인 리포지토리가 있으며, 프로젝트의 규모와 필요에 따라 선택할 수 있습니다.
* **Git:** GitHub의 핵심 기술로, 코드 변경 사항을 추적하고 관리하는 데 사용됩니다.
* **Issue:** 프로젝트에 대한 논의, 버그 보고, 기능 요청 등을 관리하는 데 사용되는 시스템입니다.
* **Pull Request:** 다른 개발자의 코드 변경 사항을 자신의 코드에 병합하기 전에 검토하고 합의를 이끌어내는 데 사용됩니다.
* **Wiki:** 프로젝트에 대한 문서, 가이드, 튜토리얼 등을 작성하고 공유하는 데 사용됩니다.
GitHub는 오픈 소스 프로젝트뿐만 아니라, 기업의 내부 프로젝트 관리에도 널리 사용되고 있습니다. GitHub를 통해 개발자들은 전 세계의 다른 개발자들과 협력하여 더 나은 소프트웨어를 만들 수 있습니다. 또한, GitHub는 코드 저장 및 버전 관리의 효율성을 높여 개발 생산성을 향상시키는 데 기여합니다. GitHub는 지속적으로 새로운 기능을 추가하고 있으며, 개발자 커뮤니티의 요구에 맞춰 발전하고 있습니다.
출처: note 원문
번역: Gemma 3(.44) 초벌 + 교정 43청크
원문 보기 | 출처: note.com