解析 ‘Query Transformations’：为什么重写用户的问题（Rewrite-Retrieve-Read）能显著提升召回率？

各位编程专家、数据科学家和对信息检索充满热情的同仁们，大家好！

今天，我们将深入探讨一个在现代信息检索和问答系统中至关重要的主题：Query Transformations（查询转换）。具体来说，我们将聚焦于为什么在“Rewrite-Retrieve-Read”这个范式中，对用户查询进行重写能够显著提升召回率。这不仅仅是理论探讨，更是一门实践的艺术，它要求我们深刻理解用户意图、语言的复杂性以及检索系统的运作机制。

信息检索的本质挑战：用户意图与系统理解的鸿沟

在任何信息检索场景中，无论是搜索引擎、企业内部知识库还是智能客服，核心任务都是将用户的查询与最相关的文档或信息片段匹配起来。听起来简单，实则不然。

问题的症结在于：用户通常以自然语言表达他们的需求，而这种表达方式往往与信息源的组织方式、词汇选择，甚至是系统内部的索引机制存在天然的鸿沟。

1. 词汇不匹配 (Lexical Gap)：

   • 用户可能使用同义词、近义词或相关词。例如，用户搜索“手机充电器”，但文档中可能只提到“移动电源适配器”或“USB-C线缆”。
   • 用户可能使用缩写、简称或俗语。例如，“AI”与“人工智能”，“ML”与“机器学习”。
   • 存在上下位关系词。例如，用户搜索“苹果”，可能指代水果，也可能指代科技公司。

2. 语义不匹配 (Semantic Gap)：

   • 用户查询可能过于宽泛或过于具体，导致难以匹配到恰当的文档。
   • 查询可能存在歧义，同一个词或短语在不同语境下有不同的含义。
   • 用户查询的结构可能与系统期望的“最佳”查询结构不符。例如，一个口语化的长句可能包含很多冗余信息。

3. 上下文缺失 (Contextual Gap)：

   • 在对话式系统中，用户的当前查询可能依赖于先前的对话历史。
   • 用户可能省略了显而易见的背景信息，期望系统能够“理解”。

这些鸿沟直接导致了一个严重的问题：即使我们拥有世界上最好的检索算法（无论是基于关键词的BM25还是基于向量的语义搜索），如果最初的查询本身就是“有缺陷”的，那么检索系统也可能无法找到那些本应高度相关的文档。这正是“召回率”受损的根本原因。

传统检索管道的局限性

在深入探讨查询转换之前，我们先快速回顾一下传统的检索管道及其在处理上述问题时的局限性。

1. 基于关键词的检索 (TF-IDF, BM25)

这类方法依赖于查询词与文档词的重合度。

# 示例：BM25 算法的简化表示
from rank_bm25 import BM25Okapi

corpus = [
    "这是一个关于机器学习的文档。",
    "人工智能是计算机科学的一个分支。",
    "深度学习是机器学习的一个子领域。",
    "我喜欢吃甜的苹果。",
    "苹果公司发布了新的iPhone。",
]

tokenized_corpus = [doc.split(" ") for doc in corpus]
bm25 = BM25Okapi(tokenized_corpus)

query = "机器学习"
tokenized_query = query.split(" ")

doc_scores = bm25.get_scores(tokenized_query)
print(f"查询 '{query}' 的文档得分: {doc_scores}")
# 预期：与“机器学习”直接相关的文档得分较高。

query_synonym = "AI" # 假设用户搜索AI
tokenized_query_synonym = query_synonym.split(" ")
doc_scores_synonym = bm25.get_scores(tokenized_query_synonym)
print(f"查询 '{query_synonym}' 的文档得分: {doc_scores_synonym}")
# 预期：如果文档没有直接出现“AI”，召回率会很低。

局限性：

• 严格依赖词汇匹配：对同义词、上下位词、缩写等不敏感。用户搜索“手机”，文档中只有“移动电话”，BM25可能无法匹配。
• 无法理解语义：它只看词频和词的位置，不理解词语背后的深层含义。

2. 基于向量的语义检索 (Embeddings)

通过将查询和文档都转换为高维向量，并在向量空间中计算相似度（如余弦相似度），来捕捉语义关联。

# 示例：使用 Sentence Transformers 模拟语义检索
from sentence_transformers import SentenceTransformer, util
import torch

# 假设我们已经加载了一个预训练模型
# model = SentenceTransformer('all-MiniLM-L6-v2') # 实际使用时需要下载
# 为了演示，我们模拟一个 embedding 函数
def get_embedding(text):
    # 实际会调用 model.encode(text, convert_to_tensor=True)
    # 这里我们用一个简化的方式来模拟语义相近的词有相近的向量
    if "机器学习" in text or "AI" in text or "人工智能" in text:
        return torch.tensor([0.9, 0.1, 0.2])
    elif "苹果" in text and "水果" in text:
        return torch.tensor([0.1, 0.8, 0.3])
    elif "苹果" in text and ("公司" in text or "iPhone" in text):
        return torch.tensor([0.1, 0.3, 0.8])
    else:
        return torch.tensor([0.5, 0.5, 0.5]) # 默认向量

