クエリ変換 — 質問と文書の言葉のずれを埋める

ユーザーは「なんか遅いんだけど」と聞き、文書には「レイテンシの悪化要因とチューニング指針」と書かれている。この2つを埋め込んで内積を取っても、うまく近づきません。検索が外れる原因の多くはコーパスの不足ではなく、質問と文書の言葉のずれにあります。

チャンク分割が文書側を検索しやすく整える工程だとすれば、クエリ変換は質問側を文書に寄せる工程です。

横にスクロール

ずれには種類がある

手法を選ぶ前に、どのずれが起きているかを見分けます。

HyDE：仮の回答を書かせて、それで検索する

HyDE（Hypothetical Document Embeddings） は発想の転換です。質問を検索クエリにする代わりに、LLMに仮の回答を書かせ、その回答文で検索します。

元の質問  : 「なんか遅いんだけど」

LLMに仮回答を生成させる
  「レスポンスが遅い原因としては、データベースのクエリ実行時間、
    ネットワークのレイテンシ、キャッシュのヒット率低下などが
    考えられます。まず各層の処理時間を分解して…」

この仮回答を埋め込んで検索する
  → 「レイテンシ」「クエリ実行時間」「キャッシュヒット率」といった
     文書と同じ語彙・同じ文体になるため、正しく近傍が引ける

ここが直感に反するところですが、仮回答の事実が間違っていても構いません。必要なのは「その話題の文書がどんな語彙と文体で書かれているか」という当たりであって、内容の正確さではありません。生成した仮回答は検索にだけ使い、最終的な回答は実際に引いた文書から作ります。

マルチクエリ：言い換えを複数投げる

同じ意図でも聞き方はいくつもあり、どの言い方をするかで結果が変わるのは望ましくありません。マルチクエリは、LLMに元の質問の言い換えを3〜5本作らせ、それぞれで検索して結果を統合します。

元の質問: 「認証が失敗する原因は？」

生成した言い換え
  1. ログインできない場合のトラブルシューティング
  2. 認証エラーの一般的な原因と対処法
  3. トークンの検証に失敗するケース

3本それぞれで検索 → RRFで統合 → 上位を採用

統合に RRF を使うのは、ハイブリッド検索と同じ理由です。複数の言い換えから支持された文書が上に来るという投票的な性質が働き、1本の言い方に依存しなくなります。

クエリ分解：話題ごとに分けて引く

「AとBの違いと、それぞれの設定方法を教えて」のような質問は、1本のベクトルにすると A と B の中間の曖昧な位置に落ちます。クエリ分解は、これを独立した副質問へ分けます。

元の質問: 「トークンバケットとリーキーバケットの違いと、
            それぞれの設定方法は？」

分解
  1. トークンバケットの仕組み
  2. リーキーバケットの仕組み
  3. トークンバケットの設定パラメータ
  4. リーキーバケットの設定パラメータ

各副質問で検索 → 結果をまとめて文脈に入れる

副質問ごとに文書を引くので、すべての話題について十分な文脈が揃います。1本のクエリでは、たいてい片方の話題の文書ばかりが上位を占めます。

分解には逐次的な形もあります。「Xを作った会社の本社はどこ？」のように、前段の答えが次の検索に必要な場合は、1つ目を解いてから2つ目のクエリを組み立てます。これはReActのような推論と行動のループと地続きで、自己改善型RAGの話題につながります。

ステップバック：一段抽象化して聞き直す

細かすぎる質問は、細かすぎる文書しか引けません。ステップバックプロンプティングは、元の質問から一段抽象度を上げた質問を作り、両方で検索します。

元の質問       : 「N+1問題が起きたとき、eager loading の
                  設定はどう書けばいい？」
ステップバック : 「ORMにおけるN+1問題とは何か、どう解決するか」

両方で検索して統合
  → 具体的な設定例と、前提となる原理の両方が文脈に入る

原理を説明した文書が入ることで、LLMが設定例を正しく解釈して応用できるようになります。具体例だけを渡すと、状況が少し違うだけで誤った適用をしがちです。

会話履歴からの書き換え（最も見落とされる）

マルチターンの対話では、質問が単独では意味をなさないことが大半です。

ユーザー: 「レートリミッタの設計を教えて」
アシスタント: （回答）
ユーザー: 「それの分散環境版は？」   ← 「それ」が解決できないと検索は必ず外れる

検索の前に、会話履歴を使って質問を自己完結な形に書き換える工程が要ります。

書き換え後: 「レートリミッタを分散環境で実装する場合の設計」

これは技術的には最も単純ですが、入れ忘れによる被害が最も大きい工程です。チャット形式のRAGで「2回目以降の質問から急に精度が落ちる」なら、まずここを疑ってください。

まとめ

• 検索が外れる主因は質問と文書の言葉のずれ。手法を選ぶ前に、どの種類のずれかを見分ける。
• HyDE は仮の回答をLLMに書かせて検索する。事実は間違っていてよく、必要なのは文書と揃った語彙と文体。知識の無い領域では逆効果になりうるので元クエリの結果とRRFで統合すると安全。
• マルチクエリは言い換えの揺れに、クエリ分解は複数話題に、ステップバックは抽象度不足に効く。
• 会話履歴からの書き換えは技術的に最も単純だが、入れ忘れの被害が最も大きい。2回目以降の質問で精度が落ちるならまずここ。
• どれもLLM呼び出しが増える。失敗クエリを分類してから必要な手だけを入れる。