RLCD 해설: TypeSafe가 Jev를 호감을 얻는 것 대신 자신감에 대해 솔직해지도록 훈련하는 이유

Jev 1.13(typesafe/jev-1.13)은 제작사가 보정된 결정을 위한 강화학습(Reinforcement Learning for Calibrated Decisions) — RLCD — 이라고 부르는 방법으로 훈련되었으며, 이 약어는 여러분이 이미 알고 있어야 하는 업계 용어가 아니라 TypeSafe가 직접 만든 조어입니다. 출시 게시물은 이를 다음과 같이 명시합니다: 회사는 "새로운 모델 아키텍처, 최대 효율을 위한 병렬 샘플러, 그리고 우리가 보정된 결정을 위한 강화학습(RLCD)이라고 부르는 훈련 방법"을 구축했습니다. 이는 한때 두 가지 답만 있던 질문에 대한 세 번째 답이며, 이것이 존재하는 이유는 대부분의 팀이 언어 모델을 의사결정 과정 안에 넣으려고 할 때 처음 마주치는 불일치 때문입니다. 그것으로 넘어가기 전에 두 날짜가 중요합니다. 이 페이지는 출시 기사가 아니기 때문입니다. TypeSafe는 모델 자체를 2026-09-15에 출시했는데, 이는 이 블로그가 다루는 7일 범위 밖에 있으며, 여기 어떤 내용도 Jev를 새로운 것으로 프레이밍하는 것으로 읽혀서는 안 됩니다. 날짜가 붙은 사건은 2026-09-24로, OrcaRouter가 자체 카탈로그에 typesafe/jev-1.13을 추가하고 이에 대한 모델 카드를 공개한 때입니다 — Jev가 TypeSafe 자체 엔드포인트를 통해서만이 아니라 서드파티 게이트웨이를 통해 호출 가능해진 첫 사례입니다. 이것이 이 페이지가 다루는 변화이며, 실질적인 결과는 아래 기법이 이제 이미 가지고 있을지도 모르는 키로 코드에서 시도해 볼 수 있는 것이지, 읽기만 하는 연구 아이디어가 아니라는 점입니다.

다음은 모델이 아니라 개념입니다. 이 페이지의 처음 3분의 1은 RLCD가 대응하도록 설계된 두 가지 훈련 방법에 관한 것입니다. RLCD는 과제가 더 이상 대화가 아니라 판단이 될 때 그 두 방법이 하는 일에 대한 보완책으로서만 이해할 수 있기 때문입니다. RLHF와 RLVR이 무엇을 최적화하는지 이미 알고 있다면, 원하는 섹션은 세 번째 섹션입니다. 여기서는 TypeSafe 자체의 3방향 표가 그 역할을 합니다.

{{1}}RLHF{{/1}}는 {{2}}사람이 선호하는 답변에 최적화한다{{/2}}

인간 피드백 기반 강화학습은 사전 학습된 언어 모델을 어시스턴트로 바꾼 방법이다. TypeSafe 자체의 입문서는 RLHF라는 제목이 붙은 카드에서 그 목표를 단호하게 밝힌다. 그것은 "사전 학습된 모델을 챗봇으로 바꿨다. 사람들이 선호하는 응답을 생성하도록 모델을 훈련시킨다."라고 말한다. InstructGPT와 ChatGPT가 이 방법으로 훈련되었으며, 그 입문서는 여기서 다른 이유로 관련이 있는 세부 사항을 덧붙인다. 즉 이 접근법은 TypeSafe의 공동 창업자이자 Jev의 출시 글을 쓴 Diogo Almeida가 공동 발명했다. 이 회사는 그 방법을 일축하는 것이 아니다. 이 회사는 그 방법을 개발하는 데 일조한 사람이 세운 회사다. 단지 특정 작업에는 그 목표가 잘못되었다고 주장할 뿐이다.

