公開2025.02.14更新2026.11.04 LLM・RAG

DeepRAGとは？サブクエリごとに検索を判断する仕組み・実験結果と公式実装の動かし方【ICLR 2026】

DeepRAGは、質問を小さなサブクエリに分け、サブクエリごとに「外部文書を検索するか、モデル自身の知識で答えるか」を判断させるRAG（検索拡張生成）の手法です。中国科学院ソフトウェア研究所とTencent WeChat AIの研究者9名が2025年2月にarXiv:2502.01142として公開し、ICLR 2026のポスター発表に採択されました。

UiPathのContext Groundingにも「DeepRAG」という同名の機能がありますが、論文とは別物です。この記事では論文のDeepRAGについて、仕組み、学習手順、実験結果、公式実装の動かし方を順に説明します。UiPath版の設定手順と消費ユニットは最後の章にまとめました。

まとめ：DeepRAGの要点

DeepRAGは、検索を伴う推論をマルコフ決定過程（MDP）として扱い、サブクエリごとに「検索する／しない」を決める学習手法
学習は2段階。二分木探索で「正解に届き、かつ検索回数が最少の経路」を集めて模倣学習し、次にChain of Calibrationで検索要否の判断を選好データで較正する
論文v2の表1では、Llama-3-8Bの6データセットにおけるEMとF1の平均が44.13で、比較手法の最高値（CoT-Retrieveの39.05）を上回った。WebQuestionsでの平均検索回数は0.28回
要旨の改善率はv1が21.99%、v2が26.4%、ICLR 2026版が25.41%と版ごとに違う。引用するときは版を明記する
公式実装はvLLMとElasticsearch 7.17.9で動き、推論スクリプトはGPU8基を前提に書かれている。学習データの作り直しには、公式スクリプトがGPU4基のテンソル並列で動かすQwen2.5-72Bを使う
公式リポジトリにもHugging Faceの重みにもライセンスの記載がない。業務で使う前に著者への確認が必要
UiPathのDeepRAGは「Deep Research-Augmented Generation」の略で、最大1,000ページの文書を横断して引用付きの回答を作る製品機能。TrialとEnterpriseのテナントでは1日2回まで無料で実行できる

DeepRAGが解こうとした問題：通常のRAGとの違い

通常のRAGは、質問を受けるたびに文書を検索し、上位の文書を文脈に入れて回答を生成します。検索が1回で済む質問なら十分ですが、「Aの監督が撮った別の映画の公開年は？」のように複数の事実をたどる質問では、1回の検索で必要な根拠がそろわず、答えに届かないことがあります。

論文は、検索と推論を組み合わせた既存手法の課題を2つ挙げています。1つは、複数の事実をたどる質問をうまく小分けにできないこと。もう1つは、モデルが答えを知っている部分まで検索してしまうことです。関係の薄い文書が文脈に混ざると、回答の品質が下がることがあります。

従来の反復型RAGは「毎ステップ検索する」か、「トークンの確信度が閾値を下回ったら検索する」ものが中心でした。DeepRAGは、検索の要否をモデル自身の知識の境界に合わせて学習させます。クエリ書き換えやリランキングで検索の質を上げる手法群（Advanced RAGと呼ばれることが多い）とは狙いが違い、「そもそも検索するか」を判断する側の改良です。検索と推論を組み合わせる設計全般はAgentic RAGのアーキテクチャ解説で扱っています。

DeepRAGの仕組み：MDPで定式化した検索判断

状態・行動・報酬の定義

状態は「元の質問と、それまでに出したサブクエリ・中間回答・検索した場合の取得文書の列」です。各ステップでモデルは2つの判断を下します。

終了判断：次のサブクエリを作るか、最終回答を出して終えるか
原子的判断（atomic decision）：いまのサブクエリを、文書を検索して答えるか、パラメータ内の知識だけで答えるか

