生成せずに「選ぶ」AI:Decision Model 100超の系譜・性能・コストを分析

著者: Lucy.·2026年10月10日 (土)
生成せずに「選ぶ」AI:Decision Model 100超の系譜・性能・コストを分析

顧客の問い合わせをどのチームに回すか、文書が審査基準を満たしているか、今の作業を続けるか人に引き継ぐか。こうした業務でまず必要なのは、長い説明よりも決められた選択肢のうちどれを選ぶか、そしてその判断をどれだけ信頼できるかです。

この領域を狙うAIが、Decision Model、判断型AIです。Jevをはじめ、AWS・Microsoft・Perplexity・Cloudflare・Liquid AIまで、各社が異なる方式のモデルを発表しています。公開資料でベースを確認できる105の実装を調べると、新しい名前でも出発点を共有するモデルが多く、大きなモデルの高い判断スコアが、そのまま低コストの運用につながるわけでもありません。

以前の記事日本語の判断テストでJevが79.4点:GPT-6.1 Solとの差、速度と費用をAIBが実測では、Jevが回答のチェックなど一部の課題で汎用AIに近い結果を出しながら、処理時間と記録されたコストを抑えた事例を紹介しました。判断型AIの強みは、あらかじめ決めた選択肢の範囲で答えるためコードの条件分岐につなげやすく、長い回答の生成を減らすことで遅延・コストを抑えられる可能性があることです。選択肢ごとの確率は、実際の正答率との差を検証したうえで、人に引き継ぐ基準に使えます。どのモデル・業務でこの利点が生きるかは、実際に比較する必要があります。

この記事では、モデルの系譜と仕組み、性能表の読み方を整理し、日々の業務でどう比較・検証するかを考えます。AIBによる日本語・韓国語の評価と、韓国語データを使う学習実験の提案も、具体的な検証例として紹介します。最初からモデルを学習させる必要はありません。繰り返し発生する業務を一つ選び、実際の入力と選択肢・判定基準を書き出すことが、最も始めやすい一歩です。

判断型AIの入力と三つの出力

判断型AIには通常、状況(state)、質問、回答として許す範囲を入力します。顧客の「連携エラーが続いています」という問い合わせを状況に、「どのチームが対応するか?」を質問に、「決済・技術サポート・営業」を選択肢にする、といった形です。出力は、決められた型の結果と確率です。

TypeSafeが文書化している代表的な三つの形式を見ると、それぞれの役割が分かります。

  • Choice — 問うこと:複数の候補から何を選ぶか? 返す結果:選択肢ごとの確率と選択結果。業務例:顧客の問い合わせを担当チームに振り分ける
  • Noul — 問うこと:この条件は成り立つか? 返す結果:はいとなる確率、0~1。業務例:文書に必須項目があるか確認する
  • Score — 問うこと:どの水準に該当するか? 返す結果:順序のある評価段階の確率と期待スコア。業務例:回答が基準をどの程度満たしているか評価する

形式の名前が同じでも、各社の入力仕様と返されるフィールドを確認する必要があります。特に、Scoreの4点、Choiceの0.8、Noulの「はい」の確率は、それぞれ違う値です。

一般的なLLMでも、A・B・Cといった回答記号のlogits、つまり正規化前のスコアを読み取って、選択肢の確率を作れます。判断型AIの特徴は、この手順を製品の中心に置き、選択・評価の結果がそのままプログラムの次の動作につながるよう設計していることです。長い回答を生成し、その文章を再び解釈する工程が減れば、繰り返しの分類やルーティングで有利になり得ます。

ただし、新しい文章を生成しないという事実は、正しい判断を保証しません。 誤った基準を入力したり、実際の業務とは異なるデータで学習したりしていれば、形式だけは正しい誤答を素早く返すこともあります。


ベース・出力部・学習方法の違い

新しい判断モデルを見るときは、何を出発点にし、結果をどう読み取り、何を学習したのかを分けて考えてください。

ベースモデルは、出発点となる事前学習済みモデルです。チェックポイントは、ある時点の重みファイルです。同じQwen系でも、サイズ・バージョン・学習・実行設定が変われば、結果は変わります。

出力部、つまりreadout headは、内部表現を選択肢のスコアに変える部分です。選択肢の位置にある表現を比較するpointer方式、A・B・Cなどの記号のスコアを読む方式、複数の質問やフィールドをまとめて処理する専用headなどがあります。LoRAは、元の重みに小さな学習可能行列を追加する学習方法であり、出力部の名前ではありません。

