大模型微调学习（一）

一、大模型微调概览

大模型微调是当前 AI 应用落地中最核心的技术路径之一。它指的是在已经预训练好的大语言模型（LLM）基础上，使用特定任务的数据继续训练，让模型从"通用文本续写器"转变为能够精准执行特定任务的"任务执行器"。本章将从整体流程、模型选择、数据准备和技术路线四个维度，系统性地梳理大模型微调的全貌。

1. 大模型项目的完整方法论

一个成功的大模型项目，绝不是一上来就进行微调，而是遵循一套严谨的工程方法论。这套方法论可以概括为以下六个阶段，它们环环相扣、彼此反馈，构成了完整的闭环流程。

1.1 Scope：界定问题

这是整个项目的起点，也是最容易被忽视却最关键的一步。第一步是 Define problem，也就是先明确项目到底要解决什么问题。 很多团队在这一步就犯了错误------他们急于选择模型、急于准备数据，却没有把任务目标说清楚。

在界定问题时，需要回答几个核心问题：

• 用户是谁？ 明确目标用户群体，他们的技术背景、使用场景和真实需求是什么。
• 输入是什么？ 模型接收什么样的数据，是文本、图片、语音还是多模态信息？
• 输出是什么？ 期望模型产出什么格式的结果，是分类标签、生成文本、抽取实体还是对话回复？
• 应用边界在哪里？ 哪些情况属于模型职责范围，哪些情况应该交给人工处理或规则引擎？

这个阶段不能急着碰模型，而是先把任务目标说清楚。 一个模糊的问题定义会导致后续所有环节的返工。

与此同时，还需要建立 Benchmark / test set，也就是评估标准和测试集。Benchmark 的作用是提前规定"什么叫模型做得好"，否则后面优化没有判断依据。一个好的 Benchmark 应该包含：

• 多样化的测试样本，覆盖各种边界情况。
• 明确的评估指标，如准确率、F1 分数、BLEU 分数等。
• 与真实业务场景一致的难度分布。

1.2 Select：选择模型

问题定义清楚之后，就进入模型选择阶段。这一阶段的核心是 Choose model，也就是选择合适的基座模型。

当前开源社区提供了丰富的基座模型选择，包括 LLaMA 系列、Qwen 系列、Mistral 系列、Baichuan 系列等。选择模型时，可以把多个候选模型放到同一个 Benchmark 上进行比较，这样能获得客观的横向对比结果。

比较时需要关注以下几个维度：

• 模型效果：在目标 Benchmark 上的表现是否达标。
• 推理速度：单次推理的延迟是否满足业务要求。
• 部署成本：需要多少 GPU 资源，推理服务的硬件开销有多大。
• 显存需求：模型参数量对应的显存占用，是否在可接受的范围内。
• 任务适配能力：模型对特定领域（如法律、医疗、代码）的先天理解能力。

图中的 1、2、3 排序可以理解为对候选模型做排行榜式筛选。 通过系统化的评估，把候选模型按照综合得分排序，选择最合适的一个。

如果所有候选模型都达不到要求，就需要回到 Scope 阶段，重新检查问题定义是否过大、目标是否过高。 这是一个重要的反馈机制------有时候不是模型不够好，而是任务定义本身超出了当前技术能力边界。

1.3 Adapt & Align：适配与对齐

这一阶段是大模型项目中最常见的优化环节。 当基座模型选定后，通常还需要经过多轮适配才能达到业务要求。这个阶段的优化遵循"先便宜，后昂贵"的原则，从成本最低的方法开始逐步升级。

Prompt engineering 是最低成本的方法，通常应该最先尝试。 通过精心设计提示词，可以在不修改模型参数的情况下引导模型输出期望的结果。好的 Prompt 设计包括：

• 明确的任务指令。
• 必要的背景信息。
• 输出格式的约束。
• 少量示例（Few-shot）的引导。

如果提示工程无法满足任务要求，就可以进入 Fine-tuning / SFT。 SFT 指监督微调，也就是用自己的任务数据让模型学习特定回答方式。与 Prompt 工程相比，SFT 能够更稳定地改变模型行为，但需要准备标注数据并消耗训练资源。

