Kev - 文書キャッシュと独立した質問処理で確率を返す判断モデル

サポートチケットには、担当部署、緊急度、感情といった異なる判断が同居する。Kevでは共通文書をstate、判断ごとの指示と基準をquestionとして分ける。ひとつの文書に複数の問いを定義し、それぞれに適した出力型を与える構成だ。READMEの例は、複数の問題を含むチケットについて候補確率を使い、確信のある判断を自動化し、それ以外を人へ送る運用を示している。

ここで必要なのは、自然文としてもっともらしい回答だけではない。複数の部署が当てはまる入力では、最大確率の候補だけを受け取ると曖昧さを扱いにくい。候補分布を返す設計なら、どの判断を自動化するかという業務側の条件を検討できる。ただし、その分布が業務上の誤りをどれだけ説明できるかは、別途評価しなければならない。

比較対象のひとつは、質問ごとに個別の順伝播を行う構成だ。この場合、同じstateを各質問で再計算するため、共通入力が長いほど重複処理が問題になる。一方、質問を同じシーケンスにまとめるなら、互いの質問を参照させない仕組みが必要になる。

READMEによれば、Qwen3.5/3.8のGated DeltaNet層はattention maskを参照しない。したがって、maskだけで同一シーケンス内の質問を分離する方法では足りない。Kevは各質問を独立した行にし、文書の計算済みキャッシュを再利用する。共有する範囲を文書に限定し、質問側の処理を分けることが、この設計を理解する出発点になる。

リポジトリは2026年9月17日に作成され、10月1日にKev 1.0が公開された。今回検討する理由は、この短い期間の公開動向に加え、質問分離、文書キャッシュ、校正、微調整までをREADMEが具体的に説明していることだ。取得資料には、実際の注目規模を判断できるスター増加や人間の議論の証拠はない。

技術的な説明の具体性と、実装の検証状況は分けて読む必要がある。リンク先のコード、テスト、重み、モデルカードは取得されていない。System One互換性や性能値も作者の説明に基づく。新しい判断サービスの設計として読むことはできるが、公開された説明だけで再現性や本番適性まで確認できたわけではない。

入口はPOST /v1/systemoneで、stateとquestionsを受け取る。READMEによれば、objectやarrayはラベル付きテキストへ変換し、区切りトークンに似た入力をescapeする。不正なrequestや、既定で65,536トークンを超えるstateは422で拒否する。文書を黙って切り捨てる仕様ではない。

出力型は三つある。noulはyesの確率、choiceは最大確率の候補と分布、scoreは順序付きレベルの位置の期待値と分布を返す。choiceとscoreには1〜255候補を指定できる。部署の選択と緊急度の評価は、同じ文書から得る判断でも出力の意味が異なる。ユーザーが付けた質問IDはモデルへ渡されないため、意味を定めるのは質問の指示と基準である。

サーバーはstateを一度計算し、そのキャッシュを各質問行で再利用する。各行はstateと単一の質問からなり、質問のposition IDはstateの直後から始める。現行モデルでは行そのものを独立させることで、他の質問を読めないようにする。同じ文書への再リクエストでも文書キャッシュを利用できると説明されている。

この共有経路はサーバーとDecisionModel.probs()にある。一方、評価用forward()はstateを質問ごとに計算する。評価経路と提供経路を同じものとして扱うと、再計算の有無を取り違える。

質問群はトークン予算に応じて分割し、バッチ処理する。任意数の質問を必ず一度の順伝播で処理する保証ではない。また、質問間の分離は、同一質問内の候補順序への不変性を保証しない。候補を並べ替えると回答が変わる場合がある。

判断の中心はpointer headだ。READMEによれば、各候補の末尾に置かれた</opt>のhidden stateと、質問の最後に置かれた<decide>のhidden stateを照合して候補スコアを求める。<decide>は、その質問の全候補を参照できる。候補スコアからsoftmaxで分布を得るため、APIの回答は候補上の選択や評価になる。

質問分離とpointer headは役割が異なる。独立行は別の質問を読ませないための実行構成であり、pointer headはひとつの質問内で候補を評価する仕組みだ。文書キャッシュは、その前提となる共通文書の計算を共有する。三つを合わせることで、共有文書に対する複数の判断を、回答文の生成とは異なる経路で返す。

usage.output_tokensも生成文の長さと混同できない。READMEでは、回答JSONを直列化したトークン数と説明されている。

各チェックポイントは単一の温度を保存し、ロード時にheadへ適用する。候補スコアの温度を調整してからsoftmaxを計算することで、分布の鋭さを変える。最大確率の候補は変わらず、confidenceの順位を改善する処理でもない。

作者は、学習に使っていない保留データで温度をfitしたKev-9Bについて、new sources集合で温度2.19を使い、校正誤差が0.103から0.041へ、誤答に0.9以上の確率を付けた割合が8.2%から2.4%へ下がったと報告している。同じモデルの調整前後の結果であり、accuracyが上がったという意味ではない。