AWS Strands Decider 2Bは具体的な例です。Qwen3.5-2Bの本体から言語生成headを外し、約100万パラメーターのpointer headとrank 16のLoRAを学習させています。開発元のリリース記事は、RTX 3090での遅延時間の中央値を約115msとしています。これはその記事におけるv18の測定であり、公開されたv19チェックポイントや、別のデバイス・入力長での速度を自動的に意味するものではありません。

こうした「小型LLM+新しい出力部+LoRA」は有力な方法ですが、この分野全体に共通する作り方ではありません。ベースをそのままにしてlogitsだけを読む実装もあれば、全体のファインチューニングや、複数の学習結果のマージを使う実装もあります。

Cloudflare Clefは、小型Transformerの出力部でスキーマに含まれる複数の質問をまとめて処理します。Fastino GLiNER2.5-Decideはencoderを使ってスコアを計算し、制約を反映した構造化結果を選びます。Liquidのd1は、モデルごとにファインチューニングとマージの工程を使います。同じ企業のモデルだからといって、一括して「LoRAモデル」と呼ぶと、大切な違いを見落とします。


主要企業の判断モデルとベース

公式リリースとモデルカードで確認した出発点を整理すると、次のようになります。ベースが公開されているかどうかと、完成した製品の提供形態は別の話です。

モデル・製品確認されたベース・構造提供形態と確認すべき点
Microsoft-Decision-1Qwen3.5-9Bを追加学習したモデルFoundry・OpenRouter API。現在のベースと、今後ほかのベースへ拡張する計画を区別する
AWS Strands Decider 2BQwen3.5-2B-Base + pointer head + LoRAv19のコード・重みはApache 2.0。リリース記事の速度測定はv18の条件
Perplexity Decider v1.1 27BQwen3.8-27B + 専用decision readoutv1を改善したチェックポイント。非因果attention・保存済みの補正温度など、専用の推論設定を確認する
Cloudflare Clef / Clef-FlashQwen3.8-27B / Qwen3.5-9Bスキーマに基づく複数質問の出力部。モデルカードはApache 2.0
Liquid d1-3BLFM2.5-VL-3B系decodertext backboneの組み合わせとファインチューニング・マージ。一度の順伝播で選択結果を算出
Liquid d1-omni-600MLFM2.5-Encoder-350M + 視覚・音声encoderテキスト+画像、またはテキスト+音声を入力。実験的なモデル
Fastino GLiNER2.5-DecideDeBERTa-v3-largeの系譜にあるGLiNER2 encoder、340M構造化された判断と制約の処理。全体またはLoRAのファインチューニングが可能
TypeSafe Jevベース・内部構造の詳細は非公開型を持つ判断API。公開された入出力仕様と測定結果で評価する

Microsoftの公式リリースは、現在のモデルがQwen3.5-9Bを出発点としていると説明しています。今後、MAIやOpenAI系などほかのベースを検討するという計画を、現在の構造と混同しないようにしてください。

Perplexity v1.1は専用readoutを使い、一部のattentionの因果マスクを解除します。一般的なcausal推論で実行すると、モデルカードが説明する評価設定を再現できません。公開カードの使用案内には、認証を伴うアクセスや約49GiBの重みメモリーといった条件も記されているため、モデル名だけを見て、すぐに軽い環境で動かせると考えるべきではありません。

FastinoのGLiDEは、さらに別の例外です。不確かな場合に追加の推論を行うAPI製品であり、すべての判断モデルが常に「一度の順伝播・出力トークン0」で終わると一般化できないことを示しています。GLiNER2.5-Decideと同じ会社の製品だからといって、GLiDEの非公開ベースまで同じだと推測することもできません。

この比較で重要なのは企業の規模よりも、私たちの入力を受け取り、必要な結果をどのような条件とコストで返してくれるかです。


105実装の系譜と上位モデル

調査リストの105件は、公開資料からベースを分類したdecoderベースの実装とdiffusionベースの実装です。現在のボードに測定値がある102件と、発表・公開資料から追加した3件を合わせています。AWS Strands Decider 2B、Microsoft-Decision-1、Liquid d1-3Bは、このリストで同じCapability測定値がない項目です。

