第9周：微调与提示工程

本日概要

提示工程的核心不是找到某句「咒语」，而是把任务说清楚：明确角色与目标、给出输入与输出的确切格式、提供边界条件与反例、必要时给出示例。官方指南推荐的做法高度一致——先写清楚任务与成功标准，再逐步增加结构（分隔符、标签、输出模板），最后才考虑示例数量。同样重要的是建立评估：没有一组固定的测试样例和判定标准，任何「改了提示感觉更好了」的判断都不可复核。把提示当成代码来管理——有版本、有测试、有变更记录——是从玩具走向生产的分界线。

学习目标

• 能写出包含角色、任务、输入格式、输出格式与边界条件的结构化提示
• 能为一个任务设计固定测试集与可判定的成功标准
• 能通过失败样例归纳出提示需要补充的具体信息
• 能说明为什么提示需要版本管理与变更记录

核心讲解

实践任务

为同一任务写出三种不同结构的提示，在一组固定测试样例上评估，记录每种提示的通过率与失败模式。

• 选定一个明确的任务（如从文本中抽取结构化字段），编写至少十条测试样例，覆盖典型、边界与已知失败情况，并写出每条的可判定期望。
• 写出三种提示：仅任务描述、任务加输出格式约束、任务加格式约束加两个示例，分别在测试集上运行并记录通过率。
• 收集失败样例，按失败原因分类（格式不符、信息缺失、越界作答、理解偏差），为每类归纳出提示中缺少的具体信息。
• 根据失败分析修订出第四版提示，重跑测试集并记录通过率变化；把四个版本、改动原因与测试结果一起存档。

自测与答案

今日完成标准

• 提交不少于十条测试样例及其可判定期望
• 提交四个提示版本的通过率对比与失败样例分类统计
• 提交版本存档，每版附改动原因与对应测试结果

常见错误与纠正提示

• 凭单次输出的观感判断提示是否变好，没有固定测试集
• 把外部文档内容与系统指令直接拼接，留下注入风险
• 提示散落在代码字符串中，无版本与改动记录

分层任务

关联知识点

• 提示工程

延伸阅读

• Prompt engineering overview（Anthropic 官方文档）

本日概要

当任务需要多步推理或需要外部信息时，单轮提示往往不够。让模型显式写出中间推理步骤，在多步算术与常识推理类任务上能明显提升准确率，但它增加输出词元与延迟，且中间步骤看起来合理不代表结论正确。ReAct 的思路是把推理与行动交替进行：模型先思考下一步要做什么，然后调用工具获取真实信息，再根据结果继续推理。这让模型的结论有了外部依据，也让整个过程可被记录和审计。工程上真正重要的是：每一步工具调用的输入输出都要留痕，失败时能定位到具体的哪一步。

学习目标

• 能说明显式中间推理的适用任务与代价，并指出它不保证结论正确
• 能描述推理与行动交替的循环结构，并画出一次完整调用的时序
• 能为工具调用设计输入校验、超时与失败处置
• 能设计可审计的执行记录，使任意一次失败都能定位到具体步骤

核心讲解

实践任务

实现一个包含推理与工具调用交替的流程，记录每一步的思考、调用与结果，并构造一次工具失败观察系统行为。

• 定义至少两个工具（如检索与计算），为每个工具写出参数结构、取值范围与校验规则。
• 实现推理与行动交替的循环，为一个需要多步的问题记录完整轨迹：每步的思考、调用参数、返回结果。
• 构造三类工具失败（超时、返回错误、返回空结果），分别记录系统行为，并写出各自的处置策略。
• 构造一个中间推理看似合理但结论错误的样例，说明为什么中间步骤不能作为结论可信的依据，并给出独立校验方案。

自测与答案

今日完成标准

• 提交工具定义与参数校验规则，覆盖非法与越界输入
• 提交一次完整执行轨迹，每步含思考、调用参数与返回结果
• 提交三类工具失败的系统行为记录与处置策略，以及一个中间推理正确但结论错误的样例分析

