Kev-4B

モデル概要

Kev-4B は意思決定モデルです。1 つの文書（状態）と、それについての型付きの質問群を読み、各質問に添えられた選択肢上の較正された確率分布を、一度のフォワードパスで、テキストを生成せずに返します。文書を分類・振り分け・トリアージ・検査し、しきい値をかけられる確率を必要とする開発者 —— たとえば不確かなケースを人によるレビューに回す —— に向けられています。TypeSafe の公開 System One API（POST /v1/systemone）を実装しているので、TypeSafe SDK が変更なしに動きます。Qwen3.5-4B-Base 上の LoRA アダプタとポインタヘッドで、24 GB の GPU 1 台か 32 GB の Apple Silicon Mac に収まる大きさです。このカードは Kev 1.0 のチェックポイントを記述しており、2026-09-24 に初めて公開されました。

モデルの詳細

入力。 状態（テキスト、またはラベル付きテキストとして描画された JSON オブジェクトか配列）と、任意の数の名前付き質問。各質問は 3 種のいずれかです:

各質問は、共有された状態から続く自分の行として答えられるので、質問は互いに影響できません。状態は一度だけ計算され、キャッシュされます。

想定用途

• 数千トークンの文書に対する型付きの決定: 分類、ルーティング、トリアージ、抽出の選択、ポリシーと資格の検査、述べられた基準に対する提案回答の判定。
• 信頼度に基づいて行動するワークフロー: 確信のあるケースを自動化し、残りを待ち行列に入れる。しきい値はユーザー自身の業務のラベル付きサンプルで凍結する。
• 控えめなハードウェア上での、System One エンドポイントの自己ホスト型 drop-in 代替と、ユーザー自身のラベルでのファインチューニングの出発点（kev.train --init_from jaredpalmer/kev-4b）。

範囲外の用途

• テキスト生成、チャット、要約、自由形式の質問応答。モデルは与えられた選択肢を採点するだけです。
• 人に対する法的、医療、金融、雇用、または同様の帰結を伴う、人によるレビューなしの完全自動の決定。
• 答えが状態になく一般知識でもない事実に依存する質問、および知識重視の試験（「限界」を参照）。
• KEV_DATE_FACTS=1 前処理器なしの日単位精度の日付演算、65,536 トークンを超える状態、英語以外の言語。

使い方

Kev リポジトリで提供します。CUDA では、融合 DeltaNet カーネルと CUDA graphs を使って bf16 で動きます（L40S、H100、または約 16 GB 空きのある任意の GPU 1 台）。Apple Silicon では、同じコマンドが自動で選ばれる MLX 経由で提供します。

git clone https://github.com/jaredpalmer/kev.git && cd kev && uv sync --extra serve
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b --port 8008           # Kev 1.0 (this card)
uv run --extra serve python -m kev.serve --run jaredpalmer/kev-4b@v1.0 --port 8008      # the same weights, pinned

from typesafe_sdk import Choice, Noul, TypeSafeClient

client = TypeSafeClient(api_key="local", base_url="http://127.0.0.1:8008", model="kev-latest")
response = client.system_one(
    state="I was charged twice for order 1182. Please refund one of the charges.",
    questions={
        "team": Choice(instructions="Which team should handle this?",
                       criteria={"billing": "Charges and refunds", "shipping": "Deliveries", "returns": "Exchanges"}),
        "urgent": Noul(instructions="Does this need a reply today?"),
    },
)
print(response.choices["team"].choice, response.nouls["urgent"].noul)

較正された温度は既定で適用されます。KEV_TEMPERATURE=1.0 は生の確率を返します。KEV_DTYPE=fp32 は評価に使う正確な経路を選びます。KEV_DATE_FACTS=1 は、状態に見つかった日付の各ペアの間の日数を追加します。これはモデルが使うように訓練されています。65,536 トークンを超える状態は、そのトークン数を示す 422 で拒否されます。

訓練データ

最初の後、各ファインチューニング段階は decision-v7 のレコードを再生します（2,000、2,000、4,000）。Jev（TypeSafe のホスト型意思決定モデル）の出力は使用していません。CodeReviewer と FlakeFlagger は Zenodo 由来、CFPB ナラティブは米国政府の著作物です。ソースごとのライセンスとリビジョンはスイートの manifest に記録されています。下の eval 専用スイート（breadth-v1、tasksource-heldout-v1、transfer-v4、longdoc-v1、そして devtools-v1 の When2Call とプロンプトインジェクションのソース）は決して訓練に入りません。

