RAG :查询改写(Query Rewriting)
2026/6/7 10:17:52 网站建设 项目流程

RAG 实际业务中,用户查询常存在意图不明确的问题。

即便采用更好的检索技术方案,收益可能并不能达到预期。

因此,在检索开始之前,对用户查询进行改写,可以增加检索到最相关内容块的可能性。

这一转化过程,即查询改写(Query Rewriting)

相比于一上来就直接优化构建检索器,通过改写来适配查询获得的收益可能更快、更直接。

查询改写器将查询转化为检索器的表示空间,能够兼容不同的检索器和索引类型。

为什么需要查询改写

用户查询的典型缺陷

大部分情况下,用户提出的查询往往语义模糊或缺乏必要的语境。

检索器因缺少必要的上下文信息,返回的结果往往偏离用户真实需求。

比如:

  • 表达模糊:口语化、省略关键实体
  • 指代不清:多轮对话中的代词(如“它”、“那个”)无法直接用于检索
  • 词汇鸿沟:日常语言提问,而知识库以专业术语建索引
  • 隐含意图:问题背后的真实信息需求未被显式表达

RAG 常应用于多轮对话场景,其中查询包含口语省略及对话上下文中的模糊指代,使系统难以准确理解用户意图。

检索系统本身的缺陷

RAG 检索层无论是采用稠密向量检索还是稀疏关键词检索,都存在一个固有缺陷:

检索器只能被动地计算查询与文档的相似度,缺乏对查询意图的主动理解与补全能力。这使得检索效果高度依赖查询质量。

稀疏检索(如 BM25)受限于词项精确匹配,难以解决同义词或一词多义问题;稠密检索虽能捕捉语义,但仍对查询措辞(如否定词、细节限定)十分敏感。

因此,即使检索系统本身的索引和排序算法足够好,低质量的原始查询也会导致相关文档无法被召回。

传统查询改写方案

查询规范化

这是最基础的规则改写,几乎适用于所有生产系统。

文本清洗类

  • • 全角转半角:"AI技术" → "AI技术"
  • • 繁简转换:"機器學習" → "机器学习"
  • • 大小写统一:"GOOD job" → "good job"
  • • 停用词过滤:去掉“的”、“了”、“请问”、“帮我”等无检索价值词
  • • 标点符号归一化:去掉多余的感叹号、省略号等

拼写纠错类

  • • 编辑距离纠错:将“机器鞋习”纠正为“机器学习”
  • • 基于语言模型的纠错:上下文感知,处理同音字错误(如“人工指能” -> “人工智能”)
  • • 键盘距离模型:针对拼音输入法的误触纠错

同义词与词典扩展

  • 基于同义词词库:将查询词映射到同义词集合,如“购买” -> “买入/采购/入手/下单”
  • 领域词典映射:行业术语规范化,如“心梗” -> “心肌梗死”;缩写展开如“AI” -> “人工智能”
  • 上下位词扩展:泛化(“德牧” -> “大型犬”)或具体化(“手机” ->“iPhone/华为/小米”),用于调整召回粒度

基于词频统计的改写

  • TF-IDF 关键词抽取:从查询中抽取高权重词,重构短查询
  • Query Likelihood + PRF:先检索 top‑k 文档,从中抽取高频词反向扩展查询,代表方法 RM3
  • 互信息(PMI)扩展:加入与查询词点互信息最高的词,如“苹果 手机”扩展出“iOS/屏幕/摄像头”

语言学规则改写

  • 词形还原与词干提取:“购买了/购买过/买了” -> “购买”
  • 句法变换:疑问句改为陈述句(“如何治疗高血压?”->“高血压治疗方法”),注意否定词处理
  • 实体识别 + 规则替换:将“去年”映射到具体年份,“这里”填入上下文地名,“几百万”扩展为范围查询

