“凡事都先微调”是很多团队的误区。微调的本质是改变模型的行为与输出格式，而不是给模型“补充知识”。补知识该用 RAG，微调解决的是“模型总把某类输出写错、风格不对、格式不稳”这类问题。想清楚这一点，判断就容易了。
值得微调的三种情况
一是输出格式高度定制，比如必须输出固定的 JSON 结构、编号规则、公司话术；二是领域表达习惯，例如何种语言下都要用内部术语；三是在特定任务上希望降本，把高频、固定的任务蒸馏成一个更小的专用模型，推理更省。
不该微调的两种情况
一是数据太少——低于数百条高质量样本，微调收益有限而风险不小；二是不缺知识、缺的是“找到并给出来”，这种情况用 Prompt 或 RAG 就能解决，微调反而增加维护成本。
成本与硬件门槛
轻量微调（LoRA）对数据量和显存要求都很低，入门门槛并不高；但无论轻量与否，都需要一轮可靠的评测闭环：微调前后在同一组用例上打分，否则你根本不知道改得好不好。这也是多数企业微调项目失败的主因——只训不评。
一句话：补知识用 RAG，改行为才微调；训了不评等于白训。不确定该走哪条路，用诊断工具判断更稳妥。