訓練手順

1. ベースレシピ。 ベースから decision-v7 で 2 エポック: LoRA ランク 16、α 32。学習率 5e-5、one-cycle スケジュール。実効バッチ 8（4 × 2 蓄積）。bf16 autocast、勾配チェックポイント。シード 2。損失は各質問の選択肢上の交差エントロピーです。選択肢順序はシャッフルされ、「none of the above」選択肢とディストラクタがランダムに挿入され、choice レコードの 4 分の 1 は最小対も生みます（「none of the above」選択肢付きの質問を、正解選択肢がある状態と除いた状態で 1 回ずつ）。
2. 日付と欠落した証拠。 段階 1 から 1 エポック、学習率 2e-5、2,000 の再生レコード付き。
3. 実文書。 段階 2 から documents-v1 train で 1 エポック、学習率 2e-5、2,000 の再生レコード付き。バッチ 2 × 4 蓄積。状態は最大 7,552 トークン。
4. スキル。 段階 3 から hard-v1 と devtools-v1 train を一緒に 1 エポック、学習率 2e-5、4,000 の再生レコード付き。バッチ 2 × 4 蓄積。状態は最大 7,552 トークン。シード 1。オプティマイザステップ 1,915。
5. 較正。 1 つの温度、T = 2.41。段階 4 のトライアルの decision-v7 開発行（1,264 質問）で負の対数尤度を最小化します。これらは訓練コーパスのホールドアウト項目です。ホールドアウトデータセットでの再フィットを評価しましたが採用しませんでした（「較正」を参照）。

評価

方法論。 特に断りのない限り、すべての数値は出荷温度での fp32 評価経路です。開発分割を選択に使い、テスト分割はこのチェックポイントのために一度だけ読みました。transfer-v4 テストはロック済み（候補ごとに一度読む）で、事前に固定した水準に対して判定されました。ペア付き区間は、レコード全体をリサンプルする 95 % ブートストラップ（2,000 リサンプル）なので、状態を共有する質問は一緒に動きます。差はパーセンテージポイント（pp）です。Jev（TypeSafe のホスト型モデル、Vercel AI Gateway 経由で照会）は、同じ項目で読まれたところに示します。スイート:

• breadth-v1: 5 領域（知識、言語、検索、ツール、芸術）の 14 のホールドアウト公開データセット。一度も訓練していない。
• tasksource-heldout-v1: 公開マルチタスクコレクションの 24 のタスクファミリー全体。一度も訓練していない（ファミリー名は非公開）。
• transfer-v4: 6 つの未訓練公開ソース（QNLI、SciQ、TweetEval-offensive、PAWS、MMLU、Emotion）からの分布外決定と、ホールドアウトのポリシー・ルール構造。
• hard-v1: 上のスキルファミリー。テスト分割は訓練済みジェネレータのテンプレートをホールドアウトします。
• devtools-v1: 6 つのライセンス確認済みソース（4 つ訓練、2 つ eval 専用）からの開発者ツール決定。
• documents-v1 / documents-v2: CFPB 苦情ナラティブ。v2 は非公開のホールドアウトテストセット。
• longdoc-v1: CUAD 商業契約と生成した合意バンドル。状態は 4k から 64k トークン。

「audited」と印付けられた主要パネルは、ラベル監査が不健全と判断した項目を除外します¹。どの除外も、比較の両側から同じ行を除きます。

ホールドアウトデータ（一度も訓練していない）。

訓練済みファミリー（ホールドアウト項目とテンプレート）。

Jev の devtools-v1 の値は全 1,074 開発質問に対するものです。Kev の行は、スイートの builder が 2 レコードに再利用した CodeReviewer id（2 質問）を除きます。

以前のバージョン比（文書段階のチェックポイント、タグ r8-documents-release、それ自身の温度 2.96。登録済み基準、各テストを一度読む）:

長文書。

