ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀，每一条都经过真实交付验证。

首页 / 资讯中心 / 正文

基于LLM的Query2doc技术：用大语言模型增强信息检索效果

2026/8/12 16:53:38 拓冰建站 浏览量
基于LLM的Query2doc技术：用大语言模型增强信息检索效果

1. 从“词不达意”到“意随词达”：信息检索的古老困境与新解法

做搜索，无论是给自家产品加个站内搜索，还是处理海量的文档库，最头疼的往往不是技术实现，而是用户那“言简意赅”的查询。用户输入“苹果”，他到底是想找水果、手机公司、还是那部叫《苹果》的电影？这种“查询歧义”和“信息鸿沟”是信息检索领域几十年的老大难问题。传统的搜索引擎，从早期的布尔模型到后来成为事实标准的BM25算法，本质上都是在做“词汇匹配”。它们很擅长处理“苹果公司市值”这种明确的关键词组合，但对于“帮我找找那种又甜又脆的水果”这种描述性、口语化的查询，就显得力不从心了。因为用户的“意图”被压缩成了几个干巴巴的关键词，大量的上下文和隐含信息丢失了。

这就是“查询扩展”技术存在的意义。它的核心思想很简单：既然用户输入的查询太短、太模糊，那我们就想办法把它“变长”、“变具体”，用更丰富的词汇去描述同一个意图，从而提高与目标文档的匹配概率。传统的方法，比如基于同义词词典或者从初次检索结果中提取相关词进行反馈，效果有限且容易引入噪声。直到大语言模型的出现，这件事才有了质的改变。

LLM，特别是经过海量文本训练的生成式模型，展现出了惊人的语言理解和生成能力。它不仅能理解“苹果”的多重含义，还能根据微妙的上下文（比如整个对话历史，或者搜索场景的领域）生成连贯、相关且信息丰富的扩展文本。Query2doc正是这一思路下的一个代表性工作。它不再把LLM当作一个简单的“同义词替换器”，而是将其视为一个“领域专家”或“知识助理”，让LLM基于原始查询，生成一段完整的、描述性的“伪文档”。然后，我们用这段生成的“文档”作为新的、增强后的查询，再去进行检索。这个“文档”里包含了原始查询意图的丰富展开，相当于为检索系统提供了一个更精确的“意图画像”。

简单来说，传统方法是给查询“加几个词”，而Query2doc是让LLM“写一段话”来解释这个查询。后者带来的信息增益是指数级的。接下来，我们就深入这个流程的每一个环节，看看如何将一个简单的想法，落地成一个稳定、高效的检索增强方案。

2. Query2doc的核心工作流拆解：从Prompt到BM25的旅程

理解Query2doc，不能只看“用LLM扩展查询”这个结论，关键是要拆解其完整的工作流，理解数据是如何流动和转化的。整个流程可以清晰地分为四个阶段：查询理解与Prompt构建、LLM的“伪文档”生成、检索查询的构造与执行，以及最终结果的融合与返回。每个环节都有其设计考量和实操细节。

2.1 第一阶段：原始查询的“语境化”包装

用户输入一个查询，比如llm框架对比。直接把这个字符串扔给LLM，让它“写一段相关文档”，效果可能很不稳定。LLM需要更明确的指令和上下文才能生成高质量、有针对性的内容。

这里的关键是设计一个有效的Prompt模板。这个模板需要完成以下几件事：

  1. 定义角色：告诉LLM它应该扮演什么角色（例如，“你是一个技术文档撰写专家”）。
  2. 明确任务：清晰说明需要它做什么（例如，“请根据以下查询，生成一段简明、信息丰富的描述性文本”）。
  3. 提供查询：将用户的原始查询放入指定位置。
  4. 设定约束：规定生成文本的长度、风格和格式（例如，“请生成一段约80-150字的段落，避免使用列表和Markdown格式”）。

一个经过实践验证的Prompt模板可能长这样：

