홈 · 결정 모델 · 멀티모달 · 구조화 출력 · 분류 · Cloudflare · Apache-2.0
결정 모델이 뭔가
보통 우리는 LLM 에게 글을 시키고, 그 글을 파싱해 결정을 뽑는다. "이 로그인 화면에 데모 계정이 필요한가?"를 물으면 문장이 돌아오고, 우리는 거기서 예/아니오를 긁어낸다. 중간에 파싱이 있고, 환각이 있고, 지연이 있다.
Clef 는 그 중간을 없앤다. 상태(글·JSON·이미지·영상)와 타입이 정해진 질문 스키마를 넣으면, 질문마다 모든 보기의 확률을 한 번의 forward 로 돌려준다. 질문 유형은 셋이다.
noul: 참/거짓. "영수증 합계가 읽히는가?"choice: 이름 붙은 보기 중 하나. "이 요청의 분류는?"score: 순서가 있는 점수. "긴급도: 나중에 / 이번 주 / 오늘"
출력은 질문마다 보기의 로짓이고, 질문별 softmax 로 확률이 된다. 자유 텍스트도, 출력 파싱도 없다.
구조 (실측)
백본은 Qwen3.8-27B 를 포스트트레인한 것으로, 비전 인코더가 그대로 붙어 있어 이미지·영상 프레임도 상태로 읽는다. 그 위에 작은 joint schema head(joint_head.safetensors + joint_schema_model.py)가 백본의 마지막 히든 상태를 읽어, 상태의 근거를 각 질문으로 라우팅하고 모든 질문의 모든 보기를 공동으로 채점한다. config 실측으로 64층·hidden 5120·하이브리드 어텐션(linear 위주 + 4층마다 full attention)이고, 위치 임베딩 상한은 262,144 토큰이다(encode_record 기본 입력 상한은 16,384).
벤치, 어디서 이기고 어디서 지나 (벤더 자체 런)
Cloudflare 자체 Decision Index 0.2.1(43 태스크) 결과다. 우리가 돌린 게 아니라 벤더 수치라는 점을 전제로 읽는다. 성격이 또렷하게 갈린다.
| 벤치 | Clef | Clef-flash | Jev |
|---|---|---|---|
| BANKING77 (macro-F1) | 94.2 | 90.9 | 79.7 |
| CLINC150+OOS (macro-F1) | 97.4 | 66.8 | 89.3 |
| 가전 시뮬 (case exact) | 83.0 | 97.7 | 52.3 |
| ContractNLI (macro-F1) | 81.4 | 84.3 | 71.7 |
| RAGTruth (환각 F1) | 79.4 | 35.6 | 76.5 |
| 중앙값 지연 (ms) | 209.3 | 38.8 | 524.1 |
| GPQA Diamond (정확도) | 48.0 | 51.0 | 78.3 |
| MMLU-Pro (정확도) | 65.9 | 65.3 | 82.7 |
| BBH (정확도) | 73.7 | 68.9 | 92.9 |
분류·도구호출·계약 NLI·환각 탐지 같은 결정 태스크와 지연에선 Clef/Clef-flash 가 앞선다. 반면 GPQA·MMLU-Pro·BBH 같은 순수 추론은 범용 모델(Jev)이 눈에 띄게 앞선다. 이건 약점 보고가 아니라 설계의 결과다. Clef 는 긴 사고를 하라고 만든 게 아니라, 정해진 질문에 빠르고 일관되게 결정을 내라고 만든 모델이다.
어떻게 쓰나
- Workers AI:
@cf/cloudflare/clef로 API 즉시 호출. 기존 Jev/SystemOne API 요청 본문을 그대로 받는다(POST /v1/systemone). - 로컬: HF
Cloudflare/clef(Apache-2.0). 27B 라 GPU 가 필요하고,joint_schema_model.py의load_release_model+systemone로 돌린다. 가벼운 쪽은Cloudflare/clef-flash.
우리 맥락에서 당장 할 일은 채택이 아니라 측정이다. LLM 으로 글을 받아 파싱하던 결정 자리(판정·게이트·lint) 하나를 골라, clef-flash 로 같은 입력에 같은 질문을 던지고 지연과 정확도를 재 보는 것. 그 수치가 나와야 '참고용'에서 '도입 후보'로 올릴지 정할 수 있다.
*이 리포트는 Hugging Face repo·config·모델카드 실측과 벤더가 공개한 벤치표 인용으로 작성했다. 모델 가중치는 클론해 재현하지 않았고, 성능 수치는 전부 벤더 자체 런이다.*
실측 정보
- 무엇
- 상태 + 타입 질문 스키마를 넣으면 결정을 낸다. 질문은 셋이다. noul(참/거짓)·choice(고르기)·score(순서 점수). 질문마다 모든 보기의 로짓을 내고 질문별 softmax 로 확률을 얻는다. 한 번의 forward 로 전부, 자유 생성도 출력 파싱도 없다. 백본 Qwen3.8-27B(비전 인코더 포함) + 작은 'joint schema head'(상태의 근거를 각 질문에 라우팅해 공동 채점)
- 규모 / 형식
- 27B 멀티모달. safetensors 12 shard + joint_head.safetensors + joint_schema_model.py(커스텀 코드). 총 25파일. config 실측: 64층·hidden 5120·하이브리드 어텐션(linear + 4층마다 full)·max_position_embeddings 262,144(encode_record 기본 입력 상한은 16,384 토큰)
- 벤치 (벤더 자체 런)
- Cloudflare 자체 Decision Index 0.2.1(43 태스크) 결과. Clef/Clef-flash 가 다수 1위다. BANKING77 94.2 · CLINC150+OOS 97.4 · 가전 시뮬 83.0→flash 97.7 · BFCL 98.5/98.8 · RAGTruth 환각 F1 79.4 · ContractNLI 81.4 · CRUXEval 86.7. ⚠️ 전부는 아니다. GPQA Diamond 48.0 vs Jev 78.3, MMLU-Pro 65.9 vs 82.7, BBH 73.7 vs 92.9. 순수 추론은 범용 모델이 앞선다. 리더보드 clef-evals.workers-ai-mle.workers.dev
- 지연 (벤더 자체 런)
- 중앙값 Clef 209.3ms · Clef-flash 38.8ms · Jev 524.1ms. p95 Clef 238.6 · Clef-flash 122.4. 결정 한 건을 수십 ms 에 내 워크플로가 기다리지 않고 바로 분기할 수 있는 수준(특히 flash)
- 라이선스 / 실행
- Apache-2.0 (HF Cloudflare/clef · Cloudflare/clef-flash). Workers AI @cf/cloudflare/clef 로 API 즉시 호출. 로컬은 27B 라 GPU 필요. ⚠️ 이 리포트는 HF repo·config·모델카드 실측 + 벤더 벤치표 인용이며, 우리가 직접 돌려 재현하지 않았다(모델 가중치는 클론 실측 대상이 아니다)
- 계보 / 날짜
- 2026-10-01 공개(HF 리비전 2f3de3d, 다운로드 824·좋아요 841 실측). API 가 'Jev'·'SystemOne' 과 호환된다. 기존 결정모델 API 요청을 그대로 받는다. RL 파인튜닝 플랫폼(AI Gateway 수집 → Workers AI 롤아웃 → Containers 샌드박스 → Trainer → BYO 배포)이 함께 나왔다
적용점
- 이럴 때 유용LLM 으로 '경계 있는 판정'을 시키던 자리다. 분류·라우팅·승인/보류·추출 같은 곳. 출력이 타입+확률이라 파싱이 없고, 확률이 붙어 임계값과 사람 에스컬레이션을 바로 걸 수 있다. 중앙값 수십 ms(flash 38.8ms)라 워크플로 중간에 넣어도 느리지 않다. Apache-2.0 라 자기 스택에 올리거나 Workers AI 로 바로 호출한다.
- 이럴 땐 주의추론기가 아니다. 열린 추론(GPQA·MMLU-Pro·BBH)은 범용 모델이 앞선다. 글을 쓰거나 긴 사고가 필요하면 대상이 아니다. 또 벤치는 전부 벤더 자체 런(Decision Index·Typesafe Evals)이라 우리가 재현한 수치가 아니고, 공개 사흘 된 모델이라 외부 검증·실사용 후기가 아직 없다.
- 먼저 볼 것아이디어가 핵심이다. 결정은 생성이 아니라 분류다. 우리가 LLM 프롬프트로 PASS/RISK/UNKNOWN 같은 걸 받아 파싱하던 자리를 타입 스키마 하나로 바꾸면 파싱·환각·지연이 같이 준다. 구조는 joint_schema_model.py 에 다 있다. 붙이기 전 clef-flash 로 우리 실제 결정 태스크의 지연·정확도부터 재 보자.
판정은 참고용이다. 당장 '도입 후보'로 올리기엔 공개 사흘 됐고, 벤치가 전부 벤더 자체 런이며, 우리가 직접 돌려 보지 않았다. 그래도 눈여겨볼 값은 분명하다. 먼저 이게 왜 다른지 보자. 보통 모델은 글을 생성하고 우리가 그 글을 파싱해 결정을 뽑는다. Clef 는 그 중간을 없앤다. 상태와 타입 질문 스키마를 넣으면 질문마다 보기의 확률을 바로 돌려준다. 자유 텍스트도 출력 파싱도 없고, 확률이 붙어 임계값과 에스컬레이션을 그 위에 그냥 얹을 수 있다. 이 범주가 우리가 매일 하는 일과 정확히 겹친다. Giting 판정 ◆◈◇, 방금 그 리뷰 게이트의 PASS/RISK/UNKNOWN, lint 분류 전부 '경계 있는 결정'이고, 지금은 LLM 에게 시켜 글로 받아 파싱한다. 벤치를 정직하게 읽으면 성격이 드러난다. 분류·도구호출·계약 NLI·환각 탐지 같은 결정 태스크와 지연에선 앞서지만, GPQA·MMLU-Pro·BBH 같은 순수 추론은 오히려 범용 모델에 밀린다. 그게 결함이 아니라 설계다. 추론기가 아니라 결정기다. Apache-2.0 에 Workers AI 즉시 호출이라 시험 비용도 낮다. 다만 벤더 벤치를 곧이곧대로 믿지 말고, 우리 실제 결정 태스크로 clef-flash 를 재 본 뒤에야 도입 후보로 올릴 일이다. 지금은 읽고, 재 볼, 참고용.
의견
판정에 대한 반론, 도입 경험, 정정 제보를 환영합니다. GitHub 계정으로 참여합니다.