corpus = [
    "这是一个关于机器学习的文档。",
    "人工智能是计算机科学的一个分支。",
    "深度学习是机器学习的一个子领域。",
    "我喜欢吃甜的苹果。",
    "苹果公司发布了新的iPhone。",
]

corpus_embeddings = [get_embedding(doc) for doc in corpus]

query = "AI"
query_embedding = get_embedding(query)

# 计算余弦相似度
cosine_scores = util.cos_sim(query_embedding, torch.stack(corpus_embeddings))[0]
print(f"查询 '{query}' 的文档语义得分: {cosine_scores}")
# 预期：即使查询是“AI”，也能找到包含“机器学习”或“人工智能”的文档。

query_complex = "苹果公司最近发布了什么新产品？"
query_complex_embedding = get_embedding(query_complex)
cosine_scores_complex = util.cos_sim(query_complex_embedding, torch.stack(corpus_embeddings))[0]
print(f"查询 '{query_complex}' 的文档语义得分: {cosine_scores_complex}")
# 预期：能找到“苹果公司发布了新的iPhone。”

局限性：

• 仍然受限于查询质量：尽管语义向量能捕捉深层含义，但如果原始查询本身就非常模糊、不完整或带有误导性，其生成的向量也可能偏离用户真实意图的“最佳”语义空间。例如，一个过于简短、缺乏上下文的查询，即使嵌入，也可能无法精准指向目标。
• 对长尾和特定领域知识的挑战：预训练模型可能对某些专业术语或新兴概念的理解不足。
• 计算成本：生成高质量的嵌入需要计算资源。

无论哪种检索方式，如果用户只输入了“ML”，而文档是“Machine Learning”，或者用户输入了“如何修理我的电脑”，而文档是“计算机故障排除指南”，那么即使是语义检索也可能因为初始查询的“不完美”而错过最佳结果。这正是查询转换的价值所在。

引入 Rewrite-Retrieve-Read (RRR) 范式

为了克服上述挑战，现代信息检索系统，尤其是问答系统，普遍采用了多阶段的流水线设计，其中“Rewrite-Retrieve-Read”是一个非常流行且高效的范式。

这个范式将复杂的检索和理解任务分解为三个逻辑上独立的阶段，每个阶段都由专门的模型或组件负责：

1. Rewrite (查询转换)：此阶段的目标是接收用户原始查询，并对其进行一个或多个转换，生成一个或多个优化后的查询。这些优化后的查询更适合下游的检索系统。这是我们今天讲座的核心。
2. Retrieve (文档召回)：使用转换后的查询（或查询集）从大规模文档库中高效地召回一组可能相关的文档子集。这个阶段追求的是高召回率，尽可能不遗漏任何潜在相关的文档。
3. Read (信息抽取与阅读理解)：对召回的文档子集进行更深度的分析。这通常涉及一个阅读理解模型（如LLM或BERT-based模型），它会精读这些文档，从中抽取精确的答案，或者对信息进行综合、摘要，最终生成用户友好的回答。这个阶段追求的是高精度。

RRR 范式核心优势：

• 职责分离：每个阶段专注于一个明确的任务，可以独立优化。
• 端到端优化：通过链式处理，每个阶段的输出都作为下一个阶段的输入，从而实现整体性能的提升。
• 灵活性：可以根据具体应用场景替换或调整不同阶段的模型。

深入探究查询转换 (Rewrite)：为何它能显著提升召回率？

现在，我们聚焦于第一个也是最关键的阶段：查询转换。它的核心目标是弥合用户查询与系统理解之间的鸿沟，从而显著提升召回率。

召回率的定义是：在所有实际相关的文档中，系统成功检索到的文档所占的比例。一个好的召回策略意味着“宁可错杀一千，不可放过一个”（当然，是在合理范围内，否则会引入太多噪音）。查询转换正是通过“拓宽搜索的网”来实现这一目标。

1. 查询扩展 (Query Expansion)

这是最直接、最常见的查询转换策略，其核心思想是向原始查询中添加更多的相关词汇或概念，从而增加与文档匹配的机会。

技术手段及对召回率的影响：

