Knock Blog

Concept of JEV

12 min read10 views
System OneJevLLMTypesafe AIAI

AI가 반드시 무언가를 생성해야 할까?

어떤 소프트웨어에서는 긴 문장을 생성하는 능력보다 현재 주어진 상황을 보고 빠르게 하나의 판단을 내려주는 능력이 더 중요할 수 있습니다.

예를 들어 다음과 같은 문제들입니다.

  • 이 문의는 환불 요청인가?
  • 이 티켓은 어느 부서로 보내야 하는가?
  • 이 메시지의 위험도는 어느 정도인가?
  • 지금 자동으로 처리해도 되는가?
  • 아니면 사람에게 검토를 요청해야 하는가?

TypeSafe의 Jev는 바로 이런 종류의 문제를 위해 만들어진 모델입니다.

1. Definition, Concept of Jev

TypeSafe는 Jev를 다음과 같이 소개합니다.

“Jev is TypeSafe’s flagship model and the first System One model.”

즉, Jev는 TypeSafe가 공개한 첫 번째 System One Model입니다. System One Model은 소프트웨어에서 직접 사용할 수 있는 빠르고 구조화된 판단을 만드는 것을 목적으로 합니다.

TypeSafe의 공식 발표문에는 Jev를 조금 더 직관적으로 설명하는 표현도 등장합니다.

“unstructured state in, typed probabilistic decisions out.”

비정형적인 상태를 입력하면 타입이 정해진 확률적 판단이 출력된다는 의미입니다.

공식 문서에서도 Jev의 사용 방식을 다음과 같이 설명하고 있습니다.

“Send state and typed questions; get structured answers your code can use directly.”

즉, Jev에게는 State와 Typed Question 크게 두 가지를 전달합니다.

그리고 그 결과로 코드가 사용할 수 있는 구조화된 판단을 받습니다.

이를 간단한 함수 형태로 추상화해보면 다음과 같이 표현할 수 있습니다.

f(state, question)
→ typed decision + probability

물론 실제 Jev API의 모든 반환값을 표현한 엄밀한 수학식은 아닙니다.

하지만 Jev가 무엇을 목적으로 만들어진 모델인지 이해하기 위한 mental model로는 꽤 유용합니다.

핵심은 다음과 같습니다.

Jev는 어떤 상태에 대한 판단을 수행하고, 그 판단을 프로그램이 직접 사용할 수 있는 타입과 확률의 형태로 반환한다.

2. 왜 이런 모델이 필요한가?

Jev를 이해하려면 먼저 소프트웨어 안에서 AI의 판단을 사용한다고 생각해볼 필요가 있습니다.

예를 들어 고객이 다음과 같은 문의를 남겼다고 가정해보겠습니다.

"결제가 두 번 됐습니다.
중복으로 결제된 금액을 환불해주세요."

우리가 알고 싶은 것은 아주 단순할 수 있습니다.

이 고객은 환불을 요청하고 있는가?

혹은,

이 문의는 어느 부서로 전달해야 하는가?

일반적인 생성형 모델에게 질문한다면 다음처럼 답할 수도 있습니다.

고객은 중복 결제로 인한 환불을 요청하고 있으므로
Billing 팀에서 처리하는 것이 적절합니다.

사람이 읽기에는 좋은 답입니다.

그런데 프로그램 입장에서는 이야기가 조금 다릅니다.

프로그램이 실제로 필요로 하는 것은 다음에 더 가깝습니다.

request_type = refund
team = billing

그리고 자동화를 하려면 하나의 정보가 더 필요합니다.

이 판단을 어느 정도까지 믿어도 되는가?

예를 들어 billing일 가능성이 99%인 상황과 billing 51%, account 49%인 상황을 동일하게 처리하면 위험할 수 있습니다.

Jev가 해결하려는 문제가 바로 이 지점입니다.

