微调、RAG 还是提示词：一张决策表选对适配方式

主轴：你想改的是「行为、知识还是指令」

三种适配方式本质上改的是模型的三样不同东西，混淆它们是选型错误的根源。提示词（prompting）改「当次指令」：不改变模型的任何持久状态，只在这一次调用里给出上下文与要求——改的是「这一句话」。RAG 改「可用知识」：把外部知识库接入检索，让模型基于检索内容作答——改的是「它能查到什么」，模型本身不变。微调（fine-tuning）改「行为模式」：用数据训练更新参数，改变模型的默认行为、风格、格式与技能倾向——改的是「模型本身」。

一个判别式可以帮助快速定位：问题出在「模型不知道怎么做」（行为/格式/风格），用微调；「模型不知道某件事」（事实/领域知识），用 RAG；「模型其实会，只是你没用对方式」，用提示词。三个典型的映射：客服回复的语气格式（行为 → 微调或 few-shot 提示）、产品手册的问答（知识 → RAG）、让模型输出 JSON（指令 → 结构化输出的提示词）。

决策表：八种常见诉求的适配方式

决策表的使用注意：多诉求并存时是「组合」而非「单选」——生产级的领域智能体常见形态是「微调管行为 + RAG 管知识 + 提示词管当次任务」的三件套（本库 Agent 工程系列的架构默认）。决策表的另一个使用提醒：先穷尽便宜的手段再上贵的——提示词的 few-shot（在 prompt 里给几个示例）经常能达到微调 80% 的效果（成本是零）；RAG 的查询改写与检索优化也常被低估——「微调」是三者中最贵的，永远放在最后尝试。

三种方式的成本与风险对照

提示词：成本近零、迭代最快（改完即生效）；风险是能力上限低（复杂行为教不会）、上下文有限（示例太多挤占窗口）、且每次调用都要付「示例的 token 钱」。RAG：成本中等（知识库建设 + 检索工程 + Embedding 维护，本库 RAG 手册的体系）；风险是检索质量决定一切（检索不准则答案必错——垃圾进垃圾出）、架构复杂度高（向量库、分块、重排的完整管线）。微调：成本最高（数据构造 + 训练管线 + 评测回归）；风险是灾难性遗忘（本库持续学习篇）、知识更新跟不上（训进去的知识冻结）、以及「数据质量决定成败」（垃圾数据的微调只会更差）。风险对照的一个总结句：提示词的风险在「上限」，RAG 的风险在「检索」，微调的风险在「数据与遗忘」——每种方式的坑都不在它的核心卖点处。

一个五分钟的自测流程

把决策表变成可执行的自测，五个问题按序问自己。问题一：先试提示词——用最好的模型 + 精心设计的 prompt（含 3–5 个示例）跑 20 个真实 case，够不够好？够 → 停（恭喜，零成本解决）。问题二：缺的是知识还是行为——case 分析失败的样本：「模型不知道资料」（→ RAG 方向）还是「知道资料但做得不像样」（→ 微调方向）。问题三（知识向）：知识会变吗？频繁变 → RAG；几乎不变且量小 → 也许长 prompt 就够。问题四（行为向）：行为能被 few-shot 表达吗？能 → 加示例进 prompt；不能（需要大量一致的行为模式）→ 微调。问题五：微调的前置数据——有没有几百到几千条高质量的「输入-理想输出」对？没有 → 先造数据（本库 SFT 篇的数据工艺），造不出来 → 回到提示词与 RAG 的组合。这个流程的价值是把「感觉该微调」的冲动，拦在「提示词与 RAG 还没试透」的事实面前——适配方式的选型，多数错误的方向是「太快上微调」。

决策表的实战补充：三种方式的失败案例与组合拳的实例

