RAG 09：質問を直す ― 探す前に、質問を検索向きにする

質問が検索に向かない、4つの理由

利用者の質問が検索に向かない理由は、主に4つあります。

3つ目の「言葉が違う」は、語彙のずれとも呼ばれ、検索の古くからの悩みです。利用者は日常の言葉で聞き、資料は正式な言葉で書かれています。「パソコンが壊れた」と聞かれても、資料の題名は「PC 故障時の手続き」かもしれません。

埋め込み（第4章）による意味の検索は、この語彙のずれにある程度強くなりました。それでも、質問が短すぎたり、「それ」のような言葉しかなかったりすると、意味の検索でも手がかりが足りません。

人は会話のつもりで聞きます。一方、検索は「資料と同じ言葉で、はっきり聞かれる」のを待っています。そのすき間を埋めるのが、この章の工夫です。

一言でいうと：探す前に、質問を検索向きに直す

この章の工夫は、一言でいうと「探す前に、LLM に検索用の問いを作らせる」です。

図の舞台を見てください。左が利用者の元の質問、真ん中が書き直しを担当する LLM、右が検索に使う問い、その先が検索です。この形は、この章でずっと使います。ページごとに変わるのは、左の質問と、右に出てくる問いだけです。

「有給って何日？」は、「年次有給休暇の付与日数」に書き直されました。資料で使われていそうな、正式で具体的な言葉になっています。

大事な約束が1つあります。書き直すのは、検索に使う問いだけです。最後に答えを作るときは、利用者の元の質問をそのまま LLM に見せます（第8章）。書き直しの途中で意味が少しずれることがあるので、答えまでずれた問いで作ると、利用者の聞きたかったことからずれてしまうからです。

この考え方は、2023年の論文で「Rewrite-Retrieve-Read」（書き直す → 探す → 読む）と名付けられて整理されています。RAG の基本形「探す → 読む」の前に、書き直しを1段足した形です。

会話の書き直し：「それ」を具体的な言葉に戻す

チャット形式の RAG では、この書き直しがほぼ必須です。会話の2回目以降の質問は、たいてい前の会話を前提にしているからです。

図の上に、会話の履歴があります。利用者は最初に有給休暇について聞き、AI が答え、次に「それって2年目だと何日？」と聞きました。この質問を単独で検索しても、有給休暇の資料は見つかりません。

そこで、直前の会話と今の質問を LLM に渡し、それだけで意味が通る1文に書き直させます。結果は「入社2年目の年次有給休暇の付与日数」。これなら検索できます。

会話の書き直しでは、次の点に気をつけます。

この処理は、会話の要約（condense＝ぎゅっと縮める）と呼ばれることもあります。多くの RAG のライブラリに、会話の履歴を踏まえて質問を書き直す部品が用意されています。

複数の言い方で探す（マルチクエリ）

マルチクエリは「複数（マルチ）の問い（クエリ＝検索に使う問いのこと）」という意味です。言葉のずれに対する、もう1つの手は「1つの言い方に賭けない」ことです。

LLM に、同じ意味の問いを複数（たとえば3つ）作らせます。図では「年次有給休暇の付与日数」「有給 何日 もらえる」「年休 入社初年度 日数」の3つです。資料が正式な言葉で書かれていても、くだけた言葉で書かれていても、どれかが当たりやすくなります。

3つの問いでそれぞれ検索すると、3つの結果の一覧ができます。これを1つにまとめるには、第6章で見た RRF（順位の逆数を足し合わせる方法）が使えます。複数の問いで何度も上位に出てくる資料ほど、本当に関係がありそうだ、という考え方です。この組み合わせは「RAG-Fusion」という名前で紹介されることもあります。

検索は並行して実行できるので、時間はそれほど増えないこともあります。ただ、料金や検索エンジンの負荷は、問いの数だけ増えます。

HyDE：仮の答えを書かせて、その文で探す

少し意外な方法があります。質問で探すのではなく、LLM に仮の答えを書かせて、その答えの文で探すのです。

この方法は HyDE（Hypothetical Document Embeddings、仮の文書の埋め込み。「ハイド」と読まれます）と呼ばれ、2022年に論文で発表されました。仮の答えを第4章の埋め込みで意味の地図の点にし、その点の近くにある本物の資料を探す、という流れです。

なぜこれが効くのでしょうか。資料は「答えの形」で書かれています。「入社6か月後に10日の年次有給休暇を付与する」のように。一方、質問は「有給って何日？」という「問いの形」です。意味の検索（第4・5章）では、形の似た文どうしのほうが近くなりやすいので、問いより仮の答えのほうが、本物の資料に近づけるのです。

大事なのは、仮の答えの中身は間違っていてよいことです。LLM はこの会社の規程を知らないので、「半年で10日」かもしれないし「20日」と書くかもしれません。でも、探すための「えさ」として使うだけなので、中身が正しい必要はありません。答えそのものは、見つかった本物の資料から作ります。

弱点もあります。仮の答えを書かせる時間がかかります。また、LLM が全く知らない分野（社内の独自の用語など）では、的外れな仮の答えになり、かえって外れることがあります。自分の資料で効くかどうかは、評価（第12章）で確かめます。

分解：1つの質問を、探せる小さな問いに分ける

「A製品とB製品、保証期間が長いのはどっち？」という質問を考えます。答えるには、A製品の保証期間と、B製品の保証期間の両方が必要です。でも、この2つはたいてい別々の資料（それぞれの製品マニュアル）に書かれています。

1回の検索では、片方の資料しか上位に来ないかもしれません。そこで、LLM に質問を小さな問いに分解させます。「A製品の保証期間」と「B製品の保証期間」。それぞれで探し、見つかった資料を両方まとめて LLM に渡せば、比べて答えられます。

