第1回 Jevの登場から考える、判定専用モデルをRAGに組み込む意味
連載：Decision-1をRAGに組み込む：設計・検証・運用の実践・第1回 ｜ 連載のまとめ
判定専用モデルのJevの登場で関心を持ったのは、AIに文章を書かせることよりも、アプリケーションの途中にある小さな判断を任せるという使い方でした。「この文書は質問に関係するか」「この根拠で回答してよいか」といった判定を、速く、低い費用で呼び出せるなら、検索と回答生成の役割分担も変えられそうです。
ただし、判定が安くても、追加した処理が回答品質を改善しなければ導入する理由は弱くなります。そこで、検索拡張生成（Retrieval-Augmented Generation、以下RAG）の検索後にMicrosoft-Decision-1（以下、Decision-1）を組み込み、品質、待ち時間、費用を比較しました。検証は2026年10月16日から20日に行っています。
1. Jevが提示した、ソフトウェアから使うAI
TypeSafe AIは2026年9月15日、Jevを早期アクセスとして発表しました。発表で掲げられたのは、入力された状態に対して、ソフトウェアが扱える型付きの判定と確率を返すモデルです。自由な文章の生成に比べ、判断の候補と出力の形を先に決める使い方が中心です。[1]
たとえば、問い合わせを「請求」「障害」「契約」のどこへ送るか、取得した文書を回答の根拠に含めるか、といった処理が考えられます。判定の結果を受け取ったコードが、その後の処理を選びます。
TypeSafe AIは速度と費用の利点も示していますが、その比較は同社が公開したデモやワークフローの条件に基づきます。RAG全体でも同じ倍率で速く、安くなると読み替えることはできません。また、出力の型が制約されることと、判定内容が正しいことは別です。選択肢の中から誤ったものを選ぶ可能性は、利用する業務データで確かめる必要があります。
ここから今回の問いが生まれました。文章を生成するモデルの前に、判定を担当するモデルを置くと、RAGはどこまで改善するのでしょうか。
2. 今回はJevではなくDecision-1で確かめる
Microsoftは2026年10月9日、Decision-1を発表しました。公式発表では、固定した選択肢への確率、Yes／No、多肢選択、段階評価などを返し、分類、優先順位付け、検証、処理の分岐に使うモデルとして説明しています。[2]
今回の評価対象は、Microsoft Foundry（以下、Foundry）にデプロイしたDecision-1です。Jevは着想の背景であり、Jev自体の性能測定や、JevとDecision-1の直接比較は行っていません。
RAGでは、質問に近い文書を検索しただけでは、回答に必要な根拠がそろうとは限りません。似たサービスの説明が混ざることもあれば、必要な条件が複数の文書に分かれていることもあります。判定モデルには、この検索結果を回答生成へ渡す直前の処理を任せました。
3. 最初に置いた三つの仮説
検証では、関連性フィルター、回答可否のゲート、追加処理の費用対効果について仮説を置きました。リランクは、これらに加えて有効性を確かめる比較構成として用意しています。[3]
| 仮説 | 期待した変化 | 同時に確かめる副作用 |
|---|---|---|
| H1：不要な根拠を除けば回答が改善する | 無関係な文書に引きずられず、根拠に忠実に答える | 回答に必要な断片まで落とさないか |
| H2：根拠不足なら生成を止めると、無理な回答が減る | 答えのない質問で回答を控える | 答えられる質問まで拒否しないか |
| H3：判定の追加費用と時間は、品質改善に見合う | 汎用の大規模言語モデルによる判定よりも効率よく改善する | 呼び出し回数や待ち時間が増えないか |
H1の例は、Azure Blob Storageの質問に、名前や用語の近い別サービスの説明が混ざる場合です。不要な文書を取り除けばよさそうに見えますが、生成モデルが元から正しい根拠だけを選べるなら、フィルターを追加する効果は小さくなります。
H2では「回答を控えた数」だけでは成功を判断できません。何も答えないシステムなら、根拠のない回答は減りますが、利用者の仕事も進みません。回答不能な質問を止める効果と、回答可能な質問を止めてしまう過剰拒否を対にして測ります。
H3では、1回のAPI呼び出しの安さに加え、1問で何回呼ぶかを見ます。検索候補20件を1件ずつ判定する構成なら、質問1件で判定を20回行います。単体の速度だけでは、利用者が待つ時間を説明できません。
4. 五つの構成で、判定を置く場所を比べる
文書を検索用に分割した断片を、チャンクと呼びます。今回は、検索候補数と検索後の処理を変えた五つの構成を比較しました。埋め込みモデル、文書の分割方法、主評価の生成モデルと生成プロンプトは共通です。[3]
| 構成 | 検索候補 | 生成前の処理 | 生成へ渡す根拠 |
|---|---|---|---|
| A：基準 | 5件 | 判定なし | 検索上位5件 |
| B：関連性フィルター | 10件 | Decision-1で1件ずつ関連性を判定 | 確率0.8以上を確率順に最大5件 |
| C：フィルター＋ゲート | 10件 | Bに加え、根拠全体の十分性を判定 | 最大5件。0件または不十分なら生成しない |
| D：リランク | 20件 | Decision-1で有用性を4段階評価して並べ替え | 評価上位5件 |
| E：汎用モデルのフィルター | 10件 | gpt-6-lunaで関連の有無を判定 | 関連ありを検索順に最大5件 |
フィルターは、条件に合わない候補を落とします。リランクは、候補の順位を付け直します。ゲートは、回答生成を実行するか決めます。同じモデルを使っていても、担う役割と失敗の影響が異なります。
BとEも、完全に同一の処理ではありません。Bは確率によるしきい値と並べ替えを使い、Eは二値判定と元の検索順を使います。差が出ても、そのすべてがモデル本体の能力差によるものだとは判断できません。
5. 結果から、どこまで言えるか
対象はMicrosoft Learn日本語版のAzure Storageに関する302記事、6,118チャンクです。テスト用96問について各構成を3回実行し、主評価ではgpt-6-lunaが回答を生成しました。採点は、正解1点、部分正解0.5点、不正解0点の平均です。完全正解の件数割合ではありません。[3]
この条件では、Aの平均0.906に対し、Dは0.938となりました。検証資料では、同じ質問の結果を対応付けて比較するブートストラップ法で、有意な改善が報告されています。BとCは、回答品質の改善が確認できませんでした。判定を追加するだけで、どの役割でも改善するという結果にはなっていません。
Dは検索候補を5件から20件に広げています。そのため、今回分かったのは「候補を広げ、Decision-1で選ぶ構成」の効果です。同じ20件を使う別の選び方との比較がない段階で、改善をDecision-1単独の効果と断定できません。
導入の出発点は、自分のRAGがどこで失敗しているかを調べることです。根拠が検索候補に入らないのか、入っていても選べないのか、根拠が足りないまま生成してしまうのか。その違いに合わせて判定の役割を決めると、検証すべき仮説が具体的になります。
参考資料
資料の確認日：2026年10月23日。独自検証の数値は2026年10月16日〜20日の記録に基づきます。本記事の執筆時にAPIの再測定は行っていません。
- Introducing System One Models & Jev（TypeSafe AI、2026年9月15日）。着想の背景と、発表元の説明を参照。
- Introducing Microsoft-Decision-1, our model for fast decision-making（Microsoft、2026年10月9日）。
- Decision-1 RAG評価検証・資料リリース（筆者の検証資料、2026年10月22日版）。「04_PoC報告と考察」「05_検証手法」「08_計画・設計・環境仕様書」を参照。