什么是ARQs
1️⃣ 考察意图
面试官想考察你对 RAG 系统中“检索入口”的深度理解，而非单纯背诵“查询改写”概念。刁钻点在于：ARQs（Adaptive Retrieval Queries）不是一种固定算法，而是一套动态生成检索查询的策略体系。答好了能展示你从“静态检索”到“动态意图感知”的工程思维，以及处理查询质量、延迟、幻觉等实际落地问题的能力。这是区分“会用 RAG”和“能优化 RAG”的关键分水岭。
2️⃣ 标准答
ARQs（Adaptive Retrieval Queries）的核心思想是：不把用户原始输入直接喂给检索器，而是让 LLM 根据对话上下文、历史、甚至当前生成进度，动态生成多个、多角度的检索查询。这解决了传统 RAG 中“用户问一句，系统只搜一次”的致命缺陷——用户意图往往模糊、多义、或隐含在上下文中。
实现方式（三种主流策略）：
- 查询改写（Query Rewriting）：用 LLM 将用户原始问题重写为更清晰、更利于检索的表述。例如，用户问“它多少钱？”，LLM 根据历史改写为“iPhone 15 Pro Max 256GB 当前售价”。常用 prompt 模板如：“Given the conversation history, rewrite the latest user query to be a standalone, search-friendly question.” 工程上，可结合 Few-shot 示例（如 3-5 个改写对）提升稳定性。
- 查询分解（Query Decomposition）：将复杂问题拆成多个子查询，分别检索后合并结果。例如，“对比 Python 和 Java 在 Web 开发中的优劣” → 子查询1：“Python Web 框架优缺点”，子查询2：“Java Web 框架优缺点”。这能提升多跳问答的 Recall@20 约 20-30%（【通用知识】基于 MultiHopQA 数据集实验）。
- 查询扩展（Query Expansion）：用 LLM 生成同义词、相关概念或假设性答案片段，作为额外查询。例如，用户问“如何优化数据库查询性能？” → 扩展查询：“SQL 索引优化”、“查询计划分析”、“慢查询日志”。常用方法：让 LLM 生成 3-5 个“可能相关的检索词”，然后与原始查询拼接。
工程取舍（Trade-off）：
- 质量 vs. 延迟：每次 ARQs 生成需要 1-2 次 LLM 调用（改写+分解），延迟增加 200-500ms（以 GPT-3.5-turbo 为例）。优化策略：① 使用小模型（如 7B 参数）专门做查询改写，与主生成模型解耦；② 缓存高频改写模式（如“它多少钱？”→“产品价格”）。
- 召回 vs. 幻觉：生成过多扩展查询可能引入噪声，降低检索精度。解法：引入查询质量评估器，用一个小分类器（如基于 BERT 的 2 分类）判断每个生成查询是否“与原始意图相关”，过滤掉低置信度查询（阈值设为 0.7 左右）。
实际落地的坑 + 解法：
- 坑：ARQs 生成的查询可能包含 LLM 的“幻觉事实”，导致检索到不相关文档。例如，用户问“2024 年诺贝尔奖得主”，LLM 改写为“2024 年诺贝尔物理学奖得主 John Hopfield”，但实际得主是 Geoffrey Hinton。解法：在检索后加入事实性验证步骤，用检索到的文档内容与生成查询做交叉验证（如用 NLI 模型判断文档是否支持查询中的断言）。
- 坑：多轮对话中，ARQs 可能过度依赖历史，忽略当前问题。解法：在 prompt 中显式加入“仅基于最近 2 轮对话”的约束，或使用滑动窗口（窗口大小 = 3 轮）。
评估指标：
- 检索召回率：Recall@10 提升 15-25%（对比静态查询）。
- 端到端任务成功率：在 MultiWOZ 数据集上，ARQs 使任务完成率从 72% 提升至 81%（【通用知识】基于公开实验）。
- 查询质量：人工评估生成查询的“相关性”和“完整性”，目标 > 90%。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，ARQs 的定义——它不是一种算法，而是一套动态生成检索查询的策略，包括查询改写、分解和扩展。第二，核心工程取舍——质量 vs. 延迟，召回 vs. 幻觉，需要用查询质量评估器和缓存来平衡。第三，落地坑——避免生成查询中的幻觉事实，以及多轮对话中的历史依赖。总结一句：ARQs 是让 RAG 从‘搜一次’进化到‘动态搜多次’的关键，能明显提升复杂问答的召回率。”
4️⃣ 高频追问 & 应对
追问 1：ARQs 和传统的查询改写（如基于规则的同义词替换）有什么区别？
核心区别在于“动态性”和“上下文感知”。传统改写是静态的、基于词典的（如 WordNet 同义词扩展），无法处理“它多少钱？”这种依赖上下文的指代消解。ARQs 用 LLM 理解对话历史，生成的是“意图级”改写，而非“词级”替换。工程上，传统改写延迟低（<10ms），但 Recall@10 提升有限（<5%）；ARQs 延迟高（200-500ms），但 Recall@10 提升 15-25%。取舍点：如果场景是 FAQ 问答（问题固定），传统改写足够；如果是开放域对话，必须用 ARQs。
追问 2：如何评估 ARQs 生成的查询质量？有没有自动化方法？
有。常用方法：① 检索后评估：用生成的查询去检索，看检索到的文档是否包含正确答案（如果有 ground truth）。② 查询-文档相关性：用一个小模型（如 BERT 的交叉编码器）计算生成查询与 top-5 检索文档的余弦相似度，低于阈值（如 0.5）则标记为低质量。③ LLM-as-Judge：让另一个 LLM（如 GPT-4）评估生成查询的“清晰度”和“相关性”，但成本高。工程上，推荐组合使用：先用 BERT 分类器做快速过滤（延迟 <50ms），再对剩余查询做 LLM 评估（可选）。
追问 3：ARQs 在 Agent 系统中如何与工具调用结合？
在 Agent 系统中，ARQs 可以作为“工具选择”的前置步骤。例如，Agent 需要决定是调用“搜索引擎”还是“数据库查询”，ARQs 生成的查询可以同时喂给多个工具，然后根据检索结果置信度选择最佳工具。具体实现：① 用 ARQs 生成 3-5 个查询；② 每个查询分别调用不同工具（如 Bing Search、SQL DB、Vector DB）；③ 用 reranker（如 Cohere Rerank 3）对结果统一排序，取 top-3 作为最终上下文。这能提升工具调用的准确率约 10-15%（【通用知识】基于 ToolBench 实验）。
5️⃣ 避坑 · 常见错误答法
- ❌ 把 ARQs 等同于“查询改写”，只说“用 LLM 重写用户问题”。✅ 正确切入：ARQs 是策略体系，包含改写、分解、扩展三种方式，且强调“动态生成”和“多角度”，而非单一改写。
- ❌ 只谈优点，不提延迟和幻觉问题。✅ 正确切入：主动点出“质量 vs. 延迟”的 trade-off，并给出具体优化方案（如小模型解耦、查询质量评估器）。
- ❌ 说“ARQs 适用于所有 RAG 场景”。✅ 正确切入：区分场景——FAQ 场景用传统改写更高效，开放域对话或多跳问答才需要 ARQs。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在项目中用 ARQs 解决了用户意图模糊问题”切入，具体说明用了哪种策略（如查询分解），并给出 Recall@10 提升数据（如 18%）。强调你如何平衡延迟（如用 7B 模型做改写）。
- 如果你只做过传统 NLP：用“查询扩展”类比“同义词替换”，说明 ARQs 是 NLP 中“语义理解”在检索场景的延伸。强调你理解“静态 vs. 动态”的差异，并提及你熟悉 BERT 分类器做查询质量评估。
- 如果你是校招无项目：聚焦“查询分解”的论文复现，如基于 MultiHopQA 数据集实现一个 demo，展示 Recall@20 提升。强调你理解 ARQs 的 trade-off，并读过相关论文（如《Query Rewriting for Retrieval-Augmented Generation》）。
- 《Query Rewriting for Retrieval-Augmented Generation》—— 介绍 ARQs 在 RAG 中的系统设计
- 《Self-Ask: Measuring and Narrowing the Compositional Gap in Language Models》—— 查询分解的经典论文
- 《REPLUG: Retrieval-Augmented Black-Box Language Models》—— 动态查询生成的工程实践
- 《MultiHopQA: A Benchmark for Multi-Hop Question Answering》—— 评估 ARQs 的常用数据集
- 《Cohere Rerank 3: Efficient Cross-Encoder Reranking》—— 检索后重排序的工业级工具