自分専用の決定モデルを訓練する:Jeff、Jeeves、そして DIY System One スタック(2026年9月)
- オープンな決定モデルの実際の訓練レシピ — 選択肢の文字に対する交差エントロピー、1 エポック、そして後からフィッティングする温度 — を説明し、なぜ校正が精度とは別の工程なのかを理解する
- 公開されたベンチマーク表を正直に読む:0.8B のモデルが商用 API に勝つ 3 つの行と、20〜26 ポイント負ける 2 つの行
- 4 つの選択肢 — ホスト型 API、ゼロショットのオープンウェイト、自前のファインチューン、素朴な埋め込み分類器 — を、こうしたプロジェクトの大半を葬り去る 1 つのベースライン値を使って判断する
- GPU 1 枚で、午後のうちに Jev 互換モデルを自分で訓練して提供する。結果を正直に保つチェックポイント選択のルールも含めて
- 決定モデルに推論を戻すことが 11 倍のレイテンシに見合うのはいつか、そして信頼度しきい値が 3 分の 1 の待ち時間で精度の大部分を買える仕組みを知る
System One 決定モデル ではカテゴリそのものを説明しました:プログラムの状態と型付きの質問を送ると、テキストの代わりに校正済みの確率が返ってくる、というものです。あのページは、オープンな再現が 9 月半ばの時点でどこまで来ていたか — Kev、Nimble、logprob シム — で終わっていました。
9 月の最終週に、話の形が変わりました。問いは「API をクローンできるか」ではなく「自分で訓練すべきか」になったのです。 9 月 28 日、Jeff というプロジェクトが 0.8B と 2B のファインチューンを公開しました。Jev の総合ベンチマークスコアに 4 ポイント差まで迫り、ラップトップ級の GPU で約 22〜28 ms で動き、ワークステーションカード 1 枚・約 2 時間で訓練されたものです。その日の Hacker News で AI 系トップの話題になりました。その 12 時間後、PostHog が Jeeves を公開します。こちらは逆のことをする — 決定モデルに推論を足す — もので、Jev 自身のハード層で Jev を上回ったと報告しています。
どちらもコードは MIT、ウェイトは Apache-2.0 です。そしてどちらも、自分が負けている行を README に載せる程度には正直です。このページは、それらの行があなたにとって何を意味するのかについてのものです。
この 72 時間を順番に
| 日付(2026年) | 何が出たか | なぜ重要か |
|---|---|---|
| 9月15日 | Jev(TypeSafe AI)、API のみ | カテゴリと /v1/systemone のリクエスト形式を定義した |
| 9月21日 | Kev、Nimble、openjev-sglang | インターフェースがオープンウェイトで再現可能だと示した |
| — | AutoJev(denis-pplx) | レシピ:Qwen3.8-27B の全重み SFT、73,000 例、H200 1 枚、ベース 69.83% に対して 84.60% |
| 9月28日 | Jeff(firelex) | 縮めた — 0.8B/2B の生徒モデル、ワークステーション GPU 1 枚で約 2 時間、MLX での提供、ゲーム評価 |
| 9月29日 | Jeeves(PostHog) | 前提をひっくり返した — 考える決定モデル、Qwen3.5-9B に LoRA + RL |
通底しているのは、2 週間で、訓練内容非公開のクローズドな API だったカテゴリが、一晩で回せるレシピになったということです。AutoJev が蝶番です — 損失関数を公開したのがここで、その後に続くものはすべてこの 1 つのアイデアの変奏です。
レシピの実体
宣伝文句を剥ぎ取ると、決定モデルは通常の LLM に対する驚くほど小さな変更です。
1. 損失は選択肢の文字に対する交差エントロピー
このモデルは「意思決定をする」ようには教えられていません。教えられているのは、ある特定の位置でたった 1 つの文字トークン — A、B、C — に確率質量を置くことです。選択肢を文字付きのパネルとして並べ、正しい文字に対する素の交差エントロピーで訓練し、推論時には文字トークンのロジットを読んで、提示した選択肢の分だけで再正規化します。
この実装上の一点が、目立つ制約を説明します。Jeff は 26 選択肢が上限で、README はそれを超える位置が「事実上絶対に選ばれない」と率直に書いています — アーキテクチャ上の理由ではなく、アルファベットが尽きたからです。(Jev 自身は最大 255 選択肢を謳っており、選択肢のエンコード方法が違うことが分かります。)
Jeeves は別の道を行きます:射影した隠れ状態と各選択肢の埋め込みをスケール済みドット積で採点するポインタヘッドです。文字を使わないので、アルファベットの天井もありません。構造の目印には、実際のテキストにはまず現れない Qwen のトークナイザの希少トークンを借りています — 状態に <|fim_prefix|>、質問に <|fim_middle|>、選択肢を囲む <|box_start|>/<|box_end|>、決定点に <|fim_suffix|>。死んだトークンを区切り文字に再利用するのは、語彙を増やさずコンテンツとも衝突しない安上がりな手です。
2. 校正は独立した 1 パラメータの工程
ここは皆が飛ばす部分であり、出力を信頼できるものにしている部分です。
精度と校正は別の性質です。モデルは、ほぼ毎回正解を 1 位にランクしながら、正解率 75% のときに「91%」と言うことがあり得ます — Jev に対する独立した BANKING77 パイロットは、まさにこの形の過信を見つけました。そのため 3 つのプロジェクトはいずれも、訓練の後にホールドアウトした開発セット上で単一のスカラー温度をフィッティングし、チェックポイントと一緒に配布しています。ロジットをそれで割って、softmax、以上です。
AutoJev はそれが何を買うのかを公開していて、スタック全体で最もきれいなビフォー/アフターになっています:
| 指標 | ベースの Qwen3.8-27B | AutoJev-27B |
|---|---|---|
| 精度 | 69.83% | 84.60% |
| ECE(期待校正誤差 — 低いほど良い) | 0.06483 | 0.04282 |
| Brier スコア(低いほど良い) | 0.40834 | 0.22027 |
3 つとも動いていますが、動いた量が違うことに注目してください。精度が約 15 ポイント上がる一方、ECE は約 34% 下がりました — 訓練はモデルをより正しく、かつより正直にしたのであり、その正直さは別途測定できます。自分で訓練して精度しか報告していないなら、まだ終わっていません。
3. 残りはすべて小さい
1 エポック。バッチ 256。全重み(Jeff、AutoJev)または LoRA r=16(Jeeves)。チェックポイント選択は開発セット上で行い、ベンチマークのパネル上では絶対に行わない — Jeff はこれを明示していますし、信頼できる小規模モデルの結果とリークした結果を分けるのは、この一行です。Jeff はさらに、各訓練ファミリの少なくとも半分を、推論時に見るのと同じパネルレイアウトに保っています。これは見た目以上に効きます。下の「言い回し」の節を参照してください。
0.8B の決定モデルを訓練する(Jeff 自身のレシピ)
# 1. Build the training mix from public datasets uv run autojev-mix ... # 2. One epoch, full-weight, lr 5e-6 scripts/train.sh RUN data/mix/public.jsonl data/mix 5e-6 40 Qwen/Qwen3.5-0.8B <revision> --epochs 1 # 3. Evaluate the SELECTED checkpoint against a held-out panel uv run autojev-evaluate --data data/panel.jsonl --local \ --checkpoint checkpoints/RUN/selected --output runs/eval/RUN.json
ステップ 2 の報告コスト:RTX PRO 6000 1 枚で、0.8B が約 2 時間、2B が約 3.5 時間。 これがトップ記事になった理由の数字です。
ベンチマーク表は横に読む
以下が Jeff の公開パネルです — 5 つの公開データセットと JevBench のハード層にわたる 4,599 問、最終列が商用 API です。総合行ではなく行ごとに読んでください。
| ベンチマーク | Jeff-0.8B | Jeff-2B | Jeff-Gemma4-E2B | Jev(API) |
|---|---|---|---|---|
| 総合 | 79.1% | 83.1% | 81.6% | 83.0% |
| Financial PhraseBank | 96.4% | 96.3% | 96.1% | 77.0% |
| RAGTruth | 86.1% | 88.9% | 87.4% | 77.3% |
| WinoGrande | 68.6% | 79.0% | 77.4% | 90.7% |
| JudgeBench | 62.6% | 64.6% | 60.6% | 78.6% |
| BBH | 64.0% | 68.0% | 66.4% | 94.3% |
| JevBench Hard | 47.6% | 53.3% | 48.6% | 73.3% |
総合スコアはほぼ互角です。行はまったく互角ではありません:
- 小さなモデルが勝つところでは、大きく勝つ。 Financial PhraseBank:96.4% 対 77.0% — 0.8B のモデルが商用 API に 19 ポイント差で勝っています。RAGTruth(この回答は検索してきた文章に忠実か?):86.1% 対 77.3%。どちらも狭く、大量で、パターン的な仕事です — 固定語彙上の感情分析、与えられた文章に対する根拠性。あなたのエージェントのホットパスがその形なら、ローカルの 0.8B は妥協ではなく、より良い道具です。
- 負けるところでは、まったく僅差ではない。 BBH は 30 ポイント下。JevBench Hard は 26 ポイント下。これらは多段の推論を要する行であり、README もはっきりそう書いています:小さな決定モデルが与えるのは「記述した選択肢の間での、速く校正された選択」であって、推論の連鎖ではありません。
- 総合の数字はこの 2 つの事実の平均であり、したがって何も説明していない。 これはこのページで最も応用の利く教訓で、決定モデルに固有の話ではありません:あらゆる単一のヘッドラインスコアは、あなたの構成比ではないベンチマーク構成比上の加重平均です。
ゲームの表こそ正直な表
Jeff はゼロショットのゲームプレイも評価しています — Doom、Frogger、Pac-Man をそれぞれ 20 エピソード — そして結果は、公開したこと自体が信頼に値するほど居心地の悪いものです:
| モデル | Doom(キル数) | Frogger(横断回数) | Pac-Man(ペレット / 98) |
|---|---|---|---|
| ランダム | −0.05 | 0 | 11.2 |
| 手書きルールボット | 6.55 | 10.25 | 94.1 |
| Jeff-0.8B | 6.55 | 10.3 | 57.0 |
| Jeff-2B | −0.9 | 6.0 | 41.2 |
2B は、ベンチマークの全行で上回っている 0.8B より、3 つのゲームすべてで劣っています。 README の読みは、大きいモデルの方がリスク回避的になった、というものです。原因が何であれ、この 2 つの表が並んでいることが要点です:ベンチマークの順位は、ループの中での振る舞いを予測しませんでした。そして手書きのルールボットが Pac-Man を 37 ポイント差で勝ち続けている — 「モデルにできるか」と「モデルにやらせるべきか」は別の問いだという念押しです。
誰も触れないレイテンシの崖
1 決定あたりの中央値レイテンシ、約 200 トークンの質問:
| モデル | RTX PRO 6000 | Apple M4 Max(MLX) | CPU(32 スレッド) |
|---|---|---|---|
| Jeff-0.8B | 22 ms | 28 ms | 463 ms |
| Jeff-2B | 24 ms | 60 ms | 708 ms |
| Jeff-Gemma4-E2B | 29 ms | — | 1.0 s |
ここから持ち帰るべきことが 2 つあります:
- 「小さいモデル」は「どこでも速く動く」を意味しない。 同じ 0.8B のチェックポイントが、GPU では 22 ms、32 CPU スレッドでは 463 ms — 21 倍の差です。決定モデルが決定モデルでいられるのは GPU のレイテンシにおいてだけで、CPU 上ではそれは自分でホストしている遅い API 呼び出しにすぎません。「リクエストパスのあちこちにこの呼び出しを散りばめる」という計画だったなら、CPU の列がその計画の予算です。
- 大きな GPU では、パラメータ 2.5 倍のコストが 2 ms。 22 → 24 ms。このサイズでは、約 200 トークンに対する 1 回の順伝播はオーバーヘッドとメモリ帯域に支配されていて演算量ではないため、速いカードの上では 2B は 0.8B に対してほぼタダです — 一方 M4 Max では同じ一歩が 2.1 倍かかります(28 → 60 ms)。モデルはパラメータ数からではなく、デプロイ先ごとに選んでください。
- uv でインストールし、Hugging Face からチェックポイントを取得し、サーバーを起動します。訓練が必要だと判断する前に、あなた自身のデータでのゼロショットの数字が欲しいはずです — 実務者が報告する最も多い結果は「ゼロショットでは足りない」であり、それは訓練を回した後よりも 20 分で分かる方がはるかに安上がりです。
- 実トラフィック、実際のラベル分布、普段なら捨ててしまう曖昧なものも含めて。このセットは二役をこなします:チェックポイントを選び、温度をフィッティングします。数字を報告するパネルと絶対に重なってはいけません。
- 同じ開発セット上で、埋め込みとロジスティック回帰ヘッド。BANKING77 では、このやり方が Jeff の議論の中で、約 15 倍小さいモデルで 93.0% と報告されました。あなたのデータでこれが勝つなら、ここで止めてください — ファインチューンと GPU を 1 つ節約できました。
- 1 エポック、バッチ 256、選択肢の文字に対する交差エントロピー、lr は 5e-6 前後。訓練例の少なくとも半分は、推論で使うのとまったく同じパネルレイアウトに保つこと。チェックポイントは開発セットで選ぶこと。
- 開発セット上でスカラー 1 つ、チェックポイントと一緒に保存します。そのうえで、精度と校正誤差の両方を自分に対して公開してください。校正されていない決定モデルとは、信頼してはいけない信頼度フィールドの付いた分類器であり、それではこのカテゴリの存在意義そのものが失われます。
- 人間やフロンティアモデルを飛ばして良いと言えるだけの精度が実測で出ている信頼度を見つけます。それより下はすべてエスカレーションです。その数字はあなたのデータの性質であって、0.9 が見た目に整っているからという理由で 0.9 になることはありません。
Jev 互換モデルをローカルで提供し、実際のリクエストを送る
# Apple silicon (MLX backend)
uv sync --no-default-groups --extra mac
uv run --no-default-groups hf download mstrasser/Jeff-Qwen3.5-0.8B --local-dir checkpoints/jeff-0.8b
JEFF_BACKEND=mlx JEFF_CHECKPOINT=checkpoints/jeff-0.8b PORT=8765 \
uv run --no-default-groups --extra mac jeff-serve
# Two independent questions, one request, one parallel pass
curl -s localhost:8765/v1/systemone -H 'content-type: application/json' -d '{
"model": "jeff-latest",
"state": "Refund request: the customer says the parcel arrived crushed and wants their money back.",
"questions": {
"route": {"type": "choice", "instructions": "Which team should handle this?",
"criteria": {"1": "Refunds and payments", "2": "Damaged or lost parcels", "3": "Account and login problems"}},
"angry": {"type": "noul", "instructions": "Is the customer angry?"}
}
}'居心地の悪い問い:そもそもモデルが必要か?
Hacker News のスレッドで最も鋭い批判は、Jeff の性能が悪いというものではありませんでした。構造的な指摘です:どのみち自前のラベル付きデータでファインチューンしなければならないのなら、買ったのはゼロショット分類器ではなく、分類器を訓練するいくぶん不格好な手段だ — しかもこの分野には、すでにもっと安い手段があります。
そのスレッドの数字は、この批判を真剣に受け取るに足るものです。ある投稿者は、0.8B をゼロショットで求人広告の分類に試して使い物にならなかったと報告し、2B でもカテゴリの取りこぼしが残ったとしています。別の投稿者は、素の埋め込みとロジスティック回帰ヘッドが、約 15 倍小さいモデルで BANKING77 において 93.0% に達したと報告しました — 同じデータセットで独立した Jev パイロットが見つけた「信頼度 87.4% / 精度 75.3%」という形に対して、です。
そこで、正直な判断表:
| 状況 | 使うもの |
|---|---|
| 固定ラベルが少数、例は潤沢、レイテンシが重要 | 埋め込み + ロジスティック回帰。 最小、最速、訓練は数秒。他を考える前に、これに勝つこと。 |
| ラベルが頻繁に変わる、またはリクエストごとに質問を散文で書く | ゼロショット決定モデル — スキーマそのものがインターフェースであり、それが実際の製品 |
| 大量トラフィックのドメインが 1 つ、ラベルがあり、午後の間 GPU が使える | ファインチューン。 Jeff のチェスの実行は 15.5% → 55.8%、約 11,000 例での音声ナビゲーションのファインチューンは 30 分未満で 31.7% → 95.8% |
| 本当に難しい多段の判断 | 推論 — Jeeves、またはカスケードの奥のフロンティアモデル |
| 今日の午後に動いてほしくて、量は少ない | ホスト型 API。 自前の GPU もタダではありません |
その下にある一般則:決定モデルが元を取るのは、スキーマが価値のある部分であるとき — 任意の型付き質問を、散文で、1 パスで解決する — です。ラベル集合が固定で既知なら、分類器の形をした仕事にモデルの形をしたコストを払っていることになります。
Jeeves:思考を戻す
Jev の創業時の主張は、この種のモデルはテキストを生成しないというものでした。PostHog の Jeeves はその前提を直接試します。Qwen3.5-9B に LoRA r=16 とポインタヘッドを載せ、決定モデルにまず考えさせてから決めさせるのです。
訓練は 3 段階で走ります:SFT(12 の公開データセットからの 19,126 問と合成ポリシーデータ、半分は推論の連鎖付き、8 GPU で 2 エポック / 596 ステップ)、次に CISPO 強化学習(9,992 問、それぞれ温度 1 で 8 ロールアウト、思考は 2,560 トークンで上限 — 624 ステップの計画を、それ以降は校正が悪化していたため意図的にステップ 402 で打ち切り)、そして同じスカラー温度のフィッティングです。
報告されている結果:
| ベンチマーク | Jeeves | Jev | Kev-9B |
|---|---|---|---|
| テスト総合 | 0.889 | 0.857 | 0.822 |
| JevBench 総合(231 項目) | 0.935 | 0.866 | 0.715 |
| JevBench ハード(111 項目) | 0.865 | 0.730 | 0.451 |
そして、上のどの行よりも重要なアブレーション:推論なしで 0.804、ありで 0.840。 このモデルでは、思考の価値は約 3.6 ポイントです。
さて、値札を付けましょう。H100 1 枚で、Jeeves は推論オフで約 0.3 秒、オンで中央値 3.3 秒、p90 では 17.1 秒で答えます。3.6 ポイントのために、中央値でおよそ 11 倍、裾は一桁悪いということです。README 自身の緩和策が、興味深いエンジニアリングです:思考を 2,560 トークンで上限にすると同時に、モデルがすでに確信しているときに早期に打ち切る 0.9 の信頼度しきい値を入れ、中央値を 2.0 秒まで戻しています。推論は、必要な項目にだけ使う出費になるわけです。
Jeeves が自分について公開している注意点が 2 つあります:知識重視のタスクでは Jev より劣る(MMLU 0.793 対 0.900)— 推論は事実を増やしません — こと、そして推論の連鎖は言語の一貫性について報酬を与えられたことがないため、確実に読めるものではないことです。監査証跡としてその連鎖が欲しかったのなら、誰かにそう約束する前に、実際に読めるかを確認してください。
1 日を無駄にさせる落とし穴
- 言い回しの一貫性は、言い回しの質に勝る。 Jeff は、すべての選択肢を兄弟同士で同じ書き方に揃えただけで、Frogger の横断回数が 15 から 23 に上がったと報告しています。選択肢は 1 回のパスで互いに比較されます — 非対称な言い回しは天秤に乗せた親指です。キーは短く保ち、説明は本文に置いてください。
- プロンプト形式は決定モデル間で移植できない。 Jev の方位数値のスタイルは Jeff には移りませんでした。代わりに結果重視の言い回しが必要でした。決定モデルの乗り換えは、モデル間のプロンプト移植とまったく同じく、再チューニングの仕事だと考えてください。
- 26 選択肢の天井は無言。 何もエラーになりません。27 番目以降の選択肢が単に一度も勝たないだけです。大きなラベル集合は、2 段階の決定に分割してください。
- Jeff は 英語、テキストのみです。AutoJev は base64 の画像を受け付けますが、Jeff は受け付けません。
- ゼロショットの品質はワークロードの形に左右され、しばしば期待外れ。 複数の実務者が、自分の実際の分類タスクでは小さいモデルが使い物にならなかったと報告しています。初日に自分のデータで測ってください。
- 訓練データのリーク除去はあなたの仕事。 Jeff が合成データをローカル生成してリーク除去をかけているのは、まさに評価パネルの近くで訓練された決定モデルが出す数字には意味がないからです。
- どちらのリポジトリも数日前のもの。 フラグ、チェックポイント名、デフォルトは動いています。ここに書いたことは、現在の README の代わりにはなりません。
Check yourself
0/5出典と参考文献
- firelex/jeff — ベンチマーク、レイテンシ、ゲームの全表、訓練コマンド、26 選択肢の制限、チェスと音声のファインチューン結果が載った README。
- PostHog/jeeves — 3 段階の訓練(SFT → CISPO → 温度)、ポインタヘッド、希少トークンのマーカー、推論のアブレーション、レイテンシとしきい値の数字。
- denis-pplx/autojev — 起点となったレシピ:Qwen3.8-27B の全重み SFT、73,000 例、H200 1 枚、精度 / ECE / Brier のビフォーアフター付き。
- Hacker News — Jeff の議論(item 49883844) — 536 ポイント、204 コメント:ゼロショットの失敗報告、ModernBERT による批判、埋め込み + ロジスティック回帰の BANKING77 の数字。
- Hacker News — Jeeves の議論(item 49891290) — 推論とレイテンシのトレードオフをめぐる議論。
- AILmanac — System One 決定モデル:Jev、Kev、そしてオープンなクローン — カテゴリそのもの、独立した BANKING77 校正パイロット、ホスト型 API の制限と価格。
次に読む
- System One 決定モデル:Jev、Kev、そしてオープンなクローン — このカテゴリが初めてならまずこちらを。API、「ハルシネーションしない」という主張、そして独立したテストを扱っています。
- モデルルーティングのパターン — 校正済みの確率が実際に元を取る場所:カスケード、信頼度ゲート、エスカレーション。
- Ollama でモデルをローカル実行する — このページが前提としている、ローカル提供の一般的な地ならし。