불일치를 명확히 보는 방법은 보상 신호가 실제로 무엇을 측정하는지 묻는 것이다. RLHF에서 그것은 두 후보 응답 사이에 대한 평가자의 선호를 측정한다. 제품이 대화일 때 이것은 훌륭한 대리 지표다. 대화의 성공 기준은 정말로 사람이 그 답변을 좋다고 여기는지 여부이기 때문이다. 제품이 결정일 때 이것은 망가진 대리 지표다. 거기서 성공 기준은 제시된 확신도가 현실과 일치하는지 여부인데, 그럴듯한 두 문단을 비교하는 평가자는 잘 보정된 0.6과 자신감 있게 들리는 0.95의 차이를 알 방법이 없다. 두 답변은 똑같이 선호될 수 있으면서도, 소프트웨어가 각각을 얼마나 신뢰해야 하는지에서는 엄청나게 다를 수 있다.

TypeSafe가 입문서에서 언급한 실패 모드들은 바로 그로부터 직접 비롯된다:

• 아첨 — 모델은 평가자가 듣고 싶어 하는 것을 산출하도록 학습하는데, 이는 진실과는 다른 목표이다.

• 자신감 있게 들리는 환각 — 유창함과 확신은 아무런 근거가 없을 때조차 선호도에 의해 더 높이 평가된다.

• 모드 드롭핑 — 선호도 최적화는 출력 분포를 좁혀, "지시 따르기와 같은 특정 스타일을 선호하면서 다른 가능한 출력의 확률을 줄인다." 모드 드롭핑은 생성적 적대 신경망을 괴롭히는 고전적인 모드 붕괴 실패의 경미한 버전으로, 여기서 생성기는 판별기를 계속 속이는 하나의 출력으로 수렴한다.

그 입문서 자체의 경고 문단이야말로 남겨둘 가치가 있는 문장이다: "어떤 출력은 사람에게는 설득력 있게 다가갈 수 있지만, 무인 자동화에 충분할 만큼 신뢰할 수 있는 것은 아니다. 인간의 선호와 기계의 신뢰성은 서로 다른 최적화 목표다." 이것은 방법으로서의 RLHF에 대한 비판이 아니다. 이는 선호도 학습을 거친 모델이 자동화가 답을 필요로 하는 질문, 즉 이 대상이 확신한다고 말할 때 정확히 얼마나 자주 맞는가라는 질문을 한 번도 받은 적이 없다는 관찰이다.

RLVR은 프로그램이 검증할 수 있는 출력에 최적화한다 — 그리고 결정에는 그러한 출력이 거의 없다

검증 가능한 보상이 있는 강화 학습은 두 번째 적응이며, 추론 모델들을 가능하게 한 바로 그것이다. TypeSafe의 입문서는 그것이 만들어낸 것을 설명한다: "수학과 같은 작업에는 강하지만, 더 느리고 더 비싼" 모델들. 그 메커니즘은 검사기다. 어떤 작업에 프로그램이 테스트할 수 있는 답—단위 테스트, 증명 검사기, 숫자 답—이 있다면, 사람에게 아무것도 묻지 않고 보상을 계산할 수 있으며, 모델은 그 신호에 맞춰 대규모로 훈련될 수 있다. 그것은 작동하며, 추론 모델들이 값싼 자동 검증이 존재하는 바로 그 영역들에서 뛰어나게 된 이유다.

한계는 "검증 가능한"이라는 단어의 형태에 있다. 검증 가능한 보상에는 검증자가 필요하고, 검증자에게는 누군가 계산할 수 있는 정답이 과제에 있어야 한다. 실제 프로덕션 시스템이 던지는 질문들을 생각해 보라. 이 지원 티켓은 청구로 가야 하는가, 기술로 가야 하는가? 이 환불 요청은 정책 범위 안에 있는가? 이 거래는 사기처럼 보이는가? 각각은 대부분의 경우 방어 가능한 답이 있지만, 어느 것도 프로그램이 확인할 수 있는 답은 없으며, 가장 중요한 사례들은 바로 경험 많은 인간들이 의견을 달리하는 사례들이다. 실행할 함수가 없다. RLVR은 보상할 것이 없으므로 아무것도 기여하지 않는다.