如果还需要让模型更符合人类偏好、安全规范或特定表达风格，可以继续做 Human feedback / DPO-RLHF。 这一层优化让模型不仅"会做任务"，还"做得符合人类期望"------比如更安全、更有礼貌、更符合品牌调性。

这一阶段的优化顺序体现了"先便宜，后昂贵"的原则。 每一步都建立在前一步无法满足需求的基础上，避免过度投入。

1.4 Evaluate：持续评估

Evaluate 不是最后才做，而是贯穿 Adapt & Align 的全过程。 这是很多团队容易犯的错误------把评估当作项目收尾时的一次性动作。

正确的做法是：

• 每一次 Prompt 修改、SFT 训练或对齐优化之后，都要回到 Benchmark 上测试。
• 通过对比优化前后的评估结果，判断改动是否真正有效。
• 如果效果没有提升甚至下降，需要及时回退或调整策略。

Benchmark 来自 Scope 阶段，所以整个流程形成闭环。 从问题定义到模型优化，再到评估反馈，形成一个持续迭代的循环。

如果评估结果不好，就继续调整模型、数据或任务定义。 这体现了评估驱动开发，而不是凭感觉判断模型好坏。数据驱动的决策方式能够避免主观偏见，让每一步优化都有据可依。

1.5 Application Integration：应用集成

当模型效果达到要求后，需要进入真实应用落地阶段。 这是从实验室到生产环境的关键一跃，涉及工程化、性能优化和系统集成等多个方面。

Serving / Inference 关注模型如何部署、如何加速、如何降低推理成本。 在生产环境中，推理效率和成本直接决定了项目的商业可行性。常见方法包括量化、KV-cache、vLLM、批处理推理等：

• 量化：将模型权重从 FP16 压缩到 INT8 或 INT4，显著降低显存占用和推理延迟。
• KV-cache：缓存注意力机制中的键值对，避免重复计算，加速长文本推理。
• vLLM：高性能推理引擎，通过 PagedAttention 等技术大幅提升吞吐量。
• 批处理推理：将多个请求合并为一批处理，提高 GPU 利用率。

API + RAG applications 表示把模型接入外部工具、数据库、知识库或业务系统。 这不仅是简单的 API 调用，更是一个完整的系统工程。

RAG 可以让模型调用外部知识，减少幻觉，并提升专业领域问答能力。 检索增强生成（Retrieval-Augmented Generation）通过以下方式增强模型能力：

• 先从知识库中检索与问题相关的文档片段。
• 将检索结果作为上下文注入 Prompt。
• 模型基于检索到的信息生成回答，减少凭空编造。

1.6 整体方法论总结

大模型项目不是一上来就微调。 正确的工程路径应该是：

1. 先定义问题：明确任务目标、评估标准和边界条件。
2. 再选择模型：基于 Benchmark 系统化比较候选模型。
3. 逐步适配：从 Prompt 工程开始，逐步升级到微调和对齐。
4. 最后部署应用：完成工程化、性能优化和系统集成。

Prompt 工程成本最低，应该优先尝试。 它不需要训练资源，迭代速度快，适合快速验证想法。

Fine-tuning 适合 Prompt 无法解决、但有高质量任务数据的情况。 当任务需要稳定的行为改变、领域知识注入或格式约束时，微调是更可靠的选择。

RAG 适合需要接入知识库、文档、数据库或实时信息的应用。 它让模型能够访问外部知识，特别适合知识密集型任务。

微调只是整个 LLM 应用流水线中的一个环节，不是唯一核心。 一个成功的大模型应用，往往是 Prompt 工程、微调、RAG 等多种技术的组合，需要根据具体场景灵活选择。

2. 从 Few-shot 到 Fine-tuning：为什么需要微调

在深入微调技术之前，我们需要先理解一个关键问题：为什么 Prompt 工程和 Few-shot 不够用？ 这一节通过分析 Few-shot 的局限性，自然引出微调的必要性。

2.1 Few-shot 的优势与局限

