AI 学习笔记系列的第五篇，介绍 LLM 的训练、使用、评估和提高效率的相关概念。

训练 LLM

通用模型可分为三类：Encoder、Encoder-Decoder 和 Decoder。 它们在架构和天然用途上不同，现在多数模型是 Decoder。

这些模型都通过取原始文本，然后做某种改动，再让模型识别 / 修复该改动的方式来训练。 不同模型类型常用不同任务，最常见的是下一 token 预测（给定文本前缀，预测下一个 token）和遮蔽 token 预测（给定部分 token 被遮蔽的文本，预测被遮蔽 token）。

语言模型的另一种训练方式是 token 编辑检测。 用另一个模型（编辑器）先改动输入中的一些 token，被训练模型（预测器）要对每个 token 预测编辑过（Edited）还是一样（Same）。 若大多数都改了，模型可能难学，因为缺少可用上下文来判断哪些被编辑。 若只改一个，训练信号很弱，学习可能很慢。

具体来说，不同的模型在建模不同的概率分布，训练任务不同：

  • Encoders：
    • 遮蔽 token 预测：BERT
    • span 预测：SpanBERT
    • 随机 token 纠错：BERT
    • 组合任务：BERT
    • token 编辑检测：ELECTRA
    • 下一句预测：BERT
  • Encoder-Decoders：
    • 遮蔽序列预测：BART
    • 遮蔽 span 预测：T5
    • 删除序列预测：BART
    • 删除 span 预测：T5
    • 置换序列预测：BART
    • 旋转序列预测：BART
    • 填空序列预测：BART
  • Decoders：
    • 下一 token 预测：GPT

预训练（Pre-training）

预训练是一个经常被提到的概念，它指的是在大规模文本数据上训练一个通用的语言模型，使其具备强大的语言理解和生成能力。

不难看出，预训练和训练在原理上是一样的，都是基于损失函数（Loss Function）做反向传播。 具体来说，都是通过不断地调整模型的参数来最小化预测下一个 token 的损失函数，使得模型能够更好地拟合训练数据中的语言规律。

备注：这里可能有歧义。之所以叫“预训练”，是为了和后续的微调与对齐区分（它们常被统称为 Post-Training）。而“训练”（Training）在不同语境里用法不同：广义上可以涵盖 Pre-Training 与 Post-Training；在不少工程讨论中，人们也会把“训练”特指 Post-Training。简单来说，Pre-Training 负责通用能力，Post-Training 负责可用性与偏好 / 安全。

预训练和训练的区别在于：

  • 预训练只做一次，训练可以做很多次
  • 预训练通常需要很长时间，训练可以是短的也可以是长的
  • 预训练通常需要大量的计算资源（比如数百到数千个 GPU），训练可以在有限的计算资源上进行
  • 预训练的数据通常是大量的原始文本数据，训练的数据通常是针对特定任务的数据（比如问答、文本分类、翻译等等）

目前我们使用的 LLM 大多是预训练好的模型，比如 GPT、Claude、Gemini 等等，这些模型已经在大规模的文本数据上进行了预训练，具备了强大的语言理解和生成能力。 因为普通用户几乎不具备预训练一个 LLM 的条件（需要大量的计算资源和数据），所以我们通常会使用已经预训练好的模型来进行微调或者直接推理。

备注：这里说“预训练只做一次”，是针对同一个模型的某个版本而言。模型版本更新时，可能会重新进行大规模预训练，也可能是在原有模型基础上继续训练或做更多 Post-Training（具体取决于团队策略与数据、成本）。

微调（Fine-tuning）

微调是指在预训练好的模型基础上，使用特定任务的数据来进一步训练模型，使得模型能够更好地适应特定的应用场景。 正因为微调是在预训练模型的基础上进行的，所以只需要相对较少的计算资源和数据。

指令微调（Instruction Fine-tuning）

