ファインチューニング不要でLLMを分類専用モデルに変える——「ロジット直読み」で1トークン判定、29データセット検証の結果は

9月26日、プライバシー特化型AIインフラを提供するprivatemode.aiが「Turn GLM-5.3-Flash into a Jev-like System One model」と題した記事を公開した。チケットの振り分け・感情分析・契約条項の分類といった判断タスクにLLMを使う際、推論コストと速度をどう抑えるかは実プロダクト開発における共通の悩みだ。この記事では、汎用LLMであるGLM-5.3-Flashをファインチューニングなしで専用決定モデルと同等の精度・速度で動作させる手法と、29データセットにわたるベンチマーク結果が詳しく紹介されている。

近年、分類・ルーティング専用に設計された「System Oneモデル」と呼ばれるカテゴリが注目を集めている。TypeSafe社のJevやConvai社のLayaがその代表例で、状態と選択肢を渡すだけで選択結果と各選択肢の確率（信頼度スコア）が即座に返ってくる。従来のLLM活用では、JSONオブジェクト全体を生成させるか、推論モデルが数百トークン思考してから答えを出すかのいずれかで、大量処理が必要な場面では現実的でなかった。privatemode.aiが示したのは、既存の汎用LLMをモデル改変なしでこの動作モードに変換できるという発想の転換だ。手法の核心は「ロジット直読み」——LLMが次のトークンを予測する際に内部で計算する確率分布を、テキスト生成の代わりに直接取得するというシンプルなアイデアにある。

核心：1トークンで決定を下す仕組み

LLMは次のトークンを予測する際、語彙全体に対する確率分布（ロジット）を出力する。通常のテキスト生成では最も確率の高いトークンを選んで繰り返すが、選択肢の形が事前にわかっているなら、その部分の確率を直接読めばいい——これが実装の核心的な洞察だ。

具体的な手順は3ステップで完結する。

選択肢に番号を付ける。 状態・質問・選択肢をJSONでプロンプトに含め、各選択肢にインデックスを付与する。モデルへの指示は「choice_index: に続けてインデックスを答えよ」とする。
アシスタントの返答を途中まで埋め込む（プリフィル）。 プロンプトを choice_index: で終わらせることで、モデルが最初に出力するトークンがそのままインデックスになる。
ロジットを直接読む。 トークンを1つだけ生成させ、その1ポジションで各選択肢インデックスに割り当てられた確率を取得して正規化する。

以下のプロンプト構造がその実装例だ。user ターンに状態・質問・選択肢をJSON形式で渡し、assistant ターンを choice_index: で終わらせることで、モデルの次トークン予測がそのまま選択結果になる。

user
{"state": "I was charged twice for my order.", "question": "Which team?", "options": [
  {"index":0, "name": "payments"},
  {"index":1, "name": "complaints"},
  {"index":2, "name": "technical"}
]}
assistant
choice_index:

この構成で max_tokens: 1 を指定し、vLLMの logprob_token_ids で各インデックストークンの確率を取得する。結果は payments: 62.1%、complaints: 37.7%、technical: 0.2% のような確率分布として得られる。生成コストはほぼゼロに近く、分類結果と同時に確率分布も副産物として手に入る。

なお、GLM-5.3-Flashは中国のAI企業・智谱AIが開発した軽量マルチモーダルモデルで、テキストと画像の両方を処理できるビジョン対応LLMだ。この特性が後述の差別化点にもなっている。

実装上の細かいポイント

GLM-5.3-FlashとvLLMの組み合わせで動かす際、いくつか重要な注意点がある。

top_logprobs では不十分。 これは語彙制限適用前の分布を返すため、スペースなどのフォーマットトークンが上位を占め、一部の選択肢が確率ゼロと見なされてしまう。vLLMの logprob_token_ids を使うと、指定したトークンIDの確率のみを正確に取得できる。
トークナイザーの扱い。 数字が必ずしも1トークンとは限らない（例：GLM-5.3-Flashは 12 を1トークンとして持つ）。トークンIDをモデルごとにハードコードせず、/completions エンドポイントに echo オプションで送ることで、実際にサービング中のモデルのトークン化を動的に取得している。
画像対応。 continue_final_message と add_generation_prompt: false の組み合わせにより、プリフィルしたアシスタントターンを継続しながら画像を同一プロンプトに含められる。GLM-5.3-Flashはビジョンモデルであるため、この対応が可能だ。

実装は以下のリポジトリで公開されている：

edgelesssys/privatemode-decisions（GitHub）

29データセットにわたるベンチマーク結果

実装の有効性を検証するため、GLM-5.3-Flash（Privatemode上）、Jev、Laya（421Mパラメータ、ローカル実行）の3システムを、インテントルーティング・感情分析・トピック分類・モデレーション・法律文書・スキャン文書など多岐にわたる29の公開ラベル付きデータセットで比較した。英語・ドイツ語が含まれる。

精度：GLM-5.3-FlashとJevは統計的に同等

28のテキストデータセットで比較した結果、GLM-5.3-FlashとJevは実質同等だった。各システムがそれぞれ10データセットで高精度を示し、残り8は両者の差が1ポイント以内。中央値の差はJev有利の0.7ポイントで、統計的有意差はない（p = 0.64）。一方、Layaは多くのデータセットで中央値13〜15ポイント差で劣る（p < 0.001）。

精度に関しては、JevかGLM-5.3-Flashかという選択よりも、選択肢の数のほうが影響が大きいという指摘は実践的に重要だ。TRECデータセットでは、6分類から42分類に増やすとJevが92.1%→85.6%、GLM-5.3-Flashが91.2%→79.6%に低下した。

レイテンシ：ホスティング地域が支配的な要因

PrivatemodeはEU（ドイツ）、JevはUSでホストされているため、両地点から計測した。

計測地点	GLM-5.3-Flash (Privatemode)	Jev
ドイツから	180ms	264ms
USから	299ms	164ms

レイテンシはホスティング地域の近さが支配的な要因であり、アーキテクチャの優劣よりも「どこで動かすか」が実運用では重要になる。

コスト：選択肢数で逆転する損益分岐点

コストはJevが有利で、100万件あたりGLM-5.3-Flashが約62ユーロ、Jevが約16ユーロ。差の主因は入力トークン単価とプロンプトのパッケージング効率だ。Jevは固定オーバーヘッドが約270トークンで選択肢あたり約10トークン。GLM-5.3-Flashは固定約55トークンで選択肢あたり約20トークン。選択肢数が約21以下の場合はGLM-5.3-Flashのほうがトークン数が少なく、選択肢が少ないユースケースではコスト差が縮まる。

画像対応という差別化点

GLM-5.3-Flashがビジョンモデルである点は、テキスト専用のJev・Layaとの明確な差別化になる。スキャン文書の分類タスクであるRVL-CDIP（16クラスのビジネス文書1,600件）では70.2%の精度を達成した。ただし画像は約1,350トークンを追加するためコストは増加する。

ベンチマークの再現に必要なコード・データセット仕様は以下で公開されている：

edgelesssys/privatemode-decisions-benchmark（GitHub）

詳細はTurn GLM-5.3-Flash into a Jev-like System One modelを参照していただきたい。