유혹적인 우회책은 데이터셋에 레이블을 붙이고 그 레이블에 맞춰 훈련함으로써 검증기를 만들어내는 것이다. 그러면 그 방법에 곱씹을 거리는 생기지만, 중요한 지점에서 목표를 바꾸어 놓는다. 레이블은 결정을 인코딩하지, 그 결정을 둘러싼 불확실성을 인코딩하지 않는다. 어려운 사례에 대한 한 팀의 판단을 재현하도록 훈련된 모델은 그 레이블이 그랬던 만큼 확신하도록 배운다 — 즉, 그 레이블을 작성한 인간들만큼 정확히 과신하도록 배운다. 그리고 진짜 검증기가 존재하는 경우에도 두 번째 간극이 있다. 검증기는 답에 점수를 매긴다. 밝힌 확신도에는 점수를 매기지 않는다. 사례의 95%에서 맞고 그 모두에 대해 확실하다고 보고하는 모델은 완벽한 보상을 받지만, 자동화 파이프라인의 구성 요소로서는 쓸모가 없다 — 왜냐하면 그 5%가 바로 파이프라인이 통보받아야 했던 유일한 부분이기 때문이다. TypeSafe의 출시 자료는 같은 요점을 반대 방향에서 제시한다: "모델이 어떤 작업을 95%의 경우 해낼 수 있지만 언제 5%에 속하는지 말하지 않는다면, 그 작업을 자동화할 수 없다."

TypeSafe 자체의 관점에서 본 RLCD가 하는 일

RLCD는 답변 품질이 아니라 출력 계약을 바꾼다. 프라이머의 카드에는 이렇게 적혀 있다: "보정된 의사결정을 위한 강화 학습은 TypeSafe가 생성된 텍스트 대신 결정과 보정된 확률을 반환하도록 훈련한다." 런칭 포스트의 간결한 버전은 "보정된 의사결정: System One 작업에서 인식론적으로 정직한 확률을 갖춘 답변"이다. 둘 다 하나의 전환을 설명한다: 사람이나 검사기가 그 답변을 좋아했는지가 아니라, 모델이 제시한 확률이 그 답변이 실제로 맞았던 빈도와 일치했는지를 기준으로 모델을 훈련하는 것이다.

런칭 게시물은 세 가지 방법을 나란히 배치하며, 그 대비가 이 아이디어를 가장 명확하게 표현한 진술이다. 표가 아니라 일련의 대비로 읽어 보자:

• 무엇을 최적화하는가 — RLHF는 인간 선호도, 즉 "인간 평가자가 선호하는 작성물과 채팅 응답"을 최적화한다; RLVR은 "프로그램적으로 검증 가능한 출력"을 최적화한다; RLCD는 캘리브레이션, 즉 "System One 작업에서 인식론적으로 정직한 확률을 가진 답변"을 최적화한다.

• 입력으로 들어가는 것 — 앞의 둘은 "순차적 메시지에 중점을 둔" 비정형 데이터를 받고, 보정된 결정 모델은 "구조화된 프로그램 상태에 중점을 둔" 비정형 데이터를 받는다.

• 무엇이 나오는가 — "파싱 + 검증이 필요한" 생성 문자열로, "AI가 통제를 벗어날 위험이 항상 있는" 반면, "가능한 출력과 구조가 미리 정의되어" 있고 모델이 "타입 오류를 결코 내지 않으며" "모든 답변에 보정된 확률과 신뢰도 점수가 함께 제공되는" 타입 안전 구조적 값과 대비됩니다.

• 샘플링 방식 — 한 번에 하나의 토큰씩, 각각 직전 토큰에 조건화되며, 단일 쿼리에서 생성된 모든 출력과 대비된다. 이것이 세 번째 방법이 저렴한 기계적 이유다: 지불해야 할 디코딩 루프가 없다.

• 비용 — 비교 모델의 경우 입력 토큰은 백만 개당 $0.20에서 $10이고 출력은 입력 가격의 약 5배입니다. 반면 Jev는 입력 토큰 백만 개당 $0.042이며 출력은 0으로 청구됩니다.

• 응답 속도 — 프런티어 모델의 경우 엔드투엔드 3~329초인 반면 70~500ms이며, 공급업체는 이를 System One 형태의 쿼리에서 40~200배 더 빠르다고 규정합니다.

