2 RAG 和传统搜索、微调分别是什么关系
P1 · rag
🏷 标签：rag, fine-tuning, search, comparison
1️⃣ 考察意图
面试官想看你是否真正理解 RAG 的定位，而非只会背概念。这道题属于系统设计对比类，刁钻点在于：很多人把 RAG 简单等同于“搜索+生成”，或认为微调可以完全替代 RAG。答好了能展示你对技术选型的工程判断力——知道什么时候该用搜索、什么时候该微调、什么时候该 RAG，以及如何组合。核心考察：能否从成本、更新频率、知识范围、可解释性四个维度给出清晰取舍，并落地到具体场景。
2️⃣ 标准答
RAG 与传统搜索、微调不是替代关系，而是互补关系，各自解决不同层面的问题。我从三个对比维度展开：
1. RAG vs. 传统搜索
- 目标不同：传统搜索（如 Elasticsearch 的 BM25）返回文档列表，用户自己筛选；RAG 返回生成式答案，直接回答用户问题。
- 检索增强：RAG 依赖检索（BM25、DPR、ColBERT-v2）但不止于检索——它用检索结果作为上下文输入 LLM 生成答案。传统搜索没有生成环节。
- 工程取舍：传统搜索对延迟敏感（<100ms），RAG 因 LLM 生成通常 1-3 秒。如果业务要求毫秒级响应（如电商搜索），纯搜索更合适；如果要求答案准确且可解释（如客服问答），RAG 更优。
- 实际坑：很多人以为 RAG 的检索部分直接用 BM25 就行，但 BM25 对语义匹配差，尤其当用户问题与文档用词不同时（如“怎么退款” vs “退货流程”）。解法：用混合检索（BM25 + dense embedding），再用重排序（如 Cohere Rerank 或 BGE-Reranker）提升 top-k 质量。
2. RAG vs. 微调
- 知识更新：微调（如 LoRA、QLoRA）更新模型参数，适合固定知识领域（如法律条款、医学指南）。一旦知识变化，需重新训练，成本高（一次微调可能 $500-$5000）。RAG 不改变参数，通过外部知识库更新，秒级生效。
- 知识范围：微调只能注入训练数据中的知识，对长尾问题泛化差。RAG 可检索任意文档，覆盖范围更广。
- 可解释性：RAG 可追溯答案来源（引用文档），微调是黑盒。在合规场景（如金融风控），RAG 更安全。
- 工程取舍：微调适合高频、稳定的任务（如客服常见问题分类），RAG 适合低频、动态的任务（如新政策解读）。实际落地中，微调+RAG 组合最常见：微调让模型学会回答格式和语气，RAG 提供实时知识。
3. 组合策略与场景举例
- 纯搜索：电商商品搜索，用户要列表，不要生成答案。
- 纯微调：医疗诊断辅助，知识稳定且需深度理解（如 ICD-10 编码）。
- 纯 RAG：企业内部知识库问答，文档频繁更新（如产品手册）。
- 微调+RAG：客服系统——微调处理 80% 常见问题（如“怎么登录”），RAG 处理 20% 新政策或异常问题（如“新退税规则”）。延迟上，微调部分 <200ms，RAG 部分 1-2s，整体可接受。
实际落地的坑：微调+RAG 组合时，微调后的模型可能“遗忘”检索能力（即不遵循检索指令）。解法：在微调数据中混入检索增强样本（如“根据以下文档回答：{文档}”），保持模型对上下文的敏感度。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，RAG 与传统搜索的目标不同——搜索返回文档列表，RAG 返回生成答案，但 RAG 依赖检索技术（如 BM25+DPR+重排序）。第二，RAG 与微调互补——微调适合固定知识、高频任务，RAG 适合动态知识、低频任务，成本上 RAG 更新秒级生效，微调需重新训练。第三，实际落地常用组合：纯搜索用于电商列表，纯微调用于稳定领域，纯 RAG 用于动态知识库，微调+RAG 用于客服系统。总结一句：RAG 不是替代品，而是用检索增强生成，与搜索和微调形成技术栈的互补。”
4️⃣ 高频追问 & 应对
追问 1：你说 RAG 适合动态知识，那如果知识库每天更新 1000 条文档，怎么保证检索质量？
核心挑战是索引更新延迟和检索噪声。解法：1）用增量索引（如 Elasticsearch 的 refresh_interval=1s），避免全量重建；2）对新增文档做质量过滤（如用 LLM 打分，剔除低质量或重复内容）；3）检索时引入时间衰减权重（如 BM25 的 b 参数调高，或 embedding 后加时间戳特征），让新文档排名更高。坑：如果文档量级大（>100 万），增量索引可能造成碎片化，需定期做段合并（segment merge）。
追问 2：微调+RAG 组合时，怎么避免微调破坏 RAG 的检索能力？
这是常见问题。微调会让模型“记住”训练数据，从而忽略检索上下文。解法：1）在微调数据中混入20%-30% 的检索增强样本，格式为“根据以下文档回答：{文档}”，让模型学会依赖外部知识；2）使用指令微调（如 Alpaca 格式），明确告诉模型“如果文档中没有相关信息，就说不知道”；3）微调后做检索鲁棒性测试：构造一批需要检索才能回答的问题，看模型是否仍能正确引用文档。如果退化，回退到更小的学习率（如 1e-5）或更少的步数。
追问 3：RAG 的可解释性具体怎么落地？用户要看到引用来源。
工程上分三步：1）检索阶段保留文档 ID 和段落位置（如 chunk_id + offset）；2）生成阶段让 LLM 输出引用标记（如 [1][2]），并在 prompt 中要求“每个答案必须引用至少一个文档”；3）后处理阶段解析引用，拼接成可点击的链接或摘要。坑：LLM 可能生成虚假引用（幻觉），解法是用引用验证——对每个引用，用 embedding 相似度或 BM25 匹配度打分，低于阈值则丢弃。工具上，LangChain 的
RetrievalQAWithSourcesChain和 LlamaIndex 的CitationQueryEngine可直接用。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“RAG 就是搜索+GPT，比搜索好” → ✅ 正确切入：RAG 不是替代搜索，而是解决搜索无法直接回答的问题；搜索适合列表场景，RAG 适合问答场景。
- ❌ 说“微调比 RAG 好，因为更准确” → ✅ 正确切入：微调准确率更高但更新成本高，RAG 灵活但依赖检索质量；实际是互补，不是谁替代谁。
- ❌ 说“RAG 不需要微调” → ✅ 正确切入：RAG 的检索部分需要调优（如 embedding 模型、chunk 大小），生成部分也可用微调优化格式和语气。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“混合检索+重排序”的工程取舍切入，展示你如何用 BM25+DPR+Cohere Rerank 提升 top-5 准确率，并对比纯搜索和纯微调的延迟/成本。
- 如果你只做过传统搜索：用“搜索是 RAG 的检索组件”类比，强调你理解 BM25 的 k1/b 参数调优如何影响 RAG 质量，并举例如何迁移到 dense embedding。
- 如果你是校招无项目：聚焦论文复现——比如复现“REALM”或“RAG”论文，对比 BM25 vs DPR 的检索效果，并讨论微调+RAG 的组合策略（如 FiD 模型）。
- Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (RAG 论文)
- Karpukhin et al., "Dense Passage Retrieval for Open-Domain Question Answering" (DPR 论文)
- Khattab & Zaharia, "ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT"
- 博客：LangChain 官方文档 "Retrieval-Augmented Generation (RAG) Guide"
- 博客：LlamaIndex 官方文档 "How to Use Citations in RAG"