• 検証済みコンテキスト長: 8,192 トークン、訓練長。16k バケットは許容差の外です: その下限は −3.4 pp で、−3 pp を下回るので、より長い長さは検証されません。
• 読みの前に固定したルール: 検証済み長は、16,384 トークン以上から、それと 8,192 との間のすべてのバケットが許容差内にあるような最大バケットの公称サイズです。許容差内とは、8k バケット（6,553–7,618 トークンの状態、訓練長）からの CUAD 精度差が、同じ契約・反復・質問でペアにされ、95 % 下限が少なくとも −3 pp で、すべてのレコードが答えられていることです。16k バケットが失敗すれば、検証済み長は 8,192 トークンです。

公称状態長ごとの CUAD 精度、ECE、8k バケットからのペア差（longdoc-v1 開発）:

出荷 T = 2.41 での ECE。Δ は、同じ契約について両方の長さで尋ねた 445–447 質問でペアにされています。4k バケットは異なる契約を持ち、ルールの参照ではありません。出所: runs/r28-readout/context.json（ラウンド 28 の登録済み読み出し、runs/r28-4b-r10-longdoc）。

較正（期待較正誤差、ECE、出荷 T = 2.41 で。低いほど良い）:

出荷温度は訓練コーパスのホールドアウト項目でフィットされました。これはプロジェクトのルールでは新しいリリースにもう許されません。ホールドアウトデータセットの 648 質問（transfer-r3 の較正分割、8 ソース、および 200 MMLU-Pro 質問）での登録済み再フィットは T = 2.30（90 % ブートストラップ区間 [2.05, 2.52]）を与えます。4,468 の audited な breadth-v1 と tasksource-heldout-v1 開発質問では、出荷値より改善しません: Brier はどちらも 0.368 で差は −0.0001 [−0.0005, +0.0003]、ECE は 0.025 対 0.024。ルールは Brier 区間がゼロ未満であることとより低い ECE を要求したので、T = 2.41 が残ります。答えは T に依存しません。

その他の結果。

提供。 CUDA、bf16 で融合カーネルと CUDA graphs。リクエストあたりのモデル時間（20 回の中央値）、新しい / 繰り返しの状態:

常駐 GPU メモリは 14.3 GB です。提供時の確率は、280 質問で fp32 評価経路から 0.017 以内にとどまり、答えの変化はありません。fp32 評価経路（H100）では、16k / 32k / 64k トークンの状態が 3.0 / 6.8 / 17.2 秒、重みとは別に 4.3 / 8.6 / 17.2 GiB を使います。

Apple Silicon（MLX、bf16、32 GB の M5。3 問、うち 1 つは 60 % の深さに植えられた事実について。状態は 1,024 トークンずつ prefill）:

60 の短い状態の質問で、MLX 経路は fp32 評価経路から 0.018 以内にとどまり、答えの変化はありません。

¹ audited パネルから除外: 4 つの breadth-v1 データセット（routerbench、その状態には尋ねられた情報が欠ける。cfcolor と humicroedit、どのシステムでもチャンス。chessbench、どのシステムでも床）。無効または回復不能なラベルの 7 つの tasksource-heldout-v1 ファミリー（名前は非公開）。状態がラベルを決めない 2 つの devtools-v1 タスク（flakeflagger、コミット変更種別）。

² コミュニティ Decision Index 0.2 のチャンス補正指数: データセットごとに (score − chance) / (1 − chance) を、各領域内で平均し、その後 100 × 5 領域の平均。Jev の指数は同じテスト項目の別の読みからのものです。

限界とトレードオフ

• 最大の利得は分布内です。 hard-v1、devtools-v1、documents-v1 の訓練分割は訓練データに入っており、hard-v1 テスト項目は訓練済みジェネレータの新しいテンプレートです。ホールドアウトデータセットでは breadth-v1 指数で Jev に 16 ポイント劣り、分布外チェックである JevBench の公開 hard tier では、スキル段階は hard-v1 での約 3 分の 1 しか得ませんでした（111 項目で +9.0 pp [+2.7, +15.3]）。
• 一部の devtools-v1 ラベルは代理です。 訓練前に、Jev を含め採点されたどのモデルも CodeReviewer と FlakeFlagger でほぼチャンスでした。それらのソースでの訓練後、開発で 0.633 と 0.693 に達しますが、これは決定ではなくラベリングヒューリスティックを学んだのかもしれません。
• 知識はベースが決めます。 MMLU-Pro は 0.565 で Jev の 0.840 に対してです。
• 日付演算は最も弱いファミリーです: deadline ポリシー質問で 0.65、Jev の 0.95 に対して。KEV_DATE_FACTS=1 前処理器が助けになります（このチェックポイントの前身である以前のチェックポイントでは 0.60 → 0.85）。このチェックポイントでは再測定されていません。
• 較正は 1 つの分布内温度です。 ホールドアウトデータセットではよく較正されており（breadth-v1 テスト ECE 0.029）、訓練済みスキルと文書ファミリーではそうでもなく（ECE 0.084–0.101）、単一の温度は信頼度を並べ替えられません: 域外の ≤ 5 % 誤りでの被覆は開発で 0.620、Jev の 0.70 に対してです。
• 未訓練の長さ。 訓練の状態は最大 7,552 トークンでした。より長い状態は 65,536 トークンまで提供されます。精度がどこまで保つかは上の検証済みコンテキスト長です。
• 選択肢順序 は答えを変えうる。質問独立性はこれを防ぎません。

