2026年7月16日 周四晚上19:30,报名腾讯会议了解“如何构建自进化的动态知识库(Brain)”(限30人)
免费POC, 零成本试错
FDE知识库

FDE知识库

学习大模型的前沿技术与行业落地应用


收藏

基于 LLM 的查询扩展:信息更全,搜索更准

发布日期:2025-02-20 15:51:05 浏览次数: 3210
作者:Jina AI

微信搜一搜,关注“Jina AI”

推荐语

探索基于LLM的查询扩展技术,提升搜索精准度和全面性。

核心内容:
1. 查询扩展在Agentic Search中的应用与重要性
2. 传统查询扩展方法及其局限性
3. 基于LLM的查询扩展技术及其优势

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家

查询扩展 (Query Expansion) ,这股风潮又刮回来了!作为曾经搜索的标配,后来一度沉寂,在今天推理式搜索 (Agentic Search) 的浪潮下,查询扩展又重新回到了聚光灯下。

做过 Agentic Search (比如 DeepSearch/DeepResearch) 的朋友肯定深有体会,用户直接输入的查询词,要么太笼统,不够聚焦;要不就太细碎,不够全面。这让那些依赖关键词匹配或者结构化数据的 Agentic 工具很难精准处理。

因此,我们需要对用户查询进行扩展或重写,让它们更符合搜索语境,更具发散性,既能覆盖足够多的信息,又能深入挖掘潜在关联。

什么是查询扩展?

最初,查询扩展是为那些靠关键词匹配来判断相关性的搜索系统设计的,比如 tf-idf 或其他稀疏向量方案。

这类方法有些天然的缺陷:词语稍微变个形式,像 "ran" 和 "running",或者 "optimise" 和 "optimize",都会影响匹配结果。虽然可以用语言预处理来解决一部分问题,但远远不够。技术术语、同义词和相关词就更难处理了。举个例子,如果搜索 "coronavirus" 相关的医学研究,系统很可能找不到包含 "COVID" 或 "SARS-CoV-2" 的文档,但它们明明也高度相关。

查询扩展就是为了解决这些问题而生的。

它的思路其实很简单:往原始查询里加一些相关的词,提高找到优质结果的概率。比如,搜索 "coronavirus",可以自动加上 "COVID" 和 "SARS-CoV-2" 这些词,这样搜出来的结果质量就能大大提高。

图 1:使用同义词典的查询扩展流程图

不过,到底该往查询里加哪些词,可不是一件容易的事儿。之前有不少研究,专门教你识别好的词,以及如何给 tf-idf 风格的检索赋予权重。常用的方法包括:

  • 使用人工编写的同义词词典。
  • 从海量的文本语料库里挖掘相关词汇。
  • 从查询日志里分析,看看类似的搜索还用了哪些关键词。
  • 通过用户反馈,了解哪些词适合用于查询扩展。

理论上讲,有了语义向量模型,应该就不需要查询扩展了。"coronavirus"、"COVID" 和 "SARS-CoV-2" 这些词的向量应该非常接近,可以自然匹配,不需要额外做任何增强。

但现实情况是,向量模型往往达不到理想效果,向量里的词可能含义模糊不清。因此,在查询中加入一些合适的词,反而能帮助模型更精准地找到目标答案。 

举个例子,如果你搜索 "skin rash" (皮疹),系统可能会搜出来 "behaving rashly" (轻率行事) 和 "skin creme" (润肤霜) 这种不太相关的结果,但却漏掉了讨论 "dermatitis" (皮炎) 的医学期刊文章。如果加上 "dermatitis" 这个词,就能让向量远离那些不相关的结果,找到更靠谱的答案。

用 LLM 做查询扩展

除了传统的同义词词典和词法挖掘,我们还探索了使用 LLM(大型语言模型)来进行查询扩展。LLM 有几个显著优势:

1. 词汇量巨大:毕竟 LLM 是在海量数据上训练出来的,不用担心找不到合适的同义词,或者没数据可用。