報酬は最終回答の時点でだけ与えられます。まず正誤を見て、正解の中では検索回数が少ないほど高くなります。精度を最優先にしつつ、同じ正解なら検索の少ない経路を選ばせる設計です。サブクエリを前の中間回答に基づいて順に作っていく流れを、論文は「retrieval narrative」と呼んでいます。

推論時の出力形式と実装での判定方法

モデルは次の形式でサブクエリと中間回答を書き出します（論文3.2節）。検索を選んだステップだけにContext行が入ります。

Question : <Question>
Follow up : <Subquery1>
Let's search the question in Wikipedia.
Context: <Paragraph Text>
Intermediate answer : <Intermediate Answer1>
Follow up : <Subquery2>
Intermediate answer : <Intermediate Answer2>
......
So the final answer is : <Answer>

この例では、1問目は検索して答え、2問目はモデルの知識だけで答えています。公式実装（src/algorithms/sragsftv2.py）では、サブクエリを生成するときの停止語に「Let」を入れています。生成が「Let」で止まれば検索の経路へ、「Intermediate answer:」で止まれば知識だけで答える経路へ進みます。検索要否の判断に別の分類器は使っておらず、モデルが次に書く語そのものが判断です。サブクエリの深さの上限はHotpotQAで6、それ以外のデータセットで10に固定されています。論文の分析では、多くの質問が3〜5ステップに分解され、検索は0〜2回に集中していました。

学習の手順：二分木探索・模倣学習・Chain of Calibration

Stage I：二分木探索による最少検索経路の収集と模倣学習

サブクエリごとに「知識で答える」「検索して答える」の2通りに分岐させると、質問ごとに二分木ができます。論文のアルゴリズム1は、検索回数を優先度にしたキューで経路を展開し、正解に届いた時点で最も検索の少ない経路を採用します。どの経路でも正解できない質問は捨てます。

学習データはHotpotQAと2WikiMultihopQAから各4,000件です。サブクエリの分解と検索結果からの回答はQwen-2.5-72Bが生成し、知識だけで答える中間回答は学習対象のモデル自身が生成します。損失の計算では検索文書の部分をマスクし、ノイズの多い文書そのものをモデルが覚え込まないようにしています。

Stage II：Chain of Calibrationによる検索判断の較正

Stage Iのモデルで最少検索の経路を探し直し、サブクエリごとに「こちらが正しい選択」という選好ペアを作ります。たとえば最適経路が「1問目は知識で、2問目は検索で」なら、1問目は知識による回答を、2問目は検索による回答を好ましい側に置きます。経路全体ではなくサブクエリ単位で較正する点が、この段の特徴です。データは両データセットから各1,000件を追加で使います。

強化学習（GRPO）への拡張

v2では、Stage IIをGRPOによる強化学習に置き換えた実験が追加されました。学習が進むにつれ2WikiMultihopQAのF1が上がり、平均検索回数は下がる推移が示されています。実装はSearch-R1-for-DeepRAGとして別リポジトリで公開されています。

実験結果：6データセットの精度と検索回数

評価には、学習に使ったHotpotQA・2WikiMultihopQA（分布内）と、学習に使っていないCAG・PopQA・WebQuestions・MuSiQue（分布外）の6データセットを使っています。検索器はBM25で、基本の知識源はDPRのWikipedia分割です。CAGの時事問題にはデータセット付属の最新の文章を使っています。

次の表は論文v2の表1から、完全一致率（EM）と回答の語句の重なりを測るF1を平均した「Avg」列を抜き出したものです。Search-o1にはDeepSeek-R1の蒸留モデルを使っており、列見出しのモデルと同一条件ではありません。

手法	Llama-3-8B	Qwen-2.5-7B	Qwen-2.5-32B
CoT（検索なし）	24.54	17.85	16.99
CoT-Retrieve	39.05	27.49	32.34
Auto-RAG	32.62	–	–
Search-o1	15.36	11.09	28.00
UAR	37.52	27.39	–
TAARE	37.75	28.38	–
DeepRAG-Imi（Stage Iのみ）	42.32	35.59	–
DeepRAG	44.13	39.00	42.27