TypeSafe는 LLM처럼 텍스트를 생성한 뒤 다시 parsing하는 대신, 처음부터 typed value와 probability distribution을 반환하는 모델을 만들고자 합니다. 공식 문서도 Jev에서는 별도의 text generation이나 parsing 없이 코드가 결과를 직접 branch, sort, route하는 것을 핵심적인 특징으로 설명합니다.

따라서 Jev의 목표를 단순하게 표현하면 다음과 같습니다.

AI가 사람에게 설명한다
        ↓
AI가 프로그램에게 판단을 제공한다

3. Jev의 핵심 개념

Jev의 구조는 크게 다음 요소들로 나누어 이해할 수 있습니다.

State
    ↓
Typed Question
    ↓
Jev
    ↓
Typed Decision
    +
Probability / Confidence

하나씩 살펴보겠습니다.

3.1 State

가장 먼저 이해해야 하는 것은 State입니다.

TypeSafe는 State를 System One Model에게 평가하도록 전달하는 내용이라고 정의합니다. 단순한 문자열일 수도 있고 JSON object나 array일 수도 있습니다.

예를 들어 앞에서 사용했던 고객 문의를 State로 표현하면 다음과 같이 만들 수 있습니다.

{
  "ticket": {
    "message": "결제가 두 번 됐습니다. 환불해주세요."
  },
  "order": {
    "id": "A-104",
    "charges": [
      {
        "amount": 49000,
        "status": "captured"
      },
      {
        "amount": 49000,
        "status": "captured"
      }
    ]
  },
  "refund_policy": "중복 결제는 환불할 수 있습니다."
}

여기에는 고객의 메시지만 있는 것이 아닙니다.

  • 고객이 무슨 말을 했는지
  • 실제 결제가 몇 번 발생했는지
  • 현재 회사의 환불 정책은 무엇인지

등 판단에 필요한 현재 상황이 들어갑니다.

따라서 State를 어렵게 생각할 필요는 없습니다.

State = Jev가 판단할 때 참고해야 하는 현재의 context

라고 이해하면 됩니다.

공식 문서에서도 관련된 정보들을 하나의 State에 모으되, 판단에 필요하지 않은 정보까지 무작정 넣지 않는 방식을 권장합니다. 불필요한 context는 현재 Jev의 정확도를 떨어뜨릴 수 있다고 명시하고 있습니다.

3.2 Typed Question

State만 전달한다고 Jev가 알아서 무엇을 해야 할지 결정하는 것은 아닙니다.

우리가 State의 어떤 속성을 판단하고 싶은지 질문을 정의해야 합니다.

예를 들어:

Does the customer request a refund?

또는:

Which team should handle this ticket?

와 같은 질문입니다.

여기서 중요한 것은 Jev의 질문이 가능한 한 작고 명확한 하나의 판단이어야 한다는 점입니다.

TypeSafe는 이를 atomic question으로 설명합니다.

좋은 질문은:

이 메시지가 긴급성을 나타내는가?

와 같은 형태입니다.

반면,

이 고객 문의를 전반적으로 분석해서
가장 좋은 대응 방안을 결정해줘.

처럼 여러 단계의 판단이 섞인 질문은 Jev가 목표로 하는 형태가 아닙니다.

TypeSafe는 복합적인 판단이 필요하다면 여러 개의 작은 질문으로 나누고, 결과를 코드에서 다시 조합할 것을 권장합니다.

3.3 Typed Decision

그렇다면 왜 Typed Question이라고 부를까요?

질문의 가능한 답의 형태를 미리 정의할 수 있기 때문입니다.

예를 들어 담당 부서를 결정한다고 해보겠습니다.

billing
orders
account

이라는 선택지를 정의할 수 있습니다.

그러면 Jev의 판단 결과는 자유로운 문장이 아니라 이 answer space를 기준으로 만들어집니다.

billing

그리고 각 선택지에 대한 probability distribution도 받을 수 있습니다.

billing    0.91
orders     0.06
account    0.03

공식 문서에 따르면 Jev의 각 answer는 사용자가 정의한 option 또는 level 안으로 제한되며, 프로그램은 생성된 문장에서 다시 값을 추출할 필요가 없습니다.