バイアス、リスク、倫理的考慮

• 較正された確率は根拠のない信頼を生みうる。温度は訓練分布の開発行でフィットされ、すべての業務に転移するわけではありません。しきい値を設定する前に、自分のデータのラベル付きサンプルで精度と較正を測定し、そこで温度を再フィットしてください（python -m kev.calibrate）。
• 精度と較正はドメイン変化の下でずれます。上の数値に頼るのではなく、本番の誤り率を監視してください。
• 人についての重大な自動決定に、人によるレビューなしで使わないでください。ベースモデルと訓練データ（他のモデルが生成したラベルを含む）のバイアスは測定されていません。
• 状態は個人データや機密データを含みうる。自己ホストは入力を自分のハードウェアに保ちます。サーバーは KEV_API_KEY を設定しない限り開いているので、自分のアクセス制御とデータ取り扱いポリシーを適用してください。

計算

• ベースレシピ: NVIDIA H100 1 台で約 56 分（ピーク 24.6 GB）。日付段階: H100 1 台で 9 分。
• 文書段階: NVIDIA H200 1 台で 43 分。スキル段階: H200 1 台で 1.4 時間（ピーク 47.7 GB）。
• 評価と提供のチェック: Modal 上の単一 H100 / H200 / L40S GPU。MLX 測定は Apple M5。

来歴と再現性

• コード、スイート、評価レポート: github.com/jaredpalmer/kev。リリース数値: runs/release/kev-4b-r10.json（scripts/release_numbers.py --release kev-4b-r10）、ロック済み読み runs/locked/kev-4b-r10-ungated/、2026-09-30 のファミリー読み runs/fam-4b-breadth/、runs/fam-4b-breadthtest/、runs/fam-4b-docs1test/、runs/fam-breadth-test-report/、較正再フィット runs/r28-readout/round28.json、提供 runs/serve-4b-l40s/、runs/grouping-4b-h100/、runs/long-state-4b-h100/、runs/mlx-long-states/、runs/mlx-full-4b/。
• 段階: ベーストライアル q35-4b-s23/00-trial-0（タグ v7-base）。日付 night2-4b-du/00-trial-0（タグ night2-du-release）。文書ラウンド 8 r8-small/00-trial-0（タグ r8-documents-release）。スキルラウンド 10 r10-skills/00-trial-0（experiments/round10/skills.json、ルール experiments/rounds/r10.json）。較正再フィット: ラウンド 28 のアーム 4b-r10（experiments/rounds/r28.json）。
• リリース済み重み: Hub リビジョン 139fdd94。アダプタ sha256 90e81735…、head.pt sha256 dd633435…（T = 2.4061）。
• リリース履歴: 2026-09-24 にラウンド 10 の確認済み候補として公開。Kev 1.0 に変更なく含まれました。どのように選ばれたかの記録（不健全として廃止されたスイート、scienthoon、WANLI-v2、TypeSafe を含む）は、Hub リビジョン 139fdd94 の README と git タグ research-archive-2026-09-24 の PLAN.md です。

引用

@misc{palmer2026kev4b,
  title        = {Kev-4B: a calibrated decision model on Qwen3.5-4B},
  author       = {Palmer, Jared},
  year         = {2026},
  howpublished = {\url{https://huggingface.co/jaredpalmer/kev-4b}},
  note         = {Kev 1.0}
}

連絡先

質問と issue: github.com/jaredpalmer/kev/issues。