confidenceにも注意が要る。choiceでは一様分布からの最大確率の隔たり、scoreでは最頻レベルからの分布の広がりを基に計算する。いずれも実測正答率ではない。公開温度が未知の業務や日本語にも妥当かは、取得資料から確認できない。

0.8B・4B・9BはQwen3.5のBaseモデルを使い、凍結したバックボーン上でrank-16 LoRAとpointer headを学習する。27Bは事後学習済みQwen3.8-27Bを基盤に、バックボーン全重みとheadを学習する。小型モデルのadapter方式を、27Bにもそのまま当てはめることはできない。

学習入力はAPI形式に正解labelを加えたJSONLで、クロスエントロピーを使う。公開モデルからの微調整には--init_fromでadapterとheadを引き継ぐ手順があり、基盤、revision、LoRA rank、head sizeの一致を確認すると説明される。その後、保留データで温度を調整し、accuracy、Brier、校正、候補順序、質問分離などを評価する。

独自カテゴリや規則、別言語については、この微調整と自分のラベルでの温度fitが推奨される。APIの出力形式を維持しながら判断を業務へ適応させる工程だが、学習後も個別能力が保たれるとは限らない。

適した配置は、チケットの部署振り分け、緊急度、感情評価、文書中の規則判定を繰り返すアプリケーションだ。同じ文書へ異なる質問を何度も行うならキャッシュを活用でき、独自ラベルを用意できるなら判断基準の適応と閾値検証を組み込める。自由文の回答生成を主目的とする処理には向かない。

作者のKev-4B微調整例では、3質問を持つサポート業務に生成した1,050レコードを使い、H100で15分学習した。accuracyは67.7%から73.6%、許容誤り率5%で自動化できる判断の割合は34%から48%へ増えたという。ただし、これは当該業務例の分布内での改善であり、別分野の性能保証ではない。400レコードでの改善はノイズ内だったとも記される。

検証用ラベルを用意せず、公開モデルの確率だけで判断を自動化する運用は、この設計の前提を満たさない。

JevはTypeSafeのホスト型APIで提供される。Kevは同じSystem One形式を自前サーバーで提供し、公開チェックポイントから独自ラベルで微調整できると説明する。READMEはTypeSafe Python SDKのbase_urlをKevへ変更する利用方法を示す。既存クライアントを生かせる可能性はあるが、互換範囲は独立検証されていない。

作者のfp32評価では、未学習のデータセット・規則を使うnew sourcesの開発／テストaccuracyはKev-27Bで0.851／0.889、Kev-4Bで0.817／0.838だった。Jevは開発値0.857のみで、テスト値はなく、学習データも不明である。これをアーキテクチャだけの優劣として読むことはできない。

知識判断にも差が残る。作者のMMLU-Pro報告はKev-27Bが0.675、Jevが0.840だった。日付の減算も不安定で、微調整により能力が悪化する例がある。自前運用できることと、必要な判断能力を満たすことは別々に確認する必要がある。

作者のH100・Kev-4B測定では、短文への6質問のモデル処理時間は20回の中央値で新規文書18.1 ms、再利用12.9 msだった。ネットワークは含まず、同一地域のModal endpoint往復には別途約65 msかかると報告される。モデル時間だけからアプリケーションの応答時間は判断できない。

32 GBのApple M5・MLX・Kev-4Bでは、約270トークンの文書への5質問が新規721 ms、再利用136 msという報告がある。H100とは質問数や入力条件が異なるため、直接の速度比は出せない。Macで65,000トークンを初めて処理した測定では、0.8Bで21.2秒、4Bで84.5秒かかった。キャッシュ済み文書の速さは、初回処理の待ち時間を消さない。

受け付ける長さと精度を検証した長さも異なる。作者のCUAD評価で、8k時点からの精度低下が3ポイント以内であることを95%下限で確認できた最長文書長は、小型3モデルが8,192、27Bが65,536トークンだった。小型では32kの精度が8kより低く、27Bも長文の確率は短文より信頼性が低いと説明される。

ローカル推論はCUDA/ROCm、またはApple SiliconのMLXを使う。READMEの手順はPython 3.12/3.13とuvを要求する。27Bは51 GBのbf16重みを配布し、servingには約66 GBの常駐GPUメモリと80 GB GPUが必要とされる。現行全重み版の大容量Macでの動作は未測定だ。

公開評価はfp32経路、既定servingはbf16で、確率や最大確率の候補が完全には一致しない。27Bはbf16のみで提供すると説明される。閾値を決める際には、公開表だけでなく実際の提供経路を確認する必要がある。

サーバーは既定で127.0.0.1にbindし、認証は無効だ。外部公開ではKEV_API_KEYによるbearer認証やproxy構成を確認する。Modalのscale-to-zero構成は、アイドル後の初回に約35秒の起動待ちがある。さらに、リポジトリのApache-2.0表記は学習データ全体の利用条件を保証しない。データセットには個別ライセンスがあり、27B基盤の事後学習データは作者にも不明である。