企业官网建设流程全解析

如果你最近在关注大模型开源生态，大概率会注意到一个现象：真正决定一个模型能不能被业务用起来的，往往不是基座模型的预训练花絮，而是后训练环节做得够不够工程化。Miles v0.1 把这个过程包装成一个明确的说法——Production-level Post-training。这篇文章我会把它拆开来讲清楚：为什么后训练值得单独做一个“生产级”版本，它跟研究脚本有什么区别，以及如果你想在自己的团队里落地整套后训练管线，应该从哪些环节入手。

先说一个明确判断：后训练在生产环境里的核心难点从来不是某个 loss 函数灵不灵，而是整个流程能不能可复现、可回滚、可观测、可灰度。模型训练组的人常说“效果还行”，但运维和业务同学更关心的是“这次训练跟上次有什么差异”“出问题了怎么退回去”“上线之后怎么评估”。Miles v0.1 这类项目传递的信号，就是把后训练当成一套标准的工程流程来设计，而不是一堆散落的实验脚本。

这篇文章会面向三类读者：正在做大模型应用、准备微调或做偏好对齐的算法工程师；负责模型上线和推理服务的平台工程师；以及被“微调一下效果就很好”这种说法误导过、想系统理解后训练全流程的技术管理者。读完你至少能获得三样东西：一张清楚的后训练全链路地图、一套可以照着搭建的最小管线实践、一份能直接用于排障的常见问题清单。

1. 这篇文章真正要解决的问题

很多人第一次接触微调时都会有一个疑惑：预训练已经花了那么多钱学知识了，为什么还要“后训练”？换一个更直接的问法：一个已经预训练好的底座模型，离“能直接上线给用户用”到底还差多远？

差得很远。预训练模型的输出往往不适合直接面对用户。它可能不会遵守对话格式，不知道什么时候该说“不知道”，容易被带偏生成有害内容，更不会主动区分“这是命令”“这是问题”“这是闲聊”。后训练要做的就是把这些能力补上，把一个“会续写文本”的模型，变成“能安全、稳定、符合预期地完成对话任务”的产品。

但问题在于，后训练本身是一条包含多阶段的链路：指令微调、偏好对齐、安全对齐、评测、量化、部署适配，每一段单独拿出来都有大量研究论文，而拼到一起后，工程复杂度指数级上升。大量团队的真实状态是：算法同学在本地 notebook 里跑通了 SFT（监督微调），效果看着不错，但没人说得清数据是怎么清洗的、训练时用了什么随机种子、评测集是不是有泄漏、上线后 loss 回升了该怎么办。

Miles v0.1 这个项目名里的关键字是 production-level。它意味着作者关心的重点不是某个新算法，而是怎么让整个后训练流程到达可生产状态。生产状态的标准是什么？至少要满足：

• 同一份代码和数据，任何时候重跑都能得到一致或近似一致的结果。
• 训练过程中的每个产物都有版本号，能追溯到输入数据、代码 commit、超参配置。
• 模型效果可以被客观评估，而不是只靠“我觉得回答得不错”。
• 上线后出现问题，能够快速定位是数据问题、训练问题还是推理部署问题。

这篇文章要解决的，就是帮你建立这套判断标准，并给出落地路径。不要把它当成某个框架的官方教程来读，更值得做的是吸收背后的工程思路，迁移到自己的技术栈里。

2. 后训练的核心概念与生产级定位

2.1 预训练与后训练的关系边界

为了把后训练讲清楚，先要明确它和预训练的关系。通常认为，预训练是在海量无标注文本上做自监督学习，模型在这阶段掌握了语言结构、世界知识和推理能力的底子；后训练则是在预训练模型基础上，用更高质量、更聚焦的数据做进一步训练，让模型行为和人类预期对齐。

可以用一个不算精确但很好理解的类比：预训练像是培养一个知识渊博但性格未定的人，他知道很多，但不知道在什么场合说什么话；后训练像是行为礼仪培训，教会他在面对不同提问时，如何组织回答、控制语气、承认无知、拒绝危险请求。

后训练的主要环节包括：