ベースが公開されていないJevとGLiDE、encoder・reranker、学習を行わないベースの対照群は、この系譜の集計から除いています。したがって、105件すべてが同じ試験を受けたモデルである、あるいは独立に開発された105のベースである、という意味ではありません。

  • Qwen — 調査数:74。割合:約70%。スコア確認数:72。Capability平均:58.9。最高値:82.8。
  • Gemma — 調査数:23。割合:約22%。スコア確認数:23。Capability平均:67.9。最高値:81.7。
  • その他 — 調査数:8。割合:約8%。スコア確認数:7。Capability平均:48.2。最高値:58.4。
  • 合計 — 調査数:105。割合:100%。スコア確認数:102。Capability平均:—。最高値:—。

平均は、測定値がある実装だけで計算しました。「その他」の48.2は、スコアがある7実装の平均です。「その他」に含まれる各ベース系統の平均は43.3~58.4であり、実装全体の平均とは区別されます。上の一覧の最高値は、コスト・遅延の制限を超えるモデルも含めたCapabilityであり、制限内の公式上位順位とは分けて読む必要があります。

Qwen3.5-4Bを出発点とする実装は29件あります。同じサイズのベースで、出力方式・データ・推論コードを変える実験が活発に行われているということです。Plumbやdeck系の実装を引き継いだ場合も、最終的な名前だけを見るのではなく、上流のベースまでさかのぼってQwenの系譜に分類しました。

一方、Benchmark Heavenのv1.6.1・board v1.7.30の公式Composite上位20件のうち、19件はGemmaの系譜で、残る一つはQwen3.5-4BベースのH2O-Lightning-4B v1.1です。ここにはGemmaの系譜にあるDiffusion Jevも含まれ、順位のないJev基準行は数えていません。

この二つの結果は、それぞれ違う問いに答えています。Qwenは、この調査リストで最も多く選ばれた出発点です。Gemmaは、このバージョンの総合スコア上位で大きな割合を占めます。提出・実装の数、判断能力、運用効率の順位は同じではありません。

また、バージョン・サイズ・学習方法・出力部・実行デバイスが混在した系統別の平均だけで、「Gemmaというベース自体が原因だ」と結論づけることはできません。実務で候補を絞る手がかりにし、近い条件の個別モデルを比較するほうが有用です。


27Bのコストは5.1~22.2倍

Qwen3.8-27B系の実装は、このリストに15件あります。直接のベースが派生モデルの場合は上流の系譜を確認し、torchcastの一部の過去のベースバージョンについては、公開ボードの推定表記も考慮しました。Flash-Nextや、2Bに蒸留したモデルまで27Bに含めてはいません。

同じボードの1,000回の判断コスト列を、Jevの固定v1.5基準コストである約0.0323ドルと比べると、この15件は約5.1~22.2倍の範囲です。

例ボードにある1,000回の判断コスト固定Jev基準との比較
JADE約$0.164約5.1倍
Perplexity Decider v1.1 27B約$0.217約6.7倍
Clef約$0.249約7.7倍
Kev 27B約$0.529約16.4倍
Open-Jev 27B v1.1約$0.716約22.2倍

したがって、「27B系はJevより6~7倍高い」という要約は、Perplexityのような一部の事例には当てはまりますが、系統全体を説明してはいません。

この列には、セルフホスティングモデルのトークン使用量と基準価格から計算した推定コストが含まれます。APIサービスの実際の請求価格、自分で借りるGPUの時間単価、バッチ処理による節約額は、別途計算する必要があります。表のコスト比率を、そのまま契約の見積もりのように使ってはいけません。

Perplexity v1.1のCapabilityは82.8で、Intelligence 75.7とCalibration 89.9の平均です。v1とv1.1は異なるチェックポイントであり、モデルカードのDecision Indexスコアも、このJevBenchの値とは異なる評価です。

Capabilityが高くても、コストがJev-classの上限を超えると、そのヘッドライン順位からは除かれます。コストも反映するCompositeの順位も変わります。どのランキングで1位かよりも、私たちの業務の予算と応答時間の範囲で、どのモデルが候補に残るかのほうが大切です。


JevBenchの能力と総合効率

Benchmark HeavenのJevBenchは、Intelligence・Calibration・Speed・Costの四つの軸を評価します。画面上では似て見えるCapabilityとCompositeですが、計算方法も、答える問いも異なります。