• 자신의 확신에 관해 말하는 내용 — 더 오래된 두 모델은 확신도 추정을 요청받은 경우에도 "과신하고 일관성이 없는 경향이 있다"; RLCD는 "모든 출력에서 확신과 불확실성을 항상 전달하며", 여기서 "확신이 높을수록 정확도가 높다."

마지막 줄이 실제 제품 주장이며, 다른 주장들과 달리 반증 가능하다. "신뢰도가 높을수록 정확도가 높다"는 것은 하나의 곡선에 관한 진술이다. 모델의 답변을 그것이 부여한 확률에 따라 구간으로 나누면, 각 구간은 그 확률이 주장하는 비율만큼 대략 맞아야 한다. TypeSafe의 신뢰도 문서는 이 계약을 유난히 구체적인 숫자로 명시한다:

• 확률 0.2가 부여된 결과는 약 20%의 빈도로 발생해야 합니다.

• 확률 0.8이 부여된 결과는 약 80%의 경우에 발생해야 합니다.

• 확률이 1.0으로 지정된 결과는 100%의 확률로 발생해야 합니다.

그리고 나서 그 주장을 정직하게 유지해 주는 문장이, 벤더의 표현 그대로 있습니다: "이 비율들은 예측들의 집단을 설명할 뿐, 어떤 단일 답변에 대한 보장이 아닙니다." 이것은 법적 이유로 덧붙인 완충 표현이 아니다. 그것이 바로 캘리브레이션의 전체 의미다. 0.8이라고 말하는 잘 캘리브레이션된 모델은 이번에는 맞을 것이라고 약속하는 것이 아니다. 그것은 0.8이라고 표시한 모든 답변에 걸쳐 약 다섯 중 넷이 정답이었다는 것을 약속하는 것이다. 답변 하나는 아무것도 알려주지 않는다. 일주일 동안의 천 개 답변은 그 곡선이 진짜인지 알려준다.

동일한 세 장의 카드 대비는 TypeSafe 자체 문서에 있으며, 이 문서는 위 비교의 출처이자 요약의 말을 그대로 믿기보다 문구를 확인할 수 있는 가장 명확한 곳입니다. 아래 캡처는 오늘날 그대로의 해당 페이지입니다: 세 가지 포스트트레이닝 접근법을 위한 세 장의 카드가 있고, 세 번째 카드에서는 RLCD를 전체 명칭으로 표기하고 있습니다.

공급업체 문서에 나오는 두 가지 추가 세부 사항은 이 방법이 제품 속으로 얼마나 깊이 파고드는지를 보여줍니다. 첫째는 신뢰도가 생성되는 것이 아니라 도출된다는 점입니다. 모델은 사용자가 제공한 선택지나 수준 전반에 걸친 전체 확률 분포를 반환하고, 신뢰도 값은 그 분포의 형태에서 계산된 통계량입니다. 그래서 문서에서 정의가 결정적인 역할을 하지 않는다고 말할 수 있는 것입니다 — 어느 쪽이든 원시 분포를 얻을 수 있고, 자신의 통계량이 더 잘 맞으면 직접 계산할 수 있기 때문입니다. 둘째는 RLCD가 가중치를 형성하는 유일한 요소라는 점입니다. TypeSafe의 모델 페이지에는 이렇게 나와 있습니다: "Jev는 고객 데이터로 미세 조정되거나 LoRA 적응되지 않습니다. 이는 보정된 결정을 반환하도록 RLCD로 훈련되며, 동일한 가중치가 모든 계정에 사용됩니다." 도메인 적응은 요청에서 — 귀하의 상태, 귀하의 기준 — 일어나며, 고객별 체크포인트에서 일어나는 것이 아닙니다. 이 방법이 만들어낸 보정이 무엇이든, 그것이 모든 고객이 받는 보정입니다.

왜 캘리브레이션이 저렴한 의사결정 모델을 쓸 수 있게 만드는 요소인가

보정된 확률은 그 자체로는 흥미롭지 않습니다. 그것은 여러분의 코드가 그 확률을 기준으로 분기하는 순간 아키텍처가 되며, TypeSafe의 신뢰도 문서는 바로 그 패턴을 세 가지 범위로 설명하는데, 각 범위는 서로 다른 시스템 동작을 만들어냅니다.