你是一个信息检索领域的专家。你的任务是根据用户提供的简短查询，生成一段高质量的、描述性的文本段落。这段文本应该自然地展开和解释查询的意图，包含相关的上下文、同义词和细节，使其更像一段完整的文档摘要。 查询: {user_query} 请生成一段约100字左右的连贯段落：

将{user_query}替换为llm框架对比，就得到了发给LLM的完整指令。这个阶段的目标是为LLM创造一个高质量的“思考起点”，引导它生成我们想要的、富含检索相关词汇的文本。

注意：Prompt的设计是影响生成质量的最大变量。对于不同领域（如医疗、法律、通用网页），可能需要定制不同的角色和风格描述。例如，对于医疗查询，角色可以设定为“严谨的医学知识科普作者”，并约束“使用规范的专业术语”。

2.2 第二阶段：LLM生成“伪文档”的实战细节

拿到精心设计的Prompt后，我们就调用LLM的文本生成接口。这里有几个关键参数直接影响输出结果和系统性能：

  • 模型选择：不需要动用千亿参数的巨型模型。像gpt-3.5-turbo,claude-3-haiku, 或开源的Llama 3 8B、Qwen2.5 7B这类模型在理解指令和生成连贯文本上已经足够出色，且在延迟和成本上更有优势。选择模型时，需要在“生成质量”、“响应速度”和“API成本/本地部署开销”之间做权衡。
  • 生成参数：
    • temperature：这个参数控制生成的随机性。对于检索任务，我们通常希望输出稳定、可靠，因此建议设置为较低值，如0.1或0.2。过高的温度会导致每次生成的“伪文档”差异巨大，影响检索结果的一致性。
    • max_tokens：限制生成文本的长度。根据我们的Prompt要求（约100字），可以设置为150到200个token，为模型留出一点余量，同时避免生成过于冗长的内容。
  • 错误处理与降级：必须考虑LLM调用失败的情况（网络超时、API限额、模型服务异常）。一个健壮的系统需要有降级策略。最简单的降级就是直接使用原始查询进行检索。更高级一点的可以准备一个缓存，存储常见查询及其扩展结果，当LLM服务不可用时使用缓存版本。

假设我们调用gpt-3.5-turbo，得到了如下生成的“伪文档”：

“大型语言模型框架对比”是一个常见的技术调研需求，涉及评估不同框架在易用性、性能、生态系统和部署灵活性等方面的表现。当前主流的LLM框架包括PyTorch系的Transformers库、TensorFlow的KerasNLP、以及专为生产环境设计的框架如vLLM和TGI。对比时通常会关注其API设计是否简洁、分布式训练支持如何、推理优化工具链是否完善、社区活跃度和预训练模型资源是否丰富。此外，对于特定硬件（如GPU或边缘设备）的适配能力也是一个关键考量点。

这段文本已经远远超出了“llm框架对比”五个字所承载的信息量。它引入了“PyTorch”、“Transformers”、“TensorFlow”、“KerasNLP”、“vLLM”、“TGI”、“分布式训练”、“推理优化”、“预训练模型”等一系列高度相关的专业词汇。这些词汇将成为后续检索的“信号放大器”。

2.3 第三阶段：构造检索查询与执行检索

生成了“伪文档”后，我们不能直接把整段文字扔给BM25。BM25等传统检索模型是基于“词袋”模型的，长文本中可能包含大量功能词（的、了、在）和与核心意图关联度不高的词汇，直接使用会稀释核心关键词的权重。

因此，我们需要从“伪文档”中提取关键信息。常用方法有两种：

  1. 直接使用：对于质量很高、非常凝练的生成文本，有时可以直接使用。但风险是可能引入噪声。
  2. 关键词提取：这是更稳妥的做法。可以使用简单的TF-IDF算法在“伪文档”内部进行词重要性排序，提取Top-N个关键词；或者使用更专业的无监督关键词提取工具（如RAKE,YAKE）。在我们的例子中，提取出的关键词可能包括：LLM框架、对比、PyTorch、Transformers、TensorFlow、推理优化、分布式训练、预训练模型。

接下来，我们用这些提取出的关键词（或整个“伪文档”）构造新的检索查询。一种有效的策略是“混合查询”：将原始查询与扩展后的关键词结合。例如：

