技术评审里最常见的万能建议，大概就是这句话。
- 用户说答案不准确 → "微调吧"；
- 说格式不统一 → "微调吧"；
- 说知识过期了 → 还是"微调吧"。
微调确实是个万能词，但它不是万能解。
有一类需求用微调做，投入大、效果还差；而用检索，可能一周就上线了。
更糟的是另一个方向的错误：用检索去解决"输出风格统一"这种问题，你会发现怎么调召回都不对——因为问题根本不在"找什么"，而在"怎么说"。
这篇文章把三个手段的边界划清楚，并给一条从便宜到贵的决策路径。
第一部分：先划清层次——三者根本不是同类
1.1 各自的职责范围
| 手段 | 控制什么 | 作用范围 | 特点 |
|---|---|---|---|
| 提示词（含上下文工程） | 这一次请求怎么被理解和执行 | 单次调用 | 影响最小、成本最低、迭代最快 |
| 检索增强（RAG） | 模型能看到哪些外部信息 | 知识的来源 | 适合频繁变化、规模巨大的知识 |
| 微调 | 模型的输出行为与表达方式 | 模型的默认倾向 | 适合稳定的格式、风格、领域表达 |
1.2 所以正确的提问方式
不是"用哪个"，而是先问"我缺的是哪一层"。
| 缺什么 | 用什么 |
|---|---|
| 缺知识 | 检索 |
| 缺格式一致性 | 微调 |
| 缺正确的指令表达 | 提示词 |
三种病，三种药。
这个"分层"的视角很关键：它让你不把这三者看成"三个竞争的方案"，而是"三个不同层级的工具"。分层之后，"选哪个"这个问题本身就消失了——你只需要诊断缺哪一层。
第二部分：判据一——知识是动态还是静态
这是最有效的一条判据。
2.1 知识会频繁变化 → 必须走检索
典型场景：制度更新、价格调整、产品迭代。
原因很直接：
| 检索 | 微调 | |
|---|---|---|
| 知识存放位置 | 外部文档 | 烧进权重 |
| 更新方式 | 改文档 | 重新训练 |
| 生效时间 | 分钟级 | 天级（还要重跑评测、重新部署） |
更新成本的差距有多大？检索是分钟级到小时级；微调是天级。
2.2 知识长期稳定 → 对微调更友好
比如某个专业领域的固有概念体系。
这类知识不变，所以"烧进权重"的代价可以被摊薄。
2.3 一句话判据
会变的放外面，不变的可考虑放里面。
这个"内外"的比喻很好用，因为它直接对应了实现方式：放外面 = 检索，放里面 = 微调。
而且它自带一个推论：现实中大部分业务知识都在"会变"这一侧——产品在迭代、政策在调整、价格在变化。所以大部分知识类需求，答案都是检索。
2.4 一个常被忽略的成本对比
除了更新时间，还有一个隐性差异：可溯源性。
- 检索：能给出出处（"根据《XX 规定》第 3 条"）；
- 微调：说不出来源，因为知识已经融进权重了。
在需要审计、合规、追责的场景里，能不能给出处往往是硬性要求 ——这时检索不只是"更新快"，而是"唯一可行"。
第三部分：判据二——你要改的是"内容"还是"方式"
第二条判据同样好用。
3.1 需要改变"输出长什么样" → 微调更合适
典型信号：
- 格式总是不对（多一个字段、少一个括号）；
- 风格不稳定（时正式时随意）；
- 术语用得不地道；
- 该简略的地方写得很长。
这类问题检索解决不了，因为知识本来就在模型里，问题在"怎么表达"。
3.2 需要"知道更多事实" → 检索更合适
典型信号：
- 模型不知道某个具体产品型号；
- 不知道某条内部规定；
- 不知道最新的政策。
这类问题微调能做，但代价大、更新难，而且容易出现"说得像但记不准"。
特别注意最后这句话：用微调灌知识的失败模式不是"答不出来"，而是"流畅地说出一个错误的答案"。这比"不知道"更危险，因为它更难被发现。
3.3 一句话区分
微调改的是习惯，检索补的是资料。
"习惯"和"资料"这两个词选得很准：
- 习惯是稳定的、内化的、不需要每次提醒的；
- 资料是外部的、需要查的、会变的。
第四部分：判据三——成本与迭代速度
把三者的经济性摆在一起看，决策会更清晰。
4.1 六维对比
| 维度 | 提示词 | 检索增强 | 微调 |
|---|---|---|---|
| 首次投入 | 极低（小时级） | 中（周级，需建库与评测） | 高（数据 + 训练 + 评测） |
| 单次推理成本 | 低 | 中（多一次检索） | 低（但可能更长上下文） |
| 更新知识的成本 | 改提示词 | 改文档，分钟级 | 重训 + 重评测，天级 |
| 调整格式/风格的难度 | 中（不稳定） | 高（不适用） | 低（稳定） |
| 可控性与可解释性 | 中等 | 高（能给出处） | 低（黑盒行为） |
| 主要风险 | 效果不稳定 | 召回不准、切分不当 | 遗忘、成本、更新慢 |
4.2 读表的关键
检索和微调各有不可替代的优势——检索赢在"更新快、可溯源"，微调赢在"稳定、可控风格"。
"各有不可替代"这个判断很重要：它意味着两者不是竞争关系。如果你发现自己在"二选一"，那大概率是诊断错了需求。
4.3 一个容易被忽略的维度
注意"单次推理成本"这一行：
- 提示词：成本随上下文长度线性增长；
- 检索：多一次检索的开销（向量搜索 + 重排），但通常远小于把全部文档塞进上下文；
- 微调：推理本身没有额外开销，但如果因为微调而需要更长的系统提示，成本也会上去。
这一行的启示是：成本不是靠"选了哪个方案"决定的，而是靠**"每次请求实际用了多少 token"** 决定的。
第五部分：一条从便宜到贵的决策路径
按这个顺序走，多数需求能在前三步解决。
5.1 第一步：先优化提示词与上下文组织
具体做什么：
- 明确任务（说清要干什么）；
- 给出示例（few-shot）；
- 规定输出格式；
- 把关键信息放在两端。
这一步能解决相当一部分"效果不好"。
5.2 第二步：问题在"缺知识"吗？
是 → 上检索。
但注意做法：先做最朴素的版本——切分 + 向量召回 + 带来源生成。
不要一上来就上混合检索和精排。
为什么？ 因为朴素版本能快速告诉你"这条路是否可行"。如果朴素检索都召不回正确内容，那问题在数据或切分方式，加精排也救不了。
5.3 第三步：问题在"格式/风格不稳定"吗？
是 → 考虑微调。
但先试结构化输出的约束（让模型按固定结构返回），很多格式问题在这一步就能解决。
这一步经常被跳过，直接奔向微调。但结构化输出（JSON schema 约束、约束解码）的成本几乎为零，而它能解决大部分"格式不对"的问题。
5.4 第四步：两者都有？
那就组合——检索提供知识，微调调整表达。
注意顺序：先把检索做扎实，再加微调。
顺序的理由见下一部分。
5.5 第五步：问题在"推理能力不够"吗？
这通常不是微调能解决的。
两个方向：
- 换基座模型（更强的基座）；
- 拆成多步流程（让每一步都变简单）。
拆流程这一招经常被低估：如果一个问题需要 5 步推理，而模型单步能做对 85%，那么整体全对率可能只有 44%。但如果把 5 步拆成 5 次独立调用，每步都能给足上下文和检查点，整体成功率会高得多。
5.6 这条路径的价值
每一步都是成本最低的尝试，失败了你只损失了少量时间。
注意最后这句话：它的设计逻辑是**"把风险成本降到最低"**，而不是"最快达到最优效果"。这在工程上是更稳健的思路——因为你没法保证一次就选对，但可以保证"试错很便宜"。
第六部分：组合的正确姿势——检索在前，微调在后
如果确实两个都要，顺序很重要。
6.1 为什么先检索
因为检索解决的是"有没有料"，这是硬约束。
如果模型根本看不到正确信息，微调再完美也只能"流畅地答错"。
这是一个必要条件关系：料的正确性是前提。前提不成立，后面的优化都是无效的。
6.2 为什么后微调
因为微调解决的是"表达是否稳定"。
当料已经齐了，再训练输出格式，梯度信号才明确。
这句话的技术含义是：如果输入里没有正确信息，模型只能靠猜——而"猜"的过程中产生的输出，会给出错误的训练信号。
6.3 组合时必须注意的两件事
注意一：训练数据要包含"带检索结果"的输入格式。
推理时输入里会有检索到的文档片段。如果训练时没见过这种格式，模型的表现会打折。
这是最容易出的低级错误。
它的具体表现：模型在评测时表现得"不知道怎么用给的材料"，要么忽略材料直接靠记忆回答，要么完全不引用。
解决方案很直接：在构造训练数据时，就把检索结果拼进去，用和推理时完全相同的模板。
注意二：微调可能降低对检索内容的"忠实度"。
机制：微调让模型更倾向于按训练时的模式输出。如果训练数据里存在"无视上下文直接回答"的样本，会削弱它对检索结果的依赖。
解决方案：训练数据里要专门放入"依据给定材料回答"的样本，而且在材料里没有答案时，要教它说"根据提供的材料无法回答"。
6.4 一句话总结组合逻辑
检索是"喂料"，微调是"教规矩"，先喂料再教规矩。
第七部分：三类典型需求的完整答案
给三个具体场景，把上面的逻辑串起来。
7.1 场景一：企业知识库问答
需求特征：
- 知识经常更新；
- 需要给出处；
- 答案要求准确。
结论：检索为主。
具体配置：
- 提示词负责"必须引用来源、材料里没有就说不知道"；
- 不需要微调，除非输出格式有强要求（比如必须返回结构化 JSON）。
验证这个结论：如果知识更新频率是每周，那么微调意味着每周都要重训+重评测+重新部署——显然不现实。
7.2 场景二：客服话术统一 + 语气规范
需求特征：
- 知识基本固定（产品信息）；
- 但要求话术统一、不能乱承诺。
结论：微调为主。
具体配置：
- 用历史优质对话做训练数据，把"语气 + 边界"训进模型；
- 加上提示词约束兜底；
- 知识部分若确实需要，再补一个轻量检索。
注意这里的"边界"：不能乱承诺是一种行为倾向，不是知识。而行为倾向正是微调擅长改的东西（这也是它必须是微调而不是检索的原因）。
7.3 场景三：结构化信息抽取
需求特征：
- 从文本里抽固定字段；
- 格式必须严格。
结论：先提示词 + 结构化输出约束，不够再微调。
理由：这类任务格式明确、可校验，微调的收益常常很明显，因为它是纯粹的"表达形态"问题。
为什么说"不够再微调"：因为结构化输出约束（schema 约束解码）本身就能解决绝大部分格式问题，而且成本几乎为零。
7.4 三个场景的共同点
判断依据是"知识是否变化"和"约束是内容还是形态"，而不是模型大小或用例名称。
这个规律的实践价值在于：它让你可以在没有先例的新场景里也做出判断，而不只是套用别人的方案。
常见误区
误区一："知识更新用微调最快。"
恰恰相反。
微调更新知识是三种手段里最慢、最贵的一种，还要承担遗忘风险。
误区二："RAG 效果不好就换微调。"
先确认检索本身有没有召回正确内容。
召回不准的情况下换微调，等于把"检索失败"掩盖成"模型不会说"。
这个掩盖的后果很严重：你会以为是模型能力问题，于是投入大量资源做微调，而真正该修的是切分策略或 embedding 模型。
误区三："三个都上最保险。"
三个都上会让问题难以归因 —— 效果不好时你分不清是谁的锅，调试成本急剧上升。
建议增量引入，每次只加一层。
"增量引入"这个原则值得强调：它让每一步的效果都可测量、可归因。而"一次性全上"会让你失去所有诊断能力。
误区四："提示词是临时方案，正经项目要微调。"
提示词和上下文工程是长期能力，不是过渡方案。
很多成熟产品主要靠上下文组织，而不是靠微调。
这个误区背后的假设是"越重的技术越正式"，但实际工程里恰恰相反：越轻的手段越容易迭代、越容易维护。
误区五："微调之后就不再需要检索了。"
如果知识会更新，必须保留检索。
微调后的模型依然不知道上周新发的文件。微调只改变它"怎么说"，不改变它"知道什么"。
误区六："RAG 和微调同时上就是最优解。"
不一定。 只有当"知识需要外部供给"且"表达需要稳定"两个条件同时成立时，组合才是有意义的。
而且组合会带来两个额外成本：训练数据要包含检索格式；要防止微调削弱忠实度。这两项都需要额外投入。
所以组合不是"更高级"，而是"两个问题都需要解决时的必然选择"。
实战问答
Q1：面试问"RAG 和微调怎么选"，怎么答得清晰？
A：按"立框架 → 给判据 → 补成本 → 说顺序"四步。
第一步，立框架：
RAG 管知识、微调管表达。
第二步，给判据：
- 知识是否频繁变化 → 变就上 RAG；
- 约束是内容还是形态 → 形态就考虑微调。
第三步，补成本对比：
RAG 更新是分钟级，微调是天级。
第四步，说清组合顺序：
先检索把料喂对，再微调把表达训稳。
这四步的结构优势在于：它不只回答了"怎么选"，还回答了"选完之后怎么用"。
Q2：我们的 RAG 效果不好，是不是该微调了？
A：先做归因，别急着换方案。
看三个指标：
| 观察 | 结论 |
|---|---|
| 召回的块里有没有答案 | 没有 → 检索问题（改切分、改 embedding、改召回策略） |
| 有答案但答案没用上 | → 提示词约束问题（明确要求"依据材料回答"） |
| 用上了但表达不好 | → 这才是微调的场景 |
多数"RAG 效果不好"最终落在前两类。
这三步归因的成本是"拿 20 条失败样本人工看一遍"，大约半小时——但它能避免几周的无效微调。
Q3：微调之后还要不要保留 RAG？
A：看知识性质。
如果知识会更新，必须保留检索——微调后的模型依然不知道上周新发的文件。
微调只改变它"怎么说"，不改变它"知道什么"。
这句话值得反复强调，因为它是很多架构决策的分界线。
Q4：三个手段能不能同时上，会不会打架？
A：可以共存，但要注意两件事。
第一，训练数据的输入格式要与推理一致（包含检索结果的那种格式）。
第二，风险在于归因困难 —— 出问题时不知道是谁的锅。
建议增量引入：每次只改一层，并保留评测基线。
具体做法：每引入一层，都记录"改之前"和"改之后"的指标。这样任何变化都能归因到具体的那一层。
Q5：我怎么知道该先做提示词还是先做检索？
A：问一个问题：
"这个错误，是模型不知道，还是模型没按我要的方式说？"
| 答案 | 先做什么 |
|---|---|
| 不知道 | 检索（先补知识） |
| 不知道怎么说 | 提示词（先明确要求） |
如果答案是"我也说不清"，那就先花半小时做提示词优化——因为它的成本最低，而且它还能帮你更清楚地看到"到底缺什么"。
一个实用技巧：在提示词里明确写"如果你不知道，就说不知道"。如果模型开始频繁说"不知道"，那知识缺口就暴露出来了 ——这时候你就知道该上检索了。
Q6：结构化输出约束能解决多少格式问题？
A：大部分。
能解决的：
- JSON 结构不对、字段缺失、多余字段；
- 枚举值超出范围；
- 类型错误（该是数字给了字符串）；
- 输出里有额外解释文字。
解决不了的：
- 内容本身选错了字段（比如把"收货地址"填进了"账单地址"）；
- 需要理解语境才能填对的值；
- 格式之外的行为倾向（比如"不能乱承诺"）。
所以判断标准是：
如果问题是"结构不对"，用约束；如果问题是"填得不对"，才需要微调。
区分这两者能省掉大量微调工作。
术语表
| 术语 | 含义 |
|---|---|
| 提示/上下文工程 | 通过组织输入来控制单次请求的行为 |
| 检索增强（RAG） | 在生成前检索外部资料并放入上下文，解决知识来源问题 |
| 微调 | 通过训练调整模型行为，解决输出形态与稳定性问题 |
| 结构化输出约束 | 强制模型按给定结构返回内容，可在不微调的情况下大幅改善格式问题 |
| 归因 | 定位"效果不好"具体出在检索、生成还是表达环节 |
| 增量引入 | 每次只增加一层手段，便于对比与定位问题 |
| 忠实度 | 模型输出与给定材料的一致程度，是 RAG 场景的核心指标 |
结语
把这篇压缩成三句话：
第一，RAG 管知识、微调管表达、提示词管这一次怎么问——三者是不同层次，不是替代关系。
搞混层次，就会出现"用微调去更新知识"这类注定低效的做法。
第二，判断顺序是：
① 知识是否频繁变化？ 变 → 检索（更新成本分钟级 vs 天级）
② 约束是内容还是形态？ 形态 → 微调（先试结构化输出约束）
③ 推理能力够不够？ 不够 → 换基座或拆流程（微调补不上）
第三，"两者都要"时，一定是先把检索做扎实，再训练表达。
检索是"喂料"，微调是"教规矩"。
而如果只允许带走一条判据，那就是：问自己"这是知识问题还是表达问题" —— 这一个问题，能定掉大部分选型。
