每当有人问我「要不要微调模型」，我的第一反应都是反问，「你试过 RAG 了吗，prompt 调过了吗」。九成的情况下，答案是没试透，就想着微调了。
微调是 LLM 定制里听起来最高级、实际上最容易被滥用的手段。它给人一种「我在做深度定制」的高级感，但成本高、风险大、而且很多场景根本不需要它。这篇讲清楚什么时候该微调、微调什么、怎么评估，帮你在「要不要微调」这个问题上做出正确判断。
先搞清楚定制的几个层次
图：LLM 定制的三个层次——Prompt 工程、RAG、微调，成本与复杂度逐级上升，原则是从轻的开始试。
LLM 的定制不是只有微调一个选项，它有几个层次，从轻到重。
最轻的是 prompt 工程。改 prompt 的措辞、结构、示例，让模型表现得更好。成本最低，改完立刻能验证，而且随时能改回去。绝大多数问题，先在这里解决。
中等的是 RAG。把外部知识检索出来喂给模型，让模型基于这些知识回答。解决「模型不知道某个领域的知识」这类问题。成本中等，但要搭一套检索管线。适合需要动态、可更新知识的场景。
最重的是微调。用领域数据重新训练模型的一部分参数，让模型「内化」某些能力或者风格。成本最高，需要数据、算力、专业知识，而且改了不容易回退。
这个层次的关键原则是，从轻的开始试。能用 prompt 解决的别上 RAG，能用 RAG 解决的别上微调。每一层升级，意味着成本和复杂度大幅上升，只有下一层确实解决不了，才往上走。
微调真正擅长的几件事
微调不是万能药，但它确实有几件事是 prompt 和 RAG 做不到或者做不好的。
风格和格式的稳定输出。你希望模型始终用特定的语气、特定的格式、特定的结构来回答。prompt 能引导但不够稳定，尤其在长对话里模型会「漂」。微调能把这种风格固化进模型参数，输出更稳定。
特定任务的性能提升。某个具体任务（比如特定格式的信息抽取、特定领域的代码生成），通用模型表现一般，用任务相关的数据微调，能显著提升这个任务的性能。
降低推理成本。如果 prompt 里要塞大量示例和指令才能让模型表现好，每次调用的 token 成本就高。把这些「示范」微调进模型，推理时用很短的 prompt 就能达到同样效果，长期省 token。
降低延迟。prompt 越短推理越快。微调让模型在短 prompt 下也能表现好，间接降低了延迟。
注意一个共性，这些场景都是「把 prompt 里反复要做的事，固化进模型」。如果某个能力靠 prompt 每次都能做到，微调的价值就不大。微调的价值在于，让那些靠 prompt 做不稳、做不快、做不省的事情，变稳、变快、变省。
微调不擅长的事
图：微调擅长（绿色，风格格式、任务性能、降本降延迟）与不擅长（红色，知识注入、消除幻觉、通用提升）的对照。
反过来，有些问题微调解决不了，但很多人误以为它能。
知识注入。想让模型知道某个领域的事实性知识，微调不是好办法。微调让模型「记住」的知识是不可靠的（它会幻觉），而且更新困难（知识变了要重新微调）。这类问题 RAG 是正解，因为 RAG 的知识可更新、可溯源。微调擅长的是「能力」和「风格」，不是「事实」。
消除幻觉。微调能降低幻觉率，但不能消除。模型还是会编造，只是编得少一点。如果你的核心问题是幻觉，微调不是答案，约束加 RAG 加溯源才是。
通用能力提升。微调通常是在某个具体方向上强化模型，但可能以牺牲其他方向的能力为代价（灾难性遗忘）。想全面提升模型能力，那是基础模型迭代的事，不是微调能干的。
什么时候该考虑微调
判断要不要微调，走完这几步。
确认 prompt 工程和 RAG 都已经充分试过。很多时候你以为「它们解决不了」的问题，其实是没调到位。换个 prompt 结构、加几个 few-shot 示例、优化 RAG 的检索质量，问题可能就解决了。只有在充分尝试后确实不够，才考虑微调。
确认你有足够的数据。微调需要一批高质量的训练数据，几百到几千条。数据的质量比数量重要，标注不准的数据微调出来比不用还差。如果你凑不齐高质量数据，微调无从谈起。
确认收益值得成本。微调的投入包括，数据准备的人力、训练的算力成本、维护和迭代的长期成本、模型版本管理的复杂度。收益要明显超过这些成本才值得做。如果微调只比 RAG 好一点点，不值当。
确认这是个反复出现的长期需求。一次性任务不值得微调。只有某个定制需求会反复出现、长期存在，微调的投入才摊得平。
微调什么，怎么评估
决定微调了，要想清楚微调的目标和评估标准。
微调什么要具体。不是「让模型更好」，而是「让模型在 X 任务上的 Y 指标提升 Z」。越具体越好评估。比如「让模型在客服问答场景下，回答格式符合规范率从 70% 提升到 95%」。
评估要用微调前后的对比。准备一个测试集，在微调前的模型上跑一遍，记录各项指标。微调后再跑一遍，对比。只有微调后在目标指标上明显提升，且在其他指标上没有显著退化，微调才算成功。
警惕灾难性遗忘。微调在强化目标能力的同时，可能让模型在其他能力上退化。比如微调让客服问答更好了，但模型的通用推理能力变差了。评估不能只看目标指标，还要在通用能力测试集上跑，确认没有显著退化。
评估要在线上验证，不只看离线指标。离线测试集上的提升，不一定等于线上体验的提升。微调后的模型要灰度上线，看真实的用户反馈和业务指标，确认改进是真的。
微调不是一次性的。基础模型升级了（GPT-4 升到 GPT-5），你的微调可能要重做。业务需求变了，微调的目标可能要调整。数据积累了新的样本，可能要重新训练。把微调当成一个需要持续投入维护的能力，而不是做完就一劳永逸的项目。如果团队没有长期维护微调模型的能力和意愿，慎入。
一个决策清单
图：微调决策流程——逐关卡校验（Prompt→RAG→数据→收益→长期性→维护力），任一不满足即退回更轻的手段。
把上面浓缩成一个决策清单。出现以下情况，可以考虑微调。
prompt 工程和 RAG 都充分试过，确实解决不了。有足够的高质量训练数据。收益明显超过成本。需求是长期的、反复出现的。有团队和能力长期维护微调模型。
这五条都满足，微调值得投入。任何一条不满足，先回到 prompt 或者 RAG 继续优化，或者换个思路。
微调是 LLM 定制工具箱里最重的那把锤子。它确实强大，但不是每个问题都是钉子。大多数问题，用更轻的工具就能解决，而且解决得更快、更省、更灵活。把微调留给那些真正需要它的场景，这才是工程上的成熟判断。