• 높은 신뢰도 — 자동으로 조치하세요. 모델이 상황을 명확히 파악하고 있으므로 사람의 개입 없이 진행할 수 있습니다.

• 중간 신뢰도 — 주의하여 진행하십시오. 모델이 합리적인 답변을 가지고 있지만 확신하지는 못하므로, 행동하기 전에 사용자에게 확인하거나, 검토 대상으로 표시하거나, 더 많은 정보를 수집하십시오.

• 낮은 신뢰도 — 행동하지 마세요. 사람에게 넘기거나, 명확화를 요청하거나, 다른 시스템으로 폴백하세요. 모델이 판단할 근거가 충분하지 않다고 알려주고 있기 때문입니다.

문서는 경계는 당신이 그릴 몫이며 결과에 따라 달라져야 한다고 분명히 밝힙니다: "신뢰도 임계값은 하나의 숫자가 아닙니다. 같은 시스템 안의 서로 다른 작업은 잘못 판단했을 때의 결과에 따라 서로 다른 수준에서 게이트되어야 합니다." 그들의 구체적인 예시는 0.5에 확고한 하한을 두고 — 모델이 그보다 낮게 보고하는 것은 추가 검토 없이 사람에게 라우팅됩니다 — 그런 다음 파괴적 작업에는 읽기 전용 작업보다 더 높은 기준을 적용합니다. 당신의 코드는 위험 허용도를 인코딩하고, 모델은 그에 대한 정직한 입력을 제공합니다.

그 패턴이 두 모델 워크플로에 대한 전체 논거이며, 기능 목록이 아니라 논거로 제시할 가치가 있다. 확신할 수 있는 대다수 사례를 처리하고 나머지는 더 큰 모델이나 사람에게 에스컬레이션하는 자동화 파이프라인을 원한다고 하자. 에스컬레이션 결정은 어디선가 나와야 한다. 저렴한 모델이 추측 중인 사례까지 포함해 모든 것에 0.98을 보고한다면, 분기가 테스트할 것이 없어지므로, 에스컬레이션했어야 할 호출까지 모두 자동화하거나, 아무것도 자동화하지 않거나 둘 중 하나가 된다. 확신도가 정보를 주는 모델만이 일부 하위 집합을 안전하게 자동화할 수 있게 해 준다. 왜냐하면 그런 모델만이 어느 하위 집합에서 안전하지 않은지 알려 줄 수 있기 때문이다. 문서는 같은 요점을 직설성 때문에 인용할 만한 한 줄로 표현한다: "지능형 시스템이, 인간이든 기계든, 정직한 불확실성을 표현할 수 없다면, 그 시스템은 신뢰할 수 없다."

값싼 모델에게 이것이 비싼 모델보다 더 중요한 두 번째 이유가 있으며, 그것이 라우팅 이야기와 RLCD 이야기가 같은 이야기인 이유다. 입력 토큰 백만 개당 $0.042에 출력 비용이 없는 모델은 충분히 저렴해서 끊임없이 참조할 수 있다 — 에이전트 루프의 매 턴마다, 배치의 모든 레코드마다, 티켓이 도착할 때마다. 끊임없이 참조된다는 것은 바로 모델의 실수가 누적되는 상황이다. 왜냐하면 그 출력이 실행되기 전에 아무도 그것을 읽지 않기 때문이다. 확신이 그것을 안전하게 만든다. 저렴함은 에스컬레이션 분기를 감당할 수 있게 만든다. 비싼 경로는 값싼 모델이 거절한 사례의 일부에만 실행되기 때문이다. 어느 쪽도 다른 쪽 없이는 작동하지 않으며, 둘을 결합하는 라우팅 결정은 숫자에 대한 임계값이다. RLCD는 그것을 믿을 만한 이유다.

정직한 한계: 보정된 것이 정확한 것은 아니다