原始查询: llm框架对比 扩展关键词: PyTorch Transformers TensorFlow 推理优化 分布式训练 最终检索查询: llm框架对比 PyTorch Transformers TensorFlow 推理优化 分布式训练

这样既保留了用户原始意图的最直接表达（“llm框架对比”），又融入了LLM提供的丰富上下文词汇。

最后，将这个增强后的查询送入检索系统（如Elasticsearch, Meilisearch 或任何支持BM25的库）。检索系统会计算该查询与文档库中所有文档的BM25相关性分数，并返回排名最高的文档列表。

2.4 第四阶段：结果的后处理与权衡

拿到检索结果后，工作还没结束。我们需要思考：增强查询的效果一定总是正面的吗？如何量化这种提升？

  • 效果评估：在学术研究和工业实践中，通常使用标准检索评测集（如MS MARCO, TREC）进行评估。核心指标包括：
    • MRR：平均倒数排名，衡量第一个相关文档出现的位置。
    • nDCG@k：归一化折损累计增益，衡量前k个结果的整体质量和排序合理性。
    • Recall@k：前k个结果中相关文档的召回率。 Query2doc类方法在这些数据集上被证明能显著提升上述指标，尤其是在处理简短、模糊的查询时。
  • 延迟与成本权衡：这是工程落地的核心矛盾。LLM的生成需要时间（几百毫秒到数秒）和成本（API调用费用或计算资源）。因此，并非所有查询都需要走LLM扩展流程。一个实用的策略是建立“查询分类器”：
    • 短查询、模糊查询：长度小于3个词，或包含指代不清的代词（“它”、“那个”），优先走Query2doc流程。
    • 长查询、明确查询：用户已经输入了很长的、描述清晰的句子，其本身信息量可能已足够，可以直接检索或仅进行轻量级扩展（如同义词替换）。
    • 高频查询缓存：对于热门查询，可以将其扩展结果缓存起来，下次直接使用，避免重复调用LLM。
  • 结果解释性：在展示结果时，可以向高级用户提供一个“为什么搜到这个”的轻量级解释，例如：“根据您对‘LLM框架对比’的查询，我们扩展了与‘PyTorch’, ‘推理优化’等相关的内容。”这能增加系统透明度，提升用户体验。

通过以上四个阶段的拆解，我们可以看到Query2doc不是一个简单的“调个API”，而是一个需要精心设计每个环节的完整系统。接下来，我们探讨如何将这个框架与当前最流行的RAG系统结合。

3. 在RAG架构中扮演“查询理解增强器”的角色

检索增强生成（RAG）系统近年来已成为构建知识密集型AI应用的标准架构。一个典型的RAG流程是：用户提问 -> 检索相关文档片段 -> 将问题和文档片段一起交给LLM生成答案。这里的瓶颈往往出现在第一步：如果检索到的文档不相关，后续LLM再怎么“巧妇难为无米之炊”，也会产生幻觉或错误答案。

Query2doc的思想可以无缝嵌入到RAG的检索环节，作为查询理解与增强的模块。它的位置在原始用户查询之后，向量检索或关键词检索之前。

3.1 与传统RAG检索方式的对比

传统RAG的检索通常有两种方式：

  1. 基于向量检索：将用户查询和文档都编码成向量（通过Embedding模型如text-embedding-ada-002, BGE等），计算余弦相似度。它对语义匹配好，但可能无法捕捉精确的关键词匹配，且对查询表述变化敏感。
  2. 基于关键词检索：使用BM25等算法。它对精确关键词匹配强，但无法理解语义，对于“汽车”和“机动车”这种表述不同但意思相同的查询无能为力。

Query2doc提供了一种混合思路：

  • 第一步：用LLM将用户的（可能是模糊的）语义意图，扩展成一段包含丰富相关词汇的文本。这个过程本质上是基于深度语义理解的查询重构。
  • 第二步：对这段生成的文本进行关键词提取，或者直接将其编码为向量。
  • 第三步：使用提取的关键词进行BM25检索，或/和使用生成的文本向量进行向量检索。