• SFT（Supervised Fine-Tuning），监督微调：用“指令-期望回答”数据做有监督学习，让模型学会服从指令。
• RLHF / DPO / GRPO 等偏好对齐：用人类偏好数据训练模型，让模型学会不只“正确”，还要“讨人喜欢”“安全”。
• 评测（Evaluation）：用自动化指标和人工评估结合的方式，判断训练是否达到目标。
• 安全与越狱防护：测试模型在面对恶意提示时是否还能保持安全边界。
• 推理适配：把训练产物转换为可服务的格式，做量化、预热、灰度。

Miles v0.1 从名称上把 Post-training 作为一个整体单元，说明它把这些环节整合到了同一套工具链里，而不是作为独立实验存在。生产级的含义是：每个环节都不是一次性手工操作，而是可重复执行的流程。

2.2 容易被误解的几个概念

新人很容易把三个概念混在一起：微调、对齐、后训练。

微调（Fine-tuning）是个泛称，只要在预训练模型上做有监督训练都算微调。对齐（Alignment）更聚焦于让模型符合人类偏好，RLHF、DPO 都是对齐方法。后训练是更大的范畴，它包含微调和对齐，还包含评测、过滤、安全处理、部署适配这些非训练环节。

另一个容易误解的点是强化学习类方法的地位。很多文章说 RLHF 让模型更像人类，但落到工程上，它只是后训练流水线中的一个阶段，而且成本很高，需要奖励模型、采样、策略更新等多个组件。DPO 这类无需奖励模型的直接偏好优化方法，因为更轻量，已经被大量生产项目使用。GRPO 则是在强化学习方法里进一步降低资源需求的一种技术路线。选择哪种偏好对齐方法，更多要结合数据规模、算力预算和团队能力，而不是一味追新。

2.3 什么是生产级

生产级这个词被用得很泛，我给出一个相对严格的定义：一个流程能被称为生产级，必须满足五个特征——确定性、可追溯、可观测、可回滚、可灰度。

确定性指的是同样的输入流程能复现出同样的结果。后训练里常见的随机性问题包括数据加载顺序、多卡通信的随机性、dropout、flash attention 的数值行为差异。要做到强确定性很难，但至少要保证变化在可控范围。

可追溯指的是任何一份模型产物都能找到它的数据版本、代码版本、配置版本。缺少这一点，训练完发现效果异常，连排查入口都没有。

可观测指的是训练过程中的 loss、梯度范数、学习率、评估指标、显存占用都要有指标记录，而不是训练完看一眼 loss 曲线就结束。

可回滚是很多团队最容易忽略的。生产系统里训练不是一条直线。有时候新数据反而让模型变笨了，这时候要能快速回到上一个效果稳定的版本。这要求检查点保存策略、模型仓库版本管理都提前设计好。

可灰度是说模型不能直接一把全量上线。先让部分请求走新模型，对比关键指标后再逐渐放大流量，这是大模型应用上线的基本纪律。

3. Miles v0.1 的定位：从研究脚本到生产管线的关键一跃

回到 Miles v0.1 本身，从项目名可以提取出两个信息：第一，项目版本是 v0.1，意味着它还处于早期阶段；第二，它的目标定位是生产级后训练，说明作者在一开始就把工程化质量放在和算法效果同等重要的位置。

结合材料来看，这个项目要应对的核心问题，是很多 AI 团队在从研究走向落地时都会撞上的墙：算法验证阶段可以用 jupyter notebook、单卡训练、随机种子不固定、数据集随手切；但一到生产环境，就要面对多卡分布式训练、超参搜索的管理、数据版本变动、评测指标口径不一致、模型上线后的持续迭代等一系列完全不浪漫的问题。

Miles v0.1 可以理解成一次把这些工程问题显式化的尝试。v0.1 意味着它并不假装自己已经大而全，而是先把最小可用的生产级管线搭出来：数据准备、训练、评测、导出决策这四件事，用一套清晰的方式串起来。

这个思路本身比某个具体功能更重要。很多团队并不是没有后训练能力，而是能力散落在不同人的脚本里，没有形成标准流程。Miles v0.1 这种项目给出的价值，是让“从数据到模型”的流程可以被他人复现和接手，而不是只能靠原作者亲手操作。