上一页重点说明 Few-shot 很有用：只要给模型一个示例，模型就能模仿格式完成任务。 这种能力被称为 In-context Learning（上下文学习），它让模型无需修改参数就能快速适应新任务。

但这一页开始说明 Few-shot 不是完美方案。 它主要讲 Few-shot / In-context Learning 的三个问题：

• 成本变高：每次推理都要携带示例，token 消耗显著增加。
• 泛化能力不稳定：示例覆盖不全时，模型容易出错。
• 占用上下文窗口：示例挤占了真正输入的空间。

2.2 左侧 Context Window 的含义

左边的大框表示模型一次能看到的 Context Window，也就是上下文窗口。 这是模型在单次推理中能处理的最大 token 数量。

框里放了多个带答案的示例，也就是 3-shot。 每个示例都包含：

• 输入评论：如 "loved this DVD"。
• 标准情感标签：如 "Positive"。

最后才是真正要模型判断的新输入：

• Classify this review: Who would use this product?
• Sentiment:

这个设计是为了让我们看到：示例越多，Prompt 就越长，上下文窗口就会被占得越满。 这是一个直观的视觉化呈现------随着示例数量增加，可用空间不断减少。

2.3 问题一：推理成本变高

Few-shot 需要在每次调用模型时，把示例一起放进 Prompt。 这意味着示例不是一次性投入，而是每次推理都要重复消耗。

这些示例本身也是 input token。 在当前的计费模式下，input token 和 output token 都按量计费。

input token 越多，调用成本就越高。 假设一个 3-shot 示例需要 500 个 token，如果每天调用 10 万次，仅示例部分就消耗 5000 万 token。

而且这些示例不是只算一次，而是每次推理都要重新发送、重新计算。 模型需要重新处理所有示例，增加了计算开销。

所以如果一个任务调用次数很多，Few-shot 的 token 成本会不断累积。 这也是右侧聊天区提到"推理成本提高了"的原因。对于高频业务场景，这种成本累积可能非常可观。

2.4 问题二：泛化能力不稳定

Few-shot 的效果依赖示例质量。 示例选择得好，模型表现就好；示例覆盖不全，模型就容易出错。

如果示例覆盖得不全面，模型遇到新的输入类型时就可能出错。 比如图中最后一句 "Who would use this product?" 并不是很典型的情感表达。

它不像 "I loved this movie" 或 "I don't like this chair" 那样直接表达喜欢或不喜欢。 前者是一个疑问句，询问谁会使用这个产品，并没有直接的情感倾向。

这种输入和前面的示例分布不太一样，模型就可能不知道该怎么判断。 因为模型只能从示例中学习模式，当输入偏离示例分布时，它就缺乏判断依据。

所以 Few-shot 不是万能的，它容易受到示例范围和示例偏差的影响。 这就是图中说的"不能泛化"或"泛化能力降低"。

2.5 问题三：占用上下文空间

模型的 Context Window 是有限的。 以 GPT-4 为例，其上下文窗口通常为 8K 到 128K token，超过这个限制就无法处理。

Prompt 通常可以理解成：

• 示例 examples：Few-shot 提供的示范样本。
• 真正输入 input：用户的实际问题或待处理内容。
• 输出要求 output format：期望的输出格式说明。

示例越多，examples 占用的 token 就越多。 每个示例都包含输入和输出，占用双倍的 token 空间。

examples 占得越多，留给真正 input 的空间就越小。 如果任务本身需要处理长文档、长对话或复杂材料，Few-shot 示例就会挤占正文空间。

一旦超过上下文窗口，可能会出现截断、遗漏信息，甚至无法正常输入。 这是实际部署中非常常见的问题，尤其是在处理长文档场景时。

2.6 为什么这页要讲 Few-shot 的缺点

上一页证明了 Few-shot 有用。 它确实是一种强大的提示工程技术，能够快速引导模型完成任务。

这一页说明 Few-shot 虽然有用，但不能一直依赖它。 它存在成本、泛化和空间三个维度的固有局限。

如果每次都靠在 Prompt 里塞示例来完成任务，就会带来成本、长度和稳定性问题。 这些问题在高频、长文本、复杂任务场景中尤为突出。

