検索だけで終わらせない——RAG時代の“質問力”
生成AIの強さは、問いの立て方に比例します。
RAG（Retrieval Augmented Generation）は検索結果を文脈に編み込み、LLMに“考えさせる”仕組みです。
しかしプロンプトを磨かないままでは、追加したデータがノイズとなり、ハルシネーションがむしろ増えることも。
本記事では、2025年上半期に登場した最新テクニックを交えつつ、データ品質からプロンプト設計、運用までを一気通貫で解説します。
RAGの基本を30秒でおさらい
パイプライン全体像
RAGは大きく①データ準備 → ②インデックス作成 → ③検索（Retriever） → ④生成（LLM）の4段構成。
従来の「いい感じのプロンプトを投げる」だけの世界から、検索精度と生成精度の二層最適化へ発展しました。
- Retriever：クエリを捌き、関連ドキュメントを数十〜数百 ms で返す
- Generator：返ってきた文脈を読み解き、整合性の高い回答を生成
ポイントは“どこまでをプロンプトで制御し、どこからをシステムで補完するか”。
後述する最適化では、この分業を明確にしながら改善ループを回します。
なぜデータ品質が9割を決めるのか
高精度回答の前提条件
RAGの精度向上記事の多くがチャンキングやエンベディングモデルに触れていますが、その手前にあるのが“データの真偽と粒度”。
2024年末にSoftBank Tech Blogが社内FAQで75％→93％へ正答率を高めた例では、検索対象のHTMLから冗長な広告タグを排除し、段落単位の正規化を徹底した
と報告されています。
- 重複文書を除去し、IDでバージョン管理
- 改行やリストタグを保ったままテキスト抽出
- JSON Schemaでメタデータ（部署・更新日など）を付与
ここまで整備すると、Retrieverはキーワード一致に頼らずとも文脈的に“近い”情報を取りやすくなります。
結果としてプロンプトは“検索品質”を前提にシンプル化でき、LLMの推論コストを平均17％削減した事例も確認されています。
プロンプト設計：Retrieverまでをクエリとして捉える
最新ベストプラクティス
2025年春にIBM Thinkが公開した解説では、prompt engineering と RAG の連携を
Query prompt → Context prompt → Answer promptの三部構成で説明しています。
本記事ではさらに、Retriever側で扱うクエリをプロンプトとしてモデルに最適化する以下のテクニックを推奨します。
- 合成クエリ：ユーザ質問を再パラフレーズし、情報密度を高めた検索文を作る
- Negative Prompting：除外したい文脈を“NOT keywords”として与えハルシネーション抑止
- Role Tagging：『あなたは◯◯の専門家』をRetrieverにも渡し、業界用語の同義語展開を支持
これにより、RetrieverとGeneratorが同一コンテキストを共有。
ベクトル検索のヒット率が平均4〜8ポイント向上し、LLMの温度を上げても破綻しにくくなります。
サンプルプロンプト断片
以下はNode + LangChainで実装する際の一例です（簡略化）。
<QUERY_PROMPT>
UserQuestion:"{question}"
Role:"Senior Data Analyst"
Instruction:"Rewrite the question into an exhaustive search query. Remove ambiguous terms."
Exclude:"pricing, campaign"
</QUERY_PROMPT>
生成されたsearch_queryをRetrieverに渡し、得た文脈を次のContext Promptへ連鎖させます。
最適化ワークフロー：評価→改善→自動化
オフライン評価
まずはGround Truthを100問ほど用意し、BLEU/ROUGEではなくLLMベース評価で比較。
GPT-5 TurboによるCritique APIが登場し、自然言語で評価テンプレートを書けるため、実装は数行で済みます。
オンラインA/Bテスト
本番環境では、フェールセーフ回路を挟んで2種類のプロンプトをランダム割り当て。
CTRだけでなくユーザの再質問率（Re-Ask Rate）を指標にし、“迷わせない回答”を定量化します。
自動リライトループ
評価結果はGitHub ActionsでJSONに書き出し、新しいプロンプトの候補をLLMが自動生成。
一定スコアを超えたもののみPRを作成し、人間がレビューしてマージする流れが主流です。
この運用で、月次リリースから週次リリースへ高速化したケースが増えています。
よくある落とし穴と対策
- ドキュメントの粒度がまちまち
→ 段落単位でIDを振り、300〜500文字を目安にチャンク化。 - RetrieverとGeneratorでトークナイザが違う
→ 多言語対応の場合は、同一SentencePieceモデルを共有。 - メタデータをプロンプト内に過剰に記載
→ 必要な属性だけembeddingに含め、プロンプトではtitle, updated_at程度に絞る。
これらの対策はZenn記事『RAGの精度改善手法』でも詳細が語られています。
“シンプルさ”こそが最速のデバッグ手段という点は、今も昔も変わりません。
まとめ：今日から始めるアクションリスト
RAGプロジェクトはデータ整備60％・プロンプト30％・評価10％が工数配分の目安です。
以下のチェックポイントを押さえれば、来週には精度改善の手応えを得られるはず。
- 社内ドキュメントを段落単位で一括クレンジング
- Query Prompt / Context Prompt / Answer Prompt の三層分離
- LLMベース自動評価をCIに組み込み、スコア推移をダッシュボード化
- Re-Ask Rateを行動指標としてA/Bテストを常時実施
RAGはまだ進化の途中にあります。
“質問力とデータ品質”を磨き続けるチームだけが、次のLLMアップデートを最速で取り込めるでしょう。
コメント