查詢擴展長期以來一直是提升搜索系統效能的重要技術，儘管自從語義嵌入出現後，它的地位有所下降。雖然在當前 RAG 和代理搜索的環境下，有些人可能認為它已經過時，但不要過早下定論。在這次深入探討中，我們將探索如何將自動查詢擴展與 jina-embeddings-v3 和 LLM 結合，以提升您的搜索效果並提供更精準的結果。
tag什麼是查詢擴展？
查詢擴展最初是為那些通過匹配查詢詞與文檔內容來判斷相關性的搜索系統開發的，比如 tf-idf 或其他「稀疏向量」方案。這種方法有一些明顯的限制。詞的變體形式會影響匹配，例如「ran」和「running」，或「optimise」和「optimize」。語言感知預處理可以緩解一些問題，但不是全部。專業術語、同義詞和相關詞則更難處理。例如，關於「coronavirus」的醫學研究查詢不會自動識別談論「COVID」或「SARS-CoV-2」的文檔，儘管這些都是非常好的匹配。
查詢擴展就是為解決這個問題而發明的。
其基本思想是在查詢中添加額外的詞語和短語，以提高識別良好匹配的可能性。這樣，「coronavirus」的查詢可能會加入「COVID」和「SARS-CoV-2」這些詞。這可以顯著提高搜索性能。
決定應該在查詢中添加哪些詞並不容易，關於如何識別好的詞語以及如何為 tf-idf 風格的檢索賦予權重，已經有了大量的研究。常見的方法包括：
- 使用人工編纂的同義詞詞典。
- 從大型文本語料庫中挖掘相關詞。
- 從查詢日誌中識別類似查詢中使用的其他詞。
- 通過用戶反饋學習哪些詞語和短語是好的查詢擴展。
然而，語義嵌入模型理應消除對查詢擴展的需求。「coronavirus」、「COVID」和「SARS-CoV-2」的良好文本嵌入應該在嵌入向量空間中非常接近。它們應該能自然匹配，無需任何增強。
但是，雖然理論上應該如此，實際上由真實模型產生的嵌入往往達不到這個標準。嵌入中的詞可能是模糊的，如果使用正確的詞，向查詢添加詞可以將其推向更好的匹配。例如，「skin rash」的嵌入可能會識別出關於「behaving rashly」和「skin creme」的文檔，而錯過討論「dermatitis」的醫學期刊文章。添加相關詞很可能會將嵌入從不相關的匹配推向更好的匹配。
tagLLM 查詢擴展
我們研究了使用 LLM 進行查詢擴展，而不是使用同義詞詞典或進行詞彙數據挖掘。LLM 有一些重要的潛在優勢：
- 廣泛的詞彙知識：因為它們是在大型、多樣化的數據集上訓練的，所以不太需要擔心選擇合適的詞典或獲取正確的數據。
- 判斷能力：並非所有建議的擴展詞都一定適合特定查詢。LLM 可能無法做出完美的主題判斷，但其他方法根本無法做出判斷。
- 靈活性：你可以根據檢索任務的需要調整提示，而其他方法則比較僵化，可能需要大量工作才能適應新的領域或數據源。
一旦 LLM 提出了一個詞語列表，嵌入的查詢擴展的操作方式與傳統查詢擴展方案相同：我們將詞語添加到查詢文本中，然後使用嵌入模型創建查詢嵌入向量。
要實現這一點，你需要：
- 訪問 LLM。
- 一個向 LLM 請求擴展詞的提示模板。
- 一個文本嵌入模型。
tag實驗測試
我們進行了一些實驗，看看這種方法是否能為文本信息檢索增加價值。我們的測試使用了：
- 一個 LLM：Google 的 Gemini 2.0 Flash。
- 兩個嵌入模型，以查看 LLM 查詢擴展是否能在不同模型間通用：jina-embeddings-v3 和
all-MiniLM-L6-v2。 - BEIR 基準測試的一個子集用於信息檢索。
我們在兩種提示條件下進行了實驗：
- 使用通用提示模板來請求擴展詞。
- 使用特定任務的提示模板。
最後，我們編寫了提示來請求不同數量的添加詞：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（在檢索的前十個項目上的標準化折扣累積增益）。
| 基準測試 | 無擴展 | 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 |
兩個模型在淨改進方面的巨大差異，很可能是因為 all-MiniLM-L6-v2 的初始性能較低。jina-embeddings-v3 在非對稱檢索模式下產生的查詢嵌入能更好地捕捉關鍵語義關係，因此查詢擴展能添加的資訊空間較小。但這個結果顯示了查詢擴展能在多大程度上提升那些在某些使用場景下可能比大型模型更受歡迎的緊湊型模型的性能。
儘管如此，查詢擴展即使對於像 jina-embeddings-v3 這樣的高性能模型也帶來了有意義的檢索改進，但這個結果在所有任務和條件下並不完全一致。
對於 jina-embeddings-v3，在 FiQA 和 NFCorpus 基準測試中，添加超過 100 個詞彙會產生反效果。我們不能說詞彙越多越好，但其他基準測試的結果表明，有時更多的詞彙確實會帶來更好的效果。
對於 all-MiniLM-L6-v2，添加超過 150 個詞彙總是會產生反效果，而在三個測試中，添加超過 100 個詞彙並未提升分數。在一個測試（FiQA）中，即使只添加 100 個詞彙也產生了明顯較低的結果。我們認為這是因為 jina-embeddings-v3 在捕捉長查詢文本中的語義資訊方面做得更好。
兩個模型在 FiQA 和 NFCorpus 基準測試中對查詢擴展的反應都較弱。
tag使用任務特定提示
上述結果模式表明，雖然查詢擴展是有幫助的，但使用 LLM 可能會添加一些無助於提升性能的查詢詞彙。這可能是由於提示的通用性造成的。
我們選取了兩個基準測試 — SciFact 和 FiQA — 並創建了更多領域特定的提示，如下所示：
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 的搜索基礎產品帶來進一步改進持樂觀態度。
