System One 모델

LLM과의 차이점

LLM은 텍스트를 이어 쓰도록 학습됩니다. System One 모델은 보정된 결정을 내리도록 학습됩니다. 확률이 예측 집단 전반의 불확실성을 반영하도록 실제 결과에 맞춰 최적화됩니다. 보정됐다고 해서 개별 답변의 정답 여부가 보장되지는 않습니다. 하지만 문단을 파싱하는 대신 코드에 처리, 검토, 상향 전달 같은 관문을 설정할 수 있습니다.

Jev에 이메일이나 함수를 작성해 달라고 요청하는 일은 없습니다. 대신 티켓을 어느 대기열에서 담당해야 하는지, 고객이 얼마나 불만스러워 보이는지, 메시지가 환불을 요청하는지를 묻습니다. TypeSafe의 개념 페이지에 있는 표도 이 세 가지 예시를 사용합니다. Choice는 choice: "billing"을, Score는 0-2 불만 척도에서 1.4를, Noul는 예/아니요 환불 확인에 0.95를 반환할 수 있습니다.

System One라는 이름은 Daniel Kahneman의 『생각에 관한 생각』에서 유래했습니다. 시스템 1은 빠르고 직관적이며, 시스템 2는 더 느리고 신중합니다. TypeSafe는 빠른 판단을 모델에 맡기고 느린 제어 흐름을 애플리케이션에 둡니다. 긴 간접 추론 사슬이나 자유 형식 글쓰기가 필요한 작업은 Jev 1.13가 아니라 생성 모델이나 코드가 담당해야 합니다.

RLHF 대신 RLCD

TypeSafe는 Reinforcement Learning for Calibrated Decisions(RLCD)으로 Jev을 훈련합니다. RLHF은 채팅 모델이 사용자에게 호의적으로 답하도록 만드는 데 쓰이는 방식입니다. RLVR은 장문 추론 모델에 일반적으로 쓰이는 방식입니다. RLCD은 TypeSafe이 System One에 대해 설명하는 방식으로, 유창한 토큰 대신 보정된 결정에 보상을 줍니다. 출시 게시물에서는 새로운 아키텍처와 하나의 state을 기준으로 여러 질문을 평가하는 병렬 샘플러도 언급합니다.

가중치를 공유하므로 고객 데이터로 Jev를 미세 조정하거나 LoRA로 조정하지 않습니다. 독점 기록은 state에 넣으세요. 도메인 규칙은 지침과 기준으로 표현하세요. 광범위한 판단은 원자적 질문으로 나누고, 숫자는 코드에서 결합하세요. 비공개 사본을 학습하지 않고 특화하는 방법으로 문서에서 제시하는 방식은 복합 점수 계산과 Jev의 확률을 입력으로 쓰는 후속 고전 모델입니다.

현재 Jev는 텍스트만 받습니다. 문자열, JSON 객체, 텍스트 배열은 허용되지만 픽셀과 파형은 허용되지 않습니다. 주 학습 언어는 영어입니다. CJK와 기타 문자 체계도 처리하지만 정확도가 낮으므로 비영어 워크로드를 배정하기 전에 테스트하세요. Choice와 Score의 Confidence를 활용하면 정확도가 낮은 언어를 사람이 검토하도록 하는 것이 실용적입니다.

대규모 워크플로 내부의 빠른 판단

문서에 나온 환불 요청 처리 절차는 다음과 같습니다. 메시지, 거래 내역, 정책으로 state를 구성하고, 독립적인 질문을 함께 묻습니다(환불을 요청했는가, 근거에 중복 청구가 나타나는가, 정책상 허용되는가). 그런 다음 답변을 결정론적 검사와 결합해 처리하거나 검토하도록 배정합니다. Primitives를 마련한 뒤에는 이를 조합하면 됩니다. 출력에 타입이 지정되므로 코드는 남은 산문을 파싱하지 않고도 답변을 검사할 수 있습니다.