2. 具备一定的判断力:不是所有扩展词都适合所有查询。虽然 LLM 不可能完美判断主题相关性,但它至少能做一些初步的筛选,而传统方法根本没这个能力。

3. 灵活,可定制:你可以根据具体的搜索任务,调整给 LLM 的提示词。相比之下,传统方法就比较死板了,想适配新的领域或者数据源,往往得费老大劲。

当 LLM 生成一个扩展词列表后,接下来的流程就和传统的查询扩展差不多了:把这些词加到原始查询文本里,然后用向量模型生成查询向量。

图 2:使用 LLM 的向量查询扩展

要实现基于 LLM 的查询扩展,你需要一个可用的 LLM 服务,一套提示词模板,用来引导 LLM 生成扩展词,以及一个文本向量模型。

实践尝试

为了测试 LLM 辅助查询扩展到底有没有用,我们进行了一系列实验。测试环境如下:

  • LLM: Google 的 Gemini 2.0 Flash

  • 向量模型:jina-embeddings-v3 和 all-MiniLM-L6-v2(用于验证该方法在不同模型上的适用性)

  • 数据集:BEIR 基准的一个子集

实验中,我们采用了两种提示词策略,一种是通用的提示词模板,另一种是针对特定任务设计的提示词模板。

另外,我们还测试了不同数量的扩展词:分别是 100 个、 150 个和 250 个。

所有代码和实验结果都开源了,欢迎大家围观和复现:

? llm-query-expansion: https://github.com/jina-ai/llm-query-expansion/

通用提示词效果

经过反复试验,我们发现以下提示词在 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.7473.3974.1674.33
TRECCOVID (医疗检索任务)77.5576.7477.1279.28
FiQA (金融期权检索)47.3447.7646.0347.34
NFCorpus (医疗信息检索)36.4640.6239.6339.20
Touche2020 (论点检索任务)26.2426.9127.1527.54

从结果可以看出,在大多数情况下,查询扩展都能提升检索效果。

为了验证该方法的稳健性,我们使用 all-MiniLM-L6-v2(一个能生成更小的向量向量的小型模型)重复了相同的测试。

all-MiniLM-L6-v2: https://huggingface.co/sentence-transformers/all-MiniLM-L6-v2

结果如下表所示:

测试集无扩展词100 个拓展词150 个拓展词250 个拓展词
SciFact (事实核查任务)64.5168.7266.2768.50
TRECCOVID (医疗检索任务)47.2567.9070.1869.60
FiQA (金融期权检索)36.8733.9632.6031.84
NFCorpus (医疗信息检索)31.5933.7633.7633.35
Touche2020 (论点检索任务)16.9025.3123.5223.23

从结果可以看出,查询扩展对检索分数有显著提升,尤其对于较小的模型,效果更为明显。下表总结了各模型在所有任务上的平均提升幅度:

模型100 拓展词150 拓展词250 拓展词
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 这样的高性能模型也有一定改进,但并非在所有任务和条件下都有效。

对于 jina-embeddings-v3,在 FiQA 和 NFCorpus 基准测试中,添加超过 100 个词反而会降低性能,说明并非词越多越好。 其他基准测试的结果则表明,在某些情况下,更多词项能够带来更好的效果。

对于 all-MiniLM-L6-v2,添加超过 150 个词项也总是会降低性能,在三个测试中,添加超过 100 个词项也没有提高分数。在 FiQA 测试中,即使只添加 100 个词项,结果也明显下降。我们认为这是因为 jina-embeddings-v3 在处理较长的查询文本时,能更好地捕捉其中的语义信息。

但两个模型在 FiQA 和 NFCorpus 基准测试中对查询扩展的响应都不太积极。

针对特定任务的提示词

前面的实验结果显示,尽管查询扩展总体上有所帮助,但直接使用 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\]

实验结果表明,这种定制化的提示策略几乎全面提升了检索性能:

测试集模型无拓展词100 拓展词150 拓展词250 拓展词
SciFactjina-embeddings-v372.7475.85 (+2.46)75.07 (+0.91)75.13 (+0.80)
SciFactall-MiniLM-L6-v264.5169.12 (+0.40)68.10 (+1.83)67.83 (-0.67)
FiQAjina-embeddings-v347.3447.77 (+0.01)48.20 (+1.99)47.75 (+0.41)
FiQAall-MiniLM-L6-v236.8734.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 个扩展词反而会带来负面影响。这进一步验证了我们之前的推测:一味地向查询中添加过多词汇可能适得其反,尤其当这些词汇偏离了核心语义时。

收益与挑战

毋庸置疑的是,查询扩展能够提升基于向量的搜索效果。但与此同时,我们也需要正视以下几个关键问题:

1. 成本考量

与 LLM 交互会增加信息检索的延迟和计算开销。如果使用商业 LLM 服务,还会产生额外的费用。因此,我们需要仔细权衡,看这些性能提升是否能够抵消由此带来的成本增长。

2. 提示词工程

设计优秀的提示词模板并非易事,需要大量的实践和实验。我们也不认为本次实验中使用的提示词是最佳方案,更无法保证它们能够直接迁移到其他 LLM 上。我们在特定任务提示方面的实验已经表明,提示词的细微改变都可能对结果质量产生显著影响,并且不同领域之间的效果差异也很大。

这些不确定性无疑会增加开发成本,并降低系统的可维护性。一旦系统中的任何环节发生变化,比如更换 LLM、向量模型或信息领域,我们就需要对整个流程进行重新评估,甚至可能需要彻底重构。

3. 其他优化路径

本次实验结果表明,查询扩展对初始性能较差的向量模型带来了更显著的提升。但需要指出的是,即便使用了查询扩展,all-MiniLM-L6-v2 仍然无法追赶上 jina-embeddings-v3 的性能水平,而 jina-embeddings-v3 通过查询扩展获得的提升也相对有限。

在这种情况下,对于 all-MiniLM-L6-v2 的用户来说,直接升级到 jina-embeddings-v3能以更低的成本获得更好的搜索效果,而不是投入精力去做查询扩展。

未来方向

文本的实验初步验证了,查询扩展确实能够优化向量搜索,以及 LLM 能够以一种简单而灵活的方式生成高质量的查询扩展词。但当前的效果提升还不够显著,还有不少工作要做。我们正在探索以下几个未来的研究方向:

  • 评估查询扩展词对于提升文档向量质量的价值。

  • 探索查询增强在重排序等其他 AI 搜索技术中的应用潜力。

  • 对比基于 LLM 的查询扩展与传统、低成本的词汇来源(例如同义词词典)的效果。

  • 针对查询扩展任务,专门训练语言模型,并提供更多领域相关的训练数据。

  • 优化扩展词数量,避免一次性添加过多(例如 100 个)扩展词。

  • 研究识别有效和无效扩展词的方法。简单地限制扩展词数量可能不够理想;如果能够动态评估推荐的扩展词,并仅保留高质量的扩展词,结果可能会有显著提升。

虽然这是一项初步的研究,但我们对这项技术能在 Jina AI Search Foundation 里做进一步应用充满期待。

53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询

扫码登录
登录即表示您同意《53AI网站服务协议》
服务协议

欢迎您使用【53AI 官方网站】(以下简称“本网站”或“我们”)。本《会员服务协议》(以下简称“本协议”)是您(以下简称“会员”或“用户”)与【深圳市博思协创网络科技有限公司】之间关于注册、登录及使用本网站会员服务所订立的法律协议。

在您注册或登录前,请务必审慎阅读、充分理解各条款内容,特别是免除或限制责任的条款、知识产权条款、争议解决条款等。此类条款将以加粗形式提示您注意。 当您通过微信公众号授权、手机验证码验证或其他方式成功登录本网站时,即视为您已完全理解并同意接受本协议的全部内容。

一、 定义

本网站:指由【深圳市博思协创网络科技有限公司】运营的,域名为【53ai.com】的网站及相关移动端页面。

会员服务:指本网站向注册会员提供的知识库文章查阅、内容检索及其他相关增值服务。

