在 RAG（检索增强生成）系统的技术版图中，Query 改写（Query Rewrite）是一个常被初学者忽视、却被面试官视为"实战试金石"的核心模块。

为什么这么说？当我们深入分析用户在实际场景中提出的问题时，会发现一个根本性的语言鸿沟：用户使用自然、口语化的表达方式描述问题，而知识库中的内容往往以结构化、正式化的文档形式存在。这两种"语言体系"之间的 gap，恰恰是 Query 改写技术需要填补的空间。

举一个典型的例子：用户问"报销怎么弄"，看似简单直接。但对于系统来说，这却是一道"送命题"——是差旅报销、项目经费还是采购报销？在哪个系统提交？审批流程是什么？这些问题在用户的单次提问中完全缺失。

Query 改写的核心使命，正是将这种模糊的、碎片化的用户问题，"翻译"成系统能够理解、能够检索、能够匹配的标准问题表达式。改不好，召回就歪；召回错了，答案再完美也是空中楼阁。

第一章：三种主流 Query 改写方案

在实际工程中，Query 改写主要有三种技术路线，从简单到复杂，从规则到智能，各有适用场景。

1.1 规则改写：最朴素的起步方案

规则改写是最基础也是最直接的方案，其核心思想是通过预定义的规则模板对用户 Query 进行转换和增强。

主要技术手段包括：

• 关键词补全：补充 Query 中缺失的关键实体，如"报销"补充为"差旅费用报销流程"

• 同义词替换：将口语词汇映射到标准术语，如"弄"替换为"申请"、"办理"

• 映射表扩展：建立问题到标准模板的映射关系，如"如何报销"映射到"费用报销申请流程说明"

规则改写的优势非常明确：快。如果系统今天立项，明天就能上线。规则改写的实现成本极低，不需要训练数据，不需要模型部署，维护逻辑清晰可解释。

然而，缺点同样明显。规则的覆盖范围极其有限，一旦用户问题稍微复杂或表达方式超出预设规则，系统就会"顶不住"。规则改写本质上是"人工打补丁"，无法应对千变万化的自然语言表达。

1.2 传统 NLP 改写：轻量级语义增强

相比规则改写的"机械感"，基于传统 NLP 技术的 Query 改写能够捕捉一定程度的语义信息，在效果上实现了质的飞跃。

核心技术栈包括：

• 命名实体识别（NER）：从 Query 中提取关键实体，如"报销人"、"金额"、"时间"等

• 同义词扩展：基于领域词典进行语义层面的词汇扩展

• 句子改写与复述：通过句法分析进行表达形式的转换

• 语义融合：综合多维度信息生成优化后的 Query

传统 NLP 方案的优势在于效果提升明显、推理速度较快、计算成本可控。它不需要 GPU 资源，在 CPU 环境下即可高效运行，非常适合大规模的生产场景。

但它的局限性也很清晰：跨领域泛化能力差。换一个行业、一套业务逻辑，就需要重新构建词典和规则。此外，面对"我之前说的那个产品怎么样了"这类强上下文依赖的复杂问题时，传统 NLP 往往力不从心——它缺乏对对话历史的理解和多轮语义的整合能力。

1.3 大模型改写：现代 RAG 的主流选择

如果说前两种方案是"及格线"，那么基于大语言模型的 Query 改写则是企业级 RAG 系统的"必答题"，也是面试官最希望听到的技术方案。

大模型改写的强大之处体现在三个核心能力：

能力一：上下文理解与跨轮补全

这是大模型改写的标志性优势。在多轮对话场景中，用户的问题往往是对前文的省略或指代：

用户：你知道马斯克是谁吗？
助手：埃隆·马斯克是...
用户：那他创立的公司呢？
→ 原始Query：他的公司
→ 改写后：马斯克创立了哪些公司

面对"他的公司"，传统系统会直接对"他的公司"进行检索，结果必然是语义模糊的。而大模型能够理解"他的"指代"马斯克"，将 Query 改写为"马斯克创立了哪些公司"，实现准确的跨轮语义补全。

能力二：多路召回扩展