이 부분을 한 문장으로 표현하면 다음과 같습니다.

Jev에서는 AI의 판단 결과가 자연어 문장이 아니라 프로그램이 다룰 수 있는 값이 된다.

3.4 Probability

Jev의 중요한 특징은 decision 하나만 반환하는 것이 아니라 그 판단을 구성하는 확률도 함께 제공한다는 것입니다.

예를 들어:

billing     0.82
orders      0.11
account     0.07

라는 결과가 있다고 생각해봅시다.

가장 높은 확률을 가진 billing이 Choice의 결과가 되겠지만, 애플리케이션은 필요하다면 전체 probability distribution까지 활용할 수 있습니다.

따라서 Jev의 판단은 단순히 정답 = billing

이라고 선언하는 것이 아니라, 현재 State를 기준으로 billing이라는 판단에 가장 많은 확률이 분포되어 있다에 더 가깝습니다.

3.5 Calibration

그렇다면 Jev가 반환하는 probability에서 중요한 것은 무엇일까요?

TypeSafe가 특히 강조하는 것이 Calibration입니다.

System One Model은 단순히 확률처럼 보이는 숫자를 출력하는 것을 목표로 하지 않습니다.

TypeSafe의 설명에 따르면 모델이 비슷한 상황들에 대해 0.8 정도의 확률을 부여했다면, 그러한 예측 집단에서는 실제 결과도 그 확률과 대응하도록 학습시키는 것을 목표로 합니다. 다만 calibration은 예측 집단에서 측정되는 특성이지, 개별 예측이 반드시 맞는다는 보장은 아닙니다.

개념적으로 표현하면

모델이 약 80%라고 판단한 사례들을 모았을 때
→ 실제 결과도 약 80% 수준에서 일치하도록
확률을 의미 있게 만드는 것

입니다.

TypeSafe는 이를 위해 **RLCD(Reinforcement Learning for Calibrated Decisions)**라는 학습 방식을 사용한다고 밝히고 있습니다.

따라서 Jev에서 probability는 단순한 부가 정보가 아니라 소프트웨어가 다음 행동을 결정하는 입력으로 활용될 수 있습니다.

3.6 Confidence

여기서 Probability와 함께 등장하는 개념이 Confidence입니다.

둘은 같은 값이 아닙니다.

예를 들어 다음 두 probability distribution을 비교해보겠습니다.

Case A
billing    0.51
orders     0.49

Case B
billing    0.98
orders     0.02

두 경우 모두 최종 Choice는 billing입니다.

하지만 두 번째 결과가 훨씬 명확한 distribution을 가지고 있습니다.

TypeSafe의 confidence는 이 probability distribution이 얼마나 한쪽으로 명확하게 집중되어 있는지를 0~1 값으로 요약한 통계값입니다.

따라서 코드는 다음과 같은 정책을 만들 수 있습니다.

High confidence
→ 자동 실행
Medium confidence
→ 추가 정보 요청
Low confidence
→ Human review

실제 threshold는 업무의 위험도와 자체 evaluation에 맞추어 결정해야 합니다. TypeSafe 역시 하나의 공통 threshold를 권장하지 않고, action의 위험도에 따라 다르게 설정할 것을 권장합니다.

참고로 현재 Jev에서는 Choice와 Score가 별도의 confidence 값을 제공하고, Noul은 별도의 confidence를 반환하지 않습니다. Noul 자체의 0~1 값이 Yes에 대한 probability입니다.

4. Jev의 세 가지 Decision Primitive

그렇다면 Jev에게 실제로 어떤 형태의 질문을 할 수 있을까요?

현재 TypeSafe는 세 가지 primitive를 제공합니다.

Noul
Choice
Score

TypeSafe는 이 primitive들을 코드에서 조합할 수 있는 작은 typed building block으로 설명합니다.

앞에서 사용한 고객 문의 예제를 그대로 이용해보겠습니다.

