RAG 检索不准？先别换模型，把问题问对再说

做了 RAG，效果就是差那么一口气——检索到的文档和问题沾边但不够准，生成的答案看起来头头是道但关键信息不对，复杂一点的组合问题就翻车。换更大的模型？改 embedding？加更多文档？试了一圈，效果还是不痛不痒。

问题到底出在哪？

大多数人的 RAG 优化是”头痛医头”——检索不准就换 embedding，回答不对就改 prompt，流程问题漏步骤就调大 topK。这些操作本身没错，但缺少一个系统性的优化框架。

RAG 不是只有”检索 + 生成”两步。把一个完整的 RAG 链路拆开来看，至少可以拆出 6 个独立阶段，每个阶段都有对应的优化策略。很多系统的瓶颈，恰恰藏在被忽略的阶段里——尤其是最前面的几个。

本文是 RAG 优化全景图的上篇，聚焦查询侧优化：在问题进入检索器之前，先让它变聪明。下篇将覆盖索引、检索和生成阶段。

RAG 6 阶段优化全景图

先看一张全景图，建立整体认知：

RAG 6阶段优化全景图：查询转换、路由、查询构建、索引、检索、生成六个阶段对应的优化策略

优化原则：传递更准的内容 → 重要的靠前放 → 不相关的尽量剔除

核心认知：RAG 优化的本质就三件事——（1）传递更准确、更相关的内容给 LLM；（2）让重要的内容排在前面，充分利用注意力机制；（3）尽可能剔除不相关内容，减少干扰和幻觉。所有优化策略，最终都在服务这三个目标。

另外，有一个容易忽略的事实：优化策略不是越多越好。每多加一层优化，就多一次 LLM 调用或模型计算，成本和延迟都会增加。合理的做法是根据场景选择性价比最高的策略组合。

上篇聚焦前三个阶段——在检索发生之前，把查询优化到位。

阶段一：查询转换（Query Transformation）

目标：把用户输入的原始问题，转换成更适合检索的形态。

这是最容易被跳过的阶段。很多人拿到用户问题直接丢给检索器，但用户的问题往往是模糊的、多意图的、口语化的。检索器理解不了这些”潜台词”。

1. 多查询重写（Multi-Query Rewriting）

核心思路：从多个角度重写用户问题，每个角度独立检索，最后合并去重。

用户问题："怎么提升 RAG 效果？"
        │
        ▼
    LLM 生成 3 个变体：
    ① "RAG 系统性能优化方法有哪些？"
    ② "检索增强生成的准确率如何提升？"
    ③ "RAG 应用中常见的优化策略是什么？"
        │
        ▼
    3 路并行检索 → 合并去重 → 唯一文档列表

多查询重写策略运行流程

优点：实现简单，小参数模型即可完成转换；并行检索性能高；能有效应对模糊查询。
缺点：合并时需要处理冗余和权重问题。

Prompt 模板（如果所用模型支持，可从低随机性配置开始；temperature=0 也不能保证跨请求、模型版本和运行环境完全一致）：

你是一名人工智能语言模型助手。你的任务是针对给定的用户问题生成 3 个不同版本，
以便从向量数据库中检索相关文档。
通过生成用户问题的多角度表述，你的目标是帮助用户克服基于距离的相似性搜索的某些局限性。
请用换行符分隔这些替代问题。
原始问题：{question}

LangChain 实现：

# LangChain v1 需要额外安装 langchain-classic
from langchain_classic.retrievers import MultiQueryRetriever

retriever = MultiQueryRetriever.from_llm(
    retriever=base_retriever,   # 基础检索器，必填
    llm=llm,                    # 用于生成变体问题，必填
    prompt=custom_prompt,        # 可选，有默认值
    include_original=True        # 是否保留原始问题一起检索
)

适用场景：用户问题比较开放、意图模糊的场景。成本低、见效快，是上手 RAG 优化的首选策略之一。

2. 问题分解（Question Decomposition）

和多查询重写不同，问题分解针对的是复杂组合问题——一个问题里包含多个子步骤，需要按顺序解决。

比如用户问”新员工入职需要走哪些审批，每个审批要找谁？“——这个问题包含两个层次：（1）流程步骤是什么；（2）每个步骤的负责人是谁。直接检索很难同时命中两个维度的信息。

问题分解有两种模式：

迭代式（深度优先）：子问题之间有强依赖，上一步的答案决定下一步怎么做。

  用户问题
     │
     ▼
  拆分子问题
     │
     ▼
  检索 + 回答 Q1
     │
     ▼
  带着上下文检索 + 回答 Q2
     │
     ▼
  汇总最终答案

并行式（广度优先）：子问题相对独立，可以同时处理。

  用户问题
     │
     ▼
  拆分子问题
     │
┌────┼────┐
▼    ▼    ▼
Q1   Q2   Q3
│    │    │
▼    ▼    ▼
A1   A2   A3
└────┼────┘
     ▼
  汇总最终答案

问题分解策略：迭代式与并行式运行流程

LangChain 没有为问题分解封装现成的检索器，需要自己构建：先用一条链做问题分解，然后迭代执行检索和回答，将上一轮的答案带入下一轮。

关于流程类问题的深层分析，可以参考本系列第一篇：RAG 为什么回答流程问题会漏步骤？，里面讨论了双层上下文方案来解决流程完整性问题。

3. HyDE（假设性文档嵌入）