• A. 同义词、近义词和相关词扩展：

  • 方法：
    • 词典/本体论 (Thesaurus/Ontology)：维护一个人工构建的同义词表或领域本体。
    • 词嵌入 (Word Embeddings)：在向量空间中查找与查询词最接近的词。
    • LLM驱动：利用大型语言模型（LLM）的强大语义理解能力，生成与原始查询在语义上等价或高度相关的替代表达。
  • 召回率提升：用户可能使用“手机充电器”，但文档中是“移动电源适配器”。通过将“手机充电器”扩展为“手机充电器 OR 移动电源适配器”，我们直接覆盖了词汇不匹配的情况，显著增加了找到相关文档的可能性。

  # 示例：简单的同义词扩展
  synonym_map = {
      "AI": ["人工智能", "机器学习"],
      "ML": ["机器学习", "人工智能"],
      "手机": ["移动电话", "智能手机"],
      "汽车": ["车辆", "轿车", "自动驾驶汽车"],
      "CPU": ["中央处理器", "处理器"],
      "充电器": ["电源适配器", "充电线", "充电头"]
  }
  
  def expand_query_with_synonyms(query: str) -> list[str]:
      expanded_terms = set()
      query_terms = query.lower().split()
  
      for term in query_terms:
          expanded_terms.add(term) # 保留原始词
          if term in synonym_map:
              expanded_terms.update(synonym_map[term])
  
      # 将扩展后的词组合成新的查询
      # 这里可以有多种策略：生成多个查询，或生成一个包含所有扩展词的查询
      return list(expanded_terms)
  
  user_query = "我需要一个手机充电器。"
  expanded_terms = expand_query_with_synonyms(user_query)
  print(f"原始查询: '{user_query}'")
  print(f"扩展词汇: {expanded_terms}")
  # 假设我们生成一个包含所有扩展词的查询，或者对每个扩展词生成一个子查询
  # 新查询可能包括: "手机 充电器 移动电话 智能手机 电源适配器 充电线 充电头"
  
  # LLM 驱动的同义词扩展 (伪代码)
  def llm_expand_query(query: str, llm_client) -> list[str]:
      prompt = f"""
      请为以下查询生成5个语义上等价或高度相关的替代查询，每个查询独立一行。
      查询: {query}
      """
      # response = llm_client.generate(prompt, max_tokens=100)
      # return response.text.strip().split('n')
  
      # 模拟LLM响应
      if "机器学习" in query:
          return [
              "机器学习是什么？",
              "人工智能与机器学习的区别",
              "机器学习算法",
              "ML概念介绍",
              "AI在数据科学中的应用"
          ]
      return ["重写查询1", "重写查询2"] # 占位符
  
  # print(f"LLM扩展查询: {llm_expand_query('机器学习', None)}")

• B. 缩写/简称全称扩展：

  • 方法：维护一个缩写-全称映射表，或利用LLM识别并扩展。
  • 召回率提升：用户搜索“ML”，系统扩展为“ML OR Machine Learning”。这样，即使文档中只出现了全称，也能被召回。

  abbreviation_map = {
      "ML": "Machine Learning",
      "AI": "Artificial Intelligence",
      "NLP": "Natural Language Processing",
      "CPU": "Central Processing Unit"
  }
  
  def expand_abbreviations(query: str) -> str:
      expanded_query = query
      for abbr, full_form in abbreviation_map.items():
          if abbr in expanded_query:
              # 简单替换，实际可能需要更复杂的正则匹配来避免误伤
              expanded_query = expanded_query.replace(abbr, f"{abbr} {full_form}")
      return expanded_query
  
  user_query = "我正在学习ML和AI。"
  expanded_query = expand_abbreviations(user_query)
  print(f"原始查询: '{user_query}'")
  print(f"扩展缩写后: '{expanded_query}'")
  # 结果: "我正在学习ML Machine Learning和AI Artificial Intelligence。"
  # 这可以作为新的查询，或者生成两个查询："我正在学习ML和AI" 和 "我正在学习Machine Learning和Artificial Intelligence"

• C. 上下位词扩展 (Hypernym/Hyponym)：

  • 方法：利用WordNet、领域本体或LLM来识别词语的层级关系。
  • 召回率提升：用户搜索“苹果”（水果），可以扩展为“苹果 OR 水果”。如果文档中提到的是“水果”，也能被召回。反之，用户搜索“水果”，也可以扩展为“水果 OR 苹果 OR 香蕉”。

• D. 上下文或会话历史扩展：

  • 方法：在对话式系统中，利用之前的对话轮次来理解当前查询的省略信息。
  • 召回率提升：用户问“它有什么特点？”，这里的“它”指代前一轮对话中提到的“iPhone 15”。系统将查询扩展为“iPhone 15有什么特点？”，大大提高了找到相关文档的可能性。