所以课程需要自然引出 Fine-tuning。 微调提供了一种根本性的解决方案。

Fine-tuning 的目标是把任务能力学进模型参数里，而不是每次都临时写进 Prompt 里。 一旦任务能力被编码进模型权重，推理时就无需携带大量示例，从根本上解决了上述三个问题。

2.7 Few-shot 和 Fine-tuning 的关系

为了更清晰地理解两者的区别，我们可以从多个维度进行对比：

Few-shot：

• 不改模型参数：模型权重保持不变，仅通过上下文引导。
• 靠上下文示例临时引导模型：每次推理都需要提供示例。
• 优点是简单、快速、训练成本低：无需训练资源，即插即用。
• 缺点是每次推理都要带示例，token 成本高，占用上下文：高频场景成本累积明显。

Fine-tuning：

• 会更新模型参数：通过训练改变模型权重。
• 把任务格式、领域知识或回答风格训练进模型：能力内化到参数中。
• 推理时可以少放甚至不放示例：大幅降低 token 消耗。
• 更适合高频、稳定、专业化的任务：一次训练，长期受益。

2.8 这张图的核心结论

Few-shot 是一种很有效的提示工程方法，但它不是最终解决方案。 它适合快速验证和低频场景，但在生产环境中存在明显瓶颈。

示例越多，模型越容易理解任务，但同时也越贵、越占空间。 这是一个 trade-off：效果与成本之间的平衡。

示例质量不好或覆盖不全时，模型泛化能力也会下降。 示例选择本身就是一个需要精心设计的环节。

所以在真实项目中，通常先尝试 Prompt engineering 和 Few-shot。 这是成本最低的起点。

如果效果不稳定、调用成本太高、上下文空间不够，就需要考虑 Fine-tuning、SFT 或 LoRA。 这正是从 Prompt Engineering 过渡到模型微调的关键动机。

3. 预训练与微调的关系

3.1 这张图讲什么

标题是 Fine-tune on Model。 但图里主要讲的是微调之前的步骤：预训练。

也就是先用海量文本训练出一个 Pre-trained LLM，然后再在它上面做微调。 理解预训练是理解微调的前提。

3.2 预训练数据是什么

左边的 Raw text、Web pages、Books、Code 表示原始文本数据。 这些数据来源多样，覆盖了互联网上的大部分文本内容。

这些数据通常不需要人工标注。 这是预训练与微调最大的区别之一------预训练数据是"免费"的，不需要人工标注成本。

模型通过大量文本学习语言规律和通用知识。 通过海量文本的统计学习，模型掌握了词汇、语法、常识和推理能力。

3.3 预训练怎么做

中间的 next-token prediction 表示"预测下一个 token"。 这是预训练的核心任务。

模型不断练习：根据前面的词，预测后面的词。 例如给定 "今天天气很"，模型需要预测下一个词是"好"还是"差"。

这个过程叫 self-supervised learning，也就是自监督学习。 因为训练目标可以从文本本身自动生成，无需人工标注。

3.4 预训练得到什么

右边的 Pre-trained LLM 就是预训练大模型。 它也可以叫 Base Model。

Base Model 很擅长续写文本，但不一定会听指令。 它学会了语言规律，但不一定理解"回答问题"或"执行任务"的指令格式。

3.5 为什么引出微调

Fine-tuning starts here 表示微调从预训练模型开始。 微调不是从零训练模型。

SFT 和 LoRA 都是在 Base Model 的基础上继续训练。 它们利用预训练模型已经学到的知识，用少量任务数据做定向调整。

目的就是让模型更会执行任务、更符合我们的应用需求。 微调的本质是"站在巨人的肩膀上"，用最小的成本获得最大的任务能力提升。

4. 微调的核心概念

4.1 这张图讲什么

这页讲的是如何在 Pre-trained LLM 上做微调。 左边是已经预训练好的 Base Model。

中间是情感分析任务的 instruction data。 这是微调所需的训练数据。

右边是微调后得到的 Fine-tuned LLM。 这是微调的最终产物。