常见错误与纠正提示

• 把模型生成的参数直接拼接进查询或命令，不做校验
• 工具失败时无处置策略，模型转而编造答案
• 只保存最终答案不保存执行轨迹，出问题无法定位步骤

分层任务

关联知识点

• 提示工程
• AI Agent

延伸阅读

• Chain-of-Thought Prompting Elicits Reasoning in Large Language Models（arXiv 论文页面）
• ReAct: Synergizing Reasoning and Acting in Language Models（arXiv 论文页面）
• Tool use with Claude（Anthropic 官方文档）

本日概要

微调是在已有模型上用领域数据继续训练，改变的是模型参数本身。它适合让模型稳定掌握特定的输出格式、专业术语或风格，不适合用来注入频繁变化的事实知识——后者应当交给检索。判断是否需要微调之前，应当先穷尽提示工程与检索的空间，因为微调引入了持续成本：数据构造与清洗、训练与评估、模型版本管理、以及每次基础模型升级后的重新微调。数据质量决定微调效果的上限，一份两千条经过人工核对的高质量样本，通常胜过几万条自动生成但未经检查的样本。

学习目标

• 能说明微调与检索各自适合解决的问题类型，并给出判断顺序
• 能列出微调引入的持续成本，并据此论证是否值得
• 能设计指令数据集的字段结构、来源与质量核对流程
• 能设计微调效果的评估方案，包含与提示工程基线的对比

核心讲解

实践任务

为一个具体任务写出微调必要性论证，并构造一份小规模高质量的指令数据集，说明每条样本的来源与核对方式。

• 为选定任务写出微调必要性论证：说明提示工程与检索分别尝试到什么程度、为何不足，以及微调预期解决什么。
• 列出微调的持续成本清单（数据、训练、评估、版本管理、基础模型升级后的重做），并对每项给出量级估计与依据。
• 构造不少于五十条指令样本，统一字段结构与输出格式，为每条标注来源与核对方式；单独划出不参与训练的评估样本。
• 设计评估方案：与提示工程基线的对比指标、评估样本的选取方式、以及判断微调是否值得的量化标准。

自测与答案

今日完成标准

• 提交微调必要性论证，说明提示与检索的尝试程度及其不足
• 提交持续成本清单，每项有量级估计与依据
• 提交不少于五十条结构统一、逐条标注来源的指令样本，并划分出独立评估样本

常见错误与纠正提示

• 跳过提示工程与检索直接微调，用高成本方案解决低成本问题
• 用微调注入会频繁变化的事实，导致模型知识很快过时
• 用参与训练的样本评估微调效果，得到虚高结论

分层任务

关联知识点

• 微调技术
• 大模型训练

延伸阅读

• Transformers: Fine-tune a pretrained model（Hugging Face 官方文档）
• Hugging Face PEFT Documentation（Hugging Face 官方文档）

本日概要

全量微调需要更新模型的全部参数，显存与存储开销都很大。低秩适配的思路是：训练时冻结原始权重，只为部分权重矩阵引入一对低秩矩阵来表示更新量，需要训练与保存的参数因此大幅减少，一个适配器通常只有几十兆，可以为不同任务分别训练并按需加载。量化版本进一步把基础模型以低位宽存放，使单卡也能微调较大的模型，代价是引入量化误差。要注意的是，参数量减少不等于效果一定持平——秩的大小、作用在哪些层、学习率都会影响结果，必须在自己的评估集上验证。

学习目标

• 能说明低秩适配为什么能大幅减少可训练参数与保存体积
• 能列出影响低秩适配效果的主要超参数，并设计对比实验
• 能说明量化基础模型带来的收益与引入的误差
• 能设计适配器的版本管理与切换方案，说明多任务场景下的优势

核心讲解

实践任务

用低秩适配微调一个小模型，对比不同秩与作用范围的显存占用、训练时长与评估效果。

