大模型垂直领域微调系列（一）：认识微调
作者：吴佳浩
撰稿时间：2026-3-9
测试版本：ms-swift v4.0.1
本系列基于 ms-swift v4.x 官方文档整理，共三篇：
第一篇（本文）：微调是什么、为什么做、什么时候该做
第二篇：ms-swift 框架全景介绍
第三篇：完整实战流程与最佳实践
目录
- 1. 大模型能力的边界
- 2. 什么是微调
- 3. 微调方法全景
- 4. 训练任务类型总览
- 5. 微调 vs 其他方案
- 6. 哪些场景需要微调
- 7. 哪些场景不需要微调
- 8. 微调成本与收益评估
- 9. 垂直领域微调行业图谱
- 10. 微调成功的三个前提
- 11. 本系列路线图
1. 大模型能力的边界
现代大语言模型（LLM）经过万亿级 token 的预训练，具备了惊人的通识能力——能写代码、会翻译、能分析、可对话。但"通识"本身就意味着边界：广度优先，而非深度优先。
把通用大模型直接用于垂直业务，会碰到四堵墙：
1.1 专业深度不足
模型对医学、法律、金融等领域的知识停留在"见过"的层面，无法做到临床级、法庭级的专业判断。同一个词在不同领域含义天差地别：
| 词语 | 医学含义 | 金融含义 | 法律含义 |
|---|---|---|---|
| 阳性 | 检测结果为真 | 正向预期 | 无特定含义 |
| 违约 | 不遵医嘱 | 债务不履行 | 合同义务违反 |
| 杠杆 | 医疗器械 | 放大投资效应 | 无特定含义 |
| 期权 | 无特定含义 | 金融衍生品 | 合同权利选择 |
通用模型极易在专业语境中混淆这些概念，产出看起来专业、实际错误的内容。
1.2 格式规范无法稳定保证
不同行业对 AI 输出格式有严格要求，通用模型无法持续稳定遵守：
| 行业 | 格式要求 | 通用模型的问题 |
|---|---|---|
| 医疗报告 | 主诉/现病史/体格检查/诊断/治疗建议五段式 | 随机组织，缺少必要章节 |
| 法律文书 | 必须引用具体法条编号，当事人信息格式严格 | 法条引用不准确，格式随意 |
| 金融研报 | 评级/目标价/核心逻辑/风险提示/免责声明 | 缺少合规性声明，结构随问法变 |
| 保险理赔 | 事故描述/责任认定/赔偿金额/适用条款 | 结构随问法不同而变，稳定性差 |
1.3 私有知识完全空白
模型训练数据有知识截止日期，且完全不包含任何企业内部数据：
- 产品手册、内部技术文档、操作规范
- 企业历史工单、客户案例库、FAQ 积累
- 公司定价体系、业务流程、组织架构
- 内部专有术语、缩写、暗语含义
这些对企业最有价值的知识，通用模型一无所知。每次调用都要通过上下文传递，既有 token 成本，又有 context 窗口限制，且每次都要重新"教"模型。
1.4 合规与安全风险
医疗、金融、法律等受监管行业，对 AI 输出有明确合规要求。通用模型未经行业合规约束训练，可能产出：
- 不符合临床指南的医疗建议，误导患者
- 可能被认定为非法投资建议的金融分析
- 引用错误版本法条的法律意见
- 缺少必要风险提示和免责声明的内容
graph TD
A[通用大模型直接用于垂直业务]
A --> B[专业深度不足]
A --> C[格式规范不稳定]
A --> D[私有知识空白]
A --> E[合规安全风险]
B --> F[需要微调解决]
C --> F
D --> F
E --> F
2. 什么是微调
微调（Fine-tuning）是在预训练模型基础上，用特定领域数据继续训练，让模型在该领域的表现大幅提升，同时尽量保留通用能力的过程。
2.1 微调与预训练的本质区别
| 维度 | 预训练（Pre-training） | 微调（Fine-tuning） |
|---|---|---|
| 数据规模 | 万亿 token 级 | 数百到数十万条样本 |
| 计算资源 | 千卡·月级别 | 单卡·小时级别 |
| 训练目标 | 学习基础语言能力 | 适配特定任务和领域 |
| 成本量级 | 数百万到数千万美元 | 数十到数千元（含云端 GPU） |
| 可行性 | 仅头部大公司 | 中小团队可独立完成 |
| 产出物 | 基础模型（Base Model） | 专业化模型（Domain Model） |
核心理解：微调不是让模型"变聪明"，而是让模型"变专业"——把已有的语言理解和生成能力，通过有监督学习引导到特定领域和任务上。
2.2 灾难性遗忘
微调有一个不可忽视的副作用：灾难性遗忘（Catastrophic Forgetting）。
当模型在领域数据上过度训练，会逐渐"忘掉"原有的通用能力。具体表现为：微调后的模型在领域任务上表现优秀，但原来能做好的翻译、代码、通用问答等任务性能下降。
有效的应对策略：
策略一：数据混合（最有效） 在领域数据中混入 10%~20% 的通用数据。ms-swift 支持直接在 --dataset 参数中混合：
--dataset 'domain_data.jsonl' \
'AI-ModelScope/alpaca-gpt4-data-zh#500' \
'AI-ModelScope/alpaca-gpt4-data-en#200'
策略二：使用参数高效微调（PEFT） LoRA 等方法只更新少量参数，对原始权重干预小，遗忘程度轻。
策略三：控制训练轮数 以验证集 Loss 最低点为停止标准，不过度拟合。
策略四：降低学习率 使用更保守的学习率（如 5e-5）减少对原始权重的冲击。
3. 微调方法全景
3.1 全量微调（Full Fine-tuning）
更新模型的全部参数，效果上限最高。
- 优点：效果上限最高，对领域的适配最彻底
- 缺点：显存需求极高（7B 模型至少需要 60GB 显存），每个任务需保存完整模型副本
- 适用：资源充足、追求极致效果、数据量充足（10万+条）
3.2 LoRA（Low-Rank Adaptation）
当前最主流的参数高效微调方法。核心思想：假设权重更新矩阵是低秩的，用两个小矩阵的乘积来近似。
原始全量更新: W = W0 + DeltaW (DeltaW 是 d x d 大矩阵)
LoRA 近似: W = W0 + B * A (B 是 d x r，A 是 r x d，r << d)
实际参数更新量从数十亿降低到数百万，显存节省 80% 以上，效果接近全量微调。
关键超参数：
| 参数 | 含义 | 推荐值 | 调整方向 |
|---|---|---|---|
--lora_rank | 矩阵的秩，越大表达能力越强 | 8~16 | 效果差则增大，OOM 则减小 |
--lora_alpha | 缩放因子，影响学习强度 | rank 的 2 倍 | 一般固定为 rank x2 |
--target_modules | 应用 LoRA 的模块 | all-linear | 默认覆盖所有线性层 |
3.3 QLoRA（Quantized LoRA）
在 LoRA 基础上，将基础模型权重量化为 4-bit，进一步压缩显存。
- 7B 模型 QLoRA 训练只需 9GB 显存
- 量化使用 bitsandbytes（BNB）实现
- 效果略低于标准 LoRA，但资源门槛大幅降低
# QLoRA 关键参数
--tuner_type lora \
--quant_bits 4 \
--quant_method bnb
3.4 其他 PEFT 方法
ms-swift 支持以下所有轻量微调方式：
| 方法 | 核心思想 | 显存 | 特点 |
|---|---|---|---|
| DoRA | 将权重分解为幅度+方向分别训练 | 中等 | 比 LoRA 更稳定，效果略好 |
| LoRA+ | A/B 矩阵使用不同学习率 | 同 LoRA | 收敛更快 |
| LLaMA-Pro | 扩展新的 Transformer 层 | 较大 | 保留原有能力强 |
| Adapter | 在 Transformer 层插入小型适配模块 | 极低 | 可热插拔，多任务切换友好 |
| LISA | 动态选择部分层进行训练 | 极低 | 适合超低资源环境 |
| ReFT | 在表示空间进行微调 | 极低 | 参数极少，有竞争力 |
| GaLore | 梯度低秩投影，节省优化器状态 | 低 | 全参训练的显存优化 |
| UnSloth | 自定义 CUDA kernel 加速 | 低 | 训练速度提升 2x+ |
| Liger-Kernel | 融合算子降低显存 | 低 | 工程优化，对效果无影响 |
3.5 偏好对齐（RLHF）
监督微调（SFT）让模型学会"怎么做"，偏好对齐让模型学会"怎么做得更好"——从人类偏好数据中学习哪种输出更符合期望。
graph LR
SFT[SFT 监督微调] --> DPO[DPO 直接偏好优化]
SFT --> PPO[PPO 近端策略优化]
SFT --> GRPO[GRPO 组相对策略优化]
DPO --> ALIGN[对齐后的模型]
PPO --> ALIGN
GRPO --> ALIGN
主流偏好对齐算法对比：
| 算法 | 数据需求 | 是否需要奖励模型 | 适用场景 |
|---|---|---|---|
| DPO | chosen/rejected 对 | 否 | 通用对齐，最常用 |
| KTO | 单条好/坏标签 | 否 | 数据获取容易，无需配对 |
| CPO | chosen/rejected 对 | 否 | DPO 的改进版 |
| SimPO | chosen/rejected 对 | 否 | 不依赖参考模型 |
| ORPO | chosen/rejected 对 | 否 | SFT+DPO 一步完成 |
| RM | chosen/rejected 对 | 是（就是在训练它） | 作为 PPO 的奖励模型 |
| PPO | prompt 列表 | 是 | 复杂对齐任务 |
| GRPO | prompt + 可验证答案 | 可自定义函数 | 数学推理等可验证任务 |
3.6 强化微调（GRPO）
GRPO（Group Relative Policy Optimization）是 DeepSeek-R1 使用的强化学习方法，不需要单独训练奖励模型，通过组内相对比较来更新策略。
特别适合：
- 数学推理（答案对错可验证）
- 代码生成（能否运行可验证）
- 格式遵从（格式正确与否可规则判断）
- 逻辑推理（多步推理任务）
ms-swift 内置了 GRPO 系列的丰富算法变体：GRPO、DAPO、GSPO、SAPO、CISPO、CHORD、RLOO、Reinforce++ 等。
4. 训练任务类型总览
除了常规的指令微调（SFT），ms-swift 支持极为丰富的训练任务类型，覆盖大模型训练的完整场景：
graph TD
TASK[ms-swift 支持的训练任务]
TASK --> CPT[持续预训练 CPT]
TASK --> SFT[指令微调 SFT]
TASK --> RLHF[偏好学习 RLHF]
TASK --> RL[强化学习 RL]
TASK --> EMBED[向量任务]
TASK --> CLS[分类任务]
SFT --> S1[纯文本对话]
SFT --> S2[多模态指令]
SFT --> S3[Agent 工具调用]
RLHF --> H1[DPO/KTO/CPO/SimPO/ORPO]
RLHF --> H2[RM 奖励模型训练]
RLHF --> H3[PPO]
RL --> R1[GRPO/DAPO/GSPO]
RL --> R2[RLOO/Reinforce++]
EMBED --> E1[Embedding 训练]
EMBED --> E2[Reranker 训练]
CLS --> C1[序列分类]
各训练任务适用场景：
| 任务类型 | 适用场景 | 数据格式 |
|---|---|---|
| CPT（持续预训练） | 注入大量领域知识，适合知识密集型场景 | 纯文本语料 |
| SFT（指令微调） | 最常用，学习回答格式和领域能力 | 问答对、对话记录 |
| DPO 等偏好学习 | 提升输出质量，减少有害输出 | 好回答/坏回答配对 |
| GRPO 强化学习 | 可验证任务（数学、代码、格式） | 问题 + 正确答案 |
| Embedding 训练 | 构建专属领域检索模型 | 文本对（相似/不相似） |
| Reranker 训练 | 提升 RAG 检索精度 | 查询-文档-相关性标注 |
| 序列分类 | 文本分类、意图识别、情感分析 | 文本 + 标签 |
5. 微调 vs 其他方案
在决定微调之前，必须先考虑其他更轻量的技术方案。
5.1 三种主要方案
graph TD
START["面临业务需求"]
START --> Q1{"Prompt 工程能解决吗?"}
Q1 -->|"能，效果达标"| P["用 Prompt 工程"]
Q1 -->|"不能"| Q2{"主要问题是什么?"}
Q2 -->|"知识缺失且需实时更新"| R["用 RAG"]
Q2 -->|"行为风格格式不对"| F["用微调"]
Q2 -->|"两者都有"| C["微调 + RAG 组合"]
提示词工程（Prompt Engineering）
通过精心设计 system prompt 和 few-shot 示例引导模型。
- 优势：零成本、即时生效、无需训练数据、迭代速度快
- 劣势：受上下文窗口限制、输出稳定性差（换一种问法结果可能大变）、无法改变"模型本身不知道的事实"、每次调用都要传入 prompt（增加延迟和 token 成本）
- 适用：任务定义清晰，few-shot 示例能充分覆盖，对格式一致性要求不极高
RAG（检索增强生成）
在生成前先检索相关文档，将检索结果作为上下文传给模型。
- 优势：知识可实时更新、文档量无上限、可追溯来源
- 劣势：检索质量是上限，检索不准则回答不准；系统架构复杂；多跳推理（需要综合多处知识）效果差；对格式一致性控制弱
- 适用：知识频繁更新（每天/每周新增内容）、文档量大（数千到数百万文档）、需要精确引用来源
微调（Fine-tuning）
在领域数据上训练，将知识和行为模式内化到模型权重中。
- 优势：输出格式极度一致、领域深度理解强、推理成本低（小模型替代大模型）
- 劣势：知识静态（需重训才能更新）、有数据标注成本和训练资源成本
- 适用：输出格式需高度一致、领域概念需深度理解、有足够高质量标注数据
5.2 量化对比
| 对比维度 | Prompt 工程 | RAG | 微调 |
|---|---|---|---|
| 实施周期 | 1~3 天 | 1~4 周 | 2~6 周 |
| 实施成本 | 极低 | 中等 | 较高 |
| 知识更新 | 即时 | 即时 | 需重新训练 |
| 格式一致性 | 60%~75% | 75%~85% | 90%~98% |
| 推理延迟 | 高（长 prompt） | 中（检索耗时） | 低 |
| 深度推理能力 | 依赖基础模型 | 弱 | 强 |
| 私有知识注入 | 浅（仅上下文） | 中（检索匹配） | 深（权重内化） |
| 长期维护成本 | 低 | 中（维护索引） | 低（定期重训） |
黄金组合：生产系统最优架构通常是「微调 + RAG」——微调解决模型格式规范和专业能力，RAG 解决知识实时性。两者相辅相成，不是替代关系。
6. 哪些场景需要微调
以下五类场景，微调几乎是唯一或最优解。
场景一：输出格式高度定制化且要求绝对稳定
典型案例：某保险公司理赔报告自动生成系统
要求每份报告必须严格包含四个部分：事故描述（客观陈述）、责任认定（含责任比例）、赔偿金额明细（表格格式）、适用条款（引用具体条款编号）。任何一个部分缺失都不可接受，且各部分顺序不能变。
- 用提示词工程的格式遵从率：约 60%~75%（随用户描述方式变化）
- 微调后的格式遵从率：稳定在 95%~98%
本质上，微调把"格式要求"从外部约束（prompt 中的指令）变成了模型的内在行为（权重中的偏置）。
场景二：领域术语与概念需要深度辨析
典型案例：中医辨证问诊系统
"肝火旺盛"和"肝气郁结"在中医理论中截然不同，前者属于实热证，后者属于气机郁滞，对应的治法（清肝泻火 vs 疏肝解郁）和主要用药完全不同。通用模型"知道"这两个词，但无法准确辨析，给出的建议可能混淆两者。
在大量中医医案、医籍数据上微调后，模型能根据症状群精确辨证，给出符合中医理论逻辑的建议。这种深度的概念辨析能力，无法通过 RAG 或 prompt 实现。
场景三：私有知识需要深度推理而非简单查询
典型案例：企业法务合同审查助手
不只是"查到"合同中的某个条款，而是需要模型理解公司历史合同纠纷模式、行业惯例与公司红线，在审查新合同时主动识别组合风险（如担保条款+付款条款组合可能产生的隐性负担），并预判纠纷可能性。
这种能力需要将内部法务知识深度融入模型的推理能力，纯 RAG 只能找到相似合同，无法做到主动的组合风险识别。
场景四：知识蒸馏——用小模型替代大模型
典型案例：用大模型输出训练专用小模型
用 GPT-4 或 Qwen-Max 对特定任务的输出作为训练数据（Teacher Model），微调一个 7B 的小模型（Student Model）。在该特定任务上，微调后的小模型效果接近大模型，但推理速度快 10 倍，成本降低 100 倍以上。
这是目前工业界降低 AI 成本最有效的方式之一，也是微调最重要的价值场景之一。
场景五：品牌声音（Brand Voice）一致性
典型案例：某品牌零售 AI 购物助手
要求：语气亲切活泼（不能过于正式或过于随意）、单条回复不超过 3 句话、遇到无法解决的问题先表达理解再引导人工、结尾必须包含品牌专属语。
微调后，模型将这套风格规范内化，不需要每次调用时都在 prompt 里写几百字的风格说明。既降低了 token 成本，也让风格更自然、更一致。
7. 哪些场景不需要微调
7.1 Prompt 工程尚未做到极限
当详细的 system prompt + 3~5 个 few-shot 示例已经能达到 80% 以上的满意度时，先不要微调。Prompt 的迭代速度比微调快 10 倍，成本接近零。
常见误区：团队 prompt 只调了两三版就放弃，转而做微调。结果花了 2~4 周，效果提升幅度还不如把 prompt 再打磨一周。
正确做法：先把 prompt 做到极限，记录哪些类型的问题用 prompt 解决不了，再把这些"无法解决的案例"作为微调的目标数据集。
7.2 知识需要频繁实时更新
微调后的知识是静态的，更新知识就要重训。如果业务知识每天都在变化（股票行情、最新新闻、政策更新），RAG 是唯一合适的方案。
判断标准：知识更新周期 < 2 周，不适合微调；≥ 2 周，可以考虑定期重训。
7.3 数据量极少且无法扩充
只有几十条样本时，微调的风险远大于收益：模型极可能过拟合，泛化极差。
替代方案：把这几十条高质量样本直接作为 few-shot 放入 prompt，效果通常优于在几十条上微调。
7.4 资源受限且没有预算
QLoRA 方案至少需要 9GB 显存的 GPU（如 RTX 3060）。如果没有 GPU 也没有购买云端资源的预算，继续使用 API + 精心优化的 prompt。
8. 微调成本与收益评估
在提项目预算和启动资源调配之前，需要对投入产出有清醒认识。
8.1 成本构成
数据标注成本（通常占总成本 60%~70%，是最大隐性成本）：
| 数据量 | 人工标注工时估算 | 任务复杂度 |
|---|---|---|
| 500 条 | 2~5 人天 | 简单问答，标注人员理解业务即可 |
| 2000 条 | 5~15 人天 | 中等复杂，需要领域知识 |
| 10000 条 | 20~60 人天 | 复杂推理，需要专家审核 |
| 50000 条 | 专职标注团队数周 | 通常需要外包标注公司 |
使用大模型辅助生成（GPT-4/Qwen-Max 生成初稿 + 人工审核）可以将标注成本降低 60%~70%，但质量保证需要充分的人工审核流程。
训练资源成本：
| 场景 | GPU 配置 | 训练时长 | 云端租用费用估算 |
|---|---|---|---|
| 7B QLoRA | RTX 3090 x1（24G） | 2~4 小时 | ¥10~30 |
| 7B LoRA | A100 40G x1 | 2~6 小时 | ¥20~60 |
| 14B LoRA | A100 40G x2 | 4~12 小时 | ¥80~250 |
| 7B Full FT | A100 80G x4 | 8~24 小时 | ¥200~600 |
| 70B LoRA | A100 80G x8 | 1~3 天 | ¥1000~3000 |
注：以上为大致估算，实际费用因云平台和时段而异。
工程人力成本：
| 阶段 | 时间估算 | 说明 |
|---|---|---|
| 数据准备 | 1~3 周 | 含收集、清洗、格式化、质量审核 |
| 训练调参 | 3~7 天 | 通常需要 2~3 轮实验 |
| 评测优化 | 3~7 天 | 构建测试集，多维度评测 |
| 部署上线 | 2~5 天 | 压力测试、灰度发布 |
| 总计 | 约 3~7 周 | 取决于团队经验和任务复杂度 |
8.2 典型收益
| 收益维度 | 典型提升幅度 | 说明 |
|---|---|---|
| 领域任务准确率 | +20%~50% | 相比直接使用基础模型 |
| 输出格式一致性 | 60% → 95%+ | 对格式有严格要求的场景 |
| 推理延迟 | 降低 50%~90% | 用微调后的小模型替代大模型 |
| API 调用成本 | 降低 70%~99% | 自部署替代调用商业 API |
| 用户满意度 | +15%~40% | 综合效果感知提升 |
8.3 投资回报判断框架
值得微调的信号：
- 该任务每天执行 1000 次以上
- 对输出质量有明确且可量化的要求
- 目前调用大模型 API 的成本每月超过 5000 元
- 有足够历史数据（500条以上）可供标注
不值得微调的信号：
- 任务执行频率低（每天 < 100 次）
- 无法明确定义"什么是好的输出"
- 数据难以获取或标注成本过高
- 团队没有工程师能维护训练-评测-部署流程
9. 垂直领域微调行业图谱
graph TD
ROOT[垂直领域微调]
ROOT --> MED[医疗健康]
ROOT --> LAW[法律合规]
ROOT --> FIN[金融投资]
ROOT --> CS[企业客服]
ROOT --> CODE[代码开发]
ROOT --> EDU[教育培训]
MED --> M1[问诊助手]
MED --> M2[病历结构化]
MED --> M3[医学文献问答]
LAW --> L1[合同审查]
LAW --> L2[法条问答]
LAW --> L3[案例分析]
FIN --> F1[研报撰写]
FIN --> F2[风险评估]
FIN --> F3[财报分析]
CS --> C1[产品咨询]
CS --> C2[故障排查]
CODE --> CO1[私有代码库补全]
CODE --> CO2[代码审查]
EDU --> E1[自适应练习]
EDU --> E2[作文批改]
各行业关键挑战与微调重点：
| 行业 | 核心挑战 | 数据特点 | 微调重点 | 评测重点 |
|---|---|---|---|---|
| 医疗 | 安全性极高，必须防止误导 | 隐私敏感，需脱敏处理 | SFT + 偏好对齐 | 临床准确率 + 安全合规 |
| 法律 | 法条引用必须精确，版本不能错 | 结构化强，有固定格式 | SFT（格式为主） | 法条准确性 + 格式规范 |
| 金融 | 监管合规，不能误导投资 | 时效性强，需配合 RAG | SFT + RAG | 合规性 + 分析逻辑 |
| 客服 | 必须拒绝超范围问题，防幻觉 | 数据量大，质量参差 | SFT + 大量拒绝样本 | 解决率 + 满意度 |
| 代码 | 代码必须可执行，语法不能错 | 容易从开源项目获取 | SFT（私有代码库） | 运行通过率 + 代码质量 |
| 教育 | 需因材施教，不同水平不同回复 | 需多难度层次设计 | SFT + 偏好对齐 | 教学效果 + 正确率 |
10. 微调成功的三个前提
前提一：明确且可量化的任务定义
微调是有监督学习，必须能清晰定义"什么是好的输出"：
- 有清晰的输入格式：什么是 query，什么是可选的 context
- 有明确的输出标准：必须包含哪些要素，不能出现哪些内容
- 有可量化的评测指标：准确率、格式遵从率、BLEU、通过率、人工评分等
"我希望模型更专业"——不是可微调的目标。
"我希望模型的回答始终包含「诊断分析/建议就医科室/注意事项」三个部分，且建议就医科室必须是标准科室名称"——这是可微调的目标。
前提二：足够数量且质量合格的训练数据
行业公认的优先级排序：
数据质量 > 数据数量 > 模型大小
500 条经专家精心标注的高质量数据，往往优于 5000 条快速收集的噪声数据。
| 任务类型 | 最少可行数据量 | 可接受效果的推荐量 | 追求高质量的数据量 |
|---|---|---|---|
| 输出格式对齐 | 200 条 | 500~1000 条 | 2000+ 条 |
| 领域知识问答 | 500 条 | 2000~5000 条 | 10000+ 条 |
| 复杂多步推理 | 1000 条 | 5000~20000 条 | 50000+ 条 |
前提三：在训练前建好测试集
这是最容易被忽略、影响最大的前提：开始任何训练之前，先把测试集建好。
测试集要求：
- 与训练集严格隔离，任何样本不能同时出现在两个集合中
- 覆盖完整的场景范围：核心场景（60%）+ 边界情况（20%）+ 应拒绝的场景（20%）
- 有明确的评分标准，不同评测人员能得到一致的结论
常见错误：先做完微调，再想怎么评测。这样根本无法知道微调是否真的有效，更无法比较不同训练方案。
11. 本系列路线图
graph LR
P1[第一篇 认识微调] --> P2[第二篇 ms-swift 框架]
P2 --> P3[第三篇 实战与最佳实践]
| 篇章 | 核心内容 | 适合读者 |
|---|---|---|
| 第一篇（本篇） | 概念、决策框架、方法全景、行业图谱 | 所有人，特别是项目负责人 |
| 第二篇 | ms-swift 框架架构、功能模块、安装配置详解 | 技术负责人、工程师 |
| 第三篇 | 数据格式、完整训练命令、评测、部署、调参与排障 | 动手实施的工程师 |
下一篇预告：第二篇将系统介绍 ms-swift 框架——这个来自阿里云魔搭社区的开源框架，支持 600+ 纯文本模型和 400+ 多模态模型的训练到部署全链路。我们将详细讲解其架构设计、功能模块、硬件支持、安装方式及各核心命令的使用。
官方文档：swift.readthedocs.io/zh-cn/lates… GitHub：github.com/modelscope/…