指標計算・条件読み方
Intelligence判断課題の性能をボードの方法で算出私たちの業務とどの課題が重なるか確認する
Calibration返された確率と結果の一致度を評価高い確率を伴う誤答がどの程度発生するか確認する
Capability(Intelligence + Calibration) ÷ 2能力と確率の較正を合わせて見た値
Jev-class固定Jev基準のコスト・遅延時間の中央値が、両方とも2倍以下ヘッドラインCapability順位の参加条件
Composite四つの軸の等しい重みの調和平均に、低い軸への減点を適用能力・速度・コストを併せて考慮する総合スコア

現在の基準におけるJev-classの上限は、1,000回の判断コストが約$0.0646、調整後の遅延時間の中央値が約1.23秒です。コストか遅延の上限を超えると、Capabilityが高くてもヘッドライン順位の資格を得られません。

Compositeの「等しい重み」は、四つのスコアを単純に足して4で割るという意味ではありません。調和平均は低い軸の影響を強く受け、Intelligence・Speed・Costが設定された基準を下回ると、追加の減点も適用されます。そのため、大きなモデルが判断を得意としていても、高いコストによって総合スコアが低くなることがあります。

過去の順位も区別する必要があります。BenchLMに残るv1.5.4では、Cygnet 73.70、Winnow 73.23が、統計的に近い上位モデルでした。この記事で見る現在のv1.6.1のComposite 1位は、H2O-Lightning-4B v1.1です。試験の構成・方法と候補は変わり得るため、バージョンの異なる数値の変化を、すべてモデルの改善効果として読むべきではありません。

もう一つのJevBenchである「JevBench: coherence tests for typed decision models」は、型を持つ判断の一貫性を検査する別のプロジェクトです。名前が同じでも、正答率・コスト・速度を総合するBenchmark Heavenのランキングと入れ替えて引用してはいけません。Decision Indexも別の評価であり、そのスコアをCapabilityと同じ尺度として混ぜません。


確率0.8とconfidence 0.8の違い

実務の自動化では、「何を選んだか」の次に「いつ人に引き継ぐか」が必要になります。このとき、サービスが返す確率とconfidenceの定義を先に確認してください。

Choiceで最も高い選択肢の確率が0.8というのは、そのモデルがその選択肢に割り当てた値です。TypeSafeのChoice confidenceは、選択肢の数に応じた一様分布の基準分を取り除いた値です。

confidence = (最高確率 - 1/選択肢数) ÷ (1 - 1/選択肢数)

例えば選択肢が4個あり、最高確率が0.8なら、confidenceは約0.733です。Noulは、別のconfidenceなしで「はい」となる確率を返します。異なるサービスの0.8に、同じ業務のしきい値を当てはめる前に、この違いを確認してください。

較正(calibration)は、似た確率が与えられた複数の事例で、実際の結果がその確率とどの程度合うかを見る性質です。0.8を与えた事例群の正答率が大幅に低ければ、モデルが過度に確信していたことになります。ECEは確率区間ごとの確信度と正答率の差を、Brier scoreは予測確率と実際の結果の差を測ります。

AWS v19カードの公開項目の正答率167/231と、そのカードの較正指標は、その評価条件における独自測定です。この比率をJevBench全体のCapabilityと呼んだり、実際の韓国語の顧客問い合わせにおける成功率に置き換えたりすることはできません。

業務データでしきい値を決める際は、自動処理の正答率と自動処理した割合、人に引き継いだ割合を併せて見てください。ほぼすべてを人に引き継いで得た高い正答率と、大部分を処理しながら得た正答率では、運用上の価値が異なります。選択肢の順序や、同じ入力を繰り返し実行した場合も確認が必要です。出力トークンがないという理由だけで、すべてのモデルの再現性が同じになるわけではありません。


韓国発モデルと韓国語の判断性能

105件のリストに含まれるEXAONE系は一つです。これは韓国で作られたベースが含まれる数であり、韓国語の判断型AIが全体で一つしかないという意味ではありません。Qwen・Gemma系も韓国語を対象に評価できますし、ベースモデルの開発国だけでは韓国語の性能は分かりません。

