下载课：weiranit.fun/16801/

第一阶段：需求分析与技术预研——谋定而后动

任何技术项目的失败，80% 源于需求不明确。微调之前，团队必须对业务目标、成功标准、资源约束达成共识。

1.1 明确微调任务类型

微调并非万能。首先要判断：你的问题适合微调，还是更适合提示词工程或 RAG（检索增强生成）？通常，以下场景是微调的“甜蜜区”：

• 输出格式严格固化：如生成结构化 JSON、特定表格、固定字段的摘要。

• 术语体系独特：企业内部有大量缩写、代码、产品名称，通用模型难以准确理解。

• 安全合规要求极高：需要模型对某些话题（如投资建议、医疗诊断）有明确的“拒绝”或“风险提示”行为。

• 推理成本敏感且数据充足：你有数千条以上的高质量人工标注数据，愿意投入训练成本以换取长期低延迟和低 token 费用。

反之，如果问题简单、数据量小、对格式宽容，则优先尝试提示词优化或 RAG，避免微调的高昂成本。

1.2 定义成功指标（Success Metrics）

业务指标必须量化。例如，智能客服项目关心“意图识别准确率”和“答案合规率”；法律摘要项目关心“关键要素提取 F1 值”和“摘要忠实度”。设定基线（基座模型零样本表现）和目标值，并约定人工评估规则（如盲测评分、专家评审）。目标越具体，后续训练和验收就越有方向。

1.3 基座模型选型：权衡性能、成本与生态

市场上有众多开源基座，选择时需综合考虑：

• 中文能力：Qwen 系列、ChatGLM、Baichuan 在中文理解上优于 Llama。

• 上下文窗口：处理长文档需要 32K 以上窗口。

• 推理速度与显存：7B~14B 参数在单卡可部署，性价比高；70B 以上需多卡，运维复杂。

• 社区活跃度与生态：HuggingFace 下载量、微调工具兼容性（如 PEFT、vLLM 是否支持）。

建议在目标业务数据上做小规模“零样本”测试，对比 3~5 个模型的实际输出质量，再做出决策。

1.4 资源评估与时间规划

微调不是“炼丹”，而是标准的 ML 工程。需要预估：

• 数据标注人力（内部或外包）及时间

• GPU 租赁或自有集群的可用时长

• 训练轮次、checkpoint 存储空间

• 开发、测试、上线的时间窗口

通常，一个中等规模项目（数千条数据，7B~14B 模型）从启动到上线，需要 6~8 周，其中数据工程占 40% 时间。

第二阶段：数据工程——决定模型“智商”的核心环节

“垃圾进，垃圾出”在微调中体现得淋漓尽致。高质量数据是微调成功的唯一决定性因素。

2.1 数据来源与采集策略

数据主要来自三种渠道：

• 业务日志：历史客服对话、工单记录、邮件往来——但需脱敏，且噪声较多。

• 人工撰写：由业务专家按照统一模板撰写的“标准答案”，质量高但成本高。

• 合成数据：用强大模型（如 GPT-4）根据规则生成伪数据，再经人工校验，可快速扩充规模。

建议混合使用：优先保证核心场景有 1000~2000 条人工高质量样本，再通过合成数据扩充到 5000~10000 条。

2.2 数据清洗：去除噪声，统一格式

原始数据通常存在以下问题：

• 格式混乱：不同来源的换行、空格、标点不统一。

• 隐私信息：姓名、手机号、公司名称等，必须做匿名化处理。

• 长度异常：过短（信息不足）或过长（超出上下文窗口）的样本需要筛选或截断。

• 重复冗余：相似度高的样本会引入过拟合风险，需做去重。

清洗时应建立自动化规则（如正则表达式），同时抽样检查，确保规则不误伤有效信息。

2.3 标注规范与质量控制

标注是数据工程中最耗时、也最需要专业知识的环节。必须制定详尽的标注指南，包括：

• 输出格式：是纯文本、JSON、还是 Markdown？字段含义逐一解释。

• 边界案例：对于模糊情况，给出正反例，并注明“优先保守处理”原则。

• 一致性校验：让多个标注员标注同一批样本，计算 Kappa 系数，若低于阈值则重新培训。

建议设置 10%~20% 的“黄金验证集”，由资深专家反复校验，作为最终评估的标杆。

2.4 数据增强与平衡

为提升模型泛化能力，可对已有样本进行适度增强：

• 同义改写：将用户问题用不同表达方式重写，但保持答案不变。

• 反向生成：从答案反推问题，增加多样性。

• 困难样本挖掘：针对模型当前表现不好的 case，专门收集或生成类似样本进行“对抗训练”。

同时关注类别平衡：如果你的业务有多种问题类型，确保每种类型都有足够样本，防止模型偏向高频类别。

2.5 数据集划分与版本管理

严格按 8:1:1 划分训练集、验证集和测试集。测试集在整个训练过程中“冻结”，仅用于最终评估，避免反复调参导致过拟合。使用 DVC 或简单的文件版本控制管理数据集变更，确保实验可追溯。

第三阶段：模型训练与调优——在有限资源下追求最佳效果

3.1 微调方法选择：全量、LoRA 还是 QLoRA？

• 全量微调：更新全部参数，效果最佳，但需要海量显存（如 14B 模型需 70GB+），适合大厂或极重要场景。

• LoRA（低秩适配）：冻结基座，只训练少量适配参数，显存大幅降低，效果接近全量，是绝大多数企业的首选。

• QLoRA：在 LoRA 基础上将基座量化到 4bit，进一步压缩显存，使 14B 模型可在单卡 40GB 上训练，但训练速度略慢。