指令微调是微调的一种特殊形式，它使用一系列不同任务的示例数据来进行微调，目的是让模型会做任务，包括在推理时处理新任务。 我们所使用的 LLM 大多是经过指令微调的模型，这也是为什么它们能够理解和执行各种各样的指令（Prompt）来完成不同的任务，而不是仅仅根据上下文来预测下一个 token。

我们需要指令微调的原因是语言模型目标函数不总是我们真正想要的。 指令微调的总体思路是在指令-回答对上训练（如 FLAN-T5）。 这里面设计到的一些关键问题包括：

  • 任务选择：高质量数据非常关键，少量高质量任务可能比大量噪声任务更好。
  • 剩余问题：词级预测不能很好衡量任务成功，有些任务不存在唯一最佳答案。

用 token 级预测评估输出，主要局限在于它难以覆盖多答案任务。 像情感分析这类任务，token 级评估通常还行，因为输出 token 在少数选项中，一个对其余错。 像翻译这类任务，一个句子可有多种正确译法。模型输出与数据集中参考译文逐词不一致，不代表模型差。 凡是多正确答案任务都常有这个问题，而这正是当前模型常做的任务，因此该评估问题会反复出现。

备注：这也是为什么很多团队会把自动指标和人工评审结合使用。

所有微调都包括在已有模型上继续训练，使用附加数据（通常比原训练数据更专门化）。 指令微调的过程相同，差别只在数据：使用我们希望模型完成的任务示例，并以如今提示词的形式表达。 普通微调可包括：用常规 next-token 目标在特定领域文本上继续训练（如法律文本），在模型顶部加任务层做预测，并在训练时同时更新底层 LLM。 简单概括，指令微调的数据是任务指令和回答（由人构造任务示例及其答案），普通微调仅有领域原始文本。

对齐（Alignment）

对齐是指在训练过程中，通过引入一些额外的约束或者奖励机制，使得模型的输出能够更好地符合人类的价值观、伦理规范和实际需求。

常见的对齐方法包括：

  • 监督微调（Supervised Fine-Tuning，SFT）：在预训练模型的基础上，使用人工标注的数据来进行微调，使得模型能够更好地理解和执行特定的任务。
  • 基于人类反馈的强化学习（Reinforcement Learning from Human Feedback，RLHF）：在预训练模型的基础上，使用人类反馈来进行强化学习，使得模型能够更好地适应人类的需求和偏好。RLHF 首先进行指令微调，然后使用人类反馈来训练一个奖励模型（Reward Model），最后通过强化学习来优化模型的输出。与传统的强化学习不同，RLHF 不需要定义一个明确的环境和动作空间，而是直接优化模型的输出。
  • 直接偏好优化（Direct Preference Optimization，DPO）：DPO 的核心思想是不通过训练一个独立的奖励模型（奖励模型本身也可能不可靠）来评估输出，而是直接使用人类的偏好数据来优化模型的输出。DPO 比 RLHF 更加便宜，因为它不需要训练一个额外的奖励模型，也不需要进行复杂的强化学习过程。在实际中，DPO 和 RLHF 可以结合使用，先使用 DPO 来快速优化模型的输出，然后再使用 RLHF 来进一步提升模型的性能和对齐效果。

如何选择对齐方法取决于具体的应用场景和需求：

  • SFT：
    • 你有明确的从输入到理想输出到数据（格式、语气、结构都能写出来）
    • 目标是更会按要求回答和更稳定输出格式
    • 成本最低、最可控，也是大多数团队的默认起点
  • RLHF：
    • 目标更复杂：不仅要像，还要更符合人类总体满意度和长期偏好
    • 你有能力做更重的训练流程（奖励模型、训练稳定性、监控回归）
    • 通常在高价值产品形态或强安全需求时更值得投入
    • 代价是流程复杂、调参和回归风险更高
  • DPO：
    • 你很在意回答风格和偏好，但很难写出唯一标准答案
    • 你能收集到哪个回答更好的成对偏好数据
    • 想要比 RLHF 更简单、更便宜地做偏好优化（不训练奖励模型）
    • 现实里常用：先 DPO 快速拉齐风格，再看是否需要更强手段
  • 组合策略（常见于实践）：
    • 先用 SFT 打底，再上 DPO 结合 RLHF 做偏好与安全强化，之后做回归评测

