글을 쓰지 않는 AI 모델? Jev의 정체는 무엇인가

URL: https://www.youtube.com/watch?v=9tPnHRSUNFA 날짜: 2026-10-04 채널: Tech Bridge

---

📌 핵심 질문 / 소프트웨어에 필요한 AI는 왜 반드시 글을 써야 하는가

==Jev는 문장을 생성하는 대신 미리 정의한 답의 형태를 고르고, 각 선택지의 확률을 돌려주는 System One 의사결정 모델이다.== 빠른 분류·라우팅·검증은 Jev에 맡기고, 설명·응답 작성처럼 실제 사고와 언어 생성이 필요한 일은 Large Language Model(LLM)에 맡기는 조합이 핵심이다.

• Jev는 질문마다 Noul(보정된 예/아니오), Choice(목록에서 하나 선택), Score(순서가 있는 척도상의 점수)처럼 타입이 정해진 답을 반환한다.
• 세 질문을 한 번의 요청에 넣으면 텍스트를 토큰 단위로 생성하지 않고 답을 동시에 돌려주므로, 이런 좁은 판단에서는 LLM보다 빠르고 저렴하다.
• 출력 확률이 보정(calibration)되어 80%라고 말한 판단이 장기적으로 약 80% 맞도록 학습되므로, 코드가 자동 처리·사람 검토·거부를 임계값으로 나눌 수 있다.
• Jev는 LLM을 대체하지 않는다. 자동 분류와 안전장치를 담당하는 System One과, 답변 작성과 복잡한 사고를 담당하는 System Two를 워크플로에 함께 배치한다.

1. Jev가 제안하는 새로운 AI 모델의 형태

Jev는 대화형 답변을 만드는 모델이 아니라, 데이터와 질문을 받아 구조화된 의사결정을 반환하는 모델이다.

1.1. TypeSafe의 System One 모델

1. 글을 생성하지 않는 모델

   1. TypeSafe의 새 AI 모델: Jev는 TypeSafe가 만든 모델이며, 일반적인 챗봇처럼 답변 문장을 쓰지 않는다.
   2. 목록 선택과 확률 반환: 질문을 받으면 가능한 답의 목록에서 선택하고, 각 답에 해당할 확률을 함께 돌려준다.
   3. 출력의 제약: 입력 시 정의한 답의 형태를 벗어나 임의의 문장을 만들지 않으므로, 소프트웨어가 바로 읽을 수 있는 구조를 만든다.

2. System One이라는 이름

   1. 출처: TypeSafe가 붙인 System One이라는 이름은 Daniel Kahneman의 책 『Thinking, Fast and Slow』에서 빌려왔다.
   2. 두 사고 방식: Kahneman이 설명한 인간의 사고에는 빠르고 자동적인 System One과 느리고 의도적인 System Two가 있다.
   3. Jev의 위치: Jev는 문장을 길게 생성하며 추론하는 모델보다 빠르고 자동적인 판단에 가까운 모델로 제시된다.

1.2. System One과 System Two의 감각적 차이

1. System One: 빠르고 자동적인 판단

   1. 즉시 떠오르는 계산: 2 * 2의 답이 4라는 사실은 머릿속에서 단계를 계산하지 않아도 바로 안다.
   2. 소프트웨어의 짧은 판단: 이메일을 읽고 환불 요청인지 아닌지 빠르게 가르는 일처럼, 복잡한 사고보다 익숙한 패턴 인식이 필요한 작업이 System One에 해당한다.

2. System Two: 느리고 의도적인 사고

   1. 단계별 계산: 17 * 24는 408이지만, 보통은 중간 계산을 차례대로 거쳐야 한다.
   2. 발표자의 농담: 발표자는 답을 직접 계산하는 대신 텔레프롬프터에서 408을 찾아 “거기 있네”라는 식으로 넘겼다. 느린 계산을 피한 작은 System One식 장면이다.
   3. AI에서의 대응: 일반적인 추론 모델은 생각의 연쇄(chain of thought)를 텍스트로 써 가며 답을 찾으므로, AI가 보여줄 수 있는 System Two에 가장 가깝다.