如果你所在的团队已经开始做微调，但每次训练都是一次“手工操作”，那这个项目的思路就有直接参考价值。你不需要照着它的代码抄，需要学习的是它如何切开流程边界、如何定义每个阶段的输入输出、如何保证流程可被重复执行。

4. 生产级后训练的环境准备与前置条件

后训练工程化第一步是把环境固定下来。很多复现问题都出在环境漂移：三个月前跑的训练脚本，今天重新执行，依赖包版本已经变了，GPU 驱动也换了，结果自然对不上。

一套生产级后训练环境，至少要包括以下层面的固定：

• 训练框架：PyTorch 为主，配合 DeepSpeed 或 Megatron-LM 做分布式加速。
• 模型底座：选择开源基座模型，比如 Qwen、Llama、DeepSeek 等系列的开放版本，注意确认基座模型的许可证和商用条款。
• Python 包管理：建议用 poetry 或 uv 管理依赖，锁版本；直接用 requirements.txt 也可以，但要锁定具体版本号，不要用范围依赖。
• GPU 资源：训练至少需要多卡环境，单卡可以用于开发和调试，但完整验证需要 2 卡以上。具体显存需求取决于模型量和 LoRA/全参训练策略，没有统一的数字。
• 实验追踪：建议准备一个实验记录平台，MLflow 或者 WandB 都可以，用于记录超参、指标、产物路径。
• 数据版本管理：用 DVC 这类数据版本工具，把数据集目录纳入版本控制。

下面给出一个推荐的目录结构，它适用于大多数中小团队的后训练项目：

posttrain-project/ ├── configs/ # 训练和评估配置 │ ├── sft.yaml │ ├── align.yaml │ └── eval.yaml ├── data/ # 数据目录 │ ├── raw/ # 原始数据 │ ├── processed/ # 清洗和格式化后的数据 │ └── splits/ # 训练/验证/测试切分 ├── scripts/ # 脚本 │ ├── prepare_data.py │ ├── run_sft.py │ ├── run_align.py │ └── run_eval.py ├── outputs/ # 训练产物 │ ├── checkpoints/ │ └── eval_results/ └── requirements.txt

这个结构的好处是：每个环节都有明确的输入输出位置，不会出现“数据在桌面的某个 zip 里，模型文件在服务器 /tmp 下”这种失控情况。

需要特别提醒的是，不要在生产训练环境里使用全局最新版的依赖。正确的做法是每次训练开始前，同步项目 lock 文件，在干净环境里安装依赖，用固定镜像构建容器。环境越能标准化，后续排障越轻松。

5. 后训练核心流程拆解

生产级后训练流程可以拆成五个阶段：数据工程、指令微调、偏好对齐、评估验收、导出上线。每个阶段都要有清晰的入口、执行过程和出口。

5.1 数据工程是真正的第一道关卡

数据质量直接决定后训练的天花板。算法再先进，数据里全是噪声，模型学出来的只会是噪声模式。数据工程可以细化为：

• 数据来源整理：明确每个数据集的来源、授权、用途。
• 去重与清洗：去掉重复样本、低质量文本、包含隐私信息的内容。
• 模板格式化：把指令和回答统一封装成模型要求的对话模板。
• 切分与隔离：严格区分训练集、验证集、测试集，避免评估集泄漏到训练数据里。

尤其要注意测试集泄漏。很多人做 SFT 时从同一个数据集里分出 train 和 eval，但 eval 里的对话和 train 里的对话高度相似，导致评测分数虚高。生产级做法是从不同来源构建评估集，或者至少做基于文本相似度的查重。

5.2 指令微调 SFT 是基础

SFT 的目标是让模型学会“看到指令，给出符合格式的回答”。这一步不需要引入复杂算法，就是标准的有监督训练。关键点在于：数据配比、训练轮数、学习率、LoRA rank 的选择。

最常见的问题是训练轮数过大导致过拟合。模型在训练集上滔滔不绝，看起来能力很强，但面对没见过的指令就只会复读训练样本里的句子。经验做法是在训练过程中持续保留一个固定评估集，每个 epoch 后都跑评测，而不是等全部训练结束再看结果。

5.3 偏好对齐提升交互质感