大模型能够对用户的原始问题进行深度拆解，一次生成多个语义等价的标准问题：

原始Query：做FDE需要什么技能？

改写后的多个Query：
1. 前端开发工程师的技能要求是什么？
2. 成为FDE的门槛有哪些？
3. FDE职位需要掌握哪些技术栈？
4. 前端开发岗位的任职资格说明

这种"一变多"的策略，相当于一次用户提问变成了多次检索并行执行，召回率显著提升，系统能够从更多角度获取相关知识。

能力三：标准化表达

大模型具备强大的语言组织能力，能够将口语化、碎片化的表达转化为结构规范、语义完整的标准问法：

原始Query：豆包是字节的吗？
改写后：豆包大语言模型是否由字节跳动开发？

标准化后的 Query 与知识库文档的匹配率大幅提升，直接改善了检索质量。

第二章：实战中的组合策略

在真实的 RAG 生产项目中，很少有系统会单独使用某一种改写方案。成熟的架构通常是多种方案的组合拳：

┌─────────────────────────────────────────────┐
│              Query 改写分层架构                │
├───────────────┬───────────────────────────────┤
│  层级          │  方案         │  职责           │
├───────────────┼───────────────┼─────────────────┤
│  兜底层        │  规则改写     │  拦截高频简单   │
│               │              │  Query，确保最低 │
│               │              │  可用性          │
├───────────────┼───────────────┼─────────────────┤
│  批处理层      │  轻量级NLP/   │  批量处理标准   │
│               │  小模型       │  问题，平衡效果  │
│               │              │  与成本          │
├───────────────┼───────────────┼─────────────────┤
│  精排层        │  大模型       │  处理复杂语义、  │
│               │              │  上下文依赖的    │
│               │              │  高价值Query    │
└───────────────┴───────────────┴─────────────────┘

这种分层架构的设计理念是：让合适的工具做合适的事。规则负责兜底，保证系统不会"裸奔"；轻量模型负责80%的常见问题，平衡性能与成本；大模型专注于需要深度语义理解的"硬骨头"，最大化关键场景的体验。

在实际调优过程中，还可以引入召回效果评估作为反馈信号：如果某次改写后的检索结果评分过低，触发回退策略或重新改写，形成闭环优化。

第三章：面试技巧与核心认知

Query 改写之所以成为"实战试金石"，是因为它不是一个可以通过背概念掌握的考点，而是需要在真实项目中经历过"调优-评估-迭代"完整流程才能深刻理解的技术模块。

面试中的回答框架

当被问到 Query 改写相关问题时，建议按照以下逻辑展开：

1. 先定义问题：明确 Query 改写解决的核心矛盾——用户语言与知识库语言的语义鸿沟

2. 再讲方案：按照从简单到复杂的顺序，依次介绍规则改写、传统 NLP 改写、大模型改写的原理与适用场景

3. 重点突出：大模型改写的三个核心能力（上下文理解、多路召回、标准化表达）是重点，需要展开说明

4. 实战经验：如果有实际调优经验，分享具体的优化案例和效果数据

5. 架构思维：描述实际项目中的分层组合策略

核心认知的拔高

面试官真正想听到的，不仅是对技术方案的描述，更是对Query 改写本质的理解。建议用一句话概括：

能够说出这句话，意味着你已经跳出了"学生思维"，具备了工程落地的实战视角。

总结

Query 改写是 RAG 系统中连接用户与知识的"桥梁"，它的质量直接决定了整个系统的上限。从规则改写的快速启动，到传统 NLP 的轻量增强，再到大模型改写的语义理解，三种方案各有千秋，组合使用才能实现最优效果。

对于技术从业者而言，理解 Query 改写不仅是面试需要，更是构建高质量 RAG 系统的必备能力。毕竟，在一个"用户问得随意，系统答得精准"的理想体验背后，Query 改写功不可没。

视频来源

本文基于果果AI入门记视频深度整理，原视频链接：https://v.douyin.com/PmMhoEbZyC8/

作者：果果AI入门记（抖音）

整理：AI KnowledgeBase Project