知识库内容:指本网站发布的包括但不限于文字、图表、数据、研究报告、行业分析等数字化内容资源。

二、 账号注册与登录

登录方式:本网站支持以下登录方式,您可根据实际情况选择:

微信公众号授权登录:您同意将您的微信OpenID信息授权给本网站,用于创建或关联会员账号。

手机验证码登录:您需提供真实有效的手机号码,并通过短信验证码完成身份验证与登录/注册。

账号安全:您的账号仅限您本人使用,禁止赠与、借用、租用、转让或售卖。因您保管不善导致的账号被盗、密码泄露等损失,由您自行承担。

实名认证:根据相关法律法规要求,我们可能要求您在特定功能下完成实名认证。如您拒绝提供,可能无法使用部分或全部服务。

未成年人保护:若您未满18周岁,请在法定监护人的陪同下阅读本协议,并在征得监护人同意后使用本服务。

三、 服务内容与规范

知识库查阅权限:会员登录后,有权按照其会员等级对应的权限范围,在线浏览、检索本网站知识库中的相关文章及内容。

服务变更:我们有权根据业务发展需要,调整、变更或终止部分服务内容,并将以网站公告、公众号消息等方式提前通知。

禁止行为:您在使用服务时不得实施以下行为:

利用技术手段批量爬取、下载、转存知识库内容;

将知识库内容用于商业目的或未经授权地向第三方传播;

干扰本网站正常运行或侵犯其他用户合法权益;

发布违法违规信息或从事违反公序良俗的活动。

四、 知识产权声明

权利归属:本网站知识库中的排版设计、软件代码等内容的知识产权均归【公司全称】或原权利人所有,受《中华人民共和国著作权法》等法律保护。

有限许可:本网站授予会员一项非独占、不可转让、不可转授权的普通许可,仅限于个人学习、研究之目的在线查阅知识库内容。

侵权追责:未经书面许可,任何单位或个人不得以任何形式复制、转载、摘编、镜像、汇编或以其他方式使用上述内容。一经发现,我们保留追究其法律责任的权利。

五、 个人信息保护

我们重视对您个人信息的保护。关于我们如何收集、使用、存储和保护您的个人信息,请单独阅读 《隐私政策》。

您通过微信公众号授权或手机号验证所提供的信息,我们将严格按照《个人信息保护法》的规定处理,仅用于身份识别、服务提供及安全验证等必要用途。

您可以随时通过网站设置或联系客服行使查阅、更正、删除个人信息及撤回授权同意的权利。

六、 免责声明

内容准确性:知识库内容仅供参考,不构成专业建议。我们不对其完整性、准确性、时效性作任何明示或暗示的保证,您应自行判断并承担使用风险。

不可抗力:因自然灾害、政策法规变化、网络故障、第三方平台接口异常(如微信接口维护、运营商短信通道故障)等不可抗力导致的服务中断或延迟,我们不承担违约责任。

第三方链接:本网站可能包含指向第三方网站的链接,该等网站的内容和服务不受我们控制,请您自行甄别风险。

七、 违约责任

如您违反本协议约定,我们有权视情节采取警告、限制功能、暂停服务、注销账号等措施,并保留要求赔偿损失的权利。

如因您的违约行为导致我们遭受行政处罚、第三方索赔或商誉损失,您应承担全部赔偿责任(包括但不限于罚款、赔偿金、律师费、公证费等)。

八、 法律适用与争议解决

本协议的订立、执行和解释均适用中华人民共和国大陆地区法律。

因本协议产生的或与本协议有关的任何争议,双方应友好协商解决;协商不成的,任何一方均可向【公司所在地】有管辖权的人民法院提起诉讼。

九、 其他

本协议构成双方就本服务达成的完整协议,取代此前任何口头或书面约定。

本协议任一条款被认定为无效或不可执行的,不影响其他条款的效力。

我们对本协议享有最终解释权,并在法律允许的范围内保留随时修改的权利。修改后的协议一经公布即生效,继续使用服务即视为同意修订内容。


已查阅