这个策略的思路非常巧妙：让 LLM 先根据用户问题”编”一篇假设性文档，然后用这篇文档的向量去检索。

为什么有效？因为用户问题和知识库文档往往处于不同的语义空间——问题是”问句”，文档是”陈述句”。直接用问句做向量检索，语义距离可能较大。但如果先让 LLM 把问句扩展成一篇假想的回答，这篇假想回答的向量就和真实文档更接近了。

用户："怎么配置 Nginx 反向代理？"
        │
        ▼
    LLM 生成假设文档：
    "配置 Nginx 反向代理需要在配置文件中
     设置 proxy_pass 指令，指定后端服务器
     地址和端口，然后重载 Nginx 服务..."
        │
        ▼
    用假设文档的向量去检索 → 更高的召回率

优点：能显著提升问答和文档语义空间不一致时的检索效果。
缺点：多了一次 LLM 调用，增加延迟和成本。
适用场景：用户提问风格和知识库文档表达风格差异较大的场景。

4. 多查询结果融合（RRF）

当你有多个检索结果来源时（比如多查询重写产生的 3 路结果，或者向量 + 关键词两路结果），怎么合并排序？

RRF（Reciprocal Rank Fusion） 是实践中效果最好的融合算法之一。核心思路：文档在越多检索结果中排名靠前，最终排名就越高。

score(d) = Σ 1 / (k + rank_i(d))

其中 k 是平滑常数（通常取 60），rank_i(d) 是文档 d 在第 i 路检索结果中的排名。

RRF 不依赖具体分数绝对值，只关心相对排名，因此不同检索器的分数尺度差异不会影响融合效果。多查询重写 + RRF 是性价比很高的组合。

阶段二：路由（Routing）

目标：根据查询类型，把问题分发到最合适的处理路径。

不是所有问题都应该走向量检索。用户问”今天天气如何”就该走搜索引擎，问”帮我算 123 × 456”就该走计算器，问”XX 产品的报价”才走知识库。

1. 动态路由

用 LLM 或规则引擎判断查询意图，动态选择检索路径：

用户提问
    │
    ▼
  LLM 意图识别
    │
    ├── 知识库查询 → 向量数据库
    ├── 实时信息   → 搜索引擎 API
    ├── 数值计算   → 计算器工具
    ├── 结构化查询 → SQL / 图数据库
    └── 闲聊     → 直接回答（跳过检索）

优点：避免不必要检索，提升效率；不同类型问题走最优路径。
实现：可以基于少量示例（few-shot）让 LLM 做路由分类，也可以用规则引擎做关键词匹配。如果追求低延迟，先用规则引擎做第一层过滤，兜底再交给 LLM 判断。

2. 图查询

如果知识有明确的实体和关系（比如组织架构、产品依赖、审批链），用图数据库（Neo4j 等）存储知识图谱，通过图查询直接获取结构化信息。比如查询”张三的直属领导是谁”，图查询比向量检索精确得多，而且可解释。

图查询和向量检索不是互斥的——可以先用图查询拿到精确的结构化信息，再让向量检索补充周边的非结构化上下文。

阶段三：查询构建（Query Construction）

目标：在检索之前，确保最终提交给检索器的查询语句是高质量的。

1. 问题重建

与查询转换不同，问题重建更聚焦于优化单条查询的表达：去掉冗余词、补充缺失上下文、将口语化表达转为正式表达。比如把”那个什么来着，就是上传文件那个接口”重写为”文件上传接口的使用方法”。

区别在于：多查询重写是”一变多”扩大覆盖面，问题重建是”一换一”提升精度。两个可以组合：先重建一个精确版本，再从多个角度生成变体。

2. 自检索（Self-Retrieval）

让 LLM 自己判断是否需要检索。有些问题 LLM 用自身知识就能回答（比如”Python 是什么”），这种情况下跳过检索可以节省成本。

用户提问 → LLM 判断 → 需要检索 → 走检索链路
                    → 不需要   → 直接回答

优点：减少不必要的检索调用，降低延迟和成本。
注意：需要 LLM 有较好的判断能力，避免误判导致遗漏关键信息。建议给判断 Prompt 加几个典型示例（few-shot），提高分类准确率。

上篇到此，覆盖了 RAG 链路的前三个优化阶段。总结一下：

阶段	核心策略	一句话
查询转换	多查询重写、问题分解、HyDE、RRF 融合	把模糊问题变成多个精准查询
路由	动态路由、图查询	把问题分发到最合适的处理路径
查询构建	问题重建、自检索	让最终提交的查询语句尽量干净

这三个阶段有一个共同的目标：在检索发生之前，把查询优化到最佳状态。这也是最容易被忽视的优化环节——很多人直接把用户原话丢给检索器，然后抱怨检索效果不好。

下篇将进入核心链路：索引、检索和生成阶段，覆盖分块策略、RAPTOR、混合检索、ReRank、Self-RAG、CRAG，以及场景化选型指南和评估体系。

本系列文章：

第一篇：RAG 为什么回答流程问题会漏步骤？ — 流程类 RAG 的专项问题与双层上下文方案

第二篇：企业级 RAG 怎么落地？ — 知识治理、权限、安全与运营闭环

第三篇：本文 — 查询转换、路由与查询构建

第四篇：优化全景图（下）：索引、检索与生成 — 打通检索到生成的最后一公里