07｜Agent 如何优化 RAG 的检索查询？有哪些方法

P1 · rag

🏷 标签：agent, rag, query-optimization, query-rewriting

1️⃣ 考察意图

面试官想考察你是否理解 RAG 系统中“查询质量”是检索效果的瓶颈，而非单纯堆砌模型。这属于系统设计+工程取舍类问题，刁钻点在于：候选人常只背“查询改写”一个方法，却忽略 Agent 动态决策的完整流程逻辑。答好了能展示你对检索链路（Query→Retrieve→Rerank→Generate）的全局掌控力，以及从规则到端到端训练的演进思维。

2️⃣ 标准答

Agent 优化 RAG 检索查询的核心目标是将用户模糊、多义、碎片化的自然语言问题，转化为检索系统（如 BM25、Dense Retriever）能高效匹配的查询形式。方法分四大类，按复杂度从低到高排列：

**查询改写（Query Rewriting）**规则式：用正则或模板处理指代消解（如“它”替换为前文实体）、拼写纠错（如“transformer”补全为“Transformer architecture”）。
LLM 式：用轻量模型（如 GPT-3.5-turbo）将用户问题重写为检索友好格式。例如用户问“那篇论文的损失函数怎么改的？”，改写为“《Attention Is All You Need》中交叉熵损失函数的改进方法”。
工程取舍：规则式快但覆盖窄（仅处理已知模式），LLM 式泛化强但延迟高（单次改写约 200-500ms）。实际落地常用规则兜底 + LLM 兜底的双层架构：先规则命中则跳过 LLM，否则触发 LLM 改写。查询分解（Query Decomposition）
将复杂问题拆成多个子查询，分别检索后合并结果。例如“对比 BERT 和 GPT 在文本分类上的表现”拆为：子查询 1：“BERT 文本分类准确率”
子查询 2：“GPT 文本分类准确率”
子查询 3：“BERT vs GPT 文本分类对比” 实际落地的坑：子查询可能返回重复文档，需用去重策略（如 MinHash 或基于 embedding 相似度去重）。工具支持：LangChain 的 MultiQueryRetriever 内置此逻辑，但默认只做简单拆分，复杂场景需自定义 Agent 决策（如根据问题长度动态决定拆分数）。查询扩展（Query Expansion）
添加同义词、相关术语或伪相关反馈（Pseudo-Relevance Feedback）。例如用户搜“深度学习”，扩展为“深度学习神经网络反向传播梯度下降”。
方法对比：静态扩展：基于 WordNet 或知识图谱（如 Wikidata）预定义同义词，快但僵化。
动态扩展：用 LLM 生成 3-5 个相关术语，或从初步检索结果中提取高频词（如 BM25 返回 top-10 文档的 TF-IDF 关键词）。取舍：静态扩展无延迟成本，但可能引入噪声（如“苹果”扩展出“水果”而非“公司”）；动态扩展更精准，但需额外一次检索（约 50-100ms）。动态调整（Adaptive Query Refinement）
Agent 根据初步检索结果（如召回文档的置信度分数）决定是否调整查询。典型流程：初始查询检索 top-5 文档。
计算文档与查询的语义相似度（如使用 Cross-encoder 打分）。
若最高分 < 阈值（如 0.6），则触发改写/扩展，重新检索。
实际落地的坑：阈值设置需调参，过低导致频繁重试（延迟爆炸），过高则错过优化机会。建议用 A/B 测试或贝叶斯优化（如 Hyperopt）在离线数据集上搜索最优阈值。
端到端训练：最新工作（如 REPLUG、Self-RAG）将查询改写器与检索器联合训练，用强化学习（如 GRPO）优化改写策略，但训练成本高（需 100k+ 查询-文档对）。

