この記事の対象読者
- LLM に分類・ルーティング・スコアリングをやらせていて、コストかレイテンシに困っている実務者
この記事で得られること
自分のワークロードのうち、どの判断をSystem Oneモデルに出してよいかを、ECE・カバー率・月額コストの3つの数字で決められるようになる。
- RLCD が RLHF・RLVR と何を変えたのかを、1枚の表で説明できる
- 「較正されている」という主張を、自分のデータで検証する 30 行のコードが手に入る
- TypeSafe が公表した「444.6倍安い」を、価格表の算術だけで再現できる
この記事で扱わないこと
- Jev の早期アクセス申請手順
- RLCD の内部アルゴリズム。2026-09-19 時点で報酬関数・アーキテクチャ・学習手順はいずれも非公開であり、本記事も推測しない
なぜこれを書くのか
筆者は放送系クライアント向けに、問い合わせメールを部署に振り分けたり、素材の不備をスコアリングしたりする小さな自動化を書いている。中身はだいたい LLM に JSON を吐かせて if で分岐するだけの、地味な代物だ。
この手の仕組みには昔から不満が1つあった。モデルに「自信はどれくらい？」と聞くと、必ず 0.9 と答えるのである。0.9 と言いながら外す。外したあとにもう一度聞いても 0.9 と答える。結局どのしきい値を引いても意味がなく、全件を人間が見るという運用に落ち着いた。自動化のつもりが確認作業を増やしただけだった。
2026年9月15日に TypeSafe AI が発表した Jev は、まさにその不満を名指しで解こうとしている。売り文句は「較正された確率を返す」。もし本当なら、筆者が諦めたしきい値運用が復活する。
だから、この記事で読者に考えてほしいのはモデルの新しさではない。確率が正しいかどうかは、自分のデータで測れるという一点である。手元は Xeon 1コア・メモリ 4GB という貧弱な Linux 環境だが、この検証にはそれで足りる。
1. System Oneモデルは、何を捨てたのか
このセクションで分かること：Jev が LLM と何を取り替えたのか。
TypeSafe AI は、元 OpenAI 研究員の Diogo Almeida 氏が創業した AI ラボである。同氏は RLHF と ChatGPT の共同発明者の一人で、同社は 4,000万ドルの調達を経て 2026年9月15日に Jev を公開した。
Jev の特徴は、文章を一切生成しないことにある。開発者はまず state という値を渡す。これは JSON オブジェクトでも、「カードが二重に請求された」という単なる文字列でもよい。そこに Choice・Score・Noul という3種類の質問プリミティブを添えると、それぞれ確率つきの構造化された答えが返る。
たとえば問い合わせをどの部署が担当すべきかを尋ねると、billing 0.08 / technical 0.85 / sales 0.07 という分布が、confidence 0.82 とともに返ってくる。人間が読む答えとしては役に立たないが、if を書く側にはこれでいい。
本記事では一貫して気象予報士のたとえを使う。従来の LLM は「明日は荒れそうですね、傘があると安心です」と文章で語る予報士だ。Jev は「降水確率 85%」とだけ言う予報士である。前者は読んで気持ちがいい。後者は、傘を持つかどうかを機械が決められる。
3つのプリミティブ
| 型 | 何を答えるか | 返る値 |
|---|---|---|
| Choice | この選択肢のどれか |
choice / probabilities / confidence
|
| Score | どの段階か |
score / legend / probabilities / confidence
|
| Noul | これは真か |
noul（0〜1の確率） |
1つのリクエストに複数の質問を入れられる。すべての質問が同じ state を見て、独立に評価され、指定した ID の下に型のついた答えが返る。
from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
state = {
"ticket_message": "フライトが欠航しました。返金してもらえますか？",
"refund_policy": "欠航便は全額返金の対象です。",
}
with TypeSafeClient() as client:
response = client.system_one(
state=state,
questions={
"refund_requested": Noul(
instructions="`ticket_message` は返金を求めているか？",
),
"request_type": Choice(
instructions="`ticket_message` の主な要求は何か？",
criteria={
"refund": "顧客は返金を求めている。",
"rebooking": "顧客は代替便を求めている。",
"information": "顧客は情報だけを求めている。",
},
),
},
)
print(response.answers["refund_requested"].noul)
print(response.answers["request_type"].choice)
捨てたものもはっきりしている。Jev はテキスト生成の訓練を受けていない。Choice を連鎖させて無理に生成させることはできるが、うまくいかないうえに非常に遅い。文章が要るなら別のモデルを使えというのが公式の立場である。
2. RLCD — 何を最適化目標に据えたのか
前節で、Jev が文章を捨てて確率だけを返すモデルだと分かりました。では、そんなモデルはどう訓練するのか。文章の良し悪しを人間に評価させる従来の方法は、そもそも評価対象の文章が存在しないので使えません。ここが RLCD の出番です。
このセクションで分かること：RLCD が RLHF・RLVR と何を入れ替えたのか。
RLCD は Reinforcement Learning for Calibrated Decisions（較正された決定のための強化学習）の略である。
事前学習済みの言語モデルを適応させる方法はこれまで2つあった。TypeSafe はそこに3つ目を足す。RLHF は人が好む応答を作るよう訓練し、RLVR は数学のように検証可能なタスクに強い推論モデルを生んだ。RLCD は、生成されたテキストではなく、決定と較正された確率を返すよう訓練する。
| RLHF | RLVR | RLCD | |
|---|---|---|---|
| 最適化対象 | 人間が好む応答 | プログラムが検証できる出力 | 較正された確率つきの決定 |
| 出力 | 文字列 | 文字列 | 型のついた構造化値 |
| 主な用途 | チャット・コパイロット | 数学・カーネル最適化 | ソフトウェア内の分岐 |
RLCD が目指す出力の契約は次の3点である。モデルはテキストを生成しない。決定と確率を返す。そして、確率が高いほど、その答えが正しい可能性が高くなければならない。
3つ目が本丸だ。較正が意味を持つのは多数の予測の集合においてである。確率 0.2 を割り当てた事象は約20%の頻度で起き、0.8 なら約80%起きる。これは予測の集団についての性質であって、個々の答えを保証するものではない。
予報士のたとえに戻すと、こうなる。RLHF は「視聴者が納得する解説」で採点される予報士だ。RLCD は「80%と言った日の8割で本当に降ったか」だけで採点される予報士である。前者は自信たっぷりに外しても評価が下がらない。
同じ RLCD という略語で、まったく別の手法が 2023 年から存在します。Yang らの Reinforcement Learning from Contrast Distillation（arXiv:2307.12950, ICLR 2024）で、こちらは RLHF 用の選好データを対照的なプロンプトから生成する手法です。検索時は必ず TypeSafe と併記してください。
3. 「較正されている」を自分で測る
前節で、RLCD の主張の中心が「確率 0.8 の答えは8割当たる」という性質だと分かりました。これは主張である以上、検証できるはずです。そして検証の道具は Jev がなくても作れます。
このセクションで分かること：較正の測り方と、それが壊れる条件。
較正のズレを測る標準的な指標が ECE（Expected Calibration Error、期待較正誤差）である。予測を確信度でビンに分け、各ビンで「言った確率」と「実際の正答率」の差を取り、件数で加重平均する。
\mathrm{ECE} = \sum_{m=1}^{M} \frac{|B_m|}{n} \Bigl| \mathrm{acc}(B_m) - \mathrm{conf}(B_m) \Bigr|
記号を1つずつ置く。
| 記号 | 読み | 型 | 予報士のたとえでの意味 |
|---|---|---|---|
| $B_m$ | m番目のビン | 集合 | 「降水確率80%台と言った日」の集まり |
| $\lvert B_m \rvert$ | ビンの件数 | スカラー | その日数 |
| $n$ | 全件数 | スカラー | 観測した全日数 |
| $\mathrm{acc}(B_m)$ | ビン内の正答率 | スカラー | 実際に降った日の割合 |
| $\mathrm{conf}(B_m)$ | ビン内の平均確信度 | スカラー | その日々に言った確率の平均 |
この式が言っているのは、言った確率と実際の頻度のズレを、日数で重みをつけて平均したものである。0 に近いほど予報が正直だ。
import numpy as np
def expected_calibration_error(probs, y, n_bins=15):
"""ECE: 予測確率をビンに分け、|平均確率 - 実際の正答率| をサンプル数で加重平均する。"""
conf = probs.max(axis=1)
correct = (probs.argmax(axis=1) == y).astype(float)
edges = np.linspace(0.0, 1.0, n_bins + 1)
ece = 0.0
for lo, hi in zip(edges[:-1], edges[1:]):
m = (conf > lo) & (conf <= hi)
if m.any():
ece += m.mean() * abs(correct[m].mean() - conf[m].mean())
return float(ece)
def gated_stats(probs, y, tau):
"""confidence >= tau を自動処理したときの (カバー率, 自動処理の誤り率) を返す。"""
gate = probs.max(axis=1) >= tau
if not gate.any():
return 0.0, float("nan")
return float(gate.mean()), float(1.0 - (probs.argmax(axis=1)[gate] == y[gate]).mean())
実験：較正はモデルの性質ではない
scikit-learn の手書き数字データセットで 10クラス分類器を学習させ、4条件で測った。B は入力にガウスノイズを乗せて分布をずらしたもの、C と D は温度スケーリングで確率だけを補正したものである。
def apply_temperature(probs, t):
"""log p を T で割って softmax し直す。argmax は不変なので正答率は変わらない。"""
z = np.log(np.clip(probs, 1e-12, None)) / t
z -= z.max(axis=1, keepdims=True)
e = np.exp(z)
return e / e.sum(axis=1, keepdims=True)
def fit_temperature(probs, y):
"""検証集合の負の対数尤度を最小化する T をグリッド探索する。"""
grid = np.linspace(0.20, 30.00, 2981)
nll = [-np.log(np.clip(apply_temperature(probs, t)[np.arange(len(y)), y], 1e-12, None)).mean()
for t in grid]
return float(grid[int(np.argmin(nll))])
def blur(X, rng, sd=4.0):
"""画素値 0-16 にガウスノイズを乗せ、本番でのドリフトを模す。"""
return np.clip(X + rng.normal(0.0, sd, X.shape), 0.0, 16.0)
計測環境：Ubuntu / Xeon 2.10GHz 1コア / RAM 4GB / Python 3.12.3 / NumPy 2.4.4 / scikit-learn 1.8.0。学習 718件・較正用 539件・テスト 540件。
| 条件 | 正答率 | 平均確信度 | ECE | 自動化率@0.90 | 自動処理の誤り率@0.90 |
|---|---|---|---|---|---|
| A 学習と同じ分布 | 0.965 | 0.967 | 0.0086 | 0.907 | 0.0041 |
| B 分布がずれた | 0.250 | 0.886 | 0.6389 | 0.665 | 0.7298 |
| C B に同分布で合わせた温度 | 0.250 | 0.866 | 0.6174 | 0.607 | 0.7348 |
| D B にずれた分布で合わせ直した温度 | 0.250 | 0.171 | 0.1067 | 0.000 | — |
条件 A では、確信度 0.90 以上を自動処理すると全体の 90.7% を人手なしでさばけて、そのうち誤るのは 0.41% だった。これが較正が効いている状態である。
条件 B が問題だ。正答率は 0.965 から 0.250 へ崩壊したのに、平均確信度は 0.886 のまま高止まりしている。しきい値 0.90 で 66.5% を自動処理し、その 73% を間違える。筆者が過去に踏んだのはまさにこれで、指標として見ると想像以上に露骨だった。
条件 C は、本番でずれることを知らずに「較正済みモデル」を使い続けた場合にあたる。ECE は 0.639 から 0.617 にしか下がらない。較正は一度やれば済む作業ではない。
条件 D で温度を引き直すと ECE は 0.107 まで下がり、そして自動化率が 0 になる。これは失敗ではない。較正されたモデルが「この分布については何も分からない」と正直に申告し、全件を人間に回した状態である。予報士が「今日は予報を出せません」と言ったのと同じで、これが欲しかった挙動だ。
ここから言えることは1つです。較正はモデル単体の性質ではなく、モデルと分布の組み合わせの性質です。RLCD で訓練されていても、あなたの本番データで測り直すまでは何も保証されません。
実務フレームワークでの書き方
PyTorch でロジットから直接測るなら3行で足りる。
import torch
def ece_torch(logits: torch.Tensor, y: torch.Tensor, n_bins: int = 15) -> torch.Tensor:
conf, pred = logits.softmax(dim=1).max(dim=1)
correct = pred.eq(y).float()
bins = torch.linspace(0, 1, n_bins + 1, device=logits.device)
ece = torch.zeros((), device=logits.device)
for lo, hi in zip(bins[:-1], bins[1:]):
m = (conf > lo) & (conf <= hi)
if m.any():
ece += m.float().mean() * (correct[m].mean() - conf[m].mean()).abs()
return ece
4. confidence の定義は1つではない
前節で、確率の目盛りが正しいかを ECE で測れることが分かりました。ただし Jev が返す confidence は確率そのものではなく、確率分布を1つの数に潰した統計量です。潰し方は何通りもあり、公式ドキュメントもそれを認めています。つまりここは、読者が選ばなければならない設計判断です。
このセクションで分かること：confidence の定義を変えると運用がどう動くか。
TypeSafe の説明では、確率分布の形そのものがモデルの確からしさを表す。1つの結果に集中していれば自信のある答えで、広がっていれば不確かな答えである。confidence プロパティはその形を 0 から 1 の1つの数に潰したもので、利用者が自分で計算しなくてもしきい値を引けるようにしてある。
そして公式ドキュメントは、この定義が唯一解ではないと明言している。多くの用途に合う便利な指標として提供しているが、利用者がこの定義に縛られることはない。評価対象によっては別の指標のほうが適することがあり、まさにそのために完全な probabilities を返している。
そこで、同じ分布から3通りの confidence を作って比べた。
def top1(p):
"""最大確率そのもの。最も素朴な定義。"""
return p.max(axis=1)
def margin(p):
"""1位と2位の差。2位が迫っているかだけを見る。"""
s = np.sort(p, axis=1)
return s[:, -1] - s[:, -2]
def neg_entropy(p):
"""1 - 正規化エントロピー。分布全体の尖り具合を見る。"""
q = np.clip(p, 1e-12, None)
h = -(q * np.log(q)).sum(axis=1) / np.log(p.shape[1])
return 1.0 - h
def err_at_coverage(p, y, conf, cov):
"""カバー率を cov に固定したときの誤り率。しきい値の目盛りの違いを打ち消して比べる。"""
k = max(1, int(round(cov * len(y))))
idx = np.argsort(-conf)[:k]
return float(1.0 - (p.argmax(axis=1)[idx] == y[idx]).mean())
| 分布 | confidence の定義 | 自動化率@0.90 | 誤り率@0.90 | カバー70%時の誤り率 | カバー50%時 |
|---|---|---|---|---|---|
| 同分布 | top1 | 0.907 | 0.0041 | 0.0000 | 0.0000 |
| 同分布 | margin | 0.872 | 0.0042 | 0.0000 | 0.0000 |
| 同分布 | 1-正規化エントロピー | 0.861 | 0.0022 | 0.0000 | 0.0000 |
| ずれた分布 | top1 | 0.665 | 0.7298 | 0.7249 | 0.7296 |
| ずれた分布 | margin | 0.604 | 0.7362 | 0.7275 | 0.7370 |
| ずれた分布 | 1-正規化エントロピー | 0.602 | 0.7354 | 0.7275 | 0.7333 |
同分布では、定義を厳しくするほど自動化率が下がり誤り率も下がる。素直なトレードオフだ。カバー率を 70% や 50% に絞れば誤りはゼロになる。
正直に言うと、筆者が驚いたのは下半分である。分布がずれると、どの定義を使っても、カバー率を 50% まで絞っても、誤り率が 73% から動かない。全体の誤り率 75% とほぼ同じである。
これは confidence が2つの能力に分解できることを示している。順位づけの力（怪しい件を下位に並べられるか）と、目盛りの正しさ（0.8 が本当に8割か）である。ECE が測るのは後者だけだ。条件 D で ECE が 0.107 まで改善しても、実は前者は失われたままだった。
したがって本番前に測るべき数字は2つあります。ECE と、「カバー率を絞ると誤り率が下がるか」です。後者が下がらないなら、どんなしきい値を引いても confidence ゲートは機能しません。
ここまでのまとめ
- Jev は文章を捨てて、型のついた確率つき決定だけを返すモデル
- RLCD は「人間の好み」でも「検証可能性」でもなく、確率の正しさを最適化目標に据えた
- 較正はモデルと分布の組み合わせの性質で、分布がずれれば壊れる
- 測るべきは ECE と、カバー率を絞ったときの誤り率の低下、この2つ
残るはコストである。
5. 「444.6倍安い」を算術で再現する
前節までで、品質側の判断材料が揃いました。あとは値段です。公表されている倍率は自社計測なので、価格表だけを使って自分で組み直せるかを確かめます。
このセクションで分かること：倍率がどこから来ているか。
公表価格はこうなっている。Jev は入力 100万トークンあたり 0.042ドル、出力は無料。1リクエストあたりの文脈長は 64k トークンで、state と最も長い質問の合計には 32k の上限がかかる。比較対象として、GPT-5.6 Terra は入力 100万トークンあたり 2.00ドル、出力 12.00ドルである。
JEV_IN = 0.042 / 1_000_000 # USD / token
def jev_cost(w):
"""state は1回だけ送り、全質問を並列評価する。出力は無料。"""
tok = w.state_tokens + w.n_questions * w.question_tokens
return tok * JEV_IN * w.decisions_per_day
def llm_cost(w, price_in, price_out, batched=True):
"""batched=False は質問ごとに別リクエストを立てる場合。state を毎回再送する。"""
if batched:
tok_in = w.state_tokens + w.n_questions * w.question_tokens
else:
tok_in = w.n_questions * (w.state_tokens + w.question_tokens)
tok_out = w.n_questions * w.out_tokens
return (tok_in * price_in + tok_out * price_out) / 1_000_000 * w.decisions_per_day
def fanout_ratio(w):
"""質問を1リクエストにまとめたときの入力トークン削減率。state 再送をやめた効果そのもの。"""
separate = w.n_questions * (w.state_tokens + w.question_tokens)
batched = w.state_tokens + w.n_questions * w.question_tokens
return separate / batched
1日10万判断、1判断あたり13問、state 2000トークン、質問40トークン、LLM 側の構造化出力を1問30トークンとした場合の月額（30日）は次のとおり。
| 構成 | 月額 USD | Jev比 |
|---|---|---|
| Jev（入力 $0.042 / 出力 $0） | 317.52 | 1.0x |
| 小型LLM（入力 $0.20 / 出力 $1.00） | 2,682.00 | 8.4x |
| GPT-5.6 Terra（入力 $2.00 / 出力 $12.00） | 29,160.00 | 91.8x |
| フロンティア級（入力 $10.00 / 出力 $50.00） | 134,100.00 | 422.3x |
フロンティア級との比が 422.3倍。TypeSafe が公表した 444.6倍にほぼ一致する。つまりこの倍率は特殊な計測条件から出た数字ではなく、価格表の引き算でおおむね再現できる。逆に言えば、比較対象を小型モデルに変えた瞬間に 8.4倍まで落ちる。倍率は相手次第だ。
「並列だから10倍速い」の正体
TypeSafe のクックブックには、13問を1リクエストにまとめると約12倍安く約10倍速いという例がある。この12倍がどこから来るかを、トークン数だけで計算してみた。
| state トークン | 質問3問 | 質問13問 | 質問30問 |
|---|---|---|---|
| 500 | 2.6x | 6.9x | 9.5x |
| 2000 | 2.9x | 10.5x | 19.1x |
| 8000 | 3.0x | 12.3x | 26.2x |
state 2000・13問で 10.5倍。公表値とほぼ同じ数字が、同じ state を13回送り直すのをやめたという一事だけから出てくる。
これは重要な注意点である。この削減はモデルの新しさとは無関係で、LLM 側でも同じことをすれば同じだけ効く。実際、GPT-5.6 Terra 相当で13問を分割送信すると月額は 29,160ドルから 173,160ドルへ 5.9倍に膨らむ。手元の実装が1問1リクエストになっているなら、モデルを替える前にそこを直したほうが早い。
公式ドキュメント内でこの倍率の記載が揺れています。プリミティブの解説ページは 11.5倍安く 9.6倍速い、ドキュメント索引は 12.2倍安く 10.0倍速いとしています。どちらを引用するにせよ出典ページを添えてください。
6. 採用判断のフローチャート
前節で、品質・較正・コストの3つの数字が揃いました。ここでそれを1つの判断に落とします。
このセクションで分かること：自分のどのタスクを移すべきか。
判断を1文にすると、生成が不要で、選択肢が閉じていて、本番分布で confidence の順位づけが機能するタスクだけが移行対象になる。
7. Jev の弱いところ
前節のフローで移行対象を絞れました。ただし移行先にも苦手があります。公式が失敗モードを公開しているので、そこから運用上の注意を拾います。
このセクションで分かること：どこで踏むか。
公式ドキュメントは jev-1.13 の弱点を明示している。System One タスクでは最も良い成績を出すが、間接性が何段も入るタスクは苦手で、理解がかなり字義通りになり、数値の精度を要するタスクでは苦戦する。
| 症状 | 原因 | 対処 |
|---|---|---|
| 意図と違う答えが返る | 書いた通りの質問に答えるため、限定語や否定が額面通りに読まれる | 境界条件を criteria に書く。解釈が要るなら2つの質問に割る |
| 件数や個数が合わない | 数えるのではなく答えの形を認識しており、対象が大きいほど誤差が増える | コードで数える。候補ごとに Noul を1つ立てて合計する |
| 日付の前後判定が外れる | 日付を順序を持つ量ではなくテキストとして読む | Choice で年月日の部品を抽出し、比較はコードで行う |
| state を大きくしたら精度が落ちた | 判断に無関係な内容が増えるほど精度が落ち、それが注意をそらす要因として働く | 先に検索・絞り込みをして、質問に必要な項目だけ送る |
| Noul と Choice で答えが食い違う | 構造的な不変性は保証されておらず、同じ問いを Noul と yes/no の Choice で聞くと値が一致しない | 一方で調整したしきい値を他方に流用しない |
「幻覚しない」という宣伝文句についても、冷静な指摘がある。The Register は、出力が自然言語でない以上これは公平な比較ではないと書いている。Jev が返すのは確率つきの構造化された応答であり、それは間違っている可能性を排除するものではない。型エラーが起きないことと、判断が正しいことは別である。
用語集
本文からの参照用に置く。
| 用語 | 定義 | 予報士のたとえでの対応 |
|---|---|---|
| System Oneモデル | テキストを生成せず、型のついた確率つき決定を返すモデルの分類 | 数字だけを言う予報士 |
| RLCD | 較正された確率つき決定を返すよう最適化する学習手法 | 「80%と言った日の8割で降ったか」で採点する仕組み |
| 較正 | 予測確率と実際の頻度が一致している性質 | 予報が当たる割合と、言った確率が揃っている状態 |
| ECE | 確信度ビンごとの確率と正答率の差を件数で加重平均した指標 | 予報のズレの平均 |
| カバー率 | しきい値以上として自動処理に回した件の割合 | 予報を出せた日の割合 |
| Noul | 真偽を確率で返す質問プリミティブ | 降るか降らないかを確率で答える |
| 分布シフト | 本番データが学習時と違う分布になること | 引っ越して気候が変わった |
学習ロードマップ
最初の一歩は Jev の申請ではなく、いま動いている分類器のログに対して ECE を計算することである。本記事のコードはそのまま使える。
まとめ
RLCD は、AI の最適化目標を「人間が納得するか」から「確率が現実と合っているか」へ動かす試みだった。方向としては正しいと思う。筆者が全件レビュー運用に落ちた原因は、まさに前者で訓練されたモデルに後者を期待したことだったからだ。
一方で、記事を書くために数字を組み直して分かったこともある。公表されている倍率のかなりの部分は、価格表の差と、state を再送しないという設計の差で説明がついてしまう。前者は比較対象を変えれば動くし、後者は今の実装を直せば今日から効く。
そして較正そのものは、訓練で与えられる性質ではなく、分布ごとに測り直す運用だった。条件 D で自動化率がゼロになった瞬間が、この検証で一番おもしろい結果だった。何もしないことを正しく選べるモデルというのは、確かに今までなかった。
アルゴリズムの詳細が公開されていない以上、現時点で言えるのはここまでである。RLCD の中身が出てきたら、また測る。
参考文献
- TypeSafe AI 公式ブログ「Introducing System One Models & Jev」（邦題訳：System One モデルと Jev の紹介）— 発表日 2026年9月15日。比較表・自社評価・留意事項が本人の言葉で書かれている
- TypeSafe AI 公式ドキュメント「AI primer」（邦題訳：AI 入門）— RLHF・RLVR・RLCD の関係と、較正の定義が書かれた一次資料
- TypeSafe AI 公式ドキュメント「Jev 1.13 jaggedness」（邦題訳：Jev 1.13 のざらつき）— ベンダー自身が公開した9つの失敗モードと回避策
- The Register「TypeSafe AI debuts model for machines that plays Doom」（邦題訳：TypeSafe AI、Doom をプレイする機械向けモデルを発表）— 調達額・比較価格と、幻覚しないという主張への批判的な整理
- Yang et al.「RLCD: Reinforcement Learning from Contrast Distillation for Language Model Alignment」（邦題訳：RLCD ── 対照蒸留による強化学習を用いた言語モデルのアラインメント）arXiv:2307.12950 — 同名の別手法。混同注意
関連記事
- Transformer — 自己回帰生成の仕組み。Jev が捨てたのはこの部分
- Attention — 逐次生成とキャッシュのコスト構造
- MCP — ツール呼び出しの型安全性が問題になる場面
公表倍率の内訳を価格表から組み直した検証と、confidence を2つの能力に分解した実測は Zenn 側に詳しく書いています。
更新や検証中の細かい話は X に流しています。
YouTubeでも解説動画を作りました。