DeepRAG-ImiとDeepRAGの差（Llama-3-8Bで1.81ポイント）が、Chain of Calibrationの上乗せ分です。Qwen-2.5-32Bでは比較手法がCoT系・Iter-DRAG・Search-o1の4つに絞られており、7B・8Bの結果とは比較範囲が違います。

検索回数と1問あたりの時間（WebQuestions）

表2では、DeepRAGがEM 32.70、平均検索0.28回、1問あたり0.50秒でした。処理時間はH20を8基搭載した環境での測定値です。反復検索型のAuto-RAGは平均4.52回検索してEMは17.40です。確信度で検索を決めるFLAREとDRAGINは、既定の閾値のままではWebQuestionsで一度も検索しませんでした。閾値を使う方式は、データセットごとに閾値の調整が要ります。

検索すべき質問を見分けられたかは、2WikiMultihopQAで別に測られています（表3）。検索なしのCoTで解けたかどうかを基準にした一致度（MCC）は、DeepRAGが0.451で、分類器で検索要否を決めるUARの0.341を上回りました。

CoT-Retrieveに負けたデータセット：時事問題のCAG

時事性を問うCAGでは、毎回検索するCoT-Retrieve（Llama-3-8BでEM 55.45）がDeepRAG（52.96）を上回りました。論文は、時事問題ではほぼ毎回検索することが正解になるためだと説明しています。

論文の版別改善率：21.99%・26.4%・25.41%

DeepRAGの紹介記事によって改善率が違うのは、引用元の版が違うためです。2026年11月4日時点で、arXivの最新版はv2です。

版	公開	要旨の改善率	主な違い
arXiv v1	2025-02-03	21.99%	題名は「Thinking to Retrieval」、5データセット
arXiv v2	2025-06-08	26.4%	題名を「Retrieve」に変更、MuSiQue・Qwen-2.5-32B・GRPOを追加
ICLR 2026採録版	2026年	25.41%	ポスター発表として採択

v2でも序論には「21.99%」が残っており、要旨の26.4%と食い違っています。どの手法を基準にした改善率なのかも、要旨には書かれていません。社内資料や提案書で数字を使うなら、単一の「○%向上」より、前章の表1のように比較手法と平均値を並べて示すほうが誤解を生みません。

公式実装の構成と推論スクリプトの手順

公式実装はGitHubのgxy-gxy/DeepRAGにあります。評価基盤は適応型検索の手法DRAGINの実装を流用しており、モデルはvLLMのOpenAI互換サーバーとして立て、検索はElasticsearchのBM25で行う構成です。以下はREADMEとscripts/配下のスクリプト（2026年11月4日時点・最終更新2026年2月17日）を抜粋して整理したものです。当社のLinux・GPU環境で導入から回答出力までを通して実行した手順ではないため、実行時は依存パッケージの版を各自で合わせてください。

必要な環境と学習済みの重み

Elasticsearchの取得先がLinux x86_64版に固定されているので、Linuxのマシンを用意します。requirements.txtはなく、install.shはspaCy・numpy==1.26.4・elasticsearch==7.17.9・BEIRなどを入れるだけです。spaCyの英語モデルは作者の手元のwheelファイルを指しているため、そのままでは入りません。vLLM・transformers・openaiは別途入れます。

学習済みの重みはHugging Faceに2つあります。

リポジトリ	アーキテクチャ	層数	重みの合計
xinyan233333/DeepRAG-7b	Qwen2（Qwen-2.5-7B系）	28	約15.2GB（bf16）
xinyan233333/DeepRAG-8b	Llama（Llama-3-8B系）	32	約16.1GB（bf16）

重みだけで15GBを超えるため、bf16のままvLLMに載せるならVRAM 16GBのGPUでは足りません。READMEの「Model Checkpoints」欄は「comming soon」のままですが、冒頭に上の2つへのリンクがあり、どちらも2026年2月17日に作成されています。