2. 기존 언어 모델과 Jev가 맡는 일의 차이

LLM은 텍스트 생성에 최적화되어 있지만, 소프트웨어 안의 많은 판단은 긴 설명보다 짧고 확실한 분류값을 필요로 한다.

2.1. 토큰을 생성하는 챗봇의 처리 방식

1. 일반 챗봇의 출력

   1. 토큰 단위 생성: 챗봇은 답을 한 번에 내놓지 않고 한 토큰씩 순차적으로 생성한다.
   2. Forward pass: 영상의 자동자막에 나온 “Ford pass”는 문맥상 forward pass를 가리킨다. 언어 모델은 이 순차적 생성 과정에서 텍스트를 쌓는다.

2. Reasoning model의 추가 비용

   1. 추론 과정의 텍스트화: reasoning model은 답뿐 아니라 chain of thought를 텍스트로 작성하며 작업한다.
   2. System Two에 가까운 이유: 중간 단계를 드러내며 천천히 문제를 풀기 때문에, 소프트웨어의 모든 짧은 판단에 투입하면 속도와 비용이 과해질 수 있다.

2.2. 고객지원 이메일이라는 구체적 사례

1. 입력된 이메일

   1. 고객의 주장: 고객이 “이번 달에 두 번 청구됐다. 고쳐 달라”고 고객지원팀에 이메일을 보냈다고 가정한다.
   2. 사람의 즉각적 판단: 사람은 이메일을 훑어보고 이것이 환불 요청이라는 사실을 바로 알아챈다. 이 짧은 판정이 Jev가 겨냥한 System One 작업이다.

2. 소프트웨어가 내려야 하는 세 가지 판단

   1. 환불 여부: 이 이메일이 환불 요청인가? 예 또는 아니오로 답한다.
   2. 담당 팀: Billing, Technical Support, Sales 중 어느 팀이 처리해야 하는가를 고른다.
   3. 긴급도: 얼마나 빨리 답해야 하는지, 낮음부터 긴급·Critical까지의 척도로 평가한다.

3. 기존 LLM 방식의 한계

   1. 구조화된 JSON 요청: 이메일을 LLM에 보내 세 판단의 답을 JSON 같은 구조화 형식으로 작성해 달라고 요청할 수 있다.
   2. 생성 지연: LLM은 JSON도 토큰을 하나씩 출력하므로, 세 판단이 동시에 확정되는 것이 아니라 생성 과정이 끝나기를 기다려야 한다.
   3. 신뢰도 부재: LLM에 “얼마나 확신하느냐”고 되묻더라도, 그 문장 속 숫자가 모델이 실제로 답을 만들 때 사용한 확률과 일치한다는 보장이 없다.

3. Jev의 입력·출력 계약

Jev는 상태(state)와 타입이 지정된 질문들을 함께 받고, 질문별 결정과 확률을 한 번에 반환한다.

3.1. 한 요청에 들어가는 요소

1. State

   1. 결정의 대상: state는 판단해야 할 데이터다. 여기서는 고객지원 이메일이 기본 상태가 된다.
   2. 보조 정보: 최근 고객 청구 내역 같은 데이터도 state에 포함할 수 있다.
   3. 공유 컨텍스트: 같은 요청에 들어간 각 질문이 이 상태를 함께 보지만, 질문은 서로 독립적으로 평가된다.

2. 질문 타입 세 가지

   1. Noul: 환불 요청인지 아닌지를 묻는 예·아니오 질문이다. 영상 자막의 “a null”은 TypeSafe가 부르는 Noul을 뜻한다.
   2. Choice: 담당 팀처럼 미리 준 목록에서 하나를 고르는 질문이다. 이 사례의 선택지는 Billing, Technical Support, Sales로 제한된다.
   3. Score: 긴급도처럼 낮음에서 Critical까지 순서가 있는 척도에서 점수를 매기는 질문이다.