分解が効く質問には、いくつかの形があります。

最後の「つなぐ」形は、少し難しくなります。1つ目の答え（私の部署はどこか）が分からないと、2つ目の問いが作れないからです。このように、答えを順にたどる必要がある質問は多段の質問（マルチホップ＝何度か飛び石を渡るように答えをたどる）と呼ばれます。探した結果を見てから次の問いを考える必要があるので、最初に一度分解するだけでは足りません。これは第11章のエージェント型 RAG で扱います。

振り分け：どこを探すか、そもそも探すか

資料がたくさんあると、索引（第5・6章で見た、速く探すための仕組み。ここでは「探す対象の資料のまとまり」くらいに考えてください）を種類ごとに分けることがあります。社内規程の索引、製品マニュアルの索引、過去の問い合わせ履歴の索引、といった具合です。

そうすると、「この質問はどの索引を探すべきか」を決める必要が出てきます。これが振り分け（ルーティング）です。図では、「ノートPCの保証は何年？」を、製品マニュアルの索引に振り分けています。

振り分けには、もう1つ大事な役目があります。探さないという判断です。

「ありがとう」で検索しても、関係ない資料が集まり、LLM がそれに引きずられて変な返事をするだけです。探す必要のない質問は、探さないほうが速く、正確です。

振り分けは、LLM に「次のどれに当たるか」を選ばせる方法が手軽です。弱点は、振り分けを間違えると、正しい索引を一度も探さないことです。迷ったら複数の索引を探す、という逃げ道を用意しておくと安全です。

絞り込み：「去年」を日付の条件に変える

「去年の営業部の経費精算の締め日は？」という質問を考えます。

意味の検索は、「去年」や「営業部」を条件として扱うのが苦手です。「去年」という言葉の意味に近い資料を探しても、2025年の資料だけが出てくるわけではありません。2019年の資料も、2026年の資料も、同じように並びます。

そこで、質問から条件を取り出して、絞り込みに変えます。

多くのベクトルデータベースは、資料に付けたメタデータ（年・部署・製品名などの付加情報）で絞り込みながら検索できます（第5章）。条件で候補を先に絞れば、別の年や別の部署の資料が混ざりません。

2つ注意があります。1つ目は、「去年」を年に直すには、今日の日付を LLM に渡す必要があることです。渡さないと、LLM は学習したころの年を基準に、当てずっぽうで決めてしまいます。2つ目は、条件に使う項目を、資料の側にも持たせておく必要があることです。資料に年や部署が付いていなければ、絞り込めません。これは資料を準備する段階（第3章）の仕事です。

作ってみる：書き直しを1回の呼び出しで

ここまでの工夫は、別々の LLM 呼び出しにすると遅くなります。実際には、1回の呼び出しで、まとめて作らせることが多いです。

図のコードは、その形を説明用に書いたものです（llm.json・searchAll・generate は仮の関数です）。

返してもらう形を JSON で決めておく（第8章の構造化出力）と、プログラムでそのまま使えます。

Python で、同じ流れを短く書くと次のようになります。

plan = llm_json(
    system=f"検索に使う問いを作る係です。今日は {today} です。",
    input={"history": history[-6:], "question": question},
    schema={"queries": "list[str]", "year": "int | None"},
)
hits = search_all(plan["queries"], year=plan["year"])
answer = generate(question, hits)  # 答えには元の質問を渡す

1行ずつ読むと、こうです。1つ目の llm_json(…) は、LLM に「今日の日付」と「直近6発言（3往復）の会話」と「今の質問」を渡し、検索用の問いの一覧（queries）と年の条件（year、無ければ None）を決まった形で返してもらいます。2つ目の search_all(…) は、その問いを全部使い、年で絞って探します。3つ目の generate(…) で答えを作ります。

最後の行に注目してください。答えを作るときには、書き直した問いではなく、元の質問を渡しています。

書き直しは、答えを作るほどの賢さは要らない、比較的やさしい仕事です。そのため、答えを作るモデルより小さく速いモデルで十分なことが多く、時間と料金を抑えられます。

限界とトレードオフ：1回ぶん遅く、高くなる

何かを得れば何かを払う、という取り引き（トレードオフ）を見ます。質問を直す工夫には、共通の代償があります。LLM の呼び出しが1回増えることです。利用者から見ると、答えが返ってくるまでの時間が、その分だけ延びます。

それぞれの技の、得るものと払うものを並べます。

どれを使うかは、「どんな質問が多いか」で決めます。チャット形式なら会話の書き直しはほぼ必須です。比べる質問が多いなら分解、日付の条件が多いなら絞り込み、というように、困っている失敗に合わせて選びます。全部を重ねると、1つの質問に何秒もかかるようになります。

効いたかどうかは、書き直しの前と後で、「正しい資料が上位に入った割合」を比べて確かめます（第12章）。

よくある落とし穴

質問を直す工夫で、よく起きる失敗をまとめます。

いちばん気づきにくいのは、1つ目の「意味が変わる」です。書き直しの結果は利用者の画面に出ないので、誰も気づかないまま、的外れな検索が続きます。

書き直した問いをログ（記録）に残し、ときどき人が見る習慣を付けましょう。元の質問と書き直した問いを並べて眺めるだけで、「この種類の質問はいつも意味が変わっている」といった癖が見えてきます。

他の章とのつながり

この章の工夫は、「探す」の入口にあたります。他の章との関係をまとめます。

特に第11章とのつながりは深いです。この章の書き直しは、「探す前に一度だけ」問いを作ります。第11章のエージェント型 RAG では、LLM が探した結果を読んでから、次に何を探すかを決めることを繰り返します。分解の「つなぐ」形のような、一度では問いを作りきれない質問に向いています。