对齐用到的数据从哪里来？

  • 让标注员自由提出任务，同时保证任务多样性。
  • 让标注员提出一条指令，并给出该指令下多个 query / response 对。
  • 让标注员基于用户 query 构造对应 Prompts。

如何构建数据集会涉及伦理问题，对齐对模型的改动也可能比较脆弱。

RLHF

**强化学习（Reinforcement Learning，RL）**是一种机器学习方法，它通过与环境的交互来学习最优策略，以最大化累积奖励。 RL 中，模型与环境交互后如何寻找最优策略有两种不同分类：

  • **强化学习路径（Reinforcement Learning Approach）**指先用偏好数据训练奖励模型，即逼近人类潜在评分函数，再用强化学习方法训练主模型。
  • **直接路径（Direct Approach）**指直接利用偏好对，通过反向传播提高被偏好输出的分数，并降低另一个输出的分数。

RLHF 的训练阶段如下：

  1. 先做指令微调，让模型达到可用水平
  2. 训练奖励模型，设 LLM 在输入 x 上产生输出 y：
    • 输入：(x, y) 对
    • 输出：一个奖励数值。若 y 好，奖励应为正；若差，奖励应为负。越好/越差应离 0 越远。
    • 奖励模型本身是神经网络，仍用常规反向传播训练
    • 训练样本不直接给奖励值，而是给偏好比较（y1 优于 y2）
    • 训练时可用 Bradley-Terry 模型来表达两两比较的概率
  3. 用奖励模型继续训练：
    • 给定一个输入，先让 LLM 生成输出，再由奖励模型打分，最后据此更新 LLM

DPO

**偏好优化（Preference Optimization）**可以理解为从人的偏好学习。 偏好优化数据通常来自人类对成对输出的偏好选择，也可以来自合成偏好数据（例如由规则或其他模型生成 / 筛选）。

用 DPO 对齐可能比较脆弱，即使尝试用 DPO 降低毒性（Toxicity，指不适当或有害的输出），毒性向量仍可能存在，因为 DPO 只是满足目标函数的最小改动，无法保证完全消除毒性。

备注：如果团队资源有限，通常会先从流程更轻的 DPO 起步，再决定是否引入 RLHF。

使用 LLM

大语言模型（Large Language Model，LLM）比语言模型（Language Model，LM）多了一个 Large，但本质不变。 使用 LLM 就是使用 LM。

使用 LM 有几种常见的方式：

  • 把语言模型用于任务：把 LM 作为系统组件，让 LM 输出作为任务模型输入。这种用法下，LM 可冻结（即不更新参数）也可微调。
  • 把任务表述为语言建模：很多任务都能改写成用 LM 做任务的形式。Encoder 模型在可直接完成的任务类型上稍受限。

不论哪种用法，核心都是设计好提示词（Prompt），让模型能理解任务需求并生成符合预期的输出。 提示词优化即在固定任务上自动寻找更有效的 Prompt。 它的难点在于 Prompt 本身通常不可微。 可选做法包括：

  • 把 Prompt 向量化后优化；
  • 用强化学习搜索更优 Prompt；
  • 把 Prompt 作为更大系统的一环，与检索、规划或评估联合优化。

推理（Inference）

推理是指在预训练和微调完成后，使用 LLM 来生成文本或者完成特定任务的过程，即上文提到的从输入到输出的流程。 推理的效率和性能取决于模型的大小、计算资源和输入文本的长度等因素。我们平时所说的部署一个 LLM，通常指的就是把预训练好的模型（或者微调后的模型）放到一个服务器或者云平台上，让用户能够通过 API 来访问和使用这个模型进行推理。

提示词工程（Prompt Engineering）

