Perplexityは、同じ状況に関する複数の質問を一度に判断するモデルを公開した。顧客からの問い合わせ分類のように複数の属性を判断するサービスの開発者は、呼び出し回数を減らせるが、質問のまとめ方は回答にも影響する。

1. 質問ごとに個別実行しない

この判断モデルは、文章を生成する代わりに、与えられた選択肢に対する判断を返す。

前のバージョンは質問ごとにモデルを実行していた。新バージョンは状況説明の後に質問を並べ、質問ごとのマーカー位置から回答を読み取る。各質問が同じ状況説明を共有し、互いの内容も参照する方式だ。

学習データには、テストセットとの重複を除いた一部ベンチマークの公式学習分割と、ほかの意思決定データを追加した。

2. スコア上昇と学習範囲を併せて見る必要がある

公開されているDecision Index 0.3の自己評価の総合スコアは、旧モデルの62.30から、質問をまとめた新モデルの68.09に上がった。新モデルに質問を個別に送ると67.75だ。総合スコアには、カテゴリ別の単純平均ではなく評価群の重みを使う。

最大1.6 MPの画像を使う公開のVision Decision Index 0.3は、旧モデルの73.22から新モデルの77.43に上がった。

一部の評価課題は、今回から学習範囲に含まれる。学習から除外した意思決定課題でも改善したとの説明はあるが、詳細なスコアは示されていない。

質問をまとめた形式で、別のデータを使って調整した確率校正係数は1.382だ。開発セットの1,497問で正解率は91.3%であり、予測確率と実際の正解率のずれを示すECEは、校正前の0.033から0.014になった。学習から除外した意思決定データでは、やや過信する傾向が残り、ECEは約0.05だった。

3. 関連する属性はまとめ、独立した候補は分ける

同じ項目の複数の属性を判断するときは、まとめる方が有利だ。同じ評価の課題スコアでは、個別リクエストに対し、まとめたリクエストは複数正解を選ぶ課題のSATA-Benchで+11.3点、候補ツールごとに質問するToolRetで−4.8点だった。独立した候補同士は、互いの判断を妨げる可能性がある。

文書の再ランキング評価群であるBEIRでは、上位10件の順位品質を示す指標のnDCG@10を使った。

リクエストごとに候補文書を8件入れる方式は、1件ずつ入れる方式に比べ、複数の根拠を結び付ける必要があるHotpotQAでは+2.1点だったが、全13データセットの平均では−0.5点だった。候補同士の比較自体が役立つかどうかを、まず見極める必要がある。

4. 高速実行も基準の結果と完全には一致しない

1つのリクエスト内で質問をまとめることと、別々のリクエストを一括処理することは異なる。高速経路は、別々のリクエストをまとめて処理する場合も、リクエスト間の独立性を維持する。

GB200を1台使い、16ビットの数値形式であるBF16で測定した。平均1,050トークン（モデルが入力を数える小さな単位）の判断評価リクエストの処理量は、長さ順にまとめて空きを埋める基準方式の毎秒9.1件から、標準の高速経路の19.8件に増えた。個別リクエストの遅延中央値は131ミリ秒から96ミリ秒に減った。基準方式も既に長さ順にリクエストをまとめるため、単にまとめるだけでは利点はほぼなく、高速化は演算のコンパイルとCUDAグラフによる実行の再利用によるものだ。

利点は処理量と遅延の改善だが、数値的な差は残る。同じ評価群のリクエスト300件、質問2,324問で、高速経路と基準経路の最上位の選択の一致率は99.8%、確率差の絶対値の平均は0.002だった。基準経路自体も、一括処理と個別処理の間で選択の一致率が99.8%、確率差の絶対値の平均が0.0017だった。高速経路の差は、基準経路自体の処理方式による変動と同程度だ。

5. 実行環境と入力上限を確認する

pplx-decider-v1.2は前のバージョンと同じQwen3.8-27Bを基盤とし、テキストと最大1.6 MPの画像を受け付ける。

直接実行するには、Python 3.12以上とCUDA GPUが必要だ。

メモリは、BF16の重み約52 GiBに加えて作業領域が必要になる。

READMEはリポジトリが非公開だとして、アクセス権のあるHugging Faceトークンによる認証を案内しているが、モデルページのメタデータはprivate:false、gated:falseと表示している。原文間で案内が食い違うため、実際のアクセス制限の有無は断定できない。ダウンロード後に基本の依存関係をインストールし、高速経路を使う場合は専用の依存関係も追加する。

以下は原文の標準の高速経路の例だ。モデルのパスとリクエスト一覧を用意してから実行する。

from pplx_decider import Decider

decider = Decider.from_pretrained(checkpoint, fast=True)
decider.warmup()
responses = decider.decide(requests)

標準の長さ上限は262,144トークンだが、学習は約32kトークンまでだ。これを超える長さは、自前の課題で検証する必要がある。設定上限を超えると、入力を切り捨てずに質問を分割し、各部分に状況と画像を再び入れる。質問が1つも収まらない場合は、実行前にエラーを出す。

サービスの実行環境には、質問間の双方向参照と、質問ごとの回答の読み取りを支える実装が必要だ。

Ollamaのv0.40.7-rc0プレリリースには、このモデルへの対応追加が含まれている。

[変更リクエスト作成者の記録](https://github.com/ollama/ollama/pull/19072)によると、その記録時点では実行ライブラリのMLX向けモデルはアップロード済みだったが、配布情報をまとめた一覧はまだ作成されていなかった。対応コードと配布の準備状況は区別する必要がある。

このモデルの導入判断は、できるだけ多くまとめることよりも、互いを参照する質問と、独立して評価する候補を分けることから始めるべきだ。