⚖️ はじめに
最近Jevをはじめとした判断特化型のモデルが続々と出てきていますよね。文章は書かずに「はい」の確からしさだけを返してくれるモデルです。この判断モデルをRAGの検索に使う「DecisionRAG」という論文が出ていたので自分なりに噛み砕いてみました。後半は通常のRAG（以降NaiveRAGと記載）と比較検証をしてみました。
🎯 対象読者
- RAGを愛してやまない方
- 判断モデルに興味がある方
- ベクトル検索の精度に不満をお持ちの方
😢 従来のRAGの問題点
NaiveRAGはキーワード一致やベクトルの近さで文書を探します。この検索は余計なものを拾ったり答えを取りこぼしたりするんですよね。検索で取りこぼした答えはどんなに賢いLLMでも取り戻せません。だったら検索にもLLM級の賢さを持ち込もう!!というのがDecisionRAGです。とはいえ検索にLLMを使うとコストも時間もかかります。どうしたものか...と頭を抱えていたところに出てきたのが判断モデル（DecisionModel）です。これを検索に使っちゃおうというわけです。
📚 階層をたどる
皆さんは図書館で本を探す時に全部の本を1冊ずつ開いたりしませんよね？映画のコーナー→監督の棚→作品と順に絞っていくはずです。DecisionRAGもこれと同じで文書をツリーとして持っておいて各段で判断モデルが「どの棚を開くか」を決めます。捨てた棚の中は一切見ないので文書が膨大でも速いという仕組みです。
⚡ 賢いのに速いっ！
NaiveRAGは速いけど意味が近いだけで答えじゃないものを拾いがちです。AgenticRAGはLLMが何度も検索するので賢いけど遅くて高い。GraphRAGは人や物のつながりを辿れるけどグラフ作りが大変です。
DecisionRAGは判断モデルに文章を書かせず確からしさだけを出させます。だからAgenticRAGの賢さをNaiveRAGに近い速さで使えるというわけです。
🗂️ 検索の前に文書を階層に整理する
DecisionRAGはデータが「カテゴリ → 文書 → チャンク」のような階層になっていることが前提です。マニュアルや社内Wikiならフォルダや見出しをそのまま階層にすればOKです。構造がないデータは論文ではクラスタリングでグループに分けて各グループの説明文をLLMに書かせていました。
🔁 検索方法
- 階層データの子階層情報を取ってくる
- 判断モデルが質問と子階層の説明文を見比べて確率を付ける
- 上位k件（top-k）だけ残して次の段へ
これを一番下の段まで繰り返して最後に残ったチャンクを生成LLMに渡すだけです。
🧪 いざ検証！実際に作って測ってみた
...と、ここまで論文を解説してきたのですが「ホントにそんな美味しい話ある？」ということで作って測ってみました。
🌐 デモサイト
検証でも使用したこちらのサイトでぜひ速度と精度を体験してみてください。
アクセスが集中すると「アクセスが集中しています」と表示されて止まることもあります。ご了承ください🙇♂️
🏗️ 検証環境
DecisionRAGは判断モデルにJev（jev-1.14.0）を使って階層をDynamoDBに置きました。NaiveRAGはTitanv2で埋め込んでS3Vectorsから検索してCohereRerank3.5でリランキングします。回答はどちらもClaude Haiku 5.5です。
🌲 検証データと階層
| 文書 | 発行元 | チャンク数 |
|---|---|---|
| モデル就業規則 | 厚生労働省 | 77 |
| 育児・介護休業等に関する規則の規定例 | 厚生労働省 | 51 |
| 法令11本（労働基準法など） | e-Gov 法令 API | 805 |
| 法改定のお知らせ | e-Gov の改正履歴をもとに作成 | 65 |
DecisionRAGは階層構造（ツリー）がないと動きません。今回は約1000チャンクを大分類（8）→ 文書（31）→ 章（120）→ 条（998）の4階層に分けました。
📝 評価のやり方
色々なパターンの質問を順番を入れ替えながら3周検証しました。
| 種類 | 問数 | 例 |
|---|---|---|
| 素直なクエリ | 12 | 新しく採用された社員の試用期間は何か月ですか？ |
| 言い換え | 12 | おじいちゃんのお葬式で会社を休むとき、何日休めますか？ |
| マルチホップ | 12 | 自分から退職するときは何日前までに届け出ればよいですか？また、会社が解雇するときは法律で何日前の予告が必要ですか？ |
| 数値 | 8 | 課長の役付手当は月にいくらですか？ |
| 時間 | 10 | 先月掲載されたお知らせを全部教えてください。 |
| 回答不能 | 10 | 社員食堂の日替わり定食はいくらですか？ |
評価指標の意味
| 指標 | 定義 |
|---|---|
| Hit@1 | 1位のチャンクが正解か |
| Recall@5 | 回答LLMに渡したチャンクに含まれる正解の割合 |
| TTFT | 質問を送ってから回答の最初のトークンが届くまで |
| Cost | 1クエリあたりの費用（USD） |
📊 結果
| 方式 | Hit@1 | Recall@5 | TTFT | Cost/query |
|---|---|---|---|---|
| DecisionRAG | 0.91 | 0.91 | 1.63秒 | $0.0013 |
| NaiveRAG | 0.72 | 0.78 | 1.65秒 | $0.0024 |
今回の検証ではDecisionRAGがNaiveRAGを全てにおいて上回りました。
NaiveRAGより速いとまでは言えません。タイトルの「速い！」はNaiveRAGと同じくらい速いという意味で受け取ってください。
コストの内訳
DecisionRAGはJevが$0.0011で回答が$0.0002です。NaiveRAGはRerankが$0.0020で回答が$0.0004でした。NaiveRAGの費用は実はほとんどRerankなんですよね...
クエリの種類ごとのHit@1はこちらです。
| 種類 | DecisionRAG | NaiveRAG |
|---|---|---|
| 素直なクエリ | 0.97 | 0.92 |
| 言い換え | 0.92 | 0.58 |
| マルチホップ | 0.78 | 0.75 |
| 数値 | 0.96 | 0.75 |
| 時間 | 0.96 | 0.56 |
| 回答不能 | 0.90 | 0.77 |
特に言い換えと時間の質問で大きく差がつきました。
🤔 DecisionRAGを採用すべきか？
一番の良さは言い換えに強いことだと思います。しかも賢くなったのにコストはほぼ半分です。また、階層ごとにスコアが残るのでどの段で落としたのか後から追えてチューニングしやすい部分も嬉しいところです。表現や言い回しの違いでなかなか精度が出ていないベクトル検索には効果があると思います。逆にベクトル検索で十分な精度が出ているものやRerankを使っていないケースでは採用するメリットが薄いように思われます。
🌱 階層の鮮度が回答の質を決める
DecisionRAGのキモは検索より階層づくりだと思っています。文書は日々増えるのでカテゴリを定期的に整理する必要があります。検索時は判断モデルに任せて人はデータのカテゴリの保守に集中します。データ登録時の文書も判断モデルに「既存の棚に近い？新しい棚が要りそう？」とふるい分けさせれば人は毎回判断する必要はなく適切なタイミングで手を入れることが可能になります。階層の鮮度を保つことがそのまま回答の精度につながっていきます。
階層データをLLMに作らせるのか判断モデルに作らせるのか、作り方には色々なパターンがありますがどちらにせよコストはかかります。このコストは今回の検証の数字に入っていません。採用するなら階層づくりの運用とコストまで含めて判断することをお勧めします。
🍜 締め
検索を判断モデルに任せるとNaiveRAGより精度が上がってコストはほぼ半分になりました。速さは同じくらいです。タイトルで「速い、安い、上手い」と万能RAGのように書いてしまいましたが、GraphRAGのように検索の結果をまた次の検索につなげるホップ型の検索はやはり苦手だと思います。他にもデータや質問によってマッチするケース、しないケースがあると思います。コストが安いので是非小さく検証してから導入を検討してみてください。
DecisionRAGの登場は「RAGの選択肢がまた一つ増えた」くらいの捉え方がちょうどいいと思います。
RAGは機密性の高いデータを扱うことが多いのでJevのような外部APIは使いづらい場面があります。Strands Decider2Bのように自社環境で動かせるモデルならデータを外に出さずに済みますが、サーバーを常時動かすので使った分だけの課金にはなりません。OpenAIのDecisionsAPIのような従量課金の判断モデルが大手クラウドベンダーからも出てくると嬉しいですね。