提示词工程是指通过精心设计和优化提示词，来引导 LLM 生成更符合预期的输出。好的提示词能够帮助模型更好地理解任务需求，提高生成结果的质量和准确性。

常见的提示词设计技巧包括：

  • 先把任务说清楚
    • 明确角色与目标：你是谁，要完成什么，面向谁输出。
    • 明确输入与输出边界：输入是什么，输出要包含什么、不包含什么。
    • 明确约束：字数、语言、语气、是否允许编造、是否需要引用等。
  • 给足上下文，但要隔离
    • 使用分隔符（Delimiters）标出用户内容与引用内容，例如 `...` 或 <context>...</context>，避免混淆与提示注入。
    • 将背景信息放到 context，将操作要求放到 instruction，结构越清晰越稳定。
  • 把输出格式固定下来
    • 要求结构化输出：JSON、YAML、字段列表、编号要点等。
    • 提供字段定义或示例输出，让模型照着填，减少跑偏。
    • 显式处理缺失信息：信息不足时输出 UNKNOWN，并说明缺少什么。
  • 让模型按步骤做
    • 分解任务：先提取，再判断，最后生成；或先列大纲，再写正文。
    • 要求先给中间结果再给最终答案，例如先列要点或证据，再输出结论。
    • 要求自检或对照验证，例如给出解法后用示例验证一遍。
  • 用示例驱动（Few-shot）
    • 提供 1-3 个高质量样例（输入与输出），让模型学格式、风格与边界。
    • 覆盖边界情况：空输入、歧义输入、冲突约束，明确处理规则。
  • 把幻觉（Hallucination）当成工程问题处理
    • 要求基于给定材料回答，材料不足就说明不足，不要自由发挥。
    • 要求引用或出处：先抽取相关片段或要点，再基于它回答，便于追溯。
  • 迭代式开发 Prompt
    • 用少量样例快速迭代：观察失败模式，调整指令、格式或示例，再测试。
    • 做误差分析：将错误按跑题、格式错、漏点、胡编、不遵循约束分类并逐个修正。
    • 逐步加约束：先让它能做对，再让它做得稳（格式、风格、安全）。

上下文工程（Context Engineering）

上下文工程是指通过合理地组织和管理输入文本的上下文信息，来提高 LLM 的理解和生成能力。 上下文工程相当于在提示词工程的基础上，考虑如何构造有效的上下文来支持模型的推理和生成，包括了提示词工程没有覆盖的历史记录、外部知识、用户信息等内容的组织和管理。 因此提示词工程可以视为上下文工程的一个子集。

上下文工程需要考虑以下几个方面：

  • 指令与优先级
    • system / developer / user 的层级与冲突处理规则
    • 安全边界、拒答规则、输出要求的全局约束
  • 上下文内容的组成
    • 任务指令（目标、约束、成功标准、失败处理）
    • 示例（Few-Shot，包含典型与边界样例）
    • 证据材料（RAG 检索片段、知识库文档、工具返回结果）
    • 记忆（短期会话摘要、长期偏好与历史背景）
    • 运行时状态 / 工作区（计划、待办、中间结论、草稿）
  • 结构与格式
    • 分隔符与内容隔离（区分指令、用户输入、引用材料）
    • 结构化约定（Schema、字段、模板），便于稳定输出与程序消费
    • 引用与可追溯标识（来源、chunk id、时间 / 版本）
  • 选择与压缩
    • 相关性筛选（只注入与当前问题有关的内容）
    • 摘要与滚动窗口（对话压缩、关键点保留）
    • 按需加载（先提供目录 / 摘要，需要时再展开）
    • 去重与一致性（避免重复、冲突信息共存）
  • 可信与安全
    • 不可信内容隔离与防提示注入（检索内容不可覆盖指令）
    • 工具白名单与权限最小化（避免越权调用）
    • 结果校验与错误语义（重试、回退、失败可解释）
  • 成本与性能
    • token 预算与延迟控制（缓存静态上下文、减少无效材料）
    • 检索与重排开销（何时检索、检索多少、是否重排）
  • 可观测与评估
    • 记录注入了什么上下文与来源（Tracing）
    • 质量指标：回答正确性、引用一致性、检索命中、工具成功率
    • 迭代流程：失败样例收集、误差分析、策略更新