"고객이 결제가 두 번 되었다며
중복 금액을 환불해달라고 요청했다."

4.1 Noul

Noul은 Yes / No 형태의 판단에 사용합니다.

예를 들어:

Does the customer request a refund?

라는 질문을 할 수 있습니다.

결과가:

noul = 0.97

이라면,

P(refund_requested = true) ≈ 0.97

처럼 이해할 수 있습니다.

Noul은 다음과 같은 문제에 적합합니다.

환불 요청인가?
개인정보를 포함하고 있는가?
긴급한 상황인가?
정책을 위반하고 있는가?

즉 하나의 조건이 참인지 아닌지에 대한 확률적 판단입니다.

4.2 Choice

Choice는 정해진 여러 옵션 중 어떤 것이 가장 적절한지 판단하는 primitive입니다.

예를 들어:

Which team should handle this ticket?

가능한 선택지를:

billing
orders
account

로 정의할 수 있습니다.

결과는 개념적으로 다음처럼 표현할 수 있습니다.

choice = billing
probabilities:
billing    0.91
orders     0.06
account    0.03

따라서 Choice는 다음과 같은 문제에 활용하기 쉽습니다.

Ticket routing
Intent classification
Document classification
Tool selection

4.3 Score

Score는 단순한 Yes/No나 category가 아니라 어떤 연속적인 정도를 판단하고 싶을 때 사용합니다.

예를 들어 고객의 불만 정도를:

0 = Calm
1 = Concerned
2 = Frustrated
3 = Very angry

와 같이 정의할 수 있습니다.

그러면 Jev는 해당 State가 이 spectrum의 어디쯤에 해당하는지를 판단합니다.

TypeSafe의 Score는 반드시 하나의 integer level만 반환하는 것이 아니라 정의된 level 사이의 위치를 나타낼 수도 있습니다. 동시에 각 level에 대한 probability distribution과 confidence도 제공합니다.

예를 들어:

frustration score = 1.7

과 같은 결과가 가능할 수 있습니다.

따라서 Score는:

위험도
심각도
사용자의 불만 정도
품질 수준
우선순위

처럼 정도의 차이가 중요한 판단에 활용할 수 있습니다.

5. 그래서 실제 프로그램에서는 어떻게 사용하는가?

여기까지 보면 Jev가 마치 독립적인 AI Agent처럼 보일 수도 있습니다.

하지만 TypeSafe가 Jev에 대해 제안하는 아키텍처는 오히려 반대에 가깝습니다.

공식 문서는 System One에 대해 명시적으로 Agent가 아니라 AI-powered software를 구축하기 위한 모델이라고 설명하며, control flow와 deterministic logic, side effect는 코드에 남겨둘 것을 권장합니다.

즉 Jev의 역할은:

Workflow 전체를 관리한다

가 아니라:

Workflow의 특정 지점에 필요한
AI Judgment를 제공한다

입니다.

전체 구조는 다음과 같이 생각할 수 있습니다.

Application State
       │
       ▼
      Jev
       │
       ▼
Decision + Probability
       │
       ▼
Application Code
       │
 ┌─────┼─────────┐
 ▼     ▼         ▼
Act   Ask More   Escalate

예를 들어:

if (refundProbability > 0.95) {
  processRefund();
} else if (refundProbability > 0.7) {
  requestMoreInformation();
} else {
  routeToHumanReview();
}

와 같은 구조입니다.

물론 실제 서비스에서 어떤 threshold를 사용할지는 자체 데이터와 risk에 맞춰 검증해야 합니다.

핵심은 Jev가 side effect를 결정해서 마음대로 실행하는 것이 아니라, 판단을 제공하고 code가 최종 행동을 결정한다는 것입니다.

TypeSafe는 이를 다음과 같은 설계 원칙으로 정리합니다.

Deterministic한 문제
→ Code
Unstructured data에 대한 Judgment
→ Jev
최종 Control Flow
→ 다시 Code

개인적으로는 이 부분이 Jev를 이해하는 데 가장 중요한 지점이라고 생각합니다.