Speculative fan-out은 이 방식을 저렴하게 만드는 패턴입니다. 특정 기기 유형이나 의도를 전제로 한 질문을 비롯해 필요하지 않을 수도 있는 질문까지 보내고, 호출 후 관련 없는 결과를 버립니다. 순차 왕복 호출은 각 단계마다 기다려야 합니다. Jev은 맵을 병렬로 평가하므로 질문이 늘어도 지연 시간은 거의 변하지 않습니다. 그래서 스마트 홈 데모에서는 범주, 도메인, 기기, 동작을 한꺼번에 질문할 수 있습니다.

System One 모델은 typesafe-sdk, @typesafe-ai/sdk 또는 POST https://api.typesafe.ai/v1/systemone. 방식으로 호출하세요. model 필드로 빌드를 선택합니다. 문서의 예시에서는 현재 jev-1.13.0를 가리키는 jev-latest를 사용합니다. state 구조와 Primitives로 시작한 뒤, 자동 부작용이 발생하기 전에 confidence 관문을 추가하세요.

System One 외부에서 처리할 작업

생성, 장기 계획, 도구를 사용하는 에이전트는 Kahneman의 용어로 시스템 2 작업입니다. Jev 1.13는 환불 이메일이나 SQL, 다음 Wikipedia 문단을 작성하지 않습니다. 대신 티켓이 환불 관련인지, 어느 대기열에서 담당해야 하는지, 그 판단을 얼마나 확신하는지 알려 줍니다. 실제로 토큰을 생성해야 할 때는 생성 모델과 함께 사용하세요.

수치의 동일성 판단도 지원하지 않습니다. 개수 계산, 날짜 순서, 16진수 거리는 코드에서 처리해야 합니다. 이러한 경계 사례는 jaggedness 페이지에 정리되어 있으며, 마지막 검토일은 17 September 2026입니다. 이 목록을 무시하는 System One 워크플로는 보정이 잘된 것처럼 보여도 문자 그대로 잘못 읽은 결과를 기준으로 라우팅하게 됩니다.

TypeSafe이 이미지 입력을 출시하기 전까지는 픽셀을 사용할 수 없습니다. Doom, Wikiracing, 스마트 홈 어시스턴트는 모두 텍스트를 전송합니다. 제품이 카메라를 사용한다면 먼저 내용을 텍스트로 옮기거나 묘사하세요. 오디오 제품에도 같은 규칙이 적용됩니다. 64k와 32k 한도는 프레임이 아니라 토큰 기준입니다.

현재 System One는 공개 모델이 하나뿐인 제품 클래스입니다. TypeSafe가 같은 엔드포인트에 두 번째 모델을 출시하면 model 필드로 선택할 수 있습니다. 그전까지 jev-1.13.0는 jev-latest와 jev-preview가 가리키는 버전 지정 ID입니다. 다른 모든 채팅 또는 추론 모델은 같은 전체 워크플로에 있더라도 별도 클래스로 취급하세요.

RLCD는 TypeSafe가 이 클래스에 사용한다고 밝힌 학습 방식입니다. 요청에 전달하는 스위치가 아닙니다. 여전히 지침과 기준을 작성하고 답변을 코드에서 결합해야 합니다. 차이는 가중치의 최적화 목표에 있습니다. 채팅 토큰이 아니라 보정된 결정입니다. 그래서 출력이 문단이 아닌 Choice, Score 또는 Noul로 나옵니다.

글쓰기는 채팅 모델에 맡기고, 갈림길의 판단은 Jev에 맡기세요. 두 모델을 같은 워크플로에서 사용할 수는 있지만 프롬프트를 공유해서는 안 됩니다. LLM 옆에 System One 모델을 두는 핵심 이유가 바로 이러한 역할 분리입니다.

Kahneman은 이름의 유래일 뿐, 런타임 모드가 아닙니다. Choice, Score 또는 Noul는 여전히 직접 선택해야 합니다.