CADDi Tech/Product Advent Calendar 2025 10日目の記事です。
こんにちは、Data&Analysis部の竹本です。
本記事ではRAGシステムを構築する上で、ユーザー意図の把握が難しい曖昧なクエリにどのように対応すべきかという課題に着目し、関連する論文や技術記事を紹介します。
- クエリの「情報不足」と「曖昧性」という壁
- Query Transformation
- Diversify then Verify
- Verified-Diversification with Consolidation
- 対話的な解決
- まとめ
クエリの「情報不足」と「曖昧性」という壁
キャディではRAGを用いて、ユーザーが膨大なドキュメントから適切に情報を得られる機能の検証を行っています。この取り組みの背景については、4日目の記事で詳しく紹介していますので是非ご覧ください。
ユーザーが膨大なドキュメントから必要な情報を適切に取得できるようにすることがRAGシステムの狙いですが、必要としているドキュメントに辿り着けないという課題が検証の中で発生しました。そこでユーザーが入力したクエリ（以下、ユーザークエリ）、中間処理の結果、および最終的な回答を分析したところ、ユーザークエリに含まれる情報の不足や曖昧さが一因となり、ユーザーが求める情報が適切にヒットしていないケースが確認されました。
情報不足や曖昧性は大きく分けて以下の2つのパターンがあると考えます。
知識ギャップによる情報不足
ユーザー自身が適切な聞き方がわからず、所望の情報が回答されないケースです。ユーザーが質問をする際、そのトピックに関する専門用語や正しい名称を知らない（周辺情報も不足している）状況は多々あります。その結果、ユーザーの意図が適切にクエリに反映されず、ユーザークエリと欲しい情報を見つけるための検索用語との間にミスマッチが発生し、所望のドキュメントがヒットしないケースです。
具体例としては、「製品Aの動きがガタつく不具合は過去に報告されていますか？」というユーザークエリに対して、ドキュメントには「ガタつく不具合」とは記載されておらず、「クリアランス（隙間）過大」と記載されていることがあります。
ユーザークエリの曖昧性
クエリが短すぎる、または抽象的すぎるため、広範なドキュメントがヒットしてしまい、回答にノイズが含まれるもしくは欲しい情報がノイズに埋もれて回答されないケースです。
ユーザークエリの具体例としては、「環境試験とは？」のようなケースです。この場合ユーザーはどの環境試験（温湿度試験、冷熱衝撃試験など）について知りたいのか、具体的に知りたい対象の製品があるのか、抽象的なクエリからは判断できません。
以降ではユーザクエリの情報不足や曖昧性に対処する手法を紹介します。
Query Transformation
アプローチの1つ目はQuery Transformationやクエリ拡張と呼ばれている手法です。Query Transformationはその中でも複数の種類があります。
Query Rewriting
Rewriterを用いてユーザークエリを書き換える手法です。Rewriterは主に2種類あります。
- Vanilla LLM Rewriter
- メリット：追加学習が不要で、検証・導入が容易
- デメリット：書き換えによる効果が保証されない。意図しない変更やノイズ混入のリスクがある
- Fine-tuned Rewriter
- メリット：書き換えタスク専用に調整できること、また軽量モデルを採用することで計算コストやレイテンシーを抑えられる
- デメリット：学習とそのための準備が必要
以下の論文ではQuery Rewritingを導入したRewrite-Retrieve-Readのフレームワークを提案しており、曖昧もしくは長文なユーザークエリに対してfine-tuningしたt5-largeを使い、検索意図を明確化にすることによる改善を報告しています。
「Query Rewriting for Retrieval-Augmented Large Language Models」より引用
Multi-Query
曖昧なユーザークエリから明確化したクエリを複数生成し（マルチクエリ）、それぞれに対応する回答と根拠文書を提供する手法です。ベクトル検索の弱点を補い、検索の取りこぼしを減らすメリットもあります。 これもQuery RewritingのRewriterと同様の選択肢があります。また、マルチクエリで得られた検索結果を全て回答に使用するのか、それとも回答前に各検索結果に対する評価を挟むのかという選択肢があります。後者の手法は後述します。
Diversify then Verify
アプローチの2つ目は曖昧なユーザークエリに対して以下の2段階を踏む、Diversify then Verify（DtV）という手法です。
- Diversify：ユーザークエリが持ちうる複数の意図を網羅するために、複数のバリエーションでマルチクエリを生成
- Verify：検索されたドキュメントや生成された回答候補を評価し、確実性が最も高いものを選抜、あるいは矛盾を排除
RAG-Fusion
RAG-Fusionは、ユーザクエリからマルチクエリを生成しベクトル検索でドキュメントを取得した上で、マルチクエリで取得したドキュメントを「複数の異なるクエリ検索で共通して上位に現れるドキュメントは信頼性が高い」という仮定に基づき、Reciprocal Rank FusionでRe-rankingする手法（Multi-Query + Re-ranking）です。
以下のアーキテクチャ図を見ると理解しやすいと思います。
「Forget RAG, the Future is RAG-Fusion」より引用
記事では、マルチクエリの使用によって本来のユーザー意図が薄れる可能性を指摘しています。その対策として、プロンプトエンジニアリングによって元のユーザークエリに重点を置くように指示することを推奨しています。
またRAG-Fusionの課題として、回答が冗長になりすぎるリスクや、LLMのコンテキストウィンドウを圧迫するリスクがある点も課題として挙げられています。
Diversify-verify-adapt
Diversify-verify-adapt（DIVA）はマルチクエリによる検索結果をLLMによって評価し、その結果から検索結果を元にした回答とClosed-book LLMによる回答を使い分ける手法です。
具体的には以下の3つのモジュールで構成されています。
- Retrieval Diversifier：
- LLMを用いて曖昧さのタイプ（主語、目的語、述語、時間、場所）を特定
- 特定した結果に基づいて別のLLMが曖昧箇所を明確化したマルチクエリ（Pseudo-interpretations）を生成
- 各クエリで検索して、得られたチャンク群に対してノイズスコアを計算し、関連性の低いチャンクを削除（Pruning）して最終的なチャンクセットを作成
- Retrieval Quality Verifier：
- 選定されたチャンクセットを使って、各クエリに対し十分な回答が得られているか（Yes or No）を評価
- 各評価結果を元に最終的に「全てのクエリでYes（=Useful）」、「一部のクエリでYes（=PartialUseful）」、「全てのクエリでNo（Useless）」の3段階で評価
- Adaptive Generator：
- Retrieval Quality Verifierで「Useful」もしくは「PartialUseful」の場合は、検索結果をプロンプトに含めてLLMによる回答を実施
- Retrieval Quality Verifierで「Useless」の場合は、検索結果を完全に無視してClosed-book LLMによる回答を実施
「Diversify-verify-adapt: Efficient and Robust Retrieval-Augmented Ambiguous Question Answering」より引用
GPT-4を使用した場合、曖昧性の検出とマルチクエリの生成を同時に行うとLLMへの負荷が高まり、性能が大幅に低下したと報告されています。論文ではステップを分離していますが、より高性能な後継モデルを使う場合は、同時処理が可能かどうか再検証してみても良いかもしれません。 一方、DIVAの課題としては、曖昧でないユーザークエリに対する過剰な処理が挙げられます。これを防ぐには、曖昧かどうかを事前に分類する手法と組み合わせて、ケースに応じて処理を使い分ける必要があると言及しています。
Verified-Diversification with Consolidation
アプローチの3つ目はDtVが抱えていた課題を改善したVerified-Diversification with Consolidation（VERDICT）という手法です。
DtVの具体的な課題とそれに対するVERDICTの解決策は以下になります。
- 「根拠のないマルチクエリ生成」を排除
- DtV：コーパスに存在しない無関係な解釈まで生成してしまい、無駄な検索が発生する
- VERDICT：ユーザークエリを緩和したクエリに書き換え、関連する広範囲な検索を一度だけ実行し、得られた文書を起点（Grounding）としてマルチクエリを生成する
- 「回答に使えない文書」を早期除外
- DtV：検索器が関連性が高いと判断した文書を全てLLMに渡すため、コンテキストウィンドウの圧迫とノイズによるハルシネーション発生リスクがある
- VERDICT：解釈の生成と同時に「その文書で回答可能か」を判断することで回答生成に使えないノイズを最初から除外する
特に1の課題については、単なる計算コストの増大だけでなく、前段のミスが後段に連鎖するカスケーディングエラーを招きやすいという構造的な問題がありました。従来のDtVが「まず広げて（Diversify）、後で検証（Verify）」という分離されたパイプラインだったのに対し、VERDICTはこの2つを統合し、「検証しながら広げる」アプローチを採用することで、計算コストとこのカスケーディングエラーの両面で問題を解決しています。
「Agentic Verification for Ambiguous Query Disambiguation」より引用
VERDICTの具体的なワークフローは、以下の4ステップで構成されています。
- Rewrite user query as relaxed query：LLMを使用し、曖昧で短いユーザークエリをより広範囲の情報を網羅できる緩和されたクエリに書き換える
- Universe Retrieval：書き換えたクエリを用いて、広範囲に検索
- Verified Diversification：検索された各チャンクに対し、LLMに「このチャンクを使って、ユーザー意図を明確にしたクエリとその回答を作る」というタスクを指示し、生成に失敗したりチャンク内に根拠が見当たらない場合はフィルタリング
- Consolidation：生成された「複数のクエリ（解釈）と回答のペア」に対してノイズ除去とクラスタリングを実施
- 各ペアをベクトル空間に射影（クエリだけでなく回答の一貫性も評価するためにペアで埋め込むのがポイント）
- HDBSCAN(Hierarchical Density-Based Spatial Clustering of Applications with Noise)を用いてクラスタリング
- クラスタに属さない外れ値は、誤った解釈やハルシネーションである可能性が高いため除外
- 形成されたクラスタの中心（Medoid）となるペアを取得
「Agentic Verification for Ambiguous Query Disambiguation」より引用
DtVとVERDICTをend-to-endのパイプラインで比較した図が以下になります。
VERDICTは検索が1回で済む一方で、得られたチャンク数分のLLM呼び出しが発生します。LLM呼び出しの並列処理が難しい環境だとその分レイテンシーが悪化する点と、外部LLMのAPIを使用する場合はレートリミットや課金体系に注意が必要です。
「Agentic Verification for Ambiguous Query Disambiguation」より引用
arxiv.org www.snowflake.com github.com
対話的な解決
最後となるアプローチの4つ目は、ユーザーへの「問いかけ」によって意図を明確化する手法です。これまでの3つのアプローチは、あくまでLLMの事前知識やコーパスに基づき、正解と思われるクエリを推論していました。しかし状況によってはユーザーに直接問い合わせる方が、より正確な情報を迅速に得られる場合があります。
動的にユーザーに問い合わせる
LangChainの記事（2023年のlangchainがv0.0.318だった頃）では、以下2つを行い、ユーザーとの対話を通して曖昧性を解決するアプローチを紹介しています。
- 検索結果に十分なコンテキストが含まれていないとLLM agentが判定した場合はユーザーへ逆質問する
- 元の質問、検索結果、会話履歴などを元にLLM agentが質問を生成
「Improve LLM responses in RAG use cases by interacting with the user」より引用
現在ではLangGraphの割り込み（Interrupt）を使ったHuman-in-the-loopが推奨されています。
上記の記事では触れていませんが、実際のプロダクトに組み込む際は、「どのタイミングで、どんな内容を、どれくらいの量、どのように作成し、どのようにユーザーへ提示するのか」といったUI/UXの設計が重要になります。この設計が不十分だと、せっかく提案されたクエリを使ったのに十分な回答が得られなかったり、意図したクエリ候補が提案されなかったりと、結果としてユーザーのがっかり体験に繋がります。
まとめ
本記事ではRAGにおける「曖昧なクエリ」が持つ課題と、代表的な解決アプローチを紹介しました。
- Query Transformation：比較的導入しやすいが、精度に限界がある場合も
- DtV (RAG-Fusion / DIVA)：検索精度は向上するが、計算コストの増大やノイズ混入のリスクがある
- VERDICT：DtVの課題を構造的に解決する一方で、LLM呼び出し回数（コスト・レイテンシー）とのバランス検討が必要
- 対話的な解決：確実性は高いが、ユーザー目線での高度なUX設計が求められる
どの手法を選択するかは、求められる回答品質、許容できるコストとレイテンシーのトレードオフによって決まります。 いずれの手法をとるにせよ、実運用において曖昧なクエリへの対応は重要な課題です。まずはシンプルな手法からスモールステップで検証を重ね、プロダクトに最適な形を模索していくのが望ましいでしょう。
最後に、キャディでは現在エンジニアを絶賛採用中です。本記事を読んで興味を持ってくれた方はぜひご連絡ください。ここには面白い課題が沢山あります。