偏好对齐解决的是“正确但是难用”的问题。模型可能回答正确，但语气生硬、内容冗长、不肯承认不知道、容易被提示词带偏。DPO 是生产环境中性价比很高的选择，它不需要单独训练奖励模型，直接用偏好数据做目标优化。

GRPO 这类方法适合团队有强化学习经验、且数据规模较大的场景。它的好处是不依赖单独的 value model，显存开销相对传统 PPO 更低，但实现的复杂度仍然高于 DPO。小团队起步阶段建议先用 DPO 打通流程，再逐步尝试更复杂的对齐策略。

5.4 评估验收是生产级的核心关卡

评估最怕主观。生产级后训练要求评估结果可以量化、复现和审计。至少要有三类指标：

• 客观指标：BLEU、ROUGE 等文本相似性指标，适合生成任务有标准答案的场景。
• 分类指标：回答是否符合格式要求、是否包含有害内容、是否偏离主题。
• 人工评估：抽样由多人打分，计算一致性。

评估集不应该只是训练数据里随机切出来的一部分，而应该针对真实业务场景单独构造。比如你的产品是客服助手，评估集就应该包含大量真实客服对话里的困难case，包括用户投诉、模糊提问、恶意输入等。

5.5 导出上线不止是转格式

训练好的模型导出到推理服务还涉及量化、图优化、预热和灰度。生产环境常用 vLLM 这类推理框架，可以支持 PagedAttention、连续批处理等特性。模型格式上，Hugging Face 格式是主流中间格式，上线时可能需要转换为推理框架特定的格式。

导出之后要跑一轮推理冒烟测试，验证 chat template 是否带上、采样参数是否合理、并发请求下显存是否稳定。

6. 完整示例与代码实现

下面以一个通用思路演示生产级后训练的核心环节。这里的代码更多是示范“Miles v0.1 所倡导的流程可以长成什么样”，具体接口以你选择的训练框架版本为准。

6.1 数据准备脚本

假设原始数据是一个 JSONL 文件，每行包含 instruction 和 output 两个字段。数据准备脚本负责清洗、格式化、切分。

# 文件路径：scripts/prepare_data.py import json import random from pathlib import Path from datasets import Dataset, DatasetDict def load_raw_data(raw_path: str) -> list[dict]: records = [] with open(raw_path, "r", encoding="utf-8") as f: for line in f: line = line.strip() if not line: continue item = json.loads(line) if "instruction" in item and "output" in item: records.append(item) return records def deduplicate(records: list[dict]) -> list[dict]: seen = set() unique = [] for item in records: key = item["instruction"].strip() if key in seen: continue seen.add(key) unique.append(item) return unique def format_to_messages(records: list[dict]) -> list[dict]: formatted = [] for item in records: messages = [ {"role": "user", "content": item["instruction"].strip()}, {"role": "assistant", "content": item["output"].strip()}, ] formatted.append({"messages": messages}) return formatted def main(): raw_path = "data/raw/train.jsonl" output_dir = Path("data/processed") output_dir.mkdir(parents=True, exist_ok=True) records = load_raw_data(raw_path) records = deduplicate(records) formatted = format_to_messages(records) random.seed(42) random.shuffle(formatted) split = int(len(formatted) * 0.9) train_data = formatted[:split] eval_data = formatted[split:] dataset = DatasetDict({ "train": Dataset.from_list(train_data), "eval": Dataset.from_list(eval_data), }) dataset.save_to_disk("data/processed/instruction_dataset") if __name__ == "__main__": main()

这段脚本做的事情很基础，但价值在于把数据从原始状态处理成训练框架可以直接读取的格式。另一个隐藏要点是随机种子固定：数据切分、打乱顺序如果不固定，两次实验的数据分布就可能不同，直接影响结果对比。

6.2 SFT 训练脚本

训练脚本使用 Transformers 的 Trainer 接口，开启 LoRA 适配以降低显存需求。

