布吉岛 Agent

Appearance

6.1.3 查询理解在 RAG 里的作用是什么？ ​

先给结论：查询理解在 RAG 里的作用，是在真正检索之前，先判断用户到底在问什么、缺了哪些关键信息、该以什么形式去查。它本质上是在把“用户表达”转成“检索可用输入”。

所以查询理解不是装饰层，而是检索前的一层问题整理和决策能力。

它到底在补什么 ​

如果只讲最核心，查询理解通常在补 4 类缺口：

  1. 表达缺口：用户说得太口语、太绕、太散
  2. 信息缺口：问题里省略了关键对象或边界
  3. 结构缺口：一个输入里混着多个意图
  4. 路径缺口：系统还不知道这类问题该去哪一路查

也就是说，查询理解做的不是“美化问题”，而是：

  • 降低后续检索犯错的概率

它在链路里的位置更像什么 ​

在一条更完整的 RAG 检索链路里，查询理解通常发生在：

  • 用户输入之后
  • 实际召回之前

一个简化后的链路可以理解成：

  1. 接收用户问题
  2. 识别问题核心和边界
  3. 必要时改写、拆解、补全
  4. 决定该走哪种检索路径
  5. 再进入真正的召回阶段

这说明它在系统里的角色更像：

  • 检索前的整理器和分发器

它会做哪些具体事情 ​

实际系统里，查询理解常见会做这些动作：

  • 指代消解
  • 术语补全
  • 上下文补齐
  • 子问题拆分
  • 意图识别
  • 检索路径路由
  • metadata 过滤条件抽取

并不是每个系统都要全做，但只要问题复杂度上来，通常至少会做其中一部分。

一个更直观的例子 ​

假设用户问：

  • “那企业版这里是不是也一样？”

如果系统不做查询理解，后面几乎没法直接搜。

而如果系统先做了理解，可能会恢复成：

  • “企业版退款规则是否与个人版一致”

或者进一步抽出：

  • 主体：企业版
  • 主题：退款规则
  • 比较对象：个人版

这样后面不管是：

  • query rewrite
  • 路由
  • metadata 过滤

都会稳很多。

为什么它对多轮对话和复杂业务特别重要 ​

在单轮、短句、明确术语问题里，查询理解有时看起来没那么显眼。

但在这些场景里，它会非常关键：

  • 多轮对话
  • 长句输入
  • 复杂业务问题
  • 带边界约束的问题

因为这些问题的共同点是：

  • 原始输入并不直接等于可检索输入

如果系统没有这层能力，后面就只能把所有问题都粗暴交给检索器硬接。

它和 Query Rewrite、Routing 是什么关系 ​

这几个概念很容易混。

可以先这样理解：

  • 查询理解 是总目标：先理解用户到底在问什么
  • Query Rewrite 是其中一种手段：把问题改成更适合检索的形式
  • Routing 也是其中一种手段：决定问题该去哪一路查

也就是说，查询理解是上层概念，而改写、扩写、过滤、路由，都是它可能用到的具体动作。

一个常见误区 ​

很多人会把查询理解理解成：

  • 用 LLM 把问题重写一遍

这太窄了。

更准确的理解是：

  • 查询理解是一层检索前决策能力

它不一定总要重写问题，但要能决定：

  • 要不要改写
  • 要不要拆分
  • 要不要补边界
  • 要不要换一路检索

一句话总结 ​

查询理解在 RAG 里的作用，是把用户表达转成更适合检索的输入。它补的是表达、信息、结构和路径上的缺口，让后面的 query rewrite、过滤、路由和召回都更有机会走对。