クエリ拡張は長年、検索システムを強化するための主要な手法でしたが、semantic embeddings が登場してからは注目度が下がっています。RAG やエージェント検索が主流の現在では時代遅れと思われるかもしれませんが、まだ捨てたものではありません。この詳細な分析では、自動クエリ拡張と jina-embeddings-v3 および LLM を組み合わせることで、検索性能を向上させ、より的確な結果を得られる方法を探ります。
tagクエリ拡張とは？
クエリ拡張は、tf-idf やその他の「スパースベクトル」方式のように、クエリの単語とそれを含む文書とのマッチングで関連性を判断する検索システム向けに開発されました。これには明らかな制限があります。「ran」と「running」、または「optimise」と「optimize」のように、単語の変形形がマッチングを妨げます。言語を考慮した前処理でこれらの問題の一部は緩和できますが、すべてではありません。専門用語、同義語、関連語はさらに対処が困難です。例えば、「coronavirus」に関する医学研究の検索では、非常に良いマッチとなるはずの「COVID」や「SARS-CoV-2」について言及している文書を自動的に特定できません。
クエリ拡張はこの解決策として発明されました。
アイデアは、良いマッチを見つける可能性を高めるために、クエリに追加の単語やフレーズを加えることです。このようにして、「coronavirus」のクエリに「COVID」や「SARS-CoV-2」という用語が追加され、検索性能を大幅に向上させることができます。
クエリにどの用語を追加すべきかを決めるのは簡単ではなく、tf-idf スタイルの検索に適した用語の特定方法や重み付けについて多くの研究がなされてきました。一般的なアプローチには以下があります：
- 人手で作成されたシソーラスの使用
- 大規模テキストコーパスから関連語を抽出するデータマイニング
- クエリログから類似クエリで使用された他の用語の特定
- ユーザーフィードバックから良いクエリ拡張となる単語やフレーズを学習
しかし、semantic embedding モデルはクエリ拡張の必要性を排除するはずでした。「coronavirus」、「COVID」、「SARS-CoV-2」の良好なテキスト埋め込みは、埋め込みベクトル空間で非常に近い位置にあるはずです。拡張なしで自然にマッチするはずです。
ただし、理論的にはそうあるべきですが、実際のモデルによって作成される実際の埋め込みは往々にして期待に及びません。埋め込みの単語は曖昧である可能性があり、適切な単語をクエリに追加することで、より良いマッチに導くことができます。例えば、「skin rash」の埋め込みは、「dermatitis」について言及する医学論文を見逃しながら、「behaving rashly」や「skin creme」に関する文書を特定してしまうかもしれません。関連する用語を追加することで、無関係なマッチから離れ、より良いマッチに向かう可能性が高くなります。
tagLLM クエリ拡張
シソーラスを使用したり語彙データマイニングを行ったりする代わりに、私たちは LLM を使用してクエリ拡張を行うことを検討しました。LLM には以下のような重要な潜在的利点があります：
- 幅広い語彙知識：大規模で多様なデータセットで訓練されているため、適切なシソーラスの選択や適切なデータの取得について心配する必要が少なくなります。
- 判断能力：提案される拡張用語がすべて特定のクエリに適切とは限りません。LLM は完璧な判断を下せないかもしれませんが、他の方法ではそもそも判断を下すことができません。
- 柔軟性：検索タスクのニーズに応じてプロンプトを調整できますが、他のアプローチは硬直的で、新しいドメインやデータソースに適応させるには多くの作業が必要になる可能性があります。
LLM が用語リストを提案すると、埋め込みのためのクエリ拡張は従来のクエリ拡張方式と同じように動作します：クエリテキストに用語を追加し、埋め込みモデルを使用してクエリ埋め込みベクトルを作成します。
これを実現するために必要なものは：
- LLM へのアクセス
- LLM から拡張用語を取得するためのプロンプトテンプレート
- テキスト埋め込みモデル
tag試してみる
このアプローチがテキスト情報検索に価値を追加するかどうかを確認するために、いくつかの実験を行いました。テストでは以下を使用しました：
- 1つの LLM：Google の Gemini 2.0 Flash
- LLM クエリ拡張がモデル間で一般化できるかを確認するための2つの埋め込みモデル：jina-embeddings-v3 と
all-MiniLM-L6-v2 - 情報検索のための BEIR ベンチマークのサブセット
実験は2つのプロンプト条件で実施しました：
- 拡張用語を取得するための一般的なプロンプトテンプレートの使用
- タスク固有のプロンプトテンプレートの使用
また、追加する用語数（100、150、250）を変えてプロンプトを作成しました。
コードと結果は GitHub で公開しており、再現可能です。
jina-ai
tag結果
tag一般的なプロンプトの使用
試行錯誤の結果、以下のプロンプトが Gemini 2.0 Flash で十分に機能することがわかりました：
Please provide additional search keywords and phrases for each of the key aspects of the following queries that make it easier to find the relevant documents (about {size} words per query): {query} Please respond in the following JSON schema: Expansion = {"qid": str, "additional_info": str} Return: list [Expansion]
このプロンプトにより、クエリを20～50のバンドルでバッチ処理し、各クエリに ID を付け、各クエリを拡張用語のリストに接続する JSON 文字列を返すことができます。別の LLM を使用する場合は、それに適したプロンプトを見つけるために実験が必要かもしれません。
この設定を jina-embeddings-v3 に 非対称検索アダプターを使用して適用しました。このアプローチでは、クエリと文書は異なる方法でエンコードされます — 同じモデルを使用しますが、異なる LoRA 拡張を使用して — 情報検索のための埋め込みを最適化します。
様々な BEIR ベンチマークでの結果を以下の表に示します。スコアは nDCG@10（検索された上位10項目における正規化割引累積利得）です。
| ベンチマーク | 拡張なし | 100用語 | 150用語 | 250用語 |
|---|---|---|---|---|
| SciFact （ファクトチェックタスク） |
72.74 | 73.39 | 74.16 | 74.33 |
| TRECCOVID （医療検索タスク） |
77.55 | 76.74 | 77.12 | 79.28 |
| FiQA （金融オプション検索） |
47.34 | 47.76 | 46.03 | 47.34 |
| NFCorpus （医療情報検索） |
36.46 | 40.62 | 39.63 | 39.20 |
| Touche2020 （議論検索タスク） |
26.24 | 26.91 | 27.15 | 27.54 |
ここでは、クエリ拡張がほぼすべてのケースで検索性能を向上させていることがわかります。
このアプローチの堅牢性をテストするため、より小さな埋め込みベクトルを生成する、はるかに小さなモデル all-MiniLM-L6-v2 で同じテストを繰り返しました。
以下の表に結果を示します：
| Benchmark | No Expansion | 100 terms | 150 terms | 250 terms |
|---|---|---|---|---|
| SciFact (Fact Checking Task) |
64.51 | 68.72 | 66.27 | 68.50 |
| TRECCOVID (Medical Retrieval Task) |
47.25 | 67.90 | 70.18 | 69.60 |
| FiQA (Financial Option Retrieval) |
36.87 | 33.96 | 32.60 | 31.84 |
| NFCorpus (Medical Information Retrieval) |
31.59 | 33.76 | 33.76 | 33.35 |
| Touche2020 (Argument Retrieval Task) |
16.90 | 25.31 | 23.52 | 23.23 |
ここでは、検索スコアのさらに大きな改善が見られます。全体的に、小さなモデルの方がクエリ拡張からより大きな恩恵を受けました。すべてのタスクにおける平均的な改善は以下の表にまとめられています：
| Model | 100 terms | 150 terms | 250 terms |
|---|---|---|---|
| jina-embeddings-v3 | +1.02 | +0.75 | +1.48 |
all-MiniLM-L6-v2 |
+6.51 | +5.84 | +5.88 |
2つのモデル間の正味の改善の大きな違いは、all-MiniLM-L6-v2 の初期性能が低かったことによると考えられます。非対称検索モードにおける jina-embeddings-v3 によって生成されるクエリ埋め込みは、主要な意味的関係をより良く捉えることができるため、クエリ拡張が情報を追加する余地が少なくなります。しかし、この結果は、大規模モデルよりも小規模モデルが好ましい場合があることを示しており、クエリ拡張によってそのような小規模モデルの性能がどれだけ向上するかを示しています。
それでもなお、jina-embeddings-v3 のような高性能モデルでも、クエリ拡張は検索に意味のある改善をもたらしましたが、この結果はすべてのタスクと条件で完全に一貫しているわけではありません。
jina-embeddings-v3 の場合、FiQA と NFCorpus のベンチマークでは、クエリに 100 個以上の用語を追加することは逆効果でした。より多くの用語が常に良いとは言えませんが、他のベンチマークの結果は、より多くの用語が少なくとも時には効果的であることを示しています。
all-MiniLM-L6-v2 の場合、150 個以上の用語を追加することは常に逆効果でした。3つのテストでは、100 個以上の追加は性能を向上させませんでした。1つのテスト（FiQA）では、100 個の用語を追加しただけでも結果が大幅に低下しました。これは、jina-embeddings-v3 が長いクエリテキストの意味情報をより良く捉えることができるためだと考えています。
両モデルとも、FiQA と NFCorpus のベンチマークではクエリ拡張への反応が小さくなりました。
tagタスク固有のプロンプトの使用
上記の結果のパターンは、クエリ拡張が有用である一方で、LLM を使用すると性能を低下させる不適切なクエリ用語が追加されるリスクがあることを示唆しています。これはプロンプトの一般的な性質に起因している可能性があります。
私たちは SciFact と FiQA という2つのベンチマークを取り上げ、以下のようなよりドメイン固有のプロンプトを作成しました：
Please provide additional search keywords and phrases for each of the key aspects of the following queries that make it easier to find the relevant documents scientific document that supports or rejects the scientific fact in the query field (about {size} words per query): {query} Please respond in the following JSON schema: Expansion = {"qid": str, "additional_info": str} Return: list [Expansion]
このアプローチは、ほぼすべての面で検索性能を向上させました：
| Benchmark | Model | No Expansion | 100 terms |
150 terms |
250 terms |
|---|---|---|---|---|---|
| SciFact | jina-embeddings-v3 | 72.74 | 75.85 (+2.46) | 75.07 (+0.91) | 75.13 (+0.80) |
| SciFact | all-MiniLM-L6-v2 |
64.51 | 69.12 (+0.40) | 68.10 (+1.83) | 67.83 (-0.67) |
| FiQA | jina-embeddings-v3 | 47.34 | 47.77 (+0.01) | 48.20 (+1.99) | 47.75 (+0.41) |
| FiQA | all-MiniLM-L6-v2 |
36.87 | 34.71 (+0.75) | 34.68 (+2.08) | 34.50 (+2.66) |
all-MiniLM-L6-v2 で SciFact クエリに 250 個の用語を追加した場合を除き、すべての条件で性能が向上しました。さらに、この改善は all-MiniLM-L6-v2 が FiQA での自身のベースラインを上回るには十分ではありませんでした。
jina-embeddings-v3 の場合、最良の結果は 100 または 150 個の追加用語で得られました。250 個の用語を追加することは逆効果でした。これは、特に用語の意味が目標から離れ始めると、クエリに追加する用語が多すぎる可能性があるという私たちの直感を裏付けています。
tagクエリ拡張における重要な考慮事項
クエリ拡張は明らかに埋め込みベースの検索に利点をもたらしますが、いくつかの注意点があります：
tagコスト
LLM との対話は情報検索にレイテンシーと計算コストを追加し、商用 LLM を使用する場合は実際のコストが発生する可能性があります。この程度の改善では、そのコストを正当化できない場合があります。
tagプロンプトエンジニアリング
良いプロンプトテンプレートの設計は経験的で実験的な技術です。この研究で使用したものが最適であるとか、他の LLM に移植可能であるとは主張しません。タスク固有のプロンプトに関する実験は、プロンプトの変更が結果の品質に非常に大きな影響を与える可能性があることを示しています。また、結果はドメインによって大きく異なります。
これらの不確実性は開発コストを増加させ、保守性を低下させます。システムの変更（LLM、埋め込みモデル、情報ドメインの変更）は、プロセス全体の再確認と場合によっては再実装を必要とします。
tag代替案
ここでは、クエリ拡張が最も大きな改善をもたらしたのは、初期性能が最も低い埋め込みモデルでした。少なくともこの実験では、クエリ拡張は all-MiniLM-L6-v2 と jina-embeddings-v3 の性能差を埋めることはできませんでした。一方、jina-embeddings-v3 はクエリ拡張からより控えめな改善を得ました。
このような状況では、all-MiniLM-L6-v2 のユーザーは、クエリ拡張を追求するよりも jina-embeddings-v3 を採用する方が、より低コストでより良い結果が得られるでしょう。
tag今後の方向性
ここでは、クエリ拡張がクエリ埋め込みを改善できること、そして LLM が良いクエリ拡張用語を得るためのシンプルで柔軟な手段を提供することを示しました。しかし、比較的控えめな改善は、さらなる研究が必要であることを示唆しています。私たちは以下のような方向性を検討しています：
- 文書埋め込みの生成における用語強化の価値のテスト。
- リランキングなどの他の AI 検索技術におけるクエリ強化の可能性の検討。
- シソーラスのような、より計算コストの低い従来の用語ソースと LLM ベースのクエリ拡張の比較。
- クエリ拡張に特化した言語モデルのトレーニングと、より領域特化したトレーニングの提供。
- 追加する用語数の制限。100 個では最初から多すぎる可能性があります。
- 有用な拡張用語と不適切な拡張用語を識別する方法の探索。クエリ拡張に設定する固定数は完璧な解決策とはならず、提案された用語を動的に評価して良い用語のみを保持できれば、性能の向上が見込めます。
これは非常に初期段階の研究であり、このような技術が Jina AI の検索基盤製品にさらなる改善をもたらすことを期待しています。