EXAONE-4.0-1.2B-JEVはLGの公式判断モデルではなく、個人開発者による派生モデルです。v0.3カードには、英語データを使った全体のファインチューニングと、選択肢の順序を二度変えて読み取り、平均する方式が説明されています。英語専用という範囲や、不慣れな領域では過度に確信する可能性があるという限界も明記されています。

ベースのEXAONE-4.0-1.2Bが韓国語に対応していることを、この派生モデルの検証済みの韓国語判断性能へと広げて解釈すべきではありません。また、ベースと派生モデルのカードには非商用ライセンスの条件があるため、事業用の候補にする前に利用条件を確認する必要があります。

AIB DecisionBench-KJの日本語・韓国語評価

日本語・韓国語での検証例として、AIBが運営するAIB DecisionBench-KJは、公開データ8種の韓国語1,250問・日本語750問、計2,000問で判断型AIを比較します。2026年10月10日の公開画面にある0.2バージョンには、判断型モデル12個と、汎用の対照群GPT-6.1 Sol・Claude Sonnet 5.5があります。以前のJev記事にある10月4日の結果から、比較モデルが増えた現在の結果です。

課題は、長い回答を書くことではなく、はい・いいえ、選択肢の選択、段階スコアで答えられる判断に合わせています。元のデータセットの人間によるラベルを正解とし、モデルが各選択肢に割り当てた確率が最も高いものを回答として採点します。

  • KoBEST — 韓国語250問: 文章に基づくはい・いいえ100、原因・結果90、感情分類60
  • KLUE — 韓国語250問: 根拠と文の一致150、文の類似度100
  • JGLUE — 日本語250問: 常識75、根拠との一致100、文の類似度75
  • KMMLU・JMMLU — 韓国語・日本語それぞれ125問: 韓国の資格試験・日本の教科レベルの知識
  • M-RewardBench — 韓国語・日本語それぞれ125問: 二つのAI回答から、よりよいほうを選択
  • PolyGuardPrompts — 韓国語・日本語それぞれ125問: 有害な要求の判別
  • K-MHaS — 韓国語250問: ヘイト表現の判別
  • RTP-LX — 韓国語・日本語それぞれ125問: 有害性の程度を段階で判断

総合正答率は、8データセットの正答率を等しい重みで平均します。韓国語・日本語のスコアも、各言語を含むデータセット同士で等しい重みの平均を取るため、総合スコアは二つの言語のスコアの単純平均ではありません。文の類似度0~5、有害性1~5のような段階スコアは、正解の段階にぴったり一致した場合に正解と数えます。

正答率とともに、さらに二つの指標を見る必要があります。確率の較正(ECE)は「90%の確信」とした回答が実際にそれだけ正しいかを、選択肢の順序による変動は、同じ問題で選択肢の順序を逆にしたときに回答が変わる割合を見ます。どちらも低いほうがよい指標です。順序の比較では最大1,340組を追加で問い、判断型モデルごとに基本の2,000問を含めた3,340リクエストで測定しました。

現在測定されている四つのモデルを、総合正答率 / 確率の較正誤差 / 選択肢の順序による変動の順に読むと、次のようになります。

  • Perplexity Decider v1.1 27B: 81.7点 / 3.4%p / 6.9%
  • Jev 1.13: 78.6点 / 3.7%p / 6.5%
  • Microsoft-Decision-1: 77.5点 / 8.6%p / 5.6%
  • Perplexity Decider v1 27B: 77.2点 / 2.3%p / 14.9%

この結果では、正答率1位と確率の較正1位が異なります。 Perplexity v1.1の総合正答率が最も高い一方、v1のほうが較正誤差は小さくなっています。また、Clef Flashの選択肢の順序による変動は4.0%と低くても、総合正答率は69.4点です。正解・確率・順序の安定性を分けて読む必要がある理由です。

速度とコストも、現在の表で併せて比較できます。Perplexity v1.1は1,000件換算で6分52秒・$0.0046、Jevは3分45秒・$0.022です。対照群のGPT-6.1 Solは、正答率83.9点、34分25秒・$0.826です。この測定では、Perplexity v1.1は正答率に2.2点の差がある一方、換算時間は約5倍短く、記録されたコストは約180分の1でした。この倍率は、そのバージョン・設問・呼び出し条件での比較結果です。

