Interview: RAG vs Fine-tuning：给你一个具体场景（如企业知识库问答），你如何做技术选型？
题目解析
这是一个高频面试题，考察候选人的系统思维和工程判断力。RAG和Fine-tuning不是互斥的，而是互补的。关键不是”哪个更好”，而是”在什么条件下用哪个”以及”什么时候两者结合”。以企业知识库问答为例，需要考虑数据特点、更新频率、精度要求、成本预算等多个维度。
解答思路
选择RAG的条件：1）知识库频繁更新（周级或更频繁）——微调无法跟上更新速度；2）需要精确的事实性回答和来源归因——RAG天然支持引用来源；3）知识库规模大(10万+文档)——微调难以记忆所有内容；4）数据敏感不宜用于训练——RAG不需要将数据送入训练流程。选择Fine-tuning的条件：1）需要特定的回答风格或格式；2）领域专业术语和表达方式与通用模型差异大；3）任务逻辑复杂，需要模型内化某种推理模式。
关键要点
- 最佳实践是RAG+Fine-tuning结合：微调模型学会利用检索上下文的格式和风格，RAG提供实时知识
- 成本对比：RAG的持续成本在检索基础设施，微调的成本在训练和数据标注
- 延迟对比：RAG增加了检索延迟(50-200ms)，微调不影响推理延迟
- 幻觉对比：RAG有检索失败风险，微调有记忆不准确风险
加分回答
可以提出一个决策框架：先用RAG快速上线(1-2周)，同时收集用户反馈数据。如果发现RAG效果不足，分析原因：如果是检索问题就优化检索；如果是模型理解问题就做微调。微调可以从LoRA开始(低成本低风险)，效果不够再考虑全参数微调。还可以讨论RPA(Retrieval-augmented Pre-training)的新范式——在预训练阶段就引入检索，让模型天然学会使用检索结果。
常见踩坑
- 在知识频繁更新的场景选择微调——模型会”记住”过时信息且无法高效更新
- 只用RAG不做任何模型适配——通用模型可能不理解领域术语导致检索和回答质量都差
- 忽略了混合方案的复杂度——RAG+微调的pipeline更复杂，需要更多工程投入