アーカイブ / LLM / RAG
検索文書で答えられるかを判定し、必要時にAPIを呼ぶDynaRAG
DynaRAG
DynaRAGの原論文から掲載した図です。細部はクリックして拡大できます。
原論文の図の説明を読む
Fig. 1: DynaRAG pipeline
概要
- DynaRAGは検索文書の関連度から回答に使えるかを判定し、不十分な場合にAPIを呼ぶ。
- 著者のCRAG評価では、APIを使えるTask 2の正答率は41.00%、幻覚率は22.09%だった。
- Task 1の正答率はDirect RAGを下回り、Task 1とTask 2の正答率差について本文と表の数値が一致しない。
補足：編集した模式図で仕組みを確認する
VISUAL EXPLAINER
図でつかむ、DynaRAGの仕組み
- 01質問
- 02ウェブ文書取得
- 03整形・再順位付け
- 04十分性判定・必要時API
- 05回答
原論文の説明をもとにした模式図です。処理の細部は省略しています。
研究の背景
DynaRAGは、検索文書だけで答えるか、更新された情報をAPIから取得するかを選ぶ質問応答手法である。検索拡張生成（RAG）は、探した文書を根拠に回答するが、文書に現在の事実がなければ古い内容に頼る恐れがある。
たとえば日々変わる情報では、質問に関連する文書が見つかっても、その内容が最新とは限らない。文書で答えられるかを見極め、足りないときに別の情報源へ進む判断が課題になる。
手法
質問に対しウェブ文書を取得し、HTMLから段落の本文を抜き出して不要な表示要素を除く。大規模言語モデル（LLM）が質問との関連度を各文書に付け、並べ直す。最高点が開発用データで調整した閾値以上なら、上位の文書を回答生成モデルへ渡す。
閾値未満なら、FAISSという類似検索の仕組みでAPIの仕様から候補を探す。API呼び出し用モデルGorilla v2が仕様を基に呼び出しを作り、その結果を文書の情報とともに回答生成モデルへ渡す。たとえば最新の数値を尋ねられ、文書が不十分と判定された場合に、APIで取得した値を回答に使う流れである。
新規性
DynaRAGは、検索文書を大規模言語モデルで再順位付けし、最高点が閾値を下回ったときにAPI照会へ進む回答手順を提案する。文書の関連度を、外部情報を取得するかどうかの判断にも使う。
API照会ではFAISSによる類似検索で仕様の候補を絞り、Gorilla v2に呼び出しを作らせる。著者が主張する前進は、この経路選択を文書検索と回答生成の間に組み込んだ点にある。
従来手法との違い
LLM Onlyは外部情報なしで答える。Direct RAGは取得したウェブ文書を最大4,000トークンの固定長で質問に添え、再順位付けや十分性判定、APIへの切り替えは行わない。
DynaRAGは文書を整形して関連度順に並べ、最高点を閾値と比べる。CRAGではAPIを使えるTask 2の正答率がDirect RAGを上回った一方、APIを使わないTask 1は下回った。改善を全条件に広げて解釈することはできない。
実験結果
著者はCRAGの4,409問で評価した。Task 1では各問に最大5件のウェブページが与えられ、Task 2ではさらに38種類の模擬APIを利用できる。基礎モデルはLlama 3–70B–Instructで、表は正答率・幻覚率・回答欠落率を報告する。
表の正答率はLLM Onlyが28.53%、Direct RAGが34.23%、DynaRAGのTask 1が29.12%、Task 2が41.00%。幻覚率は同順に34.95%、43.09%、25.33%、22.09%、回答欠落率は36.52%、22.68%、45.55%、36.91%だった。本文はTask 2とTask 1の正答率差を6.77ポイントと記すが、表から計算すると11.88ポイントで一致しない。
応用の可能性
編集上の応用案 · 論文が実証した用途とは区別しています。
編集上の応用案：社内の商品照会で、製品説明書と在庫APIを組み合わせる。担当者が型番の注文可否を尋ね、説明書で答えられない場合にAPIの在庫情報を取得し、製品の説明と現在の在庫を回答にまとめる。
入力源には検索可能な説明書と、登録済みのAPI仕様・応答が要る。閾値調整には「文書だけで答えられるか」のラベルを付けた質問を用意する。元のモデルの学習データや追加学習の要否は本文に記載がない。文書とAPIを使う想定で、専用センサーは使わない応用仮説である。
導入時の検証
導入時の検証案 · 対象データでの再評価が必要です。
導入時の検証案：説明書を検索対象にし、在庫APIの仕様を候補一覧へ登録する。文書だけで答えられるかを人が判定した質問で閾値を調整し、同じ質問に対して文書をそのまま添える方式とDynaRAG方式を比較する。
検証用には質問、正解、情報の更新要否、回答不能でよい条件をラベルとして記録する。元のモデルの学習データや追加学習の条件は本文に記載がないため、導入時に確認する。専用センサーを使わない文書・APIの構成で、正答率、根拠のない回答、回答欠落、API呼び出し回数、応答時間を測る。
限界と課題
著者は、API仕様の有無や品質への依存、再順位付けとAPI呼び出しによる遅延・計算負荷、固定閾値が分野や質問の分布に合わない可能性を限界として挙げる。評価がCRAG中心で、別の環境への一般化も未確認としている。
編集上の検証事項として、古い文書に高い関連度が付いてAPI照会を逃す場合や、API応答が得られない場合の回答を調べたい。著者も、十分だと誤判定すればAPIに進めないと説明する。運用先では閾値、応答時間、API利用回数を測る必要がある。
出典
元のタイトル・要旨を確認する（英語）
DynaRAG: Bridging Static and Dynamic Knowledge in Retrieval-Augmented Generation
We present DynaRAG, a retrieval-augmented generation (RAG) framework designed to handle both static and time-sensitive information needs through dynamic knowledge integration. Unlike traditional RAG pipelines that rely solely on static corpora, DynaRAG selectively invokes external APIs when retrieved documents are insufficient for answering a query. The system employs an LLM-based reranker to assess document relevance, a sufficiency classifier to determine when fallback is necessary, and Gorilla v2 -- a state-of-the-art API calling model -- for accurate tool invocation. We further enhance robustness by incorporating schema filtering via FAISS to guide API selection. Evaluations on the CRAG benchmark demonstrate that DynaRAG significantly improves accuracy on dynamic questions, while also reducing hallucinations. Our results highlight the importance of dynamic-aware routing and selective tool use in building reliable, real-world question-answering systems.
論文本体の取得範囲に基づく解説。AIが作成した未校閲の記事です。性能の数値は著者の評価条件に依存します。応用例と検証計画は編集上の提案です。解説更新：2026-10-01