3. 병렬 처리

   1. 단일 요청: 환불 여부·담당 팀·긴급도 세 질문을 한 요청에 함께 넣는다.
   2. 동시 반환: LLM이 JSON을 토큰별로 쓰는 동안, Jev는 텍스트를 생성하지 않고 세 답을 모두 한 번에 돌려준다.
   3. 속도와 비용: 좁은 형식의 판단에서는 생성할 토큰이 없고 결과를 파싱할 필요도 적으므로 LLM보다 빠르고 저렴하다.

3.2. 확률로 표현되는 답

1. Noul의 확률

   1. 예시 값 0.9: 환불 질문이 0.9로 돌아오면 이메일이 환불 요청일 확률이 90%라는 뜻이다.
   2. 확률과 정답의 구분: 0.9라고 해도 개별 입력에서 반드시 맞는다는 뜻은 아니며, 여러 사례에서 확률과 실제 적중률이 맞도록 보정되었다는 의미다.

2. Choice의 확률 분포

   1. 예시 값 0.85: Billing 선택지의 확률이 0.85로 돌아올 수 있다.
   2. 정의한 선택지만 허용: 담당 팀 답은 언제나 미리 정의한 Billing·Technical Support·Sales 중 하나다. 모델이 네 번째 팀을 지어낼 수 없다.

3. Score의 평가

   1. 긴급도 표현: 긴급도는 낮은 수준부터 Critical에 가까운 높은 수준까지의 점수로 돌아온다.
   2. 오답 가능성: Jev도 선택지를 잘못 고르거나 점수를 잘못 매길 수 있다. 확률은 그 판단이 맞을 가능성을 코드가 다룰 수 있게 해준다.

4. 확률을 믿을 수 있게 만드는 학습 방식

Jev의 차별점은 답을 유창하게 쓰는 능력이 아니라, 자신이 제시한 확률이 실제 결과와 맞도록 학습하는 데 있다.

4.1. 전통적인 LLM의 학습 흐름

1. Pre-training

   1. 다음 토큰 예측: 모델이 거대한 텍스트를 읽고 다음 토큰을 예측하도록 학습한다.
   2. 지식과 대화 능력의 차이: 이 과정만으로도 많은 것을 아는 모델이 되지만, 사람과 대화하는 챗봇으로 바로 쓸 수 있는 것은 아니다.

2. Post-training과 Reinforcement Learning

   1. 보상에 따른 조정: 모델이 답을 만들고, 어떤 평가기가 그 답을 점수화하면, 모델은 높은 점수를 받은 답 쪽으로 조정된다.
   2. RLHF: Reinforcement Learning from Human Feedback에서는 사람이 모델의 두 답변을 보고 더 나은 답을 고른다. 이 선택이 reward model을 학습시키고, 챗봇은 reward model이 높게 평가하는 답을 내도록 훈련된다.

3. RLHF의 과신 문제

   1. 사람이 선호하는 말투: 사람은 자신 있게 들리는 답을 좋아하는 경향이 있다.
   2. 틀려도 확신하는 모델: 그 결과 모델이 실제로는 틀린 상황에서도 매우 확신에 찬 문장을 쓰는 부작용이 생길 수 있다.

4.2. RLVR과 reasoning model의 한계

1. 검증 가능한 보상

   1. RLVR: Reinforcement Learning with Verifiable Rewards는 자동 평가가 가능한 결과를 보상한다.
   2. 수학·코드 사례: 수학 문제의 답이 맞는지, 작성한 코드가 unit test를 통과하는지를 자동으로 확인한다.
   3. 최근 reasoning model의 성능: 이런 명확한 검증 기준이 reasoning model이 수학과 코딩에서 좋아진 큰 이유다.

