一句话区分
- RAG（检索增强生成）：把外部知识以检索结果形式注入上下文，强调可更新与可引用。模型参数通常不变，知识更新主要来自索引与文档库。
- 微调（fine-tuning）：调整模型参数以适配任务分布，强调风格/格式/领域对齐，但更新成本更高，且需要更严格的数据治理。
两者不是互斥路线，但在资源有限时，优先顺序往往由问题类型决定。
何时优先考虑 RAG
在以下情况下，RAG 往往是更「划算」的第一选择：
- 知识频繁变化（政策、价格、产品文档、内部知识库）。
- 需要引用来源与可追溯答案，便于审计与纠错。
- 你希望最小化训练流水线复杂度，把迭代重点放在检索质量与分块策略上。
RAG 的典型代价是系统更复杂：索引、召回、重排、上下文拼接与幻觉治理都要工程化。别把它当成「只要_embedding 就能上线」。
何时考虑微调
在以下情况下，微调更值得认真评估：
- 你需要稳定的输出格式、术语体系或品牌口吻，而提示工程与少量示例仍不足。
- 评测显示问题主要来自「分布偏移」或「领域语言习惯」，而不是「缺知识」。
- 你有合规的数据治理与再训练流程，并能持续承担评估与回滚成本。
微调的风险在于：数据里的偏见与错误会被固化；版本管理与安全评估也要跟上线节奏绑定。
数据、隐私与合规：先问能不能用
无论 RAG 还是微调，都要先回答：训练或索引的数据是否有权使用？是否包含个人敏感信息？是否可以删除与更正？在 ToB 场景里，合同条款往往比技术偏好更先决定路线。
延迟与成本：把 SLA 写清楚
RAG 可能增加检索与重排的延迟；微调后的推理仍可能很贵，但可能减少提示长度与多轮对话轮次。把目标 SLA（P95 延迟、单次成本）写出来，再决定优化路径，而不是先选技术栈再补指标。
组合策略：常见但别迷信「万能配方」
工程上常见组合是：微调提升遵循指令与格式，RAG 提供最新事实。现实里是否值得同时上两条线，取决于团队规模、评测体系与维护预算。关键仍在于评测与监控，而不是名词本身。
决策树（简化版）
- 主要失败原因是「知识过期/找不到」→ 先加强 RAG 与内容运营。
- 主要失败原因是「格式不对/不听话」→ 先加强提示、工具约束与小样本微调评估。
- 两者都很严重 → 分阶段：先建立可靠评测，再决定组合比例。
结语
RAG 解决的是把对的知识在对的时间放进上下文；微调解决的是让模型更贴近你的任务分布。先诊断问题，再选武器，能省掉大量无效算力与无效数据标注。