第 6 章查询理解与检索链路设计

这一章开始进入 RAG 检索层里另一个非常关键的问题：用户说出来的问题，往往不是一个可以直接拿去检索的好查询。

前面几章已经把这些基础打好了：

数据怎么准备
chunk 和 metadata 怎么设计
embedding、BM25 和混合检索分别解决什么问题

接下来要继续往前走一步：同样一套索引和检索器，为什么用户问法一变，结果就可能差很多。

这背后的核心，不只是检索算法，而是：

你有没有先理解用户问题
有没有把问题改写成更适合检索的形式
有没有在检索前先做过滤和路由
面对复杂文档时，有没有走对检索路径

学这一章时，最值得先建立的判断

用户原始提问和“最终检索查询”往往不是同一个东西
查询理解不是附加优化，而是很多检索稳定性的前提
查询改写、扩写、过滤、路由，都是在降低错误召回和漏召回
很多系统不是索引不行，而是把所有问题都粗暴地走成了一条相同检索链路

这一章会解决什么问题

这一章主要回答四类问题：

为什么用户问题不能直接原样拿去检索
Query Rewrite 和 Query Expansion 在什么场景下有价值
检索前为什么要做 filtering 和 routing
面对大文档、复杂知识和长问题时，检索链路该怎样变化

这一章真正想帮你建立的是一种检索前视角：

在真正查之前，系统要不要先理解一下“用户到底在问什么”
在真正查之前，系统要不要先决定“这类问题该去哪查、该怎么查”

建议阅读顺序

主题模块

读这一章时，建议一直带着的 4 个问题

当前用户输入里，哪些内容适合直接检索，哪些内容需要先改写或拆解
当前问题更适合去哪一路索引里查，是 FAQ、规则库、代码库，还是混合路径
当前查询在进入检索前，是否应该先带上 metadata 边界或业务过滤条件
当前系统检索不稳，问题到底出在索引不行，还是查询本身没有被处理好

关联章节

这一章和第 5 章一起构成检索层的主干。
继续阅读第 7 章重排、排序与结果精选时，会更容易理解为什么“先召回，再精选”必须建立在正确查询理解之上。