Query Rewriting（查询重写）详解：RAG 系统中提升检索效果的四大核心方案

在 RAG（Retrieval-Augmented Generation）系统中，很多人会发现：

模型不一定差，真正差的是“检索”。

用户一句：

“不亮了”

你让向量数据库怎么搜？

所以，Query Rewriting（查询重写）几乎是所有生产级 RAG 系统里的核心模块。

---

一、为什么 RAG 一定需要 Query Rewriting？

很多新手做 RAG 时，流程通常是：

用户问题 → Embedding → 向量检索 → LLM回答

看起来没问题。

但真实用户的问题往往是：

用户输入	问题
“那个报错”	缺少上下文
“怎么搭”	信息不完整
“不亮了”	语义模糊
“能退吗”	场景不明确

这种 Query：

• 信息密度低
• 关键词缺失
• 向量表达弱
• 检索召回差

最终导致：

检索不到 → 上下文错误 → LLM胡说

所以：

很多 RAG 的优化，本质上都在优化 Query。

这就是 Query Rewriting 的核心价值。

---

二、什么是 Query Rewriting？

Query Rewriting（查询重写）：

在用户问题进入检索系统前，对 Query 进行优化、补全、扩展、拆分或转换。

核心目标：

让 Query 更适合“检索”
而不是更适合“人类阅读”

它本质上属于：

用户问题 → 检索语言

的转换过程。

---

三、生产级 RAG 中最常见的四种 Query Rewriting 方案

---

1. LLM Query Rewriting（LLM 查询改写）

---

原理

使用大模型对用户问题进行“语义补全”。

让模糊问题：

“那个报错”

变成：

“运行程序时出现 RuntimeError 的解决方法”

---

示例

原始问题	改写后
不亮了	温湿度传感器指示灯不亮如何排查
怎么搭	如何搭建嵌入式实验环境
那个报错	RuntimeError 的解决方案
能退吗	实训设备退款流程是什么

---

Prompt 设计

REWRITE_PROMPT = """
你是一个查询优化专家。

请将用户问题改写为更适合知识库检索的形式。

要求：
1. 补充缺失上下文
2. 消除模糊指代
3. 保持原意
4. 输出改写结果，不要解释

用户问题：
{query}

改写后：
"""

---

LangChain 实现

from langchain_core.prompts import PromptTemplate
from langchain_openai import ChatOpenAI

prompt = PromptTemplate.from_template("""
请优化用户问题用于知识库检索：

用户问题：
{query}

优化后：
""")

llm = ChatOpenAI(
    model="gpt-4o-mini",
    temperature=0
)

chain = prompt | llm

result = chain.invoke({
    "query": "那个报错"
})

print(result.content)

---

优点

1. 效果非常好

LLM 可以理解语义。

这是规则系统完全做不到的。

---

2. 泛化能力强

新领域、新设备、新问题都能处理。

---

3. Prompt 可控

可以针对：

• 医疗
• 法律
• 电商
• 客服

分别优化。

---

缺点

问题	说明
延迟高	多一次 LLM 调用
成本高	消耗 Token
依赖模型	LLM 挂了整个链路受影响

---

适用场景

推荐用于：

• 智能客服
• 企业知识库
• AI 问答系统
• 高质量 RAG

---

2. HyDE（Hypothetical Document Embeddings）

---

什么是 HyDE？

HyDE 全称：

Hypothetical Document Embeddings

核心思想：

不直接检索问题，
而是先生成“假设答案”，
再用假设答案去检索。

---

为什么有效？

因为：

问题 和 答案
在向量空间里通常距离很远

例如：

用户 Query：

温湿度传感器不亮怎么办

真实文档：

检查供电、检查接线、检查主控板...

二者词汇差异巨大。

所以：

Query embedding ≠ Document embedding

HyDE 通过生成：

“检查供电、检查接线...”

这种“伪答案”，让检索更贴近真实文档。

---

流程图

用户问题
   ↓
LLM生成假设答案
   ↓
Embedding
   ↓
向量检索
   ↓
返回相关文档

---

示例

用户问题

温湿度传感器不亮了怎么办