測定記録は10月3~10日にわたり、応答バージョンと呼び出し経路も公開しています。例えば、JevはOpenRouterのtypesafe/jev-1.13-20260917、Perplexity v1.1はPerplexityのpplx-decider-v1.1-27bで測定しました。応答時間には経由による時間が含まれ、コストは実際の請求記録に基づき、一時的に無料の版は有料コストの比較から除いています。提供元が判定を拒否した場合は誤答として扱います。

設問はシード20261003で層化抽出し、バージョン内で固定しています。セットごとの設問フィンガープリント(SHA-256)と、記録された原本revisionを公開しています。モデルを追加しても設問セットは維持します。AIBの次の研究案として、この評価を出発点に、韓国語の業務・選好・ルーティング課題を拡張する実験が考えられます。

公開評価で候補を絞ったあと、自分たちのチームの表現、業務基準、文書の長さ、例外事例を加えて再確認する必要があります。顧客の「キャンセル」が決済の取消しなのか予約の取消しなのか、「問題ありません」が確認完了なのか不満を遠回しに表したものなのか、といった違いは、全体の平均スコア一つでは分かりません。


AIBの四つの研究・評価案

この系譜調査から、AIBの研究・評価テーマとして四つの案が考えられます。以下は活用・評価の提案であり、すでにサービスへ適用した、あるいは学習を終えたという説明ではありません。

1. 韓国語の回答選好の学習。 同じ質問に対する二つの回答から、ユーザーがどちらを選んだかを活用すれば、選好判断を学習できる可能性を試せます。ただし、選好は客観的な正解や安全性の判定とは異なります。同意・利用条件を確認したデータで、重複投票、質問・モデルの偏り、ノイズを点検したうえで、学習の可能性を検討する必要があります。

2. モデルルーター。 作業の種類・長さ・要求品質と、予算・待ち時間の条件を入力し、どのモデルに送るかを選びます。安いモデルへ先に送り、難しい場合は別のモデルや人に引き継ぐ方針を比較できます。ルーター自体のコストと、誤った振り分けによる再処理のコストも、総コストに含める必要があります。

3. 投票品質のレビュー。 質問と回答の関連性、比較資料の不足、確認が必要なパターンを、NoulやChoiceで示す実験です。例外をレビュー担当者へ送る補助的なシグナルとして、まず評価する必要があります。モデルの一つのスコアだけでユーザーの信頼性や不正参加を断定する機能へと広げるべきではありません。

4. 韓国語判断ベンチマークの拡張。 既存のDecisionBench-KJに、実際の業務分類、選択肢の順序変更、選好・品質判断、モデルルーティングの課題を加える実験です。客観的な正解がある課題と、人によって選好が異なる課題を区別すれば、どのような判断が得意なのかを、より明確に見られます。

出発点は、評価できる小さな問題一つです。例えば、匿名化し、利用範囲を確認した過去の問い合わせから、担当者が確定した分類を集め、モデルが同じ基準でチームに振り分けるかを確認できます。この記事の提案は、非公開の投票を抽出したり、学習に使ったりする承認を意味しません。


AIBの韓国語学習実験:三つのベース

AIBの研究案として、韓国語データで判断モデルを学習させる実験では、Qwen3.5-4B、Gemma-4-12B、EXAONE-4.0-1.2Bを候補に比較できます。目的は、韓国語のデータに学習可能な判断シグナルがあるかを確認することです。

三つのモデルはサイズが異なります。そのため、この実験は同じサイズのベース同士の純粋な優劣を競う試験というより、異なる導入候補の品質・必要リソースを比較する実験と解釈する必要があります。EXAONEの利用条件のように、実際の採用を制限する要素も、結果とともに記録します。

比較項目揃える、または記録する条件確認したい問い
課題・データ同じ韓国語入力、選択肢、判定基準同じ業務で判断は変わるか?
データの分割学習・較正・検証・最終テストを分離見慣れた質問を暗記した結果ではないか?
出力部可能な範囲で共通の原理を用い、モデルごとの構造の違いを記録headの違いが結果に影響するか?
学習予算データ量・学習回数・seed・学習するパラメーター数同じ名前のLoRAでも、実際に同じ実験か?
実行チェックポイント・精度・デバイス・バッチ・入力長品質を得るためにどのリソースが必要か?
評価正答率・選好の一致度・ECE・Brier・遅延・コスト実際の自動処理方針に使えるか?

