桌上摊着一张标注表，只有几百条对话，格式还算整齐。有人问：是不是该马上做模型微调？这个问题在项目里出现得越来越早，早到数据还没看清，评估口径也没定。我的判断是，先别把微调当作默认动作，它更像一次有成本的改写。
先看要改的是哪一类行为
大模型已经能回答不少通用问题，但在具体业务里，常见缺口无非几类：说话方式不合场景，输出格式不稳定，对内部术语不敏感，或者需要按固定流程处理输入。前三类往往能靠提示词、检索或后处理缓解；最后一类如果流程清楚、样本足够，才进入模型微调的范围。把问题写成可观察的行为，比笼统地说“让模型更懂业务”有用。比如要求每次输出三行字段、遇到缺失信息先追问，这些都能在样本里被标注，也便于评估。
数据不是越多越省心
小样本容易让人焦虑，于是拼命补数据。但模型微调关心的不只是条数，还有覆盖面和一致性。几百条样本如果都来自同一类问法，模型可能学会表面句式，换个说法就失效。反过来，少量但边界清晰的样本，配上严格校验，能减少无效训练。这里有个常被忽略的动作：留出一部分样本不做训练，专门看模型在没见过的问法上是否稳住。评估集不必大，但要和训练集保持距离。
- 先确认目标行为能否被清楚描述，再决定要不要标注。
- 把格式错误、事实遗漏、语气偏差分开记录，避免一个分数掩盖不同问题。
- 保留失败样本，它们往往比顺利样本更能说明边界。
参数高效方法降低了门槛，但没有取消判断
LoRA 一类参数高效方法，让模型微调不必每次都改动全部参数，试验成本因此下降。这是好事，也容易带来另一种冲动：既然便宜，就多试几轮。可训练参数少，不等于问题变简单。学习率、数据配比、训练轮次仍会影响结果，过拟合也可能悄悄出现。更实际的做法是先把基线跑清楚：同一批输入，不微调时错在哪里，微调后哪些错消失了，哪些错换了形式。没有基线，训练曲线再平滑也说明不了太多。
边界比方法更先决定
决定模型微调是否值得做的，常常不是技术细节，而是维护成本。业务规则会变，术语会变，数据分布也会变。一次微调留下的是一个需要持续观察的模型版本，而不是一劳永逸的开关。如果目标只是临时活动话术，提示词加审核可能更轻；如果输出格式和内部流程长期稳定，微调才有持续价值。我的倾向是：能用外部约束解决的，先别急着改参数；确实需要把行为写进模型时，再从少量、可回滚的试验开始。
所以，小样本不是立刻微调的理由，也不是拒绝微调的理由。它只是提醒人把问题拆细：要改什么，拿什么验证，谁来维护。想清楚这三件事，这次调整才是一次可控的工程动作，而不是对不确定性的遮掩。