6. 기존 방식과 무엇이 다른가?

6.1 LLM과 Jev

Jev를 이해하기 위해 LLM의 구조를 깊게 알아야 할 필요는 없습니다.

둘의 역할 차이만 이해해도 충분합니다.

일반적인 LLM 활용 Jev
주요 목적 생성 및 범용 추론 구조화된 Judgment
주요 입력 Prompt / Messages State + Typed Question
주요 출력 생성된 Text Typed Decision
Answer Space Open-ended 미리 정의됨
Probability 일반적으로 application signal로 직접 사용하지 않음 Decision probability 제공
적합한 문제 Generation, reasoning Classification, scoring, routing 등

System One Model 역시 자연어를 이해합니다.

다만 TypeSafe가 강조하는 차이는 자연어를 이해한 뒤 무엇을 출력하도록 모델을 설계했는가에 있습니다.

LLM이 주로 생성된 text를 반환한다면 Jev는 typed decision과 probability를 반환합니다.

따라서 어느 한쪽이 더 우월하다기보다는 해결하려는 문제 자체가 다르다고 보는 편이 적절합니다.

6.2 Structured Output과는 무엇이 다른가?

여기까지 읽으면 다음과 같은 의문이 생길 수 있습니다.

"LLM에서도 JSON Schema나 Structured Output을 사용할 수 있는데 굳이 Jev가 필요한가?"

출력의 모양만 보면 비슷해 보일 수 있습니다.

하지만 TypeSafe가 주장하는 차이는 출력 format보다 모델의 학습 목적에 있습니다.

Structured Output은 일반적으로 생성 모델의 출력을 특정 schema에 맞도록 제한합니다.

LLM
↓
Generation
↓
Schema-constrained output

반면 TypeSafe는 System One Model을 처음부터:

State
↓
Structured Judgment
↓
Probability Distribution

을 수행하도록 설계하고 학습했다고 설명합니다. 특히 Jev는 typed decision과 calibrated probability를 자동화를 위한 주요 interface로 삼습니다.

즉 단순히:

"JSON으로 반환한다."

가 Jev의 특징은 아닙니다.

더 중요한 것은:

모델 자체의 최적화 대상이 structured decision이라는 점

입니다.

6.3 Agent와는 무엇이 다른가?

Agent는 일반적으로 현재 상황을 보고:

무엇을 할지 결정
↓
도구 실행
↓
결과 관찰
↓
다음 행동 결정

과 같은 control loop를 가지고 있습니다.

반면 Jev 자체는 다음 행동을 실행하거나 전체 workflow를 소유하지 않습니다.

TypeSafe는 공식적으로 System One을 agent가 아니며, 스스로 다음 action을 선택하는 모델이 아니다라고 설명합니다.

따라서 둘은 다음과 같이 구분할 수 있습니다.

Agent
= Workflow / Orchestration / Control Loop
Jev
= Judgment / Decision Primitive

둘을 함께 사용하는 것도 가능합니다.

예를 들어 Agent 내부에서:

Observe
   ↓
Jev
   ↓
retry      0.82
rollback   0.12
human      0.06
   ↓
Agent가 실제 Action 실행

처럼 Jev를 router나 judge로 사용할 수도 있습니다.

같은 관점에서 Ralph Loop와 비교한다면:

Ralph Loop
= 반복 실행과 검증을 관리하는 Control Pattern
Jev
= 그 과정에서 특정 State에 대한
  Judgment를 제공할 수 있는 Model

이라고 구분하는 것이 자연스럽습니다.

7. Jev는 어디에 사용할 수 있을까?

Jev가 적합한 문제들의 공통점은 비교적 명확합니다.

무언가를 새롭게 생성해야 하는 문제가 아니라, 주어진 정보를 바탕으로 판단해야 하는 문제입니다.

예를 들어:

Intent Classification
"사용자가 무엇을 원하는가?"

Ticket Routing
"어느 팀에서 처리해야 하는가?"

