판단만 하는 모델,
Jev

01 · Summary30초 요약

긴 글을 읽기 전에 알아야 할 세 가지.

02 · Glossary핵심 용어 10개

Jev 문서와 이 페이지에 반복해서 나오는 말입니다. 요청에 들어가는 것 4개, 답의 형태 3개, 돌아오는 것 1개, 우리가 덧붙이는 운영 장치 2개로 나눴습니다. 각 카드 오른쪽 위 표시는 그 일을 누가 맡는지(4층 프레임 기준)입니다.

같은 노트 한 건을 세 프리미티브로 물었을 때 돌아온 실제 값(2026-09-24 smoke 호출)으로 그렸습니다.

03 · Workflow한 번의 판단이 흐르는 길

위 용어들이 실제로 어떤 순서로 이어지는지입니다. 카드 번호 순서대로 읽고, 가운데 강조된 한 칸만 Jev입니다. 나머지는 코드와 사람이 맡습니다.

노트 한 건으로 따라가 보기

위 Choice·Noul·Score 카드에 쓴 실제 smoke 호출이 이 흐름을 어떻게 지나갔는지입니다. 임계값 0.7과 0.8은 설명용 예시이며 운영 값이 아닙니다.

04 · WhatJev란 무엇인가

TypeSafe가 2026-09-15 early access로 공개한 System One 모델. 회사 표현 그대로 "not trained to generate text"입니다.

학습 목표가 사람이 좋아할 답변이 아니라 소프트웨어가 바로 쓸 결정과 확률입니다. 새 모델 구조, 병렬 sampler, 보정된 결정을 위한 강화학습(RLCD)을 결합했다고 설명하지만 가중치, 파라미터 수, 학습 데이터는 공개되지 않았습니다. 공개된 것은 HTTP 계약, SDK, cookbook, 일부 평가 자료입니다. 공개 SDK가 있다는 것과 모델이 공개됐다는 것을 섞지 않습니다.

세 프리미티브

그림으로 먼저 보려면 핵심 용어의 카드를 보십시오. 여기서는 스펙만 정리합니다. 입력은 state(문서, 기록, 정책 — 문자열·JSON·배열, 텍스트 전용)와 questions(무엇을 판단할지와 가능한 답)입니다. 한 요청에 질문 여러 개를 묶을 수 있고, 각 질문은 같은 state를 공유하되 독립적으로 평가됩니다.

셋 중 어느 것도 문장을 만들지 않고, 선택지에 없는 답을 내지 않으며, 질문 간 확률이 논리적으로 맞물린다는 보장이 없습니다.

API 형태

# POST https://api.typesafe.ai/v1/systemone
# Authorization: Bearer <KEY>
{
  "model": "jev-latest",
  "state": "노트 제목, description, tags, 본문 앞 1,200자 …",
  "questions": {
    "cmds":       { "type": "choice", "instructions": "이 노트가 속한 서브카테고리는?",
                    "criteria": ["907 Product & Engineering", "720 Music", "620 Generative AI", "hold"] },
    "is_owner":   { "type": "noul",   "instructions": "소유자의 원칙 진술인가?" },
    "specific":   { "type": "score",  "instructions": "얼마나 구체적인가?",
                    "criteria": ["주장만", "근거 언급", "근거·기준선까지 명시"] }
  }
}

# 응답: model(실제 실행 버전), answers{cmds: {choice, probabilities, confidence}, …}, usage{input_tokens, output_tokens}
# 실측 예(smoke 1건): 907 0.61 / 720 0.34 / hold 0.05 / 620 0.00 · confidence 0.48 · noul 0.91 · score 1.86 (conf 0.80) · 603 in / 102 out · 0.5초

질문 키 이름은 추론에 쓰이지 않습니다. 오류는 401(인증), 422(필드 위반), 429(rate limit), 529(overloaded)이고 429·529만 지수 백오프합니다. 응답의 model은 실제 실행된 버전이며 09-24 실측 341건 전부 jev-1.13.0이었습니다.

가격, 한도, 언어

Jev가 아닌 것