• E. 伪相关反馈 (Pseudo-Relevance Feedback, PRF)：

  • 方法：先用原始查询进行一次初步检索，假定前K个召回结果是相关的，然后从这些结果中提取出高频词或关键短语，将它们添加到原始查询中，再进行第二次检索。
  • 召回率提升：通过利用初步检索结果中的“真实”文档词汇，PRF能够有效地将查询引导向更相关的语义空间，从而召回更多相关的文档。

总结查询扩展对召回率的贡献：查询扩展的本质是增加查询与文档之间词汇或语义重合的可能性。通过“拓宽搜索的网”，它能够捕捉到那些由于用户表达方式差异而原本会被遗漏的文档，从而直接而显著地提升召回率。

2. 查询简化/提炼 (Query Simplification/Refinement)

虽然扩展是为了增加覆盖面，但有时查询过于复杂、冗长或包含噪音，反而会降低召回率。简化和提炼旨在去除这些噪音，突出核心意图。

技术手段及对召回率的影响：

• A. 停用词移除 (Selective Stop Word Removal)：

  • 方法：移除对查询核心语义贡献不大的词（如“的”、“是”、“一个”），但要小心，有些停用词（如“不”、“没有”）具有关键的否定语义。
  • 召回率提升：减少噪音词汇可以使核心查询词在检索中获得更高的权重，或使语义嵌入模型更专注于核心概念，从而避免因无关词汇导致的“稀释效应”。

• B. 词形还原/词干提取 (Lemmatization/Stemming)：

  • 方法：将词语还原到其基本形式（如“running”->“run”，“cars”->“car”）。
  • 召回率提升：统一词形有助于匹配那些使用了不同变体的文档。例如，查询“runs”，文档“running”，如果都还原为“run”，则可以匹配。

  import nltk
  # nltk.download('wordnet')
  # nltk.download('punkt')
  from nltk.stem import WordNetLemmatizer
  from nltk.stem.porter import PorterStemmer
  
  lemmatizer = WordNetLemmatizer()
  stemmer = PorterStemmer()
  
  def process_query(query: str, method: str = 'lemmatize') -> str:
      tokens = nltk.word_tokenize(query.lower())
      processed_tokens = []
      for token in tokens:
          if method == 'lemmatize':
              processed_tokens.append(lemmatizer.lemmatize(token))
          elif method == 'stem':
              processed_tokens.append(stemmer.stem(token))
          else:
              processed_tokens.append(token)
      return " ".join(processed_tokens)
  
  query_a = "我正在跑步，我的车在跑道上。"
  print(f"原始查询: '{query_a}'")
  print(f"词形还原后: '{process_query(query_a, 'lemmatize')}'")
  print(f"词干提取后: '{process_query(query_a, 'stem')}'")
  # 预期: "我 正在 跑步 ， 我 的 车 在 跑道 上 。" (lemmatize)
  # "我 正 在 跑 步 ， 我 的 车 在 跑 道 上 。" (stem)
  # 实际应用中，通常只对核心词进行处理。

• C. 移除冗余信息：

  • 方法：识别并移除查询中不必要的修饰词或重复信息。
  • 召回率提升：精简后的查询更聚焦于核心概念，减少了模型在非关键信息上分散注意力的情况，有助于更精准地匹配文档。

• D. LLM驱动的查询重写：

  • 方法：利用LLM将复杂、口语化的查询重写为更简洁、更适合检索的表达。例如，“你能告诉我关于那个新的人工智能工具的一切吗？”可以重写为“最新人工智能工具信息”。
  • 召回率提升：LLM可以理解用户意图，并生成一个“理想”的查询，从而避免原始查询的表述问题。

总结查询简化对召回率的贡献：虽然看起来与扩展相反，但通过去除噪音和聚焦核心，简化后的查询能够更清晰地表达用户意图，减少检索系统被无关信息误导的可能性，从而帮助系统更准确地捕捉相关文档。

3. 查询重构以适应特定检索目标/格式 (Query Restructuring)

有时，查询转换不仅仅是增删词汇，更是改变查询的结构或形式，以更好地适应下游检索系统或特定数据源的要求。

技术手段及对召回率的影响：