Skills 功能

Skills 是把如何完成一类任务 / 工作流的知识打包成可复用模块的一种方式，通常以一个文件夹形式组织（核心是说明文件，例如 SKILL.md），也可以附带脚本、模板、示例、资源文件等，帮助模型更稳定地完成特定任务或流程。

对于支持 Skills 的 LLM，例如 Claude 会先看到每个 Skill 的最小描述，用来判断是否相关，只有在需要时才加载该 Skill 的完整说明与相关文件，从而减少上下文窗口压力并提升一致性。 执行流程可以理解为：

  1. 可用技能检索（基于 Skills 描述）
  2. 选择相关技能
  3. 加载技能细节
  4. 按技能步骤完成任务

Skills 解决了这些问题：

  • 复用：把反复解释的流程固化成模块，避免每次都在 Prompt 里重新教一遍。
  • 稳定：通过明确的步骤、检查清单、输出规范，提高一致性与可预测性。
  • 可维护：技能可以版本化、测试与迭代，并在不同产品形态中复用（如 Claude Code 和 Claude API）。

如何选择使用 Skills（对比 Prompt / RAG / Tools）：

  • 适合用 Skills 的情况
    • 固定且可重复的工作流：步骤清晰、经常复用（例如生成周报）。
    • 需要强一致性的格式与流程：输出契约、检查清单、边界情况处理都希望稳定。
  • 不太适合只靠 Skills 的情况
    • 主要缺事实 / 数据而不是缺流程：优先用 RAG / 知识库注入证据，再结合 Skills 做流程化处理。
    • 需要真实外部动作（下单、发邮件、改文件）：仍需工具调用（Tools），Skills 更像怎么调用与怎么收尾的最佳实践封装。

备注：Skills 和 MCP 不互相替代，更像互补。Skills 更偏流程与规范的封装：把一类任务的做法写成 SKILL.md，并可附带脚本 / 模板 / 资源文件，通过按需加载来提升复用性与上下文效率。MCP 则偏工具与资源的标准化接入：由 MCP server 暴露外部能力（工具 / 数据 / 服务），agent 通过统一协议安全地调用它们。两者结合使用可以让 agent 既有稳定的流程指导（Skills），又能可靠地操作外部资源（MCP）。即使模型足够强能自行生成调用代码，MCP 仍能通过结构化接口、权限边界、错误语义与可观测性降低不确定性，通常也比当场生成代码再执行更稳、更省工程维护成本。

设计 Skills 的常见要点：

  • 写清楚触发条件：什么任务该用它，不该用它（减少误触发）。
  • 给出可执行步骤：分阶段、可检查、可回退（失败时怎么做）。
  • 固定输出契约：字段、模板、示例输出，必要时要求引用 / 证据。
  • 附带资源：模板、样例、脚本、校验规则，降低模型自由发挥空间。

评估（Evaluation）

评估指标（Evaluation Metrics）

要评估一个 LLM 的性能和质量，我们需要定义一些评估指标，这些指标可以分为内在指标（Intrinsic）和外在指标（Extrinsic）两大类：

  • 内在指标：只看模型本身的输出分布或排序能力，不依赖下游任务，这里只列两个常见的指标。
    • 平均倒数排名（Mean Reciprocal Rank，MRR）：用于评估正确答案在候选列表里排得有多靠前，越大越好。
    • 困惑度（Perplexity）：衡量模型对一段文本的“惊讶程度”，数值越低表示模型对文本的预测越好，但不能跨不同的 tokenizer 比较。
  • 外在指标：把 LLM 放到具体任务或系统里，评估任务目标是否达成，比如下面提到的基准测试和竞技场。