这样一来，我们既利用了LLM的深层语义理解能力来“猜”用户到底想要什么，又将这个理解转化成了传统检索系统能更好利用的“信号”（关键词或更准确的向量）。它相当于在语义理解和词汇匹配之间架起了一座桥。

3.2 具体集成方案与代码示意

假设我们有一个简单的RAG系统，文档库已经建立好了向量索引和倒排索引（用于BM25）。集成Query2doc模块的流程如下：

import openai from typing import List import your_embedding_module # 假设的Embedding客户端 import your_bm25_searcher # 假设的BM25检索客户端 class Query2DocRAGRetriever: def __init__(self, llm_client, embed_client, bm25_searcher): self.llm = llm_client self.embed = embed_client self.bm25 = bm25_searcher def _expand_query(self, original_query: str) -> str: """使用LLM扩展查询""" prompt = f"""你是一个乐于助人的AI助手。请根据以下用户查询，生成一段简短、信息丰富的描述性文本，用以更好地理解用户的搜索意图。 查询: {original_query} 生成描述:""" try: response = self.llm.chat.completions.create( model="gpt-3.5-turbo", messages=[{"role": "user", "content": prompt}], temperature=0.1, max_tokens=150 ) expanded_text = response.choices[0].message.content.strip() return expanded_text except Exception as e: print(f"LLM查询扩展失败，降级为原始查询: {e}") return original_query # 降级策略 def retrieve(self, query: str, top_k: int = 5) -> List[Document]: # 1. 查询扩展 expanded_text = self._expand_query(query) print(f"扩展后文本: {expanded_text}") # 2. 双路检索 # 路A: 使用扩展文本的向量进行语义检索 query_vector = self.embed.encode(expanded_text) vector_results = self.vector_index.search(query_vector, top_k=top_k*2) # 多取一些 # 路B: 从扩展文本提取关键词进行稀疏检索 (这里简化处理，直接使用全文) keyword_results = self.bm25.search(expanded_text, top_k=top_k*2) # 3. 结果融合 (简单的加权融合) combined_results = {} # 给向量检索结果赋分 for doc, score in vector_results: combined_results[doc.id] = combined_results.get(doc.id, 0) + score * 0.7 # 权重0.7 # 给关键词检索结果赋分 for doc, score in keyword_results: combined_results[doc.id] = combined_results.get(doc.id, 0) + score * 0.3 # 权重0.3 # 4. 按融合后分数排序，返回Top-k sorted_docs = sorted(combined_results.items(), key=lambda x: x[1], reverse=True) final_docs = [doc for doc, _ in sorted_docs[:top_k]] return final_docs

这个示例展示了核心思想：先扩展，后双路检索，再融合。在实际中，权重系数（0.7和0.3）、是否提取关键词、融合算法（如RRF）都可以根据实际效果调优。

3.3 带来的收益与挑战

收益：

  • 召回率提升：对于表述模糊的查询，能通过扩展词汇召回更多潜在相关文档。
  • 准确率提升：生成的描述文本更接近文档的表述方式，提高了查询与文档的语义对齐度。
  • 缓解“词汇不匹配”问题：用户说的“AI编程助手”和文档里写的“基于LLM的代码生成工具”能被LLM联系起来。

挑战：

  • 延迟增加：LLM生成是主要延迟来源。需要缓存、异步等优化手段。
  • 成本：频繁调用LLM API会产生费用。
  • 可控性：LLM可能生成有偏差或无关的内容，污染检索。需要设计严格的Prompt和后续过滤机制。
  • 领域适配：通用LLM在特定专业领域（如生物医学、法律条文）的扩展能力可能不足，可能需要使用领域微调的模型。

尽管有挑战，但在对检索质量要求高的RAG场景中，引入Query2doc作为查询增强步骤，是一个性价比很高的优化方向。接下来，我们看看在真实场景中部署时会遇到哪些具体的“坑”。

4. 实战部署中的关键考量与避坑指南