同じ原文や同じ質問の変形が、学習とテストの両方に入らないよう、まとめて分割します。選択肢の順序を変えた評価や、エラー・回答を控えた事例も記録します。モデルごとの構造が異なれば、同じLoRA rankに揃えても、学習するパラメーター数が変わることがあります。

headとLoRAを追加した結果は、元のモデルのlogitsをそのまま読んだ結果と比較する必要があります。そうして初めて、複雑な学習手順が実際に役立ったかを判断できます。代表的な業務で有効なシグナルを確認してから、データとモデルの規模を広げる順序が現実的です。


実務でのモデル選定と自動処理方針

今、導入を検討するなら、105件をすべて試す必要はありません。入力言語・長さ・画像や音声が必要か、利用条件、運用方法で先に絞り、条件の近い候補を二、三個比較してください。

  1. 判定基準を書きます。 入力データ、選択肢、正解、または人がレビューする条件を決めます。選択肢に「判断できない」や人へのレビュー経路が必要かも確認します。
  2. 代表事例と難しい例外を集めます。 実際の担当者の基準を付け、業務に応じて、誤りによる損失が大きい事例を別に見ます。
  3. 出力とコストを同じ単位で記録します。 正答率だけでなく、選択肢の確率、失敗・回答を控えた事例、入力長、1,000件のコストと応答時間を比較します。
  4. しきい値と人によるレビュー方針を一緒に決めます。 自動処理する割合が同じとき、どの候補がより正確か、誤りと再処理にかかるコストはどちらが小さいかを確認します。
  5. 運用中も新しいパターンを点検します。 問い合わせの内容・文書の形式・選択肢が変わったら、以前の確率の較正としきい値が保たれるかを再確認します。

私たちの業務に必要なのは、最も高い公開順位でしょうか。それとも、決められた予算と時間の範囲で信頼できる次の動作でしょうか?

判断型AIは、業務の選択段階を切り分けて評価できるようにします。ベースの系譜を見れば候補を絞れ、確率とコストの定義を理解すれば比較しやすくなります。最後の選択は、実際の業務データと処理方針で確認する必要があります。


出典・参考資料

判断APIと確率の定義:Introduction - TypeSafe AI · Confidence - TypeSafe AI · Introducing System One Models & Jev - TypeSafe AI Blog

企業のリリースと実装:Microsoft-Decision-1: Our model for fast decision-making · Introducing Strands Decider 2B: a small, open source, decision model | Strands Agents · Open d1: Edge decision models for text, vision, and audio | Blog | Liquid AI

公開モデルカード:StrandsAgents/strands-decider-2B-hobson-v19 · Hugging Face · perplexity-ai/pplx-decider-v1.1-27b · Hugging Face · Cloudflare/clef · Hugging Face · Cloudflare/clef-flash · Hugging Face

Encoderと推論方式:GLiNER2.5-Decide: An Open-Weight Model for Structured Decision Making · fastino/GLiNER2.5-Decide · Hugging Face · Introducing GLiDE: The First Thinking Decision Model

EXAONEと比較候補:LGAI-EXAONE/EXAONE-4.0-1.2B · Hugging Face · carrtesy/EXAONE-4.0-1.2B-JEV · Hugging Face · Qwen/Qwen3.5-4B-Base · Hugging Face · google/gemma-4-12B-it · Hugging Face

評価とデータ:JevBench — AI decision model benchmark & leaderboard | Benchmark Heaven · JevBench dataset card & decision model results | Benchmark Heaven · Best AI Decision Models: Rankings, Cost & Use Cases | BenchLM.ai · JevBench: coherence tests for typed decision models

AIBの韓国語・日本語評価と以前の記事:AIB DecisionBench-KJ:日本語・韓国語の判断型(Decision)AIベンチマーク | AIB · 日本語の判断テストでJevが79.4点:GPT-6.1 Solとの差、速度と費用をAIBが実測


業務と予算に合うAIの選択

AIBは、特定のAI企業に偏らずモデルを比較できるよう支援する、独立したAI比較プラットフォームを運営する新しいスタートアップです。業務に必要な品質とコストを併せて見て、情報や予算の差がAI活用の格差につながらないよう支援したいと考えています。

繰り返しの業務をどこまで自動化するか、どのAIにつなぐか、コストと待ち時間をどう比較するか。お悩みがあれば、ぜひご相談ください。

AIの導入・コスト・活用についてAIBに相談する