内在评估在受控设置下衡量模型或表征本身（不嵌入下游系统），外在评估则在具体下游任务 / 系统中衡量端到端效果。 现代基准（Benchmark），尤其是基于 Prompt 的 Few-Shot，虽只调用 LM，但对提示、示例与解码等工程细节高度敏感，使内外在边界变得不再清晰。

离线 vs. 在线（Offline vs. Online）

离线评估（Offline Evaluation）是在固定的数据集和固定的评测流程上跑模型或系统，通过可重复的输入输出对比来衡量效果，优点是迭代快、可复现、便于回归和横向对比，缺点是容易与真实用户分布不一致，指标提升不一定等价于线上体验提升，也可能逐渐对测试集过拟合。

在线评估（Online Evaluation）是在真实用户或真实流量环境中评估系统表现，通常通过 A/B 测试、线上反馈或抽检来观察体验与业务指标，优点是最贴近真实场景、能直接反映最终效果，缺点是实施成本高、周期长、风险更大且信号噪声更强，需要分流监控、统计显著性和回滚机制。

基准测试（Benchmarking）/ 竞技场（Arena）

基准测试指用一套固定的测试集和固定的评分规则来衡量模型能力，通常覆盖不同维度（如知识、推理、代码、数学、对话等），输出一个可对比的分数 / 排名。优点是可重复、可回归、便于横向比较；缺点是容易被刷分、对提示词 / 评测设置敏感，也可能与真实产品场景有分布差异。

竞技场是一种偏好评测形式：让用户对同一问题的多个模型答案进行匿名对战式投票，再把大量投票汇总成排行榜。它更贴近真实对话体验，尤其适合开放式生成任务；但也可能受风格因素影响（例如回答长度、格式等），并且更受欢迎不一定等价于更正确 / 更安全。

提高 LLM 效率

想要提高 LLM 的效率，主要有以下几个方向：

  • 模型压缩：减少参数量与部署体积，可用蒸馏（Distillation）或剪枝（Pruning）。需要注意的是，剪枝要在计算层面带来真实加速并不容易（常受限于硬件/内核对稀疏的支持），因此实践中蒸馏往往更常见。
    • 可用大模型训练小模型并保持接近性能：DistilBERT，性能略降但模型更小、更易部署。
    • 可剪枝大模型且保持准确率：加稀疏，实践中相对不常见，因为稀疏剪枝未必对 GPU 友好，难以直接转化为端到端加速。
  • 参数高效微调（PEFT，Parameter-Efficient Fine-Tuning）：减少微调阶段可更新参数与显存占用。全量微调通常需要为大量参数保存梯度与优化器状态，内存开销很大；LoRA 等方法用低秩增量近似权重更新，使得在较低显存 GPU 上也能完成微调。
    • 可更高效地微调大模型：低秩适配（LoRA，Low-rank adaptation），在微调阶段降低显存与训练成本（也便于保存/切换不同任务的适配器）。
  • 数值近似（Numerical approximation）与量化：降低数值精度以节省显存与带宽，并在很多场景下提升吞吐；模型并不总需要全精度计算才能保持可接受效果。
    • 可用低数值精度版本：LLM.int8，对大离群值仍用常规 16-bit 精度计算；主要用于推理阶段节省显存、提升吞吐，在部分设置下也可用于训练/微调的内存优化。
  • 组合策略：将压缩 / 微调 / 量化等思路叠加使用，以获得更好的“效果—成本”权衡。
    • 可组合这些想法：量化低秩自适应（QLoRA，Quantized Low-Rank Adaptation）。
  • 条件计算与混合模型（Mixtures of models）：以多个子网络/专家组成系统，每次只激活一个或少数几个专家参与计算，用更低的每 token 计算量换取更大的模型容量与更强的表达能力（同时也会带来路由、并行通信等工程权衡）。
    • 可让多个小模型协作：稀疏混合专家模型（SMoE，Sparse Mixture of Experts）。