这篇处理客户现场最常见的技术选型争论，立场明确：先 RAG，除非证据表明需要微调。
最值得拿走的是问题分界线：模型缺知识用 RAG 补，模型行为不对（格式、语气、流程遵循）才考虑微调。多数「微调需求」经诊断后其实是检索、prompt 或评测没做好。最容易走弯路的路径是一上来就收集数据做微调，成本高、周期长，还可能根本没对症。
相比站内术语卡与专题页，这篇给出的是现场对话用的判断流程，可与 PoC 时长问答连用。补充一个供应商语境的提醒：不少服务商把微调当作增值卖点兜售，客户听到的微调建议未必中立；交付方用评测数据代替倾向性推荐，是应对这种局面最可靠的方式。补充一个演进视角：随着上下文窗口与检索能力的增强，多数知识类诉求正被 RAG 方案持续消化；微调的适用面在收窄，先 RAG 的默认顺序短期内不会逆转。
读完建议做一件事：把你项目里「想微调」的诉求写下来，按文末三问重新诊断一遍。
—— FDEChina编辑部 · 实战派
RAG 和微调先做哪个？
直接回答：绝大多数场景先做 RAG。不是 RAG 永远更好，而是两者解决的根本不是同一个问题——RAG 解决的是「模型不知道」的知识问题，微调解决的是「模型行为不对」的表现问题。先分清你面对的是哪一类，选型就不再纠结。多数现场的「要不要微调」之争，根源是没做这个区分。
为什么建议 RAG 起步？三个理由。第一，对症面更宽：企业客户的诉求大多是「让模型用上我们的资料、我们的制度、我们的数据」，这是典型的知识问题，RAG 天然对口。第二，更新与溯源：业务知识天天在变，RAG 只需更新语料库，且回答能附引用来源，客户可以查证——这对企业客户几乎是必选项。第三，成本与周期：RAG 不需要训练数据工程和训练基础设施，几周内就能看到效果，符合快速验证的交付节奏，节奏设计见 PoC 要做多久才合理。
微调真正合适的场景是什么？当你面对的是行为问题：输出格式要严格遵循行业规范、语气要贴合品牌人设、要稳定执行一套特定流程、要在垂直领域的表达风格上更专业。这些靠检索补不进来，靠 prompt 又压不稳，微调才是对的工具。反过来说，如果客户提出微调，理由是「模型不懂我们的业务」，先别动手——这十有八九是知识问题，用 RAG 就能解决。两种手段的原理级说明见 RAG 专题，判定前的需求诊断方法见 范围界定手册。
还有一个常见真相值得坦白：很多团队感觉「该微调了」，诊断下来其实是三件更基础的事没做透——检索质量不行（该优化切片与召回）、prompt 没写好（该做上下文工程，见 上下文工程）、没有评测集（不知道问题出在哪，见 Agent 项目为什么必须做评测）。这三件事的成本都远低于微调，先把它们做完，如果行为问题依然存在，再启动微调不迟。给客户的沟通话术也简单：先用便宜可控的手段逼近目标，用评测数据说话，数据证明 RAG 到顶了，微调的预算才有意义。