先这样答
先说判断依据：这两个东西解决的不是一类问题。RAG 解决「模型不知道」：把外部知识挂到检索上，答案能标出处，知识库更新了模型立刻就懂。微调解决「模型不像」：底模的表达方式、输出格式、领域术语的用法不对，用数据把它掰过来。
所以选型看三问。第一问：需求会不会变？产品知识每周都在更新的，微调追不动，只能 RAG。第二问：答案要不要可追溯？法务、医疗、企业内部制度这类场景，答案必须能指到原文，RAG 天然带引用，微调给不了。第三问：差的是知识还是能力？让模型学会输出 JSON、学会客服话术、学会某个行业的表达习惯，这是微调的活；让模型知道你家产品手册第几页写了什么，这是 RAG 的活。
实际项目里通常是组合：先上 RAG 把知识接进来跑通，等发现模型「看得懂资料但说不出人话」，比如总把检索到的内容复述得生硬、不遵守输出模板，再补一层微调。
面试官会怎么追问
- RAG 也有短板吧？ 有。检索不准答案就不准，链路长导致延迟高，而且上下文窗口有限，塞不下太多检索结果，这些都是工程上要逐一处理的。
- 什么时候只用微调就够？ 任务封闭且稳定的场景。比如固定格式的信息抽取、固定风格的改写，知识都长在任务里，不需要外部资料，微调一个小模型比 RAG 便宜也快。
- 微调能让模型「记住」新知识吗？ 能记一部分，但不可靠，还容易产生幻觉。让模型背知识，不如让模型查知识，这也是为什么知识类需求业界默认走 RAG。
- 两个都上了，顺序怎么定？ 先 RAG 后微调。RAG 的效果立竿见影、可控可回滚；微调动的是模型本身，出了问题排查成本高。
回答的坑
- 把二者说成二选一。面试官想听的是分层判断：知识问题走检索，行为问题走训练。
- 只说「RAG 实时性好」就停了。补一句代价：检索质量决定上限、链路复杂。有这句说明你真搭过。
同系列的题
—— 本题完 ——