WikipediaのElasticsearch索引作成

知識源はDPRのWikipedia分割（psgs_w100.tsv）です。ダウンロードしてElasticsearchに索引化します。

mkdir -p data/dpr
wget -O data/dpr/psgs_w100.tsv.gz https://dl.fbaipublicfiles.com/dpr/wikipedia_split/psgs_w100.tsv.gz
gzip -d data/dpr/psgs_w100.tsv.gz

cd data
wget -O elasticsearch-7.17.9.tar.gz https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.17.9-linux-x86_64.tar.gz
tar zxvf elasticsearch-7.17.9.tar.gz
cd elasticsearch-7.17.9
nohup bin/elasticsearch &
cd ../..
python retriever_tools/prep_elastic.py --data_path data/dpr/psgs_w100.tsv --index_name wiki

READMEは最終行をpython prep_elastic.pyと書いていますが、スクリプトの実体はretriever_tools/の下にあります。索引名の既定はwikiで、推論側も--es_index_nameの既定値wikiで参照します。Elasticsearchの接続先は環境変数ES_HOSTで、未設定ならlocalhostです。

vLLMサーバーの起動とDeepRAG推論の実行

公式の起動スクリプトscripts/launch/run.shは、GPU0〜7に1基ずつvLLMを立て、ポート8000〜8007で待ち受けます。

for i in `seq 0 7`; do
    CUDA_VISIBLE_DEVICES=$i nohup python3 -m vllm.entrypoints.openai.api_server --model $MODEL_PATH --tensor-parallel-size 1 --port 800$i > deploy_llama_800$i.log 2>&1 &
done

推論はscripts/inference/run.shがsrcに移動してからmain.pyを次のように呼びます（HotpotQAの例。URLはGPU1基のときの値に置き換えています）。

cd src
REMOTE_URL="http://0.0.0.0:8000/v1"
FOLLOW_UP_REMOTE_URL=${REMOTE_URL}
export ES_HOST=0.0.0.0

python main.py \
    --remote_url ${REMOTE_URL} \
    --method srag-sftv2 \
    --model_name_or_path hf_models/Meta-Llama-3-8B-Instruct \
    --dataset hotpotqa \
    --data_path data/hotpotqa \
    --split dev \
    --num_processes 32 \
    --generate_max_length 4096 \
    --sample 1000 \
    --output_dir result/hotpotqa \
    --temperature 0.0 \
    --follow_up_remote_url ${FOLLOW_UP_REMOTE_URL}

公式スクリプトはREMOTE_URLに8基分のURL（ポート8000〜8007）を空白区切りで並べます。GPUが1基なら、起動のループを1回にし、上のようにURLを1つにします。評価データ（HotpotQAのdev分割など）は同梱のREADME_DRAGIN.mdの手順で取得し、--data_pathが指す場所（srcからの相対パス）に置きます。公開重みを使う場合は、MODEL_PATHと--model_name_or_pathの両方をダウンロード先に書き換えてください。src/algorithms/basic.pyは、vLLMが返すモデル一覧の先頭のIDでトークナイザを読み込みます。同時に--model_name_or_pathの設定ファイルも必ず読むため、どちらかが実在しないパスだと起動時に止まります。DeepRAG本体の手法名はsrag-sftv2で、検索する文書数の既定は3件です。評価はscripts/eval/run.shでEMとF1を出します。

再学習用のモデル環境と質問データ

自社データで学習し直すには、Stage Iのデータ構築でサブクエリの分解役としてQwen2.5-72B-Instructを立てます。公式スクリプトrun-72b.shはこれをGPU4基のテンソル並列で動かしています。必要な台数はGPUの機種やVRAM容量によって変わるため、4基は公式の設定例として見積もりの起点にしてください。学習本体はLLaMA-Factoryを使い、Stage I（SFT）とStage II（選好学習）でスクリプトが分かれています。