• A. 自然语言到关键词/结构化查询：

  • 方法：将完整的自然语言问句转换为更简洁的关键词短语，或转换为结构化查询（如SQL、API参数）。
  • 召回率提升：
    • 关键词：对于关键词检索系统，直接提取核心关键词比整个问句效果更好。
    • 结构化查询：如果后端有结构化数据库或API，将自然语言转换为{"product": "iPhone", "feature": "camera"}这样的结构化参数，可以直接精确查询，避免自然语言匹配的模糊性，从而极大地提高在结构化数据源上的召回率。

  # 示例：LLM 将自然语言转换为结构化查询 (伪代码)
  def llm_to_structured_query(query: str, llm_client) -> dict:
      prompt = f"""
      将以下自然语言查询转换为JSON格式的结构化查询。
      如果查询关于产品，请提取'product'和'feature'。
      如果查询关于航班，请提取'origin', 'destination', 'date'。
      如果无法识别，返回空JSON。
  
      查询: {query}
      """
      # response = llm_client.generate(prompt, max_tokens=100)
      # return json.loads(response.text)
  
      # 模拟LLM响应
      if "iPhone" in query and "相机" in query:
          return {"product": "iPhone", "feature": "camera"}
      elif "从伦敦到巴黎的航班明天" in query:
          return {"origin": "London", "destination": "Paris", "date": "tomorrow"}
      return {}
  
  user_query_product = "iPhone的相机功能怎么样？"
  structured_query_product = llm_to_structured_query(user_query_product, None)
  print(f"原始查询: '{user_query_product}'")
  print(f"结构化查询: {structured_query_product}")
  
  user_query_flight = "从伦敦到巴黎的航班明天有吗？"
  structured_query_flight = llm_to_structured_query(user_query_flight, None)
  print(f"原始查询: '{user_query_flight}'")
  print(f"结构化查询: {structured_query_flight}")

• B. 问答 (QA) 特定的重写：

  • 方法：
    • 去除冗余引导词：“请告诉我……”，“我想知道……”等。
    • 代词消解 (Pronoun Resolution)：将“它”替换为具体的实体。
    • 将声明性语句转换为疑问句：例如，“关于机器学习的信息”转换为“什么是机器学习？”或“机器学习的定义”。
  • 召回率提升：对于专门训练用于回答疑问句的QA模型，将用户查询转换为标准疑问句形式能更好地激活模型的问答能力，从而提高从文档中抽取正确答案的召回率。

总结查询重构对召回率的贡献：通过将查询适配到下游系统的最佳输入格式，我们能够最大化该系统召回相关信息的能力，尤其在混合检索（结构化+非结构化）场景下至关重要。

4. 查询分解与多查询生成 (Query Decomposition & Multi-Query Generation)

对于复杂的、包含多个子意图的查询，将其分解为多个更简单、更聚焦的子查询，然后并行执行检索，可以显著提高召回率。

技术手段及对召回率的影响：

• A. 多方面问题分解：

  • 方法：将一个包含多个方面的查询（如“太阳能的优点和缺点是什么？”）分解为多个独立的子查询（“太阳能的优点是什么？”和“太阳能的缺点是什么？”）。
  • 召回率提升：如果一个文档只讨论优点，另一个文档只讨论缺点，那么原始的复合查询可能无法同时召回它们。通过分解，我们可以确保每个方面都能被独立搜索并召回，从而全面覆盖用户的所有意图。

• B. 假设性答案生成 (Hypothetical Document Embedding, HyDE)：

  • 方法：利用LLM根据原始查询生成一个“假设性”的、可能相关的文档内容。然后，对这个假设性文档进行嵌入，并使用其向量作为检索查询。
  • 召回率提升：HyDE的思路非常巧妙。它将用户查询（通常较短）转换成了一个“文档”（通常较长且信息丰富）。这种转换使得查询的语义表达更加饱满，并且与实际文档的向量空间更匹配。当语义检索器使用这个“文档级”的向量进行搜索时，它能够更好地捕捉到与用户意图高度相关的文档，即使这些文档在词汇上与原始查询差异较大。这是一种强大的、隐式的查询转换，能显著提升语义检索的召回率。

  # 示例：LLM 驱动的查询分解 (伪代码)
  def llm_decompose_query(query: str, llm_client) -> list[str]:
      prompt = f"""
      请将以下复杂查询分解为多个独立的、原子化的搜索查询，每个查询独立一行。
      查询: {query}
      """
      # response = llm_client.generate(prompt, max_tokens=200)
      # return response.text.strip().split('n')
  
      # 模拟LLM响应
      if "太阳能的优点和缺点" in query:
          return [
              "太阳能的优点",
              "太阳能的缺点",
              "太阳能的利弊分析"
          ]
      return ["子查询1", "子查询2"] # 占位符
  
  user_query = "太阳能的优点和缺点是什么？"
  decomposed_queries = llm_decompose_query(user_query, None)
  print(f"原始查询: '{user_query}'")
  print(f"分解后的查询: {decomposed_queries}")
  # 结果: ['太阳能的优点', '太阳能的缺点', '太阳能的利弊分析']
  # 接下来，我们可以对每个子查询进行检索，并将结果合并。

总结查询分解对召回率的贡献：通过将复杂意图拆解，确保每个子意图都能得到充分搜索，避免了“一叶障目”，从而确保所有相关信息的召回。HyDE则通过将查询“升级”为文档级别，更好地利用了语义检索模型的优势。

5. 大型语言模型 (LLMs) 在查询转换中的关键作用

