坑一、二：灌知识与脏数据
把制度、价格与产品参数塞进训练集，指望模型记住，结果一改版就全部过时。更常见的是标注口径不统一，同一问题在不同人手里标出相反答案。如何避免？先定标注规范，再做一次跨人的一致性抽检。
坑三：没有基线对比
不跑微调前的基线，就无法判断效果是训练带来的还是样本太简单。应固定一批评测样本，先在原模型上跑一遍记录结果，再与微调后对比；没有基线的提升，多数只是感觉上的提升，如何量化要提前想清楚。
坑四：小样本过拟合
几十条样本反复训练，模型会把案例背下来，换个问法就失效。判断方法是留出未见过的样本做测试，并观察训练损失与测试表现的差距；差距拉大时，应补数据或降低训练轮次，这个边界靠留出样本把住。
坑五：忽略许可与授权
基座模型的许可可能限制商用、再分发或输出用途；训练数据可能包含他人作品与个人信息。上线前要逐项确认，面向公众提供服务时还要按规定履行备案或登记义务，这些都不是技术问题，而是能不能上线的边界。
坑六：不做评测就上线
只看几个例子觉得不错就上线，是微调项目最常见的收尾方式。应同时跑目标任务、通用能力与安全测试，并保留回滚方案；没有回滚，一旦线上退化只能停服，代价远高于多做一轮评测，如何取舍一目了然。
适用与不适用
适合谁
- 准备做微调、需要一份自查清单的团队
- 已经训练过一版但效果不稳定的项目
- 需要向管理层说明风险与边界的负责人
不适合谁
- 知识频繁变化、应优先做检索的场景
- 没有评测集、也没有标注人力的团队
典型场景
某企业的微调项目训练后准确率看似提升，上线一周却被投诉答非所问。复盘发现训练样本只覆盖一种问法，且没有跑基线。团队补了基线对比与留出测试集，把事实类问题改由检索提供，微调只负责输出格式，问题才稳定下来。
可执行步骤
- 先确认需求究竟属于改格式还是补知识，属于补知识的应当优先走检索
- 先写清标注规范，再组织跨人的一致性抽检，不合格的样本直接剔除
- 固定一批评测样本，先在原模型上跑出基线，并完整记录每一项结果
- 留出一批没有见过的样本做测试，观察训练表现与测试表现之间的差距
- 在上线之前逐项确认基座模型的许可、数据授权与生成内容标识要求
常见坑
- 把制度与参数当成训练语料，指望模型自己记住，结果一改版就要重训，团队被版本拖着走。
- 标注口径没有统一就开训，模型学到互相矛盾的答案，表现可能比原模型还差，且难以修复。
- 不跑基线就直接凭感觉对比，很容易把样本变简单误认为模型变强，方向从一开始就错了。
- 忽略基座许可与数据授权，等到对外提供服务时才发现存在使用限制，只能临时下线调整方案。
自检与验收清单
- 需求属于改格式还是补知识，这一点是否已经分清
- 标注规范与跨人的一致性抽检是否都已经执行
- 是否在原模型上跑过完整基线，结果是否留档
- 是否留出一批未见过的样本做留出测试与对比
- 基座许可、数据授权与生成标识要求是否都已确认
常见问题
微调一定要自己标注数据吗？
通常需要。企业特有的术语、格式与判定口径只能自己标，公开数据帮不上。外包标注也要给规范与抽检比例，否则口径不统一，最后还是要自己重标一遍，成本反而更高，进度也被拖慢。
效果不好一定要加数据吗？
不一定。先看是标注问题、评测集问题还是任务本身不适合微调。很多所谓效果不好，其实是评测样本太简单或太偏，模型在真实问法上表现差异很大，加数据只是掩盖问题。
微调后的模型怎么维护？
把样本、配置与评测结果一并留档，每次更新保留可回滚的上一版。上线后按月抽新样本复测，发现退化就回退，别等到业务投诉才处理，那时再想补救已经很被动，代价也更大。