# 文件路径：scripts/run_sft.py from dataclasses import dataclass from datasets import load_from_disk from transformers import ( AutoModelForCausalLM, AutoTokenizer, Trainer, TrainingArguments, DataCollatorForSeq2Seq, ) from peft import LoraConfig, get_peft_model @dataclass class SFTConfig: model_path: str = "base-model-path" data_path: str = "data/processed/instruction_dataset" output_dir: str = "outputs/checkpoints/sft_v1" learning_rate: float = 2e-5 num_epochs: int = 3 batch_size: int = 4 grad_accum_steps: int = 8 max_length: int = 2048 lora_rank: int = 8 seed: int = 42 def main(): cfg = SFTConfig() tokenizer = AutoTokenizer.from_pretrained(cfg.model_path, trust_remote_code=True) if tokenizer.pad_token is None: tokenizer.pad_token = tokenizer.eos_token dataset = load_from_disk(cfg.data_path) def tokenize_fn(examples): texts = [ tokenizer.apply_chat_template(messages, tokenize=False) for messages in examples["messages"] ] tokenized = tokenizer( texts, truncation=True, padding=True, max_length=cfg.max_length, ) tokenized["labels"] = tokenized["input_ids"].copy() return tokenized tokenized_dataset = dataset.map(tokenize_fn, batched=True, remove_columns=["messages"]) model = AutoModelForCausalLM.from_pretrained( cfg.model_path, torch_dtype="auto", trust_remote_code=True, ) lora_config = LoraConfig( r=cfg.lora_rank, lora_alpha=cfg.lora_rank * 2, lora_dropout=0.05, target_modules=["q_proj", "v_proj", "k_proj", "o_proj"], ) model = get_peft_model(model, lora_config) model.print_trainable_parameters() training_args = TrainingArguments( output_dir=cfg.output_dir, learning_rate=cfg.learning_rate, num_train_epochs=cfg.num_epochs, per_device_train_batch_size=cfg.batch_size, gradient_accumulation_steps=cfg.grad_accum_steps, evaluation_strategy="epoch", save_strategy="epoch", logging_steps=10, save_total_limit=3, seed=cfg.seed, report_to="none", remove_unused_columns=False, ) trainer = Trainer( model=model, args=training_args, train_dataset=tokenized_dataset["train"], eval_dataset=tokenized_dataset["eval"], tokenizer=tokenizer, data_collator=DataCollatorForSeq2Seq(tokenizer), ) trainer.train() trainer.save_model(cfg.output_dir) tokenizer.save_pretrained(cfg.output_dir) if __name__ == "__main__": main()

这段脚本体现了几点生产级意识：固定随机种子、定期保存检查点、限制保存数量防止磁盘爆炸、训练过程中同步跑验证集、把 tokenizer 一并保存避免推理时格式错乱。

6.3 偏好对齐 DPO 训练配置

DPO 训练需要偏好数据，每条样本包含 chosen（更偏好回答）和 rejected（较差回答）。下面是配置文件的示例。

# 文件路径：configs/align.yaml model_path: outputs/checkpoints/sft_v1 data_path: data/processed/preference_dataset output_dir: outputs/checkpoints/dpo_v1 beta: 0.1 learning_rate: 5e-6 num_train_epochs: 2 per_device_train_batch_size: 2 gradient_accumulation_steps: 16 max_length: 2048 max_prompt_length: 1024 seed: 42

调用脚本时，使用支持 DPO 的库，比如 TRL 的 DPOConfig 和 DPOTrainer。核心调参位置是 beta 和训练轮数。beta 控制对偏好差异的敏感程度，值越大越强调对齐，但也越容易牺牲通用能力。生产环境建议从 beta=0.1 起步，观察评测结果后再调整。

6.4 评估与验收脚本

评估脚本负责加载模型，在固定评估集上生成结果，并计算关键指标。