学習の起点になる質問はdata/に同梱されています。HotpotQAと2WikiMultihopQAそれぞれ、Stage I用のsft_new.jsonlが4,000件、Stage II用のdpo_new.jsonlが1,000件で、論文の件数と一致します。中身は元データセットの質問・正解・根拠文で、構築済みの推論経路ではありません。HotpotQAの4,000件の内訳は、複数文書をたどるbridge型が3,198件、2つの対象を比べるcomparison型が802件です。自社データで作り直すときは、この形式で質問と正解のペアを数千件用意することになります。

DeepRAGが向かない場面と業務利用の前提

最初に確認すべきはライセンスです。2026年11月4日時点で、リポジトリにはLICENSEファイルがなく、GitHub上のライセンス表示も空です。Hugging Faceの2モデルにもライセンスの記載はありません。研究目的で読むのは問題ありませんが、社内システムへの組み込みや改変しての配布を考えるなら、著者に利用条件を確認してから進めてください。

そのうえで、次の条件に当てはまる用途ではDeepRAGを選ぶ理由が薄くなります。

時事性の高い質問が中心：前述のCAGのように、毎回検索する単純な構成のほうが精度が出る
質問がほぼ1回の検索で答えられる：サブクエリ分解の手間が増えるだけで、検索回数を減らす余地が小さい
自社のモデルに適用したいが追加学習できない：プロンプトの変更だけでは論文の学習手法を再現できない。公開済みの重み（Qwen-2.5-7B系とLlama-3-8B系）で推論するだけなら追加学習は要らない
知識源がWikipediaから大きく離れる：公開重みはWikipediaで答えられる質問で学習している。社内文書で検索要否の判断が働くかは論文で検証されていないので、対象業務の質問で評価してから追加学習の要否を決める

逆に、固定の社内コーパスに対する複数段の質問が多く、検索APIの呼び出し回数やレイテンシを減らしたい場合は、検討する価値があります。導入の前後で精度を比べるなら、検索と生成を分けて測るRAG評価の指標と実装の手順が使えます。自社の文書でRAGの構成から検討する場合は、RAG構築支援でも相談を受けています。

Self-RAG・Adaptive-RAG・FLAREとの比較：検索判断の仕組みと単位

適応型RAGの手法は、検索するかどうかを何で決めるか、どの単位で決めるかで分けると違いが見えます。

手法	検索の要否を決めるもの	単位
FLARE・DRAGIN	トークンの確信度・重要度と閾値	生成中のトークン
Adaptive-RAG	質問の複雑さを予測する小型の分類器	質問
UAR	別途学習した分類器	質問
Self-RAG	生成中に出す反省トークン	生成中の区切り
Auto-RAG	反復検索を続けるかの自己判断	反復ステップ
Search-o1	推論モデルが特殊トークンで呼び出す	推論の途中
DeepRAG	最少検索の経路で学習したモデル自身	サブクエリ

Adaptive-RAG（NAACL 2024）は、質問を受けた時点で「検索なし・1回検索・反復検索」のどれで解くかを分類器に選ばせます。DeepRAGは質問全体ではなく、分解した後のサブクエリごとに選ぶので、同じ質問の中で「前半は知識、後半は検索」と使い分けられます。Self-RAGは論文の関連研究で挙げられていますが、v2の実験の比較対象には入っていません。

同じくマルチホップ質問を扱うDualRAGは、検索で得た知識を整理して蓄積する仕組み（pKA）を持ち、検索の回数より知識の整理に重心があります。検索前に推論を生成してからクエリを作る方向の研究には、O1 Embedderがあります。

UiPathのDeepRAG：Context Groundingの設定手順と消費ユニット

「uipath deeprag」で調べている場合は、この章が目的の情報です。UiPathのDeepRAGは「Deep Research-Augmented Generation」の略で、Automation CloudのContext Groundingに含まれる機能です。論文のDeepRAGとは名前が同じだけで、利用者がモデルを学習させる必要はありません。

3段階の処理とセマンティック検索との使い分け