近年来，LLMs的崛起彻底改变了查询转换的格局。它们不再仅仅是规则或统计模型，而是能够进行复杂语义推理和文本生成。

LLMs 如何赋能查询转换：

• 强大的语义理解：LLMs能够理解查询的深层语义，捕捉用户意图，而不仅仅是词汇匹配。
• 上下文感知：可以利用对话历史、用户画像等上下文信息进行更智能的转换。
• 灵活的文本生成：能够生成各种形式的替代查询，包括同义词、解释、总结、结构化输出，甚至整个假设性文档。
• 零样本/少样本学习：无需大量标注数据，通过精心设计的Prompt即可实现多种转换任务。

LLM驱动的查询转换工作流示例：

import openai # 假设使用OpenAI API，或其他LLM客户端
# from dotenv import load_dotenv
# load_dotenv() # 加载环境变量中的API密钥

# def get_llm_response(prompt: str, model: str = "gpt-3.5-turbo", temperature: float = 0.7) -> str:
#     client = openai.OpenAI()
#     response = client.chat.completions.create(
#         model=model,
#         messages=[
#             {"role": "system", "content": "你是一个查询重写助手。"},
#             {"role": "user", "content": prompt}
#         ],
#         temperature=temperature,
#         max_tokens=500
#     )
#     return response.choices[0].message.content.strip()

# 模拟LLM响应函数
def get_llm_response_mock(prompt: str) -> str:
    if "替代查询" in prompt:
        return "人工智能的最新进展nAI技术发展趋势nAI领域新突破n关于人工智能的最新研究n人工智能的未来走向"
    elif "分解为多个独立的搜索查询" in prompt:
        return "机器学习的定义n机器学习的分类n机器学习的常见应用"
    elif "转换为JSON格式" in prompt:
        return '{"product": "智能音箱", "feature": "音质"}'
    elif "澄清这个查询" in prompt:
        return "你是指苹果公司还是水果苹果？"
    return "重写后的查询。"

# 结合LLM的查询转换管道
def llm_powered_query_transformer(user_query: str) -> list[str]:
    transformed_queries = []

    # 1. 语义扩展
    prompt_expand = f"""
    请为以下查询生成5个语义上等价或高度相关的替代查询，每个查询独立一行。
    查询: {user_query}
    """
    expanded_queries_str = get_llm_response_mock(prompt_expand)
    transformed_queries.extend(expanded_queries_str.split('n'))

    # 2. 查询分解 (如果适用)
    prompt_decompose = f"""
    请将以下复杂查询分解为多个独立的、原子化的搜索查询，每个查询独立一行。如果查询本身已经足够原子化，请返回原始查询。
    查询: {user_query}
    """
    decomposed_queries_str = get_llm_response_mock(prompt_decompose)
    decomposed_list = decomposed_queries_str.split('n')
    if len(decomposed_list) > 1 and decomposed_list[0] != user_query: # 避免重复添加原始查询
        transformed_queries.extend(decomposed_list)
    else:
        # 如果没有分解，可以尝试生成一个更简洁的重写
        prompt_simplify = f"""
        请将以下查询重写得更简洁、更适合检索。
        查询: {user_query}
        """
        simplified_query = get_llm_response_mock(prompt_simplify)
        transformed_queries.append(simplified_query)

    # 3. 结构化查询生成 (如果需要调用特定API)
    prompt_structured = f"""
    将以下自然语言查询转换为JSON格式的结构化查询。如果查询关于产品，请提取'product'和'feature'。
    查询: {user_query}
    """
    structured_query_str = get_llm_response_mock(prompt_structured)
    # 实际会解析JSON，这里简化
    if "{" in structured_query_str and "}" in structured_query_str:
        transformed_queries.append(f"STRUCTURED_QUERY:{structured_query_str}")

    # 去重并返回
    return list(set(transformed_queries))

user_query_llm = "最近人工智能有什么新的进展和应用？"
final_queries = llm_powered_query_transformer(user_query_llm)
print(f"原始查询: '{user_query_llm}'")
print(f"LLM生成的最终查询列表: {final_queries}")

LLM在查询转换中的挑战：

• 计算成本和延迟：每次调用LLM都会增加成本和响应时间。
• 幻觉 (Hallucinations)：LLM可能生成不准确或误导性的扩展词或重写。
• 控制性：如何精确控制LLM的输出，使其符合特定的检索策略，需要精细的Prompt Engineering。
• 领域适应性：通用LLM可能在特定垂直领域表现不佳，需要微调或提供领域知识。

为什么查询转换能如此显著地提升召回率？

现在，让我们系统地总结一下，为什么所有的这些查询转换策略，其核心目标和效果都指向一个共同的优势：显著提升召回率。

