When should I use Fine-tuning instead of RAG?**

P1 · rag

🏷 标签：rag, fine-tuning, trade-off, llm

1️⃣ 考察意图

面试官想考察你是否能跳出“RAG vs Fine-tuning”的二元对立，从工程取舍和系统设计的角度给出决策框架。刁钻点在于：很多人只会背概念（RAG更新快、微调贵），但无法量化“什么时候微调性价比更高”。答好了能展示你对LLM落地整条链路（成本、延迟、知识密度、推理能力）的权衡能力，以及设计混合方案的实战经验。

2️⃣ 标准答

核心原则：RAG解决“模型不知道”的问题，Fine-tuning解决“模型做不好”的问题。

1. 知识更新频率与稳定性

RAG优先：知识库每天/每周变化（如新闻、电商商品、政策法规）。只需更新向量索引，模型本身不动，成本极低。坑：索引更新有延迟，需设计增量索引（如FAISS的IndexIDMap配合时间戳过滤）。
Fine-tuning优先：知识稳定且需要深度内化（如公司内部代码库、医学诊断指南）。微调后模型能直接生成，无需每次检索。但注意：微调后知识固化，更新需重新训练。

2. 推理能力与任务复杂度

Fine-tuning优先：任务需要模型掌握特定推理模式（如SQL生成、数学证明、代码补全）。RAG只能提供上下文，无法改变模型推理逻辑。例如：微调CodeLlama后，SQL生成准确率从40%提升到85%，而RAG+GPT-4只能到60%。
RAG优先：任务主要是事实性问答（如客服FAQ、产品文档）。模型只需从检索结果中提取答案，无需复杂推理。Trade-off：RAG推理延迟高（检索+生成），微调后推理快（单次生成），但微调训练成本高（GPU小时数）。

3. 成本与延迟

Fine-tuning的隐性成本：训练成本（如微调7B模型需4×A100跑2小时，约$200），但推理成本低（单次生成0.1秒）。适合高并发、低延迟场景（如实时客服）。
RAG的隐性成本：检索延迟（向量检索+重排序，约100ms），但知识库维护成本低（只需更新文档）。适合知识频繁变化、但延迟容忍度高的场景（如内部知识库）。
实际落地的坑：RAG的检索质量不稳定，需加重排序（如Cohere Rerank）和阈值过滤，否则低质量检索会拉低整体准确率。

4. 数据隐私与合规

RAG优先：敏感数据（如医疗记录、金融交易）可本地化存储，只检索不训练。模型本身不接触原始数据，降低合规风险。
Fine-tuning需谨慎：微调需将数据暴露给训练流程，若用第三方API（如OpenAI微调），数据可能被用于模型更新。解决方案：用开源模型（如Llama 3）本地微调，但需自建GPU集群。

5. 混合方案：最佳实践

典型架构：先用RAG提供事实知识，再微调模型以更好地利用检索信息。例如：微调一个“检索增强生成器”，让模型学会在生成时优先引用检索结果，而非凭空编造。
具体实现：在微调数据中，将检索结果作为前缀（[Context] ... [Query] ...），训练模型学会“先看上下文再回答”。效果：在HotpotQA上，混合方案比纯RAG提升12% F1，比纯微调提升8%。
决策框架：画一个2×2矩阵（X轴：知识变化频率，Y轴：推理复杂度）。高频+低推理→RAG；低频+高推理→微调；高频+高推理→混合；低频+低推理→两者皆可，选成本低的。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从知识更新、推理能力、成本隐私三个层面回答。第一，知识频繁变化时选RAG，稳定且需深度内化时选微调。第二，任务需要特定推理模式（如SQL生成）时微调更优，事实性问答RAG足够。第三，RAG隐性成本在检索延迟，微调隐性成本在训练GPU。总结一句：RAG解决‘不知道’，微调解决‘做不好’，实际落地常用混合方案——RAG提供事实，微调优化生成逻辑。”

4️⃣ 高频追问 & 应对

追问 1：你提到混合方案，具体怎么设计微调数据？如果检索结果质量差怎么办？

微调数据构造：从知识库中随机采样，对每个query，用BM25+DPR混合检索Top-5文档，将文档拼接成[Context] ... [Query] ...格式。训练时，让模型学会在生成时优先引用检索结果。如果检索结果质量差（如召回率<70%），需在训练数据中混入“无检索”样本（即[Context] None），让模型学会在无信息时拒绝回答。同时，上线时加检索质量监控（如检索结果与query的cosine相似度阈值<0.5时，直接fallback到“无法回答”）。

追问 2：如果预算有限，只能选一个，你怎么选？

看业务核心指标。如果目标是提升用户满意度（如客服），选RAG，因为知识更新快、成本低，且能快速覆盖新问题。如果目标是提升任务完成率（如代码生成），选微调，因为推理能力提升更直接。预算有限时，RAG的ROI更高：只需一个向量数据库（如Pinecone免费层）和一个开源embedding模型（如BGE-small），总成本<$100/月。微调至少需要$500+的GPU时间。

追问 3：微调后模型会遗忘原有能力（灾难性遗忘），你怎么处理？

使用EWC（Elastic Weight Consolidation）或Replay Buffer。具体：在微调时，从原始预训练数据中采样10%作为replay数据，混合到训练集中。同时，学习率调低（如1e-5），只微调LoRA adapter（rank=8），冻结base模型。这样既能学习新任务，又不会破坏原有能力。实际测试：在MMLU上，微调后性能下降<2%，而任务准确率提升15%+。

5️⃣ 避坑 · 常见错误答法

❌ “RAG就是检索+生成，微调就是重新训练，两者互斥。” → ✅ “两者是互补的。RAG提供外部知识，微调优化内部推理。实际落地常用混合方案，比如微调一个检索增强生成器。”
❌ “微调成本太高，永远选RAG。” → ✅ “微调成本高，但推理成本低。如果业务需要高并发、低延迟（如实时翻译），微调的总成本可能更低。需要算总账：训练成本+推理成本×调用次数。”
❌ “RAG不需要训练，直接部署。” → ✅ “RAG需要调优：embedding模型选择（BGE vs OpenAI）、分块策略（chunk size 256 vs 512）、重排序模型（Cohere vs BGE-reranker）。这些调优直接影响检索质量，不是‘开箱即用’。”

6️⃣ 简历呼应

如果你有RAG项目：从“混合方案”切入，强调你在项目中如何用微调优化RAG的生成质量（如微调一个reranker或生成器），并给出具体指标提升（如F1从0.65到0.78）。
如果你只做过传统NLP：用“知识更新 vs 推理能力”类比迁移。例如：传统NLP中，规则系统（类似RAG）适合固定知识，神经网络（类似微调）适合复杂推理。强调你理解两者的trade-off。
如果你是校招无项目：聚焦论文复现demo。例如：用Llama 3复现“RAG+微调”混合方案，在HotpotQA上对比纯RAG和纯微调，并分析成本。展示你对决策框架的理解。
《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》（Lewis et al., 2020）
《LoRA: Low-Rank Adaptation of Large Language Models》（Hu et al., 2021）
《When to Use RAG vs Fine-tuning: A Practical Guide》（Hugging Face Blog）
《EWC: Overcoming Catastrophic Forgetting in Neural Networks》（Kirkpatrick et al., 2017）
《BGE: BAAI General Embedding for Retrieval》（BAAI, 2023）

—— 本场面试完 ——