要約
RAG を作っていて「検索したのに欲しい情報が出ない」とき、Vector DB や embedding model 、reranker を見直しがちです。でも、実装していて最初に踏んだのはそこではなく、ユーザーの入力をそのまま検索クエリにしていたことでした。本記事は、trend-to-rule という小さな実装で踏んだ「検索クエリ設計のズレ」の記録です。
踏んだズレ：user prompt をそのまま retrieval query にしていた
trend-to-rule は、流行記事から「共通ルール」を抽出し、それをユーザーが次に見られる形へ戻す実験です。
ここで最初、ユーザーの入力をそのまま検索に使っていました。たとえば、
今っぽいけど浮かない服が知りたい
これは入力としては自然です。でも、検索クエリとしては遠い。
理由は単純で、ユーザーの言葉は「欲しい答えの表現」であって、LLM が回答するために必要な evidence の表現とは限らないからです。検索したいのは、その文そのものではなく、その答えを作るために必要な evidence です。
だから、間に一つ変換を置く必要がありました。
user prompt
→ search intent
→ retrieval query
同じズレが、画像検索でも起きた
trend-to-rule では、抽出した共通ルールを「たとえばこんな服」と画像で見せたかった。そこで、共通ルールをそのまま画像検索に投げた。
落ち着いたベースカラーに、少しゆとりのあるシルエットを合わせる
でも、欲しい画像には届かなかった。共通ルールは判断のための抽象化であって、画像検索に必要なのは色・アイテム・シルエット・スタイル名のような視覚的な手がかりだからです。
つまり、こういう変換が要りました。
共通ルール
→ visual search intent
→ image search query 例: navy relaxed shirt gray wide trousers minimal outfit
→ real examples
一般化すると
user prompt も、共通ルールも、そのまま検索クエリではない。どちらも、間に「検索意図への変換」が必要だった。
ここを同一視すると、起きることは一つです。検索結果を見ながら調整しているつもりで、実際には作った人が横で見て、言い換えて、検索し直している。検索意図の変換を、手作業で補っているだけになります。
だから、変換を Runtime 側の責務として明示的に持つ。それが、この実装で一番効いたところでした。
実装
trend-to-rule では、生成した共通ルールや提案から画像検索用のクエリを作り、画像検索で「たとえばこんな服」に近い例へつなげています。画像そのものを生成するのではなく、抽出したルールを現実の画像例へ接続するための機能です。
もう少し体系的に見たい場合
この「user prompt をそのまま検索クエリにしない」という話は、検索クエリだけでなく retrieved evidence、failure mode、rerank、共通ルール、output boundary まで、RAG の責務を順に分けて Zenn 本にまとめました。本記事はその入口にあたる検索クエリ設計の各論です。
- 元記事（Zenn）: https://zenn.dev/mofuteq/articles/2c5ca06a689140
- Zenn本『検索結果を増やす前に見るRAG設計』: https://zenn.dev/mofuteq/books/a2fff004033f5b