02. 为什么你的项目选择 RAG，而不是直接做微调？
整理项目中选择 RAG 的判断逻辑、适用边界与和微调的关系。
简单回答
这道题考的是你对 RAG 和 微调 各自适用边界的理解，以及你在项目中做技术选型时的判断逻辑。回答要围绕你的具体项目场景，从知识更新频率、可追溯性需求、数据量和资源、以及业务约束等角度说明为什么 RAG 是更合适的选择。同时要展示你知道微调也有它的价值、不是一概否定，以及在什么条件下你会考虑加入微调。
详细解释
这道题的考察点
面试官问这个问题不是想听你背 “RAG 和微调的区别”，而是想看你做技术选型时有没有清晰的判断框架。如果你的回答是 “RAG 比微调好所以选了 RAG”，那就完全答偏了——没有哪个技术方案是绝对更好的，关键在于为什么它更适合你的场景。
一个好的回答应该包含：你的项目场景有什么具体特征 → 这些特征为什么指向 RAG → 你有没有考虑过微调（以及为什么排除了或者计划后续加入）→ 实际验证下来效果如何。
典型的选 RAG 的理由
知识更新频率高。 这是选 RAG 最常见也最硬的理由。如果知识库每周甚至每天都有新文档加入、旧文档修改或废弃，微调根本跟不上——每次知识变更都要重新微调、重新部署，成本和周期完全不可接受。RAG 只需要更新向量库中的索引，通常是分钟级的操作。
“我们的场景是企业制度文档问答，制度文档每周都有更新和修订。如果用微调，每次更新都要重新训练和部署模型，周期可能要一两天。用 RAG 的话，新文档入库只需要跑一遍 Embedding 和索引，几分钟搞定。”
需要引用来源和可追溯性。 很多企业场景要求回答 “有据可查”——用户不仅需要答案，还需要知道答案出自哪份文档的第几条。RAG 天然支持引用标注（答案可以链接到具体的 Chunk 来源），微调的知识融入参数后是无法追溯来源的。
“我们的用户是合规部门的同事，他们需要看到回答引用了哪份制度文件的哪一条。这个需求微调做不到，因为知识已经融入参数了没法追溯。RAG 每个回答都能标注来源 Chunk 和原始文档链接。”
训练数据不足或标注成本高。 高质量的 SFT 数据需要大量的 (问题, 答案) 对，在很多企业场景下这些数据是没有现成积累的，标注成本也很高。RAG 不需要标注数据——只需要把原始文档灌进向量库就能开始工作。
计算资源和团队能力约束。 微调需要 GPU 资源做训练，需要有模型训练经验的团队成员。很多应用团队是做工程开发的，没有训练大模型的经验和资源。RAG 的门槛相对低——主要是工程实现，不需要训练模型。
对模型通用能力的需求。 微调有 “灾难性遗忘” 的风险——在领域数据上微调后，模型的通用能力可能下降。如果你的场景需要模型同时具备领域知识和通用对话能力，RAG 是更安全的选择——它不改变模型本身，只是在推理时提供额外信息。
什么时候应该考虑加入微调
回答这道题时如果只说 “选了 RAG” 不提微调，会显得视野不够宽。你应该展示你知道两者可以结合，以及在什么条件下你会考虑加入微调。
“纯 RAG 跑起来之后，我们发现模型在利用检索结果做回答时不够好——有时候会忽略上下文中的关键信息，有时候信息不足时不说‘不知道’而是自己编。这些问题本质上是模型的行为模式需要调整。如果后续要优化，我们计划用 SFT 微调一个更善于遵循指令、更善于基于上下文回答的模型——微调改变行为模式，RAG 提供知识。”
“另外我们有一些领域术语的理解问题——模型对某些行业缩写和专有概念不太懂。这个可以通过继续预训练或 SFT 来让模型更好地理解领域语言。但这属于优化阶段的事情，MVP 阶段 RAG 已经够用了。”
面试官可能的追问方向
“如果知识库很小（比如只有几十篇文档），RAG 还有必要吗？” ——知识库小时 RAG 的检索价值降低（几十篇文档用 Long Context 直接塞进去可能更简单），但可追溯性和更新便利性的优势还在。要根据具体场景判断。
“你有没有评估过微调的效果？” ——如果你做过对比实验更好。没做过可以诚实说 “当时的优先级是先把 RAG 做好，微调放在后续优化计划里”，但要说清楚你知道怎么做微调、什么时候该做。
“RAG 和微调能不能结合？具体怎么结合？” ——可以，而且很多生产系统就是这样做的。微调让模型更懂怎么利用检索结果（遵循指令、忠实上下文、说 “不知道”），RAG 提供实时知识。微调解决 “怎么做”，RAG 解决 “看什么”。
面试时可以这样答
选 RAG 主要基于三个考虑。第一是我们的知识库更新很频繁，每周都有新文档和修订，微调跟不上这个更新节奏。RAG 只需要更新索引，几分钟搞定。第二是业务上需要引用来源——用户需要看到回答出自哪份文档的哪一条，微调的知识融入参数后没法追溯。第三是团队和资源的现实约束，我们是工程团队，没有训练大模型的资源和经验，RAG 的落地门槛更低。
不过我也不是觉得微调没用。上线后我们发现模型在利用检索结果方面有一些行为问题——比如信息不足时不说 “不知道”，对领域术语理解不够好。这些是 RAG 解决不了的，需要通过 SFT 微调来调整模型行为。我们的计划是 RAG 先跑起来覆盖主要场景，后续再做微调优化模型对检索结果的利用能力。
两者不是互斥的，最佳实践是 RAG 提供知识、微调优化行为，配合使用。
常见追问
- 如果让你现在给项目加微调，你会怎么做？
- 你的 RAG 系统上线后效果怎么样？有哪些不足？
- 如果知识库很小只有几十篇文档，你还会选 RAG 吗？