微调、提示词还是 RAG：三条路的效果分界与成本账

团队里常出现这种场景：模型答得不够准，有人提议补检索，有人想直接微调，还有人觉得把提示词再写细一点就行。三条路的投入差着量级，选错方向要么白花钱，要么效果始终差一口气。这篇给一张按症状对照的决策表、每步的先决条件与验证动作，以及微调落地后你必须长期承担的那部分成本，帮你把路线定下来再动手。

模型答得不够准，团队里通常同时冒出三种声音：把提示词再写细一点、赶紧补个检索、要不直接上微调。三条路的投入差着量级，选错方向的结果是要么白花钱，要么效果始终差一口气。这篇不讲概念，只给一条按症状走的选择路径和每步的验证动作。

先记住一个前提：选路不是按预算选，而是按「你缺的到底是什么」选。缺指令就去改提示词，缺资料就去补检索，缺行为习惯才轮到微调。把这三件事混淆，是绝大多数定制项目翻车的起点。

先把三条路各自在改什么说清

提示词改的是输入侧的指令与示例，模型权重不动，改完立刻生效，代价是占用上下文窗口；RAG 改的是模型能看到的外部资料，检索准不准直接决定一半效果；微调改的是权重本身，它改变的是行为习惯与输出风格，而不是往模型里塞新知识。这一点最容易被误解。

提示词

把要求、步骤、示例写清楚，模型当场照做，权重不变

RAG

先把相关资料检索出来再一起送进上下文，模型基于资料作答

微调

用你自己的样本继续训练，改变的是输出习惯与风格分布

决策表：按症状选路，而不是按预算选路

下面这张表按你观察到的症状来定位。用法是：从最上面一行往下扫，命中哪行就先做哪行的动作，不要跳步。跳步的代价通常是花了微调的钱，却解决了本该用检索解决的问题。

还有一条容易忽略的：如果你的场景对时效性敏感，检索几乎是必选项，因为微调学到的知识在训练那一刻就冻结了。这类场景里，微调只在输出风格层面有意义，不要指望它替你更新事实。

提示词的天花板在哪，什么时候该承认它到顶了

提示词能稳定解决的是表达与流程问题，解决不了模型没见过的事实。判断是否到顶，看三个信号：反复调措辞但收益递减、示例越加越长而准确率不涨、上下文被示例挤到没有空间放真正的内容。出现任意两个，就该承认这条路到顶了。

• 收益递减：改五版措辞，评测分数在一两分内来回晃
• 示例膨胀：从三个示例加到十个，错误类型没有减少
• 上下文挤压：示例占了大半窗口，真实输入反而被截断
• 泛化差：调好的一版换个说法提问就失效
• 不稳定：同一输入两次跑出不同结构，说明缺少硬约束

到顶之后先别急着上微调，回头确认一件事：你遇到的是知识问题还是指令问题。很多人把「模型不知道我们内部术语」当成指令问题去调提示词，结果怎么调都不对。不适用提示词优化的场景也很明确：任务本身高度依赖长尾格式或领域专有用法时，提示词很快见底。

RAG 优先：多数「模型不懂我们业务」其实是检索问题

补检索之前先做召回评测，量一个指标：正确文档有没有被取回来。这一步不过关，后面调什么模型都没用，因为你根本没把该给模型的资料递到它手上。召回率和最终答案准确率是两段独立的指标，要分开量，不要只看最后答得对不对。

具体选型可以去 /embeddings 看嵌入模型的对照，向量库方案在 /stacks/vector-dbs 有整理，两处都能核对当时的口径与数字，不要凭印象选。有一种情况不适合优先做检索：资料本身极少或几乎不变，这时候直接塞进提示词可能比搭一套检索链路更省，别为了架构好看硬上。

什么情况才值得微调：四个先决条件

微调不是不能做，而是有条件。下面四条同时满足，才值得投入；缺一条，先回去补那条，不要硬上，否则训练出来的只是一个把噪声学得很稳的模型。

1. 样本够且标注一致样本量和质量都要够，标注口径要统一。翻一翻历史样本，看同一类问题有没有互相矛盾的标法，有就先统一再说。
2. 任务目标稳定任务口径不会几周换一次。如果业务规则本身在快速变，微调出来的模型很快过期，不如用提示词加检索灵活应对。
3. 基线已量化提示词加检索的组合已经跑过并记录过分数，你清楚自己差多少、差在哪一类问题上。没有基线，微调之后你连有没有变好都说不清。
4. 愿意承担重跑成本接受每次换基座都要重新准备数据、重跑训练、重新验证。不接受这一条，就别开始。

选服务商的时候去 /stacks/fine-tuning 对比，重点看它支持哪些训练方式、能不能导出你需要的格式、以及数据留在哪里。这几个点决定的是你后面能不能换供应商，比单次价格更影响长期成本。这里不写具体数字，价格与规格到站内页面核对当时的版本。

微调之后躲不掉的三笔账

微调最容易被低估的是训完之后的部分。训练只是起点，真正持续消耗的是下面三笔账。算不过这三笔，微调就是负债而不是资产。

这三笔账里最容易被跳过的是评测成本。没有固定评测集，你就没有判断依据，只能靠感觉，而感觉在模型迭代面前几乎无效。所以顺序上，先把评测建起来再谈训练，这条没有例外。回归成本还有一层：即使你什么都没改，上游基座一变，你的微调版本可能就不再是最优解，需要重新对照。

微调改变的是模型说话的方式，不是它知道的事情；搞混这两者，方向一开始就错了。

落地顺序：一条不会亏的推进路线

最后给一条推进顺序。它的好处是每一步都能停下来，收益不达预期就回退，不会一次性押上全部预算。核心原则是：任何一步投入前，先确认上一步的收益已经收敛。

1. 固定评测集与基线先定下什么算达标，把当时的基线分数记下来。评测集要覆盖你最常出错的几类场景，不要只挑简单题。
2. 只动提示词在基线之上改指令和示例，每次改动都记录分数变化。这一步成本最低，先把它的空间用尽。
3. 补检索并分两段量单独量召回指标和最终答案指标，两个数分开看，才知道问题出在取资料还是用资料。
4. 小规模微调对照用一小批高质量样本做对照实验，跑不过上一步的基线就果断回退，不要因为已经投入了就硬撑。
5. 定型后建回归流程模型上线不是终点，把回归评测固化下来，基座更新或数据变化时按流程重跑一遍。

整条路线的判断标准可以收成一句：能用提示词解决的不补检索，能用检索解决的不微调，只有前三步都量化过、确认收敛之后，微调才值得进入议程。每一步都要留下数字，不然你无法判断下一步该不该走。