1. 拓宽搜索的语义网：这是最核心的原因。通过添加同义词、相关词、上下位词，或通过LLM生成多种语义等价的表达，我们极大地扩展了查询所能覆盖的语义空间。这意味着即使文档使用了与用户原始查询不同的词汇表达，只要语义相关，也能被捕捉到。这就像捕鱼时，从只撒一张小网变成撒一张大网，自然能捕到更多的鱼。

2. 弥补词汇和语义鸿沟：查询转换直接应对了用户语言与文档内容之间的天然不匹配问题。无论是显式的词汇替换（如缩写扩展），还是隐式的语义重写（如LLM生成替代查询），都在努力让用户意图以最适合检索系统的方式呈现。

3. 增强查询的鲁棒性：单一的查询是一个脆弱的输入。如果用户表达不精确，或者系统对该特定表达的理解能力有限，那么检索就可能失败。通过生成多个备选查询，我们为检索系统提供了“多条路径”来发现相关文档，从而提高了整体的鲁棒性。即使其中一两个查询效果不佳，其他的查询也可能成功。

4. 适配多样化的文档表示：在复杂的系统中，文档可能以多种形式存在（纯文本、结构化数据、多模态内容）。一个经过转换的查询可以更好地适配这些不同的表示形式。例如，结构化查询用于数据库，关键词查询用于文本索引，而语义查询用于向量数据库。多查询生成允许我们同时利用这些不同的检索机制，全面提升召回。

5. 提升语义检索的有效性 (特别是HyDE)：对于基于向量的语义检索，查询转换尤为重要。一个短小的查询，其向量可能不够“饱满”。通过扩展、重写甚至生成一个假设性文档，我们可以生成更丰富、更具代表性的查询向量，使其在向量空间中更接近真实的、相关的文档向量，从而在语义匹配上取得更好的召回效果。

6. 处理用户模糊或不完整的意图：用户有时并不知道如何精确地表达他们的需求。查询转换可以尝试“猜测”或“澄清”用户意图，生成更多样化的查询，以覆盖用户可能的所有潜在需求。

实践中的查询转换架构

在实际系统中，查询转换通常不是一个单一的模块，而是一个包含多个策略的流水线或混合系统。

转换策略类型	目标	实施技术	召回率提升机制
查询扩展	增加词汇/语义覆盖面	词典、词嵌入、LLM、PRF	捕捉同义、相关、上下位词，拓宽搜索网
查询简化/提炼	移除噪音，聚焦核心意图	停用词、词形还原、LLM	避免噪音稀释，使检索更聚焦核心概念
查询重构/格式转换	适配特定检索目标或数据源	规则、LLM (转关键词/结构化查询)	充分利用后端系统特性，精确匹配结构化数据
查询分解/多查询	处理复杂意图，从多角度搜索	规则、LLM (HyDE、多方面分解)	确保复杂意图的每个部分都被搜索，全面覆盖
上下文感知重写	利用会话/用户历史，补全省略信息	LLM (对话历史分析)	补全用户省略的上下文，使查询更完整

一个典型的架构可能如下：

class QueryTransformer:
    def __init__(self, llm_client, thesaurus=None, abbr_map=None):
        self.llm_client = llm_client
        self.thesaurus = thesaurus if thesaurus else {}
        self.abbr_map = abbr_map if abbr_map else {}
        self.lemmatizer = WordNetLemmatizer()
        self.stemmer = PorterStemmer()

    def _expand_synonyms(self, query: str) -> list[str]:
        # Implement synonym expansion using self.thesaurus or LLM
        # For brevity, returning a mock list
        return [query, f"{query} synonym1", f"{query} synonym2"]

    def _expand_abbreviations(self, query: str) -> str:
        # Implement abbreviation expansion
        return query # Mock

    def _simplify_query(self, query: str) -> str:
        # Implement stemming/lemmatization, stop word removal
        return query # Mock

    def _llm_rewrite(self, query: str, instruction: str) -> list[str]:
        # prompt = f"{instruction}n查询: {query}"
        # response = self.llm_client.get_llm_response(prompt)
        # return response.split('n')
        if "替代查询" in instruction:
            return [query, f"LLM重写_{query}_v1", f"LLM重写_{query}_v2"]
        if "分解" in instruction:
            return [query, f"子查询_{query}_part1", f"子查询_{query}_part2"]
        return [query]

    def transform(self, user_query: str, context: dict = None) -> list[str]:
        all_transformed_queries = set()
        all_transformed_queries.add(user_query) # 始终包含原始查询

        # 1. 基于规则/词典的扩展和简化
        expanded_rule_based = self._expand_synonyms(user_query)
        all_transformed_queries.update(expanded_rule_based)

        simplified_rule_based = self._simplify_query(user_query)
        all_transformed_queries.add(simplified_rule_based)

        # 2. LLM驱动的语义重写和扩展
        llm_expanded = self._llm_rewrite(user_query, "请为以下查询生成3个语义上等价或高度相关的替代查询。")
        all_transformed_queries.update(llm_expanded)

        # 3. LLM驱动的查询分解 (如果查询较长或包含连接词)
        if len(user_query.split()) > 5 or "和" in user_query or "以及" in user_query:
            llm_decomposed = self._llm_rewrite(user_query, "请将以下复杂查询分解为2-3个独立的搜索查询。")
            all_transformed_queries.update(llm_decomposed)

        # 4. 上下文重写 (如果提供了上下文)
        if context and "history" in context:
            contextual_query = f"结合历史对话'{context['history'][-1]}'，重写查询: {user_query}"
            llm_contextual = self._llm_rewrite(contextual_query, "请重写查询以包含上下文信息。")
            all_transformed_queries.update(llm_contextual)

        return list(all_transformed_queries)