2. 정답만 평가하는 구조

   1. 최종 결과 중심: RLVR은 최종 답이 맞았는지를 확인하지만, 모델이 자신의 확신 수준을 제대로 아는지는 보상하지 않는다.
   2. 실행 비용: reasoning model은 답을 내기 전 chain of thought를 오래 작성할 수 있어 실행이 느리고 비싸진다.

4.3. RLCD: Calibrated Decisions를 위한 강화학습

1. Jev의 학습 목표

   1. RLCD: Jev는 Reinforcement Learning for Calibrated Decisions, 즉 보정된 의사결정을 위한 강화학습으로 훈련된다.
   2. 공개 범위의 한계: TypeSafe는 Jev의 내부 아키텍처를 많이 공개하지 않았으므로, 설명은 TypeSafe가 공개적으로 말한 동작과 학습 목표에 한정된다.
   3. 확률 자체의 보상: 각 선택지에 준 확률이 실제 결과와 맞으면 보상한다. RLCD의 C는 이 calibrated라는 목표를 가리킨다.

2. Calibration의 의미

   1. 두 축의 관계: 그래프의 가로축에 모델이 말한 확률을 놓고, 세로축에 실제로 맞았는지를 놓는다.
   2. 이상적인 대각선: 잘 보정된 모델은 확률과 실제 적중률이 함께 올라가는 대각선에 가깝다.
   3. 80%의 해석: 80%라고 말한 판단을 충분히 많이 모으면 약 80%가 맞아야 한다. 한 건의 답이 반드시 80% 확률로 맞는다는 보증은 아니다.

5. 확률을 코드의 자동화 규칙으로 바꾸기

보정된 확률을 사용하면 “모델이 맞을까?”라는 막연한 질문을 자동 처리·사람 검토·무시의 경로로 바꿀 수 있다.

5.1. 환불 요청의 임계값 설계

1. 높은 확률

   1. 범위: 확률 축의 1은 확실함, 0은 확실히 아님을 뜻한다.
   2. 자동 환불 큐: 환불 확률이 약 0.9 이상이면 정당한 환불 요청으로 보고 환불 처리 큐에 바로 보낸다. 영상 자막의 “nine”은 앞뒤 맥락상 0.9로 해석한다.

2. 중간 확률

   1. 불확실성 구간: 확률이 0.9와 0.1 사이에 있으면 자동으로 결정하기 어렵다.
   2. Human-in-the-loop: 코드가 사람 검토를 호출하고, 담당자가 이메일을 직접 확인한다.

3. 낮은 확률

   1. 자동 거부: 확률이 0.1 미만이면 환불 요청이 아니라고 보고 아무 처리도 하지 않는다.
   2. 발표자의 농담: “Keep calm and carry on”이라고 말하며 낮은 점수의 이메일은 조용히 지나가도 된다고 표현한다.

5.2. 비용에 따른 임계값 조정

1. 확률과 오류율

   1. 운영 신호: 숫자가 보정되어 있다면 선택한 임계값은 자동 경로가 대략 얼마나 자주 틀릴지도 알려준다.
   2. 보장과 추정의 구분: 임계값은 과거의 집단적 적중률을 바탕으로 한 운영 신호이지, 단일 판정이 틀리지 않는다는 인증서가 아니다.

2. 실수의 비용 반영

   1. 비싼 오류: 환불을 잘못 승인하는 등 한 번의 실수가 큰 비용을 만들면 더 높은 임계값을 선택한다.
   2. 싼 오류: 오류 비용이 낮으면 더 낮은 임계값으로 자동 처리 범위를 넓힐 수 있다.

6. 실전 활용과 한계

Jev는 고객지원 분류뿐 아니라 LLM 주변의 안전장치로 쓸 수 있지만, 텍스트 판단 모델이라는 경계를 넘지는 않는다.

6.1. Guardrail로서의 활용