Risk Scoring
"현재 상황의 위험도가 어느 정도인가?"

Moderation
"이 콘텐츠가 특정 정책을 위반하는가?"

Workflow Branching
"어느 처리 경로로 보내야 하는가?"

Verification
"이 결과가 주어진 조건을 충족하는가?"

등을 생각할 수 있습니다.

TypeSafe 역시 Jev의 대표적인 활용 형태로 classify, route, score, verify, branch 등 AI-powered workflow 안의 판단을 강조하고 있습니다.

특히 여러 판단이 필요한 경우 Jev는 질문을 한 요청 안에서 독립적이고 병렬적으로 평가할 수 있습니다.

예를 들어 하나의 고객 문의에 대해:

refund_requested ── Noul
fraud_risk ───────── Score
routing ──────────── Choice
frustration ──────── Score
urgent ───────────── Noul

를 한 번에 질문할 수 있습니다.

TypeSafe의 문서에 따르면 같은 State를 사용하는 question들은 서로 독립적으로 평가되며 병렬로 처리됩니다.

그리고 최종 판단은 코드에서 조합합니다.

AI Judgment
+
Deterministic Logic
+
Business Rule
=
Application Decision

이 구조가 Jev를 활용하는 핵심 패턴이라고 볼 수 있습니다.

8. 그렇다면 Jev는 무엇을 잘하지 못할까?

여기서 중요한 점은 Jev를 범용적인 reasoning model로 이해하면 안 된다는 것입니다.

TypeSafe 역시 현재 Jev 1.13의 한계를 공식 문서에 공개하고 있습니다.

현재 문서상 주요 failure mode에는 다음과 같은 것들이 있습니다.

  • 정확한 arithmetic
  • Counting
  • 날짜 및 시간 계산
  • 여러 단계의 indirection
  • 불필요하게 큰 State
  • 복잡하거나 모호한 instruction
  • Text generation
  • 여러 개의 판단이 섞여 있는 질문

특히 공식 문서에서는 아주 직접적으로:

“Jev is not a calculator.”

라고 표현합니다.

예를 들어:

107 × 239는 얼마인가?

같은 문제를 Jev에게 맡기는 것은 적절하지 않습니다.

코드가 정확하게 계산할 수 있는 문제는 코드가 처리하는 것이 좋습니다.

마찬가지로:

이 회사의 시장 상황과 경쟁 환경,
재무 상태와 기술력을 모두 분석하고
5년 뒤 성공 가능성을 판단해줘.

처럼 여러 단계의 복합적인 reasoning이 필요한 문제 역시 Jev의 이상적인 사용 방식은 아닙니다.

TypeSafe는 이런 문제를 작은 독립적인 판단으로 분해한 뒤 코드에서 다시 조합할 것을 권장합니다. 현재 Jev 1.13 문서도 여러 단계의 indirection이 필요한 System Two 형태의 task를 피하라고 명시합니다.

즉:

Deep reasoning
Planning
Generation

보다는

Classification
Assessment
Scoring
Verification
Routing

에 가까운 문제를 위한 모델입니다.

9. 그래서 Jev를 어떻게 이해하면 될까?

다시 처음에 사용했던 식으로 돌아가 보겠습니다.

f(state, question)
→ typed decision + probability

처음에는 단순히:

"State를 넣으면 확률이 나오는 모델인가?"

정도로 보일 수 있습니다.

하지만 Jev의 핵심은 단순한 probability prediction보다 조금 더 넓습니다.

Jev는:

  1. 현재 판단에 필요한 State를 입력받고
  2. 작고 명확하게 정의된 Typed Question을 평가하며
  3. 프로그램이 직접 사용할 수 있는 Typed Decision과 probability를 반환하고
  4. 애플리케이션은 그 결과를 기존 코드와 결합하여 실제 workflow를 구성합니다.