决策表（正文）的实战补充：三类典型的失败案例让边界更清晰。失败案例一：该 RAG 却微调。团队希望模型「了解公司产品」，用产品文档微调——结果：模型「背下」了文档但问法一变就答不出（知识被参数化但没被泛化）、文档更新后模型的知识就过期（重训成本高）、且虚构增多（半懂的知识让模型更自信地编）。复盘：知识型诉求走 RAG，检索让答案「每次都对着最新文档说」。失败案例二：该提示词却 RAG。简单的格式转换任务（把文本转成表格），团队搭了 RAG——检索在这里毫无意义（不需要任何外部知识），复杂度白加、延迟白增。复盘：指令型诉求先试提示词，RAG 是为「知识」准备的。失败案例三：微调数据不达标硬上。客户要求「学习他们行业的写作风格」，但拿不出样例数据——团队用网上爬的通用行业文本微调，风格没学会、通用能力受损（遗忘）。复盘：微调的前置数据（几百条高质量的「输入-理想输出」）不达标就别启动，先帮客户「造数据」（用强模型起草 + 客户修改，修改后的成品就是微调数据——数据飞轮的冷启动）。组合拳的实例把正面形态补上：一个法律科技产品的最终架构——SFT 微调（法律文书的格式与措辞行为）+ RAG（法条与判例的实时检索）+ 提示词（每个任务的指令与验收要求）+ 结构化输出（文书的 JSON 模板）——四层各司其职。选型的终局认知：三种方式不是竞争关系，是同一套系统的三个执行层——决策表帮你选第一个切入点，系统设计让它们最终协同。

适配方式的演进视角：三种方式的能力边界在移动

决策表（正文）的边界不是静态的——模型能力的每一代升级都在移动三种方式的边界，演进的视角让选型有了时间维度。移动的方向一：提示词的能力上探。模型的原生能力越强（指令遵循、长上下文、原生工具调用），提示词能覆盖的诉求越多——两年前需要微调才能实现的稳定格式输出，如今 JSON mode 原生解决（本库结构化输出篇）——「简单行为适配」正在从微调的领地划归提示词。移动的方向二：RAG 的架构下沉。长上下文的扩大让「全文塞窗口」在中小知识库成为可能（免检索）——「知识适配」在中小规模场景正在从 RAG 划归长上下文；超大知识库仍是 RAG 领地（窗口放不下）。移动的方向三：微调的阵地收缩与深化。微调被挤出的领地（简单行为、小知识量）换来的是阵地深化（深度风格、专有技能、领域的深度对齐——这些是提示与 RAG 无法到达的），LoRA 的低成本让「深度微调」的门槛也在下降。演进视角的选型含义：决策表的答案每年要重估——去年选微调的决策，今年先用新一代模型的提示词复测一遍（复测成本远低于维持微调管线）；「模型在进化，选型要跟着进化」——静态的选型决策在动态的能力边界前，迟早过时。

适配决策的实测示例：同一个需求的三种实现对比

决策表（正文）的实战收尾：用一个具体需求的「三种实现对比」演示决策过程。需求：让模型用「本公司客服的专业口吻」回答产品问题。实现一：纯提示词。system prompt 里写风格指南 + 3 个示例——成本半天，效果：风格相似度约 70%（示例内的任务相似），新任务类型（没示例覆盖的）风格漂移。实现二：RAG + 提示词。知识库放产品文档（事实）+ 提示词管风格——效果：事实准确性大幅提升（有据可答），风格仍是提示词的 70% 水平。实现三：微调（SFT）。收集 2000 条真实客服对话微调——效果：风格相似度 90%+（口吻、措辞习惯、处理流程的「肌肉记忆」），但事实更新需要配合 RAG（模型内的产品知识会过时）。最终形态：实现三 + 二的组合（微调管风格、RAG 管事实）——风格 90% + 事实准确。决策过程的复盘：如果只允许选一种——先选「实现二」（RAG 的事实准确是底线，风格是锦上添花）；预算允许再上实现三补风格。这个对比演示了决策表的使用方式：三种方式不是并列的选项，是可以分阶段叠加的组合——每一阶段解决上一阶段留下的短板，预算与优先级决定叠加的次序。

小结

三种适配改三样东西：提示词改当次指令、RAG 改可用知识、微调改行为模式。判别式：不知道怎么做（行为）→ 微调；不知道某件事（知识）→ RAG；其实会但没用对 → 提示词。成本与风险对照：提示词便宜但上限低、RAG 成败系于检索、微调最贵且坑在数据与遗忘。五分钟自测流程的核心是次序——先穷尽提示词（few-shot 常达微调八成效果）、再 RAG、微调永远最后，且微调的前置数据不达标就回到组合方案。生产级形态常是三件套：微调管行为、RAG 管知识、提示词管当次任务。