query-rewriting

查询改写：用扩展、分解、HyDE 和指代消解提升 RAG 召回

补充说明

用户的问题往往不适合直接检索：太短、含指代、口语化、需要多跳推理，或者缺少领域词。查询改写把原始问题变成更适合检索的查询，常见方法包括同义扩展、多查询（Multi-Query）、查询分解、HyDE（先生成假设答案再检索）、Step-back（先问更抽象的问题）和对话指代消解。

改写能提升召回，但会增加一次 LLM 调用的延迟和成本，也可能引入幻觉约束、偏离原意。是否值得，要用同一套评估集对比改写前后的 recall@k、答案正确率和延迟。

常用示例

# 多查询：让 LLM 生成多个改写，分别检索后合并
from langchain.retrievers.multi_query import MultiQueryRetriever
from langchain_openai import ChatOpenAI

retriever = MultiQueryRetriever.from_llm(
    retriever=vectorstore.as_retriever(search_kwargs={"k": 5}),
    llm=ChatOpenAI(model="gpt-4o-mini", temperature=0),
)
docs = retriever.invoke("这个报错怎么修？")

# HyDE：先生成假设答案，再用答案的向量检索
prompt = """根据问题写一段可能的技术文档答案，不要编造具体命令：
问题：{question}
答案："""
hypothetical = llm.invoke(prompt.format(question=question)).content
docs = vectorstore.similarity_search(hypothetical, k=10)

# 对话指代消解：把“它/这个/上面说的”改写成完整问题
rewrite_prompt = """把用户问题改写成独立、可检索的查询，保留原意：
对话历史：{history}
当前问题：{question}
独立查询："""

适用判断：
- 短查询/口语化 → 扩展或改写
- 多跳问题 → 分解成子问题
- 指代/省略 → 对话改写
- 精确词/错误码 → 不要过度改写，保留原词

易错点与排错

• 改写引入不存在的约束：LLM 可能添加原文没有的条件，导致召回偏离；prompt 要求“只改写、不添加事实”。
• 过度扩展：同义扩展太多会引入噪声，稀释原始意图；限制改写数量和温度。
• 丢失精确词：错误码、型号、API 名被“同义替换”后检索不到；明确要求保留原词。
• 延迟和成本翻倍：每次查询多一次 LLM 调用；对低延迟场景用缓存、小模型或只对复杂查询改写。
• 多查询结果重复：多个改写召回同一文档，合并时要去重。
• 指代消解错误：对话历史太长或指代不清时，改写可能指向错误对象；保留原始问题作为兜底。
• 没有评估：改写听起来合理不等于召回提升；用标注集对比改写前后。
• 把改写当万能：如果检索器本身/分块/embedding 有问题，改写只能掩盖症状。

相关命令

• langchain — MultiQueryRetriever 与 RAG 编排。
• llamaindex — 查询改写与路由。
• ragflow — 知识库检索流程。
• graphrag — 多跳/图谱检索。
• hybrid-search — 改写后的混合召回。

参考链接

• LangChain 查询转换
• HyDE 论文
• LlamaIndex 查询改写

读完自测

合上页面，先回答，再展开对照。

1. HyDE 的基本思路是什么？
2. 哪些查询不适合做大幅改写？
3. 查询改写上线前应该比较哪些指标？