大模型垂直领域微调系列（一）：认识微调

作者：吴佳浩

撰稿时间：2026-3-9

测试版本：ms-swift v4.0.1

本系列基于 ms-swift v4.x 官方文档整理，共三篇：

第一篇（本文）：微调是什么、为什么做、什么时候该做

第二篇：ms-swift 框架全景介绍

第三篇：完整实战流程与最佳实践

[1. 大模型能力的边界](#1. 大模型能力的边界 "#1-%E5%A4%A7%E6%A8%A1%E5%9E%8B%E8%83%BD%E5%8A%9B%E7%9A%84%E8%BE%B9%E7%95%8C")
[2. 什么是微调](#2. 什么是微调 "#2-%E4%BB%80%E4%B9%88%E6%98%AF%E5%BE%AE%E8%B0%83")
[3. 微调方法全景](#3. 微调方法全景 "#3-%E5%BE%AE%E8%B0%83%E6%96%B9%E6%B3%95%E5%85%A8%E6%99%AF")
[4. 训练任务类型总览](#4. 训练任务类型总览 "#4-%E8%AE%AD%E7%BB%83%E4%BB%BB%E5%8A%A1%E7%B1%BB%E5%9E%8B%E6%80%BB%E8%A7%88")
[5. 微调 vs 其他方案](#5. 微调 vs 其他方案 "#5-%E5%BE%AE%E8%B0%83-vs-%E5%85%B6%E4%BB%96%E6%96%B9%E6%A1%88")
[6. 哪些场景需要微调](#6. 哪些场景需要微调 "#6-%E5%93%AA%E4%BA%9B%E5%9C%BA%E6%99%AF%E9%9C%80%E8%A6%81%E5%BE%AE%E8%B0%83")
[7. 哪些场景不需要微调](#7. 哪些场景不需要微调 "#7-%E5%93%AA%E4%BA%9B%E5%9C%BA%E6%99%AF%E4%B8%8D%E9%9C%80%E8%A6%81%E5%BE%AE%E8%B0%83")
[8. 微调成本与收益评估](#8. 微调成本与收益评估 "#8-%E5%BE%AE%E8%B0%83%E6%88%90%E6%9C%AC%E4%B8%8E%E6%94%B6%E7%9B%8A%E8%AF%84%E4%BC%B0")
[9. 垂直领域微调行业图谱](#9. 垂直领域微调行业图谱 "#9-%E5%9E%82%E7%9B%B4%E9%A2%86%E5%9F%9F%E5%BE%AE%E8%B0%83%E8%A1%8C%E4%B8%9A%E5%9B%BE%E8%B0%B1")
[10. 微调成功的三个前提](#10. 微调成功的三个前提 "#10-%E5%BE%AE%E8%B0%83%E6%88%90%E5%8A%9F%E7%9A%84%E4%B8%89%E4%B8%AA%E5%89%8D%E6%8F%90")
[11. 本系列路线图](#11. 本系列路线图 "#11-%E6%9C%AC%E7%B3%BB%E5%88%97%E8%B7%AF%E7%BA%BF%E5%9B%BE")

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 参数中混合：

bash 复制代码

--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）

当前最主流的参数高效微调方法。核心思想：假设权重更新矩阵是低秩的，用两个小矩阵的乘积来近似。

ini 复制代码

原始全量更新: 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，但资源门槛大幅降低

bash 复制代码

# 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/...

大模型垂直领域微调系列（一）：认识微调