1 用户问题进入 RAG 后，第一步为什么往往不是直接检索
P1 · rag
🏷 标签：rag, query-understanding, query-rewriting, retrieval-pipeline
1️⃣ 考察意图
面试官想考察你对 RAG 流水线（pipeline）的系统设计思维，而非单纯背概念。核心是看你能不能跳出“检索即搜索”的直觉，理解查询理解（Query Understanding） 作为前置步骤的必要性。刁钻点在于：用户问题天然带有噪声、歧义、信息不足或意图模糊，直接检索会导致向量空间中的语义偏移或稀疏匹配，降低召回率和精度。答好了能展示你对 RAG 整条链路（从 query 到 chunk 再到生成）的工程取舍能力，以及处理真实用户输入（如口语化、多跳问题）的实战经验。
2️⃣ 标准答
用户问题进入 RAG 后，第一步不是直接检索，因为原始 query 往往不适合嵌入空间或稀疏索引的匹配逻辑。直接检索会踩三个坑：语义偏移（用户说“苹果公司CEO” vs 文档写“Tim Cook”）、信息冗余（“帮我找一下关于...”）、意图模糊（“深度学习的最新进展”是综述还是论文？）。所以需要查询理解来桥接用户语言和检索系统。
核心步骤与工程取舍：
- 查询改写（Query Rewriting）：用 LLM 或规则将口语转为检索友好形式。例如“苹果公司的CEO是谁？” → “苹果 CEO”。方法：基于 LLM 的 prompt 改写（如“将以下问题简化为关键词”），或使用 T5-small 微调。
- 取舍：LLM 改写灵活但延迟高（100ms+），适合离线或高精度场景；规则改写快（<10ms）但覆盖窄。实际落地常混合使用：先规则（去停用词、实体提取），若置信度低再调 LLM。
- 坑：改写过度会丢失上下文。例如“2023年诺贝尔物理学奖得主”简化为“诺贝尔奖”导致召回爆炸。解法：保留核心实体（如“诺贝尔物理学奖 2023”），用 NER（如 spaCy）提取并保留时间限定。 查询分解（Query Decomposition）：处理多跳问题（multi-hop）。例如“特斯拉的CEO和SpaceX的CEO是同一个人吗？” → 分解为“特斯拉 CEO”和“SpaceX CEO”。
- 方法：用 LLM 生成子问题列表，或基于依存句法分析（如 Stanza）拆分。
- 取舍：分解增加检索次数（2x+），但提升复杂问题准确率。代价是延迟和 token 消耗。实际中只对意图分类为多跳的问题执行，避免无谓开销。 查询扩展（Query Expansion）：用同义词或相关概念补全。例如“AI 伦理” → “AI 伦理 算法偏见 公平性”。
- 方法：WordNet 同义词、embedding 相似词（如 fastText）、或 LLM 生成相关术语。
- 取舍：扩展提升召回但可能引入噪声。例如“苹果”扩展为“水果”导致检索偏。解法：加权检索，原始 query 权重高，扩展词权重低（如 BM25 中设置不同 k1 参数）。 实体识别与纠错（NER + Spell Correction）：处理拼写错误或别名。例如“马斯克” → “Elon Musk”。
- 方法：基于词典的实体链接（如 Wikipedia 实体库）或 LLM 纠错。
- 坑：实体链接依赖知识库更新频率。例如“DeepSeek”作为新公司可能不在库中。解法：混合检索，同时用 embedding 和 BM25，BM25 能匹配字面相似度。
实际落地案例：在电商 RAG 中，用户问“红米手机价格”，直接检索 embedding 可能匹配到“小米手机”但忽略“红米”子品牌。通过查询理解模块（NER 提取“红米”+ 同义词扩展“Redmi”），召回率提升 15%（Recall@10 从 0.72 到 0.83）。代价是延迟增加 50ms，但通过缓存常见改写结果（如 LRU cache）抵消。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，用户原始 query 有噪声和歧义，直接检索会导致语义偏移或稀疏匹配；第二，查询理解通过改写、分解、扩展和纠错来桥接用户语言和检索系统，提升召回和精度；第三，工程上需要权衡延迟和效果，比如用规则+LLM 混合策略，并注意改写过度或实体库过时的问题。总结一句：查询理解是 RAG 流水线的‘翻译官’，没有它检索就是盲人摸象。”
4️⃣ 高频追问 & 应对
追问 1：如果用户 query 是“今天天气怎么样”，没有上下文，查询理解怎么处理？
这类 query 依赖上下文（如用户位置、时间）。查询理解模块需要意图分类：识别为“天气查询”后，触发上下文注入。例如从用户 profile 或对话历史中提取位置（如“北京”），改写为“北京 2025-03-20 天气”。如果无上下文，则降级处理：返回通用结果或反问用户。工程上，用轻量级分类器（如 fastText 模型，<1ms）判断意图，避免每次调 LLM。
追问 2：查询理解模块本身可能出错，怎么保证鲁棒性？
设计回退机制：如果改写后的 query 检索结果为空或置信度低（如 BM25 最高分 < 阈值 0.3），则回退到原始 query 重新检索。同时，A/B 测试对比改写前后效果，监控 Recall@k 和 Precision@k。如果改写导致指标下降，自动禁用该改写规则。实际中，用多路召回（原始 query + 改写 query 并行检索，结果合并去重）来兜底，牺牲一点延迟换取鲁棒性。
追问 3：在资源受限场景（如移动端），查询理解怎么优化？
用规则为主、模型为辅：停用词过滤、NER（用轻量级 ONNX 模型，<5ms）、同义词扩展（预计算词典）。避免 LLM 调用。如果必须用 LLM，则离线预处理常见 query 模式（如“XX 是什么” → “XX 定义”），缓存结果。延迟目标控制在 10ms 以内，否则影响用户体验。
5️⃣ 避坑 · 常见错误答法
- ❌ “直接检索也行，只是效果差一点，查询理解不是必须的。”→ ✅ “直接检索在简单 query 上可能够用，但面对口语化、多跳或歧义 query 时，召回率会暴跌 30%+。查询理解是 RAG 流水线的标准组件，能系统性提升检索质量。”
- ❌ “查询理解就是让 LLM 改写 query，用 GPT-4 就行。”→ ✅ “LLM 改写灵活但成本高、延迟大，实际工程中常用规则+小模型（如 T5-small）混合策略。例如先做 NER 和去停用词，再对复杂 query 调 LLM，并设置超时回退。”
- ❌ “查询理解只做改写，不需要分解或扩展。”→ ✅ “多跳问题需要分解，稀疏 query 需要扩展。例如‘AI 伦理’不扩展可能只召回‘AI’相关文档，漏掉‘算法偏见’。具体方法取决于 query 类型和检索索引。”
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“我在 XX 项目中实现了查询理解模块，用 NER+同义词扩展，使 Recall@5 提升 12%”切入，强调工程取舍（延迟 vs 效果）和 A/B 测试结果。
- 如果你只做过传统 NLP：用“NER 和 query 改写类似文本分类任务，我迁移了 BERT 微调经验，在查询理解中做意图分类”类比，展示跨领域能力。
- 如果你是校招无项目：聚焦“我复现了论文《Query Rewriting for Retrieval-Augmented Generation》中的方法，在 Natural Questions 数据集上验证了改写对召回的影响”，并提到用 BM25 和 embedding 做对比实验。
- 《Query Rewriting for Retrieval-Augmented Generation》（2023, arXiv）
- 《Improving Retrieval in RAG with Query Decomposition and Expansion》（2024, ACL Workshop）
- 《HyDE: Precise Zero-Shot Dense Retrieval without Relevance Labels》（2022, ACL）
- 《RAGAS: Automated Evaluation of Retrieval Augmented Generation》（2023, arXiv）
- 《FlashAttention: Fast and Memory-Efficient Exact Attention》（2022, NeurIPS）