RLCD에 관해 가장 중요하게 제대로 이해해야 할 점은 RLCD가 주장하지 않는 바입니다. 캘리브레이션은 신뢰도의 속성이지 답변에 대한 보장이 아니며, 공급업체는 이를 비판자들에게 맡기지 않고 자체 문서에서 밝히고 있습니다. System One 페이지: “System One 모델은 캘리브레이션된 결정을 위해 훈련됩니다. 즉, 확률은 불확실성을 반영하도록 결과에 맞춰 최적화됩니다. 캘리브레이션은 예측 그룹 전반에 걸쳐 측정되며, 개별 답변이 정확하다는 것을 보장하지는 않습니다.” 모델이 완벽하게 캘리브레이션되어 있더라도 귀하의 티켓에 대해 잘못된 판단을 내릴 수 있습니다. 0.9는 열 번 중 아홉 번을 의미하며, 이번이 바로 그 열 번째일 수 있기 때문입니다.

여기서 유용한 대조점은 바로 우리 자체 서빙 수치입니다. 이는 해당 방법이 달성하는 바에 대한 주장이 아니라 프로덕션 환경에 있는 모델의 측정값이기 때문입니다. 모델이 카탈로그에 추가된 이후 OrcaRouter의 플레이그라운드를 통과한 트래픽을 대상으로, 2026-09-30로 끝나는 7일 동안 Jev 1.13 카드는 7,620만 토큰에서 0.49%의 오류율을 보고했으며, 첫 토큰까지 걸리는 시간은 p50 151ms, p95 247ms, 출력 토큰은 초당 약 349개였습니다. 이 수치와 관련해 두 가지는 분명히 말할 필요가 있습니다. 이는 벤더의 수치가 아니라 우리의 수치이며, 고정된 테스트 세트가 아니라 롤링 윈도우라는 점입니다. 동일한 필드는 윈도우 초반에는 0.57%를 기록했는데, 이는 실시간 트래픽의 지난 7일을 기준으로 다시 계산되면서 어제의 호출이 제외되기 때문입니다. 또한 이는 캘리브레이션 측정값이 아닙니다. 오류율은 우리 트래픽에서 문제가 얼마나 자주 발생했는지 알려줄 뿐, 신뢰도 값이 정직했는지는 알려주지 않습니다. 이는 별개의 질문이며, 답하려면 레이블이 지정된 데이터가 필요합니다.

다음은 벤더가 자사의 임계값 지침에 첨부한 노트에서 함께 제시하는 실용적인 지침이기도 하다. "올바른 임계값은 여러분의 도메인과 사용 사례에 대한 모델의 성능에 따라 달라집니다. 보수적인 임계값으로 시작하고, 자체 데이터로 테스트하며, 결과를 관찰하면서 조정하십시오." RLCD는 모델이 어떻게 훈련되었는지에 관한 주장이다. 그 주장이 여러분의 입력에서 성립하는지는 경험적 질문이며, 머신러닝 인프라 없이 테스트할 수 있는 몇 안 되는 모델 속성 중 하나다. 이미 레이블이 있는 사례 수백 개를 가져와 모델이 보고한 신뢰도에 따라 답변을 구간으로 나누고, 그 구간들이 주장하는 비율만큼 맞는지 확인하라. 0.9 구간이 여러분의 트래픽에서 약 90%의 경우 맞다면, 그 임계값은 실제이며 그 위는 자동화할 수 있다. 모든 것이 0.9 위에 몰려 있는데 정확도가 따라오지 않는다면, 어떤 헤드라인 숫자보다 더 유용한 것을 배운 것이다.

두 가지 추가 한계도 같은 맥락에서 언급해야 한다. 첫째, 이 모델을 검증할 공개 벤치마크 카드가 없다 — 공급업체도 이를 공개하지 않았고, 어떤 제3자 리더보드에도 이 모델이 없다. 2026-09-30 기준 이 모델에 대한 Artificial Analysis 모델 페이지는 404를 반환한다. 따라서 보정 논증은 훈련 설명, 문서화된 계약, 그리고 직접 측정한 값에 기대며, 공개된 곡선에 기대지 않는다. 둘째, 공급업체의 자체 성능 주장은 어디까지나 자사 주장이다: 출시 글은 속도와 비용 헤드라인의 근거가 된 워크플로 평가가 자사의 모델 역량 팀에 의해 구축되었고, 그 평가의 기준이 되는 참조 답변이 두 외부 모델의 평균이며, 수치가 "실제 세계 개선폭의 상단에 있다"고 공개적으로 밝힌다. 또한 그 가격이 보조금 없이 책정되었음을 입증할 수 없다고 말한다. 그 어느 것도 훈련 방법 자체를 훼손하지는 않는다. 훈련 방법은 속도 주장과는 별개의 주장이다. 다만 이는 RLCD의 근거가 확정된 실증 결과라기보다 목표 설계에 관한 논증이라는 뜻이다. 값싸게 검증할 수 있는 가설로 취급하라. 이는 대부분의 훈련 방법 주장이 남겨주는 것보다 나은 위치다.