将Query2doc从论文思路转化为线上可用的服务，会遇到一系列工程和效果上的挑战。以下是我在实践过程中总结的几个关键点和常见陷阱。

4.1 陷阱一：Prompt设计不当导致扩展偏离

这是最常见的问题。一个糟糕的Prompt会让LLM生成无关内容。

  • 反面例子：“请扩展以下查询：{query}”。这个指令太模糊，LLM可能会开始自由发挥，甚至生成一段问答对话。
  • 避坑方法：
    1. 明确指令：必须包含“生成描述性文本”、“用于信息检索”等限定词。
    2. 提供示例：在Prompt中给出1-2个高质量的输入输出示例（Few-shot Learning），能极大地稳定输出格式和质量。
    3. 限制领域：如果是在特定领域（如IT技术支持），在Prompt开头明确角色和领域，例如“你是一个IT知识库专家，专门处理软件框架相关的问题”。
    4. 迭代测试：对一批典型查询（短、模糊、长、具体）进行测试，人工评估生成文本的质量，反复调整Prompt。

4.2 陷阱二：忽略LLM的“幻觉”与安全性

LLM可能会在生成的“伪文档”中插入事实性错误或不存在的信息。

  • 风险：例如，查询“Python异步编程”，LLM可能生成“...在Python 3.12中新增了async/await关键字...”（事实上3.5就有了）。如果用这个错误信息去检索，可能会误导结果。
  • 缓解策略：
    1. 降低Temperature：如前所述，使用低随机性参数。
    2. 后置过滤：对生成文本进行简单的事实性检查，例如，如果其中包含具体的版本号、日期等事实性断言，可以尝试用另一个快速的检索来验证，或者直接过滤掉这些高风险片段。
    3. 使用“保守”模型：有些模型在指令遵循和事实性上更保守，虽然创造性可能差一些，但更适合这种“扩写”任务。
    4. 关键信息抽取而非全文信任：我们的目的不是获得一段完美的文档，而是获得扩展的关键词。因此，可以从生成文本中抽取名词、专业术语等实体，这些实体即使在不完美的句子中，也大概率是相关的。

4.3 陷阱三：性能瓶颈与降级策略缺失

线上服务对延迟敏感。LLM调用可能成为瓶颈。

  • 优化方案：
    1. 缓存层：构建一个查询-扩展结果的缓存（如Redis）。对于完全相同的查询，直接返回缓存结果。可以考虑设置TTL。
    2. 异步处理：如果应用场景允许，可以将“查询扩展”作为异步任务，先返回一个初步结果（基于原始查询），待扩展完成后在后台更新或进行下一轮精排。
    3. 模型轻量化：考虑使用更小、更快的模型，如经过蒸馏的模型，或在GPU上部署小型开源模型（如Phi-3, Gemma 2B）。
    4. 必须设计降级策略：当LLM服务超时（如2秒无响应）或出错时，系统必须能自动回退到原始查询进行检索，保证服务的基本可用性。

4.4 陷阱四：对所有查询一视同仁

不是所有查询都需要扩展。对已经很长、很具体的查询进行扩展，可能是画蛇添足，甚至引入噪声。

  • 实施策略：
    1. 查询分类：实现一个简单的分类器。规则可以基于：查询长度（词数）、是否包含疑问词、词性分布等。例如，长度小于等于2的词，且不是专有名词，则触发扩展。
    2. 成本-收益分析：对于高价值、高频率的查询（如电商中的核心商品搜索），值得使用扩展。对于边缘的、长尾的查询，可以直接使用传统检索以节省成本。
    3. A/B测试：在线上分流一部分流量，对比使用Query2doc和不用时的核心业务指标（如点击率、转化率），用数据驱动决策。

4.5 陷阱五：与现有检索系统的集成复杂度

