要約

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 では、生成した共通ルールや提案から画像検索用のクエリを作り、画像検索で「たとえばこんな服」に近い例へつなげています。画像そのものを生成するのではなく、抽出したルールを現実の画像例へ接続するための機能です。

GitHub: https://github.com/mofuteq/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