• 생성이 아닙니다. 문장·코드·이미지를 만들지 않습니다. Choice를 연쇄해 문장을 조립하면 느리고 나쁩니다. → 생성 LLM, 정규식, 사람
• 검색이 아닙니다. 웹 검색·도구 실행이 없습니다. 공개된 "Jev Search" 구현도 외부 검색 API가 검색하고 Jev는 후보를 고릅니다. → 검색 엔진, 외부 API
• 계산기가 아닙니다. "Jev is not a calculator." 개수, 합, 평균, 쿼터 산술은 불안정합니다. → 코드
• 날짜를 모릅니다. 날짜를 순서 있는 양이 아니라 텍스트로 읽습니다. "최근 7일", "오늘 밤", 하루 경계는 전부 코드. → 코드
• 권한을 결정하지 않습니다. 신원을 모릅니다. 열람 허가, 병합, 삭제, 발행, 과금은 Jev 확률로 내리지 않습니다. → 코드·DB, 사람
• 텍스트 전용입니다. 이미지·오디오 입력이 없습니다. Doom 데모도 이미지가 아니라 구조화된 game state입니다. → 전처리
• 다단 추론에 약합니다. 이중 부정, multi-hop은 정확도가 떨어집니다. → 코드가 단계를 쪼개거나 생성 LLM

05 · FrameSystem One 판단과 4층 프레임

7모델 보고서가 합의한 배정표. 출발 원칙은 "에이전트 스택은 모델이 아니라 실행 주체와 권한 경계로 선택한다"이고, Jev는 판단을 제안할 뿐 실행 권한을 갖지 않습니다.

후보를 거르는 여섯 질문

어떤 일을 Jev에 맡길지 정할 때 순서대로 묻습니다. 하나라도 걸리면 그 층에서 끝냅니다.

06 · Jaggedness문서화된 약점 9종 → 설계 규칙

공식 문서 "Jev 1.13 jaggedness"(last reviewed 2026-09-17)가 스스로 밝힌 실패 유형을, 우리 설계 규칙과 "먼저 만들 반례"로 옮긴 표입니다.

07 · Showcase사람들이 Jev로 만든 것들

출시(09-15) 열흘 동안 나온 사례 26건을 카드로 모았습니다. 출처는 커뮤니티 쇼케이스 jevable.com(위키 볼트에 09-20 클립 보관), GitHub, X입니다. 09-21 이후 사례는 Grok 4.7(X·웹 검색)과 Gemini 3.1 Pro(Google 검색)로 찾고, X 게시물 ID의 시각과 GitHub 저장소 생성일로 날짜를 다시 확인했습니다.

사례를 4층 프레임으로 읽으면

공식 소식 (09-15 ~ 09-24)

08 · Direction내 상황에 맞춘 방향

23행 포트폴리오 중 우선순위 상·중 항목을 압축했습니다. 비용은 전부 입력 tokens × $0.042 / 1,000,000이고 건수와 길이는 추정입니다. 고도화는 이미 있는 자산에 판단기를 얹는 것, 신규는 아직 코드가 없는 것입니다.

먼저 돌릴 셋

재즈 플랫폼·레슨 솔루션 설계 요약

파트너와의 대화에서 나온 인증 열람, 업보트 노출, 조언 코멘트 지연 열람은 채택된 규칙이 아니라 통제 방안 후보입니다. 공통 원칙 셋: 대상(공연장/뮤지션)에 따라 정책이 갈리므로 대상 판정이 첫 판단이되 게시 위치로 확정되면 묻지 않는다. 외부 텍스트의 노출 결정은 실패 시 비공개 또는 보류다. 실시간 오디오 경로에는 원격 판단 API를 두지 않는다.

거칠기를 Score로 둘지 순서 있는 Choice로 둘지가 실제 분기점이었습니다. 외부 재계산에서 Score만 44.67%(ECE 0.325)였고, 노출될 등급을 미검증 프리미티브에 걸 이유가 없습니다. Score는 PoC 3에서 관찰 전용입니다.

09 · Seven Models7모델 논리검증

같은 패킷(사실 원장, 논리 문항 10개, 설계 과제)을 일곱 모델에 독립적으로 주고, 정답 키와 위반 목록을 먼저 잠근 뒤 블라인드로 채점했습니다. 목적은 "누가 Jev를 가장 잘 이해하고 경계를 지키는가"입니다.

가중총점 = Σ(가중치 × 축점수 ÷ 10). 논리 블록 = L1 논리 정확성 26 + L2 사실 충실성 16 + L3 경계 판단 12. 밴드 A = 총점 85 이상 + 논리 46 이상 + Tier A 위반 0. V27 = Jev 판단만으로 노출 실행, V28 = 한 질문에 판단 여럿을 묶음.