• 选择一个小规模开源模型与上一天构造的数据集，完成一次基础的低秩适配微调，记录可训练参数量、显存占用与训练时长。
• 固定其他条件，对比至少两个不同的秩，记录三项指标与评估集效果的变化。
• 固定秩，对比只作用于注意力投影与同时覆盖前馈层两种范围，记录差异。
• 若条件允许，对比量化与非量化基础模型下的显存、训练时长与评估效果；把适配器按任务命名归档，说明多任务切换方案。

自测与答案

今日完成标准

• 提交基础微调的可训练参数量、显存、训练时长与评估效果记录
• 提交秩与作用范围两组对比实验的完整数据
• 提交适配器归档与多任务切换方案说明；若做了量化对比，附三项指标的取舍结论

常见错误与纠正提示

• 照搬他人的秩与作用范围配置，不在自身任务上验证
• 只看训练损失下降就认为微调成功，不在独立评估集上验证
• 认为参数量少就一定不会过拟合，忽略小数据集上的风险

分层任务

关联知识点

• 微调技术

延伸阅读

• LoRA: Low-Rank Adaptation of Large Language Models（arXiv 论文页面）
• QLoRA: Efficient Finetuning of Quantized LLMs（arXiv 论文页面）
• Hugging Face PEFT Documentation（Hugging Face 官方文档）

本日概要

一次可信的微调实践，流程比技巧重要。完整闭环是：确定评估集与基线、准备并核对数据、划分训练与评估、训练并记录全部配置、在独立评估集上对比基线、判断是否达到预设标准、归档模型与配置。其中最容易被跳过的是「先定评估集与基线」——若在训练之后才确定评估方式，就很难避免有意无意地挑选对自己有利的指标。另一个常见问题是灾难性遗忘：模型在目标任务上变好，却在原本擅长的通用能力上退化，因此评估集必须同时包含目标任务样本与通用能力样本。

学习目标

• 能按正确顺序组织微调闭环，并说明先定评估集的原因
• 能设计同时覆盖目标任务与通用能力的评估集
• 能识别灾难性遗忘的表现，并给出缓解方向
• 能完整记录训练配置，使他人可以复现同一次微调

核心讲解

实践任务

跑通一次完整微调闭环，在包含目标任务与通用能力两部分的评估集上对比微调前后的表现。

• 先构造评估集：一部分为目标任务样本，一部分为通用能力样本；写出每部分的判定方式与「算成功」的量化标准。
• 在未微调的基础模型上跑出两部分基线分数并记录。
• 执行微调，完整记录基础模型版本、数据版本与划分、随机种子、全部超参数、训练轮数与硬件环境。
• 在同一评估集上评估微调后模型，分别报告两部分分数变化；若通用能力下降，尝试一种缓解手段并重跑，记录效果与代价。

自测与答案

今日完成标准

• 提交评估集构成、判定方式与预设成功标准，且均在训练前确定
• 提交微调前后两部分分数的对比，明确指出目标任务提升与通用能力变化
• 提交完整训练配置记录，他人依此可复现

常见错误与纠正提示

• 训练完成后才设计评估方式，挑选有利指标
• 评估集只含目标任务样本，通用能力退化未被发现
• 只保存模型权重不保存训练配置，无法复现或对比

分层任务

关联知识点

• 微调技术
• 大模型训练

延伸阅读

• Transformers: Fine-tune a pretrained model（Hugging Face 官方文档）
• Hugging Face PEFT Documentation（Hugging Face 官方文档）
• LoRA: Low-Rank Adaptation of Large Language Models（arXiv 论文页面）

本日概要

让模型调用工具，本质上是把「生成文本」变成「触发动作」，因此安全边界必须前移。一个可用的工具接口需要：明确的名称与用途描述、结构化的参数定义与取值范围、以及对模型不可见的执行侧校验。权限应当按最小必要授予——只读工具与会产生副作用的工具必须分开对待，后者需要额外的确认或审批。同样重要的是可观测性：每次调用的参数、结果、耗时与失败原因都要记录，并为整个会话设置步数与成本上限，防止循环调用失控。