模板化改写

  • 意图模板匹配:根据预定义模板改写,如“XX 怎么用”:{产品名} 使用教程/使用方法/操作指南
  • 槽位填充:识别意图和槽位后回填,如query_weather+ location=北京, time=明天 转成 “北京 明天 天气预报”

现代查询改写方案

LLM的推理能力越来越强大,基于 LLM 的改写方案也非常成熟。

基于生成的单查询改写

HyDE(Hypothetical Document Embeddings):让 LLM 先生成一篇假设性答案文档,再将该文档的向量用于检索真实语料。这将查询空间从“问题侧”拉向“文档侧”,显著提升语义对齐效果。(注意区分,跟解析后chunk向量时的假设性不一样)

推理增强改写(Reasoning‑Enhanced Rewriting):传统改写直接输出新查询;推理增强改写则让模型先在<think>标签内完成链式推理,再输出最终改写结果,特别适合多跳推断问题。

查询分解

针对复杂、多跳问题,单次检索往往难以覆盖所有必要信息。

查询分解将一个复杂问题拆解为若干可独立检索的子问题,每个子查询独立经过 RAG,最终合并结果。

比如:原始查询:“阿良是谁,他后来恢复十四境了没有?”
-> 子问题1:“阿良是谁?”
-> 子问题2:“阿良后来恢复十四境了没有?”

(langchain的MultiQueryRetriever)

注意:分解不同于并行执行多个独立简单查询(如“阿良是谁?陈平安是谁?”),后者应归类为多查询并行而非分解。

多视角改写

多视角改写从不同角度生成多个查询变体,通过多路召回与结果融合提升召回率。

Agentic RAG 中的动态改写

如果是走 Agentic RAG 的模式,查询改写可以从一次性的静态操作转为智能体推理循环中的动态执行。

因为Agentic RAG 采用持续自适应的检索策略,若初始检索结果不完整或不相关,智能体会重写查询、调整检索策略或执行多跳检索,直到对答案有足够信心或达到预算上限。

相对“检索‑生成”的固定流程来说,Agentic RAG 是一个集规划、检索、推理、批判、改写和反思于一体的自主循环系统。在该循环中,改写可以作为智能体可调用的独立工具,也可以在内部状态中动态修改查询字符串。

结语

不要瞎改写

  • 过度扩展:添加过多词汇增加噪声、降低精度并增加成本
  • 语义漂移:LLM 改写可能改变原意或引入幻觉
  • 延迟与成本开销:额外 LLM 推理增加响应时间和费用

注意,假设查询改写不是总能改善检索效果的,搞不好还可能适得其反。

策略选择

用户查询视是原材料,需要先规范化、扩展,甚至在某些情况下拒绝查询,引导用户重新描述更清晰的提问。

利用 LLM 将模糊问题改写为包含显式实体和约束的结构化查询。

评估体系

  • 检索层指标:Recall@K、MRR、NDCG
  • 生成层指标:需关注检索失败、模型忽略检索上下文、文档间矛盾信息、知识库空白等失效模式

这个就是老生常谈的了,建立自动化的查询改写评估流程是系统性发现问题的关键。

学AI大模型的正确顺序,千万不要搞错了

🤔2026年AI风口已来!各行各业的AI渗透肉眼可见,超多公司要么转型做AI相关产品,要么高薪挖AI技术人才,机遇直接摆在眼前!

有往AI方向发展,或者本身有后端编程基础的朋友,直接冲AI大模型应用开发转岗超合适!

就算暂时不打算转岗,了解大模型、RAG、Prompt、Agent这些热门概念,能上手做简单项目,也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料,手把手帮你快速入门!👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型(GPT、文心一言等)特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架(LangChain等)实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块,看似清晰好上手,实则每个部分都有扎实的核心内容需要吃透!

我把大模型的学习全流程已经整理📚好了!抓住AI时代风口,轻松解锁职业新可能,希望大家都能把握机遇,实现薪资/职业跃迁~

这份完整版的大模型 AI 学习资料已经上传CSDN,朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询