关于微调的时机
微调不是大模型效果优化的默认选项，更不是遇到效果问题后的第一反应。真正成熟的工程判断，是先弄清楚：当前缺的是知识，还是模型的行为稳定性？
“什么时候应该做大模型微调？”是大模型岗位面试中很常见的一道题。
它表面上在问微调技术，实际上考察的是两个更重要的能力：
- 能不能区分知识问题和行为问题；
- 有没有技术选型的成本意识。
如果连问题类型都没有判断清楚，就直接把微调提上日程，往往会把一个本可低成本解决的问题，变成数据准备、模型训练和持续维护的复杂工程。
因此，讨论“要不要微调”之前，先记住一个结论：
知识问题优先用检索解决，行为问题才进入微调的候选范围。
先判断：缺知识，还是行为不稳定？
大模型应用中的效果问题，可以先沿着“知识”和“行为”两条线拆开。
| 问题类型 | 典型表现 | 对应解法 |
|---|---|---|
| 知识问题 | 模型缺少业务文档、规章制度、行业事实等外部信息 | 使用检索增强（RAG），在生成时补充所需知识 |
| 行为问题 | 模型知道正确内容，但输出格式、语气或判断规则不稳定 | 提示词无法稳定解决后，再考虑微调 |
知识问题：模型不知道事实
如果模型答不出某个问题，是因为它没有接触过企业内部文档、最新规章制度或特定行业事实，那么问题的核心不是“模型不会回答”，而是模型缺少回答所需的外部信息。
这类问题应该优先使用检索增强。知识保留在外部知识源中，需要时检索并提供给模型，而不是把它固化进模型权重。
这样做的关键价值是：知识可以灵活更新。文档变化时更新知识源即可，不必重新训练模型。
行为问题：模型知道，但做得不稳定
另一类问题是：正确内容模型其实知道，但它无法持续按照业务要求输出。例如：
- 输出结构有时正确、有时缺字段；
- 语气无法长期保持一致；
- 面对复杂判断规则时，执行结果反复波动。
这不是知识缺失，而是行为不稳定。微调真正擅长处理的，正是这类“让模型更稳定地按照指定方式做事”的问题。
所以，区分两者最直接的判断方式是：
缺事实，补检索；事实已经具备但表现不稳定，才评估微调。
效果优化要走阶梯，而不是一步跳到微调
工业界做技术选型，不能只问“哪种方案能解决”，还要问“是否有成本更低的方案能先解决”。大模型效果优化应该按照从低成本到高成本的顺序逐级推进：
| 顺序 | 优化手段 | 进入条件 |
|---|---|---|
| 第一步 | 把提示词优化到极致 | 所有场景都应先完成 |
| 第二步 | 引入检索增强方案 | 问题涉及外部知识，或提示词缺少必要事实 |
| 第三步 | 考虑使用微调 | 前两步走不通，且问题确实适合微调 |
这套阶梯的关键不是三种技术谁更高级，而是上一级没有解决问题，再进入下一级。
第一步：先把提示词优化到极致
面对格式、语气和规则执行问题，第一步不是训练，而是先验证提示词能否解决。只要提示词仍有优化空间，就不能轻易得出“必须微调”的结论。
第二步：需要外部知识时引入检索
如果问题来自知识缺失，就通过检索把业务文档、规章制度或行业事实提供给模型。检索负责补齐事实，也保留了知识更新的灵活性。
第三步：最后才考虑微调
只有提示词已经反复优化、检索也已经覆盖所需事实，问题依然存在时，微调才真正进入决策范围。
微调应该是阶梯的第三层，而不是项目启动后的默认配置。
真正需要微调的三个信号
“微调不是起点”不等于“永远不做微调”。当下面三个信号出现时，微调就可能具备明确的工程价值。
信号一：行为与格式仍然不稳定
业务要求模型稳定输出特定结构、固定语气或复杂规则，但提示词经过反复优化后，效果仍然时好时坏。
这里有两个必要前提：
- 目标是约束模型的行为与输出形态；
- 提示词优化已经充分尝试，但稳定性仍未达标。
两个条件同时成立，才说明问题可能需要通过微调进一步固化。
信号二：高频窄口径任务受到成本与延迟制约
意图分类、实体抽取、内容打标这类任务，通常口径明确、调用频率高。为了让模型准确执行规则，系统可能需要在每一次请求中重复携带很长的提示词。
长提示词会带来持续的重复开销，也会增加延迟。此时，把任务行为通过微调迁移到小模型中，能够大幅降低成本和延迟。
这里决定是否微调的，不只是效果，还有调用规模下的长期成本。
信号三：距离业务硬指标只差最后几个点
提示词已经做到位，检索也已经补齐事实，但准确率距离业务硬指标仍然差最后几个点。这说明低成本手段已经基本用尽，而剩余差距又会直接影响业务上线或验收。
此时，微调才适合作为继续突破能力边界的手段。
三个信号可以浓缩成一张判断表：
| 信号 | 关键问题 | 微调价值 |
|---|---|---|
| 行为与格式 | 提示词反复优化后，输出仍不稳定吗？ | 固化结构、语气和复杂规则 |
| 成本与延迟 | 高频窄任务是否长期重复携带长提示词？ | 用小模型降低持续成本与延迟 |
| 能力边界 | 提示词和检索都到位后，是否仍差硬指标最后几个点？ | 进一步提升专项准确率 |
微调最常见的四个坑
真正的工程风险往往不在“会不会训练”，而在于微调目标、数据和评估是否正确。下面四个问题尤其常见。
坑一：用微调灌知识
把业务文档或行业知识直接拿去微调，看起来像是在“教会模型”，实际很容易让知识变成模型中的模糊印象，反而更容易胡说。
更麻烦的是，知识会持续变化。一旦知识固化进模型权重，每次更新都可能重新触发数据准备和训练，维护成本极高。
因此，这条边界要足够明确：
知识类需求永远优先走检索，不要用微调灌知识。
坑二：重数量，轻质量
微调数据不是越多越好。几百条高质量、统一口径的样本，效果可能好过几万条脏数据。
数据中的口径冲突和错误示范，会直接让模型学到不稳定的行为。与其盲目追求数量，不如先确保样本准确、清晰且规则一致。
对于简单任务，50～100 条样本就能看到明显效果。这意味着，微调项目早期更应该关注样本质量，而不是先堆出庞大的数据规模。
坑三：忽视灾难性遗忘
模型在窄任务上被过度微调后，可能出现通用能力退化。专项任务的指标变好，并不代表整体效果一定更好。
因此，微调后的评估不能只盯着目标任务，必须同时检查：
- 专项能力是否提升；
- 通用能力是否退化。
只有两者一起评估，才能判断这次微调是否真的值得上线。
坑四：没有评估就开始微调
没有评估体系就直接训练，相当于闭着眼睛开车：训练完成后，既无法确认效果提升了多少，也无法判断出现了哪些退化。
正确的顺序应该是：评估集先于训练搭建。
先明确用什么样本和标准验证效果，再开始准备微调。否则，训练过程即使顺利完成，也无法形成可信的工程结论。
一套可落地的决策顺序
面对“当前场景是否需要微调”，可以按下面的顺序做判断：
| 决策步骤 | 要回答的问题 | 对应动作 |
|---|---|---|
| 1. 定义问题 | 缺的是外部知识，还是行为稳定性？ | 知识问题走检索；行为问题继续判断 |
| 2. 优化提示词 | 提示词是否已经反复优化到位？ | 没有则继续优化，不急于微调 |
| 3. 补齐知识 | 是否缺少业务文档、制度或行业事实？ | 引入 RAG，不把知识写进权重 |
| 4. 检查信号 | 是否出现行为不稳、成本延迟或能力边界信号？ | 信号明确后再立项微调 |
| 5. 搭建评估 | 是否已有专项与通用能力评估？ | 评估集就绪后才开始训练 |
| 6. 准备数据 | 样本是否高质量且口径统一？ | 先保证质量，再考虑数量 |
这套顺序体现的不是对微调的保守，而是对工程成本和方案边界的尊重。
面试时应该怎样回答？
如果面试官问“什么时候做微调”，一个逻辑完整的回答可以这样组织：
我会先判断这是知识问题还是行为问题。模型缺少业务文档、规章制度或行业事实时，优先使用 RAG，因为知识需要灵活更新，不应该固化进模型权重。模型已经知道正确内容，但格式、语气或判断规则在提示词反复优化后仍不稳定，才是微调的适用场景。
在方案顺序上，我会先把提示词优化到极致，再引入检索增强，前两步走不通后才考虑微调。真正推动微调立项的信号主要有三个：行为和格式仍然不稳定；高频窄口径任务受长提示词的成本与延迟影响；提示词和检索都到位后，准确率距离业务硬指标仍差最后几个点。
开始训练前，我会先搭建评估集，并保证训练样本高质量、口径统一。评估时同时关注专项能力和通用能力，避免窄任务过度微调导致灾难性遗忘。
这个回答覆盖了问题分类、方案优先级、成本判断和上线风险，也更接近真实工业场景中的技术决策方式。
总结
大模型项目中，微调最容易被误用的原因，是团队把所有效果问题都归结为“模型能力不够”。但真正需要先回答的是：模型缺的是事实，还是稳定执行规则的行为？
整套决策可以压缩为三句话：
- 知识问题优先用 RAG，行为问题才考虑微调；
- 先提示词，再检索，最后才是微调；
- 没有明确微调信号、评估集和高质量数据，就不要启动训练。
成熟的工业界方案，往往是：
微调管形态，检索管事实。
但要特别注意：这是一套经过逐级验证后形成的终局组合方案，不是项目一开始就要全部开启的技术清单。
真正专业的选型，不是把所有技术都用上，而是在正确的问题上使用正确的手段。