本文属于 RAG 工程框架中的「2 索引与召回」环节,聚焦「Query Rewrite(查询改写)」方法。可先阅读 RAG-00.方法概述 再进入本篇。
原理
将用户原始查询改写为多个语义等价或互补查询,提升对同义词、缩写、隐式条件的召回能力。
关键技术/实现路径
- 同义改写与术语扩展。
- 多查询(Multi-query)并发检索。
- 查询分解(Decomposition)。
优缺点
- 优点:低改造成本提升召回率。
- 缺点:过度改写会引入噪声。
性能与资源
- 在线时延中等(多次检索)。
应用场景
- 用户表达不标准、口语化强的问答系统。
统一合成数据示例
输入数据片段
1 | {"query":"报销deadline","rewrites":["报销截止时间","报销提交时限"]} |
中间结果(多查询召回)
1 | [{"query":"报销截止时间","doc_id":"D01","score":0.83},{"query":"报销提交时限","doc_id":"D01","score":0.86}] |
最终生成示例(含引用)
1 | {"answer":"报销需在出差结束后30天内提交。","citations":[{"doc_id":"D01","evidence_span":"30天内提交"}]} |
原始发表与工程实现
- 代表性原始发表:Query2Doc (2023), HyDE (2023)。
- 核心解决问题:解决短查询和口语查询召回不足。
- 成熟实现工具:LangChain query transform, LlamaIndex。
详细原理拆解
- 构造 Q’={q1..qn} 并行检索,目标 Recall(Q’) >= Recall(Q)。
- 典型实现可拆为:输入预处理 -> 方法核心计算 -> 候选/证据构建 -> 生成与引用。
- 工程调优重点:质量(准确率/引用率)与成本(时延/token)的联合优化。
1 | flowchart LR |
工程落地扩展示例
伪代码
1 | def expand_retrieve_merge(query, rewriter, retriever, k: int): |
参数示例
1 | rewrite_variants: 3 |
常见失败案例
- 失败模式 1:改写引入偏离主题(如把「deadline」扩成无关流程),污染候选池。
- 失败模式 2:改写过多路,延迟与成本线性增长。
- 失败模式 3:合并策略只用 union 不做重排,噪声文档被放大。
Demo 数据带入计算示例
1 | q0「报销deadline」单路 recall@5=0.60;q1「报销提交时限」=0.75;q2「报销截止时间」=0.72。 |