논리 블록만 보면 순위가 다릅니다. Astra와 Grok 4.7이 54.0으로 공동 1위, Opus 5.5 52.8, Sol 52.7, Fable 5.1 51.6. 총점 1위 Opus가 논리 블록에서 3위인 이유는 "기준이 쌓이면 확률 구간별로 코드가 적용"이라는 표 셀 하나가 사람 승인 경계를 다시 열었기 때문입니다. Fable 5.1도 "임계값 확정 후 코드가 게시"라는 같은 결의 문장을 썼고 그 감점(V27)을 그대로 받았습니다. 채점에서 가장 자주 감점된 지점이 바로 그 셀입니다.

P1~P10 논리 문항 요약

P5가 노린 함정은 "산술적으로는 맞아 보이는 항등식"이었습니다. 같은 Noul 반환값 안에서 1 − 0.30을 '아니오'의 여분으로 설명하는 것과, 별도 부정 질문의 출력이 0.70이라고 쓰는 것은 다른 주장입니다. P5가 변별한 것은 산술 능력이 아니라 닫힌 답을 열어 두는 습관입니다. 정직하게 적으면 열 문항의 변별력은 낮았고(69/70), 순위를 가른 것은 포트폴리오와 재즈 설계에서 자기가 선언한 경계를 스스로 지켰는가였습니다.

비용 가중 요약

채점 10축 어디에도 비용은 없습니다. 그래서 별도로 세운 축입니다. 이 run의 현금 청구액은 $0(전부 구독 쿼터)이고, 아래 금액은 각 모델의 공식 단가로 토큰 사용량을 환산한 동등 비교 비용입니다. 같은 패킷 프롬프트 1회 입력과 실제 청구된 출력 토큰만 곱했습니다.

품질 Q = 총점 ÷ 100. 비용점수 C = 1 − log10(비용 ÷ 최저) ÷ log10(최고 ÷ 최저). 최저 Flash $0.1055 → C = 1, 최고 Fable $1.5688 → C = 0. 합성 = 0.9Q + 0.1C(9:1) 또는 0.7Q + 0.3C(7:3).

• 밴드 A 다섯 편의 총점 차는 2.6점(94.0에서 91.4)인데 비용 차는 9배입니다(Sol $0.17 대 Fable $1.57). 품질이 동급이면 Sol이 기본 선택이고, 9:1과 7:3 어느 가중에서도 1위입니다.
• 총점 1위 Opus 5.5는 9:1에서 3위, 7:3에서 6위로 내려갑니다. 두 편의 품질 우위는 비용 가중 0.1만 얹어도 Grok과 Sol에게 뒤집힙니다.
• Fable 5.1은 이 과제에서 가장 비쌌고 품질은 3위라 어느 가중에서도 5위 이하입니다. 이 페이지를 쓴 모델에 불리한 결과를 그대로 적습니다.
• Flash는 7:3에서 2위지만 밴드 B입니다. "싸다"가 "쓸 수 있다"를 뜻하지 않으므로 밴드 규칙이 비용 가중보다 우선합니다. 밴드 A 안에서의 순서는 두 가중 모두 Sol, Grok, Opus, Astra, Fable로 같습니다.
• 1회 실행, 1과제 표본입니다. 순위의 방향은 믿되 소수 셋째 자리는 믿지 않습니다.

10 · Measurement첫 실측 (2026-09-24 오후)

smoke 1건, α 채점 재현 70건, β 서브카테고리 분류 109건, triage 5통. 볼트 파일은 하나도 수정하지 않은 shadow 실행입니다.

α · 채점 재현 (Score, 70건)

7모델 보고서의 논리 문항 답안 7편 × 10문항을 state로 주고, 문항당 Score 3단계 하나씩 10개를 한 요청에 묶었습니다. 정답은 채점자가 이미 매긴 0 / 0.5 / 1 점수입니다.

β · CMDS 서브카테고리 분류 (Choice 87 + hold, 109건)

최상위 영구 노트 109건의 제목, description, 태그, 본문 앞 1,200자를 state로 주고, 87개 서브카테고리 이름 + hold 중 하나를 고르게 했습니다. criteria는 이름만. 정답은 각 노트에 이미 적혀 있던 분류값입니다.

triage · 가상 메일 5통

