如何判断是自己 Prompt 写的不够好还是基座模型的能力不够，才需要做模型微调？
如何判断是自己 Prompt 写的不够好还是基座模型的能力不够，才需要做模型微调？
我自己踩过两边的坑——花了两个月标数据做 SFT，最后发现效果还不如好好写几版 Prompt；也反过来，死磕了很久 Prompt，最后才承认这个任务就是得微调。
怎么判断你属于哪种情况，说说我自己的做法。
"效果不好"不等于"模型不行"
很多人的思路是：试了几版 Prompt，效果不理想，那模型能力不够，上微调吧。
这个推理链条太短了。效果不好的原因起码有这么几层：你 Prompt 没说清楚模型要干什么，模型没理解意图；该给的背景知识没给，模型缺信息做判断；任务太复杂应该拆多步走，你非要它一步到位；最后才是模型基座能力确实撑不住这个任务。
只有最后一层才真正需要微调。但很多团队在第一层就跳到了最后一层。
先拿最强的模型跑一遍
这一步特别简单但很多人不做。
不管你最后打算用什么模型上线，先拿 Claude 3.5 Sonnet 或者 GPT-4o 这种当前最强的模型跑一遍你的任务。Prompt 可以写得很详细，不用管 Token 成本，Few-shot 例子使劲给。
这一步的意义在于确定天花板：如果最强模型 + 精心写的 Prompt 就能达标，那问题根本不在模型基座能力上，你要做的是想办法把这套 Prompt 策略迁移到你实际部署的模型上，或者用最强模型的输出做蒸馏。
我之前做过一个合同条款抽取的项目。团队一开始用 7B 模型跑，准确率 62%，立刻就说要微调。我让他们先拿 GPT-4o 跑了一遍同样的数据，准确率直接到了 91%。这就说明任务本身不难，7B 模型效果差是"模型太弱"不是"任务太难"。后来我们用 GPT-4o 的输出做了蒸馏，7B 模型提到了 85%，根本没花功夫自己标数据。
反过来，如果最强模型 + 你能想到的最好 Prompt 都搞不定，那要么是 Prompt 还能再优化（往下看），要么是真的需要微调了。
别凭感觉改 Prompt，做控制变量的测试
我见过最多的情况是：改了十几版 Prompt，每版改的地方不一样，最后也说不清到底是哪个改动起了作用，还是纯粹随机波动。
你需要的是消融实验。准备一个有标注的小测试集，哪怕只有五六十条也行，然后一次只改一个变量。
比如先测任务描述的清晰度。把"请分析这段文本的情感"改成"请判断以下用户评论的情感倾向，只输出正面、负面或中性三个词之一，不要输出解释"。如果第二版效果明显好过第一版，那说明不是模型的问题，是你没把任务讲清楚。
再测 Few-shot 的数量。0-shot、3-shot、5-shot、10-shot 各跑一遍。如果随着例子增多效果一直在涨，说明模型有这个能力，只是需要示范来激活，不需要微调。如果加到 3 个例子之后效果就不涨了甚至往下掉，说明 in-context learning 到头了，这时候微调才有意义。
然后测 CoT。不加推理步骤直接输出答案、加一句"请先分析再给结论"、给一套详细的分步思考指引，分别跑一遍。如果加了 CoT 效果有明显提升，说明任务需要推理而模型本身具备这个推理能力，只是你之前没引导它。
有个经验数据可以参考：如果通过这些实验，你最好的 Prompt 配置比最初的版本效果提升超过 20%，那 Prompt 工程还有很大的空间没挖完，先别急着微调。
把错误的 case 拉出来分类
这一步最花时间但最有用。不要只看准确率这种聚合指标，把模型答错的 case 一条一条拉出来看，分清楚它到底错在哪。
格式错了。 模型理解了任务但输出格式不对——你要 JSON 它给了 Markdown，你要求只输出标签它多写了一段解释。这种错误基本上 100% 能通过 Prompt 解决，加一句格式约束或者给个 Few-shot 就行，再不行用 Structured Output 强制约束。这种情况去微调纯粹浪费钱。
缺知识。 模型不知道你领域里的专有概念、术语或规则。比如你问它某个行业的监管细则，它给了个似是而非的回答。这种问题优先上 RAG，把知识文档检索出来塞到上下文里。只有当领域知识太复杂太隐晦，RAG 检索精度不够或者模型拿到文档了还是理解不了的时候，才考虑微调。
推理出了问题。 信息都给够了，但模型推理过程中某一步跳错了。先试着把复杂推理拆成多个简单步骤，每步让模型单独完成。如果拆到单步它还是搞不定，那可能真的需要微调来增强特定类型的推理。
风格对不上。 模型回答的"正确性"没问题，但语气、详略程度、表达方式不符合你的要求。比如你要简洁它啰嗦，你要专业它太口语化。这种问题是微调最擅长解决的。通过 Prompt 调风格有一定效果但有上限，而且 Prompt 越长 Token 成本越高。如果你的场景对风格有严格要求而且调用量大，SFT 在这类问题上的投入产出比是最高的。
分完类你就知道了：如果错误主要集中在格式和知识缺失上，那微调基本是浪费时间；如果主要是风格问题，那微调恰好是对症下药。
几个花了真金白银才学到的教训
第一个，用微调去解决 Prompt 能解决的问题。我见过一个团队标了 5000 条数据做 SFT，训练部署调了一个多月，最后上线效果和在 Prompt 里加 3 个 Few-shot 例子差不了多少。标注的人力成本、GPU 训练费用、模型部署运维的额外工作量，全打了水漂。
第二个，用少量数据微调来"灌知识"。微调不是往模型脑子里存知识的好方式。你拿 200 条数据微调出来的模型，对这 200 条的回答可能接近完美，换一批同类型但措辞不同的问题就不行了。泛化性极差。知识问题就老老实实用 RAG，微调的作用是调整模型的行为模式，不是给它补课。
第三个，不做基线对比就开始微调。你得先知道不微调的效果是多少，才能判断微调到底有没有用。有些人微调完觉得"效果还行"，但根本没跟纯 Prompt 方案对比过。也许一个好的 System Prompt 就能达到同样甚至更好的效果。
第四个，Prompt 改太多轮不知道收手。Prompt 优化的边际收益是递减的，通常前三五轮迭代能拿到大部分收益，之后再改来改去效果就在正负两三个百分点之间晃。如果你已经认真迭代了七八轮以上效果还是不达标，那大概率不是 Prompt 的问题了，该考虑别的方案了。
那微调到底什么时候有用？
题主说"大模型的能力已经非常强了，真的需要 SFT/RL 吗"，这个直觉大方向是对的。现在顶级基座模型加上好的 Prompt 工程，绝大多数任务确实够用了。
但微调在几个场景下还是绕不开的：
成本。你要用 1.5B 的小模型替代 API 调用来压成本，微调之后在特定任务上可以接近大模型的效果。不微调的话小模型的通用能力撑不住。
风格对齐。企业对输出的语气、格式、合规性有严格标准，靠 Prompt 调有上限，微调可以一劳永逸。
延迟和隐私。需要端侧部署、离线运行，或者数据不能出内网，那你就是得自己有个模型，微调是必经之路。
总结成一句话就是：微调是用来改变模型的行为模式的，不是用来补它的知识，更不是用来弥补 Prompt 写得不好。先把 Prompt 和 RAG 做到位，再决定要不要微调。