简要回答
RAG 更适合知识频繁更新、需要溯源、数据不能写入模型权重的场景；微调更适合固化回答风格、输出格式、领域分类边界和工具调用习惯。生产中常把二者组合：RAG 负责提供最新事实，微调或提示模板负责让模型稳定地使用这些事实。
标准回答
一、先区分“知识问题”和“行为问题”
RAG 和微调解决的不是同一种问题。RAG 解决的是知识供给问题：模型不知道某份内部文档、最新政策、客户合同或产品手册，就在推理时把相关材料检索出来放进上下文。它的优势是知识更新快、可追溯、权限容易隔离，缺点是依赖检索质量和上下文窗口，延迟也会增加。
二、微调解决的是行为固化问题
让模型更稳定地遵守某种输出格式、领域术语、分类标准、问答风格或工具调用模式。它的优势是推理时不需要每次检索大量材料，输出更一致；缺点是更新成本高，且不适合把频繁变化的事实“烘焙”进权重。
三、按场景选择方案
- 知识频繁变化、必须引用来源：优先 RAG，例如企业知识库问答、法规政策查询、售后手册问答。
- 任务规则稳定、输出格式要求强：优先微调，例如工单分类、结构化抽取、客服话术风格、固定 JSON 输出。
- 既要最新事实又要稳定行为：组合使用，例如 RAG 检索合同条款，微调模型学习如何引用条款、何时拒答、如何生成合规格式。
四、工程上要看四个约束
第一是数据更新频率。每天变的知识不适合微调，应该进知识库；长期稳定的流程和风格可以考虑微调。第二是可解释性。如果业务需要给出引用来源，RAG 更合适；微调后的知识难以逐条溯源。第三是延迟和成本。RAG 多了检索、rerank 和上下文拼接成本；微调可能降低单次推理复杂度，但训练和版本管理成本更高。第四是治理和权限。私有数据如果不能进入模型权重，RAG 的权限隔离和日志审计更容易做。
五、面试中要给出组合架构
一个成熟答案不应停在“RAG vs 微调”二选一，而要说明组合方式：先用 RAG 提供最新、可审计的事实；再用提示模板、少量微调或偏好优化约束模型如何使用检索结果；最后用评测集监控检索召回率、答案忠实度、引用准确率和拒答质量。这样既能保持知识新鲜，也能让输出稳定可控。
常见误区
⚠️ 常见踩坑
误区一：把 RAG 当成万能补丁。 如果知识库质量差、切分粗糙、权限混乱或 rerank 不稳定，RAG 只会把噪声塞进上下文，模型仍然会答错。误区二：把微调用来记最新事实。 频繁变化的价格、政策、客户信息不适合写进模型权重，否则更新慢、难溯源、也难删除。误区三：只比较效果，不比较治理成本。 企业场景还要看权限隔离、引用审计、回滚、延迟和版本管理。
追问
追问 1：RAG 检索质量差时如何兜底？
题库专题：RAG 中的文档切分（Chunking）策略如何影响检索质量？先判断是“召回不到”还是“召回不准”。
- 召回不到：优化 query rewrite、同义词扩展、HyDE、多路召回和 chunk 粒度，确保相关材料能进候选集。
- 召回不准：引入 rerank、元数据过滤、权限过滤和领域规则，避免把相似但无关的文档送给模型。
- 低置信度兜底：要求模型澄清问题或拒答，并明确说明“未在知识库中找到可靠依据”，不能强行用通用知识补答案。
生产里还要记录失败 query，定期回灌到评测集和知识库治理流程中。
题库延伸：与本追问相关的专题题 → RAG 中的文档切分（Chunking）策略如何影响检索质量？
追问 2：LoRA 和全量微调怎么选？
题库专题：LoRA 的数学原理是什么？为什么低秩分解能近似全量微调？默认先选 LoRA，只有在能力改造很深或部署约束明确时才考虑全量微调。
- LoRA 适合低成本适配：它只训练少量低秩适配参数，训练成本低、版本管理方便、可以为不同业务维护多套 adapter，适合风格、格式、领域话术和轻量任务适配。
- 全量微调适合深度能力改造：当任务需要大幅改变模型内部表示，或者 LoRA 在充分数据和调参后仍无法达到目标，再考虑全量微调。但它成本高、遗忘风险更大，也更难回滚。
- 企业实践要看部署链路：如果线上服务需要频繁切换客户或业务线，LoRA 更灵活；如果是单一垂直模型长期服务固定场景，全量微调才可能更划算。
面试里最好补一句：无论 LoRA 还是全量微调，都不能替代 RAG 的事实更新能力，微调前必须准备旧任务回归集，防止新风格学会了、原有能力却退化。
题库延伸：与本追问相关的专题题 → LoRA 的数学原理是什么？为什么低秩分解能近似全量微调？
追问 3：如何评估 RAG 系统？
题库专题：如何评估一个 RAG / Agent 系统的效果？评估要拆成检索、生成和线上业务三层。
- 检索层：看 Context Recall、MRR、NDCG、命中文档权限是否正确，判断相关材料有没有被召回。
- 生成层：看 Faithfulness、Answer Relevance、引用准确率和拒答质量，判断模型有没有忠实使用上下文。
- 业务层：看人工改写率、用户追问率、客服解决率、投诉率和延迟成本，判断系统是否真的可用。
LLM-as-judge 可以做批量初筛，但关键场景要有人类标注集兜底；引用来源必须可点击、可审计，否则“看起来正确”的答案很难进入生产。
题库延伸：与本追问相关的专题题 → 如何评估一个 RAG / Agent 系统的效果？
🔗 相似问题
同一考点的不同问法，换着练更稳
没找到想看的面试题？把你想看的告诉我们 →
延伸学习
按主题分类的相关资源，便于系统复习
