很多团队拿到一批业务文档，第一反应是选基座、开训练、盯着 loss 曲线。训练结束后才发现，模型会复述样本，却不能稳定完成真实任务；或者离线回答正常，一换推理框架就出现格式漂移。
问题通常早于训练发生：任务边界没写清，数据口径不一致，评估集又和训练集混在一起。
微调（Fine-tuning）的作用，是把预训练模型已有的语言能力迁移到特定任务。开工前可以先判断三件事：如果只是补充频繁变化的知识，优先评估检索方案；如果要固定回答格式、业务术语和处理流程，SFT 更合适；如果输出能被规则或程序明确打分，再考虑 GRPO。
先把任务写成可检查的样子
ForceInjection 的 SFT 工程手册以金融领域的「企业年报分析助手」为贯穿案例，覆盖数据构建、基座选型、LoRA/QLoRA 配置、评估和部署。这个顺序很实用，因为年报助手的目标不能只写成「看懂年报」，而要拆成可验收的任务：提取风险因素、定位原文依据、按指定格式输出，或者在证据不足时拒绝作答。
常见训练数据可以整理成 JSONL，每条样本包含 instruction、可选的 input 和预期 output：
{"instruction":"提取年报片段中的主要风险，并标注依据","input":"<年报原文片段>","output":"<经过校验的结构化答案>"}
这里有几个容易被忽略的细节：
- 保留原始文件、样本 ID 和出处，方便追查错误答案；
- 同类指令使用一致的字段、术语和回答边界；
- 训练集、验证集和测试集先切分，再做扩写，避免相似样本泄漏；
- 高阶模型生成的
output只能作为初稿，关键样本仍需人工校验； - 加入纠错、拒答和边界样本，避免模型只会处理理想输入。
数据量增加并不能自动带来更好的结果。几条互相冲突的高频样本，足以让模型在关键问题上反复摇摆。
基座先跑基线，再决定参数怎么动
Llama 3.2、Qwen 2.5、DeepSeek V3 都可以进入候选列表，但参数量只是选型条件之一。还要检查许可证、上下文长度、分词器、训练框架支持情况，以及目标硬件能否稳定推理。最稳妥的做法，是让候选模型先在同一套业务测试集上跑基线，再决定训练哪一个。
资源有限时，LoRA 通常适合作为第一轮方案。它冻结基座模型的大部分参数，只训练插入权重矩阵的低秩模块。QLoRA 则在量化后的基座上训练 LoRA，常见配置会使用 4 位量化，以进一步降低显存占用。Adapter 和 Prefix Tuning 也可用于参数高效微调，选择取决于框架支持和任务要求。
需要分清三个概念：SFT 决定模型学习什么，LoRA/QLoRA 决定训练时更新哪些参数，GRPO 则用奖励信号继续调整输出策略。它们可以组合使用，并非互相替代。
LoRA 试跑时，可以在 5e-5 到 1e-4 之间做小范围学习率搜索，并配合 Warmup。这个区间只能当起点，序列长度、batch size、数据规模和基座都会影响结果。学习率过高可能破坏模型原有能力；显存不足时，还要一起调整梯度累积、梯度检查点和输入长度。
SFT 稳定后，再决定要不要上 GRPO
SFT 先让模型模仿合格答案，适合学习格式、术语、问答方式和基础技能。百度 AI Studio 的 SFT 科普提到，可先通过 SFT 学习基础能力，再用 RFT 或 PPO 优化策略。采用 GRPO 时也应遵循这个顺序：先得到可用的 SFT 模型，再进入奖励优化。
GRPO 会让模型针对同一个问题生成多条答案，再根据组内相对奖励更新策略。它不需要单独训练价值模型，因此能省去一部分训练开销。数学推理和代码生成较适合这类方法，因为答案往往可以通过规则、测试用例或执行结果评分。
真正难的是奖励设计。只奖励格式，模型可能输出结构漂亮但内容错误的答案；只奖励最终结果，又可能忽略推理过程和依据。奖励函数还可能被模型钻空子，所以训练期间要保留人工抽查，并使用没有参与奖励设计的独立测试集。
如果任务缺少可靠的评分标准，先把 SFT 数据和评估集做好，通常比急着加入 GRPO 更有效。
loss 降了，业务结果未必过关
训练 loss 只是优化信号，无法代替业务验收。评估至少要覆盖以下几类问题：
- 任务正确性：答案是否解决了真实业务问题；
- 格式遵循：字段、顺序、长度和输出结构是否稳定；
- 证据追踪：金融年报等任务能否定位原文依据；
- 边界处理：信息不足时是否会拒绝猜测；
- 能力回退：微调后，基座原有的通用能力是否明显受损。
基座模型、SFT 检查点和 SFT+GRPO 检查点应使用同一套测试数据。LoRA 或 QLoRA 只是参数更新方式，评估时仍要对比最终模型的实际输出，不能用训练速度或显存占用代替效果判断。
部署问题，最好在开训前暴露
云端服务可以使用 vLLM 或 TGI。采用 vLLM 时，可利用 PagedAttention 管理 KV Cache。LoRA 适配器既可以在部署前合并，也可以按任务动态加载；具体选择要看并发量、适配器数量和版本管理方式。
训练与推理环境还要逐项核对：Tokenizer、Chat Template、特殊 token 和最大输入长度必须一致。很多「训练正常、上线异常」的问题，都出在这些配置差异上。
移动端或边缘设备部署通常还要做 INT4、FP8 等量化。量化完成后应重新跑业务测试集，检查精度、时延、内存和功耗。模型能够被设备加载，只是部署的第一关。
如果目标平台是昇腾 910C 和 CANN，训练前就应验证框架版本、算子支持和推理链路。等模型训完再处理硬件适配，往往会把问题集中推到交付阶段。
真正拖慢项目的，常常是训练之外的工作
微调预算不能只计算 GPU 时间，还要把数据清洗、人工复核、合规检查、评估流水线和故障回滚算进去。金融、医疗等领域尤其要确认训练数据是否涉及隐私、版权或敏感信息。
模型上线后也需要保留版本记录：使用了哪批数据、哪个基座、哪组 LoRA 参数、哪套评估集，都应能够追溯。业务规则变化时，先更新数据和测试集，再训练新的适配器，避免直接覆盖正在运行的版本。
把任务边界、评估集和部署平台在开训前定下来，LoRA、QLoRA 或 GRPO 才有可比较的意义。否则训练过程再顺利，也可能只得到一个 loss 更好看的模型。