GitHubで公開されたKevは、文章を生成するモデルというより、「この問い合わせはどの部署が担当すべきか」「緊急対応が必要か」「どれくらい不満が強いか」といった判断を返すための、小型の decision model だ。しかも、外部の専用サービスを呼ぶのではなく、自分の手元で学習し、実行できることを売りにしている。いま取り上げる理由は、単に新しいモデルが出たからではない。LLMの使い道が“文章を作る”から“判断を安定して返す”へ少しずつ広がっていて、その現実的な一例としてかなり面白いからだと思う。
Kevは、jaredpalmer が GitHub で公開している「tiny Jev-like family of decision models」だ。土台には Qwen3.5 を使い、Jev の Architecture Unmasked で述べられた設計を踏まえている。要するに、会話文や入力テキストを読んで、分類や評価を返すことに寄せたモデル群である。配布されているのは 0.8B、4B、9B の3種類で、学習コードと評価データもそろっている。重みは公開されており、pretrained weights を使うことも、自分で再学習することもできる。
入力の受け方が少し変わっている。Kev は yes/no の noul、選択肢から答える choice、段階評価の score を同じリクエストの中でまとめて処理できる。しかも、それぞれの質問は同じ入力文を参照するが、質問同士の中身は読めない。つまり、「部署判定」「緊急度」「感情の強さ」を一度に聞いても、1つ目の回答が2つ目に影響するような作りにはしていない。ここは、1回の推論で複数の判断を安定して取りたい用途に向いている。
README では、ローカルで動かす手順もかなり具体的に示されている。Python 3.12+ と uv を使い、kev.serve を立ち上げれば、localhost:8009 に API が生える。TypeSafe の System One と互換性があるので、Python SDK をそのまま向けられる。例として出ているのは、配送が遅れてサイズも違い、カードに二重請求があるという問い合わせだ。このとき Kev-4B は、department を returns、escalate を「緊急の人手対応が必要ではない」とし、frustration はかなり強い怒り寄りと返している。しかも単一ラベルではなく、returns 0.47、shipping 0.28、billing 0.25 のような確率まで返す。README がわざわざ「確率を返すのは、複数の要素が同時に見えているからだ」と説明しているのは、このモデルの狙いをよく表している。
実行面では CUDA、ROCm、Apple Silicon に対応し、4B と 9B は bf16 なら 32GB の Mac に載るとしている。ブラウザ上で試せる playground もあり、選択肢の並び順を変えたときの挙動や、複数質問をまとめて投げた場合と個別に投げた場合の違いを確認できる。さらに chess demo まであり、盤面を入力、合法手を選択肢、局面評価を score に見立てて遊べる。単なるデモ集ではなく、「こういう判断問題をこのモデルで扱える」という見本を重ねている印象だ。
性能評価も載っている。Kev-0.8B、Kev-4B、Kev-9B の3つについて、訓練で見たソースと未知のソースを分けて精度と Brier score を示している。たとえば Kev-4B は、新しいソースで Accuracy が development / test で 0.797 / 0.837、Brier が 0.299 / 0.255。Kev-9B は新しいソースで 0.822 / 0.852、Brier が 0.286 / 0.237 だった。README は、Kev-9B が Jev を新しいソースの development set で 3.5ポイント下回る一方、test set では 0.852 を出しており、Jev 側はその test set を走らせていないので厳密比較ではない、とも書いている。
興味深いのは、2026-09-21 に全モデルへ短い2回目の学習を入れた点だ。日数が明示された policy ケースや、判断材料をわざと取り除いたケースを追加で学習させ、後者は均一な回答に寄せたという。これで Kev-9B の test set は 0.837 から 0.852 に上がり、Kev-4B は 0.832 から 0.837、Kev-0.8B は 0.668 から 0.684 になった。さらに各チェックポイントには温度パラメータが保存されており、デフォルトでは calibration を整える。KEV_TEMPERATURE=1.0 にすれば生の logits に戻せるし、KEV_DATE_FACTS=1 で日付差分を文として埋め込むこともできる。README は、日付の引き算自体は苦手だが、明示された日数なら使えるとしている。
まず目を引くのは、Kev が「答えの正しさ」だけでなく「確率の扱い」まで正面から設計している点だと思う。一般的な分類モデルはラベルを返せば終わりだが、現場の判断では、どの候補がどれくらいありそうかの方が大事な場面が多い。返品、配送、請求が絡む問い合わせで単一ラベルだけ出されると、あとで人間が見直すときに根拠が薄い。Kev が複数の候補と confidence を出すのは、その弱点をかなり意識しているように見える。
一方で、これは「賢さ」の演出ではなく、運用のための設計でもある。temperature を各チェックポイントに持たせ、校正済みの確率をデフォルトにしているのは、モデルが自信満々に外す事故を減らしたいからだろう。README にある「wrong answers with probability ≥ 0.9」が calibration で半減するという説明は、派手さはないが実務では効く。人間が最終判断するなら、外れたときにどれだけ危険かは大きい。ここを隠さず出しているのは好感が持てる。
Kev の面白さは、API の思想だけでなく配布の仕方にもある。CUDA だけでなく ROCm と Apple Silicon を明記し、しかも 4B と 9B が 32GB の Mac に収まる可能性まで書いている。これは「研究デモ」としては控えめだが、個人や小規模チームにはかなり刺さる。クラウド前提の推論基盤を組まずに、自分の手元で検証し、社内の限定用途で回す道が見えるからだ。
ただ、ここには期待しすぎない方がいいとも思う。README は性能例をかなり丁寧に示しているが、同時に Mac での挙動は Serving Performance を見よ、と釘を刺している。つまり「動く」と「十分速い」は別だ。ローカルで回せることは強みだが、実運用で人が待てる応答時間か、負荷が増えたときにどうなるかはまた別問題になる。公開リポジトリがそこを曖昧にしないのは誠実だが、導入側もそこを見誤らない方がいい。
README には Jev との比較もあるが、ここは数字の上下だけで騒ぐべきではないと思う。Kev-9B は新しいソースの development set で Jev に少し届かず、test set では 0.852 を出した。ただし Jev がどのデータで学習したのか不明なので、同じ土俵の比較ではない。こう書いてあるのは地味だが重要だ。生成AIの世界では、ベンチマークの見せ方ひとつで印象が大きく変わる。ここで無理に「上回った」と言わないのは健全だ。
むしろ見たいのは、Kev が評価軸をかなり細かく持っていることだ。Accuracy だけでなく Brier score を出し、新しいソースと訓練済みソースを分け、さらに calibration の改善まで見ている。これは「当たるかどうか」だけではなく、「どれくらい信じてよいか」を測ろうとしているということだ。意思決定モデルで本当に重要なのはそこなので、この姿勢はかなり筋が通っている。
Kev を見ていると、派手なチャットAIとは別の流れがはっきりしてきた感じがある。人と雑談するモデルより、問い合わせ振り分け、フォーム審査、簡単なルーティング、将棋やチェスのような選択肢のある判断に寄せたモデルのほうが、ずっと現場で置き換えやすい。しかも、そこでは長文の創造性より、確率付きの安定した分類の方が価値になる。
ただし、こうしたモデルが広く使われるほど、評価データの作り方がより重要になるとも思う。Kev は公開データと学習コードまで出しているので、再現性の方向ではかなり良い。反面、実際の問い合わせはもっと汚く、曖昧で、部署境界も崩れていることが多い。だからこそ、このモデルを「答えを出す機械」ではなく、「人間の判断を前処理する機械」として使う方がしっくりくるはずだ。過信せず、でも軽く扱いすぎない。そのバランスを探るための素材として、Kev はかなり面白い。