1. 챗봇 앞뒤의 검사

   1. 입력·출력 검사: 챗봇으로 들어가고 나오는 메시지를 Jev가 검사하도록 둘 수 있다.
   2. Jailbreak 탐지: 데이터나 메시지에 jailbreak 시도가 있는지 빠르게 분류해 위험한 입력·출력을 막는 guardrail이 된다.

2. 다른 자동 판단

   1. 스마트한 if문: 사람이 손으로 만든 규칙이 지나치게 취약한 곳에서 분류·라우팅·긴급도 평가처럼 짧은 분기 판단을 맡긴다.
   2. 대량 적용 가능성: 판단 비용이 충분히 낮아지면 개별 이메일뿐 아니라 데이터베이스의 모든 행이나 로그 파일의 모든 줄에도 적용할 수 있다.

6.2. 현재의 한계

1. 입력 형식

   1. 텍스트 전용: 현재 Jev는 텍스트를 입력으로 받는다. 영상에서 말한 시점에는 이미지·오디오를 직접 처리하는 모델로 제시되지 않는다.
   2. 전처리 필요: 비텍스트 정보를 쓰려면 다른 시스템이 먼저 텍스트나 구조화된 필드로 바꿔야 한다.

2. 산술과 계수

   1. 수학 약점: Jev는 수학에 강하지 않다.
   2. 세기 약점: 단순히 개수를 세는 일도 잘하지 못하므로, 계산과 계수는 별도 코드나 다른 도구에 맡겨야 한다.

3. 적대적 지시

   1. 데이터 속 숨은 명령: 읽고 있는 데이터 안에 숨겨진 지시문이 있으면 Jev도 영향을 받을 수 있다.
   2. 무오류 모델이 아님: 출력 형식이 제한되어도 판단 자체를 틀릴 수 있고, 입력을 조작하는 공격을 자동으로 모두 이겨내는 것은 아니다.

7. LLM과 System One 모델을 결합하는 워크플로

System One 모델을 LLM의 대체재로 보는 대신, 빠른 분기와 느린 생성을 서로 다른 단계에 배치하는 것이 현실적인 설계다.

7.1. 고객지원 자동화의 결합 흐름

1. 첫 번째 Jev 단계

   1. 분류: Jev가 고객지원 이메일을 읽고 환불 요청인지 빠르게 판단한다.
   2. 라우팅: 결과에 따라 환불 큐나 적절한 팀으로 보낸다.

2. LLM 단계

   1. 느린 작업: LLM이 고객에게 보낼 자연스러운 답변을 작성한다.
   2. 역할 분리: 사람이 읽을 문장, 설명, 예의 바른 응답은 텍스트 생성에 강한 LLM이 맡는다.

3. 두 번째 Jev 단계

   1. 후속 응답 확인: 고객이 다시 보낸 답변을 Jev가 재분류한다.
   2. 다음 분기: 후속 메시지의 성격이나 긴급도에 따라 다시 자동 경로와 사람 검토 경로를 나눈다.

7.2. 인간 사고 방식과의 대응

1. 대부분의 일은 System One

   1. 빠른 자동 과정: 사람이 하는 일의 상당 부분도 빠르고 자동적인 System One 과정으로 처리된다.
   2. 소프트웨어 설계: Jev를 첫 번째와 마지막의 빠른 판단 단계에 놓는 것은 이 인간의 처리 방식과 닮았다.

2. 필요할 때만 System Two

   1. 복잡한 생성: 고객에게 답변을 쓰거나 실제 사고가 필요한 부분에서는 느리고 신중한 System Two에 해당하는 LLM을 호출한다.
   2. 비용·지연 절감: 모든 이메일을 LLM에 보내지 않고, 어려운 사례에만 LLM을 호출하면 전체 워크플로 비용과 지연을 줄일 수 있다.

8. Jev라는 이름과 Jevons paradox

Jev라는 이름은 19세기 경제학자의 역설을 빌려, 효율이 커지면 사용량도 폭발할 수 있다는 제품 확장 논리를 암시한다.