kind(Choice 7), urgent(Noul), fit(Score 0~2) 세 질문을 한 요청에 물었습니다. 다섯 통 모두 kind confidence ≥0.96이라 설계해 둔 "저확신 에스컬레이션" 분기가 한 번도 발동하지 않았습니다. 일부러 애매하게 쓴 메일도 Jev에게는 애매하지 않았습니다. 정책 실험을 하려면 두 요청을 한 메일에 섞거나 실제 마스킹 메일을 넣어야 합니다. 같은 스크립트를 다시 돌리면 값이 소수점 둘째 자리에서 흔들립니다.

실측이 가르치는 것은 셋입니다. 첫째, 검증자 과제에서 confidence 게이트가 실제로 작동합니다. 둘째, 분류 과제에서 같은 게이트는 작동하지 않습니다. 보정이 과제마다 다르다는 것이 확인됐으니 컷을 과제 간에 복사하지 않습니다. 셋째, 실패 지점은 "정책 미전달"과 "hold 미발동"이고 둘 다 Jev 성능이 아니라 criteria와 코드 정책의 문제라, 판정(PROPOSE)을 뒤집을 이유가 되지 않습니다.

11 · Measurement II09-26 실측: 지식 입력과 검색

노트를 볼트에 넣을 때(어느 분류, 어느 볼트, 어느 프로젝트로)와 볼트에서 노트를 찾을 때 Jev가 어디까지 맞는지, 세 라운드 3,560회 호출로 쟀습니다. 2026-09-26 새벽 실행이고, 볼트에는 한 글자도 쓰지 않은 shadow 실험입니다.

세 라운드로 잰 방법

모든 조건에 API를 부르지 않는 코드 기준선(가장 흔한 분류, frontmatter 규칙표, 검색 1위)을 같은 항목에 붙였습니다. 결정은 Jev의 응답 문구가 아니라 코드가 확률값으로 내렸고, 1위와 2위가 같거나 1위가 "보류"면 답하지 않았습니다. 합격선은 만들지 않았고, 2라운드부터는 등록 뒤 파일이 바뀌면 실행 도구가 호출을 거부합니다.

결과 한 표

1라운드 프로젝트 라우팅 이름만은 90.0%, 96.7%. 위키 안 폴더 4종 분류는 2라운드 최종 39/40으로 포화입니다. 비율은 모두 조건마다 한 번 실행한 값입니다.

검색 파이프라인: 누가 무엇을 하나

가장 큰 이득은 Jev 밖에서 먼저 났습니다. qmd의 FTS5 색인은 한글을 음절마다 띄어 저장합니다. "기록"*으로 찾으면 0건, "기 록"으로 찾으면 2,726건(09-26 07:30 재확인)입니다. 한국어 단어를 음절 구문으로 바꾸자 2라운드 후보에 표적이 든 비율이 46/55에서 50/55로, 목록 1위가 21/55에서 30/55로 올랐습니다. 끝단 정확도는 후보 재현율 × Jev 조건부 선택으로 정확히 나뉘고(3라운드 45/49 × 44/45 = 44/49), 네 표본 모두 조건부 선택이 90% 이상이라 남은 손실은 대부분 후보층에 있습니다. Jev를 고치기 전에 후보를 만드는 층부터 고칩니다.

뒤집힌 결론: 규칙표는 폴더를 넘지 않았다

2라운드에서는 Jev를 부르지 않는 frontmatter type 규칙표("type이 X면 분류 Y")가 101/120으로 모든 Jev 조건 이상이었습니다. 그래서 "규칙이 먼저 끝내고 규칙 밖 노트에만 Jev"를 다음 가설로 등록했습니다. 한 번도 쓰지 않은 폴더 세 곳의 65건에서 규칙표는 적용된 27건 중 1건만 맞혔고, 규칙 우선 조합은 20/65로 Jev 단독 28/65보다 낮았습니다. 규칙표는 그것을 만든 폴더와 type 분포의 산출물이었습니다.

Jev 쪽도 새 폴더에서 낮았습니다. 2라운드 75.8%의 대부분은 형식이 뚜렷한 분류에서 나왔습니다(이름만 줬을 때 대비 발행한 글 802는 0/27 → 26/27, 용어 104는 9/66 → 54/66). 반면 주제와 도구 분류에서는 두 라운드 모두 40% 안팎입니다. confidence 0.7 이상 구간도 3라운드에서 16/33이라 87분류에서 확률로 자동 승인하지 않습니다. 그래서 규칙 우선을 기본값으로 두지 않습니다. 폴더별 표본에서 정밀도를 확인한 규칙 행만 먼저 쓰고, 나머지는 Jev top-3 제안을 사람이 고르며, 사람의 최종 선택을 Jev 제안 옆에 병렬 기록합니다(shadow log).

