問い合わせメールを部署に振り分けたい。緊急度を 3 段階で付けたい。解約をほのめかしているかを知りたい。
こういう「決まった選択肢から選ぶ」仕事のために、LLM に JSON を書かせ、パースし、崩れたら再試行する。この手間を消す 判断モデル が、2026 年 9 月に相次いで登場しました。9 月 15 日に TypeSafe AI が Jev を、9 月 29 日に Liquid AI が d1 を発表しています。ただ、どちらも API での提供で重みは非公開、日本語の業務文での精度も公表されていません。
この記事では、拙作の日本語専用の判断モデル sokudan（即断）を、インストールから業務への組み込みまで順に使っていきます。
動機 Jev の発表の数日後、重みが公開されている多言語の判断モデル laya-multilingual を、日本語の業務文 300 件で測りました。部署の振り分けは当たる一方、解約の示唆を問う はい / いいえ は AUROC 0.523 で、偶然とほぼ区別がつきませんでした。ないなら作るしかない、と 2 日間のスプリントで作ったのが sokudan の最初の版です。
問題意識 手元の LLM 呼び出しのうち、実は「選択肢から選ぶだけ」のものがどれだけあるか。それを考えるきっかけにしてほしいと思っています。
実地の文脈 開発と計測は、コンシューマ向けハイエンド構成の一例である RTX 5090 1 枚と Core Ultra 9 285K で行いました。外部では、会計アプリの勘定科目の候補提示に PoC として組み込まれています。
記事を通して、判断モデルを ハンコしか持っていない受付係 にたとえます。
この記事を読むと、明日こう決められます。手元の日本語の判定処理のうち、どれを LLM から sokudan に移すか。そして、閾値と人の確認をどこに置くか。
この記事について
対象読者: Python から LLM の API を呼んで、分類やラベル付けをさせたことがある人
得られること
- 手元の判定処理を LLM と sokudan のどちらに任せるか、判断フローで決められる
- pip 1 行で入れて、3 種類の質問を投げられる
- 公開ベンチの精度を自分の手で計算し直せる
- 受け皿の選択肢の閾値、人に見せる候補の数、確率の見せ方を設計できる
扱わないこと: 学習手順と内部構造の詳細、Jev・d1 との精度比較（理由は 3 章）、英語の文章での利用
1. 判断モデルとは何か — ハンコしか持っていない受付係
冒頭で、LLM に JSON を書かせる手間を消すモデルが出てきたと書きました。自分の仕事に入れてよいかを判断するには、まず LLM と何が違うのかを押さえる必要があります。
このセクションで分かること: 判断モデルと LLM の違い、質問の 3 つの型、主なモデル
TypeSafe AI は Jev を最初の System One モデル と呼んでいます。呼び名の由来は、カーネマンが『ファスト&スロー』で描いた速く直感的な「システム 1」の思考です。一方、モデル名の Jev は経済学者ジェヴォンズから取ったと、発表記事にあります。
We named Jev after William Stanley Jevons.
（和訳: Jev という名前は、ウィリアム・スタンレー・ジェヴォンズにちなんで付けました）
たとえで言えば、LLM はメモを自由に書く受付係で、頼んでいない答えや崩れた書式が返ることがあります。判断モデルは選択肢のハンコしか持たない受付係で、選択肢にない答えは原理的に返りません。そのうえ、どのハンコにどれくらい手が伸びたかを確率で返します。
| LLM に分類させる | 判断モデル | |
|---|---|---|
| 答え | テキストを 1 トークンずつ生成 | 選択肢ごとの確率を 1 回で返す |
| 出力トークン | 答えの長さ分 | 0 |
| 選択肢にない答え | 返ることがある（パースと再試行が要る） | 原理的に返らない |
| 確率 | モデルに言わせた自己申告 | 出力層から読んだ値 |
質問の型は 3 つです。
- noul: はい / いいえ。P(はい) を返します
- choice: 選択肢から 1 つ。全選択肢の確率を返します
- score: 順序のある段階。段階の期待値と、段階ごとの確率を返します
| モデル | 提供 | 重み | 日本語 |
|---|---|---|---|
| Jev | TypeSafe AI | 非公開（API） | — |
| d1 | Liquid AI | 非公開（API） | — |
| Laya | Convai Innovations | 公開 | 多言語版あり |
| AnyJev | Nokia Applied Research | 既存の LLM に被せる層 | 土台の LLM 次第 |
| sokudan | GeneLab | 公開 | 日本語専用 |
重みを公開した実装はほかにも多く、それらを同じ 13 万件超の問題で採点する Hugging Face の Jev Decision Index に、sokudan も載っています。
データを社外に出せない業務なら、重み公開のモデルが候補です。表の中で日本語に絞ったのが sokudan です。
2. sokudan を入れて、最初のハンコを押してもらう
前節で、判断モデルは選択肢ごとの確率を 1 回で返し、表の中で重み公開かつ日本語専用なのは sokudan だけだと見ました。重みが手元にあれば、データを外に出さずに試せます。
このセクションで分かること: インストール方法、3 種類の質問の書き方、返ってくる値の読み方
sokudan は 314.6M パラメータで、日本語の ModernBERT（sbintuitions/modernbert-ja-310m、MIT）に判定用のヘッドを足して学習しました。ModernBERT は、読むことに特化した Transformer です。文章と質問を 1 本の入力で読み（joint encoding）、1 質問につき 1 回モデルを通します。公開中の重み v0.2 は、同じ設定で学習した 8 本の重みを平均した model soup で、ライセンスは Apache-2.0 です。
インストール
pip install sokudan
Python 3.11〜3.13 に対応しています。macOS 14 以降のApple SiliconではMLXが入り、torch は入りません。Windows、Linux、Intel Mac では PyTorch が入り、CUDA、MPS、CPU の順に自動で選ばれます。GPU を使うときは、先に CUDA 版の torch を入れてください。
pip install torch --index-url https://download.pytorch.org/whl/cu128
pip install sokudan
3 種類の質問を投げる
import sokudan
agent = sokudan.load("GeneLab/sokudan-ja-310m")
state = "先月の請求で同じ金額が二回引き落とされています。至急ご確認ください。"
questions = {
"department": {
"type": "choice",
"instructions": "この問い合わせはどの部署が担当すべきか",
"criteria": {
"請求": "支払い・返金",
"技術": "不具合・障害",
"営業": "料金・新規契約",
"その他": "上記以外",
},
},
"urgency": {
"type": "score",
"instructions": "この依頼の緊急度は",
"criteria": ["急がない", "早めに", "業務が止まっている"],
},
"churn": {
"type": "noul",
"instructions": "解約を示唆しているか",
},
}
result = agent.predict(state, questions)
print(result["answers"]["department"]["choice"])
請求
result["answers"] の中身です（抜粋）。
{
"department": {
"type": "choice",
"choice": "請求",
"probabilities": {"請求": 0.9984, "技術": 0.0004, "営業": 0.0007, "その他": 0.0005},
"confidence": 0.9984
},
"urgency": {
"type": "score",
"score": 1.09,
"probabilities": {"0": 0.2075, "1": 0.4951, "2": 0.2974}
},
"churn": {"type": "bool", "noul": 0.0903}
}
-
choice: 選んだ選択肢と全選択肢の確率です。confidenceは一番高い確率です -
score: 段階ごとの確率と、その期待値です -
noul: P(はい) です。既定で較正がかかっています（5 章）
score の値は期待値です。記号を使う順に導入します。
- $K$（段階の数、整数）: 用意したハンコの数。この例では 3 です
- $k$（段階の番号、整数、0 始まり）: 左から何番目のハンコかを表します
- $p_k$（段階 $k$ の確率、スカラー）: $k$ 番目のハンコに手が伸びた割合です
\mathrm{score} = \sum_{k=0}^{K-1} k \, p_k
この式が言っているのは、手の伸び具合をハンコの番号で重み付けして平均する、ということです。例の値では $0 \times 0.2075 + 1 \times 0.4951 + 2 \times 0.2974 \approx 1.09$ で、真ん中の「早めに」寄りと読めます。
本番では動かす場所を固定すると安心です。明示すると、失敗しても別の候補へ切り替えずにエラーになります。
agent = sokudan.load("GeneLab/sokudan-ja-310m", backend="torch", device="cuda")
3. どれくらい当たるか — 300 件で腕前を確かめる
前節で、1 件の問い合わせに 3 つの判断が返ることを確かめました。ただ、1 件当たっただけでは業務に入れられません。受付係を窓口に座らせる前に、300 件の書類で腕前を確かめます。
このセクションで分かること: 公開ベンチ bench_ja での精度と、それを手元で計算し直すコード
bench_ja は、日本語の業務文 300 件に、部署（4 択）、緊急度（3 段階）、解約の示唆（はい / いいえ）の 3 問を付けた評価セットです（CC BY 4.0）。質問は学習で一度も使っていない書き方です。
| choice 正解率 | score RPS（低いほど良い） | bool 正解率 | bool AUROC | |
|---|---|---|---|---|
| sokudan v0.2 | 0.880 | 0.075 | 0.780 | 0.844 |
| laya-multilingual | 0.747 | 0.232 | 0.543 | 0.523 |
| 多数決 | 0.380 | 0.197 | 0.703 | — |
| ランダム | 0.253 | 0.201 | 0.513 | — |
AUROC は「はい」と「いいえ」の文を 1 つずつ取ったとき「はい」側に高い確率を付ける割合で、0.5 が当てずっぽうです。RPS は段階のずれを罰する指標で、遠い段階に外すほど重く数え、0 が完璧です。
表に Jev と d1 がないのは、測っていないからです。TypeSafe AI の利用規約が、同社のサービスや出力を類似製品の開発に使うことを禁じているため、開発中に Jev は一度も呼んでいません。
手元で計算し直す
表はリポジトリの評価スクリプトの値です。同じ定義で手元計算する最小コードを載せます。
curl -LO https://raw.githubusercontent.com/hiroki-abe-58/sokudan/main/data/bench_ja.jsonl
指標を計算する関数です。
import numpy as np
def rps(probs, gold):
"""段階の確率 probs と正解の段階 gold から RPS を出す（低いほど良い）"""
k = len(probs)
pred_cdf = np.cumsum(probs)
gold_cdf = (np.arange(k) >= gold).astype(float)
return float(((pred_cdf - gold_cdf) ** 2).sum() / (k - 1))
def auroc(scores, labels):
"""正例に負例より高い確率を付けている割合（同点は平均順位で扱う）"""
s = np.asarray(scores, dtype=float)
y = np.asarray(labels, dtype=bool)
ranks = np.empty(len(s))
ranks[s.argsort()] = np.arange(1, len(s) + 1)
for v in np.unique(s):
ranks[s == v] = ranks[s == v].mean()
n_pos, n_neg = y.sum(), (~y).sum()
return float((ranks[y].sum() - n_pos * (n_pos + 1) / 2) / (n_pos * n_neg))
300 件を判定して集計します。質問は bench_ja と同じものを、パッケージから読み込みます。
import json
import sokudan
from sokudan.eval.bench_ja import bench_questions
agent = sokudan.load("GeneLab/sokudan-ja-310m", temperatures=None)
questions = bench_questions()
with open("bench_ja.jsonl", encoding="utf-8") as f:
items = [json.loads(line) for line in f]
hit, top2, p_top1, rps_list, p_true = [], [], [], [], []
for item in items:
a = agent.predict(item["state"], questions)["answers"]
probs = a["department"]["probabilities"]
ranked = sorted(probs, key=probs.get, reverse=True)
hit.append(ranked[0] == item["department"])
top2.append(item["department"] in ranked[:2])
p_top1.append(probs[ranked[0]])
urg = a["urgency"]["probabilities"]
rps_list.append(rps([urg[str(k)] for k in range(len(urg))], item["urgency"]))
p_true.append(a["churn"]["noul"])
gold = [item["churn"] for item in items]
print(f"choice acc {np.mean(hit):.3f} top-2 {np.mean(top2):.3f}")
print(f"P(top1) 中央値 {np.median(p_top1):.3f}")
print(f"score RPS {np.mean(rps_list):.3f}")
print(f"bool acc {np.mean((np.array(p_true) >= 0.5) == gold):.3f}")
print(f"bool AUROC {auroc(p_true, gold):.3f}")
確率は小数第 4 位で丸めて返るので、最後の桁はずれることがあります。temperatures=None は較正を外す指定ですが、較正は 0.5 での判定も順位も変えないので 4 指標は同じです。bench_ja は評価用なので、学習には使わないでください（ライセンスではなくお願いです）。
4. 質問の書き方で正解率が 34 ポイント動く — ハンコに注意書きを付ける
前節の 0.880 は、各選択肢に 1 行の説明を付けた質問での値です。書き方で数字が動くなら、モデルより先に質問を直すべきです。そこで説明を外して測り直しました。
このセクションで分かること: 説明の有無で精度がどれだけ変わるかと、精度を落とさない質問の書き方
bench_ja の部署の質問が持つ説明を、空にしただけです。
"criteria": {
- "請求": "支払い・返金・請求書・料金の二重引き落としなど金銭処理に関するもの",
+ "請求": "",
# 技術・営業・その他も同じように空にする
}
3 章のコードで questions["department"]["criteria"] を上のとおり書き換えると、次の値を測り直せます。
| 正解率 | 上位 2 件に正解が入る率 | 1 位の確率の中央値 | |
|---|---|---|---|
| 説明つき | 0.880 | 0.963 | 0.997 |
| ラベルだけ | 0.537 | 0.747 | 0.546 |
正直に書くと、筆者が測った中でいちばん大きく効いたのは、モデルの構造でも学習データでもなく、この 1 行の説明でした。少し悔しい結果です。
勘定科目 10 項目では、ラベルだけでも 0.852 から 0.843 とほぼ同じでした。「旅費交通費」は名前で中身が伝わりますが、「請求」のような短い部署名は説明で初めて範囲が決まります。何を請求とするか書いていないハンコでは、受付係は迷います。
精度を落とさない書き方は 3 つです。
-
state は文字列で渡す: dict を渡すと
key: valueの行に変換され、学習時の入力と違うので結果が変わります。手元の 1 事例では P(はい) が 0.318 から 0.145 まで動きました - choice の criteria は dict、score は list: choice は「選択肢: 説明」の dict、score は低い順に並べた段階の list です
- 選択肢には説明を書く: 受け皿の「その他」にも「上記以外」と書きます
5. 実務で踏む 3 つの罠 — 外れ方には癖がある
前節までで、質問を正しく書けば部署の振り分けは 9 割近く当たると分かりました。残る 1 割強の外れ方に癖があれば、運用側で受け止められます。
このセクションで分かること: 受け皿の選択肢の閾値、人に見せる候補の数、確率を画面に出す前に確かめること
5-1. 「その他」は 1 位になりにくい
bench_ja で「その他」が正解の 38 件のうち、1 位になったのは 11 件（再現率 0.289）で、取りこぼしの多くは「技術」に入りました。選んだときの的中率は 0.846 です。押せば正しいのに、手が伸びないハンコです。
それでも P(その他) の順位は取れています。筆者が勘定科目 10 項目と「その他」で作った 90 件の検査では、どの科目にも当たらない書類を P(その他) で見分ける AUROC が 0.94 でした。なので 1 位を採るのではなく、P(その他) に閾値をかけます。
THRESHOLD = 0.1 # 手元のラベル付きデータで決める
def route(answer, catch_all="その他", threshold=THRESHOLD):
probs = answer["probabilities"]
if probs[catch_all] >= threshold:
return catch_all
rest = {k: v for k, v in probs.items() if k != catch_all}
return max(rest, key=rest.get)
label = route(result["answers"]["department"])
閾値はデータで大きく変わります。事後に同じデータで調べた参考値ですが、bench_ja では P(その他) が 0.05 以上を「その他」にすると再現率が 0.500 に上がり、ほかの書類を巻き込む率は 0.8% でした。同じ閾値でも、英語の bench_en では巻き込む率が 29% に達しています。
受け皿は、並びの先頭や最後に置かないほうが選ばれやすくなります。勘定科目の検査で、正解が「その他」の書類に付いた P(その他) は、先頭で 0.218、最後で 0.213、中ほどで 0.37〜0.42 でした。端に置いたハンコほど手が伸びません。
5-2. 人が確認するなら、上位 2 件を見せる
上位 2 件まで見れば、正解が入る率は 0.880 から 0.963 に、正解が「その他」の書類でも 0.289 から 0.763 に上がります。
def top_k(answer, k=2):
probs = answer["probabilities"]
return sorted(probs, key=probs.get, reverse=True)[:k]
print(top_k(result["answers"]["department"])) # ['請求', '営業']
会計アプリの PoC も、この形です。仕訳の摘要から勘定科目の候補を 1〜3 件に絞り、人が確認しています。受付係がハンコを数本差し出し、最後に押すのは人、という分担です。
5-3. 画面の「99%」は 99% ではない
bench_ja では 300 件中 224 件で 1 位の確率が 0.99 以上でしたが、うち 14 件（6.25%）は外れでした。「確信度 99%」と表示する前に、帯ごとの正解率を確かめてください。
def accuracy_by_band(top1_probs, correct, edges=(0.0, 0.9, 0.99, 1.01)):
p = np.asarray(top1_probs)
ok = np.asarray(correct, dtype=bool)
for lo, hi in zip(edges[:-1], edges[1:]):
m = (p >= lo) & (p < hi)
if m.any():
print(f"{lo:.2f}〜{min(hi, 1.0):.2f}: {m.sum():3d} 件, 正解率 {ok[m].mean():.3f}")
accuracy_by_band(p_top1, hit) # 3 章のループで集めた値
はい / いいえには既定で較正をかけています。P(はい) が低く出る癖があり、bench_ja では「はい」の割合 0.297 に対し平均 0.133、較正後も 0.198 です。較正は手の伸びを補正する眼鏡ですが、0.5 での判定は変えません。閾値は自分のデータの割合から決めてください。
ここまでのまとめ
- 判断モデルは選択肢ごとの確率を返し、選択肢にない答えは返さない
- sokudan は bench_ja で部署の振り分け 0.880、はい / いいえの AUROC 0.844
- 精度をいちばん動かすのは選択肢の説明で、消すと 0.537 まで落ちる
- 「その他」は閾値で拾い、人には上位 2 件を見せ、確率は帯ごとの正解率を見てから出す
6. 速さと置き場所 — 質問の数だけ書類を読み直す
前節で運用の形が決まりました。残る問いは、どのマシンで 1 件に何ミリ秒かかるかです。
このセクションで分かること: 環境ごとの待ち時間とメモリ、時間が増える条件、HTTP サーバーとしての置き方
まず、2 章の例の usage を見ます。
print(result["usage"]["backbone_passes"], result["usage"]["output_tokens"]) # 3 0
質問 3 つでモデルを 3 回通し、出力トークンは 0 です。受付係は、質問ごとに書類を頭から読み直しています。
| 環境 | 入力 | 1 件あたりの時間 |
|---|---|---|
| GPU: RTX 5090（fp32） | bench_ja 300 件、3 問 | 中央値 22.8 ms（p95 27.5 ms） |
| CPU: Core Ultra 9 285K（24 スレッド） | 同上 | 中央値 371 ms（p95 583 ms） |
| Apple M1 Max（MLX、float16） | 2 章の例文、3 問 | 中央値 17.8 ms |
| Apple M1 Max（MLX、float16） | 949 トークンの長文、3 問 | 中央値 約 276 ms |
GPU と CPU はウォームアップ 20 件のあと 300 件を 1 件ずつ測った値で、GPU のメモリは約 1.3 GiB でした。M1 Max は負荷の高い状態での計測です。手元で試すコードです（items は 3 章のもの）。
import statistics
import time
agent = sokudan.load("GeneLab/sokudan-ja-310m") # device="cpu" などで比べる
questions = bench_questions()
states = [item["state"] for item in items]
for state in states[:20]: # ウォームアップ（計測しない）
agent.predict(state, questions)
times_ms = []
for state in states:
start = time.perf_counter()
agent.predict(state, questions)
times_ms.append((time.perf_counter() - start) * 1000)
times_ms.sort()
print(f"中央値 {statistics.median(times_ms):.1f} ms")
print(f"p95 {times_ms[int(len(times_ms) * 0.95)]:.1f} ms")
時間が増える条件は 3 つです。
- 質問を増やすと、ほぼ比例して増えます。質問ごとに読み直すからです
- 選択肢を増やしても、読み直しの回数は増えません。選択肢は同じ 1 本の入力に並ぶだけです
- 文章が長いと増えます。1,024 トークンを超えた分は切り詰められ、
usageのstate_truncatedがTrueになります
HTTP の窓口を開ける
GPU なら 1 件 20 ms 台、メモリ約 1.3 GiB と軽いので、1 台に置いて HTTP で呼べば足ります。
pip install "sokudan[serve]"
sokudan serve --port 8000
curl -s localhost:8000/v1/systemone -H 'content-type: application/json' -d '{
"state": "先月の請求で同じ金額が二回引き落とされています。至急ご確認ください。",
"questions": {"churn": {"type": "noul", "instructions": "解約を示唆しているか"}}
}'
POST /v1/systemone の形は TypeSafe AI の公開 API リファレンスと同じで、d1 も同じ形です。判断モデル向けのクライアントは、接続先を http://127.0.0.1:8000 に変えるだけで向けられます。サーバーは公開ドキュメントとオープンな実装の README から作り、TypeSafe AI の SDK もサービスも使っていません。
7. 苦手なことと、任せる判断 — 押させてはいけない書類
ここまでで、入れ方、当たり方、外れ方、速さ、置き方がそろいました。最後に、任せない仕事を決めます。
このセクションで分かること: sokudan に任せてはいけない入力と用途、そして判定処理ごとの任せ先の決め方
- 日本語専用です: 英語の bench_en では、はい / いいえの正解率が 0.690 で、多数決の 0.683 とほぼ同じでした
- 長い文章は精度が落ちます: 学習した文章は平均 134 トークンで、土台のモデルが一度に見渡す範囲（ローカルな Attention の窓）は 128 トークンです
- 4 段階以上の score では最初の段階が選ばれにくい: 4 段階の緊急度で、最初の段階が選ばれたのは 300 件中 5 件でした
- 学習データは合成データです: 1 つの LLM で作った 21 分野、4,833 文書です。bench_ja も合成データです
採用、与信、懲戒、医療、法律のように、人の判断を置き換える用途には使わないでください。
全部の一覧は README の Limits とモデルカードにあります。
これで、判定処理 1 つ 1 つをどちらの受付係に回すかを決められます。
最初の分岐は 1 章、中ほどはこの章、最後は 5 章の結論です。受け皿のある質問には 5-1 の閾値もかけます。
トラブルシューティング
| 症状 | 原因 | 対処 |
|---|---|---|
| 例と確率が大きく違う | state を dict で渡している | 文字列で渡す |
| GPU があるのに遅い | CPU 版の torch が入っている | CUDA 版の torch を入れ直す |
Mac で backend="torch" が ImportError |
macOS 14 以降の Apple Silicon には torch が入らない | pip install "sokudan[torch]" |
| 「その他」がほとんど選ばれない | 受け皿は 1 位になりにくい | P(その他) に閾値をかけ、中ほどに置く |
| 「はい」がほとんど出ない | P(はい) が低く出る癖 | 自分のデータの割合から閾値を決める |
| 長い文章で外れが増える | 学習した文章は平均 134 トークン | 要点を切り出す、state_truncated を確かめる |
用語集
| 用語 | 意味 | 受付係のたとえ |
|---|---|---|
| 判断モデル | 文章と型付きの質問から、選択肢ごとの確率を返すモデル | ハンコしか持っていない受付係 |
| state | 判定したい文章 | 窓口に出された書類 |
| 受け皿の選択肢 | 「その他」のように、どれにも当たらないときの選択肢 | 「該当なし」のハンコ |
| 較正 | 確率の大きさを実際に当たる割合へ近づける補正。sokudan は温度スケーリング | 手の伸び具合を補正する眼鏡 |
| AUROC | 正例と負例を 1 つずつ取ったとき、正例に高い確率を付けている割合 | 「はい」の書類へ手が伸びる割合 |
| RPS | 段階のずれ方を罰する指標。低いほど良い | 遠いハンコに手が伸びるほど減点 |
| joint encoding | 文章と質問を 1 本の入力にまとめて読む方式 | 質問ごとに書類を読み直す |
| model soup | 同じ設定で学習した複数の重みを平均したもの | 何人かの受付係の癖をならした 1 人 |
学習ロードマップ
最初の一歩は、無料の CPU で動く Colab のノートブックです。
おわりに
sokudan は、TypeSafe AI とも Liquid AI とも関係のない、個人のオープンソースプロジェクトです。「System One」は TypeSafe AI による分類名で、この記事では判断モデルの種類を指す言葉として使いました。
ハンコしか持たない受付係は、何でも書ける受付係より不自由です。それでも仕分けの窓口なら、その不自由さがそのまま安心になる、と筆者は考えています。外れた例は GitHub の Issue で教えてください。
次の記事では、このモデルを作る過程で「3 シードの平均は嘘をつく」と知った話を書く予定です。
関連記事
-
文章を生成する側の仕組み: LLM
-
重みの配布先: Hugging Face
-
実務寄りの切り口で書いた Zenn 版
-
要点をまとめた: note版
参考文献
TypeSafe AI「Introducing System One Models & Jev」（邦訳: System One モデルと Jev の紹介、2026-09-15）。Jev の発表記事で、リンクは 1 章にあります。
GIGAZINE「ベンチマークでJev超えな意思決定モデル「d1」が登場」（2026-09-30）。Liquid AI の d1 発表の日本語解説です。
sokudan の docs/choice_guidance.md「Using choice questions well」（邦訳: choice の質問をうまく使う）。5 章の数字の出典です。
sokudan の docs/latency.md。6 章の GPU と CPU の計測条件です。Apple Silicon の値は同じフォルダの mlx.md にあります。