学习目标

• 能为工具编写清晰的用途描述与结构化参数定义，包含取值范围与必填项
• 能区分只读工具与有副作用的工具，并为后者设计确认机制
• 能在执行侧实现参数校验，说明为什么不能依赖模型自觉
• 能为会话设置步数与成本上限，并验证超限时的降级行为

核心讲解

实践任务

实现一个带参数校验、权限分级与执行留痕的工具调用流程，并验证越权与越界请求被正确拒绝。

• 定义三个工具：两个只读、一个有副作用，为每个写出用途描述、参数结构、取值范围与必填项。
• 在执行侧实现参数校验，构造越界参数与指向未授权资源的请求，验证它们被拒绝并记录拒绝原因。
• 为有副作用的工具实现确认机制（人工确认或白名单校验），验证未确认时不会执行。
• 为会话设置最大步数与成本上限，构造一个会导致循环调用的问题，验证超限时正确停止并返回明确失败信息；提交完整执行留痕。

自测与答案

今日完成标准

• 提交三个工具的完整定义，参数含取值范围与必填项
• 提交越界与越权请求被拒绝的记录，以及有副作用工具的确认机制验证
• 提交步数或成本超限时的停止行为记录与完整执行留痕

常见错误与纠正提示

• 只读工具与有副作用的工具使用同一权限层级
• 把模型生成的参数直接拼接进查询、命令或文件路径
• 自主循环无步数与成本上限，失控时无法及时停止

分层任务

关联知识点

• AI Agent
• 提示工程

延伸阅读

• Tool use with Claude（Anthropic 官方文档）
• ReAct: Synergizing Reasoning and Acting in Language Models（arXiv 论文页面）

本日概要

本周收尾要回答一个高频问题：什么时候用提示，什么时候用检索，什么时候才微调。合理的顺序是自下而上——先用结构化提示与固定测试集把能拿到的效果拿满；效果瓶颈若来自模型不知道的事实，用检索补充；若来自输出格式不稳定、术语不规范或处理模式不一致，才考虑微调。三者不是互斥的，生产系统常常同时使用：微调稳定行为、检索提供事实、提示组织任务。真正的判断依据是分环节评估数据，而不是「听说微调效果好」。

学习目标

• 能按自下而上的顺序组织提示、检索与微调的选型决策
• 能用失败模式判断瓶颈属于事实缺失还是行为不稳定
• 能列出三种方案各自的一次性成本与持续成本
• 能定义改变当前选择的触发条件，并说明如何持续监控

核心讲解

实践任务

为三个不同的问题分别给出提示、检索、微调的选择与理由，并写出每种选择的成本与改变触发条件。

• 收集或构造三个不同类型的问题场景，为每个场景整理至少五条失败样例并按「事实缺失」与「行为不稳」分类。
• 根据分类结果为每个场景选择提示、检索或微调，写出选择理由与被放弃方案的具体原因。
• 为每个选择列出一次性成本与持续成本，标明哪些是估计值。
• 为每个场景定义改变选择的触发条件（含可检查的指标与阈值），并设计持续监控方案：测试集重跑时机、人工采样比例、失败类型趋势统计。

自测与答案

今日完成标准

• 三个场景各有不少于五条失败样例及其分类结果
• 每个场景有明确选择、理由、放弃原因与成本清单
• 每个场景有含指标与阈值的改变触发条件，以及可执行的持续监控方案

常见错误与纠正提示

• 凭「听说微调效果好」直接选择微调，跳过提示与检索
• 不做失败样例分类，把事实缺失误当作能力不足
• 方案定下后无持续监控，模型或数据变化后长期不知效果已退化

分层任务

关联知识点

• 提示工程
• 微调技术
• AI Agent

延伸阅读

• Prompt engineering overview（Anthropic 官方文档）
• Hugging Face PEFT Documentation（Hugging Face 官方文档）
• ReAct: Synergizing Reasoning and Acting in Language Models（arXiv 论文页面）