4.2 微调数据长什么样

每条数据都是 input → output 的格式。 这是监督微调的基本数据形式。

input 是用户给模型的问题或任务。 output 是希望模型学会输出的标准答案。

例如：

• input: loved this DVD
• output: Positive

这种格式让模型学会"看到什么输入，就输出什么答案"的映射关系。

4.3 为什么只写 x1000 examples

微调不需要像预训练那样使用海量原始文本。 预训练需要 TB 级别的数据，而微调只需要少量任务数据。

它更依赖少量高质量任务数据。 这里的 x1000 examples 表示大约一千条精心准备的数据。

重点是 quality > quantity，也就是质量比数量更重要。 一千条高质量、覆盖全面的数据，远胜于十万条低质量、重复冗余的数据。

4.4 微调后有什么变化

原来的 Base Model 更擅长续写文本。 它像一个"通用语言专家"，什么都能说一点，但不专精。

微调后的 Task Model 更擅长完成指定任务。 它变成了"领域专家"，在特定任务上表现优异。

在情感分析中，它可以直接判断新评论是 Positive 还是 Negative。 无需提供示例，模型就能直接输出判断结果。

4.5 一句话总结

Fine-tuning 就是用少量 input/output 数据，在 Pre-trained LLM 的基础上继续训练，让模型从"通用续写器"变成"任务执行器"。 这是整个微调技术的核心思想，后续章节将围绕这一思想展开具体的技术实现。

1. 这张图讲什么

   • 这页讲 Fine-tune 之前的数据划分。
   • 1000 条 instruction data 不能全部拿去训练。
   • 需要拆成训练集、验证集和测试集。

2. 训练集 Train

   • 训练集最大。
   • 它真正参与模型训练。
   • 模型会根据训练集更新权重或 LoRA 参数。
   • 作用是教模型学会任务格式和回答方式。

3. 验证集 Dev

   • 验证集不更新模型参数。
   • 它用来观察 loss 和指标。
   • 开发者根据验证集结果调整学习率、epoch、checkpoint 等配置。
   • 它相当于训练过程中的"模拟考试"。

4. 测试集 Test

   • 测试集只在最后使用。
   • 它不能提前给开发者反复查看。
   • 如果开发者一直看测试集分数并改模型，测试集就会变成第二个验证集。
   • 这样最终分数会虚高，不能代表真实效果。

5. 一句话总结

   • 训练集教模型做事，验证集教开发者调参，测试集负责最终裁判。

1. 这张图讲什么

   • 这页讲单任务微调。
   • 例子是 Summarization，也就是摘要任务。
   • 左边是 Pre-trained LLM，右边是微调后的 Instruct LLM。

2. 中间的数据是什么

   • 每条样本都包含 instruction、input、output。
   • instruction 是固定任务模板。
   • input 是要摘要的原文。
   • output 是标准摘要答案。

3. 为什么是 500-1000 examples

   • 单任务微调不需要海量数据。
   • 重点是数据质量，而不是数据数量。
   • 几百到一千条高质量样本，通常就能让模型学会一个具体任务。

4. 微调后的变化

   • 微调前，模型更像文本续写器。
   • 微调后，模型更像指令执行器。
   • 推理时只需要给任务指令和输入，不必再塞很多 few-shot 示例。

1. 这张图讲什么

   • 这页讲 Fine-tuning 的直接价值。
   • 同一个 prompt，同一个任务，唯一变化是模型有没有微调。
   • 微调前输出错误，微调后输出正确。

2. 微调前为什么错

   • Base Model 更像文本续写器。
   • 它看到 Sentiment: 后，可能继续写一段自然语言。
   • 所以它没有输出情感标签，而是输出了无关 completion。

3. 微调后为什么对

   • Fine-tuned Model 已经学过情感分类的 input/output 格式。
   • 它知道看到这类 prompt 后，要输出标签。
   • 所以它直接给出 POSITIVE。

4. 这页的核心结论

   • 微调不是单纯增加知识。
   • 微调更重要的是改变模型行为。
   • 知识主要来自预训练，任务行为来自微调。