이를 전체 구조로 표현하면 다음과 같습니다.

          `Software`  
    `┌─────────────────┐`  
    `│      State      │`  
    `└────────┬────────┘`  
             `│`  
             `▼`  
    `┌─────────────────┐`  
    `│       Jev       │`  
    `│                 │`  
    `│ Noul            │`  
    `│ Choice          │`  
    `│ Score           │`  
    `└────────┬────────┘`  
             `│`  
             `▼`  
   `Typed Decision`  
   `+ Probability`  
   `+ Confidence`  
             `│`  
             `▼`  
    `┌─────────────────┐`  
    `│      Code       │`  
    `│                 │`  
    `│ Business Rules  │`  
    `│ Thresholds      │`  
    `│ Control Flow    │`  
    `└────────┬────────┘`  
             `│`  
   `┌─────────┼──────────┐`  
   `▼         ▼          ▼`  
  `Act    More Info    Escalate`

따라서 Jev를 단순히 **"또 하나의 AI 모델"**이라고 이해하는 것보다 다음과 같이 생각하면 조금 더 본질에 가깝다고 생각합니다.

Jev는 소프트웨어 내부에서 사람의 직관적인 판단이 필요했던 부분을, typed probabilistic decision이라는 형태로 제공하기 위한 AI primitive다.

TypeSafe 역시 System One의 설계 방향을 기존 소프트웨어 workflow는 코드가 소유하고, AI는 그 안의 좁고 구조화된 판단을 담당하는 형태로 설명합니다.

그래서 개인적으로 Jev와 기존 생성형 모델의 차이를 가장 간단하게 표현하면 다음과 같습니다.

Generative Model
"What should I generate?"

반면 Jev는:

"What judgment should I make
about this state?"

에 가깝습니다.

물론 Jev는 아직 초기 단계의 모델입니다.

TypeSafe가 발표한 calibration, reliability, 속도와 비용상의 이점이 실제 다양한 production workload에서도 어느 정도 유지되는지는 앞으로 더 많은 사례와 독립적인 평가가 필요할 것입니다. TypeSafe 역시 현재 Jev의 failure mode를 별도로 문서화하고 있으며, 공개한 workflow evaluation에도 자체 평가라는 점에서 발생할 수 있는 bias를 명시하고 있습니다.

그럼에도 Jev가 제시하는 질문 자체는 꽤 흥미롭습니다.

AI가 소프트웨어에 들어가기 위해 반드시 Agent나 Chatbot 형태여야 하는가?

Jev와 System One Model은 이에 대해 다른 방향을 제안합니다.

AI에게 workflow 전체를 맡기는 대신, 기존 소프트웨어 안에 AI의 판단 능력을 하나의 primitive처럼 집어넣는 것.

이것이 현재 Jev가 제안하고 있는 가장 핵심적인 개념이라고 볼 수 있습니다.

References

TypeSafe — Introduction
Jev의 기본 정의, typed answer, probability distribution, Choice/Score/Noul에 대한 공식 문서. TypeSafe Introduction

TypeSafe — System One
System One Model의 정의와 일반적인 LLM과의 개념적 차이를 설명합니다. System One Documentation

TypeSafe — State
Jev의 State가 무엇인지와 structured state 구성 방법을 설명합니다. State Documentation

TypeSafe — Primitives
Choice, Score, Noul의 의미와 question 설계 방법을 설명합니다. Primitives Documentation

TypeSafe — Confidence
Probability와 Confidence의 차이 및 confidence gating 패턴을 설명합니다. Confidence Documentation

TypeSafe — How to build with TypeSafe
Jev를 Agent가 아니라 기존 코드와 조합하는 방법을 가장 구체적으로 설명하는 문서입니다. How to build with TypeSafe

TypeSafe — Jev 1.13 Jaggedness
현재 Jev의 알려진 한계와 failure mode를 정리한 공식 문서입니다. Jev 1.13 Jaggedness

TypeSafe — Introducing System One Models & Jev
TypeSafe 창업자 Diogo Almeida가 작성한 Jev 공식 발표문으로, Jev의 설계 철학과 RLCD를 소개합니다. Introducing System One Models & Jev

Comments

Loading comments...