# 文件路径：scripts/run_eval.py import json from pathlib import Path from datasets import load_from_disk from transformers import AutoModelForCausalLM, AutoTokenizer from vllm import LLM, SamplingParams def load_eval_set(data_path: str): dataset = load_from_disk(data_path) return dataset["eval"] def generate_with_vllm(model_path: str, prompts: list[str]) -> list[str]: llm = LLM(model=model_path, gpu_memory_utilization=0.6) sampling_params = SamplingParams( temperature=0.7, top_p=0.9, max_tokens=1024, ) outputs = llm.generate(prompts, sampling_params) return [output.outputs[0].text for output in outputs] def check_format(outputs: list[str]) -> float: if not outputs: return 0.0 valid = sum(1 for text in outputs if len(text.strip()) > 10) return valid / len(outputs) def save_eval_result(result_path: str, records: list[dict], metrics: dict): Path(result_path).parent.mkdir(parents=True, exist_ok=True) with open(result_path, "w", encoding="utf-8") as f: json.dump({"metrics": metrics, "samples": records}, f, ensure_ascii=False, indent=2) def main(): model_path = "outputs/checkpoints/dpo_v1" eval_set = load_eval_set("data/processed/eval_dataset") prompts = [item["prompt"] for item in eval_set] outputs = generate_with_vllm(model_path, prompts) records = [] for item, output in zip(eval_set, outputs): records.append({ "prompt": item["prompt"], "reference": item.get("reference", ""), "generated": output, }) metrics = { "format_ok_rate": check_format(outputs), "total_samples": len(records), } save_eval_result("outputs/eval_results/dpo_v1.json", records, metrics) if __name__ == "__main__": main()

评估产出不只是分数，更重要的是保留采样结果。以后有人质疑“这个模型是不是变笨了”，你可以直接打开 JSON 文件，看到当时模型在哪些 prompt 上怎么回答的，而不是拿一句“调参问题”敷衍过去。

运行完整的后训练流程时，按以下顺序执行：

python scripts/prepare_data.py python scripts/run_sft.py python scripts/run_align.py --config configs/align.yaml python scripts/run_eval.py

7. 运行结果与效果验证

生产级验证不能只看一个 loss 值。SFT 训练完成会有 loss 曲线，DPO 训练也有对应的 loss 变化，但这些都只能说明训练过程没有崩溃，不能说明最终模型是好的。真正要关注三件事：训练过程是否健康、评估集分数是否提升、抽样生成是否符合预期。

训练过程健康性主要看：

• loss 是否单调下降，最终收敛。
• eval loss 和 train loss 之间的差距是否过大。差距过大说明过拟合风险。
• 梯度是否稳定，是否出现 NaN。
• 显存是否持续增长，增长是否接近上限。

评估集分数是比较的基准。注意对比方式：要保证“同一评估集、同一采样参数、同一评估代码”，否则分数差异没有意义。一个常见错误是这次评估用 temperature=0.1，下次用 temperature=0.9，结果分数变化很大，但这个变化不能归因于模型变好还是变坏。

抽样生成环节，批量生成长度不要超过模型上下文限制，建议把 prompt 设计成最贴近真实业务的形式。如果模型是多轮对话模型，评估脚本要模拟完整的多轮对话，而不是每一轮都从第一句话开始。多轮一致性是生产环境中容易被低估的问题：模型单轮表现优秀，但记得住前文条件、能在多轮追问下保持立场，才是真正可用的助手。

如果训练结果不符合预期，优先检查顺序是：先确认评测集本身有没有问题，再检查模型路径是否加载正确，最后才怀疑训练超参。很多人一上来就降低学习率重训，结果问题是评估脚本里没有加载最新的 tokenizer，导致对话模板格式错误，回答质量被系统性低估。这种排查顺序可以帮助快速定位问题方向。

8. 常见问题与排查思路

后训练生产环境中会遇到的问题高度集中，这里整理一份排查表，覆盖高频场景。

这些问题的共性根源，一个是流程不规范导致的环境不一致，一个是数据管理缺失导致的效果不可归因。生产级后训练的很大一部分工作，就是在消除这类不确定性。

9. 最佳实践与工程建议

9.1 数据层面的最佳实践

第一，数据要版本化。数据集每次修改都应该有记录，至少要记下“这条数据是从哪个来源来的”“清洗脚本是哪个版本”“有多少条记录”“有没有做过去重”。推荐为每一次数据变更打一个 data version，把这个版本号写入训练配置和模型产物记录中。出了效果问题，先对比数据版本，这是最快的归因路径。

第二，评估集要独立构建。试图从训练数据里分一点出来当评估集，几乎一定会造成估值偏差。独立构建的意思是评估集的构造逻辑和训练集不同，甚至来源也不同。如果做不到完全独立，至少要做一个文本查重，把与训练样本相似度过高的评估样本过滤掉。