如何将扩展后的查询“喂”给现有的检索系统（如Elasticsearch）？

  • 方案选择：
    1. 查询重写：最简单的方式，在应用层将用户查询替换为扩展后的查询（或混合查询），然后像普通查询一样发送给检索系统。对现有系统侵入最小。
    2. 定制检索插件：如果使用Elasticsearch，可以开发一个自定义的搜索插件，在查询解析阶段集成LLM调用。这种方式更优雅但开发复杂。
    3. 两阶段检索：先用原始查询快速召回一批候选文档（比如Top 100），再用LLM扩展后的查询对这100个文档进行精排（Re-ranking）。这能平衡速度和精度。
  • 我的经验：从“查询重写”开始是最快验证效果的方式。用一个代理服务拦截查询，重写后再转发给ES。待效果验证明确后，再考虑更复杂的集成方案。

5. 效果评估与持续迭代：如何证明它真的有用？

引入任何新技术都需要评估其价值。对于Query2doc，我们需要从离线评测和在线实验两个层面来验证其效果。

5.1 离线评测：构建测试集与核心指标

离线评测是在上线前，用一个固定的测试集来评估模型。

  1. 构建测试集：
    • 查询-相关文档对：这是黄金标准。你需要一批真实的用户查询，以及人工标注的、确定相关的文档列表。可以从公开数据集（如MS MARCO, BEIR）获取，也可以从自己的业务日志中采样并人工标注。
    • 查询多样性：测试集应包含各种类型的查询：短查询（1-2词）、长查询、模糊查询、具体查询。
  2. 选择评测指标：
    • Recall@k：前k个结果中，命中了多少相关文档。这衡量了系统的“找全”能力。对于检索增强场景，k通常取5, 10, 20。
    • MRR：第一个相关文档排名的倒数平均值。这衡量了系统“把最相关的放在前面”的能力。值越接近1越好。
    • nDCG@k：不仅考虑相关文档是否出现，还考虑其排序位置，是综合性的指标。
  3. 进行A/B测试：
    • 基线系统：使用原始查询进行检索（BM25或向量检索）。
    • 实验系统：使用Query2doc增强后的查询进行检索。
    • 在同一测试集上运行两个系统，计算上述指标。如果实验系统的指标显著优于基线，则证明Query2doc有效。

5.2 在线实验：A/B测试与业务指标

离线效果好不代表线上效果好。最终要接受真实用户的检验。

  1. 设计A/B实验：
    • 将线上用户流量随机分为两组：A组（对照组）使用原始检索，B组（实验组）使用Query2doc增强检索。
    • 确保两组用户在分布上是一致的。
  2. 定义核心业务指标：
    • 搜索满意度：点击率（CTR）、结果页停留时间、后续交互深度（如翻页、点击多个结果）。
    • 下游任务成功率：在RAG场景中，最关键的指标是最终答案的正确率。可以人工评估或通过一些自动化手段（如将答案喂给LLM让其判断是否基于上下文正确回答）来衡量。
    • 系统性能指标：平均响应延迟、第95分位延迟（P95 Latency）。Query2doc不能以牺牲用户体验为代价。
  3. 分析实验结果：
    • 如果实验组在核心业务指标（如答案正确率）上有显著提升，且性能指标在可接受范围内，那么就可以考虑全量上线。
    • 如果效果不明显或为负，需要分析原因：是Prompt问题？是某些查询类型不适用？还是LLM响应太慢导致用户流失？

5.3 持续监控与迭代

上线不是终点。需要建立监控看板。

  • 质量监控：定期抽样检查LLM生成的扩展文本质量，防止模型漂移或Prompt失效。
  • 性能监控：监控LLM API的调用延迟、错误率和成本。
  • 反馈循环：收集用户对搜索结果的负面反馈（如“结果不相关”点击），这些数据可以用来优化Prompt，或调整查询分类策略。

从我实际部署的经验来看，Query2doc在处理短尾、模糊、知识型查询时提升最为明显。例如，在技术文档搜索中，将“docker网络”扩展为“Docker容器网络配置、bridge网络驱动、host网络模式、overlay网络用于Swarm集群的详细说明”后，检索到的文档相关性大幅提高。然而，对于明确的事务型查询，如“Python 3.12下载”，扩展带来的收益很小，有时反而会因为添加了不必要的上下文而降低精度。因此，一个智能的、有条件的查询扩展策略，才是保证系统整体效果最优的关键。