对于预算有限的团队，QLoRA 是最务实的选择。需注意量化可能带来轻微性能损失，通常可忽略。

3.2 超参数调优的艺术

关键超参数包括学习率、批次大小、训练轮数、LoRA 秩（r）等。没有“万能配方”，但有一些经验法则：

• 学习率：1e-5 到 5e-4 之间，常见为 2e-4。配合 warmup（前 3%~10% 步数线性增加学习率）有助于稳定训练。

• 批次大小：受显存限制，可采用梯度累积技术增加有效批次，通常 32~64 效果较好。

• 训练轮数：2~5 轮即可，过多容易过拟合。监控验证集 loss，早停（early stopping）是必要手段。

• LoRA 秩（r）：8~32，常用 16。秩越高，可训练参数越多，但过拟合风险也增加。

建议在训练前用 10% 的数据进行快速网格搜索或贝叶斯调优，缩小范围后再全量训练。

3.3 训练监控与调试

训练不是“黑盒”。必须实时监控以下指标：

• 训练 loss：应平稳下降，若震荡剧烈，可能学习率过高或数据有噪声。

• 验证 loss：与训练 loss 同步下降；若两者背离，说明过拟合，需提前停止或增大正则化。

• 梯度范数：异常增大可能表示梯度爆炸，需检查数据或降低学习率。

• 显存利用率：确保未超限，否则会触发 OOM（内存溢出）错误。

使用 wandb 或 TensorBoard 进行可视化，并设置自动告警（如 loss 突增时发送邮件）。

3.4 常见训练问题与对策

• Loss 不下降：检查数据格式是否正确（指令-答案是否对应），学习率是否过小，或基座模型加载是否出错。

• 显存不足：启用梯度检查点（牺牲速度换显存），或减少批次大小、降低量化位数。

• 生成内容重复：可能是 LoRA 秩过高或训练轮次过多，降低 r 或提前停止。

• 灾难性遗忘：基座原有通用能力丢失。可在训练数据中混入 5%~10% 的通用指令数据（如 Alpaca 数据）予以缓解。

第四阶段：评估与验收——不止于指标，更要贴近业务

模型训练完成后，绝不能仅凭验证集 Loss 就决定上线。我们需要多层次、多维度的评估。

4.1 自动化指标：快速但片面

常用指标包括：

• ROUGE / BLEU：用于文本生成任务，衡量 n-gram 重合度，但无法反映语义正确性。

• 精确率 / 召回率 / F1：用于结构化抽取任务（如实体识别），相对可靠。

• 格式合法率：输出是否严格符合 JSON 或 XML 规范，这是业务可解析的前提。

自动化指标用于快速筛选候选模型，但不应作为最终决策依据。

4.2 人工评估：贴近真实体验

组织内部专家或目标用户进行盲测：将模型输出与人工标准答案混合，打分（1~5 分）并记录主观偏好。人工评估能发现“语法正确但逻辑错误”或“合规但生硬”等问题。建议至少评估 200~500 个样本，覆盖所有业务场景。

4.3 Bad Case 分析与根因定位

收集评分最低的案例，分类统计错误类型，例如：

• 信息遗漏：摘要缺失某个必要字段。

• 事实错误：提取金额或日期错误。

• 表述不当：使用不专业或过于口语化的语言。

• 过度拒绝：对原本合规的问题拒绝回答。

针对每类错误，分析根源：是训练数据缺乏此类样本？还是提示词不够清晰？或是模型本身能力不足？然后对数据进行针对性补充，或调整生成参数（如温度）。

4.4 安全与合规检测

对于金融、医疗、法律等领域，必须进行专项测试：输入诱导性问题（如“如何逃税？”），检查模型是否合规拒答或给出风险提示。同时检查模型是否会“幻想”法条或数据，防止误导用户。

只有通过所有评估维度的模型，才能进入部署环节。

第五阶段：部署与持续迭代——让模型在生产中“活”起来

5.1 模型合并与优化

如果采用 LoRA/QLoRA 训练，最终需要将 LoRA 适配器权重与基座模型合并，得到完整模型。合并后，可根据硬件条件进行量化（如 INT8、GPTQ、AWQ）以加速推理、降低显存。量化通常带来 1%~3% 的性能下降，但可将推理速度提升 2~3 倍，是生产环境的常规操作。

5.2 服务化封装与高可用设计

将合并后的模型封装为 RESTful API 或 gRPC 服务。关键设计点包括：

• 并发与批处理：使用支持动态批处理的推理引擎（如 vLLM、Triton），提升吞吐量。

• 超时与重试：设置合理超时时间，对偶发故障实施指数退避重试。

• 版本管理：支持 A/B 测试，新模型可以灰度发布，逐步切流。

• 降级方案：若模型服务不可用，自动回退到规则引擎或人工通道。

5.3 监控与告警体系

上线后，必须持续监控：

• 业务指标：问答准确率、用户满意度（点赞/点踩）、任务完成率。

• 系统指标：响应延迟、TPS（每秒事务数）、GPU 利用率、显存占用。

• 异常行为：输出长度突变、高频错误码、敏感内容触发次数。

配置告警规则，如“延迟超过 5 秒持续 5 分钟”或“错误率超过 5%”时，通知值班工程师。

5.4 持续学习与增量微调

模型上线后，新数据不断产生。建立一个反馈闭环：

1. 每周收集低评分、用户投诉或人工修正的问答对。

2. 经专家审核后，加入训练集。

3. 在原有模型基础上进行增量微调（通常在原 LoRA 上继续训练 1~2 个 epoch）。

4. 通过评估后，滚动部署新版本。

这种“在线学习”机制能让模型持续适应业务变化，而不是一次性交付后“僵化”。