原创教学项目 · 核对：2026-10-09。沿用知识助手的例子；这里设计实验，不宣称跑出了模型收益。
我们已经把正确资料放进上下文，助手却常常不引用来源。现在有一笔有限的训练预算，该用来换模型、做 SFT，还是先改提示？
先别急着选框架。把几条错误输入留下来，确认要改变的是模型如何使用资料，而不是把每天变化的资料记进参数。两件事需要的数据和验收方式并不一样。
先做一个不训练的对照
固定问题、资料和生成预算，试清楚的指令与输出约束。比如要求返回 answer 和 citations，确实能减少漏字段；但它不能保证引用真的支持答案。格式通过与证据正确要分开测。
| 眼前的问题 | 先试什么 | 为什么不直接训练 |
|---|---|---|
| 资料已经过期 | 更新检索（retrieval）快照和版本选择 | SFT 不会自动知道昨天改了哪条规定 |
| 总漏引用字段 | 提示、结构化输出、解析检查 | 可能不需要维护新权重 |
| 字段齐全，但经常引用错段落 | 有依据的示范、缺证据与冲突样本 | 这是行为学习的候选（candidate）问题，但先确认标注可靠 |
| 两种回答都对，只是详略不同 | 明确偏好标准，检查评审一致性 | 不同评审可能偏好相反，不能只靠更多数据解决 |
假设提示已经改过，漏引和错引仍反复出现，我们才进入这次 SFT 实验。评估中保留“不应回答”的题：否则模型也许只是学会每次都编一个像引用的字符串。
LoRA、QLoRA、全参，差别在哪
SFT 描述的是用示范训练的目标；LoRA 和全参描述哪些参数更新；QLoRA 还涉及基座的量化存储。它们不是三个互斥的训练目标。
| 方案 | 这次为什么考虑它 | 要付出的代价 | 什么时候重新考虑 |
|---|---|---|---|
| LoRA | 先用较小的可训练参数集合检验数据是否有用 | rank、插入位置会限制可学习的变化；还要管理 adapter 与基座版本 | 明确的数据问题已排除，合理调参后仍欠拟合 |
| QLoRA | 基座权重是显存瓶颈，希望在量化基座上训练 adapter | 量化误差、算子和导出兼容性；未必比非量化 LoRA 更快 | 有足够显存，或量化让关键任务退化 |
| 全参微调（fine-tuning） | 希望让更多参数适应任务，并能承担状态与计算成本 | 梯度、优化器状态和保存成本更大；仍可能过拟合（overfitting） | 数据量、任务变化或实验结果不足以支持额外成本 |
例如一个 $4096\times4096$ 的线性层有 16,777,216 个权重。若给它加 rank 16 的 LoRA，新增可训练参数是 $16(4096+4096)=131{,}072$，相当于原矩阵的约 0.78%。这是这个矩阵的参数比例，不是整次训练显存只剩 0.78%。 基座还在，前向激活也还在。
QLoRA 通常冻结量化基座、训练额外参数，并不是把所有训练状态都改成 4-bit。具体支持的量化、计算精度和合并方式要核对 PEFT 的量化说明。原理可接着看 LoRA 与 QLoRA。
框架分工，不是一排替代品
这次项目先选容易检查 batch 的训练路径。等有了 rollout、奖励（reward）计算和权重同步（refit），再考虑更复杂的编排；不是装的框架越多，实验就越完整。
| 层次 | 可以用什么 | 在项目里负责什么 |
|---|---|---|
| 模型与 tokenizer | Transformers | 加载固定 revision、套聊天模板、前向与生成 |
| SFT 训练循环 | TRL SFTTrainer，或可审计的自定义循环 | 数据到 batch、loss、优化与验证 |
| 参数高效更新 | PEFT | adapter 配置、可训练参数和产物 |
| 启动与分布式后端 | Accelerate 配置训练启动；按兼容性接 DDP、FSDP 或 DeepSpeed | 混合精度、进程与状态分片（sharding），不负责定义业务正确性 |
| 多角色后训练（post-training） | NeMo RL、verl | 训练、生成、奖励等计算的组织；要额外核对模型和后端支持 |
| 生成服务 | vLLM、SGLang | 可用于评估或 rollout 的生成，不替代反向训练器（trainer） |
NeMo RL 的后端文档区分 DTensor / FSDP2 和 Megatron 路径；verl强调训练与生成组件的组织。这里不做谁“最快”的排名：只有把模型、长度分布、设备和目标固定，性能对照才有意义。已有团队栈也会影响选择；能复用可靠的数据和恢复流程，往往比少写几行启动命令更重要。
第一轮配置，要能解释每一个选择
下面是实验说明文件，不是可直接交给 TRL 的配置。尖括号必须换成真实 revision；依赖锁文件也要随实验保存。项目现有 mask 示例按 TRL v0.29.0 核对，不代表 2026 年只能用这个版本。
{
"run_id": "citation-lora-pilot",
"base_revision": "<immutable-model-revision>",
"tokenizer_revision": "<immutable-tokenizer-revision>",
"dataset_snapshot": "citation-demo-v1",
"split_rule": "question-family-v1",
"template_hash": "<sha256>",
"objective": "assistant-target-token-mean",
"adaptation": "lora",
"packing": false,
"resume_at": "optimizer-step-boundary"
}
为什么第一轮不 packing？不是它不好，而是先让每条样本的边界和 label 一眼可查。为什么先 LoRA？这次先验证示范是否有用，同时限制训练状态成本；不是预先认定全参没有价值。
学习率、rank、最大长度不能凭这张表拍定。先统计长度和有效 target token，跑一小批稳定性检查，再用事先限定的开发集调参预算比较。测试集不能变成每天反复挑配置的地方。
做到什么程度，才值得扩规模
| 阶段 | 留下什么证据 | 没通过时先查哪里 |
|---|---|---|
| 数据小样本 | 解码后的完整输入、target 区间、来源 | 模板、拼接、截断、标签 |
| tiny overfit | 少量训练样本的 loss 与生成变化 | 梯度、学习率，样本目标是否互相矛盾；记住这几条不代表能泛化 |
| 中断恢复 | 连续跑与恢复跑的样本序列、状态对照 | optimizer、调度器、RNG、数据游标 |
| 开发集比较 | 引用正确性、拒答分组、时间和显存 | 数据覆盖与目标，而不只是换更大模型 |
| 固定测试集 | 最终方案与旧版的配对结果 | 决定是否采用，不继续用测试集调参 |
“升级到 RL”也需要自己的理由：能否采样有效轨迹、奖励能否分辨好坏、是否存在奖励投机？SFT 做完没有提升，不自动说明该换 GRPO。
下一篇把这些决定落到数据结构与 batch；只关心多卡，可以直接去分布式选择。
本页术语 9
- 检索 retrieval
- 从外部语料里找出相关内容
- 候选 candidate
- 召回阶段捞出来、等待精排挑选的内容
- 微调 fine-tuning
- 在预训练权重上继续训练以适配具体任务
- 过拟合 overfitting
- 训练集越来越好，没见过的数据反而变差
- 奖励 reward
- RL 里指导策略更新的标量信号
- 权重同步 refit
- 训练器更新完权重后推回推理引擎，让下一轮 rollout 用上新策略
- 分片 sharding
- 把参数、梯度或优化器状态切开分给多张卡，每张只存其中一份
- 后训练 post-training
- 预训练之后为特定任务和行为做的所有训练
- 训练器 trainer
- 负责计算 loss、反向传播并更新模型参数的系统