class Retriever:
    def retrieve(self, query_list: list[str]) -> list[dict]:
        # 模拟从文档库中检索
        retrieved_docs = []
        for query in query_list:
            # 实际会调用BM25, vector search, or hybrid search
            # 这里简单模拟：如果查询包含某个关键词，就“召回”对应的文档
            if "机器学习" in query or "AI" in query or "人工智能" in query:
                retrieved_docs.append({"id": "doc1", "content": "关于机器学习的详细介绍"})
            if "太阳能" in query:
                retrieved_docs.append({"id": "doc2", "content": "太阳能发电的原理和应用"})
            if "iPhone" in query:
                retrieved_docs.append({"id": "doc3", "content": "iPhone最新功能评测"})
            if "子查询" in query: # 模拟子查询也能召回
                 retrieved_docs.append({"id": "doc_sub", "content": f"与 {query} 相关的片段"})

        # 实际会去重并排序
        unique_docs = {doc['id']: doc for doc in retrieved_docs}.values()
        return list(unique_docs)

class Reader:
    def read(self, docs: list[dict], original_query: str) -> str:
        # 模拟阅读理解和答案生成
        # 实际会用一个更复杂的LLM或阅读理解模型
        if not docs:
            return "抱歉，未能找到相关信息。"

        combined_content = " ".join([doc['content'] for doc in docs])
        # prompt = f"请根据以下文档回答问题: '{original_query}'n文档: {combined_content}"
        # return self.llm_client.get_llm_response(prompt)
        return f"根据找到的{len(docs)}篇文档，关于'{original_query}'的回答是：...n（此处应为LLM根据文档生成的答案）"

# --- 整体流程演示 ---
# 模拟LLM客户端
mock_llm_client = type('MockLLMClient', (object,), {'get_llm_response': get_llm_response_mock})()

transformer = QueryTransformer(mock_llm_client)
retriever = Retriever()
reader = Reader()

user_query_main = "AI最近有什么新进展和应用？"
context_data = {"history": ["我昨天问了关于机器学习的问题。"]}

# 1. Rewrite
transformed_queries = transformer.transform(user_query_main, context=context_data)
print("n--- Rewrite Phase ---")
print(f"原始查询: '{user_query_main}'")
print(f"转换后的查询列表: {transformed_queries}")

# 2. Retrieve
retrieved_documents = retriever.retrieve(transformed_queries)
print("n--- Retrieve Phase ---")
print(f"召回到的文档数量: {len(retrieved_documents)}")
for doc in retrieved_documents:
    print(f"  - Doc ID: {doc['id']}, Content Snippet: {doc['content'][:30]}...")

# 3. Read
final_answer = reader.read(retrieved_documents, user_query_main)
print("n--- Read Phase ---")
print(f"最终答案: {final_answer}")

在这个架构中，查询转换层接收用户查询，并将其转化为一个包含多个、多样化查询的列表。这个列表被送入检索器，大大增加了从文档库中召回相关文档的可能性。即使原始查询可能因为某种原因未能命中，经过转换后的某个查询也极有可能成功。

总结

查询转换是现代信息检索和问答系统中不可或缺的组成部分，尤其在“Rewrite-Retrieve-Read”范式中扮演着核心角色。通过智能地重写、扩展、简化或分解用户查询，我们能够有效弥合用户意图与系统理解之间的鸿沟。

其对召回率的显著提升，源于它能够拓宽搜索的语义网、增强查询的鲁棒性、适配多样化的文档表示，并最终确保即使面对模糊、复杂或不完整的用户查询，系统也能最大化地发现所有相关的文档。随着大型语言模型的普及，查询转换的能力达到了前所未有的高度，使得信息检索系统能够提供更智能、更全面、更令人满意的用户体验。