오늘 이걸로 무엇을 할 수 있는지

이 논증의 두 항은 한 지점에서 만난다. RLCD는 의사결정 모델의 신뢰도가 분기할 가치가 있는 이유이고, 코드 안의 임계값은 그 분기가 존재하는 자리이며, 에스컬레이션은 일반 경로가 어디서나 돌릴 만큼 저렴할 때에만 감당할 수 있다. Jev 1.13은 OrcaRouter에서 typesafe/jev-1.13으로 호출할 수 있다 — 200개 이상의 모델을 위한 단일 API, 0% 마크업, 제공사 정가 그대로 전달, 따라서 벤더의 가격 인하는 같은 날 여기에서 바로 반영된다 — 즉, 확신 있는 다수 경로와 생성적 에스컬레이션 경로가 두 개의 벤더 계약이 아니라 동일한 키로 청구된다는 뜻이다. 여전히 그것은 자체 형태인 POST /v1/systemone, 비스트리밍, 65,536토큰 컨텍스트를 대상으로 호출해야 하는데, 그것이 OpenAI 채팅 완성 라우트가 아니고 채팅 엔드포인트에 통합되어 있지도 않기 때문이다. 이를 연결해 구성할 계획이라면 벤더의 SDK 릴리스에서 나온 날짜가 붙은 두 가지 노트를 알아둘 가치가 있다. 2026-09-21에 릴리스된 버전 0.7.1은 AI 게이트웨이와 함께 사용하는 예제를 추가했고, 2026-09-26에 릴리스된 버전 0.7.2는 Python 패키지에 http2 extra를 추가했다. 두 번째는 릴리스 노트에서만 드러나는 종류의 세부 사항이다 — 전체 가치 제안이 200밀리초 미만의 왕복이라는 모델에게는 HTTP/2 클라이언트를 갖추는 것이 가치가 있다.

이 페이지에서 단 하나만 가져간다면, RLCD가 답하는 질문의 형태를 가져가세요. 그것은 "모델이 더 똑똑해질 수 있는가"가 아닙니다. 그것은 "모델이 나에게, 자신이 충분히 똑똑하지 않을 때를, 내가 나머지를 자동화할 수 있을 만큼 자주 그리고 정확하게 알려줄 수 있는가"입니다. 이는 지난 몇 년 동안 이 분야가 집중해 온 두 가지 목표와는 다른 연구 목표이며, 여러분의 코드가 실제로 작동할 수 있는 숫자를 만들어내는 유일한 목표입니다. 신뢰도 값이 바로 그 숫자입니다. 신뢰하기 전에 여러분 자신의 레이블로 시험해 보고, 맞기를 바라는 임계값이 아니라 틀리면 부끄러울 임계값부터 시작하세요.

그림의 마지막 한 조각은 이 모든 것과 함께 기억해 둘 가치가 있습니다. 왜냐하면 그것은 이 전체 그림이 겨냥하는 숫자이자, 주장된 것이 아니라 측정된 숫자이기 때문입니다. 이 카드는 jev-1.13의 7일 서빙 기록입니다 — 학습도, 벤치마크도 아닌 실제 운영 중(on the wire)의 기록입니다. 이것을 나머지 결정의 후반부로 읽어 보세요: 신뢰도는 어떤 호출에 대응해야 하는지 알려주고, 이 기록은 나머지 결정이 무인 시스템에 얼마나 가까운지 알려줍니다.