公式ドキュメント「Using DeepRAG」は、動作を次の3段階で説明しています。

Planning：質問を分析し、サブタスクと調査範囲を決める
Iterative research loop：索引済みのデータを検索し、根拠を抜き出して統合する
Synthesis：根拠をまとめ、引用付きの回答を作る

1回のクエリで最大1,000ページを横断し、主要な記述ごとに文書名・ページ番号・タイムスタンプを引用として付けます。同じ文書から該当箇所を探すだけならセマンティック検索のほうが速く安価で、DeepRAGは複数文書をまとめる分析向けと位置づけられています。所要時間の目安は200ページ以下で10分未満、500〜800ページで20分未満、1,000ページで30分未満です。60分を超えるとタイムアウトします。

Agent Builderでの設定手順

文書を用意する：ネイティブPDFかTXTで、1ファイル512MBまで。スキャンしたPDFはOCRを済ませておく
索引を作る：Agent BuilderのContextノードで新規作成し、取り込みモード（Ingestion mode）をAdvancedにして文書をアップロードする
エージェントに設定する：Contextで作成した索引を選び、検索戦略の項目でDeepRAGを選び、検索戦略用のプロンプトを書く

取り込みモードをBasicにすると「No valid files to use for DeepRAG」になります。引用は自動で付くため、プロンプトで引用の書式を指定すると結果を乱すとされています。役割・タスク・要件・出力形式の順に書く型が推奨されています。

消費ユニットと無料枠

Context Groundingのライセンスのページによると、消費量は契約の種類で単位が違います。表の20ページは約30,000トークン、10ページは約15,000トークンの目安で、実際の消費は入力サイズや利用する製品機能によって変わる場合があります。

項目	Unified Pricing	Flex
DeepRAGのクエリ	20ページあたり0.2 Platform Units	20ページあたり1 AI Unit
Advancedの取り込み	10ページあたり0.4 Platform Units	10ページあたり2 AI Units
Basicの取り込み・検索	無料	無料

TrialとEnterpriseのテナントは、DeepRAGを1日2回まで無料で実行でき、それを超えると消費が始まります。注意したいのは、CommunityとTrialではAdvancedの取り込みが使えないことです。DeepRAGの索引はAdvancedで作る手順になっているため、Trialで自前文書を取り込む前に、必要な契約への変更や利用可能な検証方法をUiPathに確認してください。なお「Using DeepRAG」のページ側の費用欄は「30Kトークンあたり0.20 AIU」と書いており、ライセンスのページと単位の書き方が揃っていません。見積もりにはライセンスのページの数字を使うのが安全です。

よくある質問

DeepRAGとは何ですか？

質問をサブクエリに分解し、サブクエリごとに検索するかモデル内の知識で答えるかを判断させるRAGの手法です。2025年2月にarXivで公開され、ICLR 2026に採択されました。

DeepRAGとSelf-RAGの違いは何ですか？

Self-RAGは生成の途中で反省トークンを出して検索や自己評価を行います。DeepRAGは判断をサブクエリ単位の「検索する／しない」の二択に絞り、正解に届く最少検索の経路から学習します。DeepRAGの論文v2の実験では、Self-RAGは比較対象に入っていません。

UiPathのDeepRAGは論文のDeepRAGと同じものですか？

別物です。UiPathのDeepRAGは「Deep Research-Augmented Generation」の略で、Context Groundingで最大1,000ページの文書を横断し、引用付きの回答を作る製品機能です。利用者がモデルを追加学習する手順はありません。

DeepRAGを自分で動かすには何が必要ですか？

Linuxのマシン、Elasticsearch 7.17.9で索引化したWikipedia、vLLMで立てたモデル（公開重みは7Bと8Bで各15〜16GB）が必要です。学習し直す場合は、データ構築用のQwen2.5-72Bを動かす環境も要ります（公式スクリプトはGPU4基のテンソル並列）。コードと重みにはライセンスの記載がないため、業務利用の前に著者へ確認してください。