数据、检索与 RAG进阶已核验核验于 2026-08-20

查询改写

Query Rewriting

根据用户意图把原始查询改写为更适合检索系统处理的表达,以提高召回和精确度。

本页目录
快速跳转

它是什么

查询改写是根据用户意图把原始查询改写为更适合检索系统处理的表达,以提高召回和精确度。在数据、检索与 RAG中,查询改写主要用于口语化的提问改写成更容易命中的检索式,用于提升召回。[S1][S2]

为什么需要它

掌握查询改写的核心价值在于明确其适用范围与设计目标。如果脱离具体业务约束,有改错的风险,改写一旦偏离原意,检索会自信地找到一堆无关内容。作为数据、检索与 RAG的核心概念,透彻掌握查询改写有助于推导整个系统的设计基准。

它如何工作

在系统运转过程中,查询改写的实现重点在于输入约束、中间处理与输出验证的闭环。具体到工程落地,围绕「把口语化的提问改写成更容易命中的检索式,用于提升召回」这一核心任务,查询改写在运行时会针对输入与约束进行动态校验,并通过标准处理链路达成预期状态。通过将抽象目标拆解为可复核的步骤,查询改写能够稳定支撑上层应用的业务逻辑。

必须澄清的误会

查询改写 ≠ 检索。 查询改写发生在检索之前且作用于问题本身,检索作用于资料集合。 查询改写 ≠ 上下文检索。 查询改写改的是问句,上下文检索调整的是搜索范围,一个动输入一个动集合。

真实例子

例如在推进数据、检索与 RAG相关的实际工程中,团队若要达成把口语化的提问改写成更容易命中的检索式,用于提升召回。,往往会以查询改写作为关键控制点或评价标准。深入研读 Writing best practices to optimize RAG applications 和 Data Services Chunking Strategies 中给出的案例与方案,能够清晰还原查询改写在端到端链路里的输入输出约束与实际运转效果。

什么时候适合与不适合

适合的场景:当系统面临明确的需求,且目标集中在把口语化的提问改写成更容易命中的检索式,用于提升召回时,引入查询改写能提供坚实的方法论支撑与执行标准。

不适合的场景:如果面临超出边界的挑战,尤其是有改错的风险,改写一旦偏离原意,检索会自信地找到一堆无关内容,切忌将查询改写作为兜底方案,否则容易引发过度设计或隐藏系统瓶颈。

亲自试一下

拿一件你正在处理的事试一次:用约 30 分钟,收集 10 条用户的原话提问,手工改写成检索式,比较改写前后的召回差异。

接下来学什么

建议接着研读 检索增强生成 与 检索,从不同维度审视查询改写与其他架构模块的协同配合。将查询改写放回整体生命周期中审视,有助于形成更加立体的系统认知。

来源与修订

本篇关于查询改写的内容参考了 Writing best practices to optimize RAG applications 和 Data Services Chunking Strategies 等专业文献与行业实践规范。技术核验完成于 2026-08-20,若后续该领域的官方接口规范、学术共识或基准评测出现重大更新,应基于一手变更事实启动对查询改写正文的同步修订。

Learning navigation

学习导航

沿认知链路:你现在在第 3 站,下一站是「给手脚 · 怎么让它做事」:先沿主路径补上这一层。

Relation topology

概念关系

本词条在知识拓扑中的连接关系。涵盖前置依赖、组成要素、对比差异与应用场景。

拓扑图谱网络 · 一度关联场

可拖拽节点、滚轮缩放、点击节点探索

Local relation field

查询改写的一层关系

2 个节点 · 1 条直接关系

关系类型
图谱进入视口后加载

交互图谱之外,本页下方保留完整文字关系与词条链接。

Related names

相关名词

下面这些名字与「查询改写」讲的是同一块知识,内容已并入本页, 不再单独作为入口出现。保留链接是为了让旧地址仍然能打开。

  • 查询扩展Query Expansion

    与同域词条「查询改写」讲的是同一块知识,不再单独作为入口;内容已并入该词条,本页只作旧链接的落点。

Source register

核验来源

  1. Writing best practices to optimize RAG applicationsAWS · 访问于 2026-07-29
  2. Data Services Chunking StrategiesDigitalOcean · 访问于 2026-07-29

发布 2026-08-20 · 更新 2026-08-20 · 核验 2026-08-20