모델 보고서 일곱 편과 대조하면 검색 쪽 설계(후보는 검색 엔진이, 하나 고르기는 Jev가, 끝단을 두 층으로 나눠 재기)는 세 라운드 내내 지지됐고, 틀린 것은 "후보에 없으면 해당 없음이라고 답한다" 하나였습니다. 입력 쪽은 합의가 두 번 틀렸습니다. 일곱 편이 모두 "코드가 87개 후보를 줄이고 Jev가 고른다"를 중심에 뒀지만 2라운드에서 상위 20개로 줄인 목록에 정답이 든 비율이 45.8%라 끝단이 35.0%에 머물렀고, 헤드 모델이 낸 규칙표 우선안은 3라운드에서 무너졌습니다. 가장 정확했던 것은 "설계에서 잠근 문안은 새 모집단을 설명하지 못한다"는 소수 경고(Grok 4.7)였습니다.

비용과 호출 위생

• 모델 핀 jev-1.13.0. 응답 모델이 바뀌면 그 배치를 빼고, 모든 컷과 규칙을 다시 등록합니다.
• 보내는 필드에 길이 상한(본문 발췌 1,200자, 후보 설명 200자). 분류의 정답을 누설하는 경로, type, 기존 분류값은 보내지 않습니다.
• 경로 거부 목록에 더해, 개인정보 규칙을 조립이 끝난 payload에 겁니다. 개인과 가족, 대화와 회의, 사생활, 건강, 제3자 연구(FGI, 인터뷰, 면담, 참여자, 참석자, 좌담, 대담, 미팅, 간담회, interview, participant), 자격증명, 거주지, 학생과 고용 기록. 제목, 설명, 태그, 본문 앞 1,500자를 대소문자 구분 없이 봅니다.
• 예산 상한을 먼저 예약하고 실측으로 정산합니다. 401이면 중단, 422는 재시도 없이 기록, 429와 529만 지수 백오프.
• 볼트에는 쓰지 않습니다. 제안 기능은 오류가 나면 제안 없이 원래 화면을 보입니다.

같은 날 돌린 8모델 논리검증

이번 실험 설계 자체를 여덟 모델에 같은 프롬프트로 맡기고, 정답 키와 위반 목록을 먼저 잠근 뒤 블라인드로 채점했습니다. 논리 문항 10개는 검색 필터 비용, 임계값 이식 함정, 순서 교차의 경제성 같은 이번 설계의 계산을 묻습니다.

• 상위 셋은 사실상 동률입니다. 총점 차가 2.2점 안이고, 논리 블록 상위 넷(Grok 4.7과 Astra 공동 1위 51.5)은 1.6점 안이라 이틀 전 잰 재채점 분산(±1.6) 안입니다. Jev 기능을 틀리게 서술한 위반은 일곱 편 모두 0건입니다.
• 헤드 모델을 밝힙니다. 결과를 통합한 헤드와 채점자 두 명, 반박자, 조정자가 모두 Claude Opus 5.5입니다. 블라인드 슬롯이 자기 선호를 줄이지만 없애지는 못하므로, Opus 5.5의 2위는 독립 검증된 순위가 아닙니다.
• Claude Fable 5.1은 빠졌습니다. 두 번 시도했지만 본문이 나오지 않아 0점이 아니라 순위 밖입니다. 그래서 이번 Claude 쪽 비교는 Opus 5.5 한 편뿐입니다.
• 추론 강도가 같지 않았습니다(Astra와 Sol은 xhigh, 나머지는 high). 공식 단가로 환산하면 밴드 A 셋은 Sol $0.25, Grok $0.45, Opus $2.14라, 품질이 동급인 이 셋 안에서는 이번에도 Sol이 기본 선택입니다.

판정과 다음 순서

