ブログ

小型の意思決定モデル「Kev」：Qwenベースのアーキテクチャと実務での活用

2026年9月26日 H.Ueda

GitHubで見かけた Kev というプロジェクトが、実務での自動判断タスクに使いやすそうだったので、その特徴と仕組みを整理してみました。

もう一つのJevという感じでしょうか。

生成AIの活用が進む中で、複雑な長文を生成するよりも「この文章は規約に違反しているか」「この問い合わせの優先度はどの程度か」といった、特定の意思決定（Decision Making）を高速かつ低コストで行いたい場面が増えています。Kevは、そうした「判断」に特化した小型モデルのファミリーです。

Kevの概要

Kevは、Qwen 2.5をベースモデルとして採用し、Jevというモデルのアーキテクチャ思想を継承した意思決定モデルです。最大の特徴は、一つの入力テキストに対して複数の異なる種類の判断（はい/いいえ、多肢選択、スコアリング）を同時に、かつ互いに干渉させることなく実行できる点にあります。

一般的にLLMに複数の指示を一度に与えると、回答が混ざったり、前の回答の内容に引きずられたりすることがありますが、Kevはこの辺りを構造的に解決しようとしています。

主な特徴

  • モデルサイズ: 0.8B、4B、9Bの3種類が展開されています。
  • マルチタスク判断: 同一のリクエスト内で「はい/いいえ」「選択肢」「数値評価」を同時に行えます。
  • ローカル実行: Apple Silicon（Mac）やCUDA、ROCm環境で動作し、4B/9Bモデルでも32GBのメモリがあればbf16形式で動かすことができます。
  • 互換性: TypeSafe社のSystem One APIと互換性があり、既存のPython SDKを利用して接続先をローカルに向けるだけで導入できる手軽さがあります。

アーキテクチャの仕組み

Kevがどのように入力を処理し、意思決定を行っているのかを整理したのが以下の図です。

flowchart TD
  In["入力テキスト (Input Text)"] --> Shared["Qwenベースの共有エンコーディング"]
  Shared --> TaskA["タスクA: はい/いいえ (noul)"]
  Shared --> TaskB["タスクB: 多肢選択 (choice)"]
  Shared --> TaskC["タスクC: レーティング (score)"]

  subgraph Decision_Heads["独立した意思決定プロセス"]
    TaskA
    TaskB
    TaskC
  end

  TaskA --> OutA["判定結果"]
  TaskB --> OutB["選択された選択肢"]
  TaskC --> OutC["0.0〜1.0 のスコア"]

この図のように、入力されたテキストは共通の基盤で処理されますが、それぞれの質問（タスク）は独立して処理されるイメージです。たとえば、ある文書に対して「機密情報が含まれるか？」という「はい/いいえ」の質問と、「文書のトーンは？」という「多肢選択」の質問を同時に投げても、一方の回答がもう一方の判断を歪めることがないように設計されています。

判断タスクの種類

Kevでは、主に以下の3つの形式でアウトプットを得ることができます。これらを組み合わせることで、複雑なワークフローの自動化が期待できます。

形式名 内容 出力のイメージ
noul はい/いいえ（Yes/No）の2値判定 true または false
choice 提示された選択肢の中から最適なものを選ぶ Option B など
score 0.0から1.0までの範囲での数値評価 0.85

たとえば、カスタマーサポートのメールを処理する場合、以下のような使い方が考えられます。

  1. noul: 「これは解約に関する問い合わせですか？」
  2. choice: 「感情分析の結果は？（ポジティブ / 中立 / ネガティブ）」
  3. score: 「対応の優先度を0から1で評価してください」

これらを一度の推論で取得できるため、効率的なパイプラインが構築できるかと思います。

実装と動作環境

Kevはオープンソース（Apache 2.0ライセンス）として公開されており、独自のデータで追加トレーニングを行うためのコードも付属しています。

対応ハードウェア

ローカル環境での動作に最適化されており、特にMacユーザーにとってはbf16を利用することで、ミドルクラスのモデル（4Bや9B）を比較的容易に動かせるのが嬉しいポイントです。

  • NVIDIA GPU: CUDAによる高速化
  • AMD GPU: ROCmのサポート
  • Apple Silicon: 32GB以上のメモリを推奨（4B/9Bモデルの場合）

APIの利用例

APIはTypeSafeのPython SDKなどと互換性があるため、以下のようなシンプルな形式で呼び出すことが想定されています（※概念的な例です）。

# System One 互換のクライアント設定
from typesafe import SystemOne

client = SystemOne(base_url="http://localhost:8000")

response = client.decide(
    input="ここに解析したい長文テキストを入力します...",
    decisions={
        "is_urgent": "noul",      # 緊急性の判定
        "category": ["sales", "support", "billing"], # カテゴリ選択
        "confidence": "score"     # 信頼度スコア
    }
)

print(response.is_urgent) # True/False

このように、構造化されたデータとして直接結果を受け取れるため、後続の処理（if文による分岐など）にそのまま流し込めるのが実務上では非常に助かる点かと思います。

まとめ

Kevは、巨大な汎用モデルを動かすほどではないけれど、単純なキーワードマッチングでは対応できないような「ちょっとした判断」を大量にこなすのに適したモデルと言えそうです。

Qwen 2.5という実績のあるモデルをベースにしつつ、判断の独立性を保つアーキテクチャを採用している点は、実務での信頼性を高める工夫だと感じました。自前でトレーニングも可能なので、特定のドメインに特化した「社内専用の判断モデル」を作ってみるのも面白いかもしれません。

まずは手元のMacやGPUサーバーで、0.8Bあたりの軽量なモデルから試してみるのが良さそうです。

参照記事

« 記事一覧へ戻る