第三，指令数据不要贪多。很多人认为数据越多越好，实际上后训练的数据质量曲线先快速上升到达峰值后，继续添加低质量数据反而会拉低效果。对 SFT 数据，宁可做几百条高质量、覆盖典型场景、标注风格一致的样本，也不要堆几万条从网页上随手抓来的杂数据。

9.2 训练过程层面的最佳实践

第一，用 checkpoint 策略做灾难恢复。每训练一个 epoch 保存一个 checkpoint，并保留最近 N 个检查点。这样无论是显存崩溃还是发现某次训练数据有问题，都能回到一个特定时间点，而不是整个实验白跑。

第二，所有实验固定随机种子。数据打乱顺序、模型权重初始化、dropout 都会受随机性影响。固定 seed 的前提下，即使不能做到完全确定，也能把不同实验的差异控制到最小。这在做超参对比时尤其关键：如果两个实验的差异既来自超参又来自随机性，结论就不干净。

第三，记录一切必要的上下文。每次训练都要记录模型基座版本、数据集路径和版本、代码 commit 号、超参配置、GPU 类型和数量、依赖包版本。这些信息收集起来很简单，但丢失之后再想补几乎不可能。推荐在训练启动前自动生成一份实验配置快照。产物目录命名也尽量带上关键信息，例如sft_v1_data_v3_lr2e-5，这样简单查看文件名就能判断实验身份，而不是每次都要打开配置文件才知道是哪个版本。

9.3 评测与上线层面的最佳实践

第一，把评测做成一个门槛，而不是一个结论。评估结果应该服务于上线决策：模型达到什么分数可以放量？关键场景的错误率超过多少必须回滚？这些规则要在训练之前就定义好，避免训练完之后根据结果美化期望。

第二，上线先小流量灰度。新的后训练模型即使离线评估再好，也无法完全模拟真实流量中的 prompt 分布。建议初期只让百分之一到百分之五的请求走新模型，观察线上指标是否异常，再逐步放量。灰度期间新模型产生的日志要单独标记，方便后续做案例复盘。

第三，保存上线模型对应的采样和预测样本。灰度结束之后，把新模型在灰度期间收到的典型请求和回答离线存档。这些样本是下一轮训练最有价值的真实数据素材。

9.4 团队协作层面的最佳实践

模型后训练不应该是一个人的手动过程。理想状态下，算法工程师定义训练方案和评估标准，平台工程师负责把流程固化到 CI/CD 里，评测工程师或者懂业务的产品同学参与评估集构建和人工评估。哪怕团队只有一两个人，也应该把每一步的信息记录成文档，方便半个月后的另一个人接手。

建议从第一天就使用分支管理训练代码：主分支保持可运行状态，实验分支跑新方案。与训练无关的推理代码不要混在同一仓库，避免互相影响依赖版本。

10. 总结与后续学习方向

Miles v0.1 把这个领域最容易被忽略的东西拉到了台面上：post-training 不是魔法，它是一套流程。这套流程要让数据、代码、超参、评测、模型产物全部可以被追溯。如果只理解到它一个训练工具，就错过了它的更大价值。

从实践路径看，第一步是跑通一个最小闭环：取一个小模型，准备一份不超过一千条的指令数据，跑一遍 SFT，再做一次 DPO 对齐，最后用固定评估集打分，把整个链路从脚本到产物完整走通。第二步是补充工程组件：实验追踪、数据版本、检查点归档、自动评估。第三步才是规模化和自动化：持续数据更新、定期重新训练、灰度发布决策。

后训练方向上值得继续深入的内容至少有三块：偏好对齐算法的选型与调参经验，比如 DPO 的 beta 值对生成风格的实际影响；评估方法论，怎样设计一个不欺骗自己的评估集；推理部署的适配，如何在量化、延迟和效果之间找到平衡点。这三块任何一块都够研究很久，但它们都应该建立在“生产级流程”这个地基上。

一个真实的工程经验放在最后：不要在一次训练里同时修改多个变量。很多人为了省时间，训练脚本里既换了数据集，又改了对话模板，还调了学习率，结果效果变好了，说不清是哪一步起的作用；效果变差了，更不知道要回滚到哪里。生产级后训练的本质就是把变量隔离开，让每一次实验回答一个小问题。这套纪律，比任何单个算法技巧都值钱。