1 RAG 是什么
🏷 标签：rag, retrieval, generation, llm
1️⃣ 考察意图
面试官想看的不是你对 RAG 的百度百科式定义，而是你是否真正理解它解决了 LLM 的什么核心问题，以及各组件在工程上的取舍。这是典型的“概念+工程取舍”题。刁钻点在于：很多人只会背“检索+生成”，但说不清为什么不用纯检索或纯生成，也讲不出检索器、生成器、融合策略之间的耦合关系。答好了能展示你对 LLM 系统设计的全局观，以及从“能用”到“好用”的落地经验。
2️⃣ 标准答
RAG（Retrieval-Augmented Generation）本质上是给 LLM 装一个“外挂知识库”，核心思想是：不把答案全压在模型参数里，而是从外部检索相关文档，再让模型基于这些文档生成回答。这直接解决了 LLM 的两个死穴：知识截止日期（无法更新）和幻觉（胡编乱造）。
1. 核心流程：三阶段管道
- 检索阶段：输入查询
q，从知识库D中召回 top-k 相关文档。这里有两个主流路线：稀疏检索：BM25，基于词频-逆文档频率（TF-IDF 的升级版），默认参数k1=1.5, b=0.75。优势是快、可解释、对罕见词友好；劣势是语义鸿沟（“苹果”和“水果”不匹配）。 - 密集检索：DPR（Dense Passage Retrieval）或 Contriever，用双编码器将查询和文档映射到同一向量空间，通过余弦相似度或内积排序。优势是语义匹配；劣势是需要训练、对 OOD（分布外）数据敏感、存储成本高（向量索引）。
- 工程取舍：线上系统通常用“混合检索”——BM25 做粗排（召回率优先），再用 ColBERT 或 Cohere Embed v3 做精排（精度优先），最后用 HNSW（Hierarchical Navigable Small World）索引加速向量搜索，延迟控制在 50ms 以内。 融合阶段：将检索到的文档与原始查询拼接成 prompt。关键坑是上下文窗口溢出：如果 top-5 文档总长度超过 8K tokens，LLM 会忽略尾部内容。解法是滑动窗口截断或重排序后只取前 3 个，并给每个文档打上 <doc> 标签，让模型能区分来源。生成阶段：LLM 基于 prompt 生成回答。这里有个实际落地的坑：如果检索到的文档全是噪声（比如用户问“苹果公司”，检索到“苹果水果”），模型会强行编造。解法是引入“无检索”兜底策略——当检索相关性得分低于阈值（如 BM25 得分 < 5.0）时，直接走纯生成模式，或返回“知识库中未找到相关信息”。
2. 为什么 RAG 比纯检索或纯生成强？
- 纯检索（如搜索引擎）：返回文档列表，用户自己消化。缺点：信息密度低、无法直接回答复杂推理问题（如“比较 Transformer 和 RNN 的优缺点”）。
- 纯生成（如 GPT-4）：依赖参数化知识。缺点：知识更新成本高（需要重新训练或微调）、容易产生幻觉。
- RAG：结合两者优势——检索提供事实锚点，生成提供语言组织和推理能力。例如，在医疗问答中，检索到《新英格兰医学杂志》的论文，LLM 基于此生成诊断建议，既保证事实准确性，又输出自然语言。
3. 常见变体与演进
- Naive RAG：单次检索+生成，简单但容易漏信息。
- Advanced RAG：引入重排序（Reranker，如 Cohere Rerank 3）、迭代检索（Iterative Retrieval，如 Self-RAG）、查询重写（Query Rewriting，如 HyDE）。
- Modular RAG：将检索、生成、记忆、路由等模块化，可插拔组合。例如，LangChain 的
RetrievalQA链允许你替换检索器（从 BM25 切换到 FAISS）而不改生成逻辑。
总结：RAG 不是银弹，它的性能瓶颈通常在检索阶段（召回率不够高），而非生成阶段。面试时如果能指出“检索器召回率低于 70% 时，RAG 效果不如纯生成”，说明你有实战经验。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，RAG 的定义和核心流程——检索、融合、生成三阶段，解决 LLM 的幻觉和知识更新问题。第二，关键组件和工程取舍——检索器用 BM25 还是 DPR，融合时如何避免上下文溢出，生成时如何做噪声兜底。第三，常见变体——从 Naive RAG 到 Modular RAG，核心演进方向是提升检索精度和模块化灵活性。总结一句：RAG 的本质是给 LLM 装外挂知识库，但效果上限取决于检索质量。”
4️⃣ 高频追问 & 应对
追问 1：如果检索到的文档全是噪声，RAG 效果反而比纯生成差，你怎么解决？
这是典型的“检索污染”问题。解法分三层：第一层，检索阶段引入相关性阈值过滤，比如 BM25 得分低于 5.0 的文档直接丢弃，或使用 Reranker 对 top-100 重排序后只保留得分 > 0.8 的。第二层，融合阶段在 prompt 中加指令约束，比如“如果检索文档与问题无关，请忽略它们并基于自身知识回答”。第三层，生成阶段做置信度校准，让 LLM 输出时附带“是否引用检索文档”的标记，如果模型判断文档不可靠，则回退到纯生成模式。实际落地中，我们曾用 LlamaIndex 的
CitationQueryEngine实现过，准确率提升了 12%。
追问 2：RAG 中检索器用 BM25 还是 DPR？怎么选？
取决于场景。如果知识库是短文本（如 FAQ、产品描述），BM25 足够，因为词频匹配就能覆盖大部分需求，且延迟低（<10ms）。如果是长文本（如论文、法律文档），DPR 更好，因为语义匹配能处理同义词和抽象概念。工程上推荐混合检索：BM25 做第一轮粗排（召回 top-200），DPR 做第二轮精排（取 top-5），这样既保证召回率又控制延迟。注意 DPR 需要定期更新编码器，否则知识库更新后向量会过时——我们每两周用新数据微调一次 Contriever。
追问 3：RAG 和微调（Fine-tuning）是什么关系？可以替代吗？
互补关系，不能替代。RAG 解决的是知识更新和事实准确性问题，微调解决的是行为对齐和风格适配问题。比如，一个医疗问答系统：RAG 负责从最新论文中检索证据，微调负责让模型输出“建议咨询医生”的谨慎语气。实际架构是“RAG + 微调”双通道：先微调 LLM 使其学会引用检索文档，再上线 RAG 管道。如果只做 RAG 不做微调，模型可能忽略检索结果；如果只做微调不做 RAG，知识会过时。
5️⃣ 避坑 · 常见错误答法
- ❌ 把 RAG 说成“把 LLM 和搜索引擎拼在一起” → ✅ 正确说法是“检索增强生成，核心是检索模块为生成模块提供事实锚点，两者通过 prompt 融合，不是简单的 API 调用拼接”。
- ❌ 认为 RAG 能解决所有幻觉问题 → ✅ 正确说法是“RAG 只能缓解事实性幻觉，无法解决推理幻觉（比如模型自己推导出错误结论），需要配合思维链（CoT）或验证器”。
- ❌ 只提概念不提组件细节 → ✅ 必须提到具体方法名（BM25、DPR、HNSW、Reranker）和参数（k1=1.5, b=0.75），展示工程深度。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“检索器召回率优化”切入，讲你如何用混合检索（BM25 + DPR）将 top-5 准确率从 65% 提升到 82%，并对比了 HNSW 和 FAISS 的索引延迟。
- 如果你只做过传统 NLP：用“信息检索 + 文本生成”类比迁移，讲你如何将 BM25 和 Seq2Seq 模型组合成 RAG 管道，并指出传统 IR 的 TF-IDF 和 RAG 中 DPR 的语义差异。
- 如果你是校招无项目：聚焦“Naive RAG vs Advanced RAG”的论文复现，讲你基于 LangChain 和 Wikipedia 数据集实现了 Self-RAG，并分析了检索迭代次数对准确率的影响（3 次迭代后收益递减）。
- Lewis et al., “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” (2020) —— RAG 原始论文
- Karpukhin et al., “Dense Passage Retrieval for Open-Domain Question Answering” (2020) —— DPR 论文
- Shao et al., “Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection” (2023) —— 迭代检索变体
- LangChain 官方文档：RetrievalQA 链与 Modular RAG 架构
- Pinecone 博客：“What is RAG?” —— 工程落地最佳实践