总结：规则式改写适合冷启动，LLM 改写和分解处理复杂问题，动态调整形成完整流程。实际系统通常组合 2-3 种方法，例如“规则改写 → LLM 分解 → 动态扩展”。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从查询改写、查询分解、查询扩展、动态调整四个层面回答。改写层用规则+LLM 双层架构处理指代和歧义；分解层将复杂问题拆为子查询，注意去重；扩展层添加同义词或伪相关反馈，动态扩展更准但需权衡延迟；动态调整层根据检索置信度决定是否重试，阈值需调参。总结一句：没有银弹，实际系统需组合 2-3 种方法，并基于离线指标（如 Recall@5）和线上延迟做取舍。”

4️⃣ 高频追问 & 应对

追问 1：你提到动态调整的阈值，具体怎么调？有没有经验值？

经验值：初始阈值设为 0.5（基于 Cross-encoder 的 [0,1] 分数），然后用离线数据集（如 Natural Questions 的 3000 条查询）做网格搜索。具体做法：对每个候选阈值（0.3-0.8，步长 0.05），计算平均检索延迟和 Recall@5，选 Pareto 最优解。实际线上常设 0.6，因为低于 0.5 时重试率超 40%，延迟翻倍；高于 0.7 时优化效果消失。注意阈值需随检索器更新（如换 embedding 模型后重新调）。

追问 2：查询分解时，子查询数量怎么定？拆太多会不会有性能问题？

子查询数量通常与问题复杂度正相关。简单规则：用 LLM 判断问题中实体数（如“对比 BERT 和 GPT”含 2 个实体，拆 2-3 个查询）。性能问题确实存在：每多一个子查询，检索延迟线性增加（假设检索器 QPS 固定）。实际落地限制最大子查询数为 5，并用异步并发检索（如 Python 的 asyncio.gather）将延迟从串行 5*100ms 降到 100ms。更激进的做法：用 Agent 决策，若初始检索结果已覆盖 80% 信息，则跳过分解。

追问 3：端到端训练查询改写器，数据怎么构造？有没有开源方案？

数据构造常用“检索-改写-反馈”完整流程：用 BM25 检索原始查询的 top-10 文档，然后用 LLM（如 GPT-4）生成改写查询，再检索并计算 Recall@5 提升。正样本是 Recall 提升 > 0.1 的改写，负样本是 Recall 下降的。开源方案：REPLUG 论文提供了训练代码（基于 T5 模型），但需自己准备检索器（如 Contriever）。注意训练数据量至少 10k 条，否则改写器容易过拟合到特定模式。

5️⃣ 避坑 · 常见错误答法

❌ 只提“用 LLM 改写查询”一种方法，忽略规则式和动态调整。→ ✅ 展示方法谱系：从规则（快但窄）到 LLM（准但慢）到动态调整（自适应），体现工程权衡。
❌ 说“查询分解就是拆成多个子查询，然后合并结果”，不提去重和并发优化。→ ✅ 点出实际坑：子查询可能返回重复文档，需去重；并发检索可降低延迟。
❌ 认为“动态调整的阈值设成 0.5 就行”，不解释调参过程。→ ✅ 给出具体调参方法（网格搜索、Pareto 最优）和经验值（0.6），展示落地思维。

6️⃣ 简历呼应

如果你有 RAG 项目：从实际调优切入，例如“我在某问答系统中用规则改写处理了 30% 的指代问题，再用 LLM 改写提升 15% 的 Recall@5，最后用动态调整将平均延迟控制在 200ms 以内”。
如果你只做过传统 NLP：用类比迁移，例如“查询改写类似文本摘要中的‘重述’任务，但目标从流畅性变为检索命中率；查询分解类似多任务学习中的子任务拆分”。
如果你是校招无项目：聚焦论文复现，例如“我复现了 REPLUG 论文的端到端训练，在 Natural Questions 上 Recall@5 从 0.65 提升到 0.72，并分析了不同改写策略的延迟-精度曲线”。
论文：REPLUG: Retrieval-Augmented Black-Box Language Models（2023）
论文：Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection（2023）
工具：LangChain MultiQueryRetriever 文档（查询分解实现）
博客：Haystack 的 Query Rewriting 最佳实践（含规则+LLM 双层架构）
论文：Query Expansion by Prompting Large Language Models（2023）

—— 本场面试完 ——