LLM 生成假设答案

首先检查电源连接，
其次检查接线是否松动，
最后检查传感器是否损坏。

再进行检索

此时召回质量会明显提升。

---

LangChain 实现

from langchain_core.prompts import PromptTemplate
from langchain_openai import ChatOpenAI

hyde_prompt = PromptTemplate.from_template("""
请根据问题生成一个可能的答案：

问题：
{query}

假设答案：
""")

llm = ChatOpenAI(model="gpt-4o-mini")

hyde_chain = hyde_prompt | llm

result = hyde_chain.invoke({
    "query": "传感器不亮了怎么办"
})

print(result.content)

---

优点

1. 技术问答效果非常强

因为技术文档答案结构稳定。

---

2. 检索语义更接近真实文档

尤其适合：

• FAQ
• 运维
• 技术支持

---

缺点

1. 容易“带偏”

如果 LLM 幻觉严重：

假设答案错了
→ 检索方向全错

---

2. 成本高

同样多一次 LLM 调用。

---

3. Query Decomposition（查询分解）

---

原理

把复杂问题拆成多个子问题。

---

示例

用户问题：

如何搭建实验环境并配置传感器？

拆分后：

1. 如何搭建实验环境？
2. 如何配置传感器？

分别检索：

环境文档 + 传感器文档

最后合并。

---

为什么重要？

因为：

复杂问题通常无法一次召回

尤其：

• 多跳问题
• 多领域问题
• 长问题

单次 embedding 很容易失败。

---

Prompt

DECOMPOSE_PROMPT = """
请将问题拆分为多个独立子问题：

问题：
{query}

输出：
"""

---

优点

1. 适合复杂任务

比如：

安装 + 配置 + 调试

---

2. 提高召回覆盖率

每个子问题都能精准检索。

---

缺点

问题	说明
实现复杂	多轮检索
延迟高	多次 embedding
成本高	多次 LLM 调用

---

适用场景

推荐：

• 企业 Copilot
• 法律 AI
• 学术问答
• 多步骤任务

---

4. Rule-based Query Rewriting（规则改写）

---

原理

不用 LLM。

纯规则。

---

常见规则

规则	示例
同义词扩展	传感器 → 检测器
停用词清理	那个、这个
拼写纠正	传敢器 → 传感器
缩写展开	MCU → 单片机

---

示例代码

SYNONYMS = {
    "传感器": ["检测器", "探头"],
    "实验箱": ["开发板", "实训箱"]
}

def rewrite(query):
    expanded = query

    for k, v in SYNONYMS.items():
        if k in query:
            expanded += " " + " ".join(v)

    return expanded

print(rewrite("传感器不亮"))

---

优点

优点	说明
快	毫秒级
稳定	不依赖 LLM
免费	零 Token 成本

---

缺点

1. 无法理解语义

只能匹配规则。

---

2. 泛化能力差

新问题容易失效。

---

3. 维护成本高

规则会越来越多。

---

五、生产环境怎么选？

---

小型项目

直接：

规则改写 + LLM Rewrite

够用了。

---

技术问答系统

推荐：

LLM Rewrite + HyDE

效果非常强。

---

企业级 RAG

推荐：

规则改写
    ↓
LLM Rewrite
    ↓
Query Decomposition
    ↓
HyDE

形成多阶段 Query Pipeline。

---

六、总结

Query Rewriting 是：

RAG效果优化的核心模块

甚至很多时候：

优化 Query
比优化模型更重要

四种核心方案：

方案	特点
LLM Rewrite	通用最强
HyDE	技术问答神器
Query Decomposition	复杂问题处理
Rule-based	低成本高性能

建议：

不要只做向量检索
一定要做 Query Pipeline

否则：

你的 RAG 很容易变成：
“检索不到 → LLM胡编”

---

八、后续系列（预告）

后面我还会继续更新：

• RAG 多路召回详解
• Rerank 重排序原理
• Chunk 切分策略
• GraphRAG 原理
• Agentic RAG 架构
• 企业级 RAG Pipeline
• LangChain / LangGraph 实战

如果这篇对你有帮助，欢迎关注。