查询扩展一直是提升搜索系统性能的传统技术，尽管自从语义嵌入问世以来它就有些被冷落了。虽然在当前 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) |
除了在 SciFact 查询中使用 all-MiniLM-L6-v2 添加 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 的搜索基础产品带来进一步改进持乐观态度。