• 검색. qmd 후보 위에 Jev 후보 고르기와 절단 0.3 유지 집합을 shadow로 붙입니다. 보류나 오류면 qmd 목록을 그대로 보입니다.
• 입력 분류. 규칙 우선 기본값은 두지 않습니다. 폴더별로 확인한 규칙 행만 먼저 쓰고, 나머지는 top-3 제안 + 역순 보류 + 사람의 최종 선택을 병렬 기록합니다. 빈 정의 14개 초안은 소유자 확인이 먼저입니다.
• 프로젝트 라우팅. README 설명 한 줄을 판단 재료에 처음부터 넣습니다.
• 메인 대 위키. 운영에 쓰지 않습니다. 순서에 따라 답이 바뀐 7건을 첫 사람 골드로 판정하고, 판정에 든 시간도 함께 잽니다.
• 다음 실험. 사람 골드 먼저, 표적을 일부러 뺀 단위 10개 이상으로 "해당 없음" 따로 재기, 같은 payload 반복으로 결정성 재기. 규칙표 재설계는 등록 뒤 새로 생기는 노트로만 검증합니다.

12 · Governance거버넌스와 HOLD 트리거

비밀 탐지를 판단기에 맡기는 것은 약점 2와 5에 어긋납니다. 반출 제외는 코드의 경로 규칙으로만 처리하고 Jev에게 "비밀인가"를 묻지 않습니다.

Jev 라벨로 자체 분류기를 학습시키지 않습니다(계약의 distillation 제한과도 맞습니다). 치환 규칙과 전후 해시를 기록합니다. 회사 측 사실: 고객 입력 비학습 정책, 미국 호스팅, enterprise ZDR은 옵션(기본 무보관 아님), SOC 2 Type II 표시는 확인했으나 감사 실물의 scope·기간·예외는 미확인.

실험 위생

• 요청 모델 jev-1.13.0 핀, 응답 model이 다르면 배치 제외
• 401 중단, 422 재시도 없이 기록, 429·529만 지수 백오프, 재시도 입력도 상한 산입
• 비용은 직접 API 단가로만. shadow 로그는 검색 인덱스 밖 (인박스에 쓰면 다음 검색이 Jev의 과거 답을 근거처럼 회수)
• 사람은 Jev 답을 보기 전에 판정하고, 검토 시간은 "제안 표시"와 "제안 없음" 조건을 나눠 잰다
• 개인정보 규칙은 조립이 끝난 payload 전체(제목, 설명, 태그, 본문 앞 1,500자)에 대소문자 구분 없이 건다 (09-26부터)
• 질문 문구는 고정 후 수정 금지. 최종 평가 뒤 프롬프트 변경은 별도 revision
• 제안 UI가 사실상 자동화가 되는 자동화 편향은 검토 시간이 비정상적으로 짧아질 때 경고

13 · Roadmap로드맵: PoC 1 → 2 → 3

500건(A 200, B 200, 경계 100; 설계 100 / 임계값 100 / 최종 300)을 총량 불변으로 셋으로 나눕니다. 과제 비율 2:2:1을 각 분할에 유지합니다.

임계값 절차 여섯 단계

비용 상한은 그대로입니다. 2,000만 tokens × $0.042/M = $0.84이므로 토큰 상한이 $1보다 먼저 닫힙니다. 4변형 500건은 $0.252로 상한의 30%. 상한이 설계를 강제하는 첫 사례가 PoC 3의 20곳 × 144회 × 7일 × 1,500 = 30,240,000 tokens이고, 변경 감지를 넣어야만 실행합니다.

다음 실험

• β 재실행, 메타 클래스 정의 포함. criteria에 "외부 소스 요약이 아닌 본인 해석은 주제와 무관하게 220"을 넣고, max p 임계값 hold 변형(예: <0.35)을 함께. 109건 × 3변형 ≈ $0.03. 09-26 실행: 이름만 20.0% → 정의와 형식 지시 75.8%, 처음 보는 폴더 43.1%. 결과
• α 재실행, P3 지시문 수정. 오독 가설 검증. 14회.
• AKM 증거 심사 40건을 α형으로 설계. 여기부터 사람 라벨이 필요합니다.
• 사람 라벨 100건 → 500건. 사람은 Jev 답을 보기 전에 판정하고 일부는 두 사람이 독립 검토.
• 4변형 완성. 기본, 영어 instructions + 한국어 state, 순서 변경, 반복. 6,000,000 tokens → $0.252.
• Brier / ECE. 구간 수를 사전 고정. 외부 0.079 / 0.082 / 0.325와 비교해 합격 처리하지 않습니다.

14 · References참고 자료

공개 링크만 적었습니다. 내부 스코어카드와 원장은 이 페이지에서 개념으로만 언급했습니다.

Upcoming다가오는 행사

요즘 제가 진행하는 세미나와 컨퍼런스입니다. 궁금하시면 오세요.