先判断是否真的需要微调
知识缺失应该用检索补，格式与风格不稳定才考虑微调。很多项目上微调，是因为检索没做好或提示写得含糊，结果训练完发现知识仍然不准，只是语气变了。立项前先用检索加提示跑一版基线，能省下大量无效投入。
数据质量决定上限
微调需要的是成对的输入与期望输出，且标注口径要一致。同一类问题出现三种写法，模型学到的就是摇摆不定的风格；数据量不必很大，但分布要覆盖真实场景，标注规范要写清楚什么算对、什么算错。
训练方式按目标选
全参训练成本高、周期长，适合数据充足且效果要求高的场景；参数高效方法成本低、迭代快，多数企业场景够用。选择时应结合显存、数据规模与迭代频率，而不是只看公开榜单上的效果对比，那些条件通常与自身环境差别很大。
评测要比基线而非只看分数
训练前后用同一批样本对比，并加入人工盲评，重点看错误类型是否减少。只看自动指标容易得出乐观结论，尤其在格式类任务上；盲评能发现「看起来更顺但事实错误」的问题，这类问题上线后代价最高。
私有化部署包含运维
私有化不只是把模型放进机房，还包括推理服务、显存规划、版本升级与监控告警。缺少运维方案时，模型上线后一旦出现性能下降或服务中断，恢复时间会很长，业务方也会对整套方案失去信心；也影响后续迭代节奏。
适用与不适用
适合谁
- 数据敏感、不能调用外部模型的场景
- 输出格式与术语要求稳定、可接受标注投入的业务
- 已有一定样本积累、能组织标注人力的企业
不适合谁
- 知识缺失为主、检索尚未做好的项目
- 样本极少、又无法补充标注样本的团队
典型场景
某医疗信息化企业希望模型按固定格式输出结构化报告。团队先做检索加提示的基线，发现格式仍不稳定，遂转入微调。用三个月的历史报告做样本，标注规范写清字段边界，先小样本验证再全量训练，最终在私有化环境上线，推理服务与监控一并交付。
可执行步骤
- 先用检索加提示跑基线，确认问题是否真在模型侧，避免无效训练与投入浪费
- 整理成对的输入与期望输出，写清标注规范与判定口径，并做一致性校准，避免各写各的
- 按数据规模与迭代频率选择训练方式，先做小样本验证，再决定是否全量
- 用同一批样本做前后对比，并加入人工盲评看错误类型，而不只看自动分数
- 私有化上线时一并交付推理服务、容量说明与监控告警，并约定升级方式
常见坑
- 用微调去补知识，训练完知识仍然不准，只是语气变了，几周时间与算力全白费，投入产出完全不成比例。
- 标注口径不统一，同类问题三种写法，模型学出摇摆风格，上线后输出质量时好时坏，排查困难且整改成本更高。
- 只看自动指标不看盲评，格式对了但事实错误增加，上线后后果由业务方承担，返工与解释成本都很高。
- 私有化只交付模型权重，没有推理服务与监控，出故障时恢复时间不可控，业务连续性也随之受影响。
自检与验收清单
- 是否已用检索加提示跑过基线，是否有对比结论
- 样本是否成对且标注口径统一，是否有争议处理规则
- 训练方式是否与数据规模匹配，是否与显存匹配
- 评测是否含人工盲评与错误类型对比，是否覆盖典型任务
- 私有化是否含推理服务与监控方案，是否包含告警
常见问题
微调能替代知识库吗？
不能。微调改变的是表达方式与输出习惯，知识仍来自训练数据，无法随政策更新而自动变化。需要频繁更新的知识应放在检索侧，微调只负责让输出更符合业务格式与术语习惯。
样本要多少才够？
取决于任务复杂度与格式要求，格式类任务通常几百到几千条即可见效，复杂推理类需要更多。与其纠结数量，不如先把分布覆盖到真实场景与典型例外，再用小样本验证效果是否随数据增加而改善。
私有化一定要买显卡吗？
不一定。可以先用云上专有实例或托管私有化方案验证，再决定是否采购硬件。关键是先算清推理并发与响应时间要求，再倒推显存与卡数，否则容易买多闲置或买少不够，两种情况都会影响项目推进。