8.1. William Stanley Jevons의 관찰

1. 1865년의 증기기관 사례
   1. 효율 향상: 경제학자 William Stanley Jevons는 1865년에 증기기관이 더 효율적으로 변한 상황을 관찰했다.
   2. 석탄 사용 증가: 효율이 좋아졌는데도 영국은 석탄을 더 많이 사용했다.
   3. Jevons paradox: 효율이 높아져 자원 사용 단가가 낮아지면 그 자원을 쓰는 영역과 총사용량이 오히려 늘 수 있다는 현상을 Jevons paradox라고 부른다.

8.2. System One 모델에 적용한 추측

1. 저렴한 판단의 확산

   1. LLM이 못 가는 곳: 판단 호출이 Jev처럼 매우 빠르고 저렴하면, 오늘날 LLM이 너무 느리거나 비싸서 들어가지 못하는 영역에 적용할 수 있다.
   2. 세밀한 데이터 처리: 데이터베이스의 모든 행이나 로그 파일의 모든 줄에 판단을 붙이는 방식이 가능해진다.

2. 열린 결말

   1. 가능성으로 남은 주장: 발표자는 이것이 실제로 어디까지 확산될지는 “누가 알겠는가”라는 식으로 열어 둔다.
   2. 시청자 질문: 각자가 작업하는 소프트웨어에 System One 모델을 어디에 넣을 수 있을지 댓글로 알려 달라고 요청하며 마무리한다.

주요 발언 모음

“Jev는 실제로 어떤 텍스트도 쓰지 않는다.”

“사람이 이메일을 훑어보기만 해도 환불 요청인지 바로 안다. 그런 종류의 일이 Jev가 만들어진 목적이다.”

“Jev는 확률을 내놓고, 그 확률이 실제 결과와 맞을 때 보상을 받는다.”

“80% 확률이라고 말한다면, 그 판단은 약 80%의 경우에 맞아야 한다. 이것이 calibration이다.”

“LLM을 버리고 System One 모델로 완전히 바꿀 때라는 뜻은 아니다. 둘은 함께 작동할 수 있다.”

“빠르고 저렴한 판단은 LLM이 오늘날 너무 느리거나 비싼 곳, 데이터베이스의 모든 행이나 로그 파일의 모든 줄로 들어갈 수 있다.”

핵심 데이터 & 수치

• 2 * 2 = 4: 즉시 떠오르는 System One 사고의 예다.
• 17 * 24 = 408: 단계별 계산이 필요한 System Two 사고의 예이며, 발표자는 텔레프롬프터에서 답을 확인했다.
• 0.9: 환불 여부가 90% 확률로 참이라고 가정한 Jev의 Noul 출력 예시다.
• 0.85: 세 팀 선택지 중 Billing이 선택될 확률 예시다.
• 0.9 이상·0.1 미만: 높은 확률은 자동 환불 큐, 낮은 확률은 비환불 경로로 보낼 수 있고, 그 사이는 사람 검토로 보낸다.
• 80% → 약 80% 적중: 보정된 확률이 의미하는 집단 수준의 관계다.
• 1865년: William Stanley Jevons가 효율적인 증기기관과 영국의 석탄 사용 증가를 지적한 해다.

결론 및 시사점

1. 문장 생성이 모든 AI 작업의 기본값은 아니다: 소프트웨어가 필요로 하는 많은 작업은 설명문보다 제한된 선택지·점수·예/아니오와 확률이다.
2. 타입과 확률을 함께 설계하라: 답의 후보를 미리 제한하면 파싱 오류와 허구의 선택지를 줄이고, 확률을 임계값과 연결할 수 있다.
3. 확신을 자동화 신호로 사용하라: 높은 확률은 자동 처리, 중간 확률은 사람 검토, 낮은 확률은 거부로 보내는 정책을 비용에 맞춰 설계한다.
4. Calibration은 집단적 성질이다: 80%가 개별 답변의 보증이 아니므로, 실제 라벨 데이터로 임계값과 오류율을 검증해야 한다.
5. LLM과 Jev를 역할별로 배치하라: Jev는 빠른 분류·라우팅·가드레일, LLM은 복잡한 사고·답변 생성, Jev는 마지막 검증을 맡는 구조가 자연스럽다.
6. 한계를 별도 시스템으로 보완하라: 수학·계수·비텍스트 입력·적대적 지시는 코드나 다른 모델로 처리하고, Jev의 출력 형식 제한을 판단 정확성과 혼동하지 않는다.
7. 효율 향상은 사용량 증가를 부를 수 있다: Jevons paradox처럼 단가가 낮아진 판단은 데이터베이스 행 단위·로그 줄 단위까지 새 적용처를 만들 수 있다.

핵심 요약 (20줄)

1. Jev는 TypeSafe가 만든 System One 모델로, 문장을 생성하지 않고 미리 정의한 답과 확률을 반환한다.
2. System One은 빠르고 자동적인 판단이며 System Two는 느리고 의도적인 사고라는 Kahneman의 구분을 따른다.
3. 2 곱하기 2는 즉시 답하지만 17 곱하기 24는 408을 단계적으로 계산해야 하는 차이가 두 사고를 보여준다.
4. 일반 챗봇은 답을 토큰 단위로 생성하고 reasoning model은 chain of thought까지 텍스트로 작성한다.
5. 소프트웨어의 많은 결정은 긴 추론보다 고객지원 이메일을 빠르게 분류하는 System One 판단에 가깝다.
6. 이중 청구 이메일은 환불 여부·담당 팀·긴급도를 각각 판단해야 하는 대표적인 고객지원 사례다.
7. LLM은 이 답을 JSON으로 만들 수 있지만 토큰을 순차 생성하고 실제 확신도와 일치하는 확률을 안정적으로 주지 못한다.
8. Jev는 이메일과 최근 청구 내역으로 구성된 state와 타입이 지정된 질문을 함께 입력받는다.
9. Noul은 예·아니오, Choice는 제한된 목록 선택, Score는 순서가 있는 척도 평가를 수행한다.
10. 세 질문은 한 요청에서 병렬 처리되어 텍스트를 생성하는 LLM보다 빠르고 저렴하게 답을 돌려준다.
11. 환불 Noul이 0.9라면 환불 요청일 확률 90%, Billing Choice가 0.85라면 Billing일 확률 85%라는 뜻이다.
12. 확률이 높아도 단일 사례의 정답을 보증하지 않으며, Jev도 선택과 점수를 틀릴 수 있다.
13. 전통적인 LLM은 pre-training으로 다음 토큰을 배우고 post-training에서 보상 점수가 높은 답을 내도록 조정된다.
14. RLHF는 사람이 선호하는 답을 보상하므로 모델이 틀렸을 때도 자신 있게 말하는 부작용을 만들 수 있다.
15. RLVR은 수학 정답이나 unit test 통과 여부를 검증하지만 확신 수준이나 calibration 자체를 보상하지 않는다.
16. Jev는 RLCD로 확률이 실제 결과와 맞도록 훈련되며 80%라고 말한 판단이 장기적으로 약 80% 맞아야 한다.
17. 약 0.9 이상은 자동 환불 큐, 0.1 미만은 비환불 경로, 중간 구간은 사람 검토로 라우팅할 수 있다.
18. Jev는 챗봇의 jailbreak를 검사하는 guardrail이 될 수 있지만 텍스트만 받고 수학·계수에는 약하다.
19. 현실적인 구조는 Jev가 빠르게 분류하고 LLM이 답변을 쓴 뒤 Jev가 고객의 후속 응답을 다시 분류하는 방식이다.
20. Jevons paradox처럼 판단 비용이 낮아지면 데이터베이스의 모든